On 10/06/2017 11:38 PM, Jorge Ramirez-Ortiz wrote:
On 10/06/2017 10:01 PM, Mark Thompson wrote:
On 06/10/17 20:53, Mark Thompson wrote:
On 06/10/17 08:52, Jorge Ramirez-Ortiz wrote:
It occurs when the codec is closed while buffer references still
exist. This is a regression from the original p
On 10/06/2017 10:01 PM, Mark Thompson wrote:
On 06/10/17 20:53, Mark Thompson wrote:
On 06/10/17 08:52, Jorge Ramirez-Ortiz wrote:
It occurs when the codec is closed while buffer references still
exist. This is a regression from the original patchset where support
for this use-case was implemen
On 06/10/17 20:53, Mark Thompson wrote:
> On 06/10/17 08:52, Jorge Ramirez-Ortiz wrote:
>> It occurs when the codec is closed while buffer references still
>> exist. This is a regression from the original patchset where support
>> for this use-case was implemented.
>>
>> The regression occurred whi
On 06/10/17 08:52, Jorge Ramirez-Ortiz wrote:
> It occurs when the codec is closed while buffer references still
> exist. This is a regression from the original patchset where support
> for this use-case was implemented.
>
> The regression occurred while cleaning the code for the last patchset
> (
On 10/06/2017 09:52 AM, Jorge Ramirez-Ortiz wrote:
It occurs when the codec is closed while buffer references still
exist. This is a regression from the original patchset where support
for this use-case was implemented.
The regression occurred while cleaning the code for the last patchset
(decod
It occurs when the codec is closed while buffer references still
exist. This is a regression from the original patchset where support
for this use-case was implemented.
The regression occurred while cleaning the code for the last patchset
(decoding was tested only with ffplay which disposes of the
