What to do with 25fps Progressive Blu-Ray Encodes?

[agressiv]

I have various blu-rays from the UK which are encoded at 25fps progressive, but because of the lack of a progressive blu-ray 25fps standard, are "flagged" as MBAFF interlaced.

However, when I use the idet filter with ffmpeg, many of these files have anywhere from 10-70 interlaced frames (TFF) out of a random 1000 sample set, and when I seek in MPC-HC, I could swear that I'm seeing interlaced jaggies, but they are obviously less pronounced then on a PAL DVD due to resolution.

So, how would you guys handle these? Would you:


Just encode them straight progressive with no filters and ignore the interlaced frames?
Would you use QTGMC with InputType=1 regardless of how many interlaced frames ffmpeg found?
Use QTGMC with double-rate?
Use QTGMC with single-rate?
Do something else?

Examples are seasons 5-9 of Doctor Who (UK Version), Life, Frozen Planet - all BBC shows.

[Gser]

http://avisynth.nl/index.php/TIVTC/TFM
Just use TFM, it will join the progressive fields and deinterlace the combed frames, you can even use QTGMC as a deinterlacer like so
deint=QTGMC( Preset="medium", FPSdivisor=2, lossless=2)
tfm(pp=4, slow=2, hint=false, clip2=deint)
Pay attention the pp setting. When using PP > 1 this parameter may be used to specify a clip to take deinterlaced frames from instead of using one of TFM's inbuilt deinterlacing methods. If PP < 5 then frames will be taken as is from clip2, if PP >= 5 (i.e. using motion adaptation) then TFM will build the mask as usual and only pixels in moving areas will be taken from the frames in clip2.
I use that script for a source that I know has mixed progressive and interlaced material but if I know a source is fully progressive but has a few combed frames here and there because of reasons, then I would set pp > 5. PS: Hint is set false because there is no need to produce hints for a decimation filter.

[kolak]

.

However, when I use the idet filter with ffmpeg, many of these files have anywhere from 10-70 interlaced frames (TFF) out of a random 1000 sample set, and when I seek in MPC-HC, I could swear that I'm seeing interlaced jaggies, but they are obviously less pronounced then on a PAL DVD due to resolution.



Have you actually looked at them and confined that they are really interlaced? It should be all progressive, maybe except credits which are quite often added as interlaced. 100 frames out of random 1000 being interlaced sounds very odd.

Check it in something frame accurate at 1:1 pixel, e.g. VDub with ffmpeg input plugin.

[agressiv]

I looked at a particular section. I don't know the technical names for it, but there was a scene where where a hand starts fading into view around frame 50 of the below clip. That's progressive. The pedestal that starts fading into view is interlaced as you can see it visually change every frame even with the fields separated.

I've saved a clip where I used AssumeTFF() and SeparateFields() and saved the resultant frames as an AVI. And of course, the end credits are interlaced as well. Please let me know if I'm wrong with the above conclusion.

https://mega.nz/#!aco3mIQa!Xpd_QqUS0mqC1f1ehgjW8euC8mDfFNPLlj0D7SS6ikg

[LemMotlow]

You say you're working with BluRay, but your sample clip has been re-encoded as mp4. I'm afraid that's making things a little too complicated.

[kolak]

For me it looks like a famous problem when interpreting progressive footage as interlaced when working on it in progressive project.
When you export this you end up with jagged lines (lost vertical resolution). It's quite common on BBC (and not only) masters, seen it many times when working on their content. They were strangely "happy with it".
When it happens in some places maybe these were re-editied etc.

The biggest problem is that there is no good way of fixing this issue. One of the best solutions which I found is to scale these places vertically 2x down and then upscale with NNEDI3 etc.

I would simply ignore it and treat whole thing as progressive. These are simply badly mastered discs with no easy fix.

[agressiv]

I could upload the 700mb AVI from virtualdub, but that mp4 is lossless -- figured it would be good enough. Instead, I've used ffmpeg to output the raw streamcopy to an MKV here. This has no modifications other than trim().

https://mega.nz/#!6ZZw3J7T!3L5HNM5fMgs0MeGFfnLF1gwaKslt_XLfX_xN77qajL0

[poisondeathray]

