Peter B. das-werkstatt.com> writes:
> Replaced the reference files accordingly
This cannot be done, we want to run fate (also)
with old sources.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmp
Hendrik Leppkes gmail.com> writes:
> > Does someone want to keep it?
Was the question about the release branch or about
master?
> Yes, I want to keep it. It works much better for
> me than the old one.
All LAV users use the new demuxer?
Isn't seeking broken for many files?
Can you point me
On Sun, Aug 30, 2015 at 08:53:37PM -0400, Ronald S. Bultje wrote:
> Hi,
>
> On Sat, Aug 29, 2015 at 10:23 PM, Michael Niedermayer
> wrote:
>
> > From: Michael Niedermayer
> >
> > This is needed for vf_mcfps, no codec related structs are part of the
> > public interface
> >
> > Signed-off-by: Mi
Hi.
I've now cleaned up a few things in the current FFV1 tests:
- Changed "ffv1.X" to "ffv1-vX", removing necessity for vcodec argument.
- Added linebreaks to FFV1 FATE tests for better readability.
- Renamed pix_fmts wording in test target name to match pix_fmt parameter.
Replaced the reference
Hi,
On Sat, Aug 29, 2015 at 10:23 PM, Michael Niedermayer
wrote:
> From: Michael Niedermayer
>
> This is needed for vf_mcfps, no codec related structs are part of the
> public interface
>
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/Makefile |2 +-
> libavcodec/avme.c |
On Sun, Aug 30, 2015 at 10:24:44PM +0200, Peter B. wrote:
> Hello,
>
> I've read the documentation on FATE tests, and would like to add new ones.
> How can I reset the FATE test data for certain targets, without having
> to re-run the whole test suite?
something like
make -j8 -k fate-this fate-th
This is mostly useful if libass was compiled with a font provider
other than fontconfig, but is still useful in that case.
Signed-off-by: Ricardo Constantino
---
doc/filters.texi | 4
libavfilter/vf_subtitles.c | 4
2 files changed, 8 insertions(+)
diff --git a/doc/filters.t
On Mon, Aug 31, 2015 at 12:15 AM, Andreas Cadhalpun
wrote:
> Hi,
>
> On 29.08.2015 04:28, Michael Niedermayer wrote:
>> Its about 2 and a half month since 2.7
>> if there are no objections then ill branch of release/2.8 from
>> some revission prior to the next API bump and will then make a 2.8
>>
On 8/29/15, wm4 wrote:
> On Sat, 29 Aug 2015 04:28:41 +0200
> Michael Niedermayer wrote:
>
>> Hi all
>>
>> Its about 2 and a half month since 2.7
>> if there are no objections then ill branch of release/2.8 from
>> some revission prior to the next API bump and will then make a 2.8
>> release from
On 8/30/15, Andreas Cadhalpun wrote:
> Hi,
>
> On 29.08.2015 04:28, Michael Niedermayer wrote:
>> Its about 2 and a half month since 2.7
>> if there are no objections then ill branch of release/2.8 from
>> some revission prior to the next API bump and will then make a 2.8
>> release from that, aft
Andy Furniss wrote:
mpv -fs -vf=lavfi=[yadif=1] ...
While playing with a bff file I just noticed that only works by luck.
It seems mpv doesn't read field order from .y4m so if it's bff you need
mpv -fs -vf=lavfi=[setfield=bff,yadif=1] ...
___
ffm
Hi,
On 29.08.2015 04:28, Michael Niedermayer wrote:
> Its about 2 and a half month since 2.7
> if there are no objections then ill branch of release/2.8 from
> some revission prior to the next API bump and will then make a 2.8
> release from that, after testing
> if you want something in the relea
Hi,
On Sat, Aug 22, 2015 at 1:57 PM, Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:
> This fixes building with FF_API_QSCALE_TYPE disabled.
>
> Signed-off-by: Andreas Cadhalpun
> ---
> libavcodec/version.h | 3 ---
> libavutil/internal.h | 7 +++
> libavutil/version.h | 3 +++
Hi,
On Sun, Aug 30, 2015 at 5:56 PM, Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:
> On 22.08.2015 19:58, Andreas Cadhalpun wrote:
> > Without this fate-filter-join fails with
> > FF_API_GET_CHANNEL_LAYOUT_COMPAT disabled.
> >
> > Signed-off-by: Andreas Cadhalpun
> > ---
> >
> > T
On 22.08.2015 19:58, Andreas Cadhalpun wrote:
> Without this fate-filter-join fails with
> FF_API_GET_CHANNEL_LAYOUT_COMPAT disabled.
>
> Signed-off-by: Andreas Cadhalpun
> ---
>
> The filter-formats reference needs to be updated, when
> FF_API_GET_CHANNEL_LAYOUT_COMPAT gets disabled:
>
> --- a
On 22.08.2015 19:57, Andreas Cadhalpun wrote:
> This fixes building with FF_API_QSCALE_TYPE disabled.
>
> Signed-off-by: Andreas Cadhalpun
> ---
> libavcodec/version.h | 3 ---
> libavutil/internal.h | 7 +++
> libavutil/version.h | 3 +++
> 3 files changed, 10 insertions(+), 3 deletions(-)
On 22.08.2015 20:30, Ronald S. Bultje wrote:
> Hi,
>
> On Sat, Aug 22, 2015 at 1:57 PM, Andreas Cadhalpun <
> andreas.cadhal...@googlemail.com> wrote:
>
>> This fixes fate with FF_API_LAVF_BITEXACT disabled.
>
>
> Does this fix lavf-mov? I couldn't get that one to work...
>
> Patch OK.
Pushed
On 25.08.2015 00:54, Andreas Cadhalpun wrote:
> On 25.08.2015 00:19, Michael Niedermayer wrote:
>> On Tue, Aug 25, 2015 at 12:03:59AM +0200, Andreas Cadhalpun wrote:
>>> On 24.08.2015 02:22, Michael Niedermayer wrote:
is below diff better: ?
iam quite unsure how to word this
usi
On 22.08.2015 18:42, Andreas Cadhalpun wrote:
> On 16.08.2015 18:15, Andreas Cadhalpun wrote:
>> av_buffersink_poll_frame has been deprecated since 2013 (commit
>> 7e6c67dd7e6c67dd).
>> By now it isn't really used anymore, so I doubt many would miss it.
>
> I intend to push the patch as is tomorr
Robert Krüger wrote:
On Sun, Aug 30, 2015 at 1:45 PM, Andy Furniss
wrote:
Carl Eugen Hoyos wrote:
Robert Krüger lesspain.de> writes:
The only other thing I noticed was that the stream seams to be
marked as interlaced when it comes out of the first il filter,
which causes warnings like the
Paul B Mahol wrote:
On 8/30/15, Andy Furniss wrote:
Oh, il stacks the fields, I was thinking of the filter that just
produces fields like mplayer tfields=0 (I never can remember what the
ffmpeg filter that does the same is called).
separatefields
Thanks, I have a mental block on rememberi
Hello,
I've read the documentation on FATE tests, and would like to add new ones.
How can I reset the FATE test data for certain targets, without having
to re-run the whole test suite?
Thank in advance,
Pb
___
ffmpeg-devel mailing list
ffmpeg-devel@ffm
On 08/30/2015 09:32 PM, Michael Niedermayer wrote:
>> - Target "fate-vsynth%-*" tests default to sws_flags
>> "accurate_rnd+bitexact". FFV1.3 tests have "neighbor+bitexact". Why?
> it makes more cases lossless IIRC
> the default upscaling + default downscaling is not binary identical
Roger tha
On 8/26/15, Nicolas George wrote:
> It has no longer any effect.
>
> Signed-off-by: Nicolas George
> ---
> libavfilter/af_afade.c | 1 -
> libavfilter/af_asetnsamples.c | 1 -
> libavfilter/af_atempo.c| 2 --
> libavfilter/af_compand.c | 1 -
> libavfilter/af_dynaudnor
On 8/26/15, Nicolas George wrote:
> It requires a loop in filters or the framework,
> that makes the scheduling less efficient and more complex.
> This is purely an internal change since the loop is now
> present in buffersink.
> Note that no filter except buffersink did rely on the requirement.
>
On Sun, Aug 30, 2015 at 07:06:44PM +0200, Peter B. wrote:
> Hello,
>
> I've been working on FATE tests for FFV1 in the past already [1]. My
> tests didn't work on all platforms and therefore never made it upstream.
> I think it's better if I try to provide these new tests in smaller
> chunks now :
On 8/30/15, wm4 wrote:
> On Sun, 30 Aug 2015 18:09:05 + (UTC)
> Carl Eugen Hoyos wrote:
>
>> wm4 googlemail.com> writes:
>>
>> > Change the default to blend with black, which
>> > gives generally expected results.
>>
>> Given that this introduces a speed regression, is
>> rarely needed and i
wm4 googlemail.com> writes:
> > And "black" may be sensible for prores, in all
> > other cases, it is either suboptimal or bad.
>
> Such as? Name all the counter examples you know. I'm curious.
I already told you:
laraShadow_dl.flv
> But side from that, blending with _any_ color is
> still m
On Sun, Aug 30, 2015 at 8:22 PM, wm4 wrote:
> On Sun, 30 Aug 2015 18:09:05 + (UTC)
> Carl Eugen Hoyos wrote:
>
>> wm4 googlemail.com> writes:
>>
>> > Change the default to blend with black, which
>> > gives generally expected results.
>>
>> Given that this introduces a speed regression, is
>
On Sun, 30 Aug 2015 18:09:05 + (UTC)
Carl Eugen Hoyos wrote:
> wm4 googlemail.com> writes:
>
> > Change the default to blend with black, which
> > gives generally expected results.
>
> Given that this introduces a speed regression, is
> rarely needed and it is immediately visible that
>
On Sun, 30 Aug 2015 18:09:05 + (UTC)
Carl Eugen Hoyos wrote:
> wm4 googlemail.com> writes:
>
> > Change the default to blend with black, which
> > gives generally expected results.
>
> Given that this introduces a speed regression, is
> rarely needed and it is immediately visible that
>
wm4 googlemail.com> writes:
> Change the default to blend with black, which
> gives generally expected results.
Given that this introduces a speed regression, is
rarely needed and it is immediately visible that
the function is needed, I don't think this is a
sensible change.
Note that contr
On 08/30/2015 07:33 PM, Paul B Mahol wrote:
> On 8/30/15, Peter B. wrote:
>> This will produce quite a number of tests :(
>> I guess it is desired to keep the number of tests as low as necessary?
> Not at all. Just look at ffv1 coverage at coverage.ffmpeg.org
:)
I'd love to add tests for FFV1 to
On 8/30/15, Peter B. wrote:
> Hello,
>
> I've been working on FATE tests for FFV1 in the past already [1]. My
> tests didn't work on all platforms and therefore never made it upstream.
> I think it's better if I try to provide these new tests in smaller
> chunks now :)
>
>
> First of all, there ar
Hello,
I've been working on FATE tests for FFV1 in the past already [1]. My
tests didn't work on all platforms and therefore never made it upstream.
I think it's better if I try to provide these new tests in smaller
chunks now :)
First of all, there are things I find inconsistent or confusing wi
On 8/30/15, Ganesh Ajjanagadde wrote:
> Signed-off-by: Ganesh Ajjanagadde
> ---
> libavfilter/vf_separatefields.c | 30 +++---
> 1 file changed, 15 insertions(+), 15 deletions(-)
>
applied
___
ffmpeg-devel mailing list
ffmpeg-d
Signed-off-by: Ganesh Ajjanagadde
---
libavfilter/vf_separatefields.c | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/libavfilter/vf_separatefields.c b/libavfilter/vf_separatefields.c
index 42ce682..3ea5eb6 100644
--- a/libavfilter/vf_separatef
The old default for alpha -> non-alpha conversion was discarding the
alpha channel without. This meant that parts of the image which were not
meant to be visible became visible. This was a problem for video which
actually contained and used alpha. It can affect PNGs with an alpha
channel as well -
On 8/30/15, Donny Yang wrote:
> On 31 August 2015 at 00:58, Paul B Mahol wrote:
>
>> On 8/28/15, Donny Yang wrote:
>> > Signed-off-by: Donny Yang
>> > ---
>> > libavcodec/pngdec.c | 98
>> > -
>> > 1 file changed, 89 insertions(+), 9 deletion
On 8/28/15, Donny Yang wrote:
> Signed-off-by: Donny Yang
> ---
> libavcodec/pngdec.c | 98
> -
> 1 file changed, 89 insertions(+), 9 deletions(-)
>
> diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
> index 6e7eae0..1153d65 100644
> ---
and decoder
---
tests/fate/subtitles.mak | 3 ++
tests/ref/fate/sub-sami2 | 91
2 files changed, 94 insertions(+)
create mode 100644 tests/ref/fate/sub-sami2
diff --git a/tests/fate/subtitles.mak b/tests/fate/subtitles.mak
index d8b2034..f5270ea
footer in the last packet
---
libavformat/samidec.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/libavformat/samidec.c b/libavformat/samidec.c
index 948e1ed..bc9b745 100644
--- a/libavformat/samidec.c
+++ b/libavformat/samidec.c
@@ -68,11 +68,17 @@ static int sami_rea
---
libavcodec/Makefile | 2 +-
libavcodec/samidec.c| 45 -
tests/ref/fate/sub-sami | 18 +-
3 files changed, 38 insertions(+), 27 deletions(-)
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index d1ffb12..1045d7a 100644
This code will be used in SAMI decoder in a later commit.
---
libavcodec/Makefile| 2 +-
libavcodec/htmlsubtitles.c | 177 +
libavcodec/htmlsubtitles.h | 29
libavcodec/srtdec.c| 149 +-
4 f
On Sun, Aug 30, 2015 at 01:50:28PM +0300, Ivan Uskov wrote:
> Hello Michael,
>
> Thursday, August 27, 2015, 6:47:43 PM, you wrote:
>
> MN> On Thu, Aug 27, 2015 at 11:02:44AM +0200, Sven Dueking wrote:
> >> > -Ursprüngliche Nachricht-
> >> > Von: ffmpeg-devel [mailto:ffmpeg-devel-boun...@f
On 8/30/15, Andy Furniss wrote:
> Andy Furniss wrote:
>> Carl Eugen Hoyos wrote:
>>> Robert Krueger lesspain.de> writes:
>>>
The only other thing I noticed was that the stream seams to be
marked as interlaced when it comes out of the first il filter,
which causes warnings like thes
Andy Furniss wrote:
Carl Eugen Hoyos wrote:
Robert Krüger lesspain.de> writes:
The only other thing I noticed was that the stream seams to be
marked as interlaced when it comes out of the first il filter,
which causes warnings like these:
[Parsed_framerate_10x7fa4e3426080] Interlaced fra
On Sun, Aug 30, 2015 at 1:45 PM, Andy Furniss wrote:
> Carl Eugen Hoyos wrote:
>
>> Robert Krüger lesspain.de> writes:
>>
>> The only other thing I noticed was that the stream seams to be
>>> marked as interlaced when it comes out of the first il filter,
>>> which causes warnings like these:
>>>
Carl Eugen Hoyos wrote:
Robert Krüger lesspain.de> writes:
The only other thing I noticed was that the stream seams to be
marked as interlaced when it comes out of the first il filter,
which causes warnings like these:
[Parsed_framerate_10x7fa4e3426080] Interlaced frame found -
the output
On Sun, Aug 30, 2015 at 4:23 AM, Michael Niedermayer
wrote:
> From: Michael Niedermayer
>
> Works well with some scenes, works really not well with others
> if you can improve it, i would not be unhappy
>
> this should not be optimized yet except trivial things, first the code
> should work well
> I have to admit I did not consider using yadif in a frame-for-each-field
> mode. If the results are better this way would have to be tested but the
> result of my initial test with deinterleaving and reinterleaving looked
> good and I also looked at the results on a progressive display using VLC
Hello Michael,
Thursday, August 27, 2015, 6:47:43 PM, you wrote:
MN> On Thu, Aug 27, 2015 at 11:02:44AM +0200, Sven Dueking wrote:
>> > -Ursprüngliche Nachricht-
>> > Von: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] Im Auftrag
>> > von Sven Dueking
>> > Gesendet: Freitag, 21. Au
On Sun, Aug 30, 2015 at 09:55:36AM +0200, Sébastien Cramatte wrote:
> Hello,
>
> I've made a small patch to add support for strftime on HLS segment
> names template.
> Now you can use "strftime" template with hls segmenter in the same
> way as with ssegmenter.
>
> https://github.com/scramatte/F
On Fri, Aug 28, 2015 at 08:33:07PM -0700, Yayoi wrote:
[...]
> @@ -82,18 +89,18 @@ static int sami_paragraph_to_ass(AVCodecContext *avctx,
> const char *src)
> if (*p == '<') {
> if (!av_strncasecmp(p, " av_isspace(p[2])))
> break;
> -
Hello,
I've made a small patch to add support for strftime on HLS segment
names template.
Now you can use "strftime" template with hls segmenter in the same way
as with ssegmenter.
https://github.com/scramatte/FFmpeg/blob/hls_strftime/libavformat/hlsenc.c
Can you please include it to the m
55 matches
Mail list logo
