Le primidi 1er prairial, an CCXXIV, Michael Niedermayer a écrit :
> can you do a quick time ffmpeg ... with -codec copy just to double
> check ? theres no major effect
It seems the memory management is not as negligible as I expected. The
result is a ~2.3% slow-down for ~90k frames from AVI, which
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, May 25, 2016 at 16:11:58 +0300, Semen Zaytsev wrote:
> I defined my filter in those files, and i string about configure this
> filter in config.mak, I move content of vf_edgedetect.c to vf_foobar.c,
> defined in makefile and in allfilters.c, when i trying to use "ffmpeg -i
> http://samples.
On Wed, May 25, 2016 at 10:36:13PM +0800, kl222 wrote:
> Filter: Add snapshot filter.
> It can save a snapshot picture. Supports .png, .jpg, .bmp formats
> Snapshot with process_command api.
>
>
> doc/filters.texi | 23
> libavfilter/Makefile |1
> libavfilter/allfilt
Avoids unwanted parser dependency on dcadata.
---
libavcodec/Makefile | 2 +-
libavcodec/dca.c| 9 +
libavcodec/dca.h| 3 +++
libavcodec/dca_exss.c | 1 -
libavcodec/dca_parser.c | 1 -
libavcodec/dcadata.c| 9 -
libavcodec/dcadata.h| 3 ---
7 files ch
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
On 5/26/2016 8:29 AM, foo86 wrote:
> Avoids unwanted parser dependency on dcadata.
> ---
> libavcodec/Makefile | 2 +-
> libavcodec/dca.c| 9 +
> libavcodec/dca.h| 3 +++
> libavcodec/dca_exss.c | 1 -
> libavcodec/dca_parser.c | 1 -
> libavcodec/dcadata.c| 9 ---
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
Enabling CUDA support adds some extremely useful features but it also
adds hard runtime dependency on NVidia driver. This commit removes that
dependency; driver library would be loaded when required.
This allows to use same CUDA-enabled FFMpeg build on machines with and
without NVidia cards.
CUDA
In ffserver.c:build_feed_streams(), the streams pointer is only
correctly reset before deallocation when there is no error.
This may cause ffserver to crash, because stream lives in static
memory, not the heap.
The patch duplicates the behaviour of the non-error case.
>From 00c9203f0349dbae6e701
On 5/18/2016 5:33 PM, Paul B Mahol wrote:
> Hi,
>
> I want to propose to have an FFmpeg IRC meeting on
> the Saturday of the next week, Saturday May 28,
> UTC 17.
>
> Candidate topics of the day:
> - Code of Conduct and policy around it
> - technical development issues
> - misc topics
>
> Fee
On Thu, May 26, 2016, at 12:43 PM, James Almer wrote:
>
> This has gotten Clement's explicit confirmation and Michael's implicit
> after eight days. With mine now that'd be three.
> We're only two days away from the proposed date. If nobody else confirms,
> maybe we should postpone it while we poke
On 5/26/16, James Almer wrote:
> On 5/18/2016 5:33 PM, Paul B Mahol wrote:
>> Hi,
>>
>> I want to propose to have an FFmpeg IRC meeting on
>> the Saturday of the next week, Saturday May 28,
>> UTC 17.
>>
>> Candidate topics of the day:
>> - Code of Conduct and policy around it
>> - technical dev
On 5/26/16, Lou Logan wrote:
> On Thu, May 26, 2016, at 12:43 PM, James Almer wrote:
>>
>> This has gotten Clement's explicit confirmation and Michael's implicit
>> after eight days. With mine now that'd be three.
>> We're only two days away from the proposed date. If nobody else confirms,
>> mayb
On Thu, May 26, 2016 at 08:29:56PM +0200, Gregor Riepl wrote:
> In ffserver.c:build_feed_streams(), the streams pointer is only
> correctly reset before deallocation when there is no error.
>
> This may cause ffserver to crash, because stream lives in static
> memory, not the heap.
>
> The patch
On Thu, May 26, 2016 at 10:48 PM, Paul B Mahol wrote:
> On 5/26/16, James Almer wrote:
>> On 5/18/2016 5:33 PM, Paul B Mahol wrote:
>>> Hi,
>>>
>>> I want to propose to have an FFmpeg IRC meeting on
>>> the Saturday of the next week, Saturday May 28,
>>> UTC 17.
>>>
>>> Candidate topics of the da
On 5/26/2016 7:56 PM, Hendrik Leppkes wrote:
> On Thu, May 26, 2016 at 10:48 PM, Paul B Mahol wrote:
>> On 5/26/16, James Almer wrote:
>>> On 5/18/2016 5:33 PM, Paul B Mahol wrote:
Hi,
I want to propose to have an FFmpeg IRC meeting on
the Saturday of the next week, Saturday M
On Wed, May 25, 2016 at 02:18:38PM -0400, Ronald S. Bultje wrote:
> Hi,
>
> On Wed, May 25, 2016 at 1:24 PM, James Almer wrote:
>
> > On 5/25/2016 1:56 PM, Jon Toohill wrote:
> > > ---
> > > libavformat/mp3dec.c | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/libavformat/
On 5/26/2016 11:05 PM, Michael Niedermayer wrote:
> On Wed, May 25, 2016 at 02:18:38PM -0400, Ronald S. Bultje wrote:
>> Hi,
>>
>> On Wed, May 25, 2016 at 1:24 PM, James Almer wrote:
>>
>>> On 5/25/2016 1:56 PM, Jon Toohill wrote:
---
libavformat/mp3dec.c | 2 ++
1 file changed, 2
On Wed, May 25, 2016 at 09:56:59AM -0700, Jon Toohill wrote:
> ---
> libavformat/mp3dec.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
> index 3725d67..192f5ef 100644
> --- a/libavformat/mp3dec.c
> +++ b/libavformat/mp3dec.c
> @@ -234,6 +2
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
21 matches
Mail list logo
