<p>Hi,</p>
<p>On May 2, 2012 8:04 AM, "Donald Graft" <<a href="mailto:donald.graft@cantab.net">donald.graft@cantab.net</a>> wrote:<br>
><br>
> At 03:49 PM 5/1/2012, you wrote:<br>
>><br>
>> I have an application that used an earlier version of libavcodec<br>
>> (circa 2009). It relied on passing NALUs one at a time. Everything<br>
>> worked fine as the h.264 codec signaled CODEC_CAP_TRUNCATED and I<br>
>> flagged CODEC_FLAG_TRUNCATED.<br>
>><br>
>> I now am upgrading to libavcodec 0.7.4 and I find that CODEC_CAP_TRUNCATED<br>
>> is no longer signaled. As an experiment I flagged it on anyway and<br>
>> found that (under linux) the decoder still worked as it did before,<br>
>> and it gave me correct AVC video decoding.<br>
>><br>
>> This raises two questions that I would appreciate feedback on:<br>
>><br>
>> 1. Can I rely on this behavior? If not, what would you suggest?<br>
>> I can't use the h264 parser because I have to feed non-contiguous NALUs<br>
>> to support my frame-accurate seeking design.<br>
>><br>
>> 2. When building libavcodec for Windows using mingw/msys (and linking<br>
>> dynamically in my application) I get a crash when trying to use truncated feeding.<br>
>> Do you have any idea why it would work under linux and not under Windows?<br>
>><br>
>> Any thoughts on this matter would be greatly appreciated. Thank you.<br>
><br>
><br>
> Just a quick follow up. It turns out that it works (by luck I suppose) only<br>
> for streams with one slice per picture. If there are multiple slices, e.g.,<br>
> bluray streams, then it fails.<br>
><br>
> I suppose I will have to package my calls to libav so that full frames are passed.<br>
> What I don't understand is why libav was revised the way it was, breaking existing<br>
> applications.</p>
<p>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</p>
<p>Ronald</p>