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
_______________________________________________
libav-api mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-api
