[FFmpeg-devel] [GASPP PATCH 2/2] Use cl for preprocessing when using armasm

2020-09-23 Thread Martin Storsjö
When invoking gas-preprocessor to preprocess only to get the dependency
list, we still need to use cpp, as cl doesn't support the -M options.

This allows using gas-preprocessor in an environment with only MSVC
available, no GCC/Clang providing a cpp.exe, allowing building e.g.
dav1d with MSVC targeting ARM, without any mingw/msys tools involved.
---
 gas-preprocessor.pl | 30 ++
 1 file changed, 18 insertions(+), 12 deletions(-)

diff --git a/gas-preprocessor.pl b/gas-preprocessor.pl
index e9baeba..69f6f6d 100755
--- a/gas-preprocessor.pl
+++ b/gas-preprocessor.pl
@@ -103,14 +103,7 @@ if (grep /\.c$/, @gcc_cmd) {
 if ($as_type eq "armasm") {
 
 $preprocess_c_cmd[0] = "cpp";
-push(@preprocess_c_cmd, "-undef");
-# Normally a preprocessor for windows would predefine _WIN32,
-# but we're using any generic system-agnostic preprocessor "cpp"
-# with -undef (to avoid getting predefined variables from the host
-# system in cross compilation cases), so manually define it here.
-push(@preprocess_c_cmd, "-D_WIN32");
-
-@preprocess_c_cmd = grep ! /^-nologo$/, @preprocess_c_cmd;
+
 # Remove -ignore XX parameter pairs from preprocess_c_cmd
 my $index = 1;
 while ($index < $#preprocess_c_cmd) {
@@ -121,10 +114,23 @@ if ($as_type eq "armasm") {
 $index++;
 }
 if (grep /^-MM$/, @preprocess_c_cmd) {
+push(@preprocess_c_cmd, "-D_WIN32");
+# Normally a preprocessor for windows would predefine _WIN32,
+# but we're using any generic system-agnostic preprocessor "cpp"
+# with -undef (to avoid getting predefined variables from the host
+# system in cross compilation cases), so manually define it here.
+# We only use this generic preprocessor for generating dependencies,
+# if the build system runs preprocessing with -M/-MM without -MF.
+push(@preprocess_c_cmd, "-undef");
+@preprocess_c_cmd = grep ! /^-nologo$/, @preprocess_c_cmd;
 print STDERR join(" ", @preprocess_c_cmd)."\n" if $verbose;
 system(@preprocess_c_cmd) == 0 or die "Error running preprocessor";
 exit 0;
 }
+
+# If not preprocessing for getting a dependency list, use cl.exe
+# instead.
+$preprocess_c_cmd[0] = "cl";
 }
 
 # if compiling, avoid creating an output file named '-.o'
@@ -139,13 +145,12 @@ if ((grep /^-c$/, @gcc_cmd) && !(grep /^-o/, @gcc_cmd)) {
 }
 }
 }
-# replace only the '-o' argument with '-', avoids rewriting the make dependency
-# target specified with -MT to '-'
+# Remove the -o argument; if omitted, we by default preprocess to stdout.
 my $index = 1;
 while ($index < $#preprocess_c_cmd) {
 if ($preprocess_c_cmd[$index] eq "-o") {
-$index++;
-$preprocess_c_cmd[$index] = "-";
+splice(@preprocess_c_cmd, $index, 2);
+last;
 }
 $index++;
 }
@@ -166,6 +171,7 @@ if ($as_type ne "armasm") {
 @preprocess_c_cmd = grep ! /^-oldit/, @preprocess_c_cmd;
 @preprocess_c_cmd = grep ! /^-FS/, @preprocess_c_cmd;
 @preprocess_c_cmd = grep ! /^-w/, @preprocess_c_cmd;
+@preprocess_c_cmd = grep ! /^-M/, @preprocess_c_cmd;
 
 @gcc_cmd = grep ! /^-G/, @gcc_cmd;
 @gcc_cmd = grep ! /^-W/, @gcc_cmd;
-- 
2.17.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] Tech consultant for video PoC

2020-09-23 Thread Michal Čudrnák
Hi all,

We’re looking for a tech consultant for a commercial proof of concept we’re 
working on with a video flow involving RT(S)P, ONVIF cameras, some OpenCV, 
video storage & playback, an iOS/macOS player and video + time-series data 
presentation sync. We’re all architects and developers but could do with some 
expertise to address specific video-related architectural issues related as 
well as some implementation work, potentially.

FFmpeg seems like an obvious foundation for this.

If anyone thinks they could help, please let me know and I’ll send more details 
and set up an intro call.

Best
Michal Čudrnák
Managing Partner
megaslice.uk
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] tests/fate-run: Always overwrite output files for md5 tests

2020-09-23 Thread Andreas Rheinhardt
Andreas Rheinhardt:
> Otherwise the result of such tests will not accurately reflect the
> current state.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  tests/fate-run.sh | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tests/fate-run.sh b/tests/fate-run.sh
> index 1b283e9c35..58d5fdbb60 100755
> --- a/tests/fate-run.sh
> +++ b/tests/fate-run.sh
> @@ -158,7 +158,7 @@ md5pipe(){
>  md5(){
>  encfile="${outdir}/${test}.out"
>  cleanfiles="$cleanfiles $encfile"
> -ffmpeg "$@" $(target_path $encfile)
> +ffmpeg -y "$@" $(target_path $encfile)
>  do_md5sum $encfile | awk '{print $1}'
>  }
>  
> 
Will apply tomorrow unless there are objections.

- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/3] avformat/swfdec: Fix memleaks on error

