On Fri, Aug 18, 2017 at 8:16 AM, Michael Niedermayer
wrote:
>
> seeking still fails with this and the sample from #6584 is that
> intended or a seperate issue ?
I didn't see any failure using "./ffmpeg -ss 00:00:10" (and also other
time from 0s to 20s). How to reproduce a seeking failure?
___
On Tue, Jan 2, 2018 at 8:03 PM, Carl Eugen Hoyos wrote:
> 2018-01-02 8:52 GMT+01:00 :
>
>> @@ -565,6 +579,10 @@ static av_cold int ffat_close_encoder(AVCodecContext
>> *avctx)
>> ff_bufqueue_discard_all(&at->frame_queue);
>> ff_bufqueue_discard_all(&at->used_frame_queue);
>> ff_af
On Tue, Jan 2, 2018 at 10:37 PM, wm4 wrote:
> On Tue, 2 Jan 2018 22:27:49 +0800
> Jiejun Zhang wrote:
>
>> On Tue, Jan 2, 2018 at 8:03 PM, Carl Eugen Hoyos wrote:
>> > 2018-01-02 8:52 GMT+01:00 :
>> >
>> >> @@ -565,6 +579,10 @@ static av_cold int ff
>
> Can't you instead create a new reference for the frame buffer? Or will
> making it non writable break things further into the process? It would
> save you a memcpy per frame.
Great idea. It works. Making it non-writable should be enough. I'm
submitting v3. Please take a look.
_
On Wed, Jan 3, 2018 at 10:02 AM, James Almer wrote:
> On 1/2/2018 1:24 PM, zhangjiejun1...@gmail.com wrote:
>> From: Jiejun Zhang
>>
>> This fixes #6940
>>
>> Although undocumented, AudioToolbox seems to require the data supplied
>> by the callback (i.e
On Wed, Jan 3, 2018 at 2:24 PM, Bang He wrote:
> maybe you should return 1, not return ret
returning ret in callback will make AudioConverterFillComplexBuffer
return ret. so i think returning ret is better. furthermore 1 is not
treated as an error code in the current implementation of ffat_encod
