Signed-off-by: James Almer
---
tests/checkasm/Makefile| 3 +
tests/checkasm/checkasm.c | 3 +
tests/checkasm/checkasm.h | 1 +
tests/checkasm/fixed_dsp.c | 169 +
4 files changed, 176 insertions(+)
create mode 100644 tests/checkasm/fixed_ds
Minor changes.
Mats
>From 02aba0be72a6d84873a9eabf1669e921f771c738 Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Tue, 19 Jan 2016 03:38:15 +0100
Subject: [PATCH v2] lavf/qtpalette: Fix incorrect palettes
This patch corrects the colors of the 2 and 4 bpp palettes.
---
libavformat/qtpalett
On Mon, Jan 18, 2016 at 10:53:52AM -0500, Ronald S. Bultje wrote:
> ---
> tests/checkasm/Makefile | 1 +
> tests/checkasm/checkasm.c | 3 ++
> tests/checkasm/checkasm.h | 1 +
> tests/checkasm/videodsp.c | 89
> +++
> 4 files changed, 94 insertions
On 19/01/16 00:18, Michael Niedermayer wrote:
> On Mon, Jan 18, 2016 at 10:49:51PM +, Mark Thompson wrote:
>>
>> ---
>> configure | 4 +
>> libavutil/Makefile | 1 +
>> libavutil/vaapi.c | 497
>> +
>> libavutil/vaapi.h | 123
On Tue, Jan 19, 2016 at 12:33:40AM +0100, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch fixes ticket #4479 here.
>
> Please comment, Carl Eugen
if w/h is set at that point then their values may be unrelated to the
actual w/h values thus the set_sar there is wrong even if w/h is set
the patch
On Mon, Jan 18, 2016 at 10:49:51PM +, Mark Thompson wrote:
>
> ---
> configure | 4 +
> libavutil/Makefile | 1 +
> libavutil/vaapi.c | 497
> +
> libavutil/vaapi.h | 123 +
> 4 files changed, 625 insertions(+)
>
Now that the seek only happens with the right mouse button, it makes
sense to toggle full screen when double-clicking with the left mouse
button, like other video players do.
Signed-off-by: Vittorio Gambaletta
---
Changelog |1 +
ffplay.c | 10 ++
2 files changed, 11 insertions(+
Seeking by clicking on the video window can be annoying, because
the user might click on it accidentally while eg. trying to get
focus on it, and ffplay seeks instead.
This commit changes that behaviour to seek only when the right
mouse button is used to click and drag on the window.
Signed-off-b
Hi!
Attached patch fixes ticket #4479 here.
Please comment, Carl Eugen
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index b1c5b67..0e95ebd 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -1653,7 +1653,8 @@ static int mjpeg_decode_app(MJpegDecodeContext *s)
On Sat, Jan 16, 2016 at 04:19:38PM -0800, Neil Birkbeck wrote:
> Adding mastering display metadata struct to avutil. The mastering display
> metadata contains information
> about the mastering display color volume (SMPTE 2086:2014).
>
> This info comes from HEVC in the SEI_TYPE_MASTERING_DISPLA
On 1/18/2016 7:56 PM, Michael Niedermayer wrote:
> On Mon, Jan 18, 2016 at 04:29:35PM -0300, James Almer wrote:
>> The option became too aggressive with GCC 6, generating nearly 500
>> warnings from static const variables defined in assorted headers
>>
>> Signed-off-by: James Almer
>> ---
>> Compa
---
configure | 1 +
libavfilter/Makefile| 1 +
libavfilter/allfilters.c| 1 +
libavfilter/vf_vaapi_conv.c | 480
4 files changed, 483 insertions(+)
create mode 100644 libavfilter/vf_vaapi_conv.c
diff --git a/confi
On Mon, Jan 18, 2016 at 04:29:35PM -0300, James Almer wrote:
> The option became too aggressive with GCC 6, generating nearly 500
> warnings from static const variables defined in assorted headers
>
> Signed-off-by: James Almer
> ---
> Compare
> http://fate.ffmpeg.org/report.cgi?time=20150921041
---
configure |1 +
libavcodec/Makefile |1 +
libavcodec/allcodecs.c |1 +
libavcodec/vaapi_enc_hevc.c | 1625 +++
4 files changed, 1628 insertions(+)
create mode 100644 libavcodec/vaapi_enc_hevc.c
diff --git a/c
---
configure | 1 +
libavcodec/Makefile | 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/vaapi_enc_h264.c | 968
4 files changed, 971 insertions(+)
create mode 100644 libavcodec/vaapi_enc_h264.c
diff --git a/confi
---
Makefile | 1 +
ffmpeg.c | 5 +
ffmpeg.h | 5 +
ffmpeg_opt.c | 14 ++
ffmpeg_vaapi.c | 622 +
5 files changed, 647 insertions(+)
create mode 100644 ffmpeg_vaapi.c
diff --git a/Makefile b/Makefile
index 7836a2
---
configure | 4 +
libavutil/Makefile | 1 +
libavutil/vaapi.c | 497 +
libavutil/vaapi.h | 123 +
4 files changed, 625 insertions(+)
create mode 100644 libavutil/vaapi.c
create mode 100644 libavutil/vaapi.h
diff
Hi,
Following* is another attempt, eliminating all global state (and making the
user set it up instead).
* Patch 1 loses all of the initialisation code while changing the hardware
context structure to both be compatible with the one currently used by the
decoder and to support locking.
* Pat
Signed-off-by: Marton Balint
---
doc/muxers.texi | 10 ++
libavformat/segment.c | 11 ++-
2 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index a308d3d..c304221 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1100,6 +11
This option can force the segmenter to only start a new segment if a packet
reaches the muxer whithin the specified duration after the segmenting clock
time, which makes it more resilient to backward local time jumps, such as leap
seconds or transition to standard time from daylight savings time.
ffmpeg has a webvtt encoder and decoder already. You can use this command
to convert mpeg2 closed captions into webvtt:
ffmpeg -f lavfi -i 'movie=input.mpg[out0+subcc]' -map s out.vtt
Aman
On Mon, Jan 18, 2016 at 7:25 AM, Sébastien Cramatte
wrote:
> Hi,
>
> We are working on an IPTv project
On 01/18/2016 11:19 AM, Mats Peterson wrote:
This patch corrects the colors of the 2 and 4 bpp palettes. Compare the
output of the two files below in QuickTime in Win or Mac with the FFmpeg
output, before and after the patch is applied (the second file is not so
obvious, but the 4 bpp palette is
The option became too aggressive with GCC 6, generating nearly 500
warnings from static const variables defined in assorted headers
Signed-off-by: James Almer
---
Compare
http://fate.ffmpeg.org/report.cgi?time=20150921041049&slot=x86_64-archlinux-gcc-experimental
with
http://fate.ffmpeg.org/rep
Signed-off-by: Paul B Mahol
---
configure | 3 +
doc/filters.texi | 77 +
libavfilter/Makefile | 1 +
libavfilter/af_afftfilt.c | 396 ++
libavfilter/allfilters.c | 1 +
5 files changed, 478 insertions(+)
c
Hi,
On Mon, Jan 18, 2016 at 10:44 AM, Michael Niedermayer <
mich...@niedermayer.cc> wrote:
> On Sat, Jan 16, 2016 at 02:44:47PM -0500, Ronald S. Bultje wrote:
> > This can overread (either before start or beyond end) of the buffer in
> > Nx1 (i.e. height=1) images.
> >
> > Fixes mozilla bug 12400
---
tests/checkasm/Makefile | 1 +
tests/checkasm/checkasm.c | 3 ++
tests/checkasm/checkasm.h | 1 +
tests/checkasm/videodsp.c | 89 +++
4 files changed, 94 insertions(+)
create mode 100644 tests/checkasm/videodsp.c
diff --git a/tests/checkasm/Ma
On Sat, Jan 16, 2016 at 02:44:47PM -0500, Ronald S. Bultje wrote:
> This can overread (either before start or beyond end) of the buffer in
> Nx1 (i.e. height=1) images.
>
> Fixes mozilla bug 1240080.
> ---
> libavcodec/x86/videodsp.asm | 21 ++---
> 1 file changed, 6 insertions(+)
Hi,
We are working on an IPTv project using FFMPEG.
Now we stream Live TV channels in HLS format.
We need to add Webvtt subtitles but as fare as I known Ffmpeg doesn't support
it yet.
We have make some lab test using CCExtractor + Home made Webvtt perl
segmenter and it works but we are
u
On 01/18/2016 03:14 PM, Michael Niedermayer wrote:
Specification for details.
applied
thanks
If grave complaints arise, we can always resort to something else.
Thanks, Michael.
Mats
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ff
Signed-off-by: Paul B Mahol
---
Partially working, it can switch video only and audio only streams.
I'm thinking about doing only one single output of single media type,
so there would be astreamselect and streamselect filter.
I don't think current behaviour is possible, or even useful if not too
On Sun, Jan 17, 2016 at 10:50:42PM +0100, Mats Peterson wrote:
> Alright Michael, I'm not entirely sure of what I'm doing regarding
> the FFALIGN(avctx->width, 32), but at least the two odd-width (113
> and 129 pixels) 1 bpp files that failed to render correctly with the
> last patch now seem to be
On Thu, Jan 14, 2016 at 18:29:42 -0600, Rodger Combs wrote:
> > Rodger's commits also introduced *_init() functions for each format.
> > I don't understand whether that is necessary. These patches work
> > for me just as they are.
> The init functions are required because avpriv_set_pts_info is cal
Le nonidi 29 nivôse, an CCXXIV, Arttu Ylä-Outinen a écrit :
> On 2016-01-16 03:31, Michael Niedermayer wrote:
>
> >its probably rather unlikely but the multiplication could overflow
>
> Thanks for taking a look. I attached an updated patch which checks for
> overflow before multiplying.
>
> - Ar
On 2016-01-16 03:31, Michael Niedermayer wrote:
its probably rather unlikely but the multiplication could overflow
Thanks for taking a look. I attached an updated patch which checks for
overflow before multiplying.
- Arttu
>From 0a8a1a1fffd008d43ec601b7e0a5ed22c2c1f784 Mon Sep 17 00:00:00
Hi,
On Sun, Jan 17, 2016 at 5:59 PM, Henrik Gramner wrote:
> The following patches were recently pushed to x264.
>
> Geza Lore (1):
> x86inc: Add debug symbols indicating sizes of compiled functions
>
> Henrik Gramner (6):
> x86inc: Be more verbose in assertion failures
> x86inc: Improve F
On 01/18/2016 01:45 PM, Mats Peterson wrote:
And please note that this 1 bpp to pal8 conversion doesn't affect AVI,
only QuickTime. AVI will still use AV_PIX_FMT_MONOWHITE. At least until
someone decides otherwise.
There's nothing that says that 1 bpp raw AVI can't have a palette as
well, but
On 01/18/2016 01:25 PM, Mats Peterson wrote:
Or just use version 3 of the patch, by the way.
And please note that this 1 bpp to pal8 conversion doesn't affect AVI,
only QuickTime. AVI will still use AV_PIX_FMT_MONOWHITE. At least until
someone decides otherwise.
Mats
__
On 01/18/2016 01:20 PM, Mats Peterson wrote:
On 01/18/2016 01:17 PM, Michael Niedermayer wrote:
the question is which way its faster, i dont know it. Only testing
can tell
Without testing, I guess was can keep the old way of doing it? I'm
already restoring it here. Yes or no?
Mats
__
On 01/18/2016 01:17 PM, Michael Niedermayer wrote:
the question is which way its faster, i dont know it. Only testing
can tell
Without testing, I guess was can keep the old way of doing it? I'm
already restoring it here. Yes or no?
Mats
___
ffmpeg-
On Mon, Jan 18, 2016 at 12:37:58PM +0100, Mats Peterson wrote:
> On 01/18/2016 12:35 PM, Michael Niedermayer wrote:
> >>>
> >>Pure logic tells me it's faster to just increment than involve a
> >>series of multiplications.
> >
> >its not so simple
> >
> >theres a optimizing compiler between you and
On 01/18/2016 12:07 PM, Mats Peterson wrote:
Unfortunately there is no "pal2" pixel format in FFmpeg...
Should be pal1 of course.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On 01/18/2016 12:35 PM, Michael Niedermayer wrote:
Pure logic tells me it's faster to just increment than involve a
series of multiplications.
its not so simple
theres a optimizing compiler between you and the CPU
the multiplication is a shift really, and the compiler may very well
change th
On Mon, Jan 18, 2016 at 12:18:09PM +0100, Mats Peterson wrote:
> On 01/18/2016 12:02 PM, Michael Niedermayer wrote:
>
> >thats unrelated and should be in a seperate patch if it is faster
> >if its not faster it should not be done
> >
> >you can test the speed with START/STOP_TIMER
> >
> Pure logic
On 01/18/2016 12:23 PM, Michael Niedermayer wrote:
1bpp could be used by qtrle too if the palette allows it
but then qtrle implies mov (with a possible palette)
raw does not imply mov so its possible that it is not intended to be
paletted
Well, perhaps so. But people will have to get used to
On Mon, Jan 18, 2016 at 12:06:17PM +0100, Mats Peterson wrote:
> On 01/18/2016 12:02 PM, Michael Niedermayer wrote:
> >the decoder should check the palette, and if it differs from
> >black+white use PAL8
> >users quite possible could complain if monochrome raw files suddenly
> >become 8 times as la
On 01/18/2016 12:02 PM, Michael Niedermayer wrote:
thats unrelated and should be in a seperate patch if it is faster
if its not faster it should not be done
you can test the speed with START/STOP_TIMER
Pure logic tells me it's faster to just increment than involve a series
of multiplications.
On 01/18/2016 12:06 PM, Mats Peterson wrote:
Well, there were no problems using pal8 all over for 1 bpp video in
lavc/qtrle, so why should it matter now? The fact is 1 bpp video in
QuickTime is NEVER monochrome, it is always palettized, even if the
palette is only 2 colors of black & white.
Mats
On 01/18/2016 12:02 PM, Michael Niedermayer wrote:
the decoder should check the palette, and if it differs from
black+white use PAL8
users quite possible could complain if monochrome raw files suddenly
become 8 times as large when its not needed
Well, there were no problems using pal8 all over
On Mon, Jan 18, 2016 at 08:43:50AM +0100, Mats Peterson wrote:
> Eliminated some calculations inside loops.
>
> Mats
> raw.c|4 ++--
> rawdec.c | 49 +++--
> 2 files changed, 33 insertions(+), 20 deletions(-)
> fc79f935e8da23cc724a5a766e81b1f
On Sat, Jan 16, 2016 at 09:09:21PM +0100, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
[...]
> +static int filter_frame(AVFilterLink *inlink, AVFrame *frame)
> +{
> +AVFilterContext *ctx = inlink->dst;
> +AVFilterLink *outlink = ctx->outputs[0];
> +AFFTFiltContext *s = ctx->priv;
This patch corrects the colors of the 2 and 4 bpp palettes. Compare the
output of the two files below in QuickTime in Win or Mac with the FFmpeg
output, before and after the patch is applied (the second file is not so
obvious, but the 4 bpp palette is incorrect nevertheless):
https://drive.goo
Nicolas George nsup.org> writes:
> Le nonidi 29 nivôse, an CCXXIV, Carl Eugen Hoyos a écrit :
> > The original patch (that does not care about tail
> > since it can't be reached anyway) uses atoi().
> > Is that not ok?
>
> atoi() has undefined behaviours in case of error
How can I produce an
On 01/18/2016 03:52 AM, Mark Thompson wrote:
> On 17/01/16 19:46, Mark Thompson wrote:
>> On 17/01/16 18:46, wm4 wrote:
>>>
>>> There are two issues:
>>> 1. global state in libav* which is not synchronized
>>> 2. thread-safety within
>>>
>>> 1. is is completely unacceptable, because it can trigger
53 matches
Mail list logo
