This repository has been archived by the owner. It is now read-only.

Wrong FPS or Duration for interlaced source #1916

Closed
kingcrimsonster opened this Issue Mar 22, 2017 · 12 comments

Comments

3 participants
@kingcrimsonster

kingcrimsonster commented Mar 22, 2017

excuse me for my english
There is an original file

original.mkv
Duration : 8 s 560 ms
Frame rate mode : Constant
Frame rate : 25.000 FPS

When I trying remux it with mkvtoolnix 9.9.0 and set FPS to 50i

"C:/Program Files/mkvtoolnix\mkvmerge.exe" --ui-language en --output ^"D:\Encode\2017.02.24\ESC 2015 - Final  - 27 songs ^(FEED 1080i^)\old\bunkus\after mkvtoolnix set 50i.mkv^" --language 0:eng --track-name 0:VIDEO --default-track 0:yes --compression 0:none --default-duration 0:50i --language 1:eng --track-name ^"1:DTS 5.1^" --compression 1:none ^"^(^" ^"D:\Encode\2017.02.24\ESC 2015 - Final  - 27 songs ^(FEED 1080i^)\old\bunkus\original.mkv^" ^"^)^" --track-order 0:0,0:1 --probe-range-percentage 1.10

Duration : 15 s 880 ms
Frame rate mode : Constant
Frame rate : 25.000 FPS

duration in now wrong

If I leave FPS field is a blank

"C:/Program Files/mkvtoolnix\mkvmerge.exe" --ui-language en --output ^"D:\Encode\2017.02.24\ESC 2015 - Final  - 27 songs ^(FEED 1080i^)\old\bunkus\after mkvtoolnix set 50i.mkv^" --language 0:eng --track-name 0:VIDEO --default-track 0:yes --compression 0:none --language 1:eng --track-name ^"1:DTS 5.1^" --compression 1:none ^"^(^" ^"D:\Encode\2017.02.24\ESC 2015 - Final  - 27 songs ^(FEED 1080i^)\old\bunkus\original.mkv^" ^"^)^" --track-order 0:0,0:1 --probe-range-percentage 1.10

Duration : 8 s 20 ms
Frame rate mode : Variable
Frame rate : 49.501 FPS
Original frame rate : 25.000 FPS

This is not the only file with this defect. As a rule, these are files downloaded from satellites in a container *.ts

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
/upload/kingcrimsonster

@mbunkus

This comment has been minimized.

Show comment
Hide comment
@mbunkus

mbunkus Mar 22, 2017

Owner

Thanks. I'll look into it, but it will likely take quite some time.

Owner

mbunkus commented Mar 22, 2017

Thanks. I'll look into it, but it will likely take quite some time.

@mkver

This comment has been minimized.

Show comment
Hide comment
@mkver

mkver Mar 22, 2017

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).
[Edit]: My gut feeling was just this: gut feeling. After doing some tests and looking a bit on the code of AVC output module it seems that mkvmerge already handles the PAFF/MBAFF distinction fine. (At least in ordinary streams. Maybe this stream here is an example where the scan type changes mid-stream.)

mkver commented Mar 22, 2017

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).
[Edit]: My gut feeling was just this: gut feeling. After doing some tests and looking a bit on the code of AVC output module it seems that mkvmerge already handles the PAFF/MBAFF distinction fine. (At least in ordinary streams. Maybe this stream here is an example where the scan type changes mid-stream.)

@mbunkus

This comment has been minimized.

Show comment
Hide comment
@mbunkus

mbunkus Mar 30, 2017

Owner

The case of not setting the default duration is working as intended as far as I can see. This is just how things work.

I haven't looked into the case of forcing the default duration yet.

Owner

mbunkus commented Mar 30, 2017

The case of not setting the default duration is working as intended as far as I can see. This is just how things work.

I haven't looked into the case of forcing the default duration yet.

@mbunkus

This comment has been minimized.

Show comment
Hide comment
@mbunkus

mbunkus Mar 31, 2017

Owner

New pre-builds for Windows that include the fix are up.

Owner

mbunkus commented Mar 31, 2017

New pre-builds for Windows that include the fix are up.

@kingcrimsonster

This comment has been minimized.

Show comment
Hide comment
@kingcrimsonster

