pkt_size / size incorrect for first IDR frame

[slhck]

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.

[slhck]

sample

[mkver]

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.)