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 +
>>> libavfilter/vf_vaapi_scale.c | 709
>>> +
On Sun, Jan 31, 2016 at 01:34:46AM +0100, Mats Peterson wrote:
> On 01/30/2016 05:10 AM, Mats Peterson wrote:
> >Now when both AVI and QuickTime use pal8 for 1 bpp video, there's no
> >need to keep the monow stuff.
> >
> I should add that I'm only removing stuff that I've added myself
> before, so
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
> check.
> ---
> libavcodec/hevc_ps.c | 6 +-
> 1 file changed, 5
On 01/31/2016 11:31 AM, Michael Niedermayer wrote:
On Sun, Jan 31, 2016 at 01:34:46AM +0100, Mats Peterson wrote:
On 01/30/2016 05:10 AM, Mats Peterson wrote:
Now when both AVI and QuickTime use pal8 for 1 bpp video, there's no
need to keep the monow stuff.
I should add that I'm only removing
On 01/31/2016 12:25 PM, Mats Peterson wrote:
On 01/31/2016 12:19 PM, Mats Peterson wrote:
I've obviously missed that one, Michael, but I don't see the reason to
switch to monow whatsoever. The space saving of using monow rather than
pal8 for 1 bpp data is rather irrelevant nowadays. Your mileage
On 01/31/2016 12:27 PM, Mats Peterson wrote:
On 01/31/2016 12:25 PM, Mats Peterson wrote:
On 01/31/2016 12:19 PM, Mats Peterson wrote:
I've obviously missed that one, Michael, but I don't see the reason to
switch to monow whatsoever. The space saving of using monow rather than
pal8 for 1 bpp da
On 01/31/2016 12:19 PM, Mats Peterson wrote:
I've obviously missed that one, Michael, but I don't see the reason to
switch to monow whatsoever. The space saving of using monow rather than
pal8 for 1 bpp data is rather irrelevant nowadays. Your mileage may
vary, of course. And in order to be conse
On 01/31/2016 12:31 PM, Mats Peterson wrote:
On 01/31/2016 12:28 PM, Mats Peterson wrote:
On 01/31/2016 12:27 PM, Mats Peterson wrote:
On 01/31/2016 12:25 PM, Mats Peterson wrote:
On 01/31/2016 12:19 PM, Mats Peterson wrote:
I've obviously missed that one, Michael, but I don't see the reason
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 hours.
>
> By replacing with an O(N) loop, this takes virtuall
On 01/31/2016 12:28 PM, Mats Peterson wrote:
On 01/31/2016 12:27 PM, Mats Peterson wrote:
On 01/31/2016 12:25 PM, Mats Peterson wrote:
On 01/31/2016 12:19 PM, Mats Peterson wrote:
I've obviously missed that one, Michael, but I don't see the reason to
switch to monow whatsoever. The space savin
On Sun, 31 Jan 2016 12:35:20 +0100
Mats Peterson wrote:
> On 01/31/2016 12:31 PM, Mats Peterson wrote:
> > On 01/31/2016 12:28 PM, Mats Peterson wrote:
> >> On 01/31/2016 12:27 PM, Mats Peterson wrote:
> >>> On 01/31/2016 12:25 PM, Mats Peterson wrote:
> On 01/31/2016 12:19 PM, Mats Pe
On 01/31/2016 01:10 PM, wm4 wrote:
On Sun, 31 Jan 2016 12:35:20 +0100
Mats Peterson wrote:
On 01/31/2016 12:31 PM, Mats Peterson wrote:
On 01/31/2016 12:28 PM, Mats Peterson wrote:
On 01/31/2016 12:27 PM, Mats Peterson wrote:
On 01/31/2016 12:25 PM, Mats Peterson wrote:
On 01/31/2016 12:19
Kristian netvigator.com> writes:
> I have uploaded a 10MB sample to the incoming folder of the ftp
> server and an explanatory file.
Uploaded to http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket4469/
I don't know if one stream really contains more than
one subtitle language.
Thank you for the
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 patch". Furthermore, to me it's highly
unncecessary to use monowhite whatsoever. The space savings are quite
irrelevant nowadays
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 patch". Furthermore, to me it's highly
> unncecessary to use mono
On 01/31/2016 01:33 PM, 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 patch". Furthermore, to me it's high
Paul B Mahol gmail.com> writes:
> > Patch applied.
>
> Did you just pushed patch that overreads or leaves
> uninitialized data?
How can I reproduce this?
> That's big nono.
Of course but valgrind shows no issues here.
Carl Eugen
___
ffmpeg-devel
Minor fix.
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 v2] lavc/rawdec: Only use AV_PIX_FMT_PAL8 for 1 bpp video
Minor fix.
---
libavco
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 changed, 16 insertions(+), 11 deletions(-)
diff --git a/ffprobe.c b/ffprobe.c
ind
CC'd Clement, side he added it originally.;
Derek Buitenhuis (2):
avutil: Add GOP timecode frame side data
mpeg12dec: Export GOP timecodes as side data
ffprobe.c | 8
libavcodec/mpeg12dec.c | 19 ---
libavutil/frame.h | 7 ++-
libavutil/versio
Signed-off-by: Derek Buitenhuis
---
libavutil/frame.h | 7 ++-
libavutil/version.h | 4 ++--
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/libavutil/frame.h b/libavutil/frame.h
index 406c8b5..e07922d 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -116,7 +116,12 @
On 1/31/2016 1:13 PM, Derek Buitenhuis wrote:
> -if (dec_ctx->timecode_frame_start >= 0) {
> -char tcbuf[AV_TIMECODE_STR_SIZE];
> -av_timecode_make_mpeg_tc_string(tcbuf,
> dec_ctx->timecode_frame_start);
> -print_str("timecode", tcbuf);
>
On 01/31/2016 02:43 PM, Michael Niedermayer wrote:
the space savings are significant, heres a 10second video to show this
Of course they are significant (8 times less), but they are quite
irrelevant nowadays with the amounts of memory we have today, as I have
stated in the description of the
On Sun, Jan 31, 2016 at 12:19:21PM +0100, Mats Peterson wrote:
> On 01/31/2016 11:31 AM, Michael Niedermayer wrote:
> >On Sun, Jan 31, 2016 at 01:34:46AM +0100, Mats Peterson wrote:
> >>On 01/30/2016 05:10 AM, Mats Peterson wrote:
> >>>Now when both AVI and QuickTime use pal8 for 1 bpp video, there
Umair Khan (1):
docs: explain properly how -fs works
doc/ffmpeg.texi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--
2.5.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
---
doc/ffmpeg.texi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index 7d3266a..07b7759 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -297,7 +297,8 @@ see @ref{time duration syntax,,the Time duration section in
the ffmpeg-utils(1)
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
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 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 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 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:
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 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 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
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
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,
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
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: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
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: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 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 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: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 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 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 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 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 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,
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
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
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
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: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, 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 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 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 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 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 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 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: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 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 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 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
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, 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:
> >
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, 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 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 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
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 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
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 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 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 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:/
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 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
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 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 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 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: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: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 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 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 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 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 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".
1 - 100 of 126 matches
Mail list logo
