On 06/03/2016 03:53 PM, Nicolas George wrote:
Le nonidi 9 prairial, an CCXXIV, Jan Sebechlebsky a écrit :
If I understand it correctly, I think this will be handled quite smoothy -
you don't have to kill the blocked write, the application has to call
write_trailer anyway before closing the mux
On 06/03/2016 03:46 PM, Nicolas George wrote:
Sorry for forgetting to reply.
L'octidi 8 prairial, an CCXXIV, Marton Balint a écrit :
What if we decouple the non-blocking queue and the retry on failure logic to
a separate "buffer" or "fifo" muxer?
This seems like what you are trying to do, an
Le nonidi 9 prairial, an CCXXIV, Jan Sebechlebsky a écrit :
> If I understand it correctly, I think this will be handled quite smoothy -
> you don't have to kill the blocked write, the application has to call
> write_trailer anyway before closing the muxer, so I guess this is the place
> where tee
Sorry for forgetting to reply.
L'octidi 8 prairial, an CCXXIV, Marton Balint a écrit :
> What if we decouple the non-blocking queue and the retry on failure logic to
> a separate "buffer" or "fifo" muxer?
>
> This seems like what you are trying to do, and by using the exisiting muxer
> interface,
Hi Nicolas,
On 05/26/2016 12:09 PM, Nicolas George wrote:
But the "stick everything in threads" approach is flawed. Just think
about what will happen if the actual muxer is blocking on a write
while the application, seeing non-blocking behaviour, wants to close
it: how do you kill the blocked
On Thu, 26 May 2016, Nicolas George wrote:
Le duodi 2 prairial, an CCXXIV, Marton Balint a écrit :
What caused these complications? Do you have some references?
I do not remember exactly. There is the problem quoted by Michael. There is
also a more global issue that options will be inconsist
On Thu, May 26, 2016 at 12:09:14PM +0200, Nicolas George wrote:
> Le duodi 2 prairial, an CCXXIV, Marton Balint a écrit :
> > What caused these complications? Do you have some references?
>
> I do not remember exactly. There is the problem quoted by Michael. There is
> also a more global issue tha
Le duodi 2 prairial, an CCXXIV, Marton Balint a écrit :
> What caused these complications? Do you have some references?
I do not remember exactly. There is the problem quoted by Michael. There is
also a more global issue that options will be inconsistent: one
implementation of non-blocking would h
On Wed, 18 May 2016, Jan Sebechlebsky wrote:
[...]
I'm thinking of implementing this queue by wrapping up AVFifoBuffer
(similarily than AVThreadMessageQueue does but with the configurable
behaviour as described above).
Exactly what behaviour is missing from AVThreadMessageQueue? Isn't there
On 5/20/16, 9:32 PM, "ffmpeg-devel on behalf of Michael Niedermayer"
wrote:
>On Fri, May 20, 2016 at 12:06:34AM +0200, Marton Balint wrote:
>>
>> On Thu, 19 May 2016, Nicolas George wrote:
>>
>> >Le tridi 23 floréal, an CCXXIV, Jan Sebechlebsky a écrit :
>> >>My current idea is to create que
On Fri, May 20, 2016 at 12:06:34AM +0200, Marton Balint wrote:
>
> On Thu, 19 May 2016, Nicolas George wrote:
>
> >Le tridi 23 floréal, an CCXXIV, Jan Sebechlebsky a écrit :
> >>My current idea is to create queue for each output (as Marton suggested) and
> >>process each output in separate thread
On Thu, 19 May 2016, Nicolas George wrote:
Le tridi 23 floréal, an CCXXIV, Jan Sebechlebsky a écrit :
My current idea is to create queue for each output (as Marton suggested) and
process each output in separate thread. I was also considering using just
single queue, but since the AVPackets are
Hello Nicolas,
On 05/19/2016 12:44 PM, Nicolas George wrote:
Le tridi 23 floréal, an CCXXIV, Jan Sebechlebsky a écrit :
My current idea is to create queue for each output (as Marton suggested) and
process each output in separate thread. I was also considering using just
single queue, but since
Le tridi 23 floréal, an CCXXIV, Jan Sebechlebsky a écrit :
> My current idea is to create queue for each output (as Marton suggested) and
> process each output in separate thread. I was also considering using just
> single queue, but since the AVPackets are referenced counted, the memory
> overhead
Hello Marton,
sorry for a delayed reply.
On 05/16/2016 01:20 AM, Marton Balint wrote:
On Wed, 11 May 2016, Jan Sebechlebsky wrote:
Hi,
I'll be working on tee muxer improvement during GSoC 2016 and I
thought maybe it is a good idea to ask about ideas which any of you
might have regarding wha
On Wed, 11 May 2016, Jan Sebechlebsky wrote:
Hi,
I'll be working on tee muxer improvement during GSoC 2016 and I thought
maybe it is a good idea to ask about ideas which any of you might have
regarding what could be done in avformat/tee.
Currently, the tee muxer works in a simple way, incom
16 matches
Mail list logo
