[FFmpeg-devel] [RFC] Avoid av_read_frame memory copy in implementation

Michael Niedermayer michaelni
Fri May 28 15:54:24 CEST 2010


On Fri, May 28, 2010 at 09:13:50AM +0200, Cyril Russo wrote:
>
>
>>> Currently, I'm using
>>> threads, and I have to copy packet because if I don't, it crashes while
>>> decoding.
>>>      
>> ffplay uses threads, it does not always copy and it doesnt crash
>>    
> This is wrong.

this is tireing, you really dont understand the code at all.


> ffplay "av_dup" each packet (except special "flush 
> packets"). Please check the first 2 lines of packet_queue_put.

av_dup_packet() != always copying a packet
i suggest you reads its c code


> Remove that part and it crashes.

remove any random line and it will break one way or another


>
> Any code not using the packet immediately must do it, since calling again 
> av_read_frame can destroy the previous returned packet's data.
>
> Currently it's:
> 1) av_read_frame allocates/reuse its packet buffer (the documentation says 
> so, and my tests confirms this)
> 2) av_read_frame demux in the allocated packet
> 3) return packet to the user code

> 4) malloc packet data in user code
> 5) copy first packet data in the malloced area in user code

i cant help you if you always copy packets


>
> What I think would be better:
> 1) av_read_frame calls user function to get a buffer (instead of reusing 
> it)
> 2) av_read_frame demux in the allocated buffer
> 3) return packet to the user code

look you dont understand the code, i tried to explain it to you but you
ignore what i wrote. So we lack a basis for discussion, you first must 
understand how the demuxers and parsers interact before you can make
suggestions for a design change.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100528/6de01b41/attachment.pgp>



More information about the ffmpeg-devel mailing list