search

FFMS / ffms2

An FFmpeg based source library and Avisynth/VapourSynth plugin for easy frame accurate access
Other
574 stars 104 forks source link

Bad field order when using rffmode=1 #429

Closed flossy83 closed 3 months ago

flossy83 commented 7 months ago

When using rffmode=1, which is necessary for many MPEG2 videos from NTSC DVD's, the field order of the output frames is not correct.

For test clips and more information please see this doom9 forum post - https://forum.doom9.org/showthread.php?p=1994388#post1994388

Thanks

myrsloik commented 3 months ago

Good bug report. It's unfortunately unfixable without doing full decoding while indexing (which we don't and probably never will) and has been broken forever. It's now removed.

flossy83 commented 3 months ago

StvG's fork fixed it here... https://forum.doom9.org/showthread.php?p=1994765#post1994765

flossy83 commented 3 months ago

Sorry just realised you're probably aware of that and what you were actually trying to say (that you don't want to do "full decoding while indexing")

flossy83 commented 3 months ago

Looking back at StvG's release notes and my demo of the issue here where you can see the field order fluctuating in FFMS2 and staying fixed in LWLibav, I will make 2 random guesses at what StvG might have done to fix rffmode=1:

  1. Just clamp the field order inside ffmpeg. However clamping the field order inside Avisynth after the fact does NOT work, so I'm dubious of this being the solution. So if it was the solution, a clamping should be inserted at the point where ffmpeg is making the decision about which fields to combine into the progressive frame.

  2. Use EncodedFrameTop and EncodedFrameBottom to set the field order of each frame as explained here.

myrsloik commented 3 months ago

Looking back at StvG's release notes and my demo of the issue here where you can see the field order fluctuating in FFMS2 and staying fixed in LWLibav, I will make 2 random guesses at what StvG might have done to fix rffmode=1:

  1. Just clamp the field order inside ffmpeg. However clamping the field order inside Avisynth after the fact does NOT work, so I'm dubious of this being the solution. So if it was the solution, a clamping should be inserted at the point where ffmpeg is making the decision about which fields to combine into the progressive frame.
  2. Use EncodedFrameTop and EncodedFrameBottom to set the field order of each frame as explained here.

I did look at StvG's patches but in the end I'm convinced they're not completely correct. Maybe due to some frame offset/other detail of his modification it appears to work but here's the big catch:

If you get the field_order using FFmpeg's AVCodecContextParser and store (StvG modification and also fastest way) you realize that it doesn't quite match the repeat_pict and field_order value set in the corresponding fully decoded AVFrames. I believe the AVFrames are correct and the discrepancy is the reason things look bad.

Also keep in mind that RFF is more or less only used in the containers where FFMS2 is known to be broken. I always use DGMPGDec and so should the whole world.

Asd-g commented 3 months ago

This release shows that the used ffmpeg is with the lsmashsource patches. For MPEG2 here how tff flags are set.