Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > MPEG-2 Encoding

Reply
 
Thread Tools Search this Thread Display Modes
Old 17th May 2005, 21:13   #381  |  Link
mrslacker
Junior Slacker
 
mrslacker's Avatar
 
Join Date: May 2004
Location: End-World
Posts: 296
Quote:
Originally posted by Xesdeeni
What tool do you recommend to extract a bit of the VOB but leave it in VOB (TS?) format?

AFAIK DVD uses program stream.

Quote:
Originally posted by neuron2 Sorry, there is a bug in the document (but not in the code). Bits 6 and 7 are swapped.
OK, so all frames are labeled progressive in that D2V. In what way? In that the mpeg progressive_frame flag is set in the picture header? Or that the picture_structure in the picture_coding_extension indicates a frame picture instead of a field picture pair?

This sort of addresses what manomo said about most PAL being progressive but encoded as interlaced. @manomo Are you saying that they are encoded as field pictures, not frame pictures?!? Or are you just saying the picture header is set to indicate interlaced frames? I would hope the encoder is not operating under the assuption that its input is not progressive, in the strict temporal definition. After all, this is why actual interlaced material is "harder" to encode. Bottom line, are you talking about a difference in the encoding algorithm, or just a stream discrepancy? Just curious.

But, as neuron2 mentioned, playing back a d2v with field operation set to RAW FRAMES would at least tell you if the original content is progressive, interlaced, hard telecined, or just messed up.

p.s. I hope this post doesn't look weird. I'm using lynx on the command line b/c of network problems.
__________________
There's no place like 127.0.0.1
mrslacker is offline   Reply With Quote
Old 18th May 2005, 08:28   #382  |  Link
manono
Moderator
 
Join Date: Oct 2001
Location: Hawaii
Posts: 7,406
Hi mrslacker-

I'm sorry, but I didn't fully understand your questions. Maybe some data from BitRate Viewer will help (and maybe not).

Here's one from an NTSC R1 DVD movie encoded as Progressive which showed as 100% FILM in the DGIndex produced .d2v:

Pic. structure: Frame
Field topfirst: Yes
DCT type: Frame
Quantscale: Nonlinear
Scan type: ZigZag
Frame type: Progressive

Here's one from a "Making Of" docu on the same DVD (Hitchcock's "Dial M For Murder") encoded as Interlaced. The .d2v is 0.00% FILM, and all full of 2's It's a mix of 30fps interlaced talking heads and photos being zoomed in and out, and hard telecined film clips:

Pic. structure: Frame
Field topfirst: Yes
DCT type: Field
Quantscale: Nonlinear
Scan type: Alternate
Frame type: Interlaced

And finally, here's one from a PAL DVD (the R2 PAL version of "Closer") which was encoded as Interlaced but had all Progressive content. The .d2v is also 0.00% FILM and also all full of 2's:

Pic. structure: Frame
Field topfirst: Yes
DCT type: Field
Quantscale: Nonlinear
Scan type: Alternate
Frame type: Interlaced
manono is offline   Reply With Quote
Old 18th May 2005, 13:09   #383  |  Link
Guest
Guest
 
Join Date: Jan 2002
Posts: 21,901
Quote:
Originally posted by mrslacker
OK, so all frames are labeled progressive in that D2V. In what way? In that the mpeg progressive_frame flag is set in the picture header? Or that the picture_structure in the picture_coding_extension indicates a frame picture instead of a field picture pair?
No, they are flagged as interlaced (bit 6 is progressive_frame and 0=interlaced). The progressive_frame flag in the picture coding extension is referred to. It's semantics are as described in the document.
Guest is offline   Reply With Quote
Old 18th May 2005, 16:36   #384  |  Link
mrslacker
Junior Slacker
 
mrslacker's Avatar
 
Join Date: May 2004
Location: End-World
Posts: 296
@neuron2
We're on the same page now. So, there's really no garauntee that a picture flagged as either progressive or interlaced is actually encoded that way, forgetting about the true nature of content entirely. For example, you could have originally progressive material, encoded as interlaced material, and later flaged as progessive. It would look progressive when viewed and when glancing at the flags, but it was encoded wrong. Does that make sense?

