Opened 6 years ago

Last modified 9 months ago

#6958 reopened defect

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

Reported by: Zhong,Li Owned by:
Priority: normal Component: ffprobe
Version: git-master Keywords: h264 codecpar regression
Cc: zhong.li@intel.com Blocked By:
Blocking: Reproduced by developer: yes
Analyzed by developer: yes

Description (last modified by Carl Eugen Hoyos)

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]

Attachments (1)

Test_1080p.h264 (18.9 KB ) - added by Zhong,Li 6 years ago.

Download all attachments as: .zip

Change History (11)

by Zhong,Li, 6 years ago

Attachment: Test_1080p.h264 added

comment:1 by Zhong,Li, 6 years ago

Analyzed by developer: set

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 in avcodec_parameters_from_context() for the latest ffmpeg, then coded_width/coded_height will be reset by avcodec_open2 with width/height.

Last edited 6 years ago by Zhong,Li (previous) (diff)

comment:2 by Zhong,Li, 6 years ago

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

comment:3 by Carl Eugen Hoyos, 6 years ago

Analyzed by developer: unset
Component: avformatavcodec
Description: modified (diff)
Keywords: h264 codecpar regression added
Priority: normalimportant
Reproduced by developer: set
Status: newopen

Regression since 6f69f7a8

comment:4 by Zhong,Li, 6 years ago

Analyzed by developer: set

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

comment:5 by Zhong,Li, 6 years ago

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

comment:6 by James, 6 years ago

Component: avcodecffprobe
Resolution: fixed
Status: openclosed

comment:7 by projectsymphony, 6 years ago

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

Last edited 6 years ago by projectsymphony (previous) (diff)

comment:8 by Balling, 10 months ago

Priority: importantnormal
Resolution: fixed
Status: closedreopened

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

Last edited 10 months ago by Balling (previous) (diff)

comment:9 by Balling, 10 months ago

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?

Note: See TracTickets for help on using tickets.