On 09.03.2015, at 07:38, Rainer Hochecker wrote:
> Reimar Döffinger gmx.de> writes:
>
>>
>> Any reason to believe this patch causes it?
>> Because I can't see how it would.
>> Maybe it's just a bug with DXVA and multithreading in the HEVC code?
>> Can you provide some more information like a st
rongyan foxmail.com> writes:
> x264 is the external library of FFmpeg. If I want to
> contribute to it, should I contribute to VideoLan directly?
Please see https://mailman.videolan.org/listinfo/x264-devel
Carl Eugen
___
ffmpeg-devel mailing list
ff
Michael Niedermayer gmx.at> writes:
> > The mpegvideo decoder sets intra_dc_precision since forever (!).
> >
> > Please comment, Carl Eugen
>
> LGTM
Patch applied.
Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://f
Michael Niedermayer gmx.at> writes:
> > Attached patch makes the behaviour of ffv1 using gprp
> > more similar to yuv for >8 bit.
> > Reported by Christoph Gerstbauer .
> >
> > Please comment, Carl Eugen
>
> LGTM
Patch applied.
Thank you, Carl Eugen
_
On 09.03.2015 02:45, Michael Niedermayer wrote:
On Mon, Mar 09, 2015 at 12:02:55AM +0100, Andreas Cadhalpun wrote:
Hi,
attached patch fixes 'Conditional jump or move depends on
uninitialized variables' valgrind warnings.
Best regards,
Andreas
ffmdec.c |2 +-
1 file changed, 1 inserti
Michael Niedermayer gmx.at> writes:
> > ffmpeg.texi |4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> > 3e2ef09ab39df5eb9d54af4ddef424b8b1cc7c26 patchimg2framerate.diff
>
> probably ok
Patch applied.
Thank you, Carl Eugen
___
ffmp
Carl Eugen Hoyos ag.or.at> writes:
> A user reported that the Solaris libc detection has
> never worked on all installations.
This should have been "... since 3a5cbc91".
> Attached patch forces the definition of __EXTENSIONS__
> which is needed for network compilation.
>
> This fixes the fol
Carl Eugen Hoyos ag.or.at> writes:
> I believe attached patch fixes ticket #3268 in some cases.
Ping, should one of the patches get applied?
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-de
Carl Eugen Hoyos ag.or.at> writes:
> -If both duration and nb_frames are specified, duration is used.
> Default is 0.
> +If both duration and nb_frames are specified, duration is used.
> Default is 0
> +(nb_frames is used by default).
I pushed this patch as I believe it improves the documentat
Paul B Mahol gmail.com> writes:
> >> Attached patch sets bits_per_raw_sample when decoding hqx.
> >
> > I will push this if nobody objects.
>
> How do you know this is correct?
I had the feeling the current code cannot be correct
but please consider the patch dropped.
Carl Eugen
On 09.03.2015 03:13, Michael Niedermayer wrote:
On Mon, Mar 09, 2015 at 12:04:13AM +0100, Andreas Cadhalpun wrote:
Hi,
some broken files can lead to an endless resync loop, which is
avoided by attached patch.
Best regards,
Andreas
ffmdec.c | 10 +-
1 file changed, 9 insertions(
On 09.03.2015 03:42, Michael Niedermayer wrote:
allowing access to the size but not the extradata itself is not useful
and could lead to potential problems if writing happens through this field
Signed-off-by: Michael Niedermayer
---
libavcodec/options_table.h |1 -
1 file changed, 1 dele
On 09.03.2015 03:46, Michael Niedermayer wrote:
On Mon, Mar 09, 2015 at 12:05:31AM +0100, Andreas Cadhalpun wrote:
Hi,
I'm not sure what the purpose of this avio_seek was, but it can
result in an endless loop. Maybe it always does.
ffm files can be written to and read at the same time, they c
dont forget you can check other open source projects
(videolan, virtualdub etc) and maybe copy how they do dshow video
capture.
There is also this library:
https://github.com/jp9000/libdshowcapture
jp9000 is the author of OBS, libdshowcapture is directly based on its
Video-Device-Capture. It
On 09.03.2015 03:56, Michael Niedermayer wrote:
On Mon, Mar 09, 2015 at 12:05:01AM +0100, Andreas Cadhalpun wrote:
Hi,
if AVERROR(EAGAIN) is returned from ffm_is_avail_data it always
causes an infinite EAGAIN loop.
it should only loop until more data is written into the ffm file
(this of cour
On 09.03.2015 03:59, Michael Niedermayer wrote:
is anything using a 0/n timebase ?
I don't think so.
if not i would extend this to also disallow 0/n
OK, new patch attached.
Best regards,
Andreas
>From be6482e2ecf8ea109e9d18f578dc5a17085dde43 Mon Sep 17 00:00:00 2001
From: Andreas Cadhalpu
On 09.03.2015 04:56, Michael Niedermayer wrote:
On Mon, Mar 09, 2015 at 12:03:11AM +0100, Andreas Cadhalpun wrote:
Hi,
attached patch fixes potential crashes.
Best regards,
Andreas
ffmdec.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
fa490a9bc11b6c8748f707fabf79d
On 09.03.2015 10:53, Lukasz Marek wrote:
In fact this is a bit wrong. COMM is guaranteed unless malformed file is
parsed. These variables are dedicated to detect doubled sections. This
patch allows them to occur twice in that case. So they should be
initialized to 0.
This patch doesn't change a
On 9 March 2015 at 12:41, Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:
> On 09.03.2015 10:53, Lukasz Marek wrote:
>
>> In fact this is a bit wrong. COMM is guaranteed unless malformed file is
>> parsed. These variables are dedicated to detect doubled sections. This
>> patch allows
On 3/8/15, compn wrote:
> On Sat, 7 Mar 2015 20:24:16 +0200
> Ilinca Andrei wrote:
>
>>Hello!
>
> welcome!
>
>>
>>*Why directshow digital video capture ?*
>>
>>Simply because It sounds really interesting and entertaining.
>> I have some experience using Matlab and Simulink
On 09.03.2015 13:20, Lukasz Marek wrote:
BTW, did you produced this malformed file using ffmpeg tools or just
prevent theoretical case?
I fuzzed a file created by ffmpeg.
Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
ht
On 9 March 2015 at 12:19, Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:
> On 09.03.2015 03:42, Michael Niedermayer wrote:
>
>> allowing access to the size but not the extradata itself is not useful
>> and could lead to potential problems if writing happens through this field
>>
>> S
On Mon, Mar 9, 2015 at 7:38 AM, Rainer Hochecker wrote:
> Reimar Döffinger gmx.de> writes:
>
>>
>> Any reason to believe this patch causes it?
>> Because I can't see how it would.
>> Maybe it's just a bug with DXVA and multithreading in the HEVC code?
>> Can you provide some more information like
On Mon, Mar 09, 2015 at 12:34:54PM +0100, Andreas Cadhalpun wrote:
> On 09.03.2015 03:59, Michael Niedermayer wrote:
> >is anything using a 0/n timebase ?
>
> I don't think so.
>
> >if not i would extend this to also disallow 0/n
>
> OK, new patch attached.
>
> Best regards,
> Andreas
>
> ff
On 9 March 2015 13:34:24 CET, Hendrik Leppkes wrote:
>On Mon, Mar 9, 2015 at 7:38 AM, Rainer Hochecker
> wrote:
>> Reimar Döffinger gmx.de> writes:
>>
>>>
>>> Any reason to believe this patch causes it?
>>> Because I can't see how it would.
>>> Maybe it's just a bug with DXVA and multithreading i
On Mon, Mar 09, 2015 at 12:17:38PM +0100, Andreas Cadhalpun wrote:
> On 09.03.2015 03:13, Michael Niedermayer wrote:
> >On Mon, Mar 09, 2015 at 12:04:13AM +0100, Andreas Cadhalpun wrote:
> >>Hi,
> >>
> >>some broken files can lead to an endless resync loop, which is
> >>avoided by attached patch.
>
On Mon, Mar 09, 2015 at 12:33:38PM +0100, Andreas Cadhalpun wrote:
> On 09.03.2015 03:56, Michael Niedermayer wrote:
> >On Mon, Mar 09, 2015 at 12:05:01AM +0100, Andreas Cadhalpun wrote:
> >>Hi,
> >>
> >>if AVERROR(EAGAIN) is returned from ffm_is_avail_data it always
> >>causes an infinite EAGAIN l
On Mon, Mar 09, 2015 at 12:27:15PM +0100, Andreas Cadhalpun wrote:
> On 09.03.2015 03:46, Michael Niedermayer wrote:
> >On Mon, Mar 09, 2015 at 12:05:31AM +0100, Andreas Cadhalpun wrote:
> >>Hi,
> >>
> >>I'm not sure what the purpose of this avio_seek was, but it can
> >>result in an endless loop.
On Mon, Mar 09, 2015 at 01:27:58PM +0100, Lukasz Marek wrote:
> On 9 March 2015 at 12:19, Andreas Cadhalpun <
> andreas.cadhal...@googlemail.com> wrote:
>
> > On 09.03.2015 03:42, Michael Niedermayer wrote:
> >
> >> allowing access to the size but not the extradata itself is not useful
> >> and co
On Mon, Mar 09, 2015 at 09:14:39AM +0530, arwa arif wrote:
> I have attached the patch, changing the configuration file.
> configure |3 +++
> 1 file changed, 3 insertions(+)
> 9d052515d6a58fba1d55930e8ca7c9645b1a2e89
> 0001-Add-dependencies-to-configure-file-for-vf_fftfilt.patch
> From 82e
On Sun, Mar 08, 2015 at 10:57:54AM +0100, Nicolas George wrote:
> L'octidi 18 ventôse, an CCXXIII, Clement Boesch a écrit :
> > Try adding tags with no text maybe. You may also try ASS drawing mode, but
> > FFmpeg probably doesn't do cray stuff about it.
>
> I tried various combinations, including
On 09.03.2015 13:59, Michael Niedermayer wrote:
i was thinking more about limiting the backward seek before resync
to the last resync position +1 if there was a previous resync
so that resync which moves forward could not end before. This would
avoid the failure and allow the demuxer to continue,
I was going through the code, and I realized that I have made a mistake. I
have corrected the code, and attached the corresponding patch.
From 2ebd299b55a34914d5549f21d264e8cb7f5f605d Mon Sep 17 00:00:00 2001
From: Arwa Arif
Date: Mon, 9 Mar 2015 19:50:32 +0530
Subject: [PATCH] Fix the wrong parsi
On Mon, Mar 9, 2015 at 1:50 PM, Reimar Döffinger
wrote:
> On 9 March 2015 13:34:24 CET, Hendrik Leppkes wrote:
>>On Mon, Mar 9, 2015 at 7:38 AM, Rainer Hochecker
>> wrote:
>>> Reimar Döffinger gmx.de> writes:
>>>
Any reason to believe this patch causes it?
Because I can't see how
On Mon, Mar 09, 2015 at 03:14:50PM +0100, Andreas Cadhalpun wrote:
> On 09.03.2015 13:59, Michael Niedermayer wrote:
> >i was thinking more about limiting the backward seek before resync
> >to the last resync position +1 if there was a previous resync
> >so that resync which moves forward could not
On Mon, Mar 9, 2015 at 3:28 PM, Hendrik Leppkes wrote:
> On Mon, Mar 9, 2015 at 1:50 PM, Reimar Döffinger
> wrote:
>> On 9 March 2015 13:34:24 CET, Hendrik Leppkes wrote:
>>>On Mon, Mar 9, 2015 at 7:38 AM, Rainer Hochecker
>>> wrote:
Reimar Döffinger gmx.de> writes:
>
> Any re
On Sun, Mar 08, 2015 at 11:07:33PM -0300, Claudio Freire wrote:
> On Sun, Mar 8, 2015 at 11:06 PM, Claudio Freire
> wrote:
> > On Sun, Mar 8, 2015 at 8:23 AM, Michael Niedermayer
> > wrote:
> >> i think its better to leave fuzz at a small value otherwise we
> >> would forget to update the targe
On Sun, Mar 08, 2015 at 11:07:33PM -0300, Claudio Freire wrote:
> On Sun, Mar 8, 2015 at 11:06 PM, Claudio Freire
> wrote:
> > On Sun, Mar 8, 2015 at 8:23 AM, Michael Niedermayer
> > wrote:
> >> i think its better to leave fuzz at a small value otherwise we
> >> would forget to update the targe
On Mon, Mar 09, 2015 at 04:41:05PM +0100, Michael Niedermayer wrote:
> On Sun, Mar 08, 2015 at 11:07:33PM -0300, Claudio Freire wrote:
> > On Sun, Mar 8, 2015 at 11:06 PM, Claudio Freire
> > wrote:
> > > On Sun, Mar 8, 2015 at 8:23 AM, Michael Niedermayer
> > > wrote:
> > >> i think its better
On Mon, Mar 9, 2015 at 12:41 PM, Michael Niedermayer wrote:
> On Sun, Mar 08, 2015 at 11:07:33PM -0300, Claudio Freire wrote:
>> On Sun, Mar 8, 2015 at 11:06 PM, Claudio Freire
>> wrote:
>> > On Sun, Mar 8, 2015 at 8:23 AM, Michael Niedermayer
>> > wrote:
>> >> i think its better to leave fuzz
On Mon, Mar 09, 2015 at 04:53:52PM +0100, Michael Niedermayer wrote:
> On Mon, Mar 09, 2015 at 04:41:05PM +0100, Michael Niedermayer wrote:
> > On Sun, Mar 08, 2015 at 11:07:33PM -0300, Claudio Freire wrote:
> > > On Sun, Mar 8, 2015 at 11:06 PM, Claudio Freire
> > > wrote:
> > > > On Sun, Mar 8,
Thank you very much for your kind replies and advices compn, Timo and
Roger.
I am at the very beginning of the journey , I've never worked with Dshow
before but I'm very excited to learn and develop. I will look through all
the materials given and start doing stuff as soon as possible.
On Mon, Ma
On Mon, Mar 09, 2015 at 12:55:43PM -0300, Claudio Freire wrote:
> On Mon, Mar 9, 2015 at 12:41 PM, Michael Niedermayer wrote:
> > On Sun, Mar 08, 2015 at 11:07:33PM -0300, Claudio Freire wrote:
> >> On Sun, Mar 8, 2015 at 11:06 PM, Claudio Freire
> >> wrote:
> >> > On Sun, Mar 8, 2015 at 8:23 AM
On Mon, Mar 9, 2015 at 1:05 PM, Michael Niedermayer wrote:
>> Head is still using a butterworth filter for the lowpass IIRC. That
>> could very well be both platform and sample rate specific.
>>
>> Sadly, I cannot test mips, but commenting the lowpass could yield
>> useful results.
>
> what exact
On 9 March 2015 at 14:28, Michael Niedermayer wrote:
> On Mon, Mar 09, 2015 at 01:27:58PM +0100, Lukasz Marek wrote:
> > On 9 March 2015 at 12:19, Andreas Cadhalpun <
> > andreas.cadhal...@googlemail.com> wrote:
> >
> > > On 09.03.2015 03:42, Michael Niedermayer wrote:
> > >
> > >> allowing acces
On Mon, Mar 09, 2015 at 01:16:56PM -0300, Claudio Freire wrote:
> On Mon, Mar 9, 2015 at 1:05 PM, Michael Niedermayer wrote:
> >> Head is still using a butterworth filter for the lowpass IIRC. That
> >> could very well be both platform and sample rate specific.
> >>
> >> Sadly, I cannot test mips,
On Mon, Mar 9, 2015 at 1:26 PM, Michael Niedermayer wrote:
> doesnt help
> but
> this does:
> -fate-aac-s7350-encode: CMD = enc_dec_pcm adts wav s16le $(REF) -strict -2
> -c:a aac -b:a 256k
> +fate-aac-s7350-encode: CMD = enc_dec_pcm adts wav s16le $(REF) -strict -2
> -c:a aac -b:a 88k
>
> this
Le nonidi 19 ventôse, an CCXXIII, Michael Niedermayer a écrit :
> you miss the problem, this is a demuxer side problem,
> a attacker can at least crash your application no muxer side change
> can fix this, the attacker has his own self written muxer that
> produces a mallicious bitstream
(Unrelate
On Mon, Mar 09, 2015 at 01:31:26PM -0300, Claudio Freire wrote:
> On Mon, Mar 9, 2015 at 1:26 PM, Michael Niedermayer wrote:
> > doesnt help
> > but
> > this does:
> > -fate-aac-s7350-encode: CMD = enc_dec_pcm adts wav s16le $(REF) -strict -2
> > -c:a aac -b:a 256k
> > +fate-aac-s7350-encode: CMD
On Mon, Mar 09, 2015 at 05:33:46PM +0100, Nicolas George wrote:
> Le nonidi 19 ventôse, an CCXXIII, Michael Niedermayer a écrit :
> > you miss the problem, this is a demuxer side problem,
> > a attacker can at least crash your application no muxer side change
> > can fix this, the attacker has his
On Mon, Mar 09, 2015 at 03:42:00AM +0100, Michael Niedermayer wrote:
> allowing access to the size but not the extradata itself is not useful
> and could lead to potential problems if writing happens through this field
>
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/options_table.h |
在 2015/3/8 20:14, Michael Niedermayer 写道:
> On Sat, Mar 07, 2015 at 11:47:08PM +0800, zhaoxiu.zeng wrote:
>> From ab12e3081ba987c2e05d819be97cde96952f1c2a Mon Sep 17 00:00:00 2001
>> From: Zeng Zhaoxiu
>> Date: Sat, 7 Mar 2015 23:29:46 +0800
>> Subject: [PATCH 1/1] avcodec/hevc_parser: use avpriv_
On Tue, Mar 10, 2015 at 12:57:57AM +0800, zhaoxiu.zeng wrote:
> 在 2015/3/8 20:14, Michael Niedermayer 写道:
> > On Sat, Mar 07, 2015 at 11:47:08PM +0800, zhaoxiu.zeng wrote:
> >> From ab12e3081ba987c2e05d819be97cde96952f1c2a Mon Sep 17 00:00:00 2001
> >> From: Zeng Zhaoxiu
> >> Date: Sat, 7 Mar 2015
---
libavfilter/vf_colormatrix.c | 146 ---
1 file changed, 95 insertions(+), 51 deletions(-)
diff --git a/libavfilter/vf_colormatrix.c b/libavfilter/vf_colormatrix.c
index daba16e..8514684 100644
--- a/libavfilter/vf_colormatrix.c
+++ b/libavfilter/vf_colo
On 9 March 2015 15:28:48 CET, Hendrik Leppkes wrote:
>On Mon, Mar 9, 2015 at 1:50 PM, Reimar Döffinger
> wrote:
>> On 9 March 2015 13:34:24 CET, Hendrik Leppkes
>wrote:
>>>On Mon, Mar 9, 2015 at 7:38 AM, Rainer Hochecker
>>> wrote:
Reimar Döffinger gmx.de> writes:
>
> Any reaso
On Mon, Mar 9, 2015 at 1:38 PM, Michael Niedermayer wrote:
> On Mon, Mar 09, 2015 at 01:31:26PM -0300, Claudio Freire wrote:
>> On Mon, Mar 9, 2015 at 1:26 PM, Michael Niedermayer wrote:
>> > doesnt help
>> > but
>> > this does:
>> > -fate-aac-s7350-encode: CMD = enc_dec_pcm adts wav s16le $(REF)
Hi,
trying to encode roqvideo into asf currently crashes, because enc->avctx
is not set in roq_encode_end, which calls:
av_frame_free(&enc->avctx->coded_frame);
Best regards,
Andreas
>From 4cd715ab02e25948f695c0a4186dab4b864a5ce3 Mon Sep 17 00:00:00 2001
From: Andreas Cadhalpun
Date: Mon,
Hi,
asfenc leaks asf->index_ptr if asf_write_header1 fails.
Attached patch fixes this.
Best regards,
Andreas
>From cd1ec21196f8f8fb0a7f4a9f42b9811ccf8109d7 Mon Sep 17 00:00:00 2001
From: Andreas Cadhalpun
Date: Mon, 9 Mar 2015 19:31:39 +0100
Subject: [PATCH] asfenc: fix leaking asf->index_ptr o
L'octidi 18 ventôse, an CCXXIII, Thomas Volkert a écrit :
> We could add "const char *av_get_audio_service_name(enum AVAudioServiceType
> type)" to avutil.h and use this function both in avformat and avfilter.
In the short term, that would probably be the best (although I would
slightly prefer if
On Fri, Feb 20, 2015 at 5:41 AM, Stefano Sabatini
wrote:
> On date Thursday 2015-02-19 17:13:15 +0530, Arwa Arif encoded:
> > Updated the patch.
>
> > From 66a8c9d03995c9e7c6ccc05fb9b20756f51c17f4 Mon Sep 17 00:00:00 2001
> > From: Arwa Arif
> > Date: Thu, 19 Feb 2015 01:26:44 +0530
> > Subject:
Hi,
trying to encode e.g. codec bmp with format rtp_mpegts crashes, because
the avformat_write_header failure isn't handled correctly.
Attached is a patch fixing this.
Best regards,
Andreas
>From c0ba3afc828bc6255a1bcf0feb34af3caa892572 Mon Sep 17 00:00:00 2001
From: Andreas Cadhalpun
Date: M
On Tue, Mar 10, 2015 at 12:57:57AM +0800, zhaoxiu.zeng wrote:
> 在 2015/3/8 20:14, Michael Niedermayer 写道:
> > On Sat, Mar 07, 2015 at 11:47:08PM +0800, zhaoxiu.zeng wrote:
> >> From ab12e3081ba987c2e05d819be97cde96952f1c2a Mon Sep 17 00:00:00 2001
> >> From: Zeng Zhaoxiu
> >> Date: Sat, 7 Mar 2015
On Mon, Mar 09, 2015 at 07:31:27PM +0100, Andreas Cadhalpun wrote:
> Hi,
>
> trying to encode roqvideo into asf currently crashes, because
> enc->avctx is not set in roq_encode_end, which calls:
> av_frame_free(&enc->avctx->coded_frame);
>
> Best regards,
> Andreas
> roqvideoenc.c |2 ++
On Sun, Mar 08, 2015 at 10:32:03PM +0100, Michael Niedermayer wrote:
> On Sat, Mar 07, 2015 at 11:44:10PM +0800, zhaoxiu.zeng wrote:
> > From 47c997fa0623ab94a7a93b2d2e4cc4fa64c85d5f Mon Sep 17 00:00:00 2001
> > From: Zeng Zhaoxiu
> > Date: Sat, 7 Mar 2015 23:26:42 +0800
> > Subject: [PATCH 1/1] a
On Mon, Mar 09, 2015 at 10:01:20PM +0100, Reimar Döffinger wrote:
> On Sun, Mar 08, 2015 at 10:32:03PM +0100, Michael Niedermayer wrote:
> > On Sat, Mar 07, 2015 at 11:44:10PM +0800, zhaoxiu.zeng wrote:
> > > From 47c997fa0623ab94a7a93b2d2e4cc4fa64c85d5f Mon Sep 17 00:00:00 2001
> > > From: Zeng Zh
On Mon, Mar 09, 2015 at 10:05:03PM +0100, Clément Bœsch wrote:
> On Mon, Mar 09, 2015 at 10:01:20PM +0100, Reimar Döffinger wrote:
> > On Sun, Mar 08, 2015 at 10:32:03PM +0100, Michael Niedermayer wrote:
> > > On Sat, Mar 07, 2015 at 11:44:10PM +0800, zhaoxiu.zeng wrote:
> > > > From 47c997fa0623ab
On Mon, Mar 09, 2015 at 07:37:56PM +0100, Andreas Cadhalpun wrote:
> Hi,
>
> asfenc leaks asf->index_ptr if asf_write_header1 fails.
> Attached patch fixes this.
>
> Best regards,
> Andreas
> asfenc.c |1 +
> 1 file changed, 1 insertion(+)
> bd66fe12def4c8cd582c02d65eb85caa8306ceb7
> 0001
In attach a patch proposal, in order to make easier parse result of ebur128
filter by external scripts
command line for testing :
ffmpeg -i aFile.wav -filter ebur128=peak=true+sample -f null -
Before patch, summary look like this :
[Parsed_ebur128_0 @ 0x7fe8b0d0] Summary:
Integrated loudne
Hi
On Mon, Mar 09, 2015 at 10:56:18AM -0700, Yayoi wrote:
> ---
> libavfilter/vf_colormatrix.c | 146
> ---
> 1 file changed, 95 insertions(+), 51 deletions(-)
[...]
> @@ -372,12 +402,26 @@ static int filter_frame(AVFilterLink *link, AVFrame *in)
>
>
On Mon, Mar 09, 2015 at 09:49:04PM +0100, Reimar Döffinger wrote:
> On Tue, Mar 10, 2015 at 12:57:57AM +0800, zhaoxiu.zeng wrote:
> > 在 2015/3/8 20:14, Michael Niedermayer 写道:
> > > On Sat, Mar 07, 2015 at 11:47:08PM +0800, zhaoxiu.zeng wrote:
> > >> From ab12e3081ba987c2e05d819be97cde96952f1c2a Mo
On Mon, Mar 09, 2015 at 10:28:43PM +0100, Martin Vignali wrote:
> In attach a patch proposal, in order to make easier parse result of ebur128
> filter by external scripts
>
> command line for testing :
> ffmpeg -i aFile.wav -filter ebur128=peak=true+sample -f null -
>
> Before patch, summary look
On Mon, Mar 09, 2015 at 06:38:18AM +, Rainer Hochecker wrote:
> Reimar Döffinger gmx.de> writes:
>
> >
> > Any reason to believe this patch causes it?
> > Because I can't see how it would.
> > Maybe it's just a bug with DXVA and multithreading in the HEVC code?
> > Can you provide some more
On Thu, Feb 26, 2015 at 04:28:54PM +0100, Carl Eugen Hoyos wrote:
> On Thursday 26 February 2015 03:31:39 pm Derek Buitenhuis wrote:
> > On 2/26/2015 2:09 PM, Carl Eugen Hoyos wrote:
> > > +snprintf(header, len + 3, "%s\r\n", s->headers);
> >
> > This does not necessarily work on window
Hi Martin,
On 09.03.2015 22:08, Martin Storsjö wrote:
Thanks for the patch, and thanks for finding the issue.
You're quite correct that the error handling here is broken, but I'm not
able to reproduce it by trying to mux bmp into this muxer - that
actually succeeds.
I guess I'm using the wron
Hi,
I'm currently working on* dshow digital video capture* and it's really
interesting, even if I' m making slow progress, as I' m not familiar with
"graphstudionext" and DShow principles .
I decided to apply for another project as well, the *MPEG-4 ALS encoder**
project, *for two reasons, as sug
On 09.03.2015 22:15, Martin Storsjö wrote:
This fixes a typo from 8e32b1f096.
---
libavformat/rtpenc_mpegts.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/rtpenc_mpegts.c b/libavformat/rtpenc_mpegts.c
index 8ad446b..8ced6a9 100644
--- a/libavformat/rtpenc_mpe
On 09.03.2015 22:15, Martin Storsjö wrote:
By making sure we at each time only have one pointer set, either a
local variable or one in the context, we avoid potential double frees
in the cleanup routines. If chain->rtp_ctx is set, it is closed by
calling avformat_write_trailer, but that shouldn't
On Thu, Feb 26, 2015 at 05:23:52PM +0100, Carl Eugen Hoyos wrote:
> Hi!
>
> A user reported that the Solaris libc detection has never worked on all
> installations. Attached patch forces the definition of __EXTENSIONS__
> which is needed for network compilation.
>
> This fixes the following err
Hi Michael,
I did the fix and verified compilation and run.
Confirmed it works.
Here is the patch
---
libavutil/opencl.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavutil/opencl.c b/libavutil/opencl.c
index 36cb6fe..2df5653 100644
--- a/libavutil/opencl.c
+++ b/libavutil/opencl
---
fixed the issue and cleaned up the code a bit
---
libavfilter/vf_colormatrix.c | 146 +++
1 file changed, 92 insertions(+), 54 deletions(-)
diff --git a/libavfilter/vf_colormatrix.c b/libavfilter/vf_colormatrix.c
index daba16e..d0839cc 100644
--- a/li
On Thu, Mar 05, 2015 at 10:59:11AM -0800, Mark Reid wrote:
> ---
> libavformat/mxfenc.c | 97
> +--
> tests/ref/lavf/mxf| 6 +--
> tests/ref/lavf/mxf_d10| 2 +-
> tests/ref/lavf/mxf_opatom | 2 +-
> 4 files changed, 91 insertions(+),
On Mon, Mar 9, 2015 at 11:06 PM, Michael Niedermayer wrote:
> On Mon, Mar 09, 2015 at 06:38:18AM +, Rainer Hochecker wrote:
>> Reimar Döffinger gmx.de> writes:
>>
>> >
>> > Any reason to believe this patch causes it?
>> > Because I can't see how it would.
>> > Maybe it's just a bug with DXVA
On Mon, Mar 9, 2015 at 4:34 PM Yayoi wrote:
> @@ -372,12 +396,26 @@ static int filter_frame(AVFilterLink *link, AVFrame
> *in)
>
> calc_coefficients(ctx);
>
> +ThreadData td = {
> +.src = in,
> +.dst = out,
> +.c2 = color->yuv_convert[color->mode][0][1],
> +
On Mon, Mar 9, 2015 at 3:31 PM, Claudio Freire wrote:
> On Mon, Mar 9, 2015 at 1:38 PM, Michael Niedermayer wrote:
>> On Mon, Mar 09, 2015 at 01:31:26PM -0300, Claudio Freire wrote:
>>> On Mon, Mar 9, 2015 at 1:26 PM, Michael Niedermayer
>>> wrote:
>>> > doesnt help
>>> > but
>>> > this does:
>
---
separate a struct variable declaraion and assignment statements.
---
libavfilter/vf_colormatrix.c | 146 ---
1 file changed, 94 insertions(+), 52 deletions(-)
diff --git a/libavfilter/vf_colormatrix.c b/libavfilter/vf_colormatrix.c
index daba16e..f5835
Hendrik Leppkes gmail.com> writes:
>
> Just making the ff_thread_finish_setup call in hevc_frame_start
> conditional on !hwaccel should do what the other patches did.
> My code isn't setup to use this path, so someone that does should test
> it and send it.
>
> - Hendrik
>
86 matches
Mail list logo
