Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Wrong FPS or Duration for interlaced source #1916
excuse me for my english
When I trying remux it with mkvtoolnix 9.9.0 and set FPS to 50i
duration in now wrong
If I leave FPS field is a blank
This is not the only file with this defect. As a rule, these are files downloaded from satellites in a container
As an example, if this file is remuxed using the "LosslessCut" program, the defect does not occurs.
This file is in 4.2.2 format, but there are many other files in 4.2.0 format that are muxed and remuxed with the "VideoRedo" program without this problem. If I again remuxing these files with mkvtoolnix - again the same problem occurs
Files uploaded FTP
My gut feeling is that your file uses the MBAFF encoding mode. H.264 knows several encoding modes: Progressive, traditional interlaced (a whole frame is either encoded as a whole frame or as two fields) or MBAFF (the decision to encode interlaced or not is done at the macroblock level (a macroblock here is a block of 16x32 pixels that the frame is divided into); this can be useful for encoding static backgrounds of an otherwise interlaced file). In progressive mode, one frame is stored in one matroska block (hence default duration should be the inverse of the framerate (if it's cfr)); in interlaced mode one field is stored in one matroska block so that the default duration should be set to the inverse of the field rate (in case of cfr). In MBAFF mode, one matroska block contains two fields/one frame so that the default duration should be double the inverse of the field rate (in case of cfr).
Mar 31, 2017
This is same file
When I trying remux it with set FPS to 50i
Duration : 7 s 940 ms
If I leave FPS field is a blank
Duration : 8 s 20 ms
The duration: Yes, that's working as expected. In your original file video actually starts at 600ms, not at 0ms. As soon as you override the default duration, all timestamps provided by the source container are thrown out of the window, and new ones are calculated. You'll have to adjust them with the
The frame rate: that's MediaInfo taking a guess and getting it wrong.
As I said, working as intended.
This is another file
I leave FPS field is a blank
Remux with VideoRedo application
Not only MediaInfo. My Hardware mediaplayer Dune HD Smart D1 also indicates 50.000 FPS and has problem with fast seek - 2x, 4x working normally, if I try enable 8x - 16x - clip freezes on the frame.
Sounds like your hardware player does the wrong thing, then. That's not mkvmerge's problem but a bug in your hardware player.
You can try adding the option
I've just looked into the VideoReDo file. What it does it not compliant with the Matroska specifications.
The video track is interlaced at (50i), but VideoReDo packs both fields of each frame into a single Matroska block. Of course with that method the duration of each frame will be 40ms (each field's duration with 50i is 20ms), and the track's default duration reflects those 40ms, which in turn MediaInfo interprets as 25 FPS — even though Matroska doesn't have an FPS header field.
The Matroska specs state that each Matroska block must only contain one field for interlaced content, one frame for progressive content.
Both mkvmerge and ffmpeg follow the specs and only put one field into each Matroska block. Therefore both tools arrive at a block duration of 20ms, track default duration 20ms, as is appropriate for 50i content.
That doesn't help
I'm not an expert in this, but even it seems to me that there is a bug mkvtoolnix.
And I've already laid out my expert opinion on why what VideoReDo does is spec-violating and what mkvmerge does is spec-compliant. If your hardware player doesn't work with spec-compliant files but with ones that violate the specs, then that's an issue in your hardware player.
This is the end of this discussion for me.