[FFmpeg-devel] New patch: strftime support for hls segment names template
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 main trunk ? Best regards Sebastien ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/4] avcodec/samidec: use ff_htmlmarkup_to_ass()
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;
> -if (!av_strncasecmp(p, " +}
> +if (!av_strncasecmp(p, " av_bprintf(dst, "\\N");
> -p++;
> -while (*p && *p != '>')
> -p++;
> -if (!*p)
> -break;
> -if (*p == '>')
> +p += 3;
> +while (*p && *p != '>')
> +p++;
*p can be 0 after this
> p++;
so when you execute this, shit happens. That's what I was trying to
explain in the previous patch.
> -continue;
> }
> -if (!av_isspace(*p))
> +if (*p == '\n') {
> +av_bprintf(dst, "\\N");
> +}
Is that really on purpose? is used to force a line break, but is a
real line break supposed to have the same purpose?
[...]
--
Clément B.
pgpAd51xOCU29.pgp
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] New patch: strftime support for hls segment names template
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/FFmpeg/blob/hls_strftime/libavformat/hlsenc.c > > Can you please include it to the main trunk ? thats not a patch please see http://ffmpeg.org/developer.html#Submitting-patches-1 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is dangerous to be right in matters on which the established authorities are wrong. -- Voltaire signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] QSV : Added look ahead rate control mode
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. August 2015 10:18
>> > An: ffmpeg-devel@ffmpeg.org
>> > Cc: Sven Dueking
>> > Betreff: [FFmpeg-devel] [PATCH] QSV : Added look ahead rate control
>> > mode
>> >
>> > From: Sven Dueking
>> >
>> > ---
>> > libavcodec/qsvenc.c | 31 +--
>> > libavcodec/qsvenc.h | 8
>> > libavcodec/qsvenc_h264.c | 12
>> > 3 files changed, 49 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c index
>> > 1532258..1aeab03 100644
>> > --- a/libavcodec/qsvenc.c
>> > +++ b/libavcodec/qsvenc.c
>> > @@ -107,8 +107,16 @@ static int init_video_param(AVCodecContext *avctx,
>> > QSVEncContext *q)
>> > q->param.mfx.RateControlMethod = MFX_RATECONTROL_CBR;
>> > ratecontrol_desc = "constant bitrate (CBR)";
>> > } else if (!avctx->rc_max_rate) {
>> > -q->param.mfx.RateControlMethod = MFX_RATECONTROL_AVBR;
>> > -ratecontrol_desc = "average variable bitrate (AVBR)";
>> > +#if QSV_VERSION_ATLEAST(1,7)
>> > +if (q->look_ahead) {
>> > +q->param.mfx.RateControlMethod = MFX_RATECONTROL_LA;
>> > +ratecontrol_desc = "lookahead (LA)";
>> > +} else
>> > +#endif
>> > +{
>> > +q->param.mfx.RateControlMethod = MFX_RATECONTROL_AVBR;
>> > +ratecontrol_desc = "average variable bitrate (AVBR)";
>> > +}
>> > } else {
>> > q->param.mfx.RateControlMethod = MFX_RATECONTROL_VBR;
>> > ratecontrol_desc = "variable bitrate (VBR)"; @@ -132,6 +140,9
>> > @@ static int init_video_param(AVCodecContext *avctx, QSVEncContext *q)
>> >
>> > break;
>> > case MFX_RATECONTROL_AVBR:
>> > +#if QSV_VERSION_ATLEAST(1,7)
>> > +case MFX_RATECONTROL_LA:
>> > +#endif
>> > q->param.mfx.TargetKbps = avctx->bit_rate / 1000;
>> > q->param.mfx.Convergence = q->avbr_convergence;
>> > q->param.mfx.Accuracy= q->avbr_accuracy;
>> > @@ -151,6 +162,22 @@ static int init_video_param(AVCodecContext *avctx,
>> > QSVEncContext *q)
>> >
>> > q->extparam[0] = (mfxExtBuffer *)&q->extco;
>> >
>> > +#if QSV_VERSION_ATLEAST(1,6)
>> > +q->extco2.Header.BufferId = MFX_EXTBUFF_CODING_OPTION2;
>> > +q->extco2.Header.BufferSz = sizeof(q->extco2);
>> > +
>> > +#if QSV_VERSION_ATLEAST(1,7)
>> > +// valid value range is from 10 to 100 inclusive
>> > +// to instruct the encoder to use the default value this
>> > should be set to zero
>> > +q->extco2.LookAheadDepth= q->look_ahead_depth != 0 ?
>> > FFMAX(10, q->look_ahead_depth) : 0;
>> > +#endif
>> > +#if QSV_VERSION_ATLEAST(1,8)
>> > +q->extco2.LookAheadDS = q->look_ahead_downsampling;
>> > +#endif
>> > +
>> > +q->extparam[1] = (mfxExtBuffer *)&q->extco2;
>> > +
>> > +#endif
>> > q->param.ExtParam= q->extparam;
>> > q->param.NumExtParam = FF_ARRAY_ELEMS(q->extparam);
>> > }
>> > diff --git a/libavcodec/qsvenc.h b/libavcodec/qsvenc.h index
>> > 2316488..2a21f82 100644
>> > --- a/libavcodec/qsvenc.h
>> > +++ b/libavcodec/qsvenc.h
>> > @@ -50,7 +50,12 @@ typedef struct QSVEncContext {
>> > mfxFrameAllocRequest req;
>> >
>> > mfxExtCodingOption extco;
>> > +#if QSV_VERSION_ATLEAST(1,6)
>> > +mfxExtCodingOption2 extco2;
>> > +mfxExtBuffer *extparam[2];
>> > +#else
>> > mfxExtBuffer *extparam[1];
>> > +#endif
>> >
>> > AVFifoBuffer *async_fifo;
>> >
>> > @@ -62,6 +67,9 @@ typedef struct QSVEncContext {
>> > int avbr_accuracy;
>> > int avbr_convergence;
>> > int pic_timing_sei;
>> > +int look_ahead;
>> > +int look_ahead_depth;
>> > +int look_ahead_downsampling;
>> >
>> > char *load_plugins;
>> > } QSVEncContext;
>> > diff --git a/libavcodec/qsvenc_h264.c b/libavcodec/qsvenc_h264.c index
>> > b15f6b2..b569efe 100644
>> > --- a/libavcodec/qsvenc_h264.c
>> > +++ b/libavcodec/qsvenc_h264.c
>> > @@ -71,6 +71,18 @@ static const AVOption options[] = {
>> > { "avbr_convergence", "Convergence of the AVBR ratecontrol",
>> > OFFSET(qsv.avbr_convergence), AV_OPT_TYPE_INT, { .i64 = 0 }, 0,
>> > INT_MAX, VE },
>> > { "pic_timing_sei","Insert picture timing SEI with
>> > pic_struct_syntax element", OFFSET(qsv.pic_timing_sei),
>> > AV_OPT_TYPE_INT, { .i64 = 1 }, 0, 1, VE },
>> >
>> > +#if QSV_VERSION_ATLEAST(1,7)
>> > +{ "look_ahead", "Use VBR algorithm with look ahead",
>> > OFFSET(qsv.look_ahead), AV_OPT_TYPE_INT, { .i64 = 1 }, 0, 1, VE
>> > },
>> > +{ "look_ahead_depth", "Depth of look ahead in number frames",
>> > +OFFSET(qsv.look_ahead_depth), AV_OPT_TYPE_INT, { .i64 = 0 },
Re: [FFmpeg-devel] [PATCH] avfilter: add framerate video filter
> 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 > with yadif as deinterlacer and I didn't see any artifacts when playing the > file. Yes, the idea is to use yadif in full-framerate mode, perform fps conversion and then re-interlace. Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avfilter: add mcfps filter
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 then it should be made to work fast > > I did some initial tests blowing up a suitable 60 fps sample (person running) to 240 fps. - mode linear gave the same results as with the framerate filter (expected) - mode gmc gave me a green screen throughout the video (I got no warning or error, though) - mode obmc looked very promising with very smooth motion in most of the image except some strong artifacts in areas with small moving parts (no idea if this can be improved) The sample I used I cannot share publicly but I can make it available to you if you like. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add framerate video filter
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 will not be correct. This sounds like an issue to me but we probably need an option for il to disable changing the interlaced flag if another usecase for the filter was found. Isn't fields being marked as interlaced correct though? I mean it's not progressive video that is produced, as each field is offset by one line and anything that could process correctly, still needs to know whether a field is top or bottom. I don't know whether the framerate filter can handle fields or not, if it can, there should be code that takes account of top/bottom. If there isn't that code then I guess it really does need de-interlaced progressive full height frames as input. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add framerate video filter
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: >>> >>> [Parsed_framerate_10x7fa4e3426080] Interlaced frame found - >>> the output will not be correct. >>> >> >> This sounds like an issue to me but we probably need an option for il >> to disable changing the interlaced flag if another usecase for the >> filter was found. >> > > Isn't fields being marked as interlaced correct though? > > I mean it's not progressive video that is produced, as each field is > offset by one line and anything that could process correctly, still > needs to know whether a field is top or bottom. > > I don't know whether the framerate filter can handle fields or not, if > it can, there should be code that takes account of top/bottom. If there > isn't that code then I guess it really does need de-interlaced > progressive full height frames as input. > > I guess the point is that the signal can be viewed as progressive after the il filter in deinterleave mode as it has the fields stacked on top of each other in each half of the picture. I thought that's the whole point of il, to apply filters that were not written with interlacing in mind and by this trick (deinterleave, process each field like a progressive picture, reinterleave) get some things done that would not be possible otherwise. Of course that's not really true with respect to picture timing but all progressive spatial filters should work using this approach (not taking into account potential quality side effects that the broadcast guys know best). I think the il filter signaling a progressive picture after deinterleaving would be more correct than signaling interlaced but if there is no consensus, it could let the user decide this using an option. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add framerate video filter
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 frame found - the output will not be correct. This sounds like an issue to me but we probably need an option for il to disable changing the interlaced flag if another usecase for the filter was found. Isn't fields being marked as interlaced correct though? I mean it's not progressive video that is produced, as each field is offset by one line and anything that could process correctly, still needs to know whether a field is top or bottom. I don't know whether the framerate filter can handle fields or not, if it can, there should be code that takes account of top/bottom. If there isn't that code then I guess it really does need de-interlaced progressive full height frames as input. 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). Still seems a bit of a strange way to use the framerate filter - but I haven't tested vs yadif. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add framerate video filter
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 these: [Parsed_framerate_10x7fa4e3426080] Interlaced frame found - the output will not be correct. >>> >>> This sounds like an issue to me but we probably need an option for >>> il to disable changing the interlaced flag if another usecase for >>> the filter was found. >> >> Isn't fields being marked as interlaced correct though? >> >> I mean it's not progressive video that is produced, as each field is >> offset by one line and anything that could process correctly, still >> needs to know whether a field is top or bottom. >> >> I don't know whether the framerate filter can handle fields or not, >> if it can, there should be code that takes account of top/bottom. If >> there isn't that code then I guess it really does need de-interlaced >> progressive full height frames as input. > > 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 > Still seems a bit of a strange way to use the framerate filter - but I > haven't tested vs yadif. > > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] QSV : Added look ahead rate control mode
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...@ffmpeg.org] Im Auftrag
> >> > von Sven Dueking
> >> > Gesendet: Freitag, 21. August 2015 10:18
> >> > An: ffmpeg-devel@ffmpeg.org
> >> > Cc: Sven Dueking
> >> > Betreff: [FFmpeg-devel] [PATCH] QSV : Added look ahead rate control
> >> > mode
> >> >
> >> > From: Sven Dueking
> >> >
> >> > ---
> >> > libavcodec/qsvenc.c | 31 +--
> >> > libavcodec/qsvenc.h | 8
> >> > libavcodec/qsvenc_h264.c | 12
> >> > 3 files changed, 49 insertions(+), 2 deletions(-)
> >> >
> >> > diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c index
> >> > 1532258..1aeab03 100644
> >> > --- a/libavcodec/qsvenc.c
> >> > +++ b/libavcodec/qsvenc.c
> >> > @@ -107,8 +107,16 @@ static int init_video_param(AVCodecContext *avctx,
> >> > QSVEncContext *q)
> >> > q->param.mfx.RateControlMethod = MFX_RATECONTROL_CBR;
> >> > ratecontrol_desc = "constant bitrate (CBR)";
> >> > } else if (!avctx->rc_max_rate) {
> >> > -q->param.mfx.RateControlMethod = MFX_RATECONTROL_AVBR;
> >> > -ratecontrol_desc = "average variable bitrate (AVBR)";
> >> > +#if QSV_VERSION_ATLEAST(1,7)
> >> > +if (q->look_ahead) {
> >> > +q->param.mfx.RateControlMethod = MFX_RATECONTROL_LA;
> >> > +ratecontrol_desc = "lookahead (LA)";
> >> > +} else
> >> > +#endif
> >> > +{
> >> > +q->param.mfx.RateControlMethod = MFX_RATECONTROL_AVBR;
> >> > +ratecontrol_desc = "average variable bitrate (AVBR)";
> >> > +}
> >> > } else {
> >> > q->param.mfx.RateControlMethod = MFX_RATECONTROL_VBR;
> >> > ratecontrol_desc = "variable bitrate (VBR)"; @@ -132,6 +140,9
> >> > @@ static int init_video_param(AVCodecContext *avctx, QSVEncContext *q)
> >> >
> >> > break;
> >> > case MFX_RATECONTROL_AVBR:
> >> > +#if QSV_VERSION_ATLEAST(1,7)
> >> > +case MFX_RATECONTROL_LA:
> >> > +#endif
> >> > q->param.mfx.TargetKbps = avctx->bit_rate / 1000;
> >> > q->param.mfx.Convergence = q->avbr_convergence;
> >> > q->param.mfx.Accuracy= q->avbr_accuracy;
> >> > @@ -151,6 +162,22 @@ static int init_video_param(AVCodecContext *avctx,
> >> > QSVEncContext *q)
> >> >
> >> > q->extparam[0] = (mfxExtBuffer *)&q->extco;
> >> >
> >> > +#if QSV_VERSION_ATLEAST(1,6)
> >> > +q->extco2.Header.BufferId = MFX_EXTBUFF_CODING_OPTION2;
> >> > +q->extco2.Header.BufferSz = sizeof(q->extco2);
> >> > +
> >> > +#if QSV_VERSION_ATLEAST(1,7)
> >> > +// valid value range is from 10 to 100 inclusive
> >> > +// to instruct the encoder to use the default value this
> >> > should be set to zero
> >> > +q->extco2.LookAheadDepth= q->look_ahead_depth != 0 ?
> >> > FFMAX(10, q->look_ahead_depth) : 0;
> >> > +#endif
> >> > +#if QSV_VERSION_ATLEAST(1,8)
> >> > +q->extco2.LookAheadDS = q->look_ahead_downsampling;
> >> > +#endif
> >> > +
> >> > +q->extparam[1] = (mfxExtBuffer *)&q->extco2;
> >> > +
> >> > +#endif
> >> > q->param.ExtParam= q->extparam;
> >> > q->param.NumExtParam = FF_ARRAY_ELEMS(q->extparam);
> >> > }
> >> > diff --git a/libavcodec/qsvenc.h b/libavcodec/qsvenc.h index
> >> > 2316488..2a21f82 100644
> >> > --- a/libavcodec/qsvenc.h
> >> > +++ b/libavcodec/qsvenc.h
> >> > @@ -50,7 +50,12 @@ typedef struct QSVEncContext {
> >> > mfxFrameAllocRequest req;
> >> >
> >> > mfxExtCodingOption extco;
> >> > +#if QSV_VERSION_ATLEAST(1,6)
> >> > +mfxExtCodingOption2 extco2;
> >> > +mfxExtBuffer *extparam[2];
> >> > +#else
> >> > mfxExtBuffer *extparam[1];
> >> > +#endif
> >> >
> >> > AVFifoBuffer *async_fifo;
> >> >
> >> > @@ -62,6 +67,9 @@ typedef struct QSVEncContext {
> >> > int avbr_accuracy;
> >> > int avbr_convergence;
> >> > int pic_timing_sei;
> >> > +int look_ahead;
> >> > +int look_ahead_depth;
> >> > +int look_ahead_downsampling;
> >> >
> >> > char *load_plugins;
> >> > } QSVEncContext;
> >> > diff --git a/libavcodec/qsvenc_h264.c b/libavcodec/qsvenc_h264.c index
> >> > b15f6b2..b569efe 100644
> >> > --- a/libavcodec/qsvenc_h264.c
> >> > +++ b/libavcodec/qsvenc_h264.c
> >> > @@ -71,6 +71,18 @@ static const AVOption options[] = {
> >> > { "avbr_convergence", "Convergence of the AVBR ratecontrol",
> >> > OFFSET(qsv.avbr_convergence), AV_OPT_TYPE_INT, { .i64 = 0 }, 0,
> >> > INT_MAX, VE },
> >> > { "pic_timing_sei","Insert picture timing SEI with
> >> > pic_struct_syntax element", OFFSET(qsv.pic_timing_sei),
> >> > AV_OPT_TYPE_INT, { .i64 = 1 }, 0, 1, VE },
> >> >
> >> > +#if QSV_VERSION_
[FFmpeg-devel] [PATCH 1/4] avcodec/srtdec: factor out HTML parsing code
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 files changed, 209 insertions(+), 148 deletions(-)
create mode 100644 libavcodec/htmlsubtitles.c
create mode 100644 libavcodec/htmlsubtitles.h
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 407c6c3..d1ffb12 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -474,7 +474,7 @@ OBJS-$(CONFIG_SONIC_DECODER) += sonic.o
OBJS-$(CONFIG_SONIC_ENCODER) += sonic.o
OBJS-$(CONFIG_SONIC_LS_ENCODER)+= sonic.o
OBJS-$(CONFIG_SP5X_DECODER)+= sp5xdec.o
-OBJS-$(CONFIG_SRT_DECODER) += srtdec.o ass.o
+OBJS-$(CONFIG_SRT_DECODER) += srtdec.o ass.o htmlsubtitles.o
OBJS-$(CONFIG_SRT_ENCODER) += srtenc.o ass_split.o
OBJS-$(CONFIG_STL_DECODER) += textdec.o ass.o
OBJS-$(CONFIG_SUBRIP_DECODER) += srtdec.o ass.o
diff --git a/libavcodec/htmlsubtitles.c b/libavcodec/htmlsubtitles.c
new file mode 100644
index 000..a138955
--- /dev/null
+++ b/libavcodec/htmlsubtitles.c
@@ -0,0 +1,177 @@
+/*
+ * Copyright (c) 2010 Aurelien Jacobs
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/avstring.h"
+#include "libavutil/common.h"
+#include "libavutil/parseutils.h"
+#include "avcodec.h"
+#include "htmlsubtitles.h"
+
+static int html_color_parse(AVCodecContext *avctx, const char *str)
+{
+uint8_t rgba[4];
+if (av_parse_color(rgba, str, strcspn(str, "\" >"), avctx) < 0)
+return -1;
+return rgba[0] | rgba[1] << 8 | rgba[2] << 16;
+}
+
+enum {
+PARAM_UNKNOWN = -1,
+PARAM_SIZE,
+PARAM_COLOR,
+PARAM_FACE,
+PARAM_NUMBER
+};
+
+typedef struct SrtStack {
+char tag[128];
+char param[PARAM_NUMBER][128];
+} SrtStack;
+
+static void rstrip_spaces_buf(AVBPrint *buf)
+{
+while (buf->len > 0 && buf->str[buf->len - 1] == ' ')
+buf->str[--buf->len] = 0;
+}
+
+void ff_htmlmarkup_to_ass(AVCodecContext *avctx, AVBPrint *dst, const char *in)
+{
+char *param, buffer[128], tmp[128];
+int len, tag_close, sptr = 1, line_start = 1, an = 0, end = 0, count;
+SrtStack stack[16];
+
+stack[0].tag[0] = 0;
+strcpy(stack[0].param[PARAM_SIZE], "{\\fs}");
+strcpy(stack[0].param[PARAM_COLOR], "{\\c}");
+strcpy(stack[0].param[PARAM_FACE], "{\\fn}");
+
+for (; !end && *in; in++) {
+switch (*in) {
+case '\r':
+break;
+case '\n':
+if (line_start) {
+end = 1;
+break;
+}
+rstrip_spaces_buf(dst);
+av_bprintf(dst, "\\N");
+line_start = 1;
+break;
+case ' ':
+if (!line_start)
+av_bprint_chars(dst, *in, 1);
+break;
+case '{':/* skip all {\xxx} substrings except for {\an%d}
+and all microdvd like styles such as {Y:xxx} */
+len = 0;
+an += sscanf(in, "{\\an%*1u}%n", &len) >= 0 && len > 0;
+if ((an != 1 && (len = 0, sscanf(in, "{\\%*[^}]}%n", &len) >= 0 &&
len > 0)) ||
+(len = 0, sscanf(in, "{%*1[CcFfoPSsYy]:%*[^}]}%n", &len) >= 0
&& len > 0)) {
+in += len - 1;
+} else
+av_bprint_chars(dst, *in, 1);
+break;
+case '<':
+tag_close = in[1] == '/';
+len = 0;
+if (sscanf(in+tag_close+1, "%127[^>]>%n", buffer, &len) >= 1 &&
len > 0) {
+if ((param = strchr(buffer, ' ')))
+*param++ = 0;
+if ((!tag_close && sptr < FF_ARRAY_ELEMS(stack)) ||
+( tag_close && sptr > 0 && !strcmp(stack[sptr-1].tag,
buffer))) {
+int i, j, unknown = 0;
+in += len + tag_close;
+if (!tag_close)
+memset(stack+sptr, 0, sizeof(*stack));
+if (!strcmp(buffer, "font")) {
+if (tag_close) {
+
[FFmpeg-devel] [PATCH 2/4] avcodec/samidec: use ff_htmlmarkup_to_ass()
---
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
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -450,7 +450,7 @@ OBJS-$(CONFIG_RV20_DECODER)+= rv10.o
OBJS-$(CONFIG_RV20_ENCODER)+= rv20enc.o
OBJS-$(CONFIG_RV30_DECODER)+= rv30.o rv34.o rv30dsp.o
OBJS-$(CONFIG_RV40_DECODER)+= rv40.o rv34.o rv40dsp.o
-OBJS-$(CONFIG_SAMI_DECODER)+= samidec.o ass.o
+OBJS-$(CONFIG_SAMI_DECODER)+= samidec.o ass.o htmlsubtitles.o
OBJS-$(CONFIG_S302M_DECODER) += s302m.o
OBJS-$(CONFIG_S302M_ENCODER) += s302menc.o
OBJS-$(CONFIG_SANM_DECODER)+= sanm.o
diff --git a/libavcodec/samidec.c b/libavcodec/samidec.c
index 47850e2..6db0ec5 100644
--- a/libavcodec/samidec.c
+++ b/libavcodec/samidec.c
@@ -27,10 +27,13 @@
#include "ass.h"
#include "libavutil/avstring.h"
#include "libavutil/bprint.h"
+#include "htmlsubtitles.h"
typedef struct {
AVBPrint source;
AVBPrint content;
+AVBPrint encoded_source;
+AVBPrint encoded_content;
AVBPrint full;
} SAMIContext;
@@ -41,11 +44,14 @@ static int sami_paragraph_to_ass(AVCodecContext *avctx,
const char *src)
char *tag = NULL;
char *dupsrc = av_strdup(src);
char *p = dupsrc;
+AVBPrint *dst_content = &sami->encoded_content;
+AVBPrint *dst_source = &sami->encoded_source;
+av_bprint_clear(&sami->encoded_content);
av_bprint_clear(&sami->content);
+av_bprint_clear(&sami->encoded_source);
for (;;) {
char *saveptr = NULL;
-int prev_chr_is_space = 0;
AVBPrint *dst = &sami->content;
/* parse & extract paragraph tag */
@@ -82,30 +88,31 @@ static int sami_paragraph_to_ass(AVCodecContext *avctx,
const char *src)
if (*p == '<') {
if (!av_strncasecmp(p, "full);
-if (sami->source.len)
-av_bprintf(&sami->full, "{\\i1}%s{\\i0}\\N", sami->source.str);
-av_bprintf(&sami->full, "%s", sami->content.str);
+if (sami->source.len) {
+ff_htmlmarkup_to_ass(avctx, dst_source, sami->source.str);
+av_bprintf(&sami->full, "{\\i1}%s{\\i0}\\N", sami->encoded_source.str);
+}
+ff_htmlmarkup_to_ass(avctx, dst_content, sami->content.str);
+av_bprintf(&sami->full, "%s", sami->encoded_content.str);
end:
av_free(dupsrc);
@@ -136,6 +143,8 @@ static av_cold int sami_init(AVCodecContext *avctx)
SAMIContext *sami = avctx->priv_data;
av_bprint_init(&sami->source, 0, 2048);
av_bprint_init(&sami->content, 0, 2048);
+av_bprint_init(&sami->encoded_source, 0, 2048);
+av_bprint_init(&sami->encoded_content, 0, 2048);
av_bprint_init(&sami->full,0, 2048);
return ff_ass_subtitle_header_default(avctx);
}
@@ -145,6 +154,8 @@ static av_cold int sami_close(AVCodecContext *avctx)
SAMIContext *sami = avctx->priv_data;
av_bprint_finalize(&sami->source, NULL);
av_bprint_finalize(&sami->content, NULL);
+av_bprint_finalize(&sami->encoded_source, NULL);
+av_bprint_finalize(&sami->encoded_content, NULL);
av_bprint_finalize(&sami->full,NULL);
return 0;
}
diff --git a/tests/ref/fate/sub-sami b/tests/ref/fate/sub-sami
index caa85a2..9eabbd7 100644
--- a/tests/ref/fate/sub-sami
+++ b/tests/ref/fate/sub-sami
@@ -10,12 +10,12 @@ Style:
Default,Arial,16,&Hff,&Hff,&H0,&H0,0,0,0,0,100,100,0,0,1,1,0,2,10
[Events]
Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
-Dialogue: 0,0:00:00.00,0:00:00.01,Default,,0,0,0,,{\i1}Pres. John F. Kennedy
{\i0}\N
-Dialogue: 0,0:00:00.01,0:00:08.80,Default,,0,0,0,,{\i1}Pres. John F. Kennedy
{\i0}\NLet the word go forth, from this time and place to friend and foe alike
that the torch
-Dialogue: 0,0:00:08.80,0:00:19.50,Default,,0,0,0,,{\i1}Pres. John F. Kennedy
{\i0}\Nhas been passed to a new generation of Americans, born in this century,
tempered by war,
-Dialogue: 0,0:00:19.50,0:00:28.00,Default,,0,0,0,,{\i1}Pres. John F. Kennedy
{\i0}\Ndisciplined by a hard and bitter peace, proud of our ancient heritage,
and unwilling to witness
-Dialogue: 0,0:00:28.00,0:00:38.00,Default,,0,0,0,,{\i1}Pres. John F. Kennedy
{\i0}\Nor permit the slow undoing of those human rights to which this nation
has always
-Dialogue: 0,0:00:38.00,0:00:46.00,Default,,0,0,0,,{\i1}Pres. John F. Kennedy
{\i0}\Nbeen committed and to which we are committed today at home and around
the world.
-Dialogue: 0,0:00:46.00,0:01:01.00,Default,,0,0,0,,{\i1}Pres. John F. Kennedy
{\i0}\NLet every nation know, whether it wishes us well or ill, that we shall
pay any price, bear any burden,
-Dialogue: 0,0:01:01.00,0:01:13.00,Default,,0,0,0,,{\i1}Pres. John F. Kennedy
{\i0}\Nmeet any hardship, support a
[FFmpeg-devel] [PATCH 3/4] avformat/samidec:do not include trailing sami
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_read_header(AVFormatContext *s)
while (!ff_text_eof(&tr)) {
AVPacket *sub;
const int64_t pos = ff_text_pos(&tr) - (c != 0);
-int is_sync, n = ff_smil_extract_next_text_chunk(&tr, &buf, &c);
+int is_sync, is_body, n = ff_smil_extract_next_text_chunk(&tr, &buf,
&c);
if (n == 0)
break;
+is_body = !av_strncasecmp(buf.str, "http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 4/4] fate/subtitles: add a new test for SAMI demuxer
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 100644
--- a/tests/fate/subtitles.mak
+++ b/tests/fate/subtitles.mak
@@ -46,6 +46,9 @@ fate-sub-realtext: CMD = fmtstdout ass -i
$(TARGET_SAMPLES)/sub/RealText_capabil
FATE_SUBTITLES_ASS-$(call DEMDEC, SAMI, SAMI) += fate-sub-sami
fate-sub-sami: CMD = fmtstdout ass -i
$(TARGET_SAMPLES)/sub/SAMI_capability_tester.smi
+FATE_SUBTITLES_ASS-$(call DEMDEC, SAMI, SAMI) += fate-sub-sami2
+fate-sub-sami2: CMD = fmtstdout ass -i
$(TARGET_SAMPLES)/sub/SAMI_multilang_tweak_tester.smi
+
FATE_SUBTITLES_ASS-$(call DEMDEC, SRT, SUBRIP) += fate-sub-srt
fate-sub-srt: CMD = fmtstdout ass -i
$(TARGET_SAMPLES)/sub/SubRip_capability_tester.srt
diff --git a/tests/ref/fate/sub-sami2 b/tests/ref/fate/sub-sami2
new file mode 100644
index 000..5bce8a2
--- /dev/null
+++ b/tests/ref/fate/sub-sami2
@@ -0,0 +1,91 @@
+[Script Info]
+; Script generated by FFmpeg/Lavc
+ScriptType: v4.00+
+PlayResX: 384
+PlayResY: 288
+
+[V4+ Styles]
+Format: Name, Fontname, Fontsize, PrimaryColour, SecondaryColour,
OutlineColour, BackColour, Bold, Italic, Underline, StrikeOut, ScaleX, ScaleY,
Spacing, Angle, BorderStyle, Outline, Shadow, Alignment, MarginL, MarginR,
MarginV, Encoding
+Style:
Default,Arial,16,&Hff,&Hff,&H0,&H0,0,0,0,0,100,100,0,0,1,1,0,2,10,10,10,0
+
+[Events]
+Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
+Dialogue: 0,0:00:01.51,0:00:01.51,Default,,0,0,0,,by Psyence
Fictionist\npsyencefiction...@gmail.com
+Dialogue: 0,0:00:01.51,0:00:08.61,Default,,0,0,0,,Sync by: honeybunny and
Kerensky\Nwww.Addic7ed.com
+Dialogue: 0,0:00:10.11,0:00:10.11,Default,,0,0,0,,\N{\b1}사랑과 배신\N탐욕과 살육의
이야기죠{\b0}
+Dialogue:
0,0:00:10.11,0:00:13.98,Default,,0,0,0,,\N{\c&H800080&}The{\c}{\c&HCBC0FF&}re{\c}
{\c&HFF&}is{\c} {\c&HA5FF&}lo{\c}{\c&H&}ve{\c}
{\c&H8000&}and{\c}{\c&H00&}
bet{\c}{\c&HFF&}rayal{\c},\N{\b1}{\c&H808080&}g{\c}r{\c&H808080&}e{\c}e{\c&H808080&}d{\c}
and {\c&HFF&}m{\c}{\c&H808080&}u{\c}{\c&HFF&}rder{\c}{\b0}.
+Dialogue: 0,0:00:17.67,0:00:17.67,Default,,0,0,0,,\N{\c&H&}선악의 정의에
대해서\N대립하는 가치관을 가진{\c}
+Dialogue:
0,0:00:17.67,0:00:21.72,Default,,0,0,0,,\N{\c&HCBC0FF&}{\fs6}It's{\fs}
{\fs8}set{\fs}{\fs10} in {\fs}{\fs12}this{\fs}{\fs14}
intere{\fs}{\fs14}sting{\fs}\N{\fs16} world{\fs}{\fs18} of{\fs}
{\fs20}cont{\fs}{\fs22}rasting{\fs}{\fs24} ideology{\fs}{\c}
+Dialogue: 0,0:00:21.84,0:00:21.84,Default,,0,0,0,,\N{\u1}매력적인 세계에서\N이 모든 것이
펼쳐집니다{\u1}
+Dialogue:
0,0:00:21.84,0:00:23.58,Default,,0,0,0,,\N{\i1}{\c&H9966CC&}of{\c}{\c&HC2A3E0&}
what's{\c} {\c&HE0D1F0&}right{\c} {\c&HFCFAFE&}and{\c} wrong.{\i0}
+Dialogue: 0,0:00:23.69,0:00:23.69,Default,,0,0,0,,\N{\i1}이 주제를 심오한 철학으로\N담아내고
있어요{\i0}
+Dialogue:
0,0:00:23.69,0:00:25.67,Default,,0,0,0,,\N{\fs20}{\c&HFF&}{\s1}It{\s0}{\c}{\fs}
has {\fs15}{\c&H00&}a{\c}{\fs} great
{\fs16}{\c&HFFCC00&}philosophy{\c}{\fs} about it.
+Dialogue: 0,0:00:40.22,0:00:40.22,Default,,0,0,0,,\N{\s1}"왕좌의 게임"은 웨스테로스라는
가상왕국의\N권력 분쟁 이야기입니다{\s0}
+Dialogue: 0,0:00:40.22,0:00:47.94,Default,,0,0,0,,\N{\c&HA5FF&}{\fs26}"Game of
Thrones"{\fs}{\c} {\c&H2A2AA5&}{\b1}is{\b0}{\c}{\c&H&}{\fs24}{\i1}
about{\i0}{\fs}{\c} {\c&H336699&}{\fs14}power{\fs}{\c}{\c&HFF&}
struggles{\c}\N{\c&HA5FF&}{\fs8}in a fantasy{\fs}{\c&HCBC0FF&}
kingdom{\c&HA5FF&}, called {\fs6}Westeros.{\fs}{\c}
+Dialogue: 0,0:00:48.06,0:00:48.06,Default,,0,0,0,,\N철의 왕좌를 둘러싼\N권력 분쟁이죠
+Dialogue: 0,0:00:48.06,0:00:50.76,Default,,0,0,0,,\N{\c&H8000&}And it's a
power struggle\Nfor the Iron Throne,{\c}
+Dialogue: 0,0:00:50.88,0:00:50.88,Default,,0,0,0,,\N{\fs20}왕국의 권력 정점이라고\N할 수
있는 자리에요{\fs}
+Dialogue: 0,0:00:50.88,0:00:53.13,Default,,0,0,0,,\Nwhich is the seat of
power\Nin this kingdom.
+Dialogue: 0,0:00:53.25,0:00:53.25,Default,,0,0,0,,\N전운이 감도네, 네드
+Dialogue: 0,0:00:53.25,0:00:55.07,Default,,0,0,0,,\NThere's a war coming, Ned.
+Dialogue: 0,0:00:56.01,0:00:56.01,Default,,0,0,0,,\N\N언제 누구와 싸우게 될지는 몰라\N하지만
분명 전쟁이 일어날걸세
+Dialogue: 0,0:00:56.01,0:01:00.09,Default,,0,0,0,,\NI don't know when, I don't
know who\Nwould be fighting, but it's coming.
+Dialogue: 0,0:01:01.10,0:01:01.10,Default,,0,0,0,,\N이야기의 핵심은 두 주요 가문의\N권력을 둘러싼
갈등입니다
+Dialogue: 0,0:01:01.10,0:01:07.04,Default,,0,0,0,,\N{\i1}At the core of it
there's a conflict for\Npower between two great houses initially.{\i0}
+Dialogue: 0,0:01:07.16,0:01:07.16,Default,,0,0,0,,\N스타크 가문과 라니스터 가문이죠
+Dialogue: 0,0:01:07.16,0:01:10.04,Default,,0,0,0,,\NHouse Stark and House
Lannister.
+Dialogue: 0,0:01:10.16,0:01:10.16,Default,,0,0,0,,\N그 외에 여러 가문이\N서로 경쟁합니다
+Dialogue: 0,0:01:10.16,0:01:13.25,Default,,0,0,0,,\NThe other major houses
are\Nall contenders as well.
+Dialogue: 0,0:01:13.37,0:01:13.37,Default,,0,0,0,,\N흥미진진하게 정치적으로\N얽혀있는 상황이죠
Re: [FFmpeg-devel] [PATCH] png: Fully support the tRNS chunk
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
> --- a/libavcodec/pngdec.c
> +++ b/libavcodec/pngdec.c
> @@ -21,6 +21,7 @@
>
> //#define DEBUG
>
> +#include "libavutil/avassert.h"
> #include "libavutil/bprint.h"
> #include "libavutil/imgutils.h"
> #include "avcodec.h"
> @@ -59,6 +60,7 @@ typedef struct PNGDecContext {
> int bits_per_pixel;
> int bpp;
> int has_trns;
> +uint8_t transparent_colour_be[6];
>
> uint8_t *image_buf;
> int image_linesize;
> @@ -590,6 +592,7 @@ static int decode_idat_chunk(AVCodecContext *avctx,
> PNGDecContext *s,
> uint32_t length, AVFrame *p)
> {
> int ret;
> +size_t byte_depth = s->bit_depth > 8 ? 2 : 1;
>
> if (!(s->state & PNG_IHDR)) {
> av_log(avctx, AV_LOG_ERROR, "IDAT without IHDR\n");
> @@ -641,6 +644,31 @@ static int decode_idat_chunk(AVCodecContext *avctx,
> PNGDecContext *s,
> return AVERROR_INVALIDDATA;
> }
>
> +if (s->has_trns && s->color_type != PNG_COLOR_TYPE_PALETTE) {
> +switch (avctx->pix_fmt) {
> +case AV_PIX_FMT_RGB24:
> +avctx->pix_fmt = AV_PIX_FMT_RGBA;
> +break;
> +
> +case AV_PIX_FMT_RGB48BE:
> +avctx->pix_fmt = AV_PIX_FMT_RGBA64BE;
> +break;
> +
> +case AV_PIX_FMT_GRAY8:
> +avctx->pix_fmt = AV_PIX_FMT_YA8;
> +break;
> +
> +case AV_PIX_FMT_GRAY16BE:
> +avctx->pix_fmt = AV_PIX_FMT_YA16BE;
> +break;
> +
> +default:
> +av_assert0(0);
> +}
> +
> +s->bpp += byte_depth;
> +}
> +
> if ((ret = ff_thread_get_buffer(avctx, &s->picture,
> AV_GET_BUFFER_FLAG_REF)) < 0)
> return ret;
> if (avctx->codec_id == AV_CODEC_ID_APNG && s->last_dispose_op !=
> APNG_DISPOSE_OP_PREVIOUS) {
> @@ -691,9 +719,21 @@ static int decode_idat_chunk(AVCodecContext *avctx,
> PNGDecContext *s,
> s->zstream.avail_out = s->crow_size;
> s->zstream.next_out = s->crow_buf;
> }
> +
> s->state |= PNG_IDAT;
> -if ((ret = png_decode_idat(s, length)) < 0)
> +
> +/* set image to non-transparent bpp while decompressing */
> +if (s->has_trns && s->color_type != PNG_COLOR_TYPE_PALETTE)
> +s->bpp -= byte_depth;
> +
> +ret = png_decode_idat(s, length);
> +
> +if (s->has_trns && s->color_type != PNG_COLOR_TYPE_PALETTE)
> +s->bpp += byte_depth;
> +
> +if (ret < 0)
> return ret;
> +
> bytestream2_skip(&s->gb, 4); /* crc */
>
> return 0;
> @@ -727,17 +767,33 @@ static int decode_trns_chunk(AVCodecContext *avctx,
> PNGDecContext *s,
> {
> int v, i;
>
> -/* read the transparency. XXX: Only palette mode supported */
> -if (s->color_type != PNG_COLOR_TYPE_PALETTE ||
> -length > 256 ||
> -!(s->state & PNG_PLTE))
> +if (s->color_type == PNG_COLOR_TYPE_PALETTE) {
> +if (length > 256 || !(s->state & PNG_PLTE))
> +return AVERROR_INVALIDDATA;
> +
> +for (i = 0; i < length; i++) {
> +v = bytestream2_get_byte(&s->gb);
> +s->palette[i] = (s->palette[i] & 0x00ff) | (v << 24);
> +}
> +} else if (s->color_type == PNG_COLOR_TYPE_GRAY || s->color_type ==
> PNG_COLOR_TYPE_RGB) {
> +if ((s->color_type == PNG_COLOR_TYPE_GRAY && length != 2) ||
> +(s->color_type == PNG_COLOR_TYPE_RGB && length != 6))
> +return AVERROR_INVALIDDATA;
> +
> +for (i = 0; i < length / 2; i++) {
> +/* only use the least significant bits */
> +v = bytestream2_get_be16(&s->gb) & ((1 << s->bit_depth) - 1);
This can crash if length of trns chunk is > 6.
> +
> +if (s->bit_depth > 8)
> +AV_WB16(&s->transparent_colour_be[2 * i], v);
> +else
> +s->transparent_colour_be[i] = v;
> +}
> +} else {
> return AVERROR_INVALIDDATA;
> -for (i = 0; i < length; i++) {
> -v = bytestream2_get_byte(&s->gb);
> -s->palette[i] = (s->palette[i] & 0x00ff) | (v << 24);
> }
> -bytestream2_skip(&s->gb, 4); /* crc */
>
> +bytestream2_skip(&s->gb, 4); /* crc */
> s->has_trns = 1;
>
> return 0;
> @@ -1122,6 +1178,29 @@ exit_loop:
> if (s->bits_per_pixel <= 4)
> handle_small_bpp(s, p);
>
> +/* apply transparency if needed */
> +if (s->has_trns && s->color_type != PNG_COLOR_TYPE_PALETTE) {
> +size_t byte_depth = s->bit_depth > 8 ? 2 : 1;
> +size_t raw_bpp = s->bpp - byte_depth;
> +unsigned x, y;
> +
> +for (y = 0; y < s->he
Re: [FFmpeg-devel] [PATCH] png: Fully support the tRNS chunk
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 deletions(-)
>> >
>> > diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
>> > index 6e7eae0..1153d65 100644
>> > --- a/libavcodec/pngdec.c
>> > +++ b/libavcodec/pngdec.c
>> > @@ -21,6 +21,7 @@
>> >
>> > //#define DEBUG
>> >
>> > +#include "libavutil/avassert.h"
>> > #include "libavutil/bprint.h"
>> > #include "libavutil/imgutils.h"
>> > #include "avcodec.h"
>> > @@ -59,6 +60,7 @@ typedef struct PNGDecContext {
>> > int bits_per_pixel;
>> > int bpp;
>> > int has_trns;
>> > +uint8_t transparent_colour_be[6];
>> >
>> > uint8_t *image_buf;
>> > int image_linesize;
>> > @@ -590,6 +592,7 @@ static int decode_idat_chunk(AVCodecContext *avctx,
>> > PNGDecContext *s,
>> > uint32_t length, AVFrame *p)
>> > {
>> > int ret;
>> > +size_t byte_depth = s->bit_depth > 8 ? 2 : 1;
>> >
>> > if (!(s->state & PNG_IHDR)) {
>> > av_log(avctx, AV_LOG_ERROR, "IDAT without IHDR\n");
>> > @@ -641,6 +644,31 @@ static int decode_idat_chunk(AVCodecContext
>> > *avctx,
>> > PNGDecContext *s,
>> > return AVERROR_INVALIDDATA;
>> > }
>> >
>> > +if (s->has_trns && s->color_type != PNG_COLOR_TYPE_PALETTE) {
>> > +switch (avctx->pix_fmt) {
>> > +case AV_PIX_FMT_RGB24:
>> > +avctx->pix_fmt = AV_PIX_FMT_RGBA;
>> > +break;
>> > +
>> > +case AV_PIX_FMT_RGB48BE:
>> > +avctx->pix_fmt = AV_PIX_FMT_RGBA64BE;
>> > +break;
>> > +
>> > +case AV_PIX_FMT_GRAY8:
>> > +avctx->pix_fmt = AV_PIX_FMT_YA8;
>> > +break;
>> > +
>> > +case AV_PIX_FMT_GRAY16BE:
>> > +avctx->pix_fmt = AV_PIX_FMT_YA16BE;
>> > +break;
>> > +
>> > +default:
>> > +av_assert0(0);
>> > +}
>> > +
>> > +s->bpp += byte_depth;
>> > +}
>> > +
>> > if ((ret = ff_thread_get_buffer(avctx, &s->picture,
>> > AV_GET_BUFFER_FLAG_REF)) < 0)
>> > return ret;
>> > if (avctx->codec_id == AV_CODEC_ID_APNG && s->last_dispose_op
>> > !=
>> > APNG_DISPOSE_OP_PREVIOUS) {
>> > @@ -691,9 +719,21 @@ static int decode_idat_chunk(AVCodecContext
>> > *avctx,
>> > PNGDecContext *s,
>> > s->zstream.avail_out = s->crow_size;
>> > s->zstream.next_out = s->crow_buf;
>> > }
>> > +
>> > s->state |= PNG_IDAT;
>> > -if ((ret = png_decode_idat(s, length)) < 0)
>> > +
>> > +/* set image to non-transparent bpp while decompressing */
>> > +if (s->has_trns && s->color_type != PNG_COLOR_TYPE_PALETTE)
>> > +s->bpp -= byte_depth;
>> > +
>> > +ret = png_decode_idat(s, length);
>> > +
>> > +if (s->has_trns && s->color_type != PNG_COLOR_TYPE_PALETTE)
>> > +s->bpp += byte_depth;
>> > +
>> > +if (ret < 0)
>> > return ret;
>> > +
>> > bytestream2_skip(&s->gb, 4); /* crc */
>> >
>> > return 0;
>> > @@ -727,17 +767,33 @@ static int decode_trns_chunk(AVCodecContext
>> > *avctx,
>> > PNGDecContext *s,
>> > {
>> > int v, i;
>> >
>> > -/* read the transparency. XXX: Only palette mode supported */
>> > -if (s->color_type != PNG_COLOR_TYPE_PALETTE ||
>> > -length > 256 ||
>> > -!(s->state & PNG_PLTE))
>> > +if (s->color_type == PNG_COLOR_TYPE_PALETTE) {
>> > +if (length > 256 || !(s->state & PNG_PLTE))
>> > +return AVERROR_INVALIDDATA;
>> > +
>> > +for (i = 0; i < length; i++) {
>> > +v = bytestream2_get_byte(&s->gb);
>> > +s->palette[i] = (s->palette[i] & 0x00ff) | (v << 24);
>> > +}
>> > +} else if (s->color_type == PNG_COLOR_TYPE_GRAY || s->color_type
>> > ==
>> > PNG_COLOR_TYPE_RGB) {
>> > +if ((s->color_type == PNG_COLOR_TYPE_GRAY && length != 2) ||
>> > +(s->color_type == PNG_COLOR_TYPE_RGB && length != 6))
>> > +return AVERROR_INVALIDDATA;
>> > +
>> > +for (i = 0; i < length / 2; i++) {
>> > +/* only use the least significant bits */
>> > +v = bytestream2_get_be16(&s->gb) & ((1 << s->bit_depth) -
>> 1);
>>
>> This can crash if length of trns chunk is > 6.
>>
>
> It shouldn't reach this code if the chunk isn't 2 or 6 bytes, since it is
> filtered out by the above check.
Indeed, please ignore.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] swscale: set sane alpha blending defaults
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 - PNGs often have garbage data in completely transparent
regions of the image.
Change the default to blend with black, which gives generally expected
results.
Fixes track issue #4746.
---
libswscale/options.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libswscale/options.c b/libswscale/options.c
index 18a6594..717b6a4 100644
--- a/libswscale/options.c
+++ b/libswscale/options.c
@@ -78,7 +78,7 @@ static const AVOption swscale_options[] = {
{ "gamma", "gamma correct scaling", OFFSET(gamma_flag),
AV_OPT_TYPE_INT,{ .i64 = 0 }, 0, INT_MAX,
VE, "gamma" },
{ "true","enable",0,
AV_OPT_TYPE_CONST, { .i64 = 1 }, INT_MIN, INT_MAX,
VE, "gamma" },
{ "false", "disable", 0,
AV_OPT_TYPE_CONST, { .i64 = 0 }, INT_MIN, INT_MAX,
VE, "gamma" },
-{ "alphablend", "mode for alpha -> non alpha",
OFFSET(alphablend),AV_OPT_TYPE_INT,{ .i64 = SWS_ALPHA_BLEND_NONE}, 0,
SWS_ALPHA_BLEND_NB-1, VE, "alphablend" },
+{ "alphablend", "mode for alpha -> non alpha",
OFFSET(alphablend),AV_OPT_TYPE_INT,{ .i64 = SWS_ALPHA_BLEND_UNIFORM}, 0,
SWS_ALPHA_BLEND_NB-1, VE, "alphablend" },
{ "none","ignore alpha", 0,
AV_OPT_TYPE_CONST, { .i64 = SWS_ALPHA_BLEND_NONE}, INT_MIN, INT_MAX,
VE, "alphablend" },
{ "uniform_color", "blend onto a uniform color",0,
AV_OPT_TYPE_CONST, { .i64 = SWS_ALPHA_BLEND_UNIFORM},INT_MIN, INT_MAX,
VE, "alphablend" },
{ "checkerboard","blend onto a checkerboard", 0,
AV_OPT_TYPE_CONST, { .i64 = SWS_ALPHA_BLEND_CHECKERBOARD},INT_MIN, INT_MAX,
VE, "alphablend" },
--
2.5.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter/vf_separatefields: use the name 's' for the pointer to the private context
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_separatefields.c
+++ b/libavfilter/vf_separatefields.c
@@ -30,10 +30,10 @@ typedef struct {
static int config_props_output(AVFilterLink *outlink)
{
AVFilterContext *ctx = outlink->src;
-SeparateFieldsContext *sf = ctx->priv;
+SeparateFieldsContext *s = ctx->priv;
AVFilterLink *inlink = ctx->inputs[0];
-sf->nb_planes = av_pix_fmt_count_planes(inlink->format);
+s->nb_planes = av_pix_fmt_count_planes(inlink->format);
if (inlink->h & 1) {
av_log(ctx, AV_LOG_ERROR, "height must be even\n");
@@ -64,19 +64,19 @@ static void extract_field(AVFrame *frame, int nb_planes,
int type)
static int filter_frame(AVFilterLink *inlink, AVFrame *inpicref)
{
AVFilterContext *ctx = inlink->dst;
-SeparateFieldsContext *sf = ctx->priv;
+SeparateFieldsContext *s = ctx->priv;
AVFilterLink *outlink = ctx->outputs[0];
int ret;
inpicref->height = outlink->h;
inpicref->interlaced_frame = 0;
-if (!sf->second) {
+if (!s->second) {
goto clone;
} else {
-AVFrame *second = sf->second;
+AVFrame *second = s->second;
-extract_field(second, sf->nb_planes, second->top_field_first);
+extract_field(second, s->nb_planes, second->top_field_first);
if (second->pts != AV_NOPTS_VALUE &&
inpicref->pts != AV_NOPTS_VALUE)
@@ -88,12 +88,12 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
*inpicref)
if (ret < 0)
return ret;
clone:
-sf->second = av_frame_clone(inpicref);
-if (!sf->second)
+s->second = av_frame_clone(inpicref);
+if (!s->second)
return AVERROR(ENOMEM);
}
-extract_field(inpicref, sf->nb_planes, !inpicref->top_field_first);
+extract_field(inpicref, s->nb_planes, !inpicref->top_field_first);
if (inpicref->pts != AV_NOPTS_VALUE)
inpicref->pts *= 2;
@@ -104,15 +104,15 @@ clone:
static int request_frame(AVFilterLink *outlink)
{
AVFilterContext *ctx = outlink->src;
-SeparateFieldsContext *sf = ctx->priv;
+SeparateFieldsContext *s = ctx->priv;
int ret;
ret = ff_request_frame(ctx->inputs[0]);
-if (ret == AVERROR_EOF && sf->second) {
-sf->second->pts *= 2;
-extract_field(sf->second, sf->nb_planes, sf->second->top_field_first);
-ret = ff_filter_frame(outlink, sf->second);
-sf->second = 0;
+if (ret == AVERROR_EOF && s->second) {
+s->second->pts *= 2;
+extract_field(s->second, s->nb_planes, s->second->top_field_first);
+ret = ff_filter_frame(outlink, s->second);
+s->second = 0;
}
return ret;
--
2.5.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vf_separatefields: use the name 's' for the pointer to the private context
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-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Adding FATE tests for FFV1 - revisited
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 with the current tests (vcodec.mak): - ENCOPTS for FFV1.3 contain "-vcodec ffv1" instead of "CODEC=ffv1" (this generates "-c ffv1.3" as parameter?) - Target "fate-vsynth%-*" tests default to sws_flags "accurate_rnd+bitexact". FFV1.3 tests have "neighbor+bitexact". Why? - ENCOPTS for "fate-vsynth%-ffv1" are "-slices 4", which is an FFV1.3-only option. - What is "ffv1.0"? My ideas/plans would be something like this: First steps: 1) Clean the current FFV1 tests (naming, ENCDEC options, etc) 2) Move FFV1 tests to its own file (ffv1.mak). Or at least to "lossless-video.mak". 3) Have separate tests for different FFV1 versions (1,3) Then: 4) Add default argument "-g 1" 5) Add tests to cover the following cases: - Color spaces YUV, RGB, GRAY - bits-per-component as currently supported - YUV subsampling 420, 422, 444 - Alpha channel: YUVA, BGRA Maybe: 6) Multiple coder/context options 7) Multiple slices options 8) Testing SliceCRC This will produce quite a number of tests :( I guess it is desired to keep the number of tests as low as necessary? I've attached my old test Makefile (ffv1.mak), for reference. :D What is the best way to proceed? Thanks in advance, Pb == References: [1] http://ffmpeg.org/pipermail/ffmpeg-user/2013-November/018361.html DEC_SRC = $(TARGET_PATH)/tests/data/fate # Word-size options for PSNR calculations: u8, s16, f32, f64 # Default is "u8" (8bits): fate-ffv1-enc-%: CMP_UNIT = u8 fate-ffv1-enc-%: CODEC = $(word 2, $(subst -, ,$(@))) fate-ffv1-enc-%: FMT = avi fate-ffv1-enc-%: SRC = tests/data/vsynth1.yuv # Limit the duration of test videos to 4 frames at 25fps: fate-ffv1-enc-%: DUR = 0:00:00.160 fate-ffv1-enc-%: CMD = enc_dec "rawvideo -s 352x288 -pix_fmt yuv420p $(RAWDECOPTS) -t $(DUR)" $(SRC) $(FMT) "-c $(CODEC) $(ENCOPTS)" rawvideo "-s 352x288 -pix_fmt yuv420p -vsync 0 $(DECOPTS)" -keep "$(DECINOPTS)" # This Makefile checks for $(CONFIG_...) variables being set, so we can # include/exclude tests accordingly: ifdef CONFIG_AVCONV FLAGS_FFV1_V3 = -strict experimental else FLAGS_FFV1_V3 = endif FATE_FFV1_LEVEL1 = v1-defaults \ v1-gray \ v1-rgb32\ v1-yuv410p \ v1-yuv411p \ v1-yuv420p \ v1-yuv422p \ v1-yuv444p \ v1-bgra \ v1-tff \ v1-bff # Target-specific tests: ifdef CONFIG_FFMPEG FATE_FFV1_LEVEL1 +=v1-bgr0 \ v1-yuv440p \ v1-yuva420p \ v1-yuva422p \ v1-yuva444p endif FATE_FFV1_LEVEL3 = v3-defaults \ v3-rgb32 \ v3-yuv410p \ v3-yuv420p \ v3-yuv422p \ v3-yuv444p \ v3-yuv420p9 \ v3-yuv422p9 \ v3-yuv444p9 \ v3-yuv420p10 \ v3-yuv422p10 \ v3-yuv444p10 \ v3-yuv420p16 \ v3-yuv422p16 \ v3-yuv444p16 \ v3-yuv422p_crc \ v3-yuv422p9_crc \ v3-yuv422p10_crc \ v3-yuv422p16_crc \ v3-yuv422p_pass1 \ v3-yuv422p_pass2 \ v3-tff \ v3-bff # Target-specific tests: ifdef CONFIG_FFMPEG FATE_FFV1_LEVEL3 +=v3-gray \ v3-gray16 \ v3-bgr0 \ v3-gbrp9 \ v3-gbrp10 \ v3-gbrp12 \ v3-gbrp14 \ v3-yuva420p9 \ v3-yuva422p9 \ v3-yuva444p9 \ v3-yuva420p10 \ v3-yuva422p10 \ v3-yuva444p10 \ v3-yuva420p16 \ v3-yuva422p16 \ v3-yuva444p16 endif FATE_FFV1 = $(FATE_FFV1_LEVEL1) \ $(FATE_FFV1_LEVEL3) # FFV1 - version 1 ### # Encoding: ### # YUV (8bit) # - This also iterates through all coder/context combinations. fate-ffv1-enc-v1-defaults: ENCOPTS = -
Re: [FFmpeg-devel] Adding FATE tests for FFV1 - revisited
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 are things I find inconsistent or confusing with the > current tests (vcodec.mak): > > - ENCOPTS for FFV1.3 contain "-vcodec ffv1" instead of "CODEC=ffv1" > (this generates "-c ffv1.3" as parameter?) > - Target "fate-vsynth%-*" tests default to sws_flags > "accurate_rnd+bitexact". FFV1.3 tests have "neighbor+bitexact". Why? > - ENCOPTS for "fate-vsynth%-ffv1" are "-slices 4", which is an > FFV1.3-only option. > - What is "ffv1.0"? > > > My ideas/plans would be something like this: > > First steps: > 1) Clean the current FFV1 tests (naming, ENCDEC options, etc) > 2) Move FFV1 tests to its own file (ffv1.mak). Or at least to > "lossless-video.mak". > 3) Have separate tests for different FFV1 versions (1,3) > > Then: > 4) Add default argument "-g 1" > 5) Add tests to cover the following cases: > - Color spaces YUV, RGB, GRAY > - bits-per-component as currently supported > - YUV subsampling 420, 422, 444 > - Alpha channel: YUVA, BGRA > > Maybe: > 6) Multiple coder/context options > 7) Multiple slices options > 8) Testing SliceCRC > > > 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've attached my old test Makefile (ffv1.mak), for reference. > :D > > > What is the best way to proceed? > > > > Thanks in advance, > Pb > > > > == References: > [1] http://ffmpeg.org/pipermail/ffmpeg-user/2013-November/018361.html > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Adding FATE tests for FFV1 - revisited
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 increase the coverage as much as possible. So, in order to avoid silent regressions in less-common combinations, I've added very detailed test-scenarios (as shown in my "ffv1.mak") previously. Except for a few other codecs (e.g. h264), most only have a handful of tests. So I thought my suggested test-suite was overkill. I'd like to keep the tests as much as necessary, but as little as possible. Regards, Pb ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] swscale: set sane alpha blending defaults
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 contrary to visual issue, the performance regression is not immediately visible. And "black" may be sensible for prores, in all other cases, it is either suboptimal or bad. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] swscale: set sane alpha blending defaults
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 > the function is needed, I don't think this is a > sensible change. Performance is no argument in this case. Alpha video is rare in the first place, so it won't affect most ffmpeg uses. Also, you can assume the alpha channel exists for a reason. As for speed, the user can always disable alpha blending. I'd rather prefer sane, correct default behavior, over fast and broken. > Note that contrary to visual issue, the performance > regression is not immediately visible. It's the other way around. Did you even look at the test video in the issue tracker? Judging whether the result is correct requires manual checking of the whole video. On the other hand, libswscale is an obvious thing to check when the conversion seems to be going too slowly. libswscale is known not to be the fastest, especially with "obscure" pixel formats. > 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. But side from that, blending with _any_ color is still more reasonable than discarding the alpha. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] swscale: set sane alpha blending defaults
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 > the function is needed, I don't think this is a > sensible change. > > Note that contrary to visual issue, the performance > regression is not immediately visible. > > And "black" may be sensible for prores, in all > other cases, it is either suboptimal or bad. > > Carl Eugen PS: there is a 3rd way: make libswscale fail initialization if an alpha conversion happens, but the user didn't specify the alpha mode. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] swscale: set sane alpha blending defaults
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 >> rarely needed and it is immediately visible that >> the function is needed, I don't think this is a >> sensible change. > > Performance is no argument in this case. Alpha video is rare in the > first place, so it won't affect most ffmpeg uses. Also, you can assume > the alpha channel exists for a reason. > > As for speed, the user can always disable alpha blending. I'd rather > prefer sane, correct default behavior, over fast and broken. > >> Note that contrary to visual issue, the performance >> regression is not immediately visible. > > It's the other way around. Did you even look at the test video in the > issue tracker? Judging whether the result is correct requires manual > checking of the whole video. On the other hand, libswscale is an > obvious thing to check when the conversion seems to be going too > slowly. libswscale is known not to be the fastest, especially with > "obscure" pixel formats. > >> 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. > > But side from that, blending with _any_ color is still more reasonable > than discarding the alpha. I agree, simply discarding information is not a good default. Defaults should be for reference quality, and degrading-but-faster modes should be options. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] swscale: set sane alpha blending defaults
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 more reasonable than discarding the alpha. This is unfortunately not true... Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] swscale: set sane alpha blending defaults
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 it is immediately visible that >> the function is needed, I don't think this is a >> sensible change. >> >> Note that contrary to visual issue, the performance >> regression is not immediately visible. >> >> And "black" may be sensible for prores, in all >> other cases, it is either suboptimal or bad. >> >> Carl Eugen > > PS: there is a 3rd way: make libswscale fail initialization if an alpha > conversion happens, but the user didn't specify the alpha mode. That or blending with checkerboard pattern. One of the strongest points in Carl objections is that there is no universal optimal and correct behavior. - In one case you would want to ignore the alpha channel, as it might contain only garbage. - In second case, you'd want to blend it with white color, because the flv is encoded with it in mind. - In this case, the proress encoding assumes blending with black color. Since there is no single optimal solution, we should force the user in picking the correct mode himself. I think the default should be blending with checkerboard pattern. It is immediately recognized as alpha artifact, so the user would know what the reason for the issue. Even better - print a hint about 'alphablend' and its modes to console. Of course, ideally there should be some metadata gimmick to set blend-to-white with .flv and blend-to-black for proress. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Adding FATE tests for FFV1 - revisited
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 :) > > > First of all, there are things I find inconsistent or confusing with the > current tests (vcodec.mak): > > - ENCOPTS for FFV1.3 contain "-vcodec ffv1" instead of "CODEC=ffv1" > (this generates "-c ffv1.3" as parameter?) > - 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 > - ENCOPTS for "fate-vsynth%-ffv1" are "-slices 4", which is an > FFV1.3-only option. > - What is "ffv1.0"? > > > My ideas/plans would be something like this: > > First steps: > 1) Clean the current FFV1 tests (naming, ENCDEC options, etc) > 2) Move FFV1 tests to its own file (ffv1.mak). Or at least to > "lossless-video.mak". > 3) Have separate tests for different FFV1 versions (1,3) > > Then: > 4) Add default argument "-g 1" > 5) Add tests to cover the following cases: > - Color spaces YUV, RGB, GRAY > - bits-per-component as currently supported > - YUV subsampling 420, 422, 444 > - Alpha channel: YUVA, BGRA > > Maybe: > 6) Multiple coder/context options > 7) Multiple slices options > 8) Testing SliceCRC > > > This will produce quite a number of tests :( > I guess it is desired to keep the number of tests as low as necessary? avoiding redundant tests would be a good idea > I've attached my old test Makefile (ffv1.mak), for reference. > :D > > > What is the best way to proceed? probably, send patches and probably better few and small ones at once then wait and see in which direction reviewes go before spending too much time in some specific direction [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB DNS cache poisoning attacks, popular search engine, Google internet authority dont be evil, please signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/5] lavfi: drop the requirement that request_frame returns a frame.
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. > > Signed-off-by: Nicolas George > --- > doc/filter_design.txt | 21 ++--- > libavfilter/avfilter.c | 10 +- > libavfilter/avfilter.h | 6 -- > libavfilter/internal.h | 13 - > 4 files changed, 19 insertions(+), 31 deletions(-) > lgtm ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 5/5] lavfi: remove FF_LINK_FLAG_REQUEST_LOOP.
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_dynaudnorm.c| 7 --- > libavfilter/af_silenceremove.c | 8 > libavfilter/avf_showfreqs.c| 1 - > libavfilter/avfilter.c | 1 - > libavfilter/f_ebur128.c| 4 > libavfilter/f_interleave.c | 2 -- > libavfilter/f_reverse.c| 8 > libavfilter/framesync.c| 1 - > libavfilter/internal.h | 14 -- > libavfilter/trim.c | 8 > libavfilter/vf_atadenoise.c| 7 --- > libavfilter/vf_blend.c | 5 ++--- > libavfilter/vf_decimate.c | 1 - > libavfilter/vf_detelecine.c| 1 - > libavfilter/vf_fieldmatch.c| 1 - > libavfilter/vf_framestep.c | 1 - > libavfilter/vf_idet.c | 7 --- > libavfilter/vf_interlace.c | 1 - > libavfilter/vf_palettegen.c| 1 - > libavfilter/vf_pullup.c| 7 --- > libavfilter/vf_random.c| 7 --- > libavfilter/vf_stereo3d.c | 1 - > libavfilter/vf_telecine.c | 1 - > libavfilter/vf_tile.c | 2 -- > libavfilter/vf_tinterlace.c| 1 - > libavfilter/vf_w3fdif.c| 1 - > 30 files changed, 2 insertions(+), 102 deletions(-) > except missing vf_framerate.c lgtm ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Adding FATE tests for FFV1 - revisited
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 that. The way I understand the tests "lossless-video.mak", they operate differently than the ones in "vcodec.mak". I'd like to use that method (using framecrc) for FFV1 tests. Yet, all of them seem to require a specific sample in fate-suite. What's the proper way of using vsynth samples for that? My approach in the past was something like this: // --- fate-ffv1-enc-%: FMT = avi fate-ffv1-enc-%: SRC = tests/data/vsynth1.yuv # Limit the duration of test videos to 4 frames at 25fps: fate-ffv1-enc-%: DUR = 0:00:00.160 fate-ffv1-enc-%: CMD = enc_dec "rawvideo -s 352x288 -pix_fmt yuv420p $(RAWDECOPTS) -t $(DUR)" $(SRC) $(FMT) "-c $(CODEC) $(ENCOPTS)" rawvideo "-s 352x288 -pix_fmt yuv420p -vsync 0 $(DECOPTS)" -keep "$(DECINOPTS)" // --- That only uses vsynth1.yuv :( >> I guess it is desired to keep the number of tests as low as necessary? > avoiding redundant tests would be a good idea :) Will try my best. >> I've attached my old test Makefile (ffv1.mak), for reference. >> :D >> >> >> What is the best way to proceed? > probably, send patches > and probably better few and small ones at once then wait and see > in which direction reviewes go before spending too much time in some > specific direction Will do that. Currently starting with tidying up the existing tests. Thanks for your input! Pb ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Clean/reset FATE test data?
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@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add framerate video filter
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 remembering that for some reason. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add framerate video filter
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 these: [Parsed_framerate_10x7fa4e3426080] Interlaced frame found - the output will not be correct. This sounds like an issue to me but we probably need an option for il to disable changing the interlaced flag if another usecase for the filter was found. Isn't fields being marked as interlaced correct though? I mean it's not progressive video that is produced, as each field is offset by one line and anything that could process correctly, still needs to know whether a field is top or bottom. I don't know whether the framerate filter can handle fields or not, if it can, there should be code that takes account of top/bottom. If there isn't that code then I guess it really does need de-interlaced progressive full height frames as input. I guess the point is that the signal can be viewed as progressive after the il filter in deinterleave mode as it has the fields stacked on top of each other in each half of the picture. I thought that's the whole point of il, to apply filters that were not written with interlacing in mind and by this trick (deinterleave, process each field like a progressive picture, reinterleave) get some things done that would not be possible otherwise. Of course that's not really true with respect to picture timing but all progressive spatial filters should work using this approach (not taking into account potential quality side effects that the broadcast guys know best). I think the il filter signaling a progressive picture after deinterleaving would be more correct than signaling interlaced but if there is no consensus, it could let the user decide this using an option. Yea, I was getting il confused with what tfields (mplayer) or separatefields would produce. The thing about using il, though, is that the frame interpolater is working with images twice as far apart temporally as it would be with de-interlaced. I've just done a quick test converting 25i to 30i and the il way is worse than yadif. Of course it's just one test with a compressed SD sample which I then deint and scale with mpv to see on an HD monitor. If you want to try, I did with this small snooker sample - https://drive.google.com/file/d/0BxP5-S1t9VEEUUR0QnVYRU8yczQ/view?usp=sharing ffmpeg -i ~/snooker-short.ts -an -sn -vf il=l=d:c=d,framerate=fps=30,il=l=i:c=i il-snk-30i.y4m ffmpeg -i ~/snooker-short.ts -an -sn -vf yadif=1,framerate=fps=60,interlace=scan=tff:lowpass=0 ya-snk-30i.y4m mpv -fs -vf=lavfi=[yadif=1] ... The motion on the cue especially, is far better on the latter. Field stepping with mpv [.] shows the "blurring" on everything is tighter on the latter. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 03/13] avfilter: add missing FF_API_AVFILTERBUFFER guards
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 tomorrow. > If you want to keep av_buffersink_poll_frame, that can be done in > a separate commit. Pushed. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/4] fate: add -fflags +bitexact to the relevant targets
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. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avformat/mux: Warn if the muxers bitexact flag is not set but it looks as if the user wants it set
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
using the exact same system as FF_API_OLD_FILTER_OPTS is tricky as
there is a semantic difference
"codec->flags & AV_CODEC_FLAG_BITEXACT" is not deprecated as in
FF_API_OLD_FILTER_OPTS
Currently storing a bitexact stream in a container makes the
container bitexact. with FF_API_LAVF_BITEXACT==0 this would no longer
be the case and the user would have to explicitly switch the muxer
into bitexact mode in addition to the encoder to get a bitexact
result.
--- a/libavformat/mux.c
+++ b/libavformat/mux.c
@@ -250,10 +250,17 @@ static int init_muxer(AVFormatContext *s,
AVDictionary **options)
(ret = av_opt_set_dict2(s->priv_data, &tmp,
AV_OPT_SEARCH_CHILDREN)) < 0)
goto fail;
+if (s->nb_streams && s->streams[0]->codec->flags &
AV_CODEC_FLAG_BITEXACT) {
+if (!(s->flags & AVFMT_FLAG_BITEXACT))
+av_log(s, AV_LOG_WARNING, "Muxer bitexact flag is not set,
please set AVFormatContext.flags |= AVFMT_FLAG_BITEXACT.\n"
+#if FF_API_LAVF_BITEXACT
+ "This will become mandatory with
future API cleanup\n"
+#endif
+);
>>>
>>> I'd prefer something like:
>>
>> whatever people/you prefer,
>> please set Author to you, if you push
>
> OK, attaching a proper patch.
> I'll push that if nobody complains.
Pushed.
Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/4] move the FF_QSCALE_TYPE_* defines to libavutil/internal.h
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(-)
>
> diff --git a/libavcodec/version.h b/libavcodec/version.h
> index f0fa7f0..3df2bd7 100644
> --- a/libavcodec/version.h
> +++ b/libavcodec/version.h
> @@ -130,9 +130,6 @@
> #ifndef FF_API_ERROR_RATE
> #define FF_API_ERROR_RATE(LIBAVCODEC_VERSION_MAJOR < 57)
> #endif
> -#ifndef FF_API_QSCALE_TYPE
> -#define FF_API_QSCALE_TYPE (LIBAVCODEC_VERSION_MAJOR < 57)
> -#endif
> #ifndef FF_API_MB_TYPE
> #define FF_API_MB_TYPE (LIBAVCODEC_VERSION_MAJOR < 57)
> #endif
> diff --git a/libavutil/internal.h b/libavutil/internal.h
> index 047f742..2f57210 100644
> --- a/libavutil/internal.h
> +++ b/libavutil/internal.h
> @@ -256,6 +256,13 @@ void avpriv_request_sample(void *avc,
> # define ff_dlog(ctx, ...) do { if (0) av_log(ctx, AV_LOG_DEBUG,
> __VA_ARGS__); } while (0)
> #endif
>
> +#if !FF_API_QSCALE_TYPE
> +#define FF_QSCALE_TYPE_MPEG1 0
> +#define FF_QSCALE_TYPE_MPEG2 1
> +#define FF_QSCALE_TYPE_H264 2
> +#define FF_QSCALE_TYPE_VP56 3
> +#endif
> +
> /**
> * A wrapper for open() setting O_CLOEXEC.
> */
> diff --git a/libavutil/version.h b/libavutil/version.h
> index 64713d3..a666de7 100644
> --- a/libavutil/version.h
> +++ b/libavutil/version.h
> @@ -129,6 +129,9 @@
> #ifndef FF_API_HMAC
> #define FF_API_HMAC (LIBAVUTIL_VERSION_MAJOR < 55)
> #endif
> +#ifndef FF_API_QSCALE_TYPE
> +#define FF_API_QSCALE_TYPE (LIBAVUTIL_VERSION_MAJOR < 55)
> +#endif
> #ifndef FF_API_CRYPTO_CONTEXT
> #define FF_API_CRYPTO_CONTEXT (LIBAVUTIL_VERSION_MAJOR < 56)
> #endif
>
Ping.
Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/4] fate: use 'c' for setting the channel_layout
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/tests/ref/fate/filter-formats > +++ b/tests/ref/fate/filter-formats > @@ -67,11 +67,11 @@ quad(side) > 8 channels (FL+FR+LFE+BC+SL+SR+DL+DR) > 8 channels (FL+FR+FC+BC+SL+SR+DL+DR) > -1 = ff_parse_channel_layout(, -1, blah); > -0 = ff_parse_channel_layout(0004, 1, 1); > -0 = ff_parse_channel_layout(0003, 2, 2); > +0 = ff_parse_channel_layout(0001, 1, 1); > +0 = ff_parse_channel_layout(0002, 1, 2); > -1 = ff_parse_channel_layout(, -1, -1); > -0 = ff_parse_channel_layout(, 60, 60); > --1 = ff_parse_channel_layout(, -1, 65); > +0 = ff_parse_channel_layout(003C, 4, 60); > +0 = ff_parse_channel_layout(0041, 2, 65); > 0 = ff_parse_channel_layout(0004, 1, 1c); > 0 = ff_parse_channel_layout(0003, 2, 2c); > -1 = ff_parse_channel_layout(, -1, -1c); > @@ -79,7 +79,7 @@ quad(side) > -1 = ff_parse_channel_layout(, -1, 65c); > 0 = ff_parse_channel_layout(003F, 6, 5.1); > 0 = ff_parse_channel_layout(0003, 2, stereo); > -0 = ff_parse_channel_layout(0004, 1, 1+1+1+1); > +0 = ff_parse_channel_layout(0001, 1, 1+1+1+1); > 0 = ff_parse_channel_layout(0004, 1, 1c+1c+1c+1c); > 0 = ff_parse_channel_layout(0007, 3, 2c+1c); > 0 = ff_parse_channel_layout(0003, 2, 0x3); > > --- > tests/fate/filter-audio.mak | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tests/fate/filter-audio.mak b/tests/fate/filter-audio.mak > index 2669498..85a36d2 100644 > --- a/tests/fate/filter-audio.mak > +++ b/tests/fate/filter-audio.mak > @@ -81,7 +81,7 @@ FATE_AFILTER-$(call FILTERDEMDECENCMUX, JOIN, WAV, > PCM_S16LE, PCM_S16LE, PCM_S16 > fate-filter-join: SRC1 = $(TARGET_PATH)/tests/data/asynth-44100-2.wav > fate-filter-join: SRC2 = $(TARGET_PATH)/tests/data/asynth-44100-3.wav > fate-filter-join: tests/data/asynth-44100-2.wav tests/data/asynth-44100-3.wav > -fate-filter-join: CMD = md5 -i $(SRC1) -i $(SRC2) -filter_complex > join=channel_layout=5 -f s16le > +fate-filter-join: CMD = md5 -i $(SRC1) -i $(SRC2) -filter_complex > join=channel_layout=5c -f s16le > fate-filter-join: CMP = oneline > fate-filter-join: REF = 88b0d24a64717ba8635b29e8dac6ecd8 > > Ping. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/4] fate: use 'c' for setting the channel_layout
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 > > --- > > > > The filter-formats reference needs to be updated, when > > FF_API_GET_CHANNEL_LAYOUT_COMPAT gets disabled: > > > > --- a/tests/ref/fate/filter-formats > > +++ b/tests/ref/fate/filter-formats > > @@ -67,11 +67,11 @@ quad(side) > > 8 channels (FL+FR+LFE+BC+SL+SR+DL+DR) > > 8 channels (FL+FR+FC+BC+SL+SR+DL+DR) > > -1 = ff_parse_channel_layout(, -1, blah); > > -0 = ff_parse_channel_layout(0004, 1, 1); > > -0 = ff_parse_channel_layout(0003, 2, 2); > > +0 = ff_parse_channel_layout(0001, 1, 1); > > +0 = ff_parse_channel_layout(0002, 1, 2); > > -1 = ff_parse_channel_layout(, -1, -1); > > -0 = ff_parse_channel_layout(, 60, 60); > > --1 = ff_parse_channel_layout(, -1, 65); > > +0 = ff_parse_channel_layout(003C, 4, 60); > > +0 = ff_parse_channel_layout(0041, 2, 65); > > 0 = ff_parse_channel_layout(0004, 1, 1c); > > 0 = ff_parse_channel_layout(0003, 2, 2c); > > -1 = ff_parse_channel_layout(, -1, -1c); > > @@ -79,7 +79,7 @@ quad(side) > > -1 = ff_parse_channel_layout(, -1, 65c); > > 0 = ff_parse_channel_layout(003F, 6, 5.1); > > 0 = ff_parse_channel_layout(0003, 2, stereo); > > -0 = ff_parse_channel_layout(0004, 1, 1+1+1+1); > > +0 = ff_parse_channel_layout(0001, 1, 1+1+1+1); > > 0 = ff_parse_channel_layout(0004, 1, 1c+1c+1c+1c); > > 0 = ff_parse_channel_layout(0007, 3, 2c+1c); > > 0 = ff_parse_channel_layout(0003, 2, 0x3); > This is because %d used to be "number of channels", and now it's "channel layout enum id", right? So this is OK upon api bump. > diff --git a/tests/fate/filter-audio.mak b/tests/fate/filter-audio.mak > > index 2669498..85a36d2 100644 > > --- a/tests/fate/filter-audio.mak > > +++ b/tests/fate/filter-audio.mak > > @@ -81,7 +81,7 @@ FATE_AFILTER-$(call FILTERDEMDECENCMUX, JOIN, WAV, > PCM_S16LE, PCM_S16LE, PCM_S16 > > fate-filter-join: SRC1 = $(TARGET_PATH)/tests/data/asynth-44100-2.wav > > fate-filter-join: SRC2 = $(TARGET_PATH)/tests/data/asynth-44100-3.wav > > fate-filter-join: tests/data/asynth-44100-2.wav > tests/data/asynth-44100-3.wav > > -fate-filter-join: CMD = md5 -i $(SRC1) -i $(SRC2) -filter_complex > join=channel_layout=5 -f s16le > > +fate-filter-join: CMD = md5 -i $(SRC1) -i $(SRC2) -filter_complex > join=channel_layout=5c -f s16le > > fate-filter-join: CMP = oneline > > fate-filter-join: REF = 88b0d24a64717ba8635b29e8dac6ecd8 > This is OK now. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/4] move the FF_QSCALE_TYPE_* defines to libavutil/internal.h
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 +++
> 3 files changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/version.h b/libavcodec/version.h
> index f0fa7f0..3df2bd7 100644
> --- a/libavcodec/version.h
> +++ b/libavcodec/version.h
> @@ -130,9 +130,6 @@
> #ifndef FF_API_ERROR_RATE
> #define FF_API_ERROR_RATE(LIBAVCODEC_VERSION_MAJOR < 57)
> #endif
> -#ifndef FF_API_QSCALE_TYPE
> -#define FF_API_QSCALE_TYPE (LIBAVCODEC_VERSION_MAJOR < 57)
> -#endif
> #ifndef FF_API_MB_TYPE
> #define FF_API_MB_TYPE (LIBAVCODEC_VERSION_MAJOR < 57)
> #endif
> diff --git a/libavutil/internal.h b/libavutil/internal.h
> index 047f742..2f57210 100644
> --- a/libavutil/internal.h
> +++ b/libavutil/internal.h
> @@ -256,6 +256,13 @@ void avpriv_request_sample(void *avc,
> # define ff_dlog(ctx, ...) do { if (0) av_log(ctx, AV_LOG_DEBUG,
> __VA_ARGS__); } while (0)
> #endif
>
> +#if !FF_API_QSCALE_TYPE
> +#define FF_QSCALE_TYPE_MPEG1 0
> +#define FF_QSCALE_TYPE_MPEG2 1
> +#define FF_QSCALE_TYPE_H264 2
> +#define FF_QSCALE_TYPE_VP56 3
> +#endif
> +
> /**
> * A wrapper for open() setting O_CLOEXEC.
> */
> diff --git a/libavutil/version.h b/libavutil/version.h
> index 64713d3..a666de7 100644
> --- a/libavutil/version.h
> +++ b/libavutil/version.h
> @@ -129,6 +129,9 @@
> #ifndef FF_API_HMAC
> #define FF_API_HMAC (LIBAVUTIL_VERSION_MAJOR < 55)
> #endif
> +#ifndef FF_API_QSCALE_TYPE
> +#define FF_API_QSCALE_TYPE (LIBAVUTIL_VERSION_MAJOR < 55)
> +#endif
> #ifndef FF_API_CRYPTO_CONTEXT
> #define FF_API_CRYPTO_CONTEXT (LIBAVUTIL_VERSION_MAJOR < 56)
> #endif
> --
> 2.5.0
I don't have any better ideas, don't get me wrong, but I cringe at putting
codec-specific things in libavutil (even if it's in internal.h). This is
crazy and we shouldn't want this to ever become a default. I would almost
just propose delaying qscale bump by one version, although that is just
kicking the can... Does anyone have good ideas on how to deal with this in
a way that doesn't take many hours for a stupid fringe feature?
Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] FFmpeg 2.8
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 release, push it prior to the bump OR > cherry pick it in release/2.8 afterwards but before the release is > made Before the release we should decide what to do with the asf_o demuxer. Since it still crashes often, it's probably best to just remove it. Does someone want to keep it? Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add framerate video filter
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] ... ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] FFmpeg 2.8
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, after testing >> if you want something in the release, push it prior to the bump OR >> cherry pick it in release/2.8 afterwards but before the release is >> made > > Before the release we should decide what to do with the asf_o demuxer. > Since it still crashes often, it's probably best to just remove it. What? Haven't all crashes been fixed? > > Does someone want to keep it? > > Best regards, > Andreas > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] FFmpeg 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 that, after testing > > The release should be after the bump. I think it is good idea API breaking changes to be done on major release. Meaning the release containing the API bump should be 3.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] FFmpeg 2.8
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 >> release from that, after testing >> if you want something in the release, push it prior to the bump OR >> cherry pick it in release/2.8 afterwards but before the release is >> made > > Before the release we should decide what to do with the asf_o demuxer. > Since it still crashes often, it's probably best to just remove it. > > Does someone want to keep it? Yes, I want to keep it. It works much better for me than the old one. Please report or fix crashes, instead of giving out such blanket statements. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Fwd: [PATCH] avfilter/vf_subtitles: allow setting fonts directory
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.texi b/doc/filters.texi
index b78cf90..d2c8842 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -9939,6 +9939,10 @@ was composed. For the syntax of this option, check
the
Due to a misdesign in ASS aspect ratio arithmetic, this is necessary to
correctly scale the fonts if the aspect ratio has been changed.
+@item fontsdir
+Set a directory path containing fonts that can be used by the filter.
+These fonts will be used in addition to whatever the font provider uses.
+
@item charenc
Set subtitles input character encoding. @code{subtitles} filter only. Only
useful if not UTF-8.
diff --git a/libavfilter/vf_subtitles.c b/libavfilter/vf_subtitles.c
index 5e1324c..b0d016c 100644
--- a/libavfilter/vf_subtitles.c
+++ b/libavfilter/vf_subtitles.c
@@ -50,6 +50,7 @@ typedef struct {
ASS_Renderer *renderer;
ASS_Track*track;
char *filename;
+char *fontsdir;
char *charenc;
char *force_style;
int stream_index;
@@ -67,6 +68,7 @@ typedef struct {
{"filename", "set the filename of file to read",
OFFSET(filename), AV_OPT_TYPE_STRING, {.str = NULL},
CHAR_MIN, CHAR_MAX, FLAGS }, \
{"f", "set the filename of file to read",
OFFSET(filename), AV_OPT_TYPE_STRING, {.str = NULL},
CHAR_MIN, CHAR_MAX, FLAGS }, \
{"original_size", "set the size of the original video (used to scale
fonts)", OFFSET(original_w), AV_OPT_TYPE_IMAGE_SIZE, {.str = NULL},
CHAR_MIN, CHAR_MAX, FLAGS }, \
+{"fontsdir", "set the directory containing the fonts to read",
OFFSET(fontsdir), AV_OPT_TYPE_STRING, {.str = NULL},
CHAR_MIN, CHAR_MAX, FLAGS }, \
/* libass supports a log level ranging from 0 to 7 */
static const int ass_libavfilter_log_level_map[] = {
@@ -106,6 +108,8 @@ static av_cold int init(AVFilterContext *ctx)
}
ass_set_message_cb(ass->library, ass_log, ctx);
+ass_set_fonts_dir(ass->library, ass->fontsdir);
+
ass->renderer = ass_renderer_init(ass->library);
if (!ass->renderer) {
av_log(ctx, AV_LOG_ERROR, "Could not initialize libass
renderer.\n");
--
2.5.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Clean/reset FATE test data?
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-that fate-whateverfoobar | patch -p1 -R might work [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Concerning the gods, I have no means of knowing whether they exist or not or of what sort they may be, because of the obscurity of the subject, and the brevity of human life -- Protagoras signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec: Add interface to motion estimation
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 | 138 > + > libavcodec/avme.h | 30 +++ > libavcodec/internal.h |2 + > libavcodec/snow.c | 30 +++ > libavcodec/version.h |2 +- > 6 files changed, 202 insertions(+), 2 deletions(-) > create mode 100644 libavcodec/avme.c > create mode 100644 libavcodec/avme.h This is just wrapper code. It may fix an interface issue, but not the implementation issue. Can you make ME available without depending on snow? I can't imagine this is hard, don't we have an mpeg encoder, doesn't that use ME also? What if I want a build with just decoders and filters, but I want to include vf_mcfps? I'd like to think of snow as a highly obscure codec that nobody ever needs. Making it a central implementation piece for our best fps filter is ... highly questionable. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Cleaning existing FFV1 tests
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 files accordingly, and ran "make fate" to verify that they still run properly. What do you think? Pb >From be1b2ee092a82fdf70ccb99eb20d70e228205182 Mon Sep 17 00:00:00 2001 From: Peter B. Date: Mon, 31 Aug 2015 03:02:36 +0200 Subject: [PATCH] Renamed pix_fmts wording in test target name to match pix_fmt parameter. --- tests/fate/vcodec.mak | 20 +++- tests/ref/vsynth/vsynth1-ffv1-v0 |4 tests/ref/vsynth/vsynth1-ffv1-v3-bgr0 |4 tests/ref/vsynth/vsynth1-ffv1-v3-yuv420p |4 tests/ref/vsynth/vsynth1-ffv1-v3-yuv422p10 |4 tests/ref/vsynth/vsynth1-ffv1-v3-yuv444p16 |4 tests/ref/vsynth/vsynth1-ffv1.0|4 tests/ref/vsynth/vsynth1-ffv1.3-420|4 tests/ref/vsynth/vsynth1-ffv1.3-422p10 |4 tests/ref/vsynth/vsynth1-ffv1.3-444p16 |4 tests/ref/vsynth/vsynth1-ffv1.3-bgr|4 tests/ref/vsynth/vsynth2-ffv1-v0 |4 tests/ref/vsynth/vsynth2-ffv1-v3-bgr0 |4 tests/ref/vsynth/vsynth2-ffv1-v3-yuv420p |4 tests/ref/vsynth/vsynth2-ffv1-v3-yuv422p10 |4 tests/ref/vsynth/vsynth2-ffv1-v3-yuv444p16 |4 tests/ref/vsynth/vsynth2-ffv1.0|4 tests/ref/vsynth/vsynth2-ffv1.3-420|4 tests/ref/vsynth/vsynth2-ffv1.3-422p10 |4 tests/ref/vsynth/vsynth2-ffv1.3-444p16 |4 tests/ref/vsynth/vsynth2-ffv1.3-bgr|4 tests/ref/vsynth/vsynth3-ffv1-v0 |4 tests/ref/vsynth/vsynth3-ffv1-v3-bgr0 |4 tests/ref/vsynth/vsynth3-ffv1-v3-yuv420p |4 tests/ref/vsynth/vsynth3-ffv1-v3-yuv422p10 |4 tests/ref/vsynth/vsynth3-ffv1-v3-yuv444p16 |4 tests/ref/vsynth/vsynth3-ffv1.0|4 tests/ref/vsynth/vsynth3-ffv1.3-420|4 tests/ref/vsynth/vsynth3-ffv1.3-422p10 |4 tests/ref/vsynth/vsynth3-ffv1.3-444p16 |4 tests/ref/vsynth/vsynth3-ffv1.3-bgr|4 tests/ref/vsynth/vsynth_lena-ffv1-v0 |4 tests/ref/vsynth/vsynth_lena-ffv1-v3-bgr0 |4 tests/ref/vsynth/vsynth_lena-ffv1-v3-yuv420|4 tests/ref/vsynth/vsynth_lena-ffv1-v3-yuv420p |4 tests/ref/vsynth/vsynth_lena-ffv1-v3-yuv422p10 |4 tests/ref/vsynth/vsynth_lena-ffv1-v3-yuv444p16 |4 tests/ref/vsynth/vsynth_lena-ffv1.0|4 tests/ref/vsynth/vsynth_lena-ffv1.3-420|4 tests/ref/vsynth/vsynth_lena-ffv1.3-422p10 |4 tests/ref/vsynth/vsynth_lena-ffv1.3-444p16 |4 tests/ref/vsynth/vsynth_lena-ffv1.3-bgr|4 42 files changed, 95 insertions(+), 89 deletions(-) create mode 100644 tests/ref/vsynth/vsynth1-ffv1-v0 create mode 100644 tests/ref/vsynth/vsynth1-ffv1-v3-bgr0 create mode 100644 tests/ref/vsynth/vsynth1-ffv1-v3-yuv420p create mode 100644 tests/ref/vsynth/vsynth1-ffv1-v3-yuv422p10 create mode 100644 tests/ref/vsynth/vsynth1-ffv1-v3-yuv444p16 delete mode 100644 tests/ref/vsynth/vsynth1-ffv1.0 delete mode 100644 tests/ref/vsynth/vsynth1-ffv1.3-420 delete mode 100644 tests/ref/vsynth/vsynth1-ffv1.3-422p10 delete mode 100644 tests/ref/vsynth/vsynth1-ffv1.3-444p16 delete mode 100644 tests/ref/vsynth/vsynth1-ffv1.3-bgr create mode 100644 tests/ref/vsynth/vsynth2-ffv1-v0 create mode 100644 tests/ref/vsynth/vsynth2-ffv1-v3-bgr0 create mode 100644 tests/ref/vsynth/vsynth2-ffv1-v3-yuv420p create mode 100644 tests/ref/vsynth/vsynth2-ffv1-v3-yuv422p10 create mode 100644 tests/ref/vsynth/vsynth2-ffv1-v3-yuv444p16 delete mode 100644 tests/ref/vsynth/vsynth2-ffv1.0 delete mode 100644 tests/ref/vsynth/vsynth2-ffv1.3-420 delete mode 100644 tests/ref/vsynth/vsynth2-ffv1.3-422p10 delete mode 100644 tests/ref/vsynth/vsynth2-ffv1.3-444p16 delete mode 100644 tests/ref/vsynth/vsynth2-ffv1.3-bgr create mode 100644 tests/ref/vsynth/vsynth3-ffv1-v0 create mode 100644 tests/ref/vsynth/vsynth3-ffv1-v3-bgr0 create mode 100644 tests/ref/vsynth/vsynth3-ffv1-v3-yuv420p create mode 100644 tests/ref/vsynth/vsynth3-ffv1-v3-yuv422p10 create mode 100644 tests/ref/vsynth/vsynth3-ffv1-v3-yuv444p16 delete mode 100644 tests/ref/vsynth/vsynth3-ffv1.0 delete mode 100644 tests/ref/vsynth/vsynth3-ffv1.3-420 delete mode 100644 tests/ref/vsynth/vsynth3-ffv1.3-422p10 delete mode 100644 tests/ref/vsynth/vsynth3-ffv1.3-444p16 delete mode 100644 tests/ref/vsynth/vsynth3-ffv1.3-bgr create mode 100644 tests/ref/vsynth/vsynth
Re: [FFmpeg-devel] [PATCH 1/2] avcodec: Add interface to motion estimation
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: Michael Niedermayer > > --- > > libavcodec/Makefile |2 +- > > libavcodec/avme.c | 138 > > + > > libavcodec/avme.h | 30 +++ > > libavcodec/internal.h |2 + > > libavcodec/snow.c | 30 +++ > > libavcodec/version.h |2 +- > > 6 files changed, 202 insertions(+), 2 deletions(-) > > create mode 100644 libavcodec/avme.c > > create mode 100644 libavcodec/avme.h > > > This is just wrapper code. It may fix an interface issue, but not the > implementation issue. Can you make ME available without depending on snow? the currently used ME code is part of snow, its a integral part of snow > I can't imagine this is hard, don't we have an mpeg encoder, doesn't that > use ME also? snow has iterative OBMC based motion estimation, mpeg does neither have iterative nor OBMC based ME If someone extracts that out of snow then by the time mcfps maybe will use its own motion estimation independant of libavcodec. Or maybe it wont i dont know. but if anything then the ME code used is not good enough, and the mpeg code is worse. Also the code has different goals, libavcodec ME code tries to find good matches for compression, it doesnt really truly matter if that matches the actual motion but for frame interpolation a single wrong motion vector can cause severe artifacts even if the block from it matches pixel wise very well so iam a bit reluctant to do API and implementation work around the ME interface ATM, my time would be better spend in improving and testing mcfps IMO what seems the most pressing need to me is to make it easier for other developers to test and work on the code. Putting it in the main development branch aka git master would achive that. Which is why iam suggesting to do that. Do you agree ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The misfortune of the wise is better than the prosperity of the fool. -- Epicurus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] FFmpeg 2.8
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 to a file that works better with the new demuxer? Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Cleaning existing FFV1 tests
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/ffmpeg-devel
