loosing croping dimension, reference frame count and bitdepth in mkv

[michaelni]

might be a duplicate of issue 5

Heres a case loosing dimensions, reference frame count timebase and bit depth:
http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket4725/

./ffmpeg-pre-codecpar -v 99 -i tickets//4725/h264_pixfmt_matroska.mkv

Stream #0:0(jpn), 4, 1/1000: Video: h264 (High 10), 3 reference frames, yuv420p10le(tv, bt709, left), 1920x1080 (1920x1088) [SAR 1:1 DAR 16:9], 1001/48000, 23.98 fps, 23.98 tbr, 1k tbn, 47.95 tbc (default)
Metadata:
title : H.264 1080p BD
Stream #0:1(jpn), 8, 1/1000: Audio: flac, 48000 Hz, stereo, s32 (24 bit) (default)

./ffmpeg -v 99 -i tickets//4725/h264_pixfmt_matroska.mkv

Stream #0:0(jpn), 4, 1/1000: Video: h264 (High 10), 1 reference frame, yuv420p10le(tv, bt709, left), 1920x1080 (0x0) [SAR 1:1 DAR 16:9], 0/1, SAR 1:1 DAR 16:9, 23.98 fps, 23.98 tbr, 1k tbn (default)
Metadata:
title : H.264 1080p BD
Stream #0:1(jpn), 8, 1/1000: Audio: flac, 48000 Hz, stereo, s32 (default)

[Nevcairiel]

reference count is not a property exported by a demuxer, so that not being available is expected.

The second dimension is also not something the demuxer would export, since it only carries one width/height. Thats really one of the main aspects what codecpar is about, clearly separating demuxer provided info.

The FLAC bitdepth seems like a bug however.

[ghost]

The FLAC bit depth thing is because avcodec_string() prints bits_per_raw_sample, not bits_per_coded_sample. The demuxer sets only bits_per_coded_sample. Maybe a decoder initialized on an AVCodecContext will set bits_per_raw_sample in turn. But av_dump_format() initializes the AVCodecContext (which avcodec_string()) is called on from codec parameters only, nothing further. It doesn't open a decoder either.

This is again a symptom of wanting to provide decoder output in the demuxer, which is just insane and won't ever work. If ffmpeg.c wants to provide accurate information, it should decode a frame and show the frame properties.

I vote for WONTFIX.

[dwbuiten]

Is it worth printing bits_per_coded sample though?

[ghost]

I'm not sure, doesn't it have different semantics? Or maybe not. In any case it might be wrong to print it next to the sample format.

[dwbuiten]

I know, but it could be worth printing somewhere. Next to the codec?