I could upload the 700mb AVI from virtualdub, but that mp4 is lossless -- figured it would be good enough. Instead, I've used ffmpeg to output the raw streamcopy to an MKV here. This has no modifications other than trim().

https://mega.nz/#!6ZZw3J7T!3L5HNM5fMgs0MeGFfnLF1gwaKslt_XLfX_xN77qajL0


It probably doesn't matter here, but in the future keep in mind this is not a "raw streamcopy", or at least not one that is unprocessed.

Using trim() means you are using avisynth, which means you are subject to whatever decoding pathway you have set up (it's been decoded, and possibly processed). You should cut from the original with something like tsmuxer . Not only will filesize be several times smaller (when you decode it using an avisynth source filter, it becomes uncompressed) , that will ensure no quality loss, or decoding issues , or unforseen processing variables (some source filters might be set to deinterlace or add post processing, especially directshow based) - and you never mentioned how you are loading it in avisynth.

If you cut it with ffmpeg using streamcopy instead of avisynth, then yes that would be acceptable, because it would not have been decoded




But assuming this was representative without any other processing issues, it looks progressive. It's a crossfade - that's what it's supposed to look like. The up/down motion when you separate fields is from the even/odd field offset. That is normal for progressive. There is no clear indication of different moments in time represented each field. Pay attention to the zoom movement in - if it was interlaced content, then you would see zoom increasing every field during that crossfade. You do not here, thus it's progressive

However, some of the other content on the disc - behinds the scenes, etc.. those are interlaced for sure.

[agressiv]

I guess I'm still trying to figure out where these interlaced frames are then, because looking at 100 frames is fairly trivial and nothing else comes close. Could this have "fooled" the idet filter in ffmpeg to thinking it was interlaced?

[poisondeathray]

I guess I'm still trying to figure out where these interlaced frames are then, because looking at 100 frames is fairly trivial and nothing else comes close. Could this have "fooled" the idet filter in ffmpeg to thinking it was interlaced?

If you use -vf idet on the same disc, same title (not the extra), then likely false positives. You probably have to adjust intl_thres and prog_thres if you still wanted to use it. Avisynth detection filters can be fooled too and might need their thresholds and settings adjusted

If it was truly an "interlaced frame" - by that I mean 2 sequential fields representing 2 different moments in time - then you would see horizontal combing artifacts when there was motion.

There can be other explanations for what you think you "saw" in the 1st post. The media player could be processing it improperly. For example , a blind deinterlace applied will cause aliasing or jaggies on progressive content.

With the exception of the old series first couple seasons, Doctor Who should all be progressive (except some extras, behind the scenes, which are interlaced). There might be some sections improperly processed, but I doubt it.

[kolak]

I guess I'm still trying to figure out where these interlaced frames are then, because looking at 100 frames is fairly trivial and nothing else comes close. Could this have "fooled" the idet filter in ffmpeg to thinking it was interlaced?

It's very easy to say if frames are interlaced or not.
You have to make sure no processing is involved and look at 1:1 pixels. You can use mentioned Vdub.
I'm not sure what you are seeing as for me your example is no near to be real interlaced content.
Don't try to judge anything when you putting video through some avisynth script with a lot of processing.
Don't rely on any automated interlacing detection- it's never 100% accurate. You have to adjust parameters and learn how to interpret results.

[LemMotlow]

25fps progressive isn't valid for BluRay. Whether it's progressive content mixed with interlaced or not, the entire video would have to be encoded as interlaced if it's going to be official "BluRay" and encoded as MPEG or as h.264/AVC. A BluRay program stream file can be edited (cut on full GOP's) without re-encoding and without container changes by any number of free programs from TSMuxer on, or by trial versions of VideoReDo or TMPGEnc Smart Renderer. Even a full MediaInfo report would be better than all the mashuguna sample processing you're going thru. I keep wondering why this is getting so complicated. And since when is "BluRay" encoded at 1920x540 @ 50fps, as your sample was? I guess I missed something, so maybe I should pass.

[wonkey_monkey]

It's not unheard of for the odd bit of interlaced footage to sneak through into a modern episode of Doctor Who - post-production shake effects or screen inserts, for example - but it's very rare and there's none evident in your sample.