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

[Stefano Sabatini]

On date Wednesday 2013-12-18 02:56:34 +0900, Yusuke Nakamura encoded:
> 2013/12/17 Stefano Sabatini <stefasab at gmail.com>
[...]
> 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.

What I don't understand is how the VPS/SPS/PPS are processed in the
FFmpeg framework, if they correspond to packets or if are stored
somewhere else when processing the bitstream (e.g. as extradata
used to decode the next frames).

So I suppose if such information is not contained in the same packet
of the corresponding I-frame, then in case we split a H.264 stream at
a key-packet we may miss that information when we start decoding the
segment from that packet.

But since this is not the general case, then I wonder when this is
happening, and if there is some way to fix it.

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

Thanks for taking the time to reply.
-- 
FFmpeg = Formidable & Formidable Meaningless Patchable Erratic Gymnast