[FFmpeg-devel] h264: dealing with "broken links"
Mon Nov 19 03:24:46 CET 2007
On Sun, Nov 18, 2007 at 11:48:43PM +0100, Reinhard Nissl wrote:
> in the thread "[PATCH] Enable PAFF decoding", Loren Merritt wrote, that
> H.264's "closed gop" implementation are IDR slices. When I start
> replaying a VDR recording at an I frame which is coded with IDR slices,
> I can successfully watch the recording.
> But I've got some samples from Russia which contain very few IDR coded I
> frames so, most often replay starts at an I frame which was coded with
> non IDR slices. But in that case, FFmpeg decodes the I frame properly
> but then runs out of frames when dealing with the B frame.
> It reports [h264 @ 0xb61bb2f0]warning: first frame is no keyframe
> and then gotos to a location in MPV_frame_start() where it allocates a
> further frame. This "loop" continues until all 32 frames are allocated,
> where replay terminates with an error.
> A debug version would have asserted before entering the loop:
> assert(s->pict_type != B_TYPE); //these should have been dropped if we
> don't have a reference
> But I'm a bit pointless where this should have been done. Attached is a
> hack which patches pict_type to P_TYPE in that case, which makes the
> sample play properly. As I do not get any errors regarding picture
> referencing, I think it is legal to try to replay "broken links"
> although they do not start with IDR slices.
patch rejected, as the text says b frames should be droped if a reference
and changing pict_type to in invalid value is never acceptable
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel