[Libav-user] "no picture" from decoding single h264 keyframe

Dídac Pérez perez.didac at gmail.com
Thu Apr 3 10:24:46 CEST 2014


Hi Andrey,

PLEASE: I am not sure what I am about to say (better if somebody can
correct me).

I think that if you try to decode a AVPacket it may not return the actual
packet, but the previous one. This is because the bidirectional prediction.
This means that maybe you will decode the AVPacket with the keyframe in the
next iteration using the next AVPacket.

--
Dídac Pérez



2014-04-03 3:28 GMT+02:00 Andrey Utkin <andrey.krieger.utkin at gmail.com>:

> Hi all!
> I am checking a C application using ffmpeg libs, which does the following:
> it demuxes h264 stream from RTSP channel, and, when an event happens,
> it waits for next keyframe (determined with AVPacket.flags &
> AV_PKT_FLAG_KEY), creates appropriate decoder AVCodecContext for it,
> and decodes the frame for further processing. The idea is that having
> a keyframe, we can decode just single encoded frame and get valid
> picture. This approach must have been working correctly in practice,
> but now i have it not working with h264 stream from IP camera Axis
> M1034-W; the decoding operation indicates that we got no picture (by a
> avcodec_decode_video2() flag parameter), and prints
> [h264 @ blah] no picture
>
> This shouldn't be RTP loss, the camera is connected directly to my PC
> with a patchcord.
> If that is needed, i can share a remuxed stream dump.
> BTW Is there an easy way to print out the types of encoded h264 frames
> (I, P, B...)?
>
> Could please somebody elaborate what exactly happens? Is above
> approach generally broken, or it can be fixed (without decoding a lot
> more frames)?
>
> --
> Andrey Utkin
> _______________________________________________
> Libav-user mailing list
> Libav-user at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/libav-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ffmpeg.org/pipermail/libav-user/attachments/20140403/5fba1196/attachment.html>


More information about the Libav-user mailing list