Log in

View Full Version : Importing Progressive DVD with BD-RB


Sharc
14th September 2012, 18:36
@jdobbs
Thank you for the new Import feature which is very convenient.
The vast majority of (PAL-)DVDs are progressive content. BD-RB encodes these interlaced (--tff) rather than --fake-interlace which I understand would be more efficient for x264 (perhaps this is no longer valid?).
Is the reason for using --tff because it is not possible to detect progressive content reliably?
I am also asking because interlaced encoding (--tff, MBAFF) excludes --weightp

jdobbs
15th September 2012, 14:31
@jdobbs
Thank you for the new Import feature which is very convenient.
The vast majority of (PAL-)DVDs are progressive content. BD-RB encodes these interlaced (--tff) rather than --fake-interlace which I understand would be more efficient for x264 (perhaps this is no longer valid?).
Is the reason for using --tff because it is not possible to detect progressive content reliably?
I am also asking because interlaced encoding (--tff, MBAFF) excludes --weightp You really can't do it with fake-interlaced because of the difference in framerates (25fps v.s. 23.976fps). There is no legal 25fps progressive output in blu-ray (except for secondary video). You'd also have to change the audio (by speeding it up) to make up for the difference or you'll end of with 1 second of audio desync for every 25 seconds of video. It can be done -- but you have to accept audio that is slightly less-than-perfect.

Sharc
15th September 2012, 15:15
You really can't do it with fake-interlaced because of the difference in framerates (25fps v.s. 23.976fps). There is no legal 25fps progressive output in blu-ray (except for secondary video). You'd also have to change the audio (by speeding it up) to make up for the difference or you'll end of with 1 second of audio desync for every 25 seconds of video. It can be done -- but you have to accept audio that is slightly less-than-perfect.
Hmmm..., PAL DVDs are native 25 fps, so there are actually no issues with audio sync. Agree, 720x576@25 fps as well as 720x480@29.97fps must be interlaced for blu-ray compliance. Now this is exactly why --fake interlace has been introduced in x264: It marks a stream as "interlaced" even when not encoding as interlaced (therefore "fake").
No big issue though as --ttf (interlaced) is always most compliant. It just prohibits --weightp in x264 which would improve compression and quality in fades according to the wiki.

So far I had no issues with PAL DVD import, I tried both 4:3 and 16:9 DAR. It uses the correct --sar for x264 and playback DAR on TV is correct.

jdobbs
15th September 2012, 15:30
Hmmm..., PAL DVDs are native 25 fps, so there are actually no issues with audio sync. Agree, 720x576@25 fps as well as 720x480@29.97fps must be interlaced for blu-ray compliance. Now this is exactly why --fake interlace has been introduced in x264: It marks a stream as "interlaced" even when not encoding as interlaced (therefore "fake").
No big issue though as --ttf (interlaced) is always most compliant. It just prohibits --weightp in x264 which would improve compression and quality in fades according to the wiki.

So far I had no issues with PAL DVD import, I tried both 4:3 and 16:9 DAR. It uses the correct --sar for x264 and playback DAR on TV is correct. Ugghh... I don't know where my head was when I replied. Yes, you can use fake-interlaced. The question is "How can you tell whether the source is really interlaced?"

I think the only time anyone will ever see aspect-ratio issues is when the original is flagged wrong. There were a couple of lower-end packages out there that were used for authoring some DVDs (SpruceUp comes to mind). Those packages didn't support 16:9 -- so the 16:9 video was encoded with flags saying 4:3 (to allow support with that package) -- and then the IFO was modified after-the-fact to correct it during playback (the IFO has precedence over the stream). Unfortunately, when that video is imported via TSMUXER, the aspect ratio is read from the MPEG-2 stream, not the IFO. So the aspect is wrong. The bottom line is that the issue isn't in BD-RB -- it is in the poor authoring of the source. Luckily those discs are rare. One way I know to correct for that would be to look at the IFO, and then look at the first video sequence in the MPEG-2 file to make sure it matches. But then if it doesn't you'd have to scan through the entire 8GB stream correcting it. That's a lot of time & work for a few discs that were incorrectly authored to begin with.

jdobbs
15th September 2012, 23:08
@jdobbs
Thank you for the new Import feature which is very convenient.
The vast majority of (PAL-)DVDs are progressive content. BD-RB encodes these interlaced (--tff) rather than --fake-interlace which I understand would be more efficient for x264 (perhaps this is no longer valid?).
Is the reason for using --tff because it is not possible to detect progressive content reliably?
I am also asking because interlaced encoding (--tff, MBAFF) excludes --weightp

You know, now that I think about it... all you have to do is select "DEINTERLACE" in the SETUP menu. If the original was already progressive, the routine shouldn't have much to do and shouldn't change the picture (since there's no temporal difference between the two fields) -- and "fake-interlace" is always used on sources that have been deinterlaced.

Sharc
16th September 2012, 21:53
You know, now that I think about it... all you have to do is select "DEINTERLACE" in the SETUP menu. If the original was already progressive, the routine shouldn't have much to do and shouldn't change the picture (since there's no temporal difference between the two fields) -- and "fake-interlace" is always used on sources that have been deinterlaced.

Cool. Thanks!

Sharc
17th September 2012, 18:33
You know, now that I think about it... all you have to do is select "DEINTERLACE" in the SETUP menu. If the original was already progressive, the routine shouldn't have much to do and shouldn't change the picture (since there's no temporal difference between the two fields) -- and "fake-interlace" is always used on sources that have been deinterlaced.
Cool....
One more question: When I am sure that the DVD source is progressive (i.e. no temporal difference between fields) then I should probably set DEINTERLACER_TYPE=4 in the hidden options, correct?

Edit:
I just completed an encode with DEINTERLACER_TYPE=4 in the hidden options and selecting 'Use DEINTERLACER on interlaced sources' in the Setup menu: It did exactly what I have been asking for. Thanks again for the hint.