[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