kingcrimsonster Apr 1, 2017

10.0.0-build20170331-01451-43f6c799d

This is same file

When I trying remux it with set FPS to 50i

Duration : 7 s 940 ms
Frame rate mode : Variable
Frame rate : 50.000 FPS
Original frame rate : 25.000 FPS

"C:/Program Files/mkvtoolnix\mkvmerge.exe" --ui-language en --output ^"G:\My Programms\MPEG Programs\MKVToolnix\bunkus\kingcrimsonster\original.mkv^" --language 0:eng --track-name 0:VIDEO --default-track 0:yes --display-dimensions 0:1920x1080 --compression 0:none --default-duration 0:50i --language 1:eng --track-name ^"1:DTS 5.1^" --compression 1:none ^"^(^" ^"G:\My Programms\MPEG Programs\MKVToolnix\bunkus\kingcrimsonster\original.mkv^" ^"^)^" --track-order 0:0,0:1 --probe-range-percentage 1.10

If I leave FPS field is a blank

Duration : 8 s 20 ms
Frame rate mode : Variable
Frame rate : 49.501 FPS
Original frame rate : 25.000 FPS

"C:/Program Files/mkvtoolnix\mkvmerge.exe" --ui-language en --output ^"G:\My Programms\MPEG Programs\MKVToolnix\bunkus\kingcrimsonster\original.mkv^" --language 0:eng --track-name 0:VIDEO --default-track 0:yes --display-dimensions 0:1920x1080 --compression 0:none --language 1:eng --track-name ^"1:DTS 5.1^" --compression 1:none ^"^(^" ^"G:\My Programms\MPEG Programs\MKVToolnix\bunkus\kingcrimsonster\original.mkv^" ^"^)^" --track-order 0:0,0:1 --probe-range-percentage 1.10

kingcrimsonster commented Apr 1, 2017

10.0.0-build20170331-01451-43f6c799d

This is same file

When I trying remux it with set FPS to 50i

Duration : 7 s 940 ms
Frame rate mode : Variable
Frame rate : 50.000 FPS
Original frame rate : 25.000 FPS

"C:/Program Files/mkvtoolnix\mkvmerge.exe" --ui-language en --output ^"G:\My Programms\MPEG Programs\MKVToolnix\bunkus\kingcrimsonster\original.mkv^" --language 0:eng --track-name 0:VIDEO --default-track 0:yes --display-dimensions 0:1920x1080 --compression 0:none --default-duration 0:50i --language 1:eng --track-name ^"1:DTS 5.1^" --compression 1:none ^"^(^" ^"G:\My Programms\MPEG Programs\MKVToolnix\bunkus\kingcrimsonster\original.mkv^" ^"^)^" --track-order 0:0,0:1 --probe-range-percentage 1.10

If I leave FPS field is a blank

Duration : 8 s 20 ms
Frame rate mode : Variable
Frame rate : 49.501 FPS
Original frame rate : 25.000 FPS

"C:/Program Files/mkvtoolnix\mkvmerge.exe" --ui-language en --output ^"G:\My Programms\MPEG Programs\MKVToolnix\bunkus\kingcrimsonster\original.mkv^" --language 0:eng --track-name 0:VIDEO --default-track 0:yes --display-dimensions 0:1920x1080 --compression 0:none --language 1:eng --track-name ^"1:DTS 5.1^" --compression 1:none ^"^(^" ^"G:\My Programms\MPEG Programs\MKVToolnix\bunkus\kingcrimsonster\original.mkv^" ^"^)^" --track-order 0:0,0:1 --probe-range-percentage 1.10

@mbunkus

This comment has been minimized.

Show comment
Hide comment
@mbunkus

mbunkus Apr 1, 2017

Owner

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 --sync option (in the GUI: Delay (in ms)).

The frame rate: that's MediaInfo taking a guess and getting it wrong.

As I said, working as intended.

Owner

mbunkus commented Apr 1, 2017

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 --sync option (in the GUI: Delay (in ms)).

The frame rate: that's MediaInfo taking a guess and getting it wrong.

As I said, working as intended.

@mbunkus

This comment has been minimized.

Show comment
Hide comment
@mbunkus

mbunkus Apr 1, 2017

Owner