There are 10 types of people who understand binary, those who do and those who don't. And I started counting bits at 1 instead of 0... Oh the shame! Thanks.
__________________
There's no place like 127.0.0.1
mrslacker is offline   Reply With Quote
Old 18th May 2005, 16:45   #385  |  Link
mpucoder
Moderator
 
Join Date: Oct 2001
Posts: 3,530
While you cannot reliably determine the nature of the source from the flags, especially PAL, the flags DO tell you how each picture is encoded. That is their purpose. Progressive frame pictures are decoded differently than non-progressive (and fiddling with the flag will produce strange results). Also only progressive frame pictures can be pulled down using rff. However, and you will love this, within a progressive frame picture each macroblock can be either progressive or interlaced.

Last edited by mpucoder; 18th May 2005 at 16:52.
mpucoder is offline   Reply With Quote
Old 18th May 2005, 17:22   #386  |  Link
mrslacker
Junior Slacker
 
mrslacker's Avatar
 
Join Date: May 2004
Location: End-World
Posts: 296
Yes! That's exactly what I'm talking about. The DCT type the material was encoded with. The spec says that progressive_frame implies a given dct_type, if I'm reading it correctly.

I bring this up because I hear reports of material encoded as this or that, but are they talking about reckless and improper changing of the flags, or are they talking about the way the encoder treated the material in creating the DCT's macroblocks.

Like you said, mpucoder, the consequences would be quite deleterious. Given the widespread use of pulldown.exe -nopulldown (or maybe ReStream) with -prog_frames [p|i] set on a whim... Well it's nerve racking.

EDIT: I just wish there were a better way to determine Frame or Field DCT Coding. Is there no immutable indicator of frame or field macroblocks? Building a histogram of the macroblock types in a frame would be the idea way to determine and report the intended frame type... at least for the sake of the decoder to function properly.
__________________
There's no place like 127.0.0.1

Last edited by mrslacker; 18th May 2005 at 17:36.
mrslacker is offline   Reply With Quote
Old 18th May 2005, 19:13   #387  |  Link
mpucoder
Moderator
 
Join Date: Oct 2001
Posts: 3,530
You don't need a histogram for the decoder to operate properly, just the information as presented. That's the nature of streaming protocols.
There is a lot of interaction with picture structure, progressive frame, frame_pred_frame_dct, and dct_type. Also pulldown is affected by progressive sequence as well as the tff and rff flags. And alternate_scan can be more efficient at times for interlaced material. But why worry about it? All that is needed for pulldown is non-progressive sequence with progressive frame pictures. Anything else will not work properly. And trying to change flags without re-encoding just to make it work will fail as well. The choice of DCT and scan pattern are just tools for the encoder to get the best quality for the least bits, and not indicators of the source material type.
mpucoder is offline   Reply With Quote
Old 18th May 2005, 19:45   #388  |  Link
mrslacker
Junior Slacker
 
mrslacker's Avatar
 
Join Date: May 2004
Location: End-World
Posts: 296
Quote:
Originally posted by mpucoder
You don't need a histogram for the decoder to operate properly, just the information as presented.
Then just for informational purposes. But, If all macroblocks are field-coded, they you know the picture was encoded as part of an interlaced sequence, not just labeled incorrectly. What if you don't trust the information (flags) you are given? Does the decoder still function optimally, determining the nature of each macroblock? Maybe these questions are silly. I don't know enough to say.

Quote:
All that is needed for pulldown is non-progressive sequence with progressive frame pictures. Anything else will not work properly. And trying to change flags without re-encoding just to make it work will fail as well.
I'm getting completely off topic, as I'm not thinking about pulldown, just frame type flagging. I just want to know what it means when people say that PAL is usually progressive, but encoded as interlaced.

Quote:
The choice of DCT and scan pattern are just tools for the encoder to get the best quality for the least bits, and not indicators of the source material type.
Why else would an encoder split every 16x16 macroblock into 16x8 fields by taking alternating lines of pixels, unless the operator of the encoder explicitly specified interlaced encoding mode. This seems to be a pretty solid indicator of a stream that should be reported as interlaced.... For all practical purposes, it needs to be flagged that way (correctly), as you said in your last post. But if all you can do is trust the flags, I'm thinking in circles.
__________________
There's no place like 127.0.0.1

Last edited by mrslacker; 18th May 2005 at 19:50.
mrslacker is offline   Reply With Quote
Old 18th May 2005, 19:54   #389  |  Link
mrslacker
Junior Slacker
 
