On Tue, Feb 2, 2016 at 6:20 PM Timothy Gu wrote:
> >
> > diracdsp_init.o should be part of OBJS, not YASM-OBJS.
>
> Done.
>
> >
> > While you're at it you could also change dirac_dwt in a similar
> > fashion.
>
> And done.
>
17:42 < jamrial> Timothy_Gu: yeah, seems ok. you'll have to rebase the d
On 2/5/2016 4:46 PM, James Almer wrote:
> Up to ~4 times faster on x86_64, ~8 times on x86_32 if compiling using x87 fp
> math.
>
> Signed-off-by: James Almer
> ---
> libavcodec/dcadsp.c | 3 +
> libavcodec/dcadsp.h | 1 +
> libavcodec/x86/Makefile | 4 +-
> libavco
On 02/06/2016 05:05 AM, Mats Peterson wrote:
This patch removes the monowhite switching code for 1 bpp raw AVI
without a palette. I don't see any reason to keep it, since it's
semantically incorrect to use monowhite for palettized data in my book,
it adds unnecessary noise to the code, and it's i
This patch removes the monowhite switching code for 1 bpp raw AVI
without a palette. I don't see any reason to keep it, since it's
semantically incorrect to use monowhite for palettized data in my book,
it adds unnecessary noise to the code, and it's inconsistent with the
rest of the code in FF
The functions are all private.
---
libavcodec/dirac_dwt.c | 12 ++--
libavcodec/dirac_dwt.h | 6 +++---
libavcodec/dirac_dwt_template.c | 10 +-
libavcodec/diracdec.c | 4 ++--
4 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/libavcodec
---
libavcodec/dirac_dwt.c | 13 ++---
libavcodec/dirac_dwt_template.c | 25 +
2 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/libavcodec/dirac_dwt.c b/libavcodec/dirac_dwt.c
index 732615c..7ccb310 100644
--- a/libavcodec/dirac_dwt.c
+++ b/
Output still looks a bit odd though
---
libavutil/pixdesc.c | 28
libavutil/pixfmt.h| 4
libswscale/input.c| 4
libswscale/swscale_unscaled.c | 3 +++
libswscale/utils.c| 6 ++
5 files changed, 45 inserti
On 2016-02-04 19:40, Paul B Mahol wrote:
> +#define FN_ENTRY(name) {#name, script_ ## name}
> +struct fn_entry {
> +const char *name;
> +int (*fn)(lua_State *L);
> +};
> +
> +static const struct fn_entry main_fns[] = {
> +FN_ENTRY(log),
> +FN_ENTRY(frame_count),
> +FN_ENTRY(fil
Michael Bradshaw gmail.com> writes:
> Attached patch fixes building ffmpeg on OS X with the following
> configuration: --disable-optimizations --disable-asm
Patch applied, I believe similar issues were observed in
the past.
Thank you, Carl Eugen
___
The UUID is based on http://www.adobe.com/devnet/xmp.html
The patch is made according to XMP SPECIFICATION PART 3 - STORAGE IN
FILES See Table 8
---
libavformat/mov.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index e2f107f
On 2016-02-05 21:20, Paul B Mahol wrote:
> diff --git a/cmdutils.c b/cmdutils.c
> index e0d2807..03a4836 100644
> --- a/cmdutils.c
> +++ b/cmdutils.c
> @@ -1625,7 +1625,7 @@ int show_filters(void *optctx, const char *opt, const
> char *arg)
>( i && (filter->flag
On Friday, February 5, 2016, Hendrik Leppkes wrote:
> On Fri, Feb 5, 2016 at 9:33 PM, Michael Bradshaw > wrote:
> > Hi,
> >
> > Attached patch fixes building ffmpeg on OS X with the following
> > configuration: --disable-optimizations --disable-asm
>
> > Without this patch the following error i
On 2/5/16, Chau Pham wrote:
> Dear Senior,
>
>
> I would like to ask something about ffplay.
>
>
> ffmpeg define AVMediaType in avutil.h with 5 type of media as below
>
>
> enum AVMediaType {
> AVMEDIA_TYPE_UNKNOWN = -1, ///< Usually treated as AVMEDIA_TYPE_DATA
> AVMEDIA_TYPE_VIDEO,
>
On Fri, Feb 5, 2016 at 9:31 PM, James Darnley wrote:
> Looks good to me but then I thought the old one did too so you probably
> want to wait for someone else to sign off too.
On Fri, Feb 5, 2016 at 10:00 PM, Ronald S. Bultje wrote:
> lgtm.
Applied, thanks.
_
Hi,
On Fri, Feb 5, 2016 at 3:20 PM, Henrik Gramner wrote:
> Using rNm and x86inc's stack allocation with a negative value at the same
> time isn't supported, and caused the original stack pointer to be clobbered
> when using a compiler that doesn't support stack alignment.
> ---
> libavcodec/x8
On Fri, 5 Feb 2016 21:45:00 +0100
Hendrik Leppkes wrote:
> On Fri, Feb 5, 2016 at 9:33 PM, Michael Bradshaw wrote:
> > Hi,
> >
> > Attached patch fixes building ffmpeg on OS X with the following
> > configuration: --disable-optimizations --disable-asm
> >
> > Without this patch the following err
On Thu, 4 Feb 2016, Michael Niedermayer wrote:
On Thu, Feb 04, 2016 at 01:57:59AM +0100, Marton Balint wrote:
Signed-off-by: Marton Balint
---
doc/muxers.texi | 20
libavformat/asf.h| 2 --
libavformat/asfenc.c | 41 +
3
On Thu, 4 Feb 2016, Michael Niedermayer wrote:
On Thu, Feb 04, 2016 at 01:57:58AM +0100, Marton Balint wrote:
Signed-off-by: Marton Balint
---
libavformat/asfenc.c | 24 +---
1 file changed, 17 insertions(+), 7 deletions(-)
LGTM
Thanks, pushed.
Regards,
Marton
On Fri, Feb 5, 2016 at 9:33 PM, Michael Bradshaw wrote:
> Hi,
>
> Attached patch fixes building ffmpeg on OS X with the following
> configuration: --disable-optimizations --disable-asm
>
> Without this patch the following error is observed:
>
> LD ffmpeg_g
> Undefined symbols for architecture x86_
On Fri, 5 Feb 2016, Michael Niedermayer wrote:
On Fri, Feb 05, 2016 at 12:10:53AM +0100, Marton Balint wrote:
On Thu, 4 Feb 2016, Michael Niedermayer wrote:
should be ok if tested with some other software, especially official
implemenattion from MS
I have tested it VLC, Windows Media ASF V
On Thu, 4 Feb 2016, Michael Niedermayer wrote:
On Thu, Feb 04, 2016 at 01:57:56AM +0100, Marton Balint wrote:
Signed-off-by: Marton Balint
---
libavformat/asfenc.c | 5 +
1 file changed, 5 insertions(+)
LGTM
Thanks, pushed.
Regards,
Marton
On Thu, 4 Feb 2016, Michael Niedermayer wrote:
On Thu, Feb 04, 2016 at 01:57:55AM +0100, Marton Balint wrote:
Signed-off-by: Marton Balint
---
libavformat/asfenc.c | 17 +
1 file changed, 17 insertions(+)
LGTM
Thanks, pushed.
Regards,
Marton
_
On 2016-02-05 21:20, Henrik Gramner wrote:
> Using rNm and x86inc's stack allocation with a negative value at the same
> time isn't supported, and caused the original stack pointer to be clobbered
> when using a compiler that doesn't support stack alignment.
> ---
> libavcodec/x86/h264_deblock.asm
Hi,
Attached patch fixes building ffmpeg on OS X with the following
configuration: --disable-optimizations --disable-asm
Without this patch the following error is observed:
LD ffmpeg_g
Undefined symbols for architecture x86_64:
"_ff_spatial_idwt_init_mmx", referenced from:
_ff_spatial_id
Using rNm and x86inc's stack allocation with a negative value at the same
time isn't supported, and caused the original stack pointer to be clobbered
when using a compiler that doesn't support stack alignment.
---
libavcodec/x86/h264_deblock.asm | 4 +++-
1 file changed, 3 insertions(+), 1 deletio
Hi,
patch attached.
From a928c1769d858cb778681b9cdc4933b86dab5c72 Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Fri, 5 Feb 2016 21:18:45 +0100
Subject: [PATCH] cmdutils: realign for some additional filters with very long
name
Signed-off-by: Paul B Mahol
---
cmdutils.c | 2 +-
1 file chang
Up to ~4 times faster on x86_64, ~8 times on x86_32 if compiling using x87 fp
math.
Signed-off-by: James Almer
---
libavcodec/dcadsp.c | 3 +
libavcodec/dcadsp.h | 1 +
libavcodec/x86/Makefile | 4 +-
libavcodec/x86/dcadsp.asm| 199 ++
On 2/5/2016 3:57 PM, Hendrik Leppkes wrote:
> On Fri, Feb 5, 2016 at 6:29 PM, James Almer wrote:
>> Up to ~4 times faster on x86_64, ~8 times on x86_32 if compiling using x87
>> fp math.
>>
>> Signed-off-by: James Almer
>
> Nice numbers! Any overall impact ideas?
Not much, apparently. With a 1
On Fri, Feb 5, 2016 at 6:29 PM, James Almer wrote:
> Up to ~4 times faster on x86_64, ~8 times on x86_32 if compiling using x87 fp
> math.
>
> Signed-off-by: James Almer
Nice numbers! Any overall impact ideas?
- Hendrik
___
ffmpeg-devel mailing list
On 2/5/16, James Almer wrote:
> Up to ~4 times faster on x86_64, ~8 times on x86_32 if compiling using x87
> fp math.
Nice!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Up to ~4 times faster on x86_64, ~8 times on x86_32 if compiling using x87 fp
math.
Signed-off-by: James Almer
---
libavcodec/dcadsp.c | 3 +
libavcodec/dcadsp.h | 1 +
libavcodec/x86/Makefile | 4 +-
libavcodec/x86/dcadsp.asm| 196 ++
Cosmetic change.
Signed-off-by: James Almer
---
libavcodec/dcadsp.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavcodec/dcadsp.c b/libavcodec/dcadsp.c
index 787d7b8..6acfe0b 100644
--- a/libavcodec/dcadsp.c
+++ b/libavcodec/dcadsp.c
@@ -84,13 +84,13 @@ static v
On Thu, Feb 4, 2016 at 7:27 PM Timothy Gu wrote:
> On Fri, Feb 05, 2016 at 02:58:14AM +0100, Michael Niedermayer wrote:
> > On Thu, Feb 04, 2016 at 05:10:16PM -0800, Timothy Gu wrote:
> > > As of now, the "top bar" James mentioned has been added, so fatebeta
> has full
> > > feature parity with t
On 02/05/2016 05:20 PM, Mats Peterson wrote:
One can't force 2 or 4 bpp, of cousre, so it's not possible to match 2
and 4 bpp input files exactly in the output. Then it's better to use
-vcodec copy (which currently works badly with nut, as I mentioned before).
And it works badly with AVI as wel
On 02/05/2016 05:18 PM, Mats Peterson wrote:
A better way would of course be to peek at the BITMAPINFOHEADER or video
sample description of the input file to determine how many bits per
pixel it uses, and match that in the output file, rather than trying to
guess from the number of colors in the
On 02/05/2016 05:04 PM, Mats Peterson wrote:
THE ENCODERS SHOULD BE THE ONES TO FIX. Hope I'm clear enough now.
And ideally, for example, the AVI muxer could use 1 bpp format if the
palette only contains 2 colors in spite of being pal8, and it should put
a 2-color palette in the output file, e
On 02/05/2016 05:00 PM, Mats Peterson wrote:
On 02/05/2016 04:58 PM, Mats Peterson wrote:
Alright, you were focusing on encoders here, yes, they aren't handled
here of course. I've only changed stuff to use pal8 correctly internally
on the *decoder* side for every codec. They should really be t
On 02/05/2016 04:58 PM, Mats Peterson wrote:
Alright, you were focusing on encoders here, yes, they aren't handled
here of course. I've only changed stuff to use pal8 correctly internally
on the *decoder* side for every codec. They should really be the ones
who fix, you're right.
Mats
THE EN
On 02/05/2016 04:58 PM, Mats Peterson wrote:
Alright, you were focusing on encoders here, yes, they aren't handled
here of course. I've only changed stuff to use pal8 correctly internally
on the *decoder* side for every codec. They should really be the ones
who fix, you're right.
The ones to f
On 02/05/2016 04:54 PM, Mats Peterson wrote:
On 02/05/2016 04:52 PM, Mats Peterson wrote:
patch applied, but i think theres more that needs fixing than pal8
in nut.
Most important is that the code which chooses the pixel format for
encoding end up choosing monowhite if the inut is PAL8 with 2 ma
On 02/05/2016 03:43 PM, Michael Niedermayer wrote:
On Fri, Feb 05, 2016 at 03:29:36AM +0100, Mats Peterson wrote:
On 02/05/2016 03:04 AM, Mats Peterson wrote:
Yes, it could (regarding stride being zero). Here's an updated patch.
If you think it's extremely important to use monow for the case
On 02/05/2016 04:52 PM, Mats Peterson wrote:
patch applied, but i think theres more that needs fixing than pal8
in nut.
Most important is that the code which chooses the pixel format for
encoding end up choosing monowhite if the inut is PAL8 with 2 matching
colors.
Then decoders could output PAL8
Hi,
On Fri, Feb 5, 2016 at 9:34 AM, Hendrik Leppkes wrote:
> On Fri, Feb 5, 2016 at 3:33 PM, Derek Buitenhuis
> wrote:
> > On 2/5/2016 2:19 PM, Michael Niedermayer wrote:
> >> because the code builds the header a few lines above, i assume
> >> the header we just build is correct
> >
> > Perhaps
On 2/5/16, Paul B Mahol wrote:
> Hi,
>
> patch attached.
>
Improved version attached.
From 985c54d508e2e086ddd72e8c6545a7209a771983 Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Fri, 5 Feb 2016 12:54:06 +0100
Subject: [PATCH] avfilter: add conditional filter
Signed-off-by: Paul B Mahol
---
On Fri, Feb 05, 2016 at 03:34:48PM +0100, Hendrik Leppkes wrote:
> On Fri, Feb 5, 2016 at 3:33 PM, Derek Buitenhuis
> wrote:
> > On 2/5/2016 2:19 PM, Michael Niedermayer wrote:
> >> because the code builds the header a few lines above, i assume
> >> the header we just build is correct
> >
> > Perh
On Fri, Feb 05, 2016 at 03:29:36AM +0100, Mats Peterson wrote:
> On 02/05/2016 03:04 AM, Mats Peterson wrote:
> >Yes, it could (regarding stride being zero). Here's an updated patch.
>
>
> If you think it's extremely important to use monow for the case of
> raw 1 bpp AVI without a palette, I can
Hi,
patch attached.
From 07e5e6ef03dc4c5705fe2b76859d8aa9caaaf518 Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Fri, 5 Feb 2016 12:54:06 +0100
Subject: [PATCH] avfilter: add conditional filter
Signed-off-by: Paul B Mahol
---
libavfilter/Makefile | 1 +
libavfilter/allfilters.c
On Fri, Feb 5, 2016 at 3:33 PM, Derek Buitenhuis
wrote:
> On 2/5/2016 2:19 PM, Michael Niedermayer wrote:
>> because the code builds the header a few lines above, i assume
>> the header we just build is correct
>
> Perhaps you could elaborate what CID1351343 is then, in the commit
> messages.
>
A
On 2/5/2016 2:19 PM, Michael Niedermayer wrote:
> because the code builds the header a few lines above, i assume
> the header we just build is correct
Perhaps you could elaborate what CID1351343 is then, in the commit
messages.
- Derek
___
ffmpeg-devel
On Fri, Feb 05, 2016 at 02:05:57PM +, Derek Buitenhuis wrote:
> On 2/3/2016 11:20 PM, Michael Niedermayer wrote:
> > +ret = avpriv_mpegaudio_decode_header(&mpah, header);
> > +av_assert0(ret >= 0);
>
> Why is this an assert and not an normal check?
because the code builds the
On 2/5/2016 5:30 AM, Hendrik Leppkes wrote:
> On Sun, Jan 31, 2016 at 9:41 PM, James Almer wrote:
>> @@ -67,23 +67,23 @@ typedef struct DCADSPContext {
>> int32_t **subband_samples_lo,
>> int32_t **subband_samples_hi,
>>
On 2/3/2016 11:20 PM, Michael Niedermayer wrote:
> +ret = avpriv_mpegaudio_decode_header(&mpah, header);
> +av_assert0(ret >= 0);
Why is this an assert and not an normal check?
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.or
On 2/4/2016 11:28 PM, Thierry Foucu wrote:
> The UUID is based on http://www.adobe.com/devnet/xmp.html
>
> The patch is made according to XMP SPECIFICATION PART 3 - STORAGE IN
> FILES See Table 8
> ---
> libavformat/mov.c | 28
> 1 file changed, 28 insertions(+)
[...
Le septidi 17 pluviôse, an CCXXIV, Paul B Mahol a écrit :
> From eab0be0e21fe312bf40c6330e493d2d0e9fdff2b Mon Sep 17 00:00:00 2001
> From: Paul B Mahol
> Date: Fri, 5 Feb 2016 09:11:55 +0100
> Subject: [PATCH] avfilter/split: support any channel count for asplit filter
>
> Signed-off-by: Paul B M
2016-01-30 10:44 GMT+01:00 Stefano Sabatini :
> On date Friday 2016-01-29 17:38:13 +0100, Martin Vignali encoded:
> > 2016-01-29 12:35 GMT+01:00 Stefano Sabatini :
> [...]
> > > +AVDictionaryEntry * tcr = av_dict_get(s->metadata, "timecode",
> > > NULL, 0);
> > > > +if (tcr){
> > >
Marton Balint passwd.hu> writes:
> On Thu, 4 Feb 2016, Carl Eugen Hoyos wrote:
>
> > Marton Balint passwd.hu> writes:
> >
> >> + item packet_size
> >> +Set the muxer packet size. By tuning this setting you may reduce data
> >> +fragmentation or muxer overhead depending on your source.
> >> Def
Kanthan Pillay gmail.com> writes:
> Tearing my hair out trying to decode the file “warehouse.mxf”
You could try to use --disable-decoder=jpeg2000 --enable-libopenjpeg
with latest libopenjpeg.
(More complicated workarounds probably exist.)
> The file is created by Maxx-2400HD video server from
Paul B Mahol gmail.com> writes:
> patch attached.
Please add a reference to ticket #5218 to the commit message.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Sun, Jan 31, 2016 at 9:41 PM, James Almer wrote:
> This is more consistent with the rest of the codebase
>
> Signed-off-by: James Almer
> ---
> libavcodec/dcadsp.c | 46 +++---
> libavcodec/dcadsp.h | 34 +-
> 2 files cha
Hi,
patch attached.
From eab0be0e21fe312bf40c6330e493d2d0e9fdff2b Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Fri, 5 Feb 2016 09:11:55 +0100
Subject: [PATCH] avfilter/split: support any channel count for asplit filter
Signed-off-by: Paul B Mahol
---
libavfilter/split.c | 28 +
60 matches
Mail list logo