[FFmpeg-devel] [PATCH] libavcodec/escape130: fixes and improvements
Hi! Recently I completely decompiled original Eidos Escape codecs, and I wanted to fix and improve Escape130 code of ffmpeg. Here are three sequential commits and very short (few frames) RPL-video file sample. Please review, Michael Chaban - - - Image links to compare - - - Original Eidos decoder: https://ibb.co/mvLUby FFmpeg before my commits: https://ibb.co/k8GP9J FFmpeg after 1/3 commit: thttps://ibb.co/dUavGy FFmpeg after 2/3 commit: https://ibb.co/cgLj9J FFmpeg after 3/3 commit: https://ibb.co/isTFGy 0001-libavcodec-escape130-fixed-wrong-Y-copy-block-decodi.patch Description: Binary data 0002-libavcodec-escape130-the-default-YUV-colorspace-repl.patch Description: Binary data 0003-libavcodec-escape130-The-original-decoder-blockiness.patch Description: Binary data short_sample.rpl Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v4][GSOC] avfilter: added colorconstancy
> Am 16.07.2018 um 13:41 schrieb Mina : > > Hi, > > This patch introduces Grey-Edge algorithm as part of the Color Constancy > Filter project in GSOC. > > V4 changes: > - Fixed error in filter.texi that resulted in breaking "make > doc/ffprobe-all.html" If there are no more comments coming in I‘ll push this in a couple of days. -Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Reimbursement request
> Am 01.07.2018 um 23:27 schrieb Thomas Volkert : > > >> On 23.03.2018 22:12, Thilo Borgmann wrote: >>> Am 18.03.18 um 20:57 schrieb Thilo Borgmann: >>> Hi, >>> As already discussed, FFmpeg was present on Chemnitzer Linux Tage, in addition, Thilo and I went to Brussels for FOSDEM where we attended the talks in the multimedia room kindly (co-) organized by Kieran and answered some questions. I would like to request reimbursement for the travel costs, that's flights-only, Thilo payed the gasoline and the hotel. >>> from my side there are hotel & gas for Chemnitz, and flight & hotel for >>> Brussels that I'd like to ask to reimburse for. For Chemnitz it is the >>> usual drive by car Carl Eugen and me do from Berlin, which are around 290 >>> km one way as well as a shared hotel room (they did not manage to put all >>> of us into one suite this time, so we had to stick to two rooms for all >>> four of us): >>> Chemnitz: 125,85 >>> Hotel: 194.00 EUR >>> Gas: 36.62 + 21.67 + 39.51 = 97.80 EUR >>> - >>> Total: 291,80 EUR >>> >>> Brussels: 192,41 >>> Flight:111.81 EUR >>> Hotel: 186.69 EUR >>> - >>> Total: 298,50 EUR >>> >>> >>> BTW, on both events some of our T-Shirts have found their way to some >>> users, forgot to mention this in the CLT report. Also, we ran out of stock >>> of our stickers during CLT, so I will order new ones asap. I also forgot to >>> mention that we have met the organizers of a similar event in Prague in >>> October (LinuxDays) [1]. I'll try to have us there with a booth, too! >>> >>> Also, regarding FOSDEM, I'd really like to have a booth there from next >>> year on. In contrast to Chemnitz (and possibly Prague), Brussels is an >>> expensive place in general though I could get an AirBNB near the price of >>> an actual hotel in Chemnitz. FOSDEM of course is the biggest event with a >>> bigger audience of technical knowledge in our field, so we really should >>> consider a booth at FOSDEM, IMHO. (However this is almost a year in the >>> future) >>> >>> If there are no objections, I'll send all the invoices to Stefano privately >>> (like I almost always do...;) >>> > > My expenses contained: > - 184 € for 1080 km of traveling from the area of Stuttgart to Chemnitz > (transporting monitor and other equipment, stopped midway again) > - 194€ for the hotel double room during the weekend for Alexander > Strasser and me. > => 378 € > > I will send the invoice to Stefano. > > (pictures are already on our Facebook page) Ping. I guess it‘s not for an attendee to ok Thomas request but someone else please do. -Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v9 0/3] Re-commit for davs2 api change.
Ping, any comments for following patches? At 2018-07-16 15:24:54, "hwren" wrote: >hwren (3): > lavc: add avs2 parser > lavf: add avs2 fourcc > lavc,doc,configure: add avs2 video decoder wrapper > > Changelog| 1 + > configure| 4 ++ > doc/decoders.texi| 6 ++ > doc/general.texi | 14 > libavcodec/Makefile | 2 + > libavcodec/allcodecs.c | 1 + > libavcodec/avcodec.h | 1 + > libavcodec/avs2_parser.c | 95 + > libavcodec/codec_desc.c | 7 ++ > libavcodec/libdavs2.c| 177 +++ > libavcodec/parser.c | 1 + > libavcodec/version.h | 4 +- > libavformat/riff.c | 1 + > 13 files changed, 312 insertions(+), 2 deletions(-) > create mode 100644 libavcodec/avs2_parser.c > create mode 100644 libavcodec/libdavs2.c > >-- >2.7.4 > >___ >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] avcodec: parse options from AVCodec.bsfs
On 7/18/2018 3:57 PM, Aman Gupta wrote:
> From: Aman Gupta
>
avcodec/decode: parse options from AVCodec.bsfs
> Fixes a bug that would prevent using multiple comma-separated filters,
> and allows options to be passed to each filter.
>
> Based on similar loop in ffmpeg_opt.c's new_output_stream().
>
> Signed-off-by: Aman Gupta
> ---
> libavcodec/decode.c | 47 ---
> 1 file changed, 40 insertions(+), 7 deletions(-)
>
> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> index 6a3a4df179..67b7443b9d 100644
> --- a/libavcodec/decode.c
> +++ b/libavcodec/decode.c
> @@ -36,6 +36,7 @@
> #include "libavutil/imgutils.h"
> #include "libavutil/internal.h"
> #include "libavutil/intmath.h"
> +#include "libavutil/opt.h"
>
> #include "avcodec.h"
> #include "bytestream.h"
> @@ -195,27 +196,33 @@ static int bsfs_init(AVCodecContext *avctx)
> while (bsfs_str && *bsfs_str) {
> AVBSFContext **tmp;
> const AVBitStreamFilter *filter;
> -char *bsf;
> +char *bsf, *bsf_options_str, *bsf_name;
>
> bsf = av_get_token(&bsfs_str, ",");
> if (!bsf) {
> ret = AVERROR(ENOMEM);
> goto fail;
> }
> +bsf_name = av_strtok(bsf, "=", &bsf_options_str);
> +if (!bsf_name) {
> +av_freep(&bsf);
> +ret = AVERROR(ENOMEM);
> +goto fail;
> +}
>
> -filter = av_bsf_get_by_name(bsf);
> +filter = av_bsf_get_by_name(bsf_name);
> if (!filter) {
> av_log(avctx, AV_LOG_ERROR, "A non-existing bitstream filter %s "
> "requested by a decoder. This is a bug, please report
> it.\n",
> - bsf);
> -ret = AVERROR_BUG;
> + bsf_name);
> av_freep(&bsf);
> +ret = AVERROR_BUG;
> goto fail;
> }
> -av_freep(&bsf);
>
> tmp = av_realloc_array(s->bsfs, s->nb_bsfs + 1, sizeof(*s->bsfs));
> if (!tmp) {
> +av_freep(&bsf);
> ret = AVERROR(ENOMEM);
> goto fail;
> }
> @@ -223,8 +230,10 @@ static int bsfs_init(AVCodecContext *avctx)
> s->nb_bsfs++;
>
> ret = av_bsf_alloc(filter, &s->bsfs[s->nb_bsfs - 1]);
> -if (ret < 0)
> +if (ret < 0) {
> +av_freep(&bsf);
> goto fail;
> +}
>
> if (s->nb_bsfs == 1) {
> /* We do not currently have an API for passing the input
> timebase into decoders,
> @@ -238,12 +247,36 @@ static int bsfs_init(AVCodecContext *avctx)
> ret = avcodec_parameters_copy(s->bsfs[s->nb_bsfs - 1]->par_in,
>s->bsfs[s->nb_bsfs - 2]->par_out);
> }
> -if (ret < 0)
> +if (ret < 0) {
> +av_freep(&bsf);
> goto fail;
> +}
> +
> +if (bsf_options_str && filter->priv_class) {
> +const AVOption *opt = av_opt_next(s->bsfs[s->nb_bsfs -
> 1]->priv_data, NULL);
> +const char * shorthand[2] = {NULL};
> +
> +if (opt)
> +shorthand[0] = opt->name;
> +
> +ret = av_opt_set_from_string(s->bsfs[s->nb_bsfs - 1]->priv_data,
> bsf_options_str, shorthand, "=", ":");
> +if (ret < 0) {
> +av_log(avctx, AV_LOG_ERROR, "Invalid options for bitstream
> filter %s "
> + "requested by the decoder. This is a bug, please
> report it.\n",
> + bsf_name);
> +av_freep(&bsf);
> +ret = AVERROR_BUG;
> +goto fail;
> +}
As i said on IRC, av_opt_set_from_string() can return ENOMEM which is
not a bug in the string contents, so do something like
if (ret < 0) {
if (ret != AVERROR(ENOMEM)) {
av_log(avctx, AV_LOG_ERROR, "Invalid options for bitstream filter %s "
"requested by the decoder. This is a bug, please report it.\n",
bsf_name);
ret = AVERROR_BUG;
}
av_freep(&bsf);
goto fail;
}
> +}
> +av_freep(&bsf);
>
> ret = av_bsf_init(s->bsfs[s->nb_bsfs - 1]);
> if (ret < 0)
> goto fail;
> +
> +if (*bsfs_str)
> +bsfs_str++;
> }
>
> return 0;
>
Should be ok otherwise.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]lavfi/af_aiir, af_afir: Remove a variable that is always -1
Hi!
Two very similar conditions in af_aiir.c and af_afir.c can never be true afaict.
Please review, Carl Eugen
From 6c83ac40c1c83987fe4bc408e5408166815b88d8 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Thu, 19 Jul 2018 02:28:25 +0200
Subject: [PATCH] lavfi/af_afir,af_aiir: Remove a variable that is always -1.
Fixes two warnings:
libavfilter/af_afir.c:194:45: warning: assuming signed overflow does not occur when assuming that (X - c) > X is always false [-Wstrict-overflow]
int dx = FFABS(x1-x0), sx = x0 < x1 ? 1 : -1;
^~~~
libavfilter/af_aiir.c:689:45: warning: assuming signed overflow does not occur when assuming that (X - c) > X is always false [-Wstrict-overflow]
int dx = FFABS(x1-x0), sx = x0 < x1 ? 1 : -1;
^~~~
---
libavfilter/af_afir.c |4 ++--
libavfilter/af_aiir.c |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavfilter/af_afir.c b/libavfilter/af_afir.c
index 75de147..a4a7160 100644
--- a/libavfilter/af_afir.c
+++ b/libavfilter/af_afir.c
@@ -191,7 +191,7 @@ static void drawtext(AVFrame *pic, int x, int y, const char *txt, uint32_t color
static void draw_line(AVFrame *out, int x0, int y0, int x1, int y1, uint32_t color)
{
-int dx = FFABS(x1-x0), sx = x0 < x1 ? 1 : -1;
+int dx = FFABS(x1-x0);
int dy = FFABS(y1-y0), sy = y0 < y1 ? 1 : -1;
int err = (dx>dy ? dx : -dy) / 2, e2;
@@ -205,7 +205,7 @@ static void draw_line(AVFrame *out, int x0, int y0, int x1, int y1, uint32_t col
if (e2 >-dx) {
err -= dy;
-x0 += sx;
+x0--;
}
if (e2 < dy) {
diff --git a/libavfilter/af_aiir.c b/libavfilter/af_aiir.c
index 65c8201..9a4769c 100644
--- a/libavfilter/af_aiir.c
+++ b/libavfilter/af_aiir.c
@@ -686,7 +686,7 @@ static void drawtext(AVFrame *pic, int x, int y, const char *txt, uint32_t color
static void draw_line(AVFrame *out, int x0, int y0, int x1, int y1, uint32_t color)
{
-int dx = FFABS(x1-x0), sx = x0 < x1 ? 1 : -1;
+int dx = FFABS(x1-x0);
int dy = FFABS(y1-y0), sy = y0 < y1 ? 1 : -1;
int err = (dx>dy ? dx : -dy) / 2, e2;
@@ -700,7 +700,7 @@ static void draw_line(AVFrame *out, int x0, int y0, int x1, int y1, uint32_t col
if (e2 >-dx) {
err -= dy;
-x0 += sx;
+x0--;
}
if (e2 < dy) {
--
1.7.10.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/pixfmt: Document chroma plane size for odd resolutions
2018-07-18 22:23 GMT+02:00, Michael Niedermayer : > Signed-off-by: Michael Niedermayer > --- > libavutil/pixfmt.h | 4 > 1 file changed, 4 insertions(+) > > diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h > index aea008bbdc..2b3307845e 100644 > --- a/libavutil/pixfmt.h > +++ b/libavutil/pixfmt.h > @@ -42,6 +42,10 @@ > * This is stored as BGRA on little-endian CPU architectures and ARGB on > * big-endian CPUs. > * > + * @note > + * If the resolution is not a multiple of the chroma subsampling factor > + * then the chroma plane resolution must be rounded up. Lgtm, thank you! Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] avformat/lrcdec: fix losing opening bracket
On Wed, Jul 18, 2018 at 06:04:29PM +0530, Umair Khan wrote:
> On Sat, Jul 14, 2018 at 8:37 PM Michael Niedermayer
> wrote:
> >
> > On Fri, Jul 13, 2018 at 01:34:47PM +0530, Umair Khan wrote:
> > > On Wed, Jul 11, 2018 at 11:07 PM Michael Niedermayer
> > > wrote:
> > > >
> > > > On Tue, Jul 10, 2018 at 08:10:00PM +0530, Umair Khan wrote:
> > > > > Hi,
> > > > >
> > > > > Patch attached.
> > > > >
> > > > > -Umair
> > > >
> > > > > lrcdec.c |3 +++
> > > > > 1 file changed, 3 insertions(+)
> > > > > 6782b07bfa45139361c15527ee5fb78e5893b9ba
> > > > > 0001-avformat-lrcdec-fix-losing-opening-bracket.patch
> > > > > From 95a5d2e5575c5f895e4251775a48f7deb4c86124 Mon Sep 17 00:00:00 2001
> > > > > From: Umair Khan
> > > > > Date: Tue, 10 Jul 2018 19:51:41 +0530
> > > > > Subject: [PATCH 1/1] avformat/lrcdec: fix losing opening bracket
> > > > >
> > > > > Fixes #7255
> > > > >
> > > > > Signed-off-by: Umair Khan
> > > > > ---
> > > > > libavformat/lrcdec.c | 3 +++
> > > > > 1 file changed, 3 insertions(+)
> > > > >
> > > > > diff --git a/libavformat/lrcdec.c b/libavformat/lrcdec.c
> > > > > index f4e9a4efa9..d1e28aff87 100644
> > > > > --- a/libavformat/lrcdec.c
> > > > > +++ b/libavformat/lrcdec.c
> > > > > @@ -68,6 +68,9 @@ static int64_t count_ts(const char *p)
> > > > > (p[offset] >= '0' && p[offset] <= '9'))) {
> > > > > offset++;
> > > > > } else {
> > > > > +if (in_brackets) {
> > > > > +--offset;
> > > > > +}
> > > > > break;
> > > >
> > > > this is probably ok but it doesnt fix this completely
> > > >
> > > > consider 2 [[
> > > > or a [123
> > > >
> > > > The code should probably remember the last position after a correctly
> > > > parsed timestamp or maybe use sscanf() to parse these timestamps
> > >
> > > The new attached patch takes care of these cases.
> > >
> > > > Also it seems the code doesnt handle timestamps in the middle of lines
> > > > (not related to your patch though)
> > >
> > > I can handle this case if you can give me an example of what case you
> > > are talking about exactly.
> > >
> > > -Umair
> >
> > > lrcdec.c |7 ---
> > > 1 file changed, 4 insertions(+), 3 deletions(-)
> > > 72feffd56541236991001caaa92e533382b98b53
> > > 0001-avformat-lrcdec-fix-losing-opening-bracket.patch
> > > From 81c2e13aa0a7559886502cfb69f788bd0de7a64a Mon Sep 17 00:00:00 2001
> > > From: Umair Khan
> > > Date: Fri, 13 Jul 2018 13:24:51 +0530
> > > Subject: [PATCH 1/1] avformat/lrcdec: fix losing opening bracket
> > >
> > > ---
> > > libavformat/lrcdec.c | 7 ---
> > > 1 file changed, 4 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/libavformat/lrcdec.c b/libavformat/lrcdec.c
> > > index f4e9a4efa9..4093cbdf10 100644
> > > --- a/libavformat/lrcdec.c
> > > +++ b/libavformat/lrcdec.c
> > > @@ -60,14 +60,15 @@ static int64_t count_ts(const char *p)
> > > } else if(p[offset] == '[') {
> > > offset++;
> > > in_brackets++;
> > > -} else if (p[offset] == ']' && in_brackets) {
> > > -offset++;
> > > -in_brackets--;
> > > } else if(in_brackets &&
> > > (p[offset] == ':' || p[offset] == '.' || p[offset] ==
> > > '-' ||
> > > (p[offset] >= '0' && p[offset] <= '9'))) {
> > > offset++;
> > > } else {
> > > +if (p[offset] == ']' && in_brackets) {
> > > +offset++;
> > > +in_brackets--;
> > > +}
> > > break;
> >
> > This breaks multiple times like:
> > [00:35.62][00:35.63][00:35.64]123 is a number
> >
> > this should be interpreted as 3 occurances of "123 is a number" IIUC
>
> Are you sure about this? As much as I read, there's no example of it
> being interpreted as 3 occurrences. It could be interpreted as empty
> words at the first two timestamps.
fate-suite/sub/test-lrc.lrc contains examples of this
The lyrics with repeats written out are here:
https://www.joshwoodward.com/song/Swansong
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
No great genius has ever existed without some touch of madness. -- Aristotle
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffv1dec: Ensure that pixel format constraints are respected
On Wed, Jul 18, 2018 at 11:03:47AM -0400, Derek Buitenhuis wrote: > On Wed, Jul 18, 2018 at 10:01 AM, Vittorio Giovara > wrote: > >> this does not follow from what you write below. But more so this is not > >> how pixel formats were implemented in FFmpeg. > >> Where does this idea come from ? > > > > I found the following description of this pixel format pretty accurate: > > https://linuxtv.org/downloads/v4l-dvb-apis/uapi/v4l/pixfmt-yuv410.html > > > > I am not sure how non-mod4 sizes work, but probably codecs within ffmpeg > > take into account more alignment than necessary and make things work > > To expand on this (and other replies): The behavior in FFmpeg is very > unexpected > for an API user who may wish to actually use the returned yuv410p data with an > application or other library that is *not* from FFmpeg, such as a renderer, or > external encoder lib, resizer, etc. Everything else on the planet > assumes that if > you have a buffer of a specific chroma subsampling type, you actually > have enough > data for it to be valid, with width/height that make it so. It's very > surprising when > you get back a set of buffers/width/height that don't make sense for a > given pixel > format, and is little to no documentation about why/how. I think i see what you mean. But iam not sure i understand how the proposed changes would be the ideal solution. For example: lets assume we have a 3x3 image of 420 or 410 (be that from a jpeg or whatever) If we want to use this with software that that does support odd resolutions then it should just work. Theres no 4th column or row in the logic image that could be used. OTOH if we want to use this with softwate that does not support odd resolutions then its not going to work with a 3x3 (as odd) or 2x2 (looses a column and row) or a 4x4 (which has a column and a row that is uninitialized or black) what i mean is that the API by which one exports the width and height doesnt really affect this. To get from a 3x3 to something that actually works with external code which only supports even resolutions, something somewhere has to make it even and either scale, crop or fill in. More specifically, saying that this 3x3 is a 4x4 image with crop is not really true as theres not neccesarily any data in the last column and row. And a filter or encoder using that anyway could produce bad output > > I don't think "logic guarantees the buffer is mod4/aligned" is a > reasonable thing > to tell an API user in lieu of documentation for unexpected behavior. just posted a small patch to document this [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avutil/pixfmt: Document chroma plane size for odd resolutions
Signed-off-by: Michael Niedermayer --- libavutil/pixfmt.h | 4 1 file changed, 4 insertions(+) diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h index aea008bbdc..2b3307845e 100644 --- a/libavutil/pixfmt.h +++ b/libavutil/pixfmt.h @@ -42,6 +42,10 @@ * This is stored as BGRA on little-endian CPU architectures and ARGB on * big-endian CPUs. * + * @note + * If the resolution is not a multiple of the chroma subsampling factor + * then the chroma plane resolution must be rounded up. + * * @par * When the pixel format is palettized RGB32 (AV_PIX_FMT_PAL8), the palettized * image data is stored in AVFrame.data[0]. The palette is transported in -- 2.18.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec: parse options from AVCodec.bsfs
From: Aman Gupta
Fixes a bug that would prevent using multiple comma-separated filters,
and allows options to be passed to each filter.
Based on similar loop in ffmpeg_opt.c's new_output_stream().
Signed-off-by: Aman Gupta
---
libavcodec/decode.c | 47 ---
1 file changed, 40 insertions(+), 7 deletions(-)
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 6a3a4df179..67b7443b9d 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -36,6 +36,7 @@
#include "libavutil/imgutils.h"
#include "libavutil/internal.h"
#include "libavutil/intmath.h"
+#include "libavutil/opt.h"
#include "avcodec.h"
#include "bytestream.h"
@@ -195,27 +196,33 @@ static int bsfs_init(AVCodecContext *avctx)
while (bsfs_str && *bsfs_str) {
AVBSFContext **tmp;
const AVBitStreamFilter *filter;
-char *bsf;
+char *bsf, *bsf_options_str, *bsf_name;
bsf = av_get_token(&bsfs_str, ",");
if (!bsf) {
ret = AVERROR(ENOMEM);
goto fail;
}
+bsf_name = av_strtok(bsf, "=", &bsf_options_str);
+if (!bsf_name) {
+av_freep(&bsf);
+ret = AVERROR(ENOMEM);
+goto fail;
+}
-filter = av_bsf_get_by_name(bsf);
+filter = av_bsf_get_by_name(bsf_name);
if (!filter) {
av_log(avctx, AV_LOG_ERROR, "A non-existing bitstream filter %s "
"requested by a decoder. This is a bug, please report
it.\n",
- bsf);
-ret = AVERROR_BUG;
+ bsf_name);
av_freep(&bsf);
+ret = AVERROR_BUG;
goto fail;
}
-av_freep(&bsf);
tmp = av_realloc_array(s->bsfs, s->nb_bsfs + 1, sizeof(*s->bsfs));
if (!tmp) {
+av_freep(&bsf);
ret = AVERROR(ENOMEM);
goto fail;
}
@@ -223,8 +230,10 @@ static int bsfs_init(AVCodecContext *avctx)
s->nb_bsfs++;
ret = av_bsf_alloc(filter, &s->bsfs[s->nb_bsfs - 1]);
-if (ret < 0)
+if (ret < 0) {
+av_freep(&bsf);
goto fail;
+}
if (s->nb_bsfs == 1) {
/* We do not currently have an API for passing the input timebase
into decoders,
@@ -238,12 +247,36 @@ static int bsfs_init(AVCodecContext *avctx)
ret = avcodec_parameters_copy(s->bsfs[s->nb_bsfs - 1]->par_in,
s->bsfs[s->nb_bsfs - 2]->par_out);
}
-if (ret < 0)
+if (ret < 0) {
+av_freep(&bsf);
goto fail;
+}
+
+if (bsf_options_str && filter->priv_class) {
+const AVOption *opt = av_opt_next(s->bsfs[s->nb_bsfs -
1]->priv_data, NULL);
+const char * shorthand[2] = {NULL};
+
+if (opt)
+shorthand[0] = opt->name;
+
+ret = av_opt_set_from_string(s->bsfs[s->nb_bsfs - 1]->priv_data,
bsf_options_str, shorthand, "=", ":");
+if (ret < 0) {
+av_log(avctx, AV_LOG_ERROR, "Invalid options for bitstream
filter %s "
+ "requested by the decoder. This is a bug, please report
it.\n",
+ bsf_name);
+av_freep(&bsf);
+ret = AVERROR_BUG;
+goto fail;
+}
+}
+av_freep(&bsf);
ret = av_bsf_init(s->bsfs[s->nb_bsfs - 1]);
if (ret < 0)
goto fail;
+
+if (*bsfs_str)
+bsfs_str++;
}
return 0;
--
2.14.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/decode: fix bsfs string parsing when more than one filter is requested
av_get_token() leaves bsfs_str pointing to the delimiter character, so any iteration past the first would be off by one character and start parsing from the delimiter in question. No test case as no decoder currently requests more than one bsfs. Signed-off-by: James Almer --- libavcodec/decode.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/libavcodec/decode.c b/libavcodec/decode.c index 6a3a4df179..8e9a40b7c0 100644 --- a/libavcodec/decode.c +++ b/libavcodec/decode.c @@ -244,6 +244,9 @@ static int bsfs_init(AVCodecContext *avctx) ret = av_bsf_init(s->bsfs[s->nb_bsfs - 1]); if (ret < 0) goto fail; + +if (*bsfs_str) +bsfs_str++; } return 0; -- 2.18.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 0/5] AV1 support in mp4
On 7/9/2018 3:26 PM, James Almer wrote: > What the subject says. > > There are a few comments in some of the patches as well. > > James Almer (5): > avcodec: add AV1 packet split API > avcodec/extract_extradata: add support for AV1 > avcodec/libaomenc: export Sequence Header and Metadata OBUs as > extradata > avformat/mov: add support for AV1 streams > avformat/movenc: add support for AV1 streams > > configure | 1 + > libavcodec/Makefile| 2 +- > libavcodec/av1.h | 42 ++ > libavcodec/av1_parse.c | 103 +++ > libavcodec/av1_parse.h | 126 + > libavcodec/extract_extradata_bsf.c | 80 ++ > libavcodec/libaomenc.c | 41 ++ > libavformat/Makefile | 2 +- > libavformat/av1.c | 107 > libavformat/av1.h | 70 > libavformat/isom.c | 1 + > libavformat/mov.c | 31 +++ > libavformat/movenc.c | 36 +++-- > 13 files changed, 633 insertions(+), 9 deletions(-) > create mode 100644 libavcodec/av1.h > create mode 100644 libavcodec/av1_parse.c > create mode 100644 libavcodec/av1_parse.h > create mode 100644 libavformat/av1.c > create mode 100644 libavformat/av1.h > I'll be pushing this set soon. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libswresample: Use channel count if channel layout is undefined
Rematrixing supports up to 64 channels. However, there is only a limited number
of channel layouts defined. Since the in/out channel count is obtained from the
channel layout, for undefined layouts (e.g. for 9, 10, 11 channels etc.) the
rematrixing fails.
In ticket #6790 the problem has been partially addressed by applying a patch to
swr_set_matrix() in rematrix.c:72.
However, a similar change must be also applied to swri_rematrix_init() in
rematrix.c:389 and swri_rematrix_init_x86() in rematrix_init.c:36.
---
libswresample/rematrix.c | 6 --
libswresample/x86/rematrix_init.c | 6 --
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/libswresample/rematrix.c b/libswresample/rematrix.c
index 8227730056..d1a0cfe7f8 100644
--- a/libswresample/rematrix.c
+++ b/libswresample/rematrix.c
@@ -384,8 +384,10 @@ av_cold static int auto_matrix(SwrContext *s)
av_cold int swri_rematrix_init(SwrContext *s){
int i, j;
-int nb_in = av_get_channel_layout_nb_channels(s->in_ch_layout);
-int nb_out = av_get_channel_layout_nb_channels(s->out_ch_layout);
+int nb_in = (s->in.ch_count > 0) ? s->in.ch_count :
+av_get_channel_layout_nb_channels(s->in_ch_layout);
+int nb_out = (s->out.ch_count > 0) ? s->out.ch_count :
+av_get_channel_layout_nb_channels(s->out_ch_layout);
s->mix_any_f = NULL;
diff --git a/libswresample/x86/rematrix_init.c
b/libswresample/x86/rematrix_init.c
index d71b41a73e..4f9c92e4ab 100644
--- a/libswresample/x86/rematrix_init.c
+++ b/libswresample/x86/rematrix_init.c
@@ -33,8 +33,10 @@ D(int16, sse2)
av_cold int swri_rematrix_init_x86(struct SwrContext *s){
#if HAVE_X86ASM
int mm_flags = av_get_cpu_flags();
-int nb_in = av_get_channel_layout_nb_channels(s->in_ch_layout);
-int nb_out = av_get_channel_layout_nb_channels(s->out_ch_layout);
+int nb_in = (s->in.ch_count > 0) ? s->in.ch_count :
+av_get_channel_layout_nb_channels(s->in_ch_layout);
+int nb_out = (s->out.ch_count > 0) ? s->out.ch_count :
+av_get_channel_layout_nb_channels(s->out_ch_layout);
int num= nb_in * nb_out;
int i,j;
--
2.18.0.203.gfac676dfb9-goog
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libswresample: Use channel count if channel layout is undefined
Thanks for your input Tobias!
On Wed, Jul 18, 2018 at 3:23 PM Tobias Rapp wrote:
> On 13.07.2018 13:43, Marcin Gorzel wrote:
> > Rematrixing supports up to 64 channels. However, there is only a limited
> number of channel layouts defined. Since the in/out channel count is
> obtained from the channel layout, for undefined layouts (e.g. for 9, 10, 11
> channels etc.) the rematrixing fails.
> >
> > In ticket #6790 the problem has been partially addressed by applying a
> patch to swr_set_matrix() in rematrix.c:72.
> > However, a similar change must be also applied to swri_rematrix_init()
> in rematrix.c:389 and swri_rematrix_init_x86() in rematrix_init.c:36.
> >
> > This patch adds the following check to the swri_rematrix_init() in
> rematrix.c:389 and swri_rematrix_init_x86() in rematrix_init.c:36: if
> channel layout is non-zero, obtain channel count from the channel layout,
> otherwise, use channel count instead.
> >
> > It also modifies the checks in swr_set_matrix() in rematrix.c:72 to
> match the above checks. (Since
> av_get_channel_layout_nb_channels(s->user_in_ch_layout) was originally
> used, there may be preference to rely on the channel layout first (if
> available) before falling back to the user channel count).
> > ---
> > libswresample/rematrix.c | 18 --
> > libswresample/x86/rematrix_init.c | 8 ++--
> > 2 files changed, 18 insertions(+), 8 deletions(-)
> >
> > diff --git a/libswresample/rematrix.c b/libswresample/rematrix.c
> > index 8227730056..8c9fbf3804 100644
> > --- a/libswresample/rematrix.c
> > +++ b/libswresample/rematrix.c
> > @@ -69,10 +69,12 @@ int swr_set_matrix(struct SwrContext *s, const
> double *matrix, int stride)
> > return AVERROR(EINVAL);
> > memset(s->matrix, 0, sizeof(s->matrix));
> > memset(s->matrix_flt, 0, sizeof(s->matrix_flt));
> > -nb_in = (s->user_in_ch_count > 0) ? s->user_in_ch_count :
> > -av_get_channel_layout_nb_channels(s->user_in_ch_layout);
> > -nb_out = (s->user_out_ch_count > 0) ? s->user_out_ch_count :
> > -av_get_channel_layout_nb_channels(s->user_out_ch_layout);
> > +nb_in = s->user_in_ch_layout != 0
> > +? av_get_channel_layout_nb_channels(s->user_in_ch_layout)
> > +: s->user_in_ch_count;
> > +nb_out = s->user_out_ch_layout != 0
> > +? av_get_channel_layout_nb_channels(s->user_out_ch_layout)
> > +: s->user_out_ch_count;
> > for (out = 0; out < nb_out; out++) {
> > for (in = 0; in < nb_in; in++)
> > s->matrix_flt[out][in] = s->matrix[out][in] = matrix[in];
>
> Sorry for jumping into the discussion late but I don't think this change
> is necessary. If only one of the user_*_ch_count / user_*_ch_layout
> field pair is set, the outcome will be the same. If both field values
> are set they must be consistent or undefined behavior will occur. So if
> we assume the field values are consistent, why use the value that has to
> be calculated first from the layout mask instead of the explicit count
> value?
>
Makes sense. I am new to this code and I wasn't sure what historical
reasons were behind using av_get_channel_layout_nb_channels(layout) to get
the channel count in the first place so I thought it would be safer to
leave the code so that it is used first, before falling back to the channel
count.
> @@ -384,8 +386,12 @@ av_cold static int auto_matrix(SwrContext *s)
> >
> > av_cold int swri_rematrix_init(SwrContext *s){
> > int i, j;
> > -int nb_in = av_get_channel_layout_nb_channels(s->in_ch_layout);
> > -int nb_out = av_get_channel_layout_nb_channels(s->out_ch_layout);
> > +int nb_in = s->in_ch_layout != 0
> > +? av_get_channel_layout_nb_channels(s->in_ch_layout)
> > +: s->user_in_ch_count;
> > +int nb_out = s->out_ch_layout != 0
> > +? av_get_channel_layout_nb_channels(s->out_ch_layout)
> > +: s->user_out_ch_count;
> >
> > s->mix_any_f = NULL;
> >
> > diff --git a/libswresample/x86/rematrix_init.c
> b/libswresample/x86/rematrix_init.c
> > index d71b41a73e..a6ae074926 100644
> > --- a/libswresample/x86/rematrix_init.c
> > +++ b/libswresample/x86/rematrix_init.c
> > @@ -33,8 +33,12 @@ D(int16, sse2)
> > av_cold int swri_rematrix_init_x86(struct SwrContext *s){
> > #if HAVE_X86ASM
> > int mm_flags = av_get_cpu_flags();
> > -int nb_in = av_get_channel_layout_nb_channels(s->in_ch_layout);
> > -int nb_out = av_get_channel_layout_nb_channels(s->out_ch_layout);
> > +int nb_in = s->in_ch_layout != 0
> > +? av_get_channel_layout_nb_channels(s->in_ch_layout)
> > +: s->user_in_ch_count;
> > +int nb_out = s->out_ch_layout != 0
> > +? av_get_channel_layout_nb_channels(s->out_ch_layout)
> > +: s->user_out_ch_count;
> > int num= nb_in * nb_out;
> > int i,j;
> >
> >
>
> Like said above I think the same effect can be achieved with less CPU
> cycles by using a "(count > 0) ? count :
>
Re: [FFmpeg-devel] [PATCH] ffv1dec: Ensure that pixel format constraints are respected
On Wed, Jul 18, 2018 at 10:01 AM, Vittorio Giovara wrote: >> this does not follow from what you write below. But more so this is not >> how pixel formats were implemented in FFmpeg. >> Where does this idea come from ? > > I found the following description of this pixel format pretty accurate: > https://linuxtv.org/downloads/v4l-dvb-apis/uapi/v4l/pixfmt-yuv410.html > > I am not sure how non-mod4 sizes work, but probably codecs within ffmpeg > take into account more alignment than necessary and make things work To expand on this (and other replies): The behavior in FFmpeg is very unexpected for an API user who may wish to actually use the returned yuv410p data with an application or other library that is *not* from FFmpeg, such as a renderer, or external encoder lib, resizer, etc. Everything else on the planet assumes that if you have a buffer of a specific chroma subsampling type, you actually have enough data for it to be valid, with width/height that make it so. It's very surprising when you get back a set of buffers/width/height that don't make sense for a given pixel format, and is little to no documentation about why/how. I don't think "logic guarantees the buffer is mod4/aligned" is a reasonable thing to tell an API user in lieu of documentation for unexpected behavior. Cheers, - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libswresample: Use channel count if channel layout is undefined
On 13.07.2018 13:43, Marcin Gorzel wrote:
Rematrixing supports up to 64 channels. However, there is only a limited number
of channel layouts defined. Since the in/out channel count is obtained from the
channel layout, for undefined layouts (e.g. for 9, 10, 11 channels etc.) the
rematrixing fails.
In ticket #6790 the problem has been partially addressed by applying a patch to
swr_set_matrix() in rematrix.c:72.
However, a similar change must be also applied to swri_rematrix_init() in
rematrix.c:389 and swri_rematrix_init_x86() in rematrix_init.c:36.
This patch adds the following check to the swri_rematrix_init() in
rematrix.c:389 and swri_rematrix_init_x86() in rematrix_init.c:36: if channel
layout is non-zero, obtain channel count from the channel layout, otherwise,
use channel count instead.
It also modifies the checks in swr_set_matrix() in rematrix.c:72 to match the
above checks. (Since av_get_channel_layout_nb_channels(s->user_in_ch_layout)
was originally used, there may be preference to rely on the channel layout first
(if available) before falling back to the user channel count).
---
libswresample/rematrix.c | 18 --
libswresample/x86/rematrix_init.c | 8 ++--
2 files changed, 18 insertions(+), 8 deletions(-)
diff --git a/libswresample/rematrix.c b/libswresample/rematrix.c
index 8227730056..8c9fbf3804 100644
--- a/libswresample/rematrix.c
+++ b/libswresample/rematrix.c
@@ -69,10 +69,12 @@ int swr_set_matrix(struct SwrContext *s, const double
*matrix, int stride)
return AVERROR(EINVAL);
memset(s->matrix, 0, sizeof(s->matrix));
memset(s->matrix_flt, 0, sizeof(s->matrix_flt));
-nb_in = (s->user_in_ch_count > 0) ? s->user_in_ch_count :
-av_get_channel_layout_nb_channels(s->user_in_ch_layout);
-nb_out = (s->user_out_ch_count > 0) ? s->user_out_ch_count :
-av_get_channel_layout_nb_channels(s->user_out_ch_layout);
+nb_in = s->user_in_ch_layout != 0
+? av_get_channel_layout_nb_channels(s->user_in_ch_layout)
+: s->user_in_ch_count;
+nb_out = s->user_out_ch_layout != 0
+? av_get_channel_layout_nb_channels(s->user_out_ch_layout)
+: s->user_out_ch_count;
for (out = 0; out < nb_out; out++) {
for (in = 0; in < nb_in; in++)
s->matrix_flt[out][in] = s->matrix[out][in] = matrix[in];
Sorry for jumping into the discussion late but I don't think this change
is necessary. If only one of the user_*_ch_count / user_*_ch_layout
field pair is set, the outcome will be the same. If both field values
are set they must be consistent or undefined behavior will occur. So if
we assume the field values are consistent, why use the value that has to
be calculated first from the layout mask instead of the explicit count
value?
@@ -384,8 +386,12 @@ av_cold static int auto_matrix(SwrContext *s)
av_cold int swri_rematrix_init(SwrContext *s){
int i, j;
-int nb_in = av_get_channel_layout_nb_channels(s->in_ch_layout);
-int nb_out = av_get_channel_layout_nb_channels(s->out_ch_layout);
+int nb_in = s->in_ch_layout != 0
+? av_get_channel_layout_nb_channels(s->in_ch_layout)
+: s->user_in_ch_count;
+int nb_out = s->out_ch_layout != 0
+? av_get_channel_layout_nb_channels(s->out_ch_layout)
+: s->user_out_ch_count;
s->mix_any_f = NULL;
diff --git a/libswresample/x86/rematrix_init.c b/libswresample/x86/rematrix_init.c
index d71b41a73e..a6ae074926 100644
--- a/libswresample/x86/rematrix_init.c
+++ b/libswresample/x86/rematrix_init.c
@@ -33,8 +33,12 @@ D(int16, sse2)
av_cold int swri_rematrix_init_x86(struct SwrContext *s){
#if HAVE_X86ASM
int mm_flags = av_get_cpu_flags();
-int nb_in = av_get_channel_layout_nb_channels(s->in_ch_layout);
-int nb_out = av_get_channel_layout_nb_channels(s->out_ch_layout);
+int nb_in = s->in_ch_layout != 0
+? av_get_channel_layout_nb_channels(s->in_ch_layout)
+: s->user_in_ch_count;
+int nb_out = s->out_ch_layout != 0
+? av_get_channel_layout_nb_channels(s->out_ch_layout)
+: s->user_out_ch_count;
int num= nb_in * nb_out;
int i,j;
Like said above I think the same effect can be achieved with less CPU
cycles by using a "(count > 0) ? count :
av_get_channel_layout_nb_channels(layout)" code pattern.
Also not sure what is the difference between the "in_ch_layout" field
used here and the "user_in_ch_layout" field used in function swr_set_matrix.
Minor nit: In my personal opinion putting parentheses around the
condition part of the ternary operator would improve readability.
Regards,
Tobias
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] ffv1dec: Ensure that pixel format constraints are respected
On Tue, Jul 17, 2018 at 11:58:06PM +0200,Michael Niedermayer wrote: > > Its a consequence of the subsampling factor. > > this does not follow from what you write below. But more so this is not > how pixel formats were implemented in FFmpeg. > Where does this idea come from ? I found the following description of this pixel format pretty accurate: https://linuxtv.org/downloads/v4l-dvb-apis/uapi/v4l/pixfmt-yuv410.html I am not sure how non-mod4 sizes work, but probably codecs within ffmpeg take into account more alignment than necessary and make things work within the ffmpeg libraries. Problems like this usually affect API users. Vittorio ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] svq1dec: Ensure that pixel format constraints are respected
2018-07-17 21:39 GMT+02:00, Carl Eugen Hoyos : > 2018-07-17 21:39 GMT+02:00, Vittorio Giovara : > > YUV410P requires that sizes are divisible by 4. There seem to be > > some encoders that ignore that and encode a different value in > > the bitstream itself. Handle that case by exporting the relative > > cropping information. > >Can you provide a sample? > >Thank you, Carl Eugen It is possible to generate samples affected by this bug with the svq1 or ffv1 encoders, like this: ./ffmpeg -f lavfi -i testsrc -s 190x240 -t 1 -pix_fmt yuv410p -c:v ffv1 output-yuv410p.avi A prime example where the generated sample will fail is with a strict scaler, such as zimg: ./ffmpeg -i output-yuv410p.avi -vf zscale -f null - which will fail with code 1027: image dimensions must be divisible by subsampling factor Error while filtering: Generic error in an external library Failed to inject frame into filter network: Generic error in an external library Error while processing the decoded data for stream #0:0 While the proposed patch won't directly fix the issue with zscale, it will offer tools for API users to adjust sizes accrodingly, and avoid it altoether. Regards, Vittorio ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] avformat/lrcdec: fix losing opening bracket
On Sat, Jul 14, 2018 at 8:37 PM Michael Niedermayer
wrote:
>
> On Fri, Jul 13, 2018 at 01:34:47PM +0530, Umair Khan wrote:
> > On Wed, Jul 11, 2018 at 11:07 PM Michael Niedermayer
> > wrote:
> > >
> > > On Tue, Jul 10, 2018 at 08:10:00PM +0530, Umair Khan wrote:
> > > > Hi,
> > > >
> > > > Patch attached.
> > > >
> > > > -Umair
> > >
> > > > lrcdec.c |3 +++
> > > > 1 file changed, 3 insertions(+)
> > > > 6782b07bfa45139361c15527ee5fb78e5893b9ba
> > > > 0001-avformat-lrcdec-fix-losing-opening-bracket.patch
> > > > From 95a5d2e5575c5f895e4251775a48f7deb4c86124 Mon Sep 17 00:00:00 2001
> > > > From: Umair Khan
> > > > Date: Tue, 10 Jul 2018 19:51:41 +0530
> > > > Subject: [PATCH 1/1] avformat/lrcdec: fix losing opening bracket
> > > >
> > > > Fixes #7255
> > > >
> > > > Signed-off-by: Umair Khan
> > > > ---
> > > > libavformat/lrcdec.c | 3 +++
> > > > 1 file changed, 3 insertions(+)
> > > >
> > > > diff --git a/libavformat/lrcdec.c b/libavformat/lrcdec.c
> > > > index f4e9a4efa9..d1e28aff87 100644
> > > > --- a/libavformat/lrcdec.c
> > > > +++ b/libavformat/lrcdec.c
> > > > @@ -68,6 +68,9 @@ static int64_t count_ts(const char *p)
> > > > (p[offset] >= '0' && p[offset] <= '9'))) {
> > > > offset++;
> > > > } else {
> > > > +if (in_brackets) {
> > > > +--offset;
> > > > +}
> > > > break;
> > >
> > > this is probably ok but it doesnt fix this completely
> > >
> > > consider 2 [[
> > > or a [123
> > >
> > > The code should probably remember the last position after a correctly
> > > parsed timestamp or maybe use sscanf() to parse these timestamps
> >
> > The new attached patch takes care of these cases.
> >
> > > Also it seems the code doesnt handle timestamps in the middle of lines
> > > (not related to your patch though)
> >
> > I can handle this case if you can give me an example of what case you
> > are talking about exactly.
> >
> > -Umair
>
> > lrcdec.c |7 ---
> > 1 file changed, 4 insertions(+), 3 deletions(-)
> > 72feffd56541236991001caaa92e533382b98b53
> > 0001-avformat-lrcdec-fix-losing-opening-bracket.patch
> > From 81c2e13aa0a7559886502cfb69f788bd0de7a64a Mon Sep 17 00:00:00 2001
> > From: Umair Khan
> > Date: Fri, 13 Jul 2018 13:24:51 +0530
> > Subject: [PATCH 1/1] avformat/lrcdec: fix losing opening bracket
> >
> > ---
> > libavformat/lrcdec.c | 7 ---
> > 1 file changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/libavformat/lrcdec.c b/libavformat/lrcdec.c
> > index f4e9a4efa9..4093cbdf10 100644
> > --- a/libavformat/lrcdec.c
> > +++ b/libavformat/lrcdec.c
> > @@ -60,14 +60,15 @@ static int64_t count_ts(const char *p)
> > } else if(p[offset] == '[') {
> > offset++;
> > in_brackets++;
> > -} else if (p[offset] == ']' && in_brackets) {
> > -offset++;
> > -in_brackets--;
> > } else if(in_brackets &&
> > (p[offset] == ':' || p[offset] == '.' || p[offset] == '-'
> > ||
> > (p[offset] >= '0' && p[offset] <= '9'))) {
> > offset++;
> > } else {
> > +if (p[offset] == ']' && in_brackets) {
> > +offset++;
> > +in_brackets--;
> > +}
> > break;
>
> This breaks multiple times like:
> [00:35.62][00:35.63][00:35.64]123 is a number
>
> this should be interpreted as 3 occurances of "123 is a number" IIUC
Are you sure about this? As much as I read, there's no example of it
being interpreted as 3 occurrences. It could be interpreted as empty
words at the first two timestamps.
For timestamps in the middle of the lines, do you mean something like
- "[xx.yy.zz] line1 [xx.yy.zz] lines2" ? Or something else?
-Umair
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/5] avcodec/lagarith: Remove redundant varianble init
On Sun, Jul 15, 2018 at 03:13:37PM +0200, Michael Niedermayer wrote: > Signed-off-by: Michael Niedermayer > --- > libavcodec/lagarith.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Take away the freedom of one citizen and you will be jailed, take away the freedom of all citizens and you will be congratulated by your peers in Parliament. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/5] avcodec/tscc: Move reget buffer to after decoding
On Sun, Jul 15, 2018 at 03:13:38PM +0200, Michael Niedermayer wrote: > reget buffer can be time consuming, theres no need to do it if failures > occur > > Testcase: > 9010/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TSCC_fuzzer-6042614817095680 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/tscc.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you drop bombs on a foreign country and kill a hundred thousand innocent people, expect your government to call the consequence "unprovoked inhuman terrorist attacks" and use it to justify dropping more bombs and killing more people. The technology changed, the idea is old. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/dvbsub_parser: Do not discard data
On Fri, Jul 06, 2018 at 05:24:29PM +0200, Michael Niedermayer wrote: > May fix: oss fuzz issue 9220 > > Signed-off-by: Michael Niedermayer > --- > libavcodec/dvbsub_parser.c | 16 +--- > 1 file changed, 9 insertions(+), 7 deletions(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 2 "100% positive feedback" - "All either got their money back or didnt complain" "Best seller ever, very honest" - "Seller refunded buyer after failed scam" signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/cfhd: Use bytestream2 for peaks
On Sun, Jul 15, 2018 at 08:51:36PM +0100, Kieran Kunhya wrote: > On Sat, 14 Jul 2018 at 00:14 Michael Niedermayer > wrote: > > > This fixes out of array accesses > > No testcase known > > > > Signed-off-by: Michael Niedermayer > > > > Looks ok if Gagandeep is ok noone seems to have objected so far so ill apply this soon thanks [...] -- 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: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mxfdec: drop invalid index table segments when sorting them
fre 2018-07-13 klockan 23:43 +0200 skrev Marton Balint:
> This way we can guess a proper index instead of using an invalid one.
>
> Fixes seeking in the sample of ticket #5671.
>
> > Signed-off-by: Marton Balint
> ---
> libavformat/mxfdec.c | 25 +
> 1 file changed, 17 insertions(+), 8 deletions(-)
>
> diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> index 996969d1ff..b032914388 100644
> --- a/libavformat/mxfdec.c
> +++ b/libavformat/mxfdec.c
> @@ -1348,9 +1348,22 @@ static int mxf_get_sorted_table_segments(MXFContext
> *mxf, int *nb_sorted_segment
> return AVERROR(ENOMEM);
> }
>
> -for (i = j = 0; i < mxf->metadata_sets_count; i++)
> -if (mxf->metadata_sets[i]->type == IndexTableSegment)
> -unsorted_segments[j++] =
> (MXFIndexTableSegment*)mxf->metadata_sets[i];
> +for (i = nb_segments = 0; i < mxf->metadata_sets_count; i++) {
> +if (mxf->metadata_sets[i]->type == IndexTableSegment) {
> +MXFIndexTableSegment *s =
> (MXFIndexTableSegment*)mxf->metadata_sets[i];
> +if (s->edit_unit_byte_count || s->nb_index_entries)
> +unsorted_segments[nb_segments++] = s;
> +else
> +av_log(mxf->fc, AV_LOG_WARNING, "IndexSID %i segment at
> %"PRId64" missing EditUnitByteCount and IndexEntryArray\n",
> + s->index_sid, s->index_start_position);
> +}
> +}
> +
> +if (!nb_segments) {
> +av_freep(sorted_segments);
> +av_free(unsorted_segments);
> +return AVERROR_INVALIDDATA;
> +}
>
> *nb_sorted_segments = 0;
>
> @@ -1482,7 +1495,7 @@ static int mxf_edit_unit_absolute_offset(MXFContext
> *mxf, MXFIndexTable *index_t
>
> if (s->edit_unit_byte_count)
> offset_temp += s->edit_unit_byte_count * index;
> -else if (s->nb_index_entries) {
> +else {
> if (s->nb_index_entries == 2 * s->index_duration + 1)
> index *= 2; /* Avid index */
>
> @@ -1493,10 +1506,6 @@ static int mxf_edit_unit_absolute_offset(MXFContext
> *mxf, MXFIndexTable *index_t
> }
>
> offset_temp = s->stream_offset_entries[index];
> -} else {
> -av_log(mxf->fc, AV_LOG_ERROR, "IndexSID %i segment at
> %"PRId64" missing EditUnitByteCount and IndexEntryArray\n",
> - index_table->index_sid, s->index_start_position);
> -return AVERROR_INVALIDDATA;
> }
>
> if (edit_unit_out)
Looks OK to me
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] Make the user help mailing lists subscription only
On 18-07-2018 04:13 AM, Lou Logan wrote: I'm considering changing the ffmpeg-user and libav-user mailing lists to only accept messages from subscribed users. ffmpeg-devel would be excluded from this due to the higher familiarity of mailing lists with that audience. What's the volume of messages from non-subscribers relative to subscribers? One issue I see with subscriptions is that the typical 'customer' of *-users is someone only interested in solving their problem. Receiving a bunch of unrelated messages every day, when one has only a narrow and temporary concern with ffmpeg, is annoying. When the list receives a message from a first-time non-subscriber user, can Mailman either auto-subscribe them or send out an email with a link to a pre-filled subscription page ? Just thinking of ways to reduce friction or annoyance for someone who's just discovered the ML and wants to post a query. Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Avoid undefined behavior by limiting PTS to 62 bits in ogg decoder
On Mon, Jul 16, 2018 at 04:32:14PM -0700, Fredrik Hubinette wrote: > With some (garbled) OGG data, PTS can overflow causing undefined behavior. > This patch avoids that by zeroing out PTS values greater than 2^62. > oggdec.h |3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > ff003b78842c7724ccc1a42f9584b1f8aa0b0b3d > 0001-Avoid-undefined-behavior-by-limiting-PTS-to-62-bits-.patch > From 26a8582bc04f5bddc037ffcce99025e2f977abe0 Mon Sep 17 00:00:00 2001 > From: Fredrik Hubinette > Date: Mon, 16 Jul 2018 14:54:43 -0700 > Subject: [PATCH] Avoid undefined behavior by limiting PTS to 62 bits in ogg > decoder > > --- > libavformat/oggdec.h | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) I think someone reading this commit message would like to know more about where that undefined behaviour occurs and how this is guranteeing to fix it [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB "Nothing to hide" only works if the folks in power share the values of you and everyone you know entirely and always will -- Tom Scott signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Patch: to add missing padding to nearest WORD boundary AVI
On Tue, Jul 10, 2018 at 08:06:40PM +0200, stefan.becker...@gmx.de wrote: > avidec.c |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > 5f20b4d86b6f21342654d925f4834aa199f99cca > 0001-add-missing-padding-to-nearest-WORD-boundary-AVI.patch > From 82bce9859429ab76261ef2ab852a03c9e0f03ece Mon Sep 17 00:00:00 2001 > From: Stefan Becker > Date: Tue, 10 Jul 2018 10:08:43 +0200 > Subject: [PATCH] add missing padding to nearest WORD boundary (AVI) > > --- > libavformat/avidec.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) i suspect this change is correct but i also would like to have a sample/testcase first [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Its not that you shouldnt use gotos but rather that you should write readable code and code with gotos often but not always is less readable signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Avoid undefined behavior when start_time_text is -1<<63
On Tue, Jul 17, 2018 at 02:37:55PM -0700, Fredrik Hubinette wrote: > > utils.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > e69f1a3a447e331cad7ea85e28c0ed13e48ce33c > 0001-Avoid-undefined-behavior-when-start_time_text-is-1-6.patch > From d7bd55c3d280c10b990577003a985296f10a2b59 Mon Sep 17 00:00:00 2001 > From: Fredrik Hubinette > Date: Tue, 17 Jul 2018 14:35:55 -0700 > Subject: [PATCH] Avoid undefined behavior when start_time_text is -1<<63 > > --- > libavformat/utils.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavformat/utils.c b/libavformat/utils.c > index c9cdd2b470..5b83ed7872 100644 > --- a/libavformat/utils.c > +++ b/libavformat/utils.c > @@ -2666,7 +2666,7 @@ static void update_stream_timings(AVFormatContext *ic) > duration = FFMAX(duration, duration1); > } > } > -if (start_time == INT64_MAX || (start_time > start_time_text && > start_time - start_time_text < AV_TIME_BASE)) > +if (start_time == INT64_MAX || (start_time > start_time_text && > start_time - AV_TIME_BASE < start_time_text )) Casting to uint64_t should be a more complete fix. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Awnsering whenever a program halts or runs forever is On a turing machine, in general impossible (turings halting problem). On any real computer, always possible as a real computer has a finite number of states N, and will either halt in less than N cycles or never halt. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] svq1dec: Ensure that pixel format constraints are respected
On Tue, Jul 17, 2018 at 09:39:18PM +0200, Vittorio Giovara wrote:
> YUV410P requires that sizes are divisible by 4. There seem to be
> some encoders that ignore that and encode a different value in
> the bitstream itself. Handle that case by exporting the relative
> cropping information.
> ---
> Alternatively it is possible to always enforce mod4 sizes and call
> it a day.
> Vittorio
>
> libavcodec/svq1dec.c | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/svq1dec.c b/libavcodec/svq1dec.c
> index d3e60c3a4a..55047b43ce 100644
> --- a/libavcodec/svq1dec.c
> +++ b/libavcodec/svq1dec.c
> @@ -663,7 +663,8 @@ static int svq1_decode_frame(AVCodecContext *avctx, void
> *data,
> return result;
> }
>
> -result = ff_set_dimensions(avctx, s->width, s->height);
> +/* sizes must be always disivible by 4 due to pixel format constraints */
> +result = ff_set_dimensions(avctx, FFALIGN(s->width, 4),
> FFALIGN(s->height, 4));
> if (result < 0)
> return result;
>
> @@ -755,6 +756,11 @@ static int svq1_decode_frame(AVCodecContext *avctx, void
> *data,
> *got_frame = 1;
> result = buf_size;
>
> +cur->crop_left = 0;
> +cur->crop_top= 0;
> +cur->crop_right = FFALIGN(s->width, 4) - s->width;
> +cur->crop_bottom = FFALIGN(s->height, 4) - s->height;
> +
> err:
> av_free(pmv);
> return result;
> @@ -843,6 +849,7 @@ AVCodec ff_svq1_decoder = {
> .close = svq1_decode_end,
> .decode = svq1_decode_frame,
> .capabilities = AV_CODEC_CAP_DR1,
> +.caps_internal = FF_CODEC_CAP_EXPORTS_CROPPING,
> .flush = svq1_flush,
> .pix_fmts = (const enum AVPixelFormat[]) { AV_PIX_FMT_YUV410P,
> AV_PIX_FMT_NONE },
I dont think this is neccessary. but if it is fixing some testcase iam
interrested in that testcase.
Also this seems to break make fate
TESTsvq1-headerswap
--- ./tests/ref/fate/svq1-headerswap2018-07-16 18:42:40.498707547 +0200
+++ tests/data/fate/svq1-headerswap 2018-07-18 12:24:50.225870370 +0200
@@ -4,6 +4,3 @@
#dimensions 0: 293x178
#sar 0: 0/1
0, 0, 0,1,58814, 0x5caad04b
-0, 1, 1,1,58814, 0x98d8ceb8
-0, 2, 2,1,58814, 0x8925cdb0
-0, 3, 3,1,58814, 0x6ffc02c3
Test svq1-headerswap failed. Look at tests/data/fate/svq1-headerswap.err for
details.
make: *** [fate-svq1-headerswap] Error 69
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] fate: add more vc2 encoder tests
On 2018-07-18 02:24, Michael Niedermayer wrote: > On Mon, Jul 16, 2018 at 01:03:53PM +0200, James Darnley wrote: >> From: James Darnley >> >> --- >> Michael, can you test this for the same failure you saw last time? > > seems to work in all cases i tested Good, I didn't confuse make this time. I will recheck after the mov changes Gyan pushed, update if nessecary, and push in a few minutes. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
