Opened 9 years ago
Closed 3 years ago
#4757 closed defect (wontfix)
pkt_size / size incorrect for first IDR frame
Reported by: | slhck | Owned by: | |
---|---|---|---|
Priority: | minor | Component: | avcodec |
Version: | git-master | Keywords: | h264 |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
When you list the frame sizes of an H.264 bitstream:
$ ffprobe tmp/input.264 -show_frames -of compact -show_entries frame=pict_type,pkt_size ffprobe version N-74286-ge5774f2 Copyright (c) 2007-2015 the FFmpeg developers built with gcc 4.9.3 (GCC) configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-avisynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libdcadec --enable-libfreetype --enable-libgme --enable-libgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libschroedinger --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid --enable-lzma --enable-decklink --enable-zlib libavutil 54. 30.100 / 54. 30.100 libavcodec 56. 57.100 / 56. 57.100 libavformat 56. 40.101 / 56. 40.101 libavdevice 56. 4.100 / 56. 4.100 libavfilter 5. 32.100 / 5. 32.100 libswscale 3. 1.101 / 3. 1.101 libswresample 1. 2.101 / 1. 2.101 libpostproc 53. 3.100 / 53. 3.100 [h264 @ 0000000002f8e580] Stream #0: not enough frames to estimate rate; consider increasing probesize Input #0, h264, from 'tmp/a2d3e400-3605-11e5-9bff-005056c00008.264': Duration: N/A, bitrate: N/A Stream #0:0: Video: h264 (High), yuv420p, 1920x1080, 24 fps, 24 tbr, 1200k tbn, 48 tbc frame|pkt_size=354784|pict_type=I frame|pkt_size=19850|pict_type=B frame|pkt_size=27829|pict_type=B frame|pkt_size=21599|pict_type=B frame|pkt_size=67117|pict_type=P ...
The first frame (packet?) is indicated as being 354784 Bytes large. I don't know what exactly the definition of "packet" with regard to raw bitstreams is (I would have guessed a NALU, but apparently I'm wrong).
But when I look at the NAL units in detail, and reorder the ffmpeg output from display to decoding order, I can see that ffmpeg actually includes the AUD, SEI, SPS and PPS in the size of the first frame:
ffmpeg NALU (+ size, incl. start code) ============= =============================== I: 354784 AUD: 6 SEI: 739 SPS: 30 PPS: 10 IDR slice: 353999 ----------------------------------------------- P: 67117 AUD: 6 NonIDR slice: 67111 ----------------------------------------------- ...
The bug here is that when the size of a packet is requested, ffmpeg should show the actual size of the NAL unit(s) of the slice(s) belonging to that frame, and it should not include the NAL units irrelevant to that frame, such as SPS/PPS, SEI, or AUDs.
Attachments (1)
Change History (3)
by , 9 years ago
Attachment: | a2d3e400-3605-11e5-9bff-005056c00008.264 added |
---|
comment:1 by , 9 years ago
Keywords: | h264 added |
---|---|
Priority: | normal → minor |
comment:2 by , 3 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
These NAL units are not irrelevant to the frame; they are part of the access unit that the IDR slice belongs to. (Access unit is also what FFmpeg puts into one packet and what most containers expect (although it is also supported to have a pair of field pictures in one packet (as is common in mpegts)); read the H.264 spec if you want to know how access units are delimited.)
sample