mrslacker's Avatar
 
Join Date: May 2004
Location: End-World
Posts: 296
Quote:
Originally posted by mpucoder
However, and you will love this, within a progressive frame picture each macroblock can be either progressive or interlaced.
OK, I see. The decision to use frame or field DCT coding is made on a macroblock-by-macroblock basis. Funky! But if they are all frame or field...

Maybe I should stop asking and start reading. Thanks for all the tips, manomo, neuron2, and mpucoder.
__________________
There's no place like 127.0.0.1
mrslacker is offline   Reply With Quote
Old 30th May 2005, 20:50   #390  |  Link
scharfis_brain
brainless
 
scharfis_brain's Avatar
 
Join Date: Mar 2003
Location: Germany
Posts: 3,653
I ran in several problems recently, related to dgpulldowned files.
I am doing a 23.976 fps to 50i pulldown to avoid Audio conversion.

If I want to create a SVCD:
- muxing with TMPGenc results in non-seekable videos
- muxing with bbmpeg results in a seekable mpeg with destroyed pulldown (runs at 20 fps / 25fps with 3:2 pulldown)

If I want to create a DVD:
- muxing with IfoEdit returns a non seekable DVD (with software players)
- muxman rejects the m2v. (says GOP too long)
- authoring with DVDlab was sucessfully

Also I noticed that my 23.976p - 50i pulldowned DVDs don't run smoothly on the PC.
there is a stop every second, like every 24th frame gets duplicated.
But the progressive video itself is true 23.976 fps. so why does it jerk like that?

Using lates DGPulldown and MediaPlayerClassic.
__________________
Don't forget the 'c'!

Don't PM me for technical support, please.
scharfis_brain is offline   Reply With Quote
Old 1st June 2005, 14:10   #391  |  Link
nnigam
Registered User
 
Join Date: Nov 2004
Posts: 92
I do not know about svcd, but for dvd the spec is 29.97fps for NTSC and 25fps for PAL, so 50fps encoding is most likely the problem. The authoring program should have given an error..

For my stuff, I just separate out the audio/video. Change the fps of the video to whatever I need using dgpulldown, and then mux with my authoring program. No problem at all, and audio is in perfect synch. Most of my stuff is 60p fps that coumes out as 23.976 so I just convert this to 29.97 for dvd.
__________________
Neeraj C. Nigam
nnigam@pntravels.com
nnigam is offline   Reply With Quote
Old 1st June 2005, 14:56   #392  |  Link
scharfis_brain
brainless
 
scharfis_brain's Avatar
 
Join Date: Mar 2003
Location: Germany
Posts: 3,653
Quote:
I do not know about svcd, but for dvd the spec is 29.97fps for NTSC and 25fps for PAL, so 50fps encoding is most likely the problem. The authoring program should have given an error..
I am not encoding 50fps.
50i == 25i
__________________
Don't forget the 'c'!

Don't PM me for technical support, please.
scharfis_brain is offline   Reply With Quote
Old 1st June 2005, 16:35   #393  |  Link
Guest
Guest
 
Join Date: Jan 2002
Posts: 21,901
The GOP length issue is known. There are a couple threads about it.

Regarding jerkiness, the pulldown should repeat a field about once per half-second. It shouldn't be noticeable. Can you make available an encoded clip that shows this, so I can check that the pulldown is applied correctly?
Guest is offline   Reply With Quote
Old 1st June 2005, 17:09   #394  |  Link
scharfis_brain
brainless
 
scharfis_brain's Avatar
 
Join Date: Mar 2003
Location: Germany
Posts: 3,653
Quote:
Regarding jerkiness, the pulldown should repeat a field about once per half-second. It shouldn't be noticeable.
Judging from my encoded DVD, the pulldown is applied correctly
(two minor stops per second, only visible in panning scenes)

Only the progressive playback with the PC shows on big stop per second, where it should be two minor ones per second, or even better: NONE!

Quote:
Can you make available an encoded clip that shows this, so I can check that the pulldown is applied correctly?
Which format do you like to see?
m2v or VOB?
__________________
Don't forget the 'c'!

Don't PM me for technical support, please.
scharfis_brain is offline   Reply With Quote
Old 1st June 2005, 18:31   #395  |  Link
Guest
Guest
 
