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

mkvmerge does not detect type of certain raw H.264/AVC files #1946

Closed
sneaker2 opened this Issue Apr 16, 2017 · 5 comments

Comments

2 participants
@sneaker2

sneaker2 commented Apr 16, 2017

Hi,

as the title says I have trouble opening some raw H.264/AVC files created by older x264 versions. I have uploaded a small sample to your ftp. This does not happen with newer x264 versions but I cannot see any commit in the x264 gitlog that seems to be relevant.

mkvmerge -o output.mkv mkvmerge_cannot_open_sample.264
mkvmerge v10.0.0 ('To Drown In You') 32bit Error: The type of file 'mkvmerge_cannot_open_sample.264' could not be recognized.

Tested using mkvtoolnix-32bit-10.0.0-build20170416-01478-21eb1ecd5 (pre).

For the record: the error is gone somewhere between x264 2334 and 2345. I'm using the de-facto official builds that changed from x264.nl to videolan, though. Maybe it has something to do with that - there seem to be differences in the framerate detection of x264.

@mbunkus

This comment has been minimized.

Show comment
Hide comment
@mbunkus

mbunkus Apr 17, 2017

Owner

Thanks. I'll look into it.

Owner

mbunkus commented Apr 17, 2017

Thanks. I'll look into it.

@mbunkus

This comment has been minimized.

Show comment
Hide comment
@mbunkus

mbunkus Apr 17, 2017

Owner

The sequence parameter set contains some interesting timing values (confirmed by both mkvmerge and ffmpeg):

  num_units_in_tick: 1
  time_scale:        2000000000

ffmpeg interprets this as 25 FPS. I'd like to know why…

For mkvmerge this leads to a calculated default duration of 0, which in turn leads to a division by zero error later on causing the detection to fail.

I can make mkvmerge recognize such values as meaning 25 FPS, but not without knowing how ffmpeg arrives at that value.

Owner

mbunkus commented Apr 17, 2017

The sequence parameter set contains some interesting timing values (confirmed by both mkvmerge and ffmpeg):

  num_units_in_tick: 1
  time_scale:        2000000000

ffmpeg interprets this as 25 FPS. I'd like to know why…

For mkvmerge this leads to a calculated default duration of 0, which in turn leads to a division by zero error later on causing the detection to fail.

I can make mkvmerge recognize such values as meaning 25 FPS, but not without knowing how ffmpeg arrives at that value.

@sneaker2

This comment has been minimized.

Show comment
Hide comment
@sneaker2

sneaker2 Apr 17, 2017

25 might be a default value that's chosen because fixed_frame_rate_flag is 0.

25 might be a default value that's chosen because fixed_frame_rate_flag is 0.

@mbunkus

This comment has been minimized.

Show comment
Hide comment
@mbunkus

mbunkus Apr 17, 2017

Owner

Which doesn't explain how to interpret these particular values for time_scale and num_units_in_tick. Just ignore them? The current values mean that each field is 0.5 ns long. Obviously bogus.

Owner

mbunkus commented Apr 17, 2017

Which doesn't explain how to interpret these particular values for time_scale and num_units_in_tick. Just ignore them? The current values mean that each field is 0.5 ns long. Obviously bogus.

@sneaker2

This comment has been minimized.

Show comment
Hide comment
@sneaker2

sneaker2 Apr 17, 2017

In the end the user must supply timecodes or default-duration for such files. Maybe mkvmerge should fall back to the default 25 fps if values are outside of a sane range, say 0.1 fps to 10000 fps? I don't think it really matters.

In the end the user must supply timecodes or default-duration for such files. Maybe mkvmerge should fall back to the default 25 fps if values are outside of a sane range, say 0.1 fps to 10000 fps? I don't think it really matters.

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