[libav-api] CODEC_CAP_TRUNCATED/CODEC_FLAG_TRUNCATED for h.264?

Donald Graft donald.graft at cantab.net
Wed May 2 17:04:22 CEST 2012


At 03:49 PM 5/1/2012, you wrote:
>I have an application that used an earlier version of libavcodec
>(circa 2009). It relied on passing NALUs one at a time. Everything
>worked fine as the h.264 codec signaled CODEC_CAP_TRUNCATED and I
>flagged CODEC_FLAG_TRUNCATED.
>
>I now am upgrading to libavcodec 0.7.4 and I find that CODEC_CAP_TRUNCATED
>is no longer signaled. As an experiment I flagged it on anyway and
>found that (under linux) the decoder still worked as it did before,
>and it gave me correct AVC video decoding.
>
>This raises two questions that I would appreciate feedback on:
>
>1. Can I rely on this behavior? If not, what would you suggest?
>I can't use the h264 parser because I have to feed non-contiguous NALUs
>to support my frame-accurate seeking design.
>
>2. When building libavcodec for Windows using mingw/msys (and linking
>dynamically in my application) I get a crash when trying to use 
>truncated feeding.
>Do you have any idea why it would work under linux and not under Windows?
>
>Any thoughts on this matter would be greatly appreciated. Thank you.

Just a quick follow up. It turns out that it works (by luck I suppose) only
for streams with one slice per picture. If there are multiple slices, e.g.,
bluray streams, then it fails.

I suppose I will have to package my calls to libav so that full 
frames are passed.
What I don't understand is why libav was revised the way it was, 
breaking existing
applications.

Don 



More information about the libav-api mailing list