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

[Cyril Russo]

>> 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. ffplay "av_dup" each packet (except special "flush 
packets"). Please check the first 2 lines of packet_queue_put.
Remove that part and it crashes.

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

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




>
>    
>> If I had my own allocate_packet function in the context, then I would
>> probably allocate them in a thread's specific buffer.
>> The default function could simply act like it does currently (we would keep
>> the "returned packet is valid until next av_read_frame" part, but add
>> "unless you provide your own allocate_packet function").
>>      
> you dont seem to understand the problem at all or i dont understand you.
>
>    
What I want is simple, I want to avoid the player to copy the stream 
twice in memory.
Currently, you can't store a read packet for later decoding, unless you 
dup' it.

To change this, av_read_frame semantic should be changed, either by 
writing another function or by implementing a function pointer for 
packet allocation so av_read_frame can't reuse a packet buffer.
The former is a pain for users, they'll need to update their code, the 
latter seems more like it's already done (and packet already have a 
"destruct" function pointer).

I don't know which is best, or if the solution worth it at all, hence 
the RFC.

Regards,
Cyril