[FFmpeg-devel] Splitting H.264 stream at key packet, first frame is not an I-frame

[Yusuke Nakamura]

2013/12/17 Stefano Sabatini <stefasab at gmail.com>

> Hi,
>
> sorry if the topic is not really for ffmpeg-devel, but I'm having this
> problem and I'm not sure if this is a bug or what.
>
> I'm splitting a file using the segment muxer:
> ffmpeg -i IN.ts -codec copy -f segment -segment_time 6 -map 0
> -segment_format mpegts seg-%d.ts
>
> The file is correctly split at a key packet, as I can see with:
> $ ffprobe seg-1.ts -show_entries packet=pts_time,flags -select_streams v
> -of compact -read_intervals "%+#3"
> packet|pts_time=6.286400|flags=K
> packet|pts_time=6.328111|flags=_
> packet|pts_time=6.369811|flags=_
>
> But the first frame is not correctly decoded, so I get the following
> $ ffprobe seg-1.ts -show_entries
> packet=pts_time,flags:frame=pkt_pts_time,pict_type -select_streams v -of
> compact -read_intervals "%+#3"
> [h264 @ 0x3823400] non-existing PPS referenced
> [h264 @ 0x3823400] non-existing PPS 0 referenced
> [h264 @ 0x3823400] decode_slice_header error
> [h264 @ 0x3823400] no frame!
> [h264 @ 0x3823400] non-existing PPS referenced
> [h264 @ 0x3823400] non-existing PPS 0 referenced
> [h264 @ 0x3823400] decode_slice_header error
> [h264 @ 0x3823400] no frame!
> [repeated multiple times]
> Input #0, mpegts, from 'seg-1.ts':
>   Duration: 00:00:03.67, start: 6.286400, bitrate: 2627 kb/s
>   Program 1
>     Metadata:
>       service_name    : Service01
>       service_provider: FFmpeg
>     Stream #0:0[0x100]: Video: h264 (Constrained Baseline) ([27][0][0][0]
> / 0x001B), yuv420p, 1024x576 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 90k
> tbn, 47.95 tbc
>     Stream #0:1[0x101]: Audio: aac ([15][0][0][0] / 0x000F), 22050 Hz,
> stereo, fltp, 57 kb/s
> packet|pts_time=6.286400|flags=K
> packet|pts_time=6.328111|flags=_
> packet|pts_time=6.369811|flags=_
> frame|pkt_pts_time=6.328111|pict_type=P
> frame|pkt_pts_time=6.369811|pict_type=P
>
> I'd expect the first key packet to contain an I-frame, and assume that
> this should be decodable with no reference to previous frames, but
> maybe this is not the case.
>
> So the question is: is this a decoder bug or is expected behavior?
>
> How it is possible to generate a H.264 stream for which any key-packet
> corresponds to a fully decodable I-frame (so that key-packet splitting
> won't result in corrupted or missing frames)?
>
> Is it possible to export the frame dependency information, and show it
> with ffprobe?
> --
> FFmpeg = Friendly and Fabulous Mournful Philosophical Extroverse Game
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

For AVC and HEVC stream, IDR-picture or I-picture with
recovery_frame_cnt==0 themselves are not a Random Access Point (RAP).
The specification doesn't forbid that these pictures have no corresponding
parameter sets (VPS, SPS and PPS), but libavcodec/libavformat marks as a
keyframe even if the corresponding parameter sets are missing.
Though I don't know the definition of keyframe within ffmpeg/libav
framework, it is marked in CODEC level as far as I can see.
For containers conveying parameter sets out-of-bandly such as MP4, all
sample containing IDR-picture or I-picture with recovery_frame_cnt==0 are a
RAP since the decoder can be initialized in any time.
For containers conveying parameter sets in-bandly such as MPEG-2 TS, all
sample containing IDR-picture or I-picture with recovery_frame_cnt==0 are
not always a RAP since the decoder can be initialized only when you get the
corresponding parameter sets, i.e. all sample containing IDR-picture or
I-picture with recovery_frame_cnt==0 with the corresponding parameter sets
are a RAP.
Under the current keyframe usage, keyframe and RAP is not equivalent.

I want a framework which distinguishes keyframe and RAP for libavformat.
This is useful when remuxing a stream from an in-band typed container into
an out-of-band typed containter, and vice versa.