Join Date: Jan 2002
Posts: 21,901
Quote:
Originally Posted by scharfis_brain
Judging from my encoded DVD, the pulldown is applied correctly
(two minor stops per second, only visible in panning scenes)

Only the progressive playback with the PC shows on big stop per second, where it should be two minor ones per second, or even better: NONE!



Which format do you like to see?
m2v or VOB?
Your choice.
Guest is offline   Reply With Quote
Old 6th June 2005, 23:23   #396  |  Link
TimIacobucci
Registered User
 
Join Date: Apr 2005
Posts: 6
pulldown problem

I have encoded a divx avi via avisynth with cce. This avi was 25 fps. I then used dgpulldown to flag it to 29.97 for authoring in dvd maestro. I have done this maybe 30 times before successfully without any problems.

But with this project when I bring the flagged video into maestro the time length of the video is stretched approximately proportional to the change in frame rate from 1 hour 54 minutes to 2 hours 17 minutes. The length is also incorrect in media player classic as well but shows up fine in vdubmod. I have rencoded and redone the pulldown twice to be sure it wasn't some strange glitch.

I can’t make much sense of why this isn't working and any suggestions would be appreciated.

Also many thanks for the great program, until this it has always worked flawlessly.
TimIacobucci is offline   Reply With Quote
Old 7th June 2005, 03:05   #397  |  Link
Guest
Guest
 
Join Date: Jan 2002
Posts: 21,901
Can you make a shorter version that shows the problem and then upload it to my server?
Guest is offline   Reply With Quote
Old 19th June 2005, 14:19   #398  |  Link
Guest
Guest
 
Join Date: Jan 2002
Posts: 21,901
I see a few files on my FTP, but I forgot to tell you to inform me here of the filename if you upload a stream. So, if you have uploaded a stream, please tell me the file name. Thank you.
Guest is offline   Reply With Quote
Old 20th June 2005, 20:48   #399  |  Link
Rosco42
Registered User
 
Join Date: Jun 2005
Posts: 1
I've got a very weird problem with DGPulldown... well, not with DGPulldown itself I think but it's in the loop..

did a bunch of re-encodes using the method (720x480, 25fps, progressive) and then ran DGPulldown on them, all nicely appearing to be 29.97 to the outside world (TMPGenc Author, Womble Video Wizard (not editing, checking the frame rate), etc.. etc..)

Then I was trying out a new authoring program (DVD Composer www.codejam.com) and it only sees the video as 23.97 FPS, naturally the audio track drifts way out of sync..)

Here's the problem.... I fed it some OTHER "real" 3:2 pulldown streams (the 'normal way' of 23.97 > 29.97) and it sees that as 29.97 just fine... only chokes on the 25 > 29.97 stream....

any thoughts on how to 'enlighten' the the program that it's misreading the stream? I've been in contact with the author and they are looking at it (and pointed them to the dgpulldown link on www.videohelp.com) but nothing like checking in at the source...
Rosco42 is offline   Reply With Quote
Old 29th June 2005, 15:46   #400  |  Link
flumpdumpy
Registered User
 
Join Date: Feb 2004
Posts: 6
A question about HD content.

I've been toying around with backing up some HD content that I have captured. and I noticed something interesting about 720p streams. Most of this is common knowledge so please forgive me for going over rudimentary stuff here, I'll get the point as quickly as possible.
The majority of HD programming other than sports, is filmed on movie-type cameras that record at 24fps. When a show is then broadcast in 1080i it uses the same pulldown method that DVD's use to change to 29.97fps. When a show is broadcast in 720p, it uses a similar method to get to 59.94fps. The difference though, is that with a progressive input and progressive output, whole frames are repeated, not fields.
Getting 720p show back down to it's original 23.976fps is no problem. But since I am going to have to re-encode anyway, I'd like to make the video stream as compliant as possible so I won't have to re-encode again when recordable HD-DVD's or Blu-Ray come out.
I originally thought, "Hey, no problem, I'll use the custom setting in DGpulldown and set it to 23.976->59.94". But then I got to thinking, is this really going to give me what I need. So here is the question:
If I use the custom setting to go from 23.976 to 59.94, will it achieve this by repeating whole-frames or fields. Because if it uses fields, that will likely thrash the video output.
flumpdumpy is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 13:03.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.