2020-09-23 Thread Andreas Rheinhardt
Andreas Rheinhardt:
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavformat/swfdec.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/libavformat/swfdec.c b/libavformat/swfdec.c
> index e427998744..7a74fa3ac7 100644
> --- a/libavformat/swfdec.c
> +++ b/libavformat/swfdec.c
> @@ -146,13 +146,18 @@ static int swf_read_header(AVFormatContext *s)
>  swf->zbuf_out = av_malloc(ZBUF_SIZE);
>  swf->zpb = avio_alloc_context(swf->zbuf_out, ZBUF_SIZE, 0, s,
>zlib_refill, NULL, NULL);
> -if (!swf->zbuf_in || !swf->zbuf_out || !swf->zpb)
> +if (!swf->zbuf_in || !swf->zbuf_out || !swf->zpb) {
> +av_freep(&swf->zbuf_in);
> +av_freep(&swf->zbuf_out);
> +avio_context_free(&swf->zpb);
>  return AVERROR(ENOMEM);
> +}
>  swf->zpb->seekable = 0;
>  if (inflateInit(&swf->zstream) != Z_OK) {
>  av_log(s, AV_LOG_ERROR, "Unable to init zlib context\n");
>  av_freep(&swf->zbuf_in);
>  av_freep(&swf->zbuf_out);
> +avio_context_free(&swf->zpb);
>  return AVERROR(EINVAL);
>  }
>  pb = swf->zpb;
> 
Will apply.

- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/3] avformat/swfdec: Reorder allocations/initializations

