ffprobe coded_width, coded_height, and all dec_ctx->properties fields broken (regression)

[Gregory Beauregard]

Summary of the bug: The coded_height and coded_width parameters don't work in ffprobe; they always display the same as the width and height fields.
How to reproduce: Run the following command on any 1080p h264 file. Expected coded_height is 1088, but it will show 1080.

ffprobe -select_streams v -show_entries stream=coded_width,coded_height file.mkv

This behavior is a regression since 04f49645a519233f3638104e0df5215758652fcb

This behavior was also broken in the past and was fixed in ​https://trac.ffmpeg.org/ticket/6958 before regressing.

ffprobe should not be outputting wrong info

[Gregory Beauregard]

My personal dog in this is I would like to access this info so I have a way to do calculations needed for bitstream filter (bsf) cropping, but this should be removed rather than displaying the wrong value if the wish is to deprecate it.

A fix or removal would also need backported to 4.4.

[Gregory Beauregard]

Removal or re-implementation of all fields that depended on ist->dec_ctx->properties being set (like closed_captions and film-grain and more?) will also need backported to 4.4 if the API has already been removed (precluding the revert of the commit). All ffprobe fields that depended on this being set regressed in the same commit and now show fake wrong results with ffprobe.

If the API is not yet removed the better solution is probably reverting the commit in the 4.4 branch so the deprecation or fix of all these ffprobe fields can be done correctly in master.

[Gregory Beauregard]

avstream.codec was removed before 4.4 release: ​https://github.com/FFmpeg/FFmpeg/commit/3749eede

So we will need to backport a deprecation or re-implementation of these ffprobe fields to 4.4 branch

[Gregory Beauregard]

updated properties to correspond to triage on previous instance of this bug ​https://trac.ffmpeg.org/ticket/6958 since the bug is the same except for also breaking a few additional things

[Carl Eugen Hoyos]

Please provide the command line you tested together with the complete, uncut console output and an input sample to make this a valid ticket.

[Gregory Beauregard]

Replying to Carl Eugen Hoyos:

Please provide the command line you tested together with the complete, uncut console output and an input sample to make this a valid ticket.

+reproduced by developer (communication in irc a few months ago)

You can find the sample and commandline output on the trac linked in the description, but if you're uncomfortable using that uploaded sample you can also use probably most of the samples in fate or that have been uploaded if they don't have the right multiple (i.e. any 1080p h264 file)

[Balling]

This specific approach is IMO acceptable. It basically recovers the
pre-codecpar behavior until AVStream->codec is removed, and effectively
fixes the "regression".
Once that's gone, ffprobe will stop reporting coded_width/height
altogether instead of doing so with a bogus value, as everything is
being wrapped in the proper checks.

quote from ​https://patchwork.ffmpeg.org/project/ffmpeg/patch/7D9B0A5171224A4A9A6308992BC4469B3BC46423@shsmsx102.ccr.corp.intel.com/

So AVStream->codec was removed, yet you did not remove coded_width, etc, fields. Is this some kind of joke? Closing as a duplicate of #6958, that I reopened.