On Mon, 19 Feb 2018 23:30:24 -0300
James Almer wrote:
> On 2/19/2018 11:16 PM, Michael Niedermayer wrote:
> > On Mon, Feb 19, 2018 at 09:57:35PM +0100, Hendrik Leppkes wrote:
> >> On Mon, Feb 19, 2018 at 8:30 PM, Michael Niedermayer
> >> wrote:
> >>> On Sun, Feb 18, 2018 at 05:58:16PM +,
On 2/19/2018 11:16 PM, Michael Niedermayer wrote:
> On Mon, Feb 19, 2018 at 09:57:35PM +0100, Hendrik Leppkes wrote:
>> On Mon, Feb 19, 2018 at 8:30 PM, Michael Niedermayer
>> wrote:
>>> On Sun, Feb 18, 2018 at 05:58:16PM +, Josh de Kock wrote:
This should be the last of the major API cha
On Mon, Feb 19, 2018 at 09:57:35PM +0100, Hendrik Leppkes wrote:
> On Mon, Feb 19, 2018 at 8:30 PM, Michael Niedermayer
> wrote:
> > On Sun, Feb 18, 2018 at 05:58:16PM +, Josh de Kock wrote:
> >> This should be the last of the major API changes. I'm not entirely
> >> sure if I missed anything.
On Mon, Feb 19, 2018 at 06:45:11PM +0100, Tomas Härdin wrote:
>
> filters.texi | 13 +
> 1 file changed, 13 insertions(+)
> af8d1d10b307cc4123fda3f8a0d5cd3c9e86b7d7
> 0001-Add-vf-scale-example-for-making-pixels-square.patch
> From 9605df7c8402fb8d5fdbb55ae05639338a1ae0a1 Mon Sep
On Mon, Feb 19, 2018 at 10:48:22AM -0800, Philip Langdale wrote:
> In preparation for introducing Colour Range as a buffersrc parameter,
> we need an option type to pass it. This probably seems like overkill
> for an enum with two valid values, but even then you need to do
> string parsing so you m
On Mon, Feb 19, 2018 at 10:48:24AM -0800, Philip Langdale wrote:
[...]
> diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
> index 9f45032e85..21ae709d6b 100644
> --- a/libavfilter/vf_scale.c
> +++ b/libavfilter/vf_scale.c
> @@ -342,11 +342,16 @@ static int config_props(AVFilterLink *out
On 2/19/2018 1:09 PM, James Almer wrote:
> On 2/19/2018 11:37 AM, Carl Eugen Hoyos wrote:
>> 2018-02-17 3:35 GMT+01:00 James Almer :
>>> Defined in a recent revision of https://www.webmproject.org/docs/container/
>>>
>>> Signed-off-by: James Almer
>>> ---
>>> libavformat/matroskadec.c | 4
>>
On Mon, 19 Feb 2018 23:28:47 +
Mark Thompson wrote:
> Examine the supported fourcc list manually and make the best choice,
> then use the external attribute on the frames context to force that
> fourcc. ---
> libavcodec/vaapi_decode.c | 152
> +++---
>
---
tests/fate/filter-video.mak | 4 +++-
tests/ref/fate/filter-fps-start-drop | 11 +++
tests/ref/fate/filter-fps-start-fill | 11 +++
3 files changed, 25 insertions(+), 1 deletion(-)
create mode 100644 tests/ref/fate/filter-fps-start-drop
create mode 100644 tests/ref/
Since the config_props function now references both the input and output
links, rename the 'link' variable to 'outlink'.
Fix up some mismatching indentation.
Don't bother setting the width and height on the outlink; the filter
framework does that for us.
---
libavfilter/vf_fps.c | 16 +++
Second revision of the patch set, incorporating feedback from Nicolas
George.
This also fixes the start_time option, which didn't work at all in the
v1 patch set. I've added some tests based on the behaviour of the old
version of the filter, and adapted the new version to pass them.
The third pa
The old version of the filter had a problem where it would queue up
all of the duplicate frames required to fill a timestamp gap in a
single call to filter_frame. In problematic files - I've hit this in
webcam streams with large gaps due to network issues - this will queue
up a potentially huge num
On Mon, 19 Feb 2018 23:28:46 +
Mark Thompson wrote:
> ---
> libavutil/hwcontext_vaapi.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
> index 68f88ecd6b..af9a136ef0 100644
> --- a/libavutil/hwcontext_va
On Mon, 19 Feb 2018 23:28:45 +
Mark Thompson wrote:
> Adds YUV 4:1:1, 4:4:0 and 4:4:4 - these will be needed for JPEG
> decoding. ---
> libavutil/hwcontext_vaapi.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
> index 2
On Mon, 19 Feb 2018 23:28:44 +
Mark Thompson wrote:
> Also adds some extra fields to the main context structure that may
> be needed by a hwaccel decoder.
> ---
> YUVJ hacks are removed, they will be handled in API-specific code.
>
>
> libavcodec/mjpegdec.c | 74
> +
On Mon, 19 Feb 2018 23:28:49 +
Mark Thompson wrote:
> From: Philip Langdale
>
> ---
> Changelog| 2 +-
> configure| 2 ++
> libavcodec/Makefile | 1 +
> libavcodec/hwaccels.h| 1 +
> libavcodec/mjpegdec.c| 6
> libavcodec/nvdec.c
On Mon, 19 Feb 2018 23:28:43 +
Mark Thompson wrote:
> This is needed by later hwaccel code to tell which encoding process
> was used for a particular frame, because hardware decoders may only
> support a subset of possible methods.
> ---
> libavcodec/avcodec.h | 6 ++
> l
On Fri, Feb 16, 2018 at 11:06 AM, Aman Gupta wrote:
> From: Aman Gupta
>
> ---
> fftools/ffmpeg.c | 1 +
> libavformat/avformat.h | 1 +
> libavformat/dump.c | 2 ++
> libavformat/mpegts.c | 3 +++
> 4 files changed, 7 insertions(+)
>
> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg
On Sat, Feb 17, 2018, at 10:56 AM, Lou Logan wrote:
> LGTM. Sorry for the delay. I'll push by Monday unless someone else wants
> to do so earlier.
Pushed/applied. Thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/li
---
libavutil/hwcontext_vaapi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index 68f88ecd6b..af9a136ef0 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -475,9 +475,9 @@ static int v
Adds YUV 4:1:1, 4:4:0 and 4:4:4 - these will be needed for JPEG decoding.
---
libavutil/hwcontext_vaapi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index 29698d1b27..68f88ecd6b 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/lib
Also adds some extra fields to the main context structure that may
be needed by a hwaccel decoder.
---
YUVJ hacks are removed, they will be handled in API-specific code.
libavcodec/mjpegdec.c | 74 ---
libavcodec/mjpegdec.h | 13 +
2 files
Examine the supported fourcc list manually and make the best choice, then
use the external attribute on the frames context to force that fourcc.
---
libavcodec/vaapi_decode.c | 152 +++---
libavcodec/vaapi_decode.h | 2 +
2 files changed, 132 insertions(+)
From: Philip Langdale
---
Changelog| 2 +-
configure| 2 ++
libavcodec/Makefile | 1 +
libavcodec/hwaccels.h| 1 +
libavcodec/mjpegdec.c| 6
libavcodec/nvdec.c | 1 +
libavcodec/nvdec_mjpeg.c | 86 +
---
Tested on both Intel and AMD. Some issues on both, but they all seem to be on
the driver side.
Changelog | 2 +-
configure | 2 +
libavcodec/Makefile | 1 +
libavcodec/hwaccels.h | 1 +
libavcodec/mjpegdec.c | 6 ++
libavcodec/vaapi_d
This is needed by later hwaccel code to tell which encoding process was
used for a particular frame, because hardware decoders may only support a
subset of possible methods.
---
libavcodec/avcodec.h | 6 ++
libavcodec/mjpegdec.c| 7 +++
tests/ref/fate/api-mj
On Mon, 19 Feb 2018, Aman Gupta wrote:
On Fri, Feb 16, 2018 at 11:22 AM, Stefan Pöschel
wrote:
The supplementary audio descriptor is defined in ETSI EN 300 468 and
provides more details regarding accessibility audio tracks, especially
the normative annex J contains a detailed description of
On Fri, Feb 16, 2018 at 11:22 AM, Stefan Pöschel
wrote:
> The supplementary audio descriptor is defined in ETSI EN 300 468 and
> provides more details regarding accessibility audio tracks, especially
> the normative annex J contains a detailed description of its use.
>
> Its language code (if pre
On Mon, 19 Feb 2018, Michael Niedermayer wrote:
Hi
Its 4 months since 3.4 was branched so its time for a new major release
Is 4.0 or 3.5 preferred ?
4.0
Any name suggestions ?
If there are no objections i will likely make that release in the next weeks
Removal of the nvenc headers was
Hi Tom,
> > if (ctx->texture == 1) {
> > ...
>
> The ordering of sections in a Hap frame is not specified, so you can’t
> assume the first is the colour and the second alpha - you will have to
> query the section types for both sections and choose the appropriate one.
>
Ok
>
> > bytestream2_se
Just a few comments on your review:
On Sun, 2018-02-18 at 19:01 +0100, Nicolas George wrote:
> > @@ -91,31 +94,46 @@ static av_cold int init(AVFilterContext *ctx)
> > {
> > FPSContext *s = ctx->priv;
> >
> > -if (!(s->fifo = av_fifo_alloc_array(2, sizeof(AVFrame*
> > -retur
On Sat, Feb 17, 2018 at 9:57 AM, Hendrik Leppkes wrote:
> On Fri, Feb 16, 2018 at 10:21 PM, Hendrik Leppkes wrote:
>> The GCC generated import libraries don't work properly when being imported
>> by MSVC, resulting in missing symbols at runtime.
>>
>> This reverts 5b5365fe9 and partially reverts
Hi Martin
From 0002-avcodec-hapqa_extract_bsf-add-new-bsf-filter:
> if (ctx->texture == 1) {
> ...
The ordering of sections in a Hap frame is not specified, so you can’t assume
the first is the colour and the second alpha - you will have to query the
section types for both sections and choose
On Mon, Feb 19, 2018 at 8:30 PM, Michael Niedermayer
wrote:
> On Sun, Feb 18, 2018 at 05:58:16PM +, Josh de Kock wrote:
>> This should be the last of the major API changes. I'm not entirely
>> sure if I missed anything.
>
> Moving from a register based system where a user app can register
> an
Hi Nicolas,
On Sun, 2018-02-18 at 19:01 +0100, Nicolas George wrote:
>
> Thanks for the patch. It was something I had in my TODO list for a
> long
> time. The code looks very good. Here are a few comments below. Of
> course
> open to discussion.
Thanks for the review. I'm going to spend some tim
Dear All,
Currently using HLS_TEMP together with HLS_SECOND_LEVEL_SEGMENT_DURATION
and/or HLS_SECOND_LEVEL_SEGMENT_SIZE gives error at end of each segment
writing and the final segment file names do not contain the desired
data. This patch fixes this bug by delaying the initilization of
original
On Mon, Feb 19, 2018 at 08:39:56AM +0100, Felix Matouschek wrote:
> Hello Michael,
>
> do you think the patch could be merged in its current state?
> It is functional, maybe I can do the cosmetic changes later.
> I was a bit busy the last weeks.
>
> Would be nice if it could get into the 3.5 / 4.
On Sun, Feb 18, 2018 at 05:58:16PM +, Josh de Kock wrote:
> This should be the last of the major API changes. I'm not entirely
> sure if I missed anything.
Moving from a register based system where a user app can register
any subset to a system which registers all via an array will
increase
Today, we have a colour range property on decoders and encoders. The
decoder sets the property on itself to reflect what it is decoding,
and the user sets it on the encoder to reflect what is being encoded.
However, we don't support a way to pass it through filter chains and
'ffmpeg' does not make
Certain filters set or modify the output colour range. Today, they
do that per-frame, but now that we have a link property, they need
to set that as well.
Signed-off-by: Philip Langdale
---
libavfilter/avf_showcqt.c | 1 +
libavfilter/avf_showspectrum.c | 1 +
libavfilter/vf_colorspace.c
In preparation for introducing Colour Range as a buffersrc parameter,
we need an option type to pass it. This probably seems like overkill
for an enum with two valid values, but even then you need to do
string parsing so you might as well get it right.
Signed-off-by: Philip Langdale
---
libavuti
This is relatively straightforward; we set the colour range from the
encoder context into the buffersrc parameters and then set the range
on the decoder from the buffersink.
I did not touch ifilter as part of this change, as I'm not sure whether
it is relevant. ifilter initialisation seems to be d
As part of achieving our YUVJ-free future, it needs to be possible
to pass the colour range property from a decoder context to an
encoder context. In the absence of filters, this is obviously
trivial, but as soon as filters are introduced, there needs to
be a way to pass and preserve the property (
From 9605df7c8402fb8d5fdbb55ae05639338a1ae0a1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Mon, 19 Feb 2018 18:42:25 +0100
Subject: [PATCH] Add -vf scale example for making pixels square
This is a common use case.
---
doc/filters.texi | 13 +
1 file changed,
Michael Niedermayer wrote:
>Is 4.0 or 3.5 preferred ?
I would prefer 4.0 for the reasons already mentioned by others.
I suggest as well to move the 2.8 branch from the Releases to
the Old Releases.
>Any name suggestions ?
>I do not agree with what you have to say, but I'll defend to
>the death
On 2/19/2018 1:31 PM, Kieran Kunhya wrote:
> On Mon, 19 Feb 2018 at 16:06 James Almer wrote:
>
>> On 2/19/2018 5:54 AM, Paul B Mahol wrote:
>>> On 2/19/18, James Almer wrote:
On 2/18/2018 10:50 PM, Michael Niedermayer wrote:
> Hi
>
> Its 4 months since 3.4 was branched so its ti
On Mon, 19 Feb 2018 at 16:06 James Almer wrote:
> On 2/19/2018 5:54 AM, Paul B Mahol wrote:
> > On 2/19/18, James Almer wrote:
> >> On 2/18/2018 10:50 PM, Michael Niedermayer wrote:
> >>> Hi
> >>>
> >>> Its 4 months since 3.4 was branched so its time for a new major release
> >>>
> >>> Is 4.0 or
On 2/19/2018 11:37 AM, Carl Eugen Hoyos wrote:
> 2018-02-17 3:35 GMT+01:00 James Almer :
>> Defined in a recent revision of https://www.webmproject.org/docs/container/
>>
>> Signed-off-by: James Almer
>> ---
>> libavformat/matroskadec.c | 4
>> 1 file changed, 4 insertions(+)
>>
>> diff --gi
On 2/19/2018 5:54 AM, Paul B Mahol wrote:
> On 2/19/18, James Almer wrote:
>> On 2/18/2018 10:50 PM, Michael Niedermayer wrote:
>>> Hi
>>>
>>> Its 4 months since 3.4 was branched so its time for a new major release
>>>
>>> Is 4.0 or 3.5 preferred ?
>>
>> Definitely 4.0. With the major bump, the re
On 2/19/18, wm4 wrote:
> On Mon, 19 Feb 2018 09:54:57 +0100
> Paul B Mahol wrote:
>
>> On 2/19/18, James Almer wrote:
>> > On 2/18/2018 10:50 PM, Michael Niedermayer wrote:
>> >> Hi
>> >>
>> >> Its 4 months since 3.4 was branched so its time for a new major release
>> >>
>> >> Is 4.0 or 3.5 pref
2018-02-17 3:35 GMT+01:00 James Almer :
> Defined in a recent revision of https://www.webmproject.org/docs/container/
>
> Signed-off-by: James Almer
> ---
> libavformat/matroskadec.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
On Fri, Feb 16, 2018 at 05:40:03PM +, Aman Gupta wrote:
> On Fri, Feb 16, 2018 at 4:01 AM Matthieu Bouron
> wrote:
>
> > On Thu, Feb 15, 2018 at 07:52:14PM -0800, Aman Gupta wrote:
> > > From: Aman Gupta
> >
> > Hi,
> >
> > >
> > > This refactor splits up the main mediacodec decode loop into
On 2/16/2018 11:35 PM, James Almer wrote:
> Defined in a recent revision of https://www.webmproject.org/docs/container/
>
> Signed-off-by: James Almer
> ---
> libavformat/matroskadec.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/libavformat/matroskadec.c b/libavformat/matroskad
Includes test log of silence_end at eos
---
tests/fate/filter-video.mak | 3 +++
tests/ref/fate/filter-metadata-silencedetect2 | 4
2 files changed, 7 insertions(+)
create mode 100644 tests/ref/fate/filter-metadata-silencedetect2
diff --git a/tests/fate/filter-video.mak b/
rungetavlogs() allows to get avlog messages (instead of stdout)
---
tests/fate-run.sh | 14 ++
1 file changed, 14 insertions(+)
diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index 05f4ca5e20..0f28af5858 100755
--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
@@ -84,6 +84,20 @@ run
---
libavfilter/af_silencedetect.c | 7 +--
tests/ref/fate/filter-metadata-silencedetect | 26 +-
2 files changed, 18 insertions(+), 15 deletions(-)
diff --git a/libavfilter/af_silencedetect.c b/libavfilter/af_silencedetect.c
index b4184c2486..749c3fbcb7
---
libavfilter/af_silencedetect.c | 3 ++-
tests/ref/fate/filter-metadata-silencedetect | 12 ++--
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/libavfilter/af_silencedetect.c b/libavfilter/af_silencedetect.c
index 749c3fbcb7..8973049fe5 100644
--- a/libavf
Fixes ticket #6968
---
libavfilter/af_silencedetect.c | 33 +++--
1 file changed, 27 insertions(+), 6 deletions(-)
diff --git a/libavfilter/af_silencedetect.c b/libavfilter/af_silencedetect.c
index 8973049fe5..6e321a5d97 100644
--- a/libavfilter/af_silencedetect.c
+++
0 is a valid value for silence_start
---
libavfilter/af_silencedetect.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/libavfilter/af_silencedetect.c b/libavfilter/af_silencedetect.c
index c53b9d9218..b4184c2486 100644
--- a/libavfilter/af_silencedetect.c
+++ b/
Set relevant filter parameters such that the result can easily be
checked with a waveform editor.
In particular, it makes it clear the silence_start is not accurate in
the current code.
---
tests/fate/filter-video.mak | 3 +-
tests/ref/fate/filter-metadata-silencedetect | 54
I have updated all the commit messages, and the typo in patch 6/8 is now clean
up - there was no other comment so far.
Please review
Nicolas Gaullier
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
In mono mode, silence is detected in any single channel instead of all
of them simultaneously
---
libavfilter/af_silencedetect.c | 78 +++---
1 file changed, 51 insertions(+), 27 deletions(-)
diff --git a/libavfilter/af_silencedetect.c b/libavfilter/af_silenced
On 16.02.2018 21:09, calvin.wal...@kepstin.ca wrote:
Oops, I forgot to remove this bit from the changelog:
On Fri, 2018-02-16 at 15:02 -0500, Calvin Walton wrote:
TODO: This is still a work in progress. It may have different
behaviour
in some cases from the old fps filter. I have not yet implem
On Mon, 19 Feb 2018 09:54:57 +0100
Paul B Mahol wrote:
> On 2/19/18, James Almer wrote:
> > On 2/18/2018 10:50 PM, Michael Niedermayer wrote:
> >> Hi
> >>
> >> Its 4 months since 3.4 was branched so its time for a new major release
> >>
> >> Is 4.0 or 3.5 preferred ?
> >
> > Definitely 4.0.
On 2/19/18, James Almer wrote:
> On 2/18/2018 10:50 PM, Michael Niedermayer wrote:
>> Hi
>>
>> Its 4 months since 3.4 was branched so its time for a new major release
>>
>> Is 4.0 or 3.5 preferred ?
>
> Definitely 4.0. With the major bump, the removal of ffprobe and WinXP
ffprobe is removed? I'm
65 matches
Mail list logo
