ffprobe can't show correct coded_height for h264 1080p videos

[Zhong,Li]

Summary of the bug:

Use ffprobe to analyze a h264 1080p(920x1080) video， it will show the coded_height is 1080, which is different from the value parsed from
h264_decode_frame (1088).

Looks like ffprobe always show coded_height/coded_width equal to height/width

How to reproduce:

./ffprobe -report -show_streams ~/Videos/test_1080p.h264
ffprobe started on 2018-01-11 at 17:25:35
Report written to "ffprobe-20180111-172535.log"
ffprobe version N-89764-g76a3753 Copyright (c) 2007-2018 the FFmpeg developers
  built with gcc 4.8.5 (GCC) 20150623 (Red Hat 4.8.5-11)
  configuration: --enable-libmfx --enable-libx264 --enable-gpl --disable-optimizations --enable-debug=3
  libavutil      56.  7.100 / 56.  7.100
  libavcodec     58.  9.100 / 58.  9.100
  libavformat    58.  3.100 / 58.  3.100
  libavdevice    58.  0.100 / 58.  0.100
  libavfilter     7. 11.101 /  7. 11.101
  libswscale      5.  0.101 /  5.  0.101
  libswresample   3.  0.101 /  3.  0.101
  libpostproc    55.  0.100 / 55.  0.100
Input #0, h264, from '/samba/anonymous/Videos/test_1080p.h264':
  Duration: N/A, bitrate: N/A
    Stream #0:0: Video: h264 (High), yuv420p(progressive), 1920x1080 [SAR 1:1 DAR 16:9], 25 fps, 25 tbr, 1200k tbn, 50 tbc
[STREAM]
index=0
codec_name=h264
codec_long_name=H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10
profile=High
codec_type=video
codec_time_base=1/50
codec_tag_string=[0][0][0][0]
codec_tag=0x0000
width=1920
height=1080
coded_width=1920
coded_height=1080
has_b_frames=1
sample_aspect_ratio=1:1
display_aspect_ratio=16:9
pix_fmt=yuv420p
level=40
color_range=unknown
color_space=unknown
color_transfer=unknown
color_primaries=unknown
chroma_location=left
field_order=progressive
timecode=N/A
refs=1
is_avc=false
nal_length_size=0
id=N/A
r_frame_rate=25/1
avg_frame_rate=25/1
time_base=1/1200000
start_pts=N/A
start_time=N/A
duration_ts=N/A
duration=N/A
bit_rate=N/A
max_bit_rate=N/A
bits_per_raw_sample=8
nb_frames=N/A
nb_read_frames=N/A
nb_read_packets=N/A
DISPOSITION:default=0
DISPOSITION:dub=0
DISPOSITION:original=0
DISPOSITION:comment=0
DISPOSITION:lyrics=0
DISPOSITION:karaoke=0
DISPOSITION:forced=0
DISPOSITION:hearing_impaired=0
DISPOSITION:visual_impaired=0
DISPOSITION:clean_effects=0
DISPOSITION:attached_pic=0
DISPOSITION:timed_thumbnails=0
[/STREAM]

[Zhong,Li]

Looks like it is a regression issue, checking it with an old version ffmpeg/ffprobe (such as ffmpeg 2.8.13), ffprobe can show correct coded_height (1088). It is due to codec->coded_width/coded_height haven't been passed to AVCodecParameters for the latest ffmpeg, then coded_width/coded_height will be reset by avcodec_open2 with width/height.

[Carl Eugen Hoyos]

Regression since 6f69f7a8

[Zhong,Li]

Send a patch (​https://patchwork.ffmpeg.org/patch/7318/) to fix this issue.

[Zhong,Li]

Updated with a new patch to fix it (​https://patchwork.ffmpeg.org/patch/7344/)

[James]

Fixed in 19b1d905b88d32a86511219585eae6afda23dfbd.

[projectsymphony]

This is hiding (or will hide) the reporting of coded_width and coded_height entirely, which is actually needed by downstream.

[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 a) coded_width=1920 coded_height=1080 are still there so AVStream->codec is still there, right? (oops, it was removed in 3749eede66c3774799766b1f246afae8a6ffc9bb) b) this issue was apparently never fixed or regressed (apparently regressed after 04f49645a519233f3638104e0df5215758652fcb, see #9456)? See also: #9411, that I will close as a dup

[Balling]

Wait a second, what is that?? 94eb5505ad7b061e17e1c338f04bec0d05e10ca0

Why does it trigger a warning on non-windows systems because

Works on Windows, apparently because compat/w32pthreads.h pulls it

But that is insane: nvenc.c uses 4 different FF_ENABLE_DEPRECATION_WARNINGS/ disable... so what is the problem? LOL, what is that?

[Balling]

Apparently it still works in some cases like on this video, but it is hevc:

​https://code.videolan.org/videolan/vlc/uploads/8085c161cc962671fa0d0c5985b1e3a0/original.mp4

And also crop: ​https://code.videolan.org/videolan/vlc/uploads/1ff874f1ced381b7bbee27233f7cbe09/croppedwithmetadata.mp4

[Balling]

Okay, when will printing of those two deprecated values going to be stopped? Either fix it, or nuke it.