On 02/01/2016 06:03 AM, Mats Peterson wrote:
ping
Since noone here seems to object to this patch (except you), I take it
as a "silent approval".
Mats
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-d
On 01/31/2016 02:09 PM, Mats Peterson wrote:
Minor fix.
Mats
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
ping
___
ffmpeg-devel mailing list
ffmp
On 02/01/2016 04:48 AM, Mats Peterson wrote:
On 01/31/2016 11:22 PM, Mats Peterson wrote:
also i dont think its just avi. The raw video decoder is potentially
used for more than avi.
mkv and nut come to mind as potential formats that might use the
same codepath
Yes it is used for other file
On 01/31/2016 11:22 PM, Mats Peterson wrote:
also i dont think its just avi. The raw video decoder is potentially
used for more than avi.
mkv and nut come to mind as potential formats that might use the
same codepath
Yes it is used for other file formats as well, but only AVI and
QuickTime ex
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 94f0f3d..f15b9a7 100644
--- a/libavcodec/dca_core.c
+++ b/libavcodec/dc
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 +++
tests/ref/fate/dca-xll | 1 +
2 files changed, 4 insertions(+)
crea
doc/examples/transcoding is not able to reencode with libx264.
Please help to teach it to do so.
This script reproduces the issue in automated fashion:
https://gist.github.com/andrey-utkin/925ce227b2b530d1e808
(ffmpeg.issue.sh attached).
The script applies one patch to the example program. The pa
On 1/31/2016 8:28 PM, Timothy Gu wrote:
> ---
> libavcodec/x86/vc1dsp.asm| 98
> libavcodec/x86/vc1dsp_init.c | 13 +++
> libavcodec/x86/vc1dsp_mmx.c | 207
> ---
> 3 files changed, 111 insertions(+), 207 deletions(-)
>
> diff -
On Wed, Jan 27, 2016 at 11:20:44PM +0100, Michael Niedermayer wrote:
> Hi all
>
> ill make new point releases soon
> if you want something backported, backport it now
>
> also should i add the concat/subfile_enable switch and have them
> disabled by default or is it preferred to leave them as is
On Sat, Jan 30, 2016 at 05:52:24PM +, Derek Buitenhuis wrote:
> On 1/27/2016 6:18 PM, Stephen Hutchinson wrote:
> > I have no strong opinion on it. 68 seems like the compromise
> > position since it'd allow both 1.8 and 1.9 to be used, whereas
> > any of the earlier ones still fall within 1.8'
On Sun, Jan 31, 2016 at 03:28:40PM -0800, Timothy Gu wrote:
> ---
> libavcodec/x86/vc1dsp.asm| 98
> libavcodec/x86/vc1dsp_init.c | 13 +++
> libavcodec/x86/vc1dsp_mmx.c | 207
> ---
> 3 files changed, 111 insertions(+), 207 dele
Hi,
On Sun, Jan 31, 2016 at 6:27 PM, Timothy Gu wrote:
> On Sun, Jan 31, 2016 at 06:18:53PM -0300, James Almer wrote:
> > On 1/31/2016 4:48 PM, Timothy Gu wrote:
> > > ---
> > > libavcodec/x86/vc1dsp.asm| 104 ++
> > > libavcodec/x86/vc1dsp_init.c | 13 +++
> > > libavc
Fixes tickets #5208 and #5209
---
libavcodec/cfhd.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
index 115081c..410bb7b 100644
--- a/libavcodec/cfhd.c
+++ b/libavcodec/cfhd.c
@@ -224,7 +224,7 @@ static int cfhd_decode(AVCodecCont
On Fri, Jan 29, 2016 at 10:10:48AM +0100, Clément Bœsch wrote:
> On Thu, Jan 28, 2016 at 06:33:56PM -0800, Timothy Gu wrote:
> > ---
> > tests/fate/source-check.sh | 11 +++
> > tests/ref/fate/source | 12
> > 2 files changed, 23 insertions(+)
> >
> > diff --git a/tests/
On Thu, Jan 28, 2016 at 06:33:54PM -0800, Timothy Gu wrote:
> ---
> compat/aix/math.h | 6 +++---
> compat/msvcrt/snprintf.h| 6 +++---
> compat/os2threads.h | 6 +++---
> compat/tms470/math.h| 6 +++---
> compat/w32pthreads.h
On Sat, Jan 30, 2016 at 07:27:22PM +, Derek Buitenhuis wrote:
> On 1/30/2016 7:15 PM, Timothy Gu wrote:
> > FATE passes here on a x86-64 machine with both GCC 4.9.2 and 5.3.1.
>
> Perhaps this should be restricted to x86?
Fair enough.
Timothy
>From b75076b5d735005a5a8b25d47c21c38cbaebb30b Mo
On Sun, Jan 31, 2016 at 10:36:11PM +1100, Peter Ross wrote:
> On Fri, Jan 29, 2016 at 09:36:30PM +, popcorn mix wrote:
> > The index creation is O(N^2) with number of entries (typically thousands).
> > On a Raspberry Pi this can take more than 60 seconds to execute for a
> > recording of a few
On Sat, Jan 30, 2016 at 09:47:21PM +0100, Paul B Mahol wrote:
>
> ok
Pushed.
Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
---
libavcodec/x86/vc1dsp.asm| 98
libavcodec/x86/vc1dsp_init.c | 13 +++
libavcodec/x86/vc1dsp_mmx.c | 207 ---
3 files changed, 111 insertions(+), 207 deletions(-)
diff --git a/libavcodec/x86/vc1dsp.asm b/libavcodec/x86/vc1dsp.
On Sun, Jan 31, 2016 at 06:18:53PM -0300, James Almer wrote:
> On 1/31/2016 4:48 PM, Timothy Gu wrote:
> > ---
> > libavcodec/x86/vc1dsp.asm| 104 ++
> > libavcodec/x86/vc1dsp_init.c | 13 +++
> > libavcodec/x86/vc1dsp_mmx.c | 207
> >
On Sun, Jan 31, 2016 at 10:25:19PM +0100, Paul B Mahol wrote:
> Hi,
>
> patch attached.
> vf_yadif.c | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
> cc8e27e4902af54fe8c1f1815177c4d5680f77fb
> 0001-avfilter-vf_yadif-make-use-of-ctx-pointer.patch
> From a71c17e7a52cc
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/libavformat/hls.c b/libavformat/hls.c
index dce8a5c..2d8e6c0 100644
--- a/libavform
On Sun, Jan 31, 2016 at 11:16:48PM +0100, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch adds autodetection for adx files.
> Our decoder has never accepted files without the copyright string
> and our encoder has never written other files.
>
> Please comment, Carl Eugen
> adxdec.c | 14 +++
On 01/31/2016 11:19 PM, Michael Niedermayer wrote:
i think that default palette code could be removed if 1bpp->pal8
isnt done when theres no palete
also i dont think its just avi. The raw video decoder is potentially
used for more than avi.
mkv and nut come to mind as potential formats that migh
On Sun, Jan 31, 2016 at 11:11:31PM +0100, Mats Peterson wrote:
> On 01/31/2016 11:08 PM, Michael Niedermayer wrote:
> >On Sun, Jan 31, 2016 at 10:53:35PM +0100, Mats Peterson wrote:
> >>On 01/31/2016 10:49 PM, Mats Peterson wrote:
> this decission should be made by other developers, who where n
Hi!
Attached patch adds autodetection for adx files.
Our decoder has never accepted files without the copyright string
and our encoder has never written other files.
Please comment, Carl Eugen
diff --git a/libavformat/adxdec.c b/libavformat/adxdec.c
index 66ea8ab..05cef0b 100644
--- a/libavforma
On 01/31/2016 11:08 PM, Michael Niedermayer wrote:
my suggestion is just about the raw video decoder, that is if a
AVPacket contains monochrome 1bpp black/white data without a palette
that this is passed through and not converted to pal8
*
If you want to pass it through, just use "-c:v copy".
On 01/31/2016 11:08 PM, Michael Niedermayer wrote:
On Sun, Jan 31, 2016 at 10:53:35PM +0100, Mats Peterson wrote:
On 01/31/2016 10:49 PM, Mats Peterson wrote:
this decission should be made by other developers, who where not
involved in this disagreement, that should result in a outcome that
rep
On 01/31/2016 10:53 PM, Mats Peterson wrote:
Just because we have monow and monob pixel formats, it doesn't mean they
should be used wherever 1 bpp data is involved. And once again, the
semantics according to Microsoft are that 1 bpp AVI is NEVER monochrome,
it is ALWAYS palettized, regardless of
On Sun, Jan 31, 2016 at 10:53:35PM +0100, Mats Peterson wrote:
> On 01/31/2016 10:49 PM, Mats Peterson wrote:
> >>this decission should be made by other developers, who where not
> >>involved in this disagreement, that should result in a outcome that
> >>represents the preferrances of the community
On Sun, Jan 31, 2016 at 10:18 PM, James Almer wrote:
> On 1/31/2016 4:48 PM, Timothy Gu wrote:
>> +; ff_vc1_inv_trans_?x?_dc_mmxext(uint8_t *dest, int linesize, int16_t
>> *block)
>> +INIT_MMX mmxext
>> +cglobal vc1_inv_trans_4x4_dc, 3,4,0, dest, linesize, block
>> +movsx r3d, WORD [b
On 01/31/2016 10:49 PM, Mats Peterson wrote:
this decission should be made by other developers, who where not
involved in this disagreement, that should result in a outcome that
represents the preferrances of the community better.
wm4 is already on my side, as far as I understand.
Just beca
On 01/31/2016 10:49 PM, Michael Niedermayer wrote:
So, will you apply my patch? Or are you willing to change to this
funny logic for every file format that uses 1 bpp? As I said, both 2
and 4 bpp uses pal8 internally, and nobody seems to complain about
that. I'm beginning to get rather tired of t
On Sun, Jan 31, 2016 at 10:33:33PM +0100, Mats Peterson wrote:
> On 01/31/2016 10:31 PM, Michael Niedermayer wrote:
> >
> >If a AVI contains a palette one might argue its a paletted avi
> >either way i dont know, i dont have such a file
> >it would be needed to have real world files in that categor
On 01/31/2016 10:33 PM, Mats Peterson wrote:
On 01/31/2016 10:31 PM, Michael Niedermayer wrote:
If a AVI contains a palette one might argue its a paletted avi
either way i dont know, i dont have such a file
it would be needed to have real world files in that category
to know if treating them as
On 01/31/2016 10:31 PM, Michael Niedermayer wrote:
If a AVI contains a palette one might argue its a paletted avi
either way i dont know, i dont have such a file
it would be needed to have real world files in that category
to know if treating them as pal8 is better or not
So, will you apply
On Sun, Jan 31, 2016 at 10:08:41PM +0100, Mats Peterson wrote:
> On 01/31/2016 03:07 PM, Michael Niedermayer wrote:
> >On Sun, Jan 31, 2016 at 01:27:22PM +0100, Mats Peterson wrote:
> >>I don't really appreciate that you're doing things behind my back,
> >>Michael. There's nothing mentioned on the
On 1/31/2016 6:18 PM, James Almer wrote:
> On 1/31/2016 4:48 PM, Timothy Gu wrote:
>> +; ff_vc1_inv_trans_?x?_dc_mmxext(uint8_t *dest, int linesize, int16_t
>> *block)
>> +INIT_MMX mmxext
>> +cglobal vc1_inv_trans_4x4_dc, 3,4,0, dest, linesize, block
>> +movsx r3d, WORD [blockq]
>
> C
On 01/31/2016 10:08 PM, Mats Peterson wrote:
Even if you stubbornly decide to keep your patch, it is incorrect
anyway. If a 1 bpp AVI contains a palette, black & white or not, pal8
will be used regardless. Look at the snippet below. Furthermore, the
palette side data packet will be retrieved twi
Hi,
patch attached.
From a71c17e7a52ccc5ff4e7cf379cb87389bd60eff1 Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Sun, 31 Jan 2016 22:23:07 +0100
Subject: [PATCH] avfilter/vf_yadif: make use of ctx pointer
Signed-off-by: Paul B Mahol
---
libavfilter/vf_yadif.c | 16
1 file c
On Thu, Jan 28, 2016 at 5:18 PM, Henrik Gramner wrote:
> ---
> configure | 1 +
> 1 file changed, 1 insertion(+)
No complaints and the same patch was OK:ed by Derek on libav-devel, so pushed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http:/
On Sun, Jan 31, 2016 at 02:36:19PM +, Derek Buitenhuis wrote:
> The codec context field was rightly deprecated, and the data
> may change per-frame.
>
> Signed-off-by: Derek Buitenhuis
> ---
> I really don't liek dumping part of this at the end of mpeg_decode_frame,
> but I have no idea where
On 1/31/2016 9:18 PM, Michael Niedermayer wrote:
> is it intended to set this also when ret < 0
No, you're right, it should not be. Amended locally.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-
On 1/31/2016 4:48 PM, Timothy Gu wrote:
> ---
> libavcodec/x86/vc1dsp.asm| 104 ++
> libavcodec/x86/vc1dsp_init.c | 13 +++
> libavcodec/x86/vc1dsp_mmx.c | 207
> ---
> 3 files changed, 117 insertions(+), 207 deletions(-)
>
> diff
On 01/31/2016 03:07 PM, Michael Niedermayer wrote:
On Sun, Jan 31, 2016 at 01:27:22PM +0100, Mats Peterson wrote:
I don't really appreciate that you're doing things behind my back,
Michael. There's nothing mentioned on the ffmpeg-devel mailing lis
indeed, i should have clearly stated that i ap
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 changed, 40 insertions(+), 40 deletions(-)
diff --git a/libavcodec/d
Hi,
On Sun, Jan 31, 2016 at 2:48 PM, Timothy Gu wrote:
> +; ff_vc1_inv_trans_?x?_dc_mmxext(uint8_t *dest, int linesize, int16_t
> *block)
+INIT_MMX mmxext
> +cglobal vc1_inv_trans_4x4_dc, 3,4,0, dest, linesize, block
>
[..]
> +%define linesize3q r2q
>
DEFINE_ARGS dest, linesize, linesize3
Re
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 changed, 40 insertions(+), 40 deletions(-)
diff --git a/libavcodec/d
On Sun, Jan 31, 2016 at 08:17:04PM +, Derek Buitenhuis wrote:
> On 1/31/2016 8:02 PM, Michael Niedermayer wrote:
> > whats the first frame of a gop ?
> > for example there may be B frames prior to an I frame in display
> > order
>
> In this case, it's the first frame output after decoding the
On 1/31/2016 8:02 PM, Michael Niedermayer wrote:
> whats the first frame of a gop ?
> for example there may be B frames prior to an I frame in display
> order
In this case, it's the first frame output after decoding the GOP header.
Do you think there is a better way to word it?
- Derek
_
On Sun, Jan 31, 2016 at 05:55:55PM +, Derek Buitenhuis wrote:
> On 1/31/2016 5:50 PM, Michael Niedermayer wrote:
> > this causes segfaults in fate
>
> Did you try v2?
did now, v2 works
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The misfortune of the w
On Sun, Jan 31, 2016 at 02:36:18PM +, Derek Buitenhuis wrote:
> Signed-off-by: Derek Buitenhuis
> ---
> doc/APIchanges | 3 +++
> libavutil/frame.c | 1 +
> libavutil/frame.h | 7 ++-
> libavutil/version.h | 4 ++--
> 4 files changed, 12 insertions(+), 3 deletions(-)
>
> diff --
On Sun, 31 Jan 2016 20:51:23 +0100
Michael Niedermayer wrote:
> On Sun, Jan 31, 2016 at 04:04:41PM -0300, James Almer wrote:
> > On 1/31/2016 3:57 PM, James Almer wrote:
> > > On 1/31/2016 3:51 PM, Michael Niedermayer wrote:
> > >> On Sun, Jan 31, 2016 at 05:14:14PM +0100, foo86 wrote:
> >
Signed-off-by: Umair Khan
---
doc/ffmpeg.texi | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index 7d3266a..e02807c 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -297,7 +297,9 @@ see @ref{time duration syntax,,the Time duration sec
---
libavcodec/x86/vc1dsp.asm| 104 ++
libavcodec/x86/vc1dsp_init.c | 13 +++
libavcodec/x86/vc1dsp_mmx.c | 207 ---
3 files changed, 117 insertions(+), 207 deletions(-)
diff --git a/libavcodec/x86/vc1dsp.asm b/libavcodec/x86/vc1ds
On Sun, Jan 31, 2016 at 04:04:41PM -0300, James Almer wrote:
> On 1/31/2016 3:57 PM, James Almer wrote:
> > On 1/31/2016 3:51 PM, Michael Niedermayer wrote:
> >> On Sun, Jan 31, 2016 at 05:14:14PM +0100, foo86 wrote:
> >>> ffmpeg | branch: master | foo86 | Sat Jan 16
> >>> 11:54:38 2016 +0300| [a
On 01/31/2016 07:04 PM, Mats Peterson wrote:
Why whould it "stop working well" with monochrome just because we use a
different internal depth? And as I said, both QuickTime (raw and RLE)
Both 2 bpp and 4 bpp use pal8 internally, but nobody seems to complain
about that fact.
Mats
___
On Sun, Jan 31, 2016, at 07:33 AM, Carl Eugen Hoyos wrote:
>
> It would be great if somebody writes a (short) news entry.
If someone provides the text I can add it to the site.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mail
On 1/31/2016 3:57 PM, James Almer wrote:
> On 1/31/2016 3:51 PM, Michael Niedermayer wrote:
>> On Sun, Jan 31, 2016 at 05:14:14PM +0100, foo86 wrote:
>>> ffmpeg | branch: master | foo86 | Sat Jan 16 11:54:38
>>> 2016 +0300| [ae5b2c52501d5009fe712334428138a9b758849b] | committer: Hendrik
>>> Lepp
On Sun, Jan 31, 2016 at 7:57 PM, James Almer wrote:
> On 1/31/2016 3:51 PM, Michael Niedermayer wrote:
>> On Sun, Jan 31, 2016 at 05:14:14PM +0100, foo86 wrote:
>>> ffmpeg | branch: master | foo86 | Sat Jan 16 11:54:38
>>> 2016 +0300| [ae5b2c52501d5009fe712334428138a9b758849b] | committer: Hendr
On 1/31/2016 3:51 PM, Michael Niedermayer wrote:
> On Sun, Jan 31, 2016 at 05:14:14PM +0100, foo86 wrote:
>> ffmpeg | branch: master | foo86 | Sat Jan 16 11:54:38
>> 2016 +0300| [ae5b2c52501d5009fe712334428138a9b758849b] | committer: Hendrik
>> Leppkes
>>
>> avcodec/dca: add new decoder based on
On Sun, Jan 31, 2016 at 05:14:14PM +0100, foo86 wrote:
> ffmpeg | branch: master | foo86 | Sat Jan 16 11:54:38
> 2016 +0300| [ae5b2c52501d5009fe712334428138a9b758849b] | committer: Hendrik
> Leppkes
>
> avcodec/dca: add new decoder based on libdcadec
>
> > http://git.videolan.org/gitweb.cgi/ff
On 01/31/2016 07:04 PM, Mats Peterson wrote:
either way, as said iam happy to switch to using pal8 for monochrome
avis if people want.
I just dont know if people want that
Furthermore, there is no such thing as "monochrome AVIs". The semantics
are that they are palettized, even if there are on
On 01/31/2016 05:48 PM, Michael Niedermayer wrote:
ffmpeg (the application) reads and writes multimedia files
why should ffmpeg suddenly stop working well with monochrome ?
(and require the user to per file convert to monochrome when the input
already is monochrome)
Also we talk about the raw
On 1/31/2016 5:50 PM, Michael Niedermayer wrote:
> this causes segfaults in fate
Did you try v2?
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Sun, Jan 31, 2016 at 01:13:42PM +, Derek Buitenhuis wrote:
> The codec context field was rightly deprecated, and the data
> may change per-frame.
>
> Signed-off-by: Derek Buitenhuis
> ---
> ffprobe.c | 8
> libavcodec/mpeg12dec.c | 19 ---
> 2 files
On Sun, Jan 31, 2016 at 04:03:36PM +0100, Mats Peterson wrote:
> On 01/31/2016 03:59 PM, Michael Niedermayer wrote:
> >ffmpeg source is not unchanegable,
> >if you belive that pal8 should be used in place of monochrome you
> >could certaily make the code act more reasonable with a 2 entry
> >(black
On Sun, 31 Jan 2016 16:32:24 +
Mark Thompson wrote:
> On 31/01/16 16:24, Mark Thompson wrote:
> > On 31/01/16 16:13, wm4 wrote:
> >> On Sat, 30 Jan 2016 22:11:52 +
> >> Mark Thompson wrote:
> >>> +
> >>> +static AVClass vaapi_class = {
> >>> +.class_name = "vaapi",
> >>> +.it
On Sun, Jan 31, 2016 at 04:41:44PM +0100, Mats Peterson wrote:
> On 01/31/2016 04:19 PM, Mats Peterson wrote:
> >People will have to get used to the video data being converted from 1
> >bpp to 8 bpp internally, just as they have become used to 2 and 4 bpp
> >data being converted to 8 bpp. It should
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
Signed-off-by: Paul B Mahol
---
libavdevice/lavfi.c | 8 ++--
1 file chan
Hendrik Leppkes gmail.com> writes:
> The decoder has been pushed now.
It would be great if somebody writes a (short) news entry.
Thank you!
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-de
On 31/01/16 16:24, Mark Thompson wrote:
> On 31/01/16 16:13, wm4 wrote:
>> On Sat, 30 Jan 2016 22:11:52 +
>> Mark Thompson wrote:
>>> +
>>> +static AVClass vaapi_class = {
>>> +.class_name = "vaapi",
>>> +.item_name = av_default_item_name,
>>> +.version= LIBAVUTIL_VERSION_INT,
On 31/01/16 16:13, wm4 wrote:
> On Sat, 30 Jan 2016 22:11:52 +
> Mark Thompson wrote:
>> +
>> +static AVClass vaapi_class = {
>> +.class_name = "vaapi",
>> +.item_name = av_default_item_name,
>> +.version= LIBAVUTIL_VERSION_INT,
>> +};
>> +static AVClass *vaapi_log = &vaapi_cl
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 2016-01-31 16:58, Umair Khan wrote:
> Hi,
> Thanks for reply. I did a lot of searching but couldn't get what is
> the proper way to resend the patch with amended commit.
> Should I just do git send-email again ?
> And should I send it to this thread only ? If yes, how ?
Yes. Run send-email aga
On Sat, Jan 30, 2016 at 11:02 PM, James Almer wrote:
> On 1/30/2016 6:45 PM, Hendrik Leppkes wrote:
>> On Sat, Jan 30, 2016 at 10:41 PM, James Almer wrote:
>>> On 1/30/2016 6:15 PM, Hendrik Leppkes wrote:
On Sat, Jan 30, 2016 at 7:05 PM, Hendrik Leppkes
wrote:
> On Sat, Jan 30, 20
On Sun, Jan 31, 2016 at 8:04 PM, Carl Eugen Hoyos wrote:
> Umair Khan gmail.com> writes:
>
>> +Set the file size limit, expressed in bytes. No more bytes are written
>> +after the limit is exceeded.
>
> Does this explain that the file size is never smaller than
> the requested size (but usually h
On 01/31/2016 04:19 PM, Mats Peterson wrote:
People will have to get used to the video data being converted from 1
bpp to 8 bpp internally, just as they have become used to 2 and 4 bpp
data being converted to 8 bpp. It shouldn't come as a shock, since this
is perfectly logical behaviour, as long
On 01/31/2016 04:05 PM, Mats Peterson wrote:
I don't believe. It's a fact. And it is used in other places (QuickTime,
both raw and RLE, and BMP) for 1 bpp data, so why shouldn't it for AVI
as well? Please, just apply my latest patch that restores the pal8-only
behaviour. This is a lot more logica
On 01/31/2016 04:03 PM, Mats Peterson wrote:
On 01/31/2016 03:59 PM, Michael Niedermayer wrote:
ffmpeg source is not unchanegable,
if you belive that pal8 should be used in place of monochrome you
could certaily make the code act more reasonable with a 2 entry
(black+white) PAL8
I don't belie
On 01/31/2016 03:59 PM, Michael Niedermayer wrote:
ffmpeg source is not unchanegable,
if you belive that pal8 should be used in place of monochrome you
could certaily make the code act more reasonable with a 2 entry
(black+white) PAL8
I don't believe. It's a fact. And it is used in other place
On Sun, Jan 31, 2016 at 03:33:00PM +0100, Mats Peterson wrote:
> On 01/31/2016 03:29 PM, Michael Niedermayer wrote:
> >less than one out of a hundread users would realize that
> >also it does feel unclean to me to convert monochrome to pal8 in
> >the decoder and then require the user to manually fo
On 01/31/2016 03:33 PM, Mats Peterson wrote:
On 01/31/2016 03:29 PM, Michael Niedermayer wrote:
less than one out of a hundread users would realize that
also it does feel unclean to me to convert monochrome to pal8 in
the decoder and then require the user to manually force convertion
of paletted
Derek Buitenhuis (3):
avutil: Add GOP timecode frame side data
mpeg12dec: Export GOP timecodes as side data
ffprobe: Deprecate stream timecode field and add frame side data
timecode field
doc/APIchanges | 3 +++
ffprobe.c | 6 ++
libavcodec/mpeg12dec.c | 22 ++
The codec context field was rightly deprecated, and the data
may change per-frame.
Signed-off-by: Derek Buitenhuis
---
I really don't liek dumping part of this at the end of mpeg_decode_frame,
but I have no idea where else to put it, so that the decoder delay and
reordering do not affect it.
Any
Signed-off-by: Derek Buitenhuis
---
doc/APIchanges | 3 +++
libavutil/frame.c | 1 +
libavutil/frame.h | 7 ++-
libavutil/version.h | 4 ++--
4 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 15aefb5..45ccf13 100644
--- a/doc/APIcha
On 01/31/2016 03:29 PM, Michael Niedermayer wrote:
less than one out of a hundread users would realize that
also it does feel unclean to me to convert monochrome to pal8 in
the decoder and then require the user to manually force convertion
of paletted data back to monochrome
Since this is the w
On 01/31/2016 03:27 PM, Michael Niedermayer wrote:
It's not bizarre at all. Black & white is just a variant of
palettized data in this context, it's not monochrome. And just
because you don't have a non-b/w sample, it doesn't mean you should
use monow. A 1 bpp AVI is not monochrome once again, it
Signed-off-by: Derek Buitenhuis
---
ffprobe.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/ffprobe.c b/ffprobe.c
index c352b44..f7b51ad 100644
--- a/ffprobe.c
+++ b/ffprobe.c
@@ -1917,6 +1917,10 @@ static void show_frame(WriterContext *w, AVFrame *frame,
AVStream *stream,
Umair Khan gmail.com> writes:
> +Set the file size limit, expressed in bytes. No more bytes are written
> +after the limit is exceeded.
Does this explain that the file size is never smaller than
the requested size (but usually higher)?
Please mention ticket #5160 in the commit message.
Carl E
On 31/01/16 01:02, Timothy Gu wrote:
> On Sat, Jan 30, 2016 at 10:11:52PM +, Mark Thompson wrote:
>> +static AVClass vaapi_class = {
>
> static const
>
>> +.class_name = "vaapi",
>> +.item_name = av_default_item_name,
>> +.version= LIBAVUTIL_VERSION_INT,
>> +};
>> +static AVC
On Sun, Jan 31, 2016 at 03:16:46PM +0100, Mats Peterson wrote:
> On 01/31/2016 03:07 PM, Michael Niedermayer wrote:
> >indeed, i should have clearly stated that i applied the pal8
> >patches with the plan to use pal8 only when neccessary.
> >I had asked you to implement exactly that but it seemed y
On Sun, Jan 31, 2016 at 03:22:57PM +0100, Mats Peterson wrote:
> On 01/31/2016 03:20 PM, Michael Niedermayer wrote:
> >but
> >converting from monochrome avis/nuts/others? to other formats would
> >not store monochrome but paletted or RGB then
> >
> >heres an example with tiff:
> >
> >./ffmpeg
On 01/31/2016 03:20 PM, Michael Niedermayer wrote:
but
converting from monochrome avis/nuts/others? to other formats would
not store monochrome but paletted or RGB then
heres an example with tiff:
./ffmpeg -i test.avi -vframes 1 test.tiff
./ffmpeg-ref -i test.avi -vframes 1 test-ref.tiff
On 31/01/16 09:32, Paul B Mahol wrote:
> On 1/30/16, Mark Thompson wrote:
>> On 30/01/16 22:22, Paul B Mahol wrote:
>>> On 1/30/16, Mark Thompson wrote:
---
configure| 3 +
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
>
On 01/31/2016 03:22 PM, Mats Peterson wrote:
Yes it would, but just force -pix_fmt monow then.
With the reservation that pal8 to monow is somewhat erratic, but I'll
leave that to you guys to solve. I'm not able to.
Mats
___
ffmpeg-devel mailing li
On 01/31/2016 03:20 PM, Michael Niedermayer wrote:
On Sun, Jan 31, 2016 at 01:33:02PM +0100, wm4 wrote:
On Sun, 31 Jan 2016 13:27:22 +0100
Mats Peterson wrote:
I don't really appreciate that you're doing things behind my back,
Michael. There's nothing mentioned on the ffmpeg-devel mailing lis
On 01/31/2016 03:07 PM, Michael Niedermayer wrote:
indeed, i should have clearly stated that i applied the pal8
patches with the plan to use pal8 only when neccessary.
I had asked you to implement exactly that but it seemed you didnt
know how to do that cleanly and simply so i thought "no problem
On Sun, Jan 31, 2016 at 01:33:02PM +0100, wm4 wrote:
> On Sun, 31 Jan 2016 13:27:22 +0100
> Mats Peterson wrote:
>
> > I don't really appreciate that you're doing things behind my back,
> > Michael. There's nothing mentioned on the ffmpeg-devel mailing list
> > about your "monowhite switching p
On Sun, Jan 31, 2016 at 01:27:22PM +0100, Mats Peterson wrote:
> I don't really appreciate that you're doing things behind my back,
> Michael. There's nothing mentioned on the ffmpeg-devel mailing lis
indeed, i should have clearly stated that i applied the pal8
patches with the plan to use pal8 on
1 - 100 of 126 matches
Mail list logo