Or to put it another way: unless you're having a playback problem with a file or you really know what you're doing, don't bother overwriting the default duration. mkvmerge will usually do The Right Thing by default.

Owner

mbunkus commented Apr 1, 2017

Or to put it another way: unless you're having a playback problem with a file or you really know what you're doing, don't bother overwriting the default duration. mkvmerge will usually do The Right Thing by default.

@kingcrimsonster

This comment has been minimized.

Show comment
Hide comment
@kingcrimsonster

kingcrimsonster Apr 1, 2017

This is another file
/upload/kingcrimsonster
Ellie Goulding - Figure 8.ts
Duration : 3 min 57 s
Frame rate : 25.000 FPS

I leave FPS field is a blank
Duration : 3 min 57 s
Frame rate mode : Variable
Frame rate : 50.000 FPS
Original frame rate : 25.000 FPS

"C:/Program Files/mkvtoolnix\mkvmerge.exe" --ui-language en --output ^"L:\bunkus\new2\Ellie Goulding - Figure 8.mkv^" --language 0:eng --compression 0:none --language 1:eng --compression 1:none ^"^(^" ^"L:\bunkus\new2\Ellie Goulding - Figure 8.ts^" ^"^)^" --track-order 0:0,0:1 --probe-range-percentage 1.10

Remux with VideoRedo application
Duration : 3 min 57 s
Frame rate mode : Constant
Frame rate : 25.000 FPS

The frame rate: that's MediaInfo taking a guess and getting it wrong.

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.
Original and Remuxed with VideoRedo files - not this problem.

kingcrimsonster commented Apr 1, 2017

This is another file
/upload/kingcrimsonster
Ellie Goulding - Figure 8.ts
Duration : 3 min 57 s
Frame rate : 25.000 FPS

I leave FPS field is a blank
Duration : 3 min 57 s
Frame rate mode : Variable
Frame rate : 50.000 FPS
Original frame rate : 25.000 FPS

"C:/Program Files/mkvtoolnix\mkvmerge.exe" --ui-language en --output ^"L:\bunkus\new2\Ellie Goulding - Figure 8.mkv^" --language 0:eng --compression 0:none --language 1:eng --compression 1:none ^"^(^" ^"L:\bunkus\new2\Ellie Goulding - Figure 8.ts^" ^"^)^" --track-order 0:0,0:1 --probe-range-percentage 1.10

Remux with VideoRedo application
Duration : 3 min 57 s
Frame rate mode : Constant
Frame rate : 25.000 FPS

The frame rate: that's MediaInfo taking a guess and getting it wrong.

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.
Original and Remuxed with VideoRedo files - not this problem.

@mbunkus

This comment has been minimized.

Show comment
Hide comment
@mbunkus

mbunkus Apr 1, 2017

Owner

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 --fix-bitstream-timing-information trackID:1 (replace trackID by the track's ID). If that doesn't help, then I cannot help you.

Owner

mbunkus commented Apr 1, 2017

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 --fix-bitstream-timing-information trackID:1 (replace trackID by the track's ID). If that doesn't help, then I cannot help you.

@mbunkus

This comment has been minimized.

Show comment
Hide comment
@mbunkus

mbunkus Apr 1, 2017

Owner

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.

Owner

mbunkus commented Apr 1, 2017

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.

@kingcrimsonster

This comment has been minimized.

Show comment
Hide comment
@kingcrimsonster

kingcrimsonster Apr 1, 2017

You can try adding the option --fix-bitstream-timing-information trackID:1 (replace trackID by the track's ID)

That doesn't help

that's MediaInfo taking a guess and getting it wrong.

Sounds like your hardware player does the wrong thing, then

I'm not an expert in this, but even it seems to me that there is a bug mkvtoolnix.

You can try adding the option --fix-bitstream-timing-information trackID:1 (replace trackID by the track's ID)

That doesn't help

that's MediaInfo taking a guess and getting it wrong.

Sounds like your hardware player does the wrong thing, then

I'm not an expert in this, but even it seems to me that there is a bug mkvtoolnix.

@mbunkus

This comment has been minimized.

Show comment
Hide comment
@mbunkus

mbunkus Apr 1, 2017

Owner

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.

Owner

mbunkus commented Apr 1, 2017

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.