On 9/20/2019 5:39 PM, Andreas Rheinhardt wrote:
> Up until now, ff_packet_list_put had a flaw: When it moved a packet to
> the list (meaning, when it ought to move the reference to the packet
> list instead of creating a new one via av_packet_ref), it did not reset
> the original packet, confusing
On 9/25/2019 7:06 PM, Andreas Rheinhardt wrote:
> James Almer:
>> On 9/20/2019 5:39 PM, Andreas Rheinhardt wrote:
>>> Up until now, ff_packet_list_put had a flaw: When it moved a packet to
>>> the list (meaning, when it ought to move the reference to the packet
>>> list instead of creating a new
James Almer:
> On 9/20/2019 5:39 PM, Andreas Rheinhardt wrote:
>> Up until now, ff_packet_list_put had a flaw: When it moved a packet to
>> the list (meaning, when it ought to move the reference to the packet
>> list instead of creating a new one via av_packet_ref), it did not reset
>> the
On 9/20/2019 5:39 PM, Andreas Rheinhardt wrote:
> Up until now, ff_packet_list_put had a flaw: When it moved a packet to
> the list (meaning, when it ought to move the reference to the packet
> list instead of creating a new one via av_packet_ref), it did not reset
> the original packet, confusing
Up until now, ff_packet_list_put had a flaw: When it moved a packet to
the list (meaning, when it ought to move the reference to the packet
list instead of creating a new one via av_packet_ref), it did not reset
the original packet, confusing the ownership of the data in the packet.
This has been
