[FFmpeg-devel] [PATCH] rtpdec: Better logic for immediately returning packets from the queue

Luca Barbato lu_zero
Fri Oct 8 14:30:46 CEST 2010


On 10/08/2010 11:44 AM, Martin Storsj? wrote:
> On Fri, 8 Oct 2010, Luca Barbato wrote:
>
>> On 10/08/2010 11:16 AM, Martin Storsj? wrote:
>>> But what if packets 1-5 were one single large fragmented packet? Then the
>>> depacketization of packet 1 would return AVERROR(EAGAIN), and return no
>>> data until the whole frame has been depacketized. Currently, we'd return
>>> the control to the caller, and only proceed to check packet 2 the next
>>> time we're called. These patches instead make sure we check if we have the
>>> next packet in sequence, and try to parse that, if the current parsing
>>> returned<   0.
>>>
>>> I've tested this with the VP8 depacketizer that uses this logic, with an
>>> intentionally scrambled/reordered sender, and it seems to work as I intend
>>> now.
>>>
>>> Opinions?
>>
>> I'd check for EAGAIN explicitly, beside that it's fine for me.
>
> Not all of them return AVERROR(EAGAIN), some just return -1, too...

That might need attention.

> And on
> the other side, even if packet 1 failed due to it being invalid, I still
> think we can try to depacketize the next one if we have it, and see if
> that one succeeds instead.

I think would be better notify this to the upper layer sooner and not 
hide it.

lu

-- 

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero




More information about the ffmpeg-devel mailing list