2020-09-23 Thread Andreas Rheinhardt
Andreas Rheinhardt:
> The earlier code would first attempt to allocate two buffers, then
> attempt to allocate an AVIOContext, using one of the new buffers I/O
> buffer, then check the allocations. On success, a z_stream that is used
> in the AVIOContext's read_packet callback is initialized afterwards.
> 
> There are two problems with this: In case the allocation of the I/O
> buffer fails avio_alloc_context() will be given a NULL read buffer
> with a size > 0. This works right now, but it is fragile. The second
> problem is that the z_stream used in the read_packet callback is not
> functional when avio_alloc_context() is allocated (it might be that
> avio_alloc_context() might already fill the buffer in the future). This
> commit fixes both of these problems by reordering the operations.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavformat/swfdec.c | 24 ++--
>  1 file changed, 10 insertions(+), 14 deletions(-)
> 
> diff --git a/libavformat/swfdec.c b/libavformat/swfdec.c
> index 7a74fa3ac7..d1ed1e2a53 100644
> --- a/libavformat/swfdec.c
> +++ b/libavformat/swfdec.c
> @@ -128,6 +128,8 @@ retry:
>  
>  return buf_size - z->avail_out;
>  }
> +
> +static av_cold int swf_read_close(AVFormatContext *avctx);
>  #endif
>  
>  static int swf_read_header(AVFormatContext *s)
> @@ -142,24 +144,18 @@ static int swf_read_header(AVFormatContext *s)
>  if (tag == MKBETAG('C', 'W', 'S', 0)) {
>  av_log(s, AV_LOG_INFO, "SWF compressed file detected\n");
>  #if CONFIG_ZLIB
> -swf->zbuf_in  = av_malloc(ZBUF_SIZE);
> -swf->zbuf_out = av_malloc(ZBUF_SIZE);
> -swf->zpb = avio_alloc_context(swf->zbuf_out, ZBUF_SIZE, 0, s,
> -  zlib_refill, NULL, NULL);
> -if (!swf->zbuf_in || !swf->zbuf_out || !swf->zpb) {
> -av_freep(&swf->zbuf_in);
> -av_freep(&swf->zbuf_out);
> -avio_context_free(&swf->zpb);
> -return AVERROR(ENOMEM);
> -}
> -swf->zpb->seekable = 0;
>  if (inflateInit(&swf->zstream) != Z_OK) {
>  av_log(s, AV_LOG_ERROR, "Unable to init zlib context\n");
> -av_freep(&swf->zbuf_in);
> -av_freep(&swf->zbuf_out);
> -avio_context_free(&swf->zpb);
>  return AVERROR(EINVAL);
>  }
> +if (!(swf->zbuf_in  = av_malloc(ZBUF_SIZE)) ||
> +!(swf->zbuf_out = av_malloc(ZBUF_SIZE)) ||
> +!(swf->zpb = avio_alloc_context(swf->zbuf_out, ZBUF_SIZE, 0,
> +s, zlib_refill, NULL, NULL))) {
> +swf_read_close(s);
> +return AVERROR(ENOMEM);
> +}
> +swf->zpb->seekable = 0;
>  pb = swf->zpb;
>  #else
>  av_log(s, AV_LOG_ERROR, "zlib support is required to read SWF 
> compressed files\n");
> 
Will apply.

- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] tests/fate-run: Always overwrite output files for md5 tests

2020-09-23 Thread Jan Ekström
On Sun, Sep 20, 2020 at 5:54 PM Andreas Rheinhardt
 wrote:
>
> Otherwise the result of such tests will not accurately reflect the
> current state.
>
> Signed-off-by: Andreas Rheinhardt 
> ---
>  tests/fate-run.sh | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tests/fate-run.sh b/tests/fate-run.sh
> index 1b283e9c35..58d5fdbb60 100755
> --- a/tests/fate-run.sh
> +++ b/tests/fate-run.sh
> @@ -158,7 +158,7 @@ md5pipe(){
>  md5(){
>  encfile="${outdir}/${test}.out"
>  cleanfiles="$cleanfiles $encfile"
> -ffmpeg "$@" $(target_path $encfile)
> +ffmpeg -y "$@" $(target_path $encfile)
>  do_md5sum $encfile | awk '{print $1}'
>  }
>
> --
> 2.25.1

LGTM.

I think I hit this when working with the movenc changes recently when
I had to update fate-mov-gpmf-remux.

In theory these tests should be using stdout + file redirection, but
alas this is what's configured here at the moment :) .

Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] tests/fate-run: Always overwrite output files for md5 tests

2020-09-23 Thread Andreas Rheinhardt
Jan Ekström:
> On Sun, Sep 20, 2020 at 5:54 PM Andreas Rheinhardt
>  wrote:
>>
>> Otherwise the result of such tests will not accurately reflect the
>> current state.
>>
>> Signed-off-by: Andreas Rheinhardt 
>> ---
>>  tests/fate-run.sh | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/tests/fate-run.sh b/tests/fate-run.sh
>> index 1b283e9c35..58d5fdbb60 100755
>> --- a/tests/fate-run.sh
>> +++ b/tests/fate-run.sh
>> @@ -158,7 +158,7 @@ md5pipe(){
>>  md5(){
>>  encfile="${outdir}/${test}.out"
>>  cleanfiles="$cleanfiles $encfile"
>> -ffmpeg "$@" $(target_path $encfile)
>> +ffmpeg -y "$@" $(target_path $encfile)
>>  do_md5sum $encfile | awk '{print $1}'
>>  }
>>
>> --
>> 2.25.1
> 
> LGTM.
> 
> I think I hit this when working with the movenc changes recently when
> I had to update fate-mov-gpmf-remux.
> 
> In theory these tests should be using stdout + file redirection, but
> alas this is what's configured here at the moment :) .
> 
> Jan

There is already a md5pipe test method for this (it uses our md5
protocol); the introduction of md5 test here was specifically done in
7ed6f9168b7fd13915e19b5cb1ed599c1a2d6d31 because the md5 protocol is not
seekable, so that the test results e.g. dependeded on the size of the
AVIO buffers (which determined whether a seek within the buffer
succeeded or not).

- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v3] avutil/pixfmt: improve definition of AVColorRange

2020-09-23 Thread Vittorio Giovara
On Sun, Sep 20, 2020 at 8:48 PM Jan Ekström  wrote:

> On Sun, Sep 20, 2020 at 9:34 PM Vittorio Giovara
>  wrote:
> >
> > On Sun, Sep 20, 2020 at 7:12 PM Jan Ekström  wrote:
> >
> > > As it was brought up that the current documentation leaves things
> > > as specific to YCbCr only, ICtCp and RGB are now mentioned.
> > > Additionally, the specifications on which these definitions of
> > > narrow and full range are defined are mentioned.
> > >
> > > This way, the documentation of AVColorRange should now match how
> > > most people seem to read interpret it at this point, and thus
> > > flagging RGB AVFrames as full range is valid not only according to
> > > common sense, but also the enum definition.
> > > ---
> > >  libavutil/pixfmt.h | 54 +++---
> > >  1 file changed, 51 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
> > > index a46acf3c5e..46ef211add 100644
> > > --- a/libavutil/pixfmt.h
> > > +++ b/libavutil/pixfmt.h
> > > @@ -530,12 +530,60 @@ enum AVColorSpace {
> > >  };
> > >
> > >  /**
> > > - * MPEG vs JPEG YUV range.
> > > + * Visual content value range.
> > > + *
> > > + * These values are based on definitions that can be found in multiple
> > > + * specifications, such as ITU-T BT.709 (3.4 - Quantization of RGB,
> > > luminance
> > > + * and colour-difference signals), ITU-T BT.2020 (Table 5 - Digital
> > > + * Representation) as well as ITU-T BT.2100 (Table 9 - Digital 10- and
> > > 12-bit
> > > + * integer representation). At the time of writing, the BT.2100 one is
> > > + * recommended, as it also defines the full range representation.
> > > + *
> > > + * Common definitions:
> > > + *   - For RGB and luminance planes such as Y in YCbCr and I in ICtCp,
> > > + * 'E' is the original value in range of 0.0 to 1.0.
> > > + *   - For chrominance planes such as Cb,Cr and Ct,Cp, 'E' is the
> original
> > > + * value in range of -0.5 to 0.5.
> > > + *   - 'n' is the output bit depth.
> > > + *   - For additional definitions such as rounding and clipping to
> valid n
> > > + * bit unsigned integer range, please refer to BT.2100 (Table 9).
> > >   */
> > >  enum AVColorRange {
> > >  AVCOL_RANGE_UNSPECIFIED = 0,
> > > -AVCOL_RANGE_MPEG= 1, ///< the normal 219*2^(n-8) "MPEG"
> YUV
> > > ranges
> > > -AVCOL_RANGE_JPEG= 2, ///< the normal 2^n-1   "JPEG"
> YUV
> > > ranges
> > > +
> > > +/**
> > > + * Narrow or limited range content.
> > > + *
> > > + * - For luminance planes:
> > > + *
> > > + *   (219 * E + 16) * 2^(n-8)
> > > + *
> > > + *   F.ex. the range of 16-235 for 8 bits
> > > + *
> > > + * - For chrominance planes:
> > > + *
> > > + *   (224 * E + 128) * 2^(n-8)
> > > + *
> > > + *   F.ex. the range of 16-240 for 8 bits
> > > + */
> > >
> >
> > I might have a minor suggestion: instead of giving the example for 8 bit
> > only, why not provide the generic formula for any bitdepth?
>
> I think I already have the formulas there ;) .
>
> If you generate the doxygen, it even puts the formula into a nice code
> block.
>
> > If you think it's too convoluted or the wrong place for this information,
> > I'd still recommend adding an example for 10 bit too, since a lot of new
> > content is produced in 10 bit, and could be a useful reference.
> >
>
> I think personally a single example is enough since the formulas and
> definition of E and n are already there. But if anyone else feels
> heavily for adding the 10 bit example values, I can add them.
>

No further comments over here, push any time!
-- 
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avformat/udp: remove redundant setting of h->max_packet_size

2020-09-23 Thread Zhao Zhili
h->max_packet_size is being reset in the following code.
---
 libavformat/udp.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/libavformat/udp.c b/libavformat/udp.c
index 30d8041433..96d8b8ee11 100644
--- a/libavformat/udp.c
+++ b/libavformat/udp.c
@@ -650,9 +650,6 @@ static int udp_open(URLContext *h, const char *uri, int 
flags)
 goto fail;
 }
 
