Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bad field order when using rffmode=1 #429

Closed
flossy83 opened this issue Nov 29, 2023 · 6 comments
Closed

Bad field order when using rffmode=1 #429

flossy83 opened this issue Nov 29, 2023 · 6 comments

Comments

@flossy83
Copy link

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
Copy link
Contributor

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
Copy link
Author

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

@flossy83
Copy link
Author

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
Copy link
Author

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
Copy link
Contributor

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
Copy link
Contributor

Asd-g commented Mar 15, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants