<p dir="ltr">I had to recompile ffmpeg without threads support to solve a similar issue. Can you try that?</p>
<div class="gmail_quote">On Oct 22, 2014 9:35 AM, "Info || Non-Lethal Applications" <<a href="mailto:info@non-lethal-applications.com">info@non-lethal-applications.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Bruce,<br>
<br>
thanks for your response!<br>
<br>
> It's sounds a bit like you're seeing multi-threaded decoding, in which each decode call gets back a frame that was previously passed in as a packet, and was decoded on another thread.<br>
> The returned frame should have an associated PTS, so it's not a problem.<br>
<br>
That’s the problem. The AVFrame's PTS is not set (well, it is set to 0x800000000000).<br>
The only thing I have left is the pkt_pts and pkt_dts which are both wrong.<br>
<br>
> Set the number of threads to 1 in your codec context and see if it changes.<br>
<br>
Good idea! I tried that but it didn’t help.<br>
<br>
Any other ideas?<br>
<br>
Thanks,<br>
<br>
Flo<br>
<br>
>> On Oct 22, 2014, at 02:53, Info || Non-Lethal Applications <<a href="mailto:info@non-lethal-applications.com">info@non-lethal-applications.com</a>> wrote:<br>
>><br>
>> I’m having problems with my own movie player I wrote using the FFmpeg libraries.<br>
>> The problem appears with a test DV clip created by Apple’s Compressor. It’s a generated clip, so I can upload it if it helps.<br>
>><br>
>> Let me quickly outline what I’m doing:<br>
>><br>
>> - I read video frames into a frame queue which is used as a source for playback<br>
>> - I read audio samples into a ring buffer which is used as a source for playback<br>
>><br>
>> To not risk audio dropouts, I’m reading about 200 ms audio samples more than I would need to display the respective video frames.<br>
>> While reading audio samples, I’m storing all video packets that come along in a video packet queue.<br>
>> When the next video frame is requested, I’m searching the queue first and read from the file only when the queue is empty.<br>
>> This procedure worked fine for all other formats I’ve been working with so far (mostly MOV and MXF).<br>
>><br>
>> I’ve been analyzing the issue for a couple of hours now and it seems to me that the packets that I put to the queue contain different content when I decode them later on.<br>
>> Actually, it seems that all packets in the queue decode to the frame that would be next in line when reading from the file.<br>
>><br>
>> Is there anything I could do to prevent this from happening?<br>
>> As I said I would be happy to upload the file. It’s 2 minutes of DV PAL, about 430 MB in size. I could make it smaller.<br>
>><br>
>> Thanks in advance!<br>
>><br>
>> Best,<br>
>><br>
>> Flo<br>
>> _______________________________________________<br>
>> Libav-user mailing list<br>
>> <a href="mailto:Libav-user@ffmpeg.org">Libav-user@ffmpeg.org</a><br>
>> <a href="http://ffmpeg.org/mailman/listinfo/libav-user" target="_blank">http://ffmpeg.org/mailman/listinfo/libav-user</a><br>
> _______________________________________________<br>
> Libav-user mailing list<br>
> <a href="mailto:Libav-user@ffmpeg.org">Libav-user@ffmpeg.org</a><br>
> <a href="http://ffmpeg.org/mailman/listinfo/libav-user" target="_blank">http://ffmpeg.org/mailman/listinfo/libav-user</a><br>
<br>
_______________________________________________<br>
Libav-user mailing list<br>
<a href="mailto:Libav-user@ffmpeg.org">Libav-user@ffmpeg.org</a><br>
<a href="http://ffmpeg.org/mailman/listinfo/libav-user" target="_blank">http://ffmpeg.org/mailman/listinfo/libav-user</a><br>
</blockquote></div>