At 10:24 AM 5/2/2012, you wrote:
Hi,
On May 2, 2012 8:04 AM, "Donald Graft"
<<mailto:[email protected]>[email protected]> wrote:
>
> 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.
Frame-level multi threading. You can restore old behaviour by
setting AVCodecContext.thread_count = 1 or thread_type = 0. But then
you do not get multithreading
Ronald
Thank you for your response, Ronald. That didn't help, however. The
point is I suppose that the
h264 decoder no longer supports CODEC_FLAG_TRUNCATED, as that does
not appear in its code
anymore. So it's not possible to get the old behavior. Please correct
me if I am wrong
about that.
Don
_______________________________________________
libav-api mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-api
