Bugs with setting FPS and bitstream timing
Created by: mkver
as the title already indicates, I have found several bugs concerning forcing fps/default duration for a track. And I think I have found out why the bitstream timing of several H.264 streams can't be successfully updated (resulting in mediainfo showing the "original frame rate" field and decoders ignoring the update). But first things first. I uploaded a bunch of files to your ftp-server into the directory "H264 Framerate". The original file is 1.mkv (which in itself is derived from a satellite recording). It is 25i television (50 fields per second). I used mkvextract to extract the H.264 track and used h264_parse.exe (which I found via this thread on doom9; for your convenience I uploaded it to your server) to give me information about the h264-stream. I then remuxed 1.mkv via mkvmerge 9.1 to the other mkv-files in the directory. I only used two muxing parameters: I set the FPS-field to the value indicated by the name of the file and I used the option to overwrite the timing information on the H.264 bitstream. Then I extracted the h264-streams and parsed them.
- Mkvtoolnix only updates the "time_scale" and "num_units_per_tick" in the very first sequence parameter set (SPS). But there can be more than one SPS in a h264-stream (it is needed for example for TV streams so that you get this information right away after you switch a channel) and for such streams the timing information in the bitstream is not really overwritten, because the other SPS (there seems to be one right before every idr frame) still contain the information; and apparently the local information precedes the global one (wouldn't make sense otherwise) so that the overwriting the header SPS is useless. (I'm wondering right know if you are aware of this and if this is a design choice that you won't change (which of course concerns whether I should invest time into this bug report; I eventually decided to do it). Your answer here left me puzzled: You seem to be aware of the fact that mkvmerge only changes the values in the header (suggesting that you know that there are other SPS) and then conclude that this behaviour is correct, although it is of no help to satmonk.)
- The way mkvmerge handles interlaced fps input is buggy: According to the documentation which speaks of 'interlaced frames per second' 10i should be regarded as 20 fields per second; but instead mkvmerge creates files with a default duration of 200ms, i.e. 5 fields per second for interlaced content. And the header SPS is overwritten with values corresponding to (roughly, see below) 10 fields per second so that 10i.mkv contains three different framerates. This behaviour does not affect the hard-coded standard framerates (at least not the one I checked).
- And for some reason the header SPS aren't overwritten with integral numbers when possible but with unnecessary approximations: The time scale is always (except for some hardcoded framerates; and I have not checked what happens when you enter proper fractions) 2147483648=2^31 and num_units_in_tick is selected to fit to this choice (for 10 fields per second it's 214748364). But if the input is a floating point number with not too many digits then one can always use an exact representation by choosing an appropriate power of 10 as time_scale.
Thanks again for creating mkvtoolnix Andi
PS: There seem to be other SPS fields (like time_offset_length) that might be affected by overwriting the timing information in the bitstream. This might be important if you decide to fix 1.