On 02/02/2016 08:36 AM, Mats Peterson wrote:
On 02/02/2016 06:53 AM, Mats Peterson wrote:
On 02/02/2016 06:49 AM, Mats Peterson wrote:
I can tell you "-vcodec copy" doesn't work for nut without my patch
either. It seems nut only supports 24-bit RGB video, am I right? Just a
parenthesis.
Mats
On 02/02/2016 06:53 AM, Mats Peterson wrote:
On 02/02/2016 06:49 AM, Mats Peterson wrote:
I can tell you "-vcodec copy" doesn't work for nut without my patch
either. It seems nut only supports 24-bit RGB video, am I right? Just a
parenthesis.
Mats
The classical "MPlayer" syndrome, so to speak
On 02/02/2016 06:49 AM, Mats Peterson wrote:
I can tell you "-vcodec copy" doesn't work for nut without my patch
either. It seems nut only supports 24-bit RGB video, am I right? Just a
parenthesis.
Mats
The classical "MPlayer" syndrome, so to speak.
Mats
_
On 02/01/2016 04:26 PM, Michael Niedermayer wrote:
breaks converting to nut
example:
./ffmpeg -i test.avi -vcodec rawvideo test-new.nut
./ffplay test-new.nut
does not play
"-vcodec copy" instead of rawvideo also does not make it work
before the patch
./ffmpeg -i test.avi -vcodec rawvideo test.nu
On 02/02/2016 04:04 AM, Mats Peterson wrote:
It's like you're "clutching at straws" just to keep this little part of
FFmpeg (1 bpp AVI without a palette) working by using monow instead of
actually fixing the pal8 issues themselves. I'm not the one to do it at
least.
And until the pal8 issues a
On 2/2/2016 1:50 AM, Timothy Gu wrote:
> ---
> libavcodec/diracdsp.c | 5 +++--
> libavcodec/x86/Makefile| 2 +-
> libavcodec/x86/{diracdsp_yasm.asm => diracdsp.asm} | 0
> libavcodec/x86/{diracdsp_mmx.h => diracdsp.h} | 2 +-
> libavco
---
libavcodec/diracdsp.c | 5 +++--
libavcodec/x86/Makefile| 2 +-
libavcodec/x86/{diracdsp_yasm.asm => diracdsp.asm} | 0
libavcodec/x86/{diracdsp_mmx.h => diracdsp.h} | 2 +-
libavcodec/x86/{diracdsp_mmx.c => diracdsp_init.c} | 4 ++-
---
libavcodec/diracdsp.c | 5 +++--
libavcodec/x86/Makefile| 2 +-
libavcodec/x86/{diracdsp_yasm.asm => diracdsp.asm} | 0
libavcodec/x86/{diracdsp_mmx.h => diracdsp.h} | 2 +-
libavcodec/x86/{diracdsp_mmx.c => diracdsp_init.c} | 4 ++-
On 2/1/2016 8:55 PM, Hendrik Leppkes wrote:
> +define FATE_DCADEC_LOSSLESS_SUITE
> +FATE_DCADEC_LOSSLESS += fate-dca-$(1) fate-dca-$(1)-dmix_2
> fate-dca-$(1)-dmix_6
> +fate-dca-$(1): CMD = framemd5 -i
> $(TARGET_SAMPLES)/dts/dcadec-suite/$(1).dtshd -f $(2)
> +fate-dca-$(1)-dmix_2: CMD = framemd5
On Tue, Feb 02, 2016 at 12:45:32AM +0100, Andreas Cadhalpun wrote:
> On 30.01.2016 02:17, Michael Niedermayer wrote:
> > From: Michael Niedermayer
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavdevice/lavfi.c |7 ++-
> > libavformat/async.c |
On 02/02/2016 03:56 AM, Mats Peterson wrote:
Is the problem with pal8 not including a palette, and other issues, the
reason behind your choice to use monow for AVI whenever possible?
Because there is really no sensible reason to use it otherwise.
It's like you're "clutching at straws" just to
---
libavcodec/cinepakenc.c | 267 +---
1 file changed, 161 insertions(+), 106 deletions(-)
diff --git a/libavcodec/cinepakenc.c b/libavcodec/cinepakenc.c
index 2896fa1..06b06da 100644
--- a/libavcodec/cinepakenc.c
+++ b/libavcodec/cinepakenc.c
@@ -525,
---
libavdevice/xv.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/libavdevice/xv.c b/libavdevice/xv.c
index c19c15c..64cddeb 100644
--- a/libavdevice/xv.c
+++ b/libavdevice/xv.c
@@ -291,7 +291,8 @@ static int xv_repaint(AVFormatContext *s)
return 0;
}
---
libavdevice/sdl.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/libavdevice/sdl.c b/libavdevice/sdl.c
index b98aae5..4cccfe5 100644
--- a/libavdevice/sdl.c
+++ b/libavdevice/sdl.c
@@ -27,6 +27,7 @@
#include
#include "libavutil/avstring.h"
+#include "libavu
On 02/01/2016 06:12 PM, Michael Niedermayer wrote:
The problem is not using pal8 the problem is that it currently doesnt
work well at all if pal8 is used
making pal8 work well may or may not be alot of work, i dont know
but if you dont want to make pal8 work well then you also shouldnt
push tha
On Tue, Feb 02, 2016 at 12:43:09AM +0100, Andreas Cadhalpun wrote:
> On 30.01.2016 02:17, Michael Niedermayer wrote:
> > From: Michael Niedermayer
> >
> > TODO: Docs
> > TODO: version bump
> >
> > Note to maintainers: update tools
> >
> > Note to maintainers: set a default whitelist for your pr
On 2/1/2016 7:51 PM, Hendrik Leppkes wrote:
> On Mon, Feb 1, 2016 at 11:29 PM, James Almer wrote:
>> On 2/1/2016 7:01 PM, Hendrik Leppkes wrote:
>>> ---
>>> tests/fate/dca.mak| 72
>>> +++
>>> tests/ref/fate/dca-xll_51_16_192_768_0| 1
On Mon, Feb 01, 2016 at 01:26:37AM +0100, Michael Niedermayer wrote:
>
> breaks on x86-32 it seems
>
> vcodec/x86/vp9dsp_init_12bpp.o
> CC libavcodec/x86/vp9dsp_init_16bpp.o
> STRIP libavcodec/x86/qpeldsp.o
> src/libavcodec/x86/vc1dsp.asm:444: error: invalid combination of opcode and
> op
On Mon, Feb 1, 2016 at 11:29 PM, James Almer wrote:
> On 2/1/2016 7:01 PM, Hendrik Leppkes wrote:
>> ---
>> tests/fate/dca.mak| 72
>> +++
>> tests/ref/fate/dca-xll_51_16_192_768_0| 1 +
>> tests/ref/fate/dca-xll_51_16_192_768_1
On Mon, Feb 01, 2016 at 09:20:48PM +0100, Hendrik Leppkes wrote:
> ---
> tests/fate/dca.mak | 41
>
> tests/ref/fate/dca-xll_51_16_192_768_0 | 1 +
> tests/ref/fate/dca-xll_51_16_192_768_1 | 1 +
> tests/ref/fate/dca-xll_51_24_48_768
On 2/1/2016 7:01 PM, Hendrik Leppkes wrote:
> ---
> tests/fate/dca.mak| 72
> +++
> tests/ref/fate/dca-xll_51_16_192_768_0| 1 +
> tests/ref/fate/dca-xll_51_16_192_768_1| 1 +
> tests/ref/fate/dca-xll_51_16_192_768_1-dmix_2 |
On Mon, Feb 1, 2016 at 11:01 PM, Hendrik Leppkes wrote:
> ---
> tests/fate/dca.mak| 72
> +++
> tests/ref/fate/dca-xll_51_16_192_768_0| 1 +
> tests/ref/fate/dca-xll_51_16_192_768_1| 1 +
> tests/ref/fate/dca-xll_51_16_192_768
On 30.01.2016 17:36, Derek Buitenhuis wrote:
> On 1/30/2016 12:11 PM, Michael Niedermayer wrote:
>> patch should be ok
>
> Related to this:
>
> [16:25] <@Daemon404> that src/ dir really screws up my grepping if i dont
> distclean first
> [16:25] <@Daemon404> i get all my results twice
> [16:25]
On 30.01.2016 02:17, Michael Niedermayer wrote:
> From: Michael Niedermayer
>
> TODO: Docs
> TODO: version bump
>
> Note to maintainers: update tools
>
> Note to maintainers: set a default whitelist for your protocol
> If that makes no sense then consider to set "none" and thus require the user
---
tests/fate/dca.mak | 65 +
tests/ref/fate/dca-xll_51_16_192_768_0 | 11 +
tests/ref/fate/dca-xll_51_16_192_768_0-dmix_2 | 11 +
tests/ref/fate/dca-xll_51_16_192_768_0-dmix_6 | 11 +
tests/ref/fate/dca-xll_51_16_192_7
On Tue, Feb 2, 2016 at 12:24 AM, Michael Niedermayer
wrote:
> On Mon, Feb 01, 2016 at 09:34:12PM +0100, Hendrik Leppkes wrote:
>> On Mon, Feb 1, 2016 at 9:22 PM, Hendrik Leppkes wrote:
>> > On Mon, Feb 1, 2016 at 9:20 PM, Hendrik Leppkes
>> > wrote:
>> >> ---
>> >> tests/fate/dca.mak
On 30.01.2016 02:28, Michael Niedermayer wrote:
> On Sat, Jan 30, 2016 at 12:49:54AM +0100, Andreas Cadhalpun wrote:
>> On 27.01.2016 23:20, Michael Niedermayer wrote:
>>> ill make new point releases soon
>>> if you want something backported, backport it now
>>>
>>> also should i add the concat/sub
On 30.01.2016 02:17, Michael Niedermayer wrote:
> From: Michael Niedermayer
>
> Signed-off-by: Michael Niedermayer
> ---
> libavdevice/lavfi.c |7 ++-
> libavformat/async.c |2 +-
> libavformat/cache.c |3 ++-
> libavformat/concat.c
This implements the receiver side for
https://tools.ietf.org/html/draft-weaver-payload-rtp-vc2hq-01
---
Changelog| 1 +
libavformat/Makefile | 1 +
libavformat/rtpdec.c | 1 +
libavformat/rtpdec_formats.h | 1 +
libavformat/rtpdec_vc2hq.c | 230
+++
On Mon, Feb 01, 2016 at 09:34:12PM +0100, Hendrik Leppkes wrote:
> On Mon, Feb 1, 2016 at 9:22 PM, Hendrik Leppkes wrote:
> > On Mon, Feb 1, 2016 at 9:20 PM, Hendrik Leppkes wrote:
> >> ---
> >> tests/fate/dca.mak | 41
> >>
> >> tests/ref/
This implements the receiver side for
https://tools.ietf.org/html/draft-weaver-payload-rtp-vc2hq-01
---
Changelog| 1 +
libavformat/Makefile | 1 +
libavformat/rtpdec.c | 1 +
libavformat/rtpdec_formats.h | 1 +
libavformat/rtpdec_vc2hq.c | 227
+++
On Mon, Feb 01, 2016 at 09:20:47PM +0100, Hendrik Leppkes wrote:
> ---
> tests/Makefile | 1 +
> tests/fate/audio.mak | 16
> tests/fate/dca.mak | 15 +++
> 3 files changed, 16 insertions(+), 16 deletions(-)
> create mode 100644 tests/fate/dca.mak
LGTM
thx
On Mon, Feb 1, 2016 at 11:36 PM, Michael Niedermayer
wrote:
> On Mon, Feb 01, 2016 at 09:20:48PM +0100, Hendrik Leppkes wrote:
>> ---
>> tests/fate/dca.mak | 41
>>
>> tests/ref/fate/dca-xll_51_16_192_768_0 | 1 +
>> tests/ref/fate/dca-xl
---
tests/Makefile | 1 +
tests/fate/audio.mak | 16
tests/fate/dca.mak | 15 +++
3 files changed, 16 insertions(+), 16 deletions(-)
create mode 100644 tests/fate/dca.mak
diff --git a/tests/Makefile b/tests/Makefile
index 62544d0..ac524ac 100644
--- a/tests/
On Mon, Feb 1, 2016 at 9:20 PM, Hendrik Leppkes wrote:
> ---
> tests/fate/dca.mak | 41
>
> tests/ref/fate/dca-xll_51_16_192_768_0 | 1 +
> tests/ref/fate/dca-xll_51_16_192_768_1 | 1 +
> tests/ref/fate/dca-xll_51_24_48_768 | 1 +
On 02/01/2016 07:15 PM, wm4 wrote:
Can you just try to wait with your reply 30-60mins, instead of
constantly spamming the mailing list with follow ups?
I'll try. Thanks for reminding me.
Mats
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
htt
Please see updated patch.
On Mon, Jan 25, 2016 at 11:39 PM, Neil Birkbeck wrote:
> I guess png is another example; 10 is the denominator for the 32-bit
> integer:
> https://github.com/FFmpeg/FFmpeg/blob/b58cfa616c169c90166938608e7135cdab5820e0/libavcodec/pngenc.c#L290
>
> In the standards, th
---
tests/fate/dca.mak| 72 +++
tests/ref/fate/dca-xll_51_16_192_768_0| 1 +
tests/ref/fate/dca-xll_51_16_192_768_1| 1 +
tests/ref/fate/dca-xll_51_16_192_768_1-dmix_2 | 1 +
tests/ref/fate/dca-xll_51_24_48_768 | 1 +
On 1/31/2016 2:36 PM, Derek Buitenhuis wrote:
> Signed-off-by: Derek Buitenhuis
> ---
> ffprobe.c | 6 ++
> 1 file changed, 6 insertions(+)
OK'd by Clement on IRC.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mai
On Mon, Feb 1, 2016 at 9:22 PM, Hendrik Leppkes wrote:
> On Mon, Feb 1, 2016 at 9:20 PM, Hendrik Leppkes wrote:
>> ---
>> tests/fate/dca.mak | 41
>>
>> tests/ref/fate/dca-xll_51_16_192_768_0 | 1 +
>> tests/ref/fate/dca-xll_51_16_192_76
Hi Nico,
On Mon, Feb 1, 2016 at 3:23 PM, Nico Weber wrote:
> Hi,
>
> After http://llvm.org/viewvc/llvm-project?view=revision&revision=259271,
> clang complains:
>
> fmpeg\libavcodec/vp3data.h(61,34) : error: implicit
> conversion from 'int' to 'int8_t' (aka 'signed char') changes value
>
Hi,
After http://llvm.org/viewvc/llvm-project?view=revision&revision=259271,
clang complains:
fmpeg\libavcodec/vp3data.h(61,34) : error: implicit
conversion from 'int' to 'int8_t' (aka 'signed char') changes value
from
128 to -128 [-Werror,-Wconstant-conversion]
32, 40, 48, 64, 6
---
tests/fate/dca.mak | 41
tests/ref/fate/dca-xll_51_16_192_768_0 | 1 +
tests/ref/fate/dca-xll_51_16_192_768_1 | 1 +
tests/ref/fate/dca-xll_51_24_48_768 | 1 +
tests/ref/fate/dca-xll_51_24_48_none | 1 +
tests/ref/fate/dca
On Mon, 1 Feb 2016 18:29:30 +0100
Mats Peterson wrote:
> On 02/01/2016 06:05 PM, Michael Niedermayer wrote:
>
> > i expect that if my input is 1bpp and the output side supports 1bpp
> > then the output would be 1bpp and not 8bpp
> >
>
> Using monowhite/monoblack is fine for formats like TIFF
On 02/01/2016 06:05 PM, Michael Niedermayer wrote:
i expect that if my input is 1bpp and the output side supports 1bpp
then the output would be 1bpp and not 8bpp
Using monowhite/monoblack is fine for formats like TIFF which explicitly
uses black & white for its bilevel mode. It's not fine fo
On 02/01/2016 06:05 PM, Michael Niedermayer wrote:
i expect that if my input is 1bpp and the output side supports 1bpp
then the output would be 1bpp and not 8bpp
So, using this logic, in the name of consequence, you're ready to add
extra code for QuickTime RLE and BMP to accomplish this goal t
On 02/01/2016 06:12 PM, Michael Niedermayer wrote:
The problem is not using pal8 the problem is that it currently doesnt
work well at all if pal8 is used
making pal8 work well may or may not be alot of work, i dont know
but if you dont want to make pal8 work well then you also shouldnt
push that
On 02/01/2016 04:26 PM, Michael Niedermayer wrote:
breaks converting to nut
example:
./ffmpeg -i test.avi -vcodec rawvideo test-new.nut
./ffplay test-new.nut
does not play
"-vcodec copy" instead of rawvideo also does not make it work
before the patch
./ffmpeg -i test.avi -vcodec rawvideo test.n
On Mon, Feb 01, 2016 at 01:39:41PM +, Derek Buitenhuis wrote:
> On 1/31/2016 8:29 PM, Michael Niedermayer wrote:
> > the spec says this:
> > "The time code refers to the first picture after the group of
> > pictures header that has a temporal_reference of zero."
>
> I *think* this is the
On 02/01/2016 05:49 PM, Mats Peterson wrote:
-> You seem to love to bring this irrelevant subject up, Michael. Of course
an 8 bpp file will be larger than a 1 bpp one, did you expect anything
else? But what's the big deal with that? Nobody complains at "filesize
explosion" when using 2 and 4 bpp
Hi,
On Mon, Feb 1, 2016 at 11:53 AM, Timothy Gu wrote:
> On Sun, Jan 31, 2016 at 4:19 PM Ronald S. Bultje
> wrote:
>
> > > I wanted to do that at first, but then I realized that to change this
> I'd
> > > need
> > > to change simple_idct and a bunch of other decoders.
> >
> >
> > Wait, what? Ho
On 02/01/2016 02:58 PM, Michael Niedermayer wrote:
its not ok,
if only 2bpp are used and its possible to store just 2bpp then thats
what should be done by default. Same for 4bpp
that could be done with PAL8 and using its palette or using
some *_bits_per_pixel variable or a seperate PAL4/PAL2
many
On 02/01/2016 04:04 PM, Michael Niedermayer wrote:
fix the regressions your patch causes and iam happy to apply it
2-8 times output filesize explosion with default parameters being
the main regression
You seem to love to bring this irrelevant subject up, Michael. Of course
an 8 bpp file will
On Sat, 30 Jan 2016 22:15:04 +
Mark Thompson wrote:
> ---
> configure| 3 +
> libavfilter/Makefile | 1 +
> libavfilter/allfilters.c | 1 +
> libavfilter/vf_vaapi_scale.c | 709
> +++
> 4 files changed, 714 insert
On Sat, 30 Jan 2016 22:11:52 +
Mark Thompson wrote:
> ---
> configure | 5 +
> libavcodec/Makefile| 1 +
> libavcodec/vaapi_support.c | 710
> +
> libavcodec/vaapi_support.h | 122
> 4 files changed, 838 inser
On Sat, 30 Jan 2016 22:12:36 +
Mark Thompson wrote:
> ---
> Makefile | 1 +
> configure | 5 +
> ffmpeg.c | 6 +
> ffmpeg.h | 9 +
> ffmpeg_opt.c | 38 +++-
> ffmpeg_vaapi.c | 642
> +
> 6 files change
On Mon, Feb 01, 2016 at 09:31:51AM +0100, Tomas Härdin wrote:
> On Fri, 2016-01-29 at 17:45 +0100, Sebastian Dröge wrote:
> > From: Sebastian Dröge
> >
> > This reverts commit 8ed82d8174a666f80ab8834e3617cbe91ae740a9.
> >
> > SMPTE S377-1-2009c defines in F.4.1 that the Video Line Map should
> >
On Mon, 01 Feb 2016 15:17:51 +
John Cox wrote:
> Hi
>
> In order to get a copy-free display on my target h/w I need to have my
> decode output YUV planes contiguous. The default allocater gets each
> plane separately (so they aren't or at least aren't always). Is there a
> simple preferred
Hi
In order to get a copy-free display on my target h/w I need to have my
decode output YUV planes contiguous. The default allocater gets each
plane separately (so they aren't or at least aren't always). Is there a
simple preferred way of getting this to work? I've got slightly lost in
the maze
On Mon, Feb 01, 2016 at 08:02:02AM +0100, Mats Peterson wrote:
> Should be "1 bpp video in AVI", not just "1 bpp video".
>
> Mats
>
> --
> Mats Peterson
> http://matsp888.no-ip.org/~mats/
> libavcodec/rawdec.c | 43
> +++---
> tests/ref/vsynth/v
On 2/1/2016 6:10 AM, Hendrik Leppkes wrote:
> On Mon, Feb 1, 2016 at 4:36 AM, James Almer wrote:
>> And check for bitexact output instead
>>
>> Signed-off-by: James Almer
>> ---
>> The samples in https://github.com/foo86/dcadec-samples will have to
>> be added eventually to fully test all the DTS
On Mon, Feb 01, 2016 at 05:52:02PM +0100, Mats Peterson wrote:
> On 02/01/2016 02:58 PM, Michael Niedermayer wrote:
> >its not ok,
> >if only 2bpp are used and its possible to store just 2bpp then thats
> >what should be done by default. Same for 4bpp
> >that could be done with PAL8 and using its p
On 02/01/2016 06:09 PM, Mats Peterson wrote:
Is that my problem? No. It's for you to fix in the nut code.
What a name, by the way.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Mon, Feb 01, 2016 at 08:17:54AM +0100, Mats Peterson wrote:
> On 02/01/2016 08:02 AM, Mats Peterson wrote:
> >Should be "1 bpp video in AVI", not just "1 bpp video".
> >
>
> Your patch that switches to monow when a 1 bpp AVI doesn't contain a
> palette is rather kludgy and redundant to me. And
On Mon, Feb 01, 2016 at 05:49:09PM +0100, Mats Peterson wrote:
> On 02/01/2016 04:04 PM, Michael Niedermayer wrote:
> >fix the regressions your patch causes and iam happy to apply it
> >
> >2-8 times output filesize explosion with default parameters being
> >the main regression
> >
>
> You seem to
On Sun, Jan 31, 2016 at 4:19 PM Ronald S. Bultje wrote:
> > I wanted to do that at first, but then I realized that to change this I'd
> > need
> > to change simple_idct and a bunch of other decoders.
>
>
> Wait, what? How? Isn't this vc1-only code?
>
https://github.com/FFmpeg/FFmpeg/blob/235381e
> > Fixes tickets #5208 and #5209
Hmm, something strange happens here. I get crash only without valgrind (32-bit
build):
aaa@aaa-VirtualBox /media/sdb1 $ valgrind --leak-check=full ffmpeg/ffmpeg_g
-loglevel -1 -threads 1 -i 3_fuzz.avi -f null -
==13424== Memcheck, a memory error detector
==1342
2.6 times faster (366 vs. 142 cycles)
---
Changes since last patch:
- name changed to follow 420 version.
- use one less reg by using r4 more (James Almer's suggestion)
- don't require aligned space in the stack, use a negative value as the cglobal
argument. (perhaps unnessecary now that r6 i
On Mon, Feb 01, 2016 at 10:53:04AM +0100, wm4 wrote:
> On Mon, 1 Feb 2016 00:05:33 +0100
> Michael Niedermayer wrote:
>
> > This can cause problems with urls that have arguments after the filename
> >
> > This reverts commit b0c57206d583517a5ea35dd7f365f8260d9106f2.
> > ---
> > libavformat/hls
On Mon, Feb 01, 2016 at 01:14:02PM +0100, Mats Peterson wrote:
> On 02/01/2016 08:17 AM, Mats Peterson wrote:
> >I don't understand what's so important about retaining monow inside
> >FFmpeg when it comes to AVI, when it's obviously OK to convert 2 and 4
> >bpp to pal8. Once again, if you want a st
On 1/31/2016 8:29 PM, Michael Niedermayer wrote:
> the spec says this:
> "The time code refers to the first picture after the group of
> pictures header that has a temporal_reference of zero."
I *think* this is the frame I attach the side data too, but I'm
not a master of the mpeg*.c files.
On date Monday 2016-02-01 09:39:39 +, Carl Eugen Hoyos encoded:
> Umair Khan gmail.com> writes:
>
> > -Set the file size limit, expressed in bytes.
> > +Set the file size limit, expressed in bytes. No further chunk
> > of bytes is written
> > +after the limit is exceeded. The size of the out
On 02/01/2016 08:17 AM, Mats Peterson wrote:
I don't understand what's so important about retaining monow inside
FFmpeg when it comes to AVI, when it's obviously OK to convert 2 and 4
bpp to pal8. Once again, if you want a straight passthrough of 1 bpp AVI
video data, just use "-c:v copy".
You
On date Sunday 2016-01-31 17:43:21 +0100, Paul B Mahol encoded:
> Hi,
>
> patch attached.
> From 93a99efb889615d2f51f585d4cc49c2d6df70e28 Mon Sep 17 00:00:00 2001
> From: Paul B Mahol
> Date: Sun, 31 Jan 2016 17:40:55 +0100
> Subject: [PATCH] avdevice/lavfi: replace deprecated avpicture_layout
>
Michael Niedermayer niedermayer.cc> writes:
> ill push a similar solution that doesnt have that problem
> (after a bit more testing)
Works fine here, thank you!
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailma
Michael Niedermayer niedermayer.cc> writes:
> > adxdec.c | 14 ++
> > 1 file changed, 14 insertions(+)
> > 320063db5ec33166d9c40ed76e34415a69a2cf4c patchadxenc.diff
>
> should be ok
Patch applied.
Thank you, Carl Eugen
___
ffmpeg-dev
On 02/01/2016 10:59 AM, Mats Peterson wrote:
Well, I do know you're against everything I do, that's no news.
Fix MPlayer by the way.
Mats
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On 02/01/2016 10:41 AM, Carl Eugen Hoyos wrote:
-> Please don't.
Carl Eugen
Well, I do know you're against everything I do, that's no news.
Mats
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Mon, 1 Feb 2016 00:05:33 +0100
Michael Niedermayer wrote:
> This can cause problems with urls that have arguments after the filename
>
> This reverts commit b0c57206d583517a5ea35dd7f365f8260d9106f2.
> ---
> libavformat/hls.c |3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/lib
On Thu, Jan 28, 2016 at 10:58 PM, Bruce Dawson wrote:
>> Can you elaborate which test should be failing?
>
> Sure.
>
> The test that is failing is not in the ffmpeg repo, but it uses the ffmpeg
> repo. The Chromium test that fails (debug and release because we always
> compile ffmpeg optimized) is
On Sun, Jan 31, 2016 at 11:40 AM, Michael Niedermayer
wrote:
> On Sat, Jan 30, 2016 at 05:44:34PM +0100, Hendrik Leppkes wrote:
>> This fixes retrieving a valid profile for many of the FATE conformance
>> samples,
>> allowing them to be properly decoded by the HWAccel after adding a profile
>> c
Mats Peterson ffmpeg.org> writes:
> Judging by the lack of objections against this patch from people (except
> you, Michael) on the mailing list, I take it as a "silent approval".
Please don't.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@f
Umair Khan gmail.com> writes:
> -Set the file size limit, expressed in bytes.
> +Set the file size limit, expressed in bytes. No further chunk
> of bytes is written
> +after the limit is exceeded. The size of the output file is
> slightly more than the
> +requested file size.
Please mention ti
On Mon, Feb 1, 2016 at 4:36 AM, James Almer wrote:
> And check for bitexact output instead
>
> Signed-off-by: James Almer
> ---
> The samples in https://github.com/foo86/dcadec-samples will have to
> be added eventually to fully test all the DTS extensions.
>
> tests/fate/audio.mak | 3 +++
>
On Mon, Feb 1, 2016 at 4:36 AM, James Almer wrote:
> Fixes compilation with TRACE enabled
>
> Signed-off-by: James Almer
> ---
> libavcodec/dca_core.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/libavcodec/dca_core.c b/libavcodec/dca_core.c
> index 94f
On Fri, 2016-01-29 at 17:45 +0100, Sebastian Dröge wrote:
> From: Sebastian Dröge
>
> This reverts commit 8ed82d8174a666f80ab8834e3617cbe91ae740a9.
>
> SMPTE S377-1-2009c defines in F.4.1 that the Video Line Map should
> always be an array with two 32 bit integers as elements. This is
> repeated
On 02/01/2016 08:02 AM, Mats Peterson wrote:
Should be "1 bpp video in AVI", not just "1 bpp video".
Your patch that switches to monow when a 1 bpp AVI doesn't contain a
palette is rather kludgy and redundant to me. And users will undoubtly
be surprised by the use of monow for the unique case
Should be "1 bpp video in AVI", not just "1 bpp video".
Mats
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From c8e99942495c797067be55fb115a21955e11b76b Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Sun, 31 Jan 2016 14:08:19 +0100
Subject: [PATCH v3] lavc/rawdec: Only use AV_PIX_FMT_P
88 matches
Mail list logo
