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. |
17th May 2005, 21:13 | #381 | Link | ||
Junior Slacker
Join Date: May 2004
Location: End-World
Posts: 296
|
Quote:
Quote:
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 |
||
18th May 2005, 08:28 | #382 | Link |
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 |
18th May 2005, 13:09 | #383 | Link | |
Guest
Join Date: Jan 2002
Posts: 21,901
|
Quote:
|
|
18th May 2005, 16:36 | #384 | Link |
Junior Slacker
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 |
18th May 2005, 16:45 | #385 | Link |
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. |
18th May 2005, 17:22 | #386 | Link |
Junior Slacker
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. |
18th May 2005, 19:13 | #387 | Link |
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. |
18th May 2005, 19:45 | #388 | Link | |||
Junior Slacker
Join Date: May 2004
Location: End-World
Posts: 296
|
Quote:
Quote:
Quote:
__________________
There's no place like 127.0.0.1 Last edited by mrslacker; 18th May 2005 at 19:50. |
|||
18th May 2005, 19:54 | #389 | Link | |
Junior Slacker
Join Date: May 2004
Location: End-World
Posts: 296
|
Quote:
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 |
|
30th May 2005, 20:50 | #390 | Link |
brainless
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. |
1st June 2005, 14:10 | #391 | Link |
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. |
1st June 2005, 14:56 | #392 | Link | |
brainless
Join Date: Mar 2003
Location: Germany
Posts: 3,653
|
Quote:
50i == 25i
__________________
Don't forget the 'c'! Don't PM me for technical support, please. |
|
1st June 2005, 16:35 | #393 | Link |
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? |
1st June 2005, 17:09 | #394 | Link | ||
brainless
Join Date: Mar 2003
Location: Germany
Posts: 3,653
|
Quote:
(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:
m2v or VOB?
__________________
Don't forget the 'c'! Don't PM me for technical support, please. |
||
1st June 2005, 18:31 | #395 | Link | |
Guest
Join Date: Jan 2002
Posts: 21,901
|
Quote:
|
|
6th June 2005, 23:23 | #396 | Link |
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. |
20th June 2005, 20:48 | #399 | Link |
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... |
29th June 2005, 15:46 | #400 | Link |
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. |
Thread Tools | Search this Thread |
Display Modes | |
|
|