-if (s->pkt_size > 0)
-h->max_packet_size = s->pkt_size;
-
 p = strchr(uri, '?');
 if (p) {
 if (av_find_info_tag(buf, sizeof(buf), "reuse", p)) {
-- 
2.25.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avformat/mov: move av_freep to if block to reduce no-ops

2020-09-23 Thread Zhao Zhili
Use the check since it's there already.
---
 libavformat/mov.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 4f64e96bc0..dcd263b02a 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -2909,9 +2909,10 @@ static int mov_read_stts(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 av_log(c->fc, AV_LOG_TRACE, "track[%u].stts.entries = %u\n",
 c->fc->nb_streams-1, entries);
 
-if (sc->stts_data)
+if (sc->stts_data) {
 av_log(c->fc, AV_LOG_WARNING, "Duplicated STTS atom\n");
-av_freep(&sc->stts_data);
+av_freep(&sc->stts_data);
+}
 sc->stts_count = 0;
 if (entries >= INT_MAX / sizeof(*sc->stts_data))
 return AVERROR(ENOMEM);
-- 
2.25.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v3] avutil/pixfmt: improve definition of AVColorRange

2020-09-23 Thread Jan Ekström
On Wed, Sep 23, 2020 at 6:49 PM Vittorio Giovara
 wrote:
>
> On Sun, Sep 20, 2020 at 8:48 PM Jan Ekström  wrote:
>
> > On Sun, Sep 20, 2020 at 9:34 PM Vittorio Giovara
> >  wrote:
> > >
> > > On Sun, Sep 20, 2020 at 7:12 PM Jan Ekström  wrote:
> > >
> > > > As it was brought up that the current documentation leaves things
> > > > as specific to YCbCr only, ICtCp and RGB are now mentioned.
> > > > Additionally, the specifications on which these definitions of
> > > > narrow and full range are defined are mentioned.
> > > >
> > > > This way, the documentation of AVColorRange should now match how
> > > > most people seem to read interpret it at this point, and thus
> > > > flagging RGB AVFrames as full range is valid not only according to
> > > > common sense, but also the enum definition.
> > > > ---
> > > >  libavutil/pixfmt.h | 54 +++---
> > > >  1 file changed, 51 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
> > > > index a46acf3c5e..46ef211add 100644
> > > > --- a/libavutil/pixfmt.h
> > > > +++ b/libavutil/pixfmt.h
> > > > @@ -530,12 +530,60 @@ enum AVColorSpace {
> > > >  };
> > > >
> > > >  /**
> > > > - * MPEG vs JPEG YUV range.
> > > > + * Visual content value range.
> > > > + *
> > > > + * These values are based on definitions that can be found in multiple
> > > > + * specifications, such as ITU-T BT.709 (3.4 - Quantization of RGB,
> > > > luminance
> > > > + * and colour-difference signals), ITU-T BT.2020 (Table 5 - Digital
> > > > + * Representation) as well as ITU-T BT.2100 (Table 9 - Digital 10- and
> > > > 12-bit
> > > > + * integer representation). At the time of writing, the BT.2100 one is
> > > > + * recommended, as it also defines the full range representation.
> > > > + *
> > > > + * Common definitions:
> > > > + *   - For RGB and luminance planes such as Y in YCbCr and I in ICtCp,
> > > > + * 'E' is the original value in range of 0.0 to 1.0.
> > > > + *   - For chrominance planes such as Cb,Cr and Ct,Cp, 'E' is the
> > original
> > > > + * value in range of -0.5 to 0.5.
> > > > + *   - 'n' is the output bit depth.
> > > > + *   - For additional definitions such as rounding and clipping to
> > valid n
> > > > + * bit unsigned integer range, please refer to BT.2100 (Table 9).
> > > >   */
> > > >  enum AVColorRange {
> > > >  AVCOL_RANGE_UNSPECIFIED = 0,
> > > > -AVCOL_RANGE_MPEG= 1, ///< the normal 219*2^(n-8) "MPEG"
> > YUV
> > > > ranges
> > > > -AVCOL_RANGE_JPEG= 2, ///< the normal 2^n-1   "JPEG"
> > YUV
> > > > ranges
> > > > +
> > > > +/**
> > > > + * Narrow or limited range content.
> > > > + *
> > > > + * - For luminance planes:
> > > > + *
> > > > + *   (219 * E + 16) * 2^(n-8)
> > > > + *
> > > > + *   F.ex. the range of 16-235 for 8 bits
> > > > + *
> > > > + * - For chrominance planes:
> > > > + *
> > > > + *   (224 * E + 128) * 2^(n-8)
> > > > + *
> > > > + *   F.ex. the range of 16-240 for 8 bits
> > > > + */
> > > >
> > >
> > > I might have a minor suggestion: instead of giving the example for 8 bit
> > > only, why not provide the generic formula for any bitdepth?
> >
> > I think I already have the formulas there ;) .
> >
> > If you generate the doxygen, it even puts the formula into a nice code
> > block.
> >
> > > If you think it's too convoluted or the wrong place for this information,
> > > I'd still recommend adding an example for 10 bit too, since a lot of new
> > > content is produced in 10 bit, and could be a useful reference.
> > >
> >
> > I think personally a single example is enough since the formulas and
> > definition of E and n are already there. But if anyone else feels
> > heavily for adding the 10 bit example values, I can add them.
> >
>
> No further comments over here, push any time!

Thanks, applied as d8ce8e8ed37e05136c96ac61f7aee83638d0600a .

Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avformat/mov: make better use of av_fast_realloc and fix spurious ENOMEM

2020-09-23 Thread Zhao Zhili
If sc->ctts_allocated_size is larger than the new buffer size,
av_fast_realloc() will return NULL. Since sc->ctts_data is freed,
ctts_allocated_size should be reset to zero. It's better to avoid
free sc->ctts_data at the first place to make better use of
av_fast_realloc().
---
 libavformat/mov.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index dcd263b02a..fcb5a583bd 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -3014,6 +3014,7 @@ static int mov_read_ctts(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 {
 AVStream *st;
 MOVStreamContext *sc;
+MOVStts *ctts_data;
 unsigned int i, entries, ctts_count = 0;
 
 if (c->fc->nb_streams < 1)
@@ -3031,10 +3032,13 @@ static int mov_read_ctts(MOVContext *c, AVIOContext 
*pb, MOVAtom atom)
 return 0;
 if (entries >= UINT_MAX / sizeof(*sc->ctts_data))
 return AVERROR_INVALIDDATA;
-av_freep(&sc->ctts_data);
-sc->ctts_data = av_fast_realloc(NULL, &sc->ctts_allocated_size, entries * 
sizeof(*sc->ctts_data));
-if (!sc->ctts_data)
+ctts_data = av_fast_realloc(sc->ctts_data, &sc->ctts_allocated_size, 
entries * sizeof(*sc->ctts_data));
+if (!ctts_data) {
+av_freep(&sc->ctts_data);
+sc->ctts_allocated_size = 0;
 return AVERROR(ENOMEM);
+}
+sc->ctts_data = ctts_data;
 
 for (i = 0; i < entries && !pb->eof_reached; i++) {
 int count= avio_rb32(pb);
-- 
2.25.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v3] libavcodec/vp8dec: fix the multi-thread HWAccel decode error

2020-09-23 Thread Eoff, Ullysses A
I tested:

PASS: make THREADS=2 THREAD_TYPE=frame fate-vp8
PASS: make THREADS=1 THREAD_TYPE=frame fate-vp8
PASS: make THREADS=8 THREAD_TYPE=frame fate-vp8
PASS: make THREADS=6 THREAD_TYPE=frame fate-vp8

FAIL: make THREADS=2 THREAD_TYPE=tile fate-vp8
FAIL: make THREADS=1 THREAD_TYPE=tile fate-vp8
FAIL: make THREADS=8 THREAD_TYPE=tile fate-vp8
FAIL: make THREADS=6 THREAD_TYPE=tile fate-vp8

The vp8-2451 case fails, above, for tile thread type *without* this patch, too.

This patch also fixes the issues reported at:

https://github.com/intel/media-driver/issues/1028 and
https://github.com/intel/media-driver/issues/1028#issuecomment-695033952

Regards,
U. Artie

> -Original Message-
> From: Xiang, Haihao 
> Sent: Monday, September 21, 2020 8:09 PM
> To: ffmpeg-devel@ffmpeg.org; Eoff, Ullysses A 
> Subject: Re: [FFmpeg-devel] [PATCH v3] libavcodec/vp8dec: fix the 
> multi-thread HWAccel decode error
> 
> 
> > *bump*
> >
> > This patch fixes vp8d output corruption in multi-thread mode.  This bug has
> > existed for way too long.
> 
> This patch works fine for me too, could someone in MAINTAINERS take a look at
> this patch and merge it if no problem?
> 
> Thanks
> Haihao
> 
> >
> > > -Original Message-
> > > From: ffmpeg-devel  On Behalf Of Wang,
> > > Shaofei
> > > Sent: Monday, July 01, 2019 1:22 AM
> > > To: FFmpeg development discussions and patches 
> > > Cc: Xiang, Haihao 
> > > Subject: Re: [FFmpeg-devel] [PATCH v3] libavcodec/vp8dec: fix the multi-
> > > thread HWAccel decode error
> > >
> > > > -Original Message-
> > > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> > > > myp...@gmail.com
> > > > Sent: Monday, July 1, 2019 3:28 PM
> > > > To: FFmpeg development discussions and patches 
> > > > Cc: Xiang, Haihao 
> > > > Subject: Re: [FFmpeg-devel] [PATCH v3] libavcodec/vp8dec: fix the
> > > > multi-thread HWAccel decode error
> > > >
> > > > On Mon, Jul 1, 2019 at 2:38 PM Wang, Shaofei 
> > > > wrote:
> > > > Is it this patch https://patchwork.ffmpeg.org/patch/13723/ fix the same
> > > > issue?
> > >
> > > It won't fix this issue in vp8.
> > > ___
> > > ffmpeg-devel mailing list
> > > ffmpeg-devel@ffmpeg.org
> > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > >
> > > To unsubscribe, visit link above, or email
> > > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v3] libavcodec/vp8dec: fix the multi-thread HWAccel decode error

2020-09-23 Thread Eoff, Ullysses A
> -Original Message-
> From: ffmpeg-devel  On Behalf Of Eoff, 
> Ullysses A
> Sent: Wednesday, September 23, 2020 10:33 AM
> To: Xiang, Haihao ; ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v3] libavcodec/vp8dec: fix the 
> multi-thread HWAccel decode error
> 
> I tested:
> 
> PASS: make THREADS=2 THREAD_TYPE=frame fate-vp8
> PASS: make THREADS=1 THREAD_TYPE=frame fate-vp8
> PASS: make THREADS=8 THREAD_TYPE=frame fate-vp8
> PASS: make THREADS=6 THREAD_TYPE=frame fate-vp8
> 
> FAIL: make THREADS=2 THREAD_TYPE=tile fate-vp8
> FAIL: make THREADS=1 THREAD_TYPE=tile fate-vp8
> FAIL: make THREADS=8 THREAD_TYPE=tile fate-vp8
> FAIL: make THREADS=6 THREAD_TYPE=tile fate-vp8
> 
> The vp8-2451 case fails, above, for tile thread type *without* this patch, 
> too.
> 
> This patch also fixes the issues reported at:
> 
> https://github.com/intel/media-driver/issues/1028 and
> https://github.com/intel/media-driver/issues/1028#issuecomment-695033952
> 
> Regards,
> U. Artie
> 

Oops, it is "slice" not "tile" (thanks BBB for your help), so:

PASS: make THREADS=2 THREAD_TYPE=slice fate-vp8
PASS: make THREADS=1 THREAD_TYPE=slice fate-vp8
PASS: make THREADS=8 THREAD_TYPE=slice fate-vp8
PASS: make THREADS=6 THREAD_TYPE=slice fate-vp8

Cheers,
U. Artie
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v2] examples/decode_video: flush parser to fix missing frame

2020-09-23 Thread Zhao Zhili
To reproduce, run decode_video with a single frame sample. No frame
was decoded before the patch.
---
 doc/examples/decode_video.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/doc/examples/decode_video.c b/doc/examples/decode_video.c
index 18ee90a6c0..9ce3531d63 100644
--- a/doc/examples/decode_video.c
+++ b/doc/examples/decode_video.c
@@ -92,6 +92,7 @@ int main(int argc, char **argv)
 uint8_t *data;
 size_t   data_size;
 int ret;
+int eof;
 AVPacket *pkt;
 
 if (argc <= 2) {
@@ -150,15 +151,14 @@ int main(int argc, char **argv)
 exit(1);
 }
 
-while (!feof(f)) {
+do {
 /* read raw data from the input file */
 data_size = fread(inbuf, 1, INBUF_SIZE, f);
-if (!data_size)
-break;
+eof = !data_size;
 
 /* use the parser to split the data into frames */
 data = inbuf;
-while (data_size > 0) {
+while (data_size > 0 || eof) {
 ret = av_parser_parse2(parser, c, &pkt->data, &pkt->size,
data, data_size, AV_NOPTS_VALUE, 
AV_NOPTS_VALUE, 0);
 if (ret < 0) {
@@ -170,8 +170,10 @@ int main(int argc, char **argv)
 
 if (pkt->size)
 decode(c, frame, pkt, outfilename);
+else if (eof)
+break;
 }
-}
+} while (!eof);
 
 /* flush the decoder */
 decode(c, frame, NULL, outfilename);
-- 
2.25.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] examples/decode_video: flush parser to fix missing frame

2020-09-23 Thread Zhao Zhili


> On Sep 9, 2020, at 1:55 PM, Guangxin Xu  wrote:
> 
> 
> 
> On Tue, Aug 18, 2020 at 8:05 PM  > wrote:
> From: Zhao Zhili mailto:quinkbl...@foxmail.com>>
> 
> To reproduce, run decode_video with a single frame sample. No frame
> was decoded before the patch.
> ---
>  doc/examples/decode_video.c | 12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/doc/examples/decode_video.c b/doc/examples/decode_video.c
> index 169188a4b9..ba753c6dc1 100644
> --- a/doc/examples/decode_video.c
> +++ b/doc/examples/decode_video.c
> @@ -92,6 +92,7 @@ int main(int argc, char **argv)
>  uint8_t *data;
>  size_t   data_size;
>  int ret;
> +int eof;
>  AVPacket *pkt;
> 
>  if (argc <= 2) {
> @@ -150,15 +151,14 @@ int main(int argc, char **argv)
>  exit(1);
>  }
> 
> -while (!feof(f)) {
> +do {
>  /* read raw data from the input file */
>  data_size = fread(inbuf, 1, INBUF_SIZE, f);
> -if (!data_size)
> -break;
> +eof = !data_size;
> 
>  /* use the parser to split the data into frames */
>  data = inbuf;
> -while (data_size > 0) {
> +while (data_size > 0 || eof) {
>  ret = av_parser_parse2(parser, c, &pkt->data, &pkt->size,
> data, data_size, AV_NOPTS_VALUE, 
> AV_NOPTS_VALUE, 0);
>  if (ret < 0) {
> @@ -170,8 +170,10 @@ int main(int argc, char **argv)
> 
>  if (pkt->size)
>  decode(c, frame, pkt, outfilename);
> +if (eof)
> +break;
> what if the parser cached more than one frame at the eof?

Good point. The internal loop should break only if (pkt->size == 0 && eof).

The updated patch:
http://ffmpeg.org/pipermail/ffmpeg-devel/2020-September/270251.html

>  }
> -}
> +} while (!eof);
> 
>  /* flush the decoder */
>  decode(c, frame, NULL, outfilename);
> -- 
> 2.28.0
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org 
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel 
> 
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org  with 
> subject "unsubscribe".

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avformat/http: fix memleak

2020-09-23 Thread Zhao Zhili
Ping for review.

> On Aug 24, 2020, at 12:58 AM, Zhao Zhili  wrote:
> 
> ---
> libavformat/http.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/libavformat/http.c b/libavformat/http.c
> index 6c39da1a8b..3d25d652d3 100644
> --- a/libavformat/http.c
> +++ b/libavformat/http.c
> @@ -577,7 +577,7 @@ static int http_open(URLContext *h, const char *uri, int 
> flags,
>"No trailing CRLF found in HTTP header. Adding it.\n");
> ret = av_reallocp(&s->headers, len + 3);
> if (ret < 0)
> -return ret;
> +goto bail_out;
> s->headers[len] = '\r';
> s->headers[len + 1] = '\n';
> s->headers[len + 2] = '\0';
> @@ -588,6 +588,7 @@ static int http_open(URLContext *h, const char *uri, int 
> flags,
> return http_listen(h, uri, flags, options);
> }
> ret = http_open_cnx(h, options);
> +bail_out:
> if (ret < 0)
> av_dict_free(&s->chained_options);
> return ret;
> -- 
> 2.25.1
> 

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v3] libavcodec/vp8dec: fix the multi-thread HWAccel decode error

2020-09-23 Thread Ronald S. Bultje
Hi,

On Wed, Sep 23, 2020 at 1:48 PM Eoff, Ullysses A 
wrote:

> > -Original Message-
> > From: ffmpeg-devel  On Behalf Of Eoff,
> Ullysses A
> > Sent: Wednesday, September 23, 2020 10:33 AM
> > To: Xiang, Haihao ; ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [PATCH v3] libavcodec/vp8dec: fix the
> multi-thread HWAccel decode error
> >
> > I tested:
> >
> > PASS: make THREADS=2 THREAD_TYPE=frame fate-vp8
> > PASS: make THREADS=1 THREAD_TYPE=frame fate-vp8
> > PASS: make THREADS=8 THREAD_TYPE=frame fate-vp8
> > PASS: make THREADS=6 THREAD_TYPE=frame fate-vp8
> >
> > FAIL: make THREADS=2 THREAD_TYPE=tile fate-vp8
> > FAIL: make THREADS=1 THREAD_TYPE=tile fate-vp8
> > FAIL: make THREADS=8 THREAD_TYPE=tile fate-vp8
> > FAIL: make THREADS=6 THREAD_TYPE=tile fate-vp8
> >
> > The vp8-2451 case fails, above, for tile thread type *without* this
> patch, too.
> >
> > This patch also fixes the issues reported at:
> >
> > https://github.com/intel/media-driver/issues/1028 and
> > https://github.com/intel/media-driver/issues/1028#issuecomment-695033952
> >
> > Regards,
> > U. Artie
> >
>
> Oops, it is "slice" not "tile" (thanks BBB for your help), so:
>
> PASS: make THREADS=2 THREAD_TYPE=slice fate-vp8
> PASS: make THREADS=1 THREAD_TYPE=slice fate-vp8
> PASS: make THREADS=8 THREAD_TYPE=slice fate-vp8
> PASS: make THREADS=6 THREAD_TYPE=slice fate-vp8


Merged.

Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avformat/flvdec: RtmpSampleAccess no longer breaks stream detection

2020-09-23 Thread Michael Niedermayer
On Mon, Sep 21, 2020 at 12:10:04PM +0200, Peter van der Spek wrote:
> Hi Michael,
> 
> Friendly ping to get this one merged.

will apply

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Nations do behave wisely once they have exhausted all other alternatives. 
-- Abba Eban


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avfilter/setparams: add FF_FILTER_FLAG_HWFRAME_AWARE

2020-09-23 Thread Paul B Mahol
On Mon, Sep 21, 2020 at 09:47:40PM -0600, Pavel Koshevoy wrote:
> Allow setparams to be used with hw backed frames and
> avoid an assertion failure in avfilter_config_links.
> ---
>  libavfilter/vf_setparams.c | 3 +++
>  1 file changed, 3 insertions(+)
> 

LGTM

> diff --git a/libavfilter/vf_setparams.c b/libavfilter/vf_setparams.c
> index 689097fac0..72a69e3fc2 100644
> --- a/libavfilter/vf_setparams.c
> +++ b/libavfilter/vf_setparams.c
> @@ -169,6 +169,7 @@ AVFilter ff_vf_setparams = {
>  .priv_class  = &setparams_class,
>  .inputs  = inputs,
>  .outputs = outputs,
> +.flags_internal = FF_FILTER_FLAG_HWFRAME_AWARE,
>  };
>  
>  #if CONFIG_SETRANGE_FILTER
> @@ -208,6 +209,7 @@ AVFilter ff_vf_setrange = {
>  .priv_class  = &setrange_class,
>  .inputs  = inputs,
>  .outputs = outputs,
> +.flags_internal = FF_FILTER_FLAG_HWFRAME_AWARE,
>  };
>  #endif /* CONFIG_SETRANGE_FILTER */
>  
> @@ -242,5 +244,6 @@ AVFilter ff_vf_setfield = {
>  .priv_class  = &setfield_class,
>  .inputs  = inputs,
>  .outputs = outputs,
> +.flags_internal = FF_FILTER_FLAG_HWFRAME_AWARE,
>  };
>  #endif /* CONFIG_SETFIELD_FILTER */
> -- 
> 2.26.2
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/cfhd: check that lowpass_height is >= 3 when used in vertical filter

2020-09-23 Thread Michael Niedermayer
On Tue, Sep 22, 2020 at 08:50:57PM +0200, Paul B Mahol wrote:
> Also check for out of buffer access.
> Also return early when encountering fatal error.
> 
> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/cfhd.c | 89 +--
>  1 file changed, 56 insertions(+), 33 deletions(-)

should be ok

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avformat/udp: remove redundant setting of h->max_packet_size

2020-09-23 Thread myp...@gmail.com
On Thu, Sep 24, 2020 at 12:15 AM Zhao Zhili  wrote:
>
> h->max_packet_size is being reset in the following code.
> ---
>  libavformat/udp.c | 3 ---
>  1 file changed, 3 deletions(-)
>
> diff --git a/libavformat/udp.c b/libavformat/udp.c
> index 30d8041433..96d8b8ee11 100644
> --- a/libavformat/udp.c
> +++ b/libavformat/udp.c
> @@ -650,9 +650,6 @@ static int udp_open(URLContext *h, const char *uri, int 
> flags)
>  goto fail;
>  }
>
> -if (s->pkt_size > 0)
> -h->max_packet_size = s->pkt_size;
> -
>  p = strchr(uri, '?');
>  if (p) {
>  if (av_find_info_tag(buf, sizeof(buf), "reuse", p)) {
> --
LGTM
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avformat/http: fix memleak

2020-09-23 Thread myp...@gmail.com
On Thu, Sep 24, 2020 at 2:10 AM Zhao Zhili  wrote:
>
> Ping for review.
>
> > On Aug 24, 2020, at 12:58 AM, Zhao Zhili  wrote:
> >
> > ---
> > libavformat/http.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavformat/http.c b/libavformat/http.c
> > index 6c39da1a8b..3d25d652d3 100644
> > --- a/libavformat/http.c
> > +++ b/libavformat/http.c
> > @@ -577,7 +577,7 @@ static int http_open(URLContext *h, const char *uri, 
> > int flags,
> >"No trailing CRLF found in HTTP header. Adding it.\n");
> > ret = av_reallocp(&s->headers, len + 3);
> > if (ret < 0)
> > -return ret;
> > +goto bail_out;
> > s->headers[len] = '\r';
> > s->headers[len + 1] = '\n';
> > s->headers[len + 2] = '\0';
> > @@ -588,6 +588,7 @@ static int http_open(URLContext *h, const char *uri, 
> > int flags,
> > return http_listen(h, uri, flags, options);
> > }
> > ret = http_open_cnx(h, options);
> > +bail_out:
> > if (ret < 0)
> > av_dict_free(&s->chained_options);
> > return ret;
> > --
> > 2.25.1
> >
>
LGTM
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v5 2/2] libavformat/webp: add WebP demuxer

2020-09-23 Thread Zlomek, Josef
On Sat, Sep 12, 2020 at 3:01 PM Lynne  wrote:

> On 11/09/2020 08:36, Josef Zlomek wrote:
> > Adds the demuxer of animated WebP files.
> > It supports non-animated, animated, truncated, and concatenated files.
> > Reading from a pipe (and other non-seekable inputs) is also supported.
> >
> > The WebP demuxer splits the input stream into packets containing one
> frame.
> > It also marks the key frames properly.
> > The loop count is ignored by default (same behaviour as animated PNG and
> GIF),
> > it may be enabled by the option '-ignore_loop 0'.
> >
> > The frame rate is set according to the frame delay in the ANMF chunk.
> > If the delay is too low, or the image is not animated, the default frame
> rate
> > is set to 10 fps, similarly to other WebP libraries and browsers.
> > The fate suite was updated accordingly.
> >
> > Signed-off-by: Josef Zlomek 
> Can someone take a look at the demuxer? I'd rather not apply the decoder
> without the demuxer, and lavf isn't my specialty.
>

Does someone have time to look at the WebP demuxer?

Josef
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".