Re: [FFmpeg-devel] [PATCH v7 2/2] lavc/tiff: Decode embedded JPEGs in DNG images

[Paul B Mahol]

On Sun, Jul 28, 2019 at 12:30 AM Reimar Döffinger 
wrote:

> On 26.07.2019, at 09:34, Nick Renieris  wrote:
>
> > Στις Παρ, 26 Ιουλ 2019 στις 2:21 π.μ., ο/η Reimar Döffinger
> >  έγραψε:
> >>
> >> On 25.07.2019, at 17:35, velocit...@gmail.com wrote:
> >>
> >>> +// Lookup table lookup
> >>> +if (lut)
> >>> +value = lut[value];
> >>
> >> As this function is in the innermost loop, doing the if here instead of
> having 2 different implementations is likely not ideal speed-wise.
> >
> > If this were C++ this'd be trivial, but as it stands I don't see a way
> > to do this without sacrificing code readability and/or size.
>
> Huh? Are you thinking of templates? always_inline can usually be used the
> same way.
> I haven't looked into the how or anything, it was just a comment in
> principle.
>
> > I believe branch prediction and instruction pipelining will hide this
> > delay. I doubt it has any measurable effect on performance.
>
> There are CPUs without that.
>
> >>> +// Color scaling
> >>> +value = av_clip_uint16_c((unsigned)(((float)value * scale_factor)
> * 0x));
> >>
> >> As input and output are both 16 bit I wonder if floating-point isn't
> rather overkill compared to doing fixed-point arithmetic.
> >
> > Scaling in the [0.0, 1.0] range is mentioned in the DNG spec and it's
> > also what dcraw does.
>
> I don't see the connection? The point is as input and output are 16 bit
> this calculation can be done as integer operations without the need for
> floating point and all the conversion.
> Depending on required precision with either 32 or 64 bit intermediate
> values.
> Essentially by simply changing
> (value * scale_factor) * 0x
> to something along the lines of
> (value * (unsigned)(scale_factor * 0x * (1<<8))) >> 8
> With of course most all but one multiply and shift outside the loop.
> Of course would need to look at what the actual requirements are
> concerning precision, rounding and range. But that should be done anyway.
>
> >>> +if (is_u16) {
> >>> +for (line = 0; line < height; line++) {
> >>> +uint16_t *dst_u16 = (uint16_t *)dst;
> >>> +uint16_t *src_u16 = (uint16_t *)src;
> >>> +
> >>> +for (col = 0; col < width; col++)
> >>> +*dst_u16++ = dng_raw_to_linear16(*src_u16++,
> s->dng_lut, s->black_level, scale_factor);
> >>> +
> >>> +dst += dst_stride * sizeof(uint16_t);
> >>> +src += src_stride * sizeof(uint16_t);
> >>
> >> Is all this casting working correctly on e.g. big-endian?
> >
> > Not sure, I don't see why not, considering I've seen such casting in
> > other parts of ffmpeg.
>
> Well, I did not find it obvious where src and dst are from and what format
> they are in.
> Essentially if they are decoder output it's likely fine, if they are read
> from a file without decoding step it's likely wrong.
>
> >> Also not sure if since these are essentially brightness/contrast
> adjustments if we should't rather just have a way to export the transform
> to use...
> >
> > Export to where?
>
> Just provide as metadata and leave to e.g. libavfilter.
>

That does not follow DNG specification.
I really do not have time to comment on other irrelevant stuff you pointed
in your review.


>
> > I don't see why you'd need to complicate this by
> > calling into other components, the transformation code is concise,
> > clear and accurate for this use case.
>
> Slow and unoptimized and in it's current form hard to SIMD optimize,
> especially without changing output as well though (in addition to the large
> bit width of floats reducing the benefit, denormals can be an issue for
> SIMD-accelerating float code).
> Unless I miss a reason why nobody would ever want this to be faster?
>
> >>> @@ -1519,6 +1773,26 @@ again:
> >>>return AVERROR_INVALIDDATA;
> >>>}
> >>>
> >>> +/* Handle DNG images with JPEG-compressed tiles */
> >>> +
> >>> +if (s->tiff_type == TIFF_TYPE_DNG || s->tiff_type ==
> TIFF_TYPE_CINEMADNG) {
> >>> +if (s->is_jpeg) {
> >>> +if (s->is_bayer) {
> >>> +if ((ret = dng_decode(avctx, (AVFrame*)data, avpkt))
> > 0)
> >>> +*got_frame = 1;
> >>> +return ret;
> >>> +} else {
> >>> +avpriv_report_missing_feature(avctx, "DNG
> JPG-compressed non-bayer-encoded images");
> >>> +return AVERROR_PATCHWELCOME;
> >>> +}
> >>> +} else if (s->is_tiled) {
> >>> +avpriv_report_missing_feature(avctx, "DNG uncompressed
> tiled images");
> >>> +return AVERROR_PATCHWELCOME;
> >>> +}
> >>
> >> There is no need for an "else" block if the "if" block ends in a return.
> >
> > Indeed, but in my opinion it makes the code clearer on first glance
> > (if you miss the return). I can change it if you insist.
>
> The second comment was the more relevant one actually.
> I only really care about finding some way to make this part 

Re: [FFmpeg-devel] [PATCH v7 2/2] lavc/tiff: Decode embedded JPEGs in DNG images

[Nick Renieris]

Στις Κυρ, 28 Ιουλ 2019 στις 1:30 π.μ., ο/η Reimar Döffinger
 έγραψε:
>
> Huh? Are you thinking of templates? always_inline can usually be used the 
> same way.
> I haven't looked into the how or anything, it was just a comment in principle.

You're totally right (I checked on godbolt just to make sure), I
hadn't considered that. Would need a trivial change (plus the function
is already inlined) so I'll do it.

> > I believe branch prediction and instruction pipelining will hide this
> > delay. I doubt it has any measurable effect on performance.
>
> There are CPUs without that.

Yes, but with neither? Branch prediction, sure, but I'd like to hear
one example of a CPU FFmpeg runs on without pipelining (I genuinely
don't know if there are).

> Of course would need to look at what the actual requirements are concerning 
> precision, rounding and range. But that should be done anyway.
Like I said, I did. It's not possible :)

> Well, I did not find it obvious where src and dst are from and what format 
> they are in.
> Essentially if they are decoder output it's likely fine, if they are read 
> from a file without decoding step it's likely wrong.

Right, I see your concern. They are read from a file and they can be
both LE/BE, but that's specified in the file and there is logic in
tiff.c to account for it. So when we process them they are guaranteed
to be the same endianness as the host.

> >> Also not sure if since these are essentially brightness/contrast 
> >> adjustments if we should't rather just have a way to export the transform 
> >> to use...
> >
> > Export to where?
>
> Just provide as metadata and leave to e.g. libavfilter.

Not sure how I'd do that or if it'd be appropriate/feasible.

> > I don't see why you'd need to complicate this by
> > calling into other components, the transformation code is concise,
> > clear and accurate for this use case.
>
> Slow and unoptimized and in it's current form hard to SIMD optimize, 
> especially without changing output as well though (in addition to the large 
> bit width of floats reducing the benefit, denormals can be an issue for 
> SIMD-accelerating float code).
> Unless I miss a reason why nobody would ever want this to be faster?

I'll take out the comparison which should make it faster, I'll talk
with my mentor if he thinks I should use libavfilter.

> >> There is no need for an "else" block if the "if" block ends in a return.
> >
> > Indeed, but in my opinion it makes the code clearer on first glance
> > (if you miss the return). I can change it if you insist.
>
> The second comment was the more relevant one actually.
> I only really care about finding some way to make this part a whole lot more 
> readable.

Ok, hopefully the code I posted right after your review is readable enough.
___
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 v7 2/2] lavc/tiff: Decode embedded JPEGs in DNG images

[Nick Renieris]

Actually, I checked a more accurate version of my loop, and GCC
optimizes away the LUT check anyway:
https://godbolt.org/z/G1e1R4
As you can see it's smart enough to create 2 versions of my functions
(started at L3 with a lookup and L7 without it) and it does the check
outside.

There's no guarantee this is happening with the actual version of
course (it could be slower, or even faster if it also optimizes it
through dng_blit).
I could check the actual disasm in FFmpeg, but I don't think it's
worth it at this point (my mentor agrees).

Στις Κυρ, 28 Ιουλ 2019 στις 10:40 π.μ., ο/η Nick Renieris
 έγραψε:
>
> Στις Κυρ, 28 Ιουλ 2019 στις 1:30 π.μ., ο/η Reimar Döffinger
>  έγραψε:
> >
> > Huh? Are you thinking of templates? always_inline can usually be used the 
> > same way.
> > I haven't looked into the how or anything, it was just a comment in 
> > principle.
>
> You're totally right (I checked on godbolt just to make sure), I
> hadn't considered that. Would need a trivial change (plus the function
> is already inlined) so I'll do it.
>
> > > I believe branch prediction and instruction pipelining will hide this
> > > delay. I doubt it has any measurable effect on performance.
> >
> > There are CPUs without that.
>
> Yes, but with neither? Branch prediction, sure, but I'd like to hear
> one example of a CPU FFmpeg runs on without pipelining (I genuinely
> don't know if there are).
>
> > Of course would need to look at what the actual requirements are concerning 
> > precision, rounding and range. But that should be done anyway.
> Like I said, I did. It's not possible :)
>
> > Well, I did not find it obvious where src and dst are from and what format 
> > they are in.
> > Essentially if they are decoder output it's likely fine, if they are read 
> > from a file without decoding step it's likely wrong.
>
> Right, I see your concern. They are read from a file and they can be
> both LE/BE, but that's specified in the file and there is logic in
> tiff.c to account for it. So when we process them they are guaranteed
> to be the same endianness as the host.
>
> > >> Also not sure if since these are essentially brightness/contrast 
> > >> adjustments if we should't rather just have a way to export the 
> > >> transform to use...
> > >
> > > Export to where?
> >
> > Just provide as metadata and leave to e.g. libavfilter.
>
> Not sure how I'd do that or if it'd be appropriate/feasible.
>
> > > I don't see why you'd need to complicate this by
> > > calling into other components, the transformation code is concise,
> > > clear and accurate for this use case.
> >
> > Slow and unoptimized and in it's current form hard to SIMD optimize, 
> > especially without changing output as well though (in addition to the large 
> > bit width of floats reducing the benefit, denormals can be an issue for 
> > SIMD-accelerating float code).
> > Unless I miss a reason why nobody would ever want this to be faster?
>
> I'll take out the comparison which should make it faster, I'll talk
> with my mentor if he thinks I should use libavfilter.
>
> > >> There is no need for an "else" block if the "if" block ends in a return.
> > >
> > > Indeed, but in my opinion it makes the code clearer on first glance
> > > (if you miss the return). I can change it if you insist.
> >
> > The second comment was the more relevant one actually.
> > I only really care about finding some way to make this part a whole lot 
> > more readable.
>
> Ok, hopefully the code I posted right after your review is readable enough.
___
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, v4 1/2] fftools/ffmpeg_filter: add -autoscale to disable/enable the default scale

[Linjie Fu]

Currently, ffmpeg inserts scale filter by default in the filter graph
to force the whole decoded stream to scale into the same size with the
first frame. It's not quite make sense in resolution changing cases if
user wants the rawvideo without any scale.

Using autoscale/noautoscale to indicate whether auto inserting the scale
filter in the filter graph:
-noautoscale or -autoscale 0:
disable the default auto scale filter inserting.

Update docs.

Signed-off-by: U. Artie Eoff 
Signed-off-by: Linjie Fu 
---
 doc/ffmpeg.texi | 16 
 fftools/ffmpeg.c|  1 +
 fftools/ffmpeg.h|  4 
 fftools/ffmpeg_filter.c |  2 +-
 fftools/ffmpeg_opt.c|  8 
 5 files changed, 26 insertions(+), 5 deletions(-)

diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index cd35eb4..29da951 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -734,10 +734,6 @@ ffmpeg -dump_attachment:t "" -i INPUT
 Technical note -- attachments are implemented as codec extradata, so this
 option can actually be used to extract extradata from any stream, not just
 attachments.
-
-@item -noautorotate
-Disable automatically rotating video based on file metadata.
-
 @end table
 
 @section Video Options
@@ -819,6 +815,18 @@ Create the filtergraph specified by @var{filtergraph} and 
use it to
 filter the stream.
 
 This is an alias for @code{-filter:v}, see the @ref{filter_option,,-filter 
option}.
+
+@item -autorotate
+Automatically rotate the video according to file metadata. Enabled by
+default, use @option{-noautorotate} to disable it.
+
+@item -autoscale
+Automatically scale the video according to the resolution of first frame.
+Enabled by default, use @option{-noautoscale} to disable it. When autoscale is
+disabled, all output frames of filter graph might not be in the same resolution
+and may be inadequate for some encoder/muxer. Therefore, it is not recommended
+to disable it unless you really know what you are doing.
+Disable autoscale at your own risk.
 @end table
 
 @section Advanced Video options
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 01f0410..5d52430 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -2133,6 +2133,7 @@ static int ifilter_send_frame(InputFilter *ifilter, 
AVFrame *frame)
 
 /* determine if the parameters for this input changed */
 need_reinit = ifilter->format != frame->format;
+fg->autoscale = ifilter->ist->autoscale;
 
 switch (ifilter->ist->st->codecpar->codec_type) {
 case AVMEDIA_TYPE_AUDIO:
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index 7b6f802..1602406 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -133,6 +133,8 @@ typedef struct OptionsContext {
 intnb_hwaccel_output_formats;
 SpecifierOpt *autorotate;
 intnb_autorotate;
+SpecifierOpt *autoscale;
+intnb_autoscale;
 
 /* output options */
 StreamMap *stream_maps;
@@ -285,6 +287,7 @@ typedef struct FilterGraph {
 
 AVFilterGraph *graph;
 int reconfiguration;
+int autoscale;
 
 InputFilter   **inputs;
 int  nb_inputs;
@@ -335,6 +338,7 @@ typedef struct InputStream {
 int guess_layout_max;
 
 int autorotate;
+int autoscale;
 
 int fix_sub_duration;
 struct { /* previous decoded subtitle and related variables */
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index 72838de..2a2eb08 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -469,7 +469,7 @@ static int configure_output_video_filter(FilterGraph *fg, 
OutputFilter *ofilter,
 if (ret < 0)
 return ret;
 
-if (ofilter->width || ofilter->height) {
+if ((ofilter->width || ofilter->height) && fg->autoscale) {
 char args[255];
 AVFilterContext *filter;
 AVDictionaryEntry *e = NULL;
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index f5ca18a..41cb676 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -742,7 +742,9 @@ static void add_input_streams(OptionsContext *o, 
AVFormatContext *ic)
 MATCH_PER_STREAM_OPT(ts_scale, dbl, ist->ts_scale, ic, st);
 
 ist->autorotate = 1;
+ist->autoscale  = 1;
 MATCH_PER_STREAM_OPT(autorotate, i, ist->autorotate, ic, st);
+MATCH_PER_STREAM_OPT(autoscale, i, ist->autoscale, ic, st);
 
 MATCH_PER_STREAM_OPT(codec_tags, str, codec_tag, ic, st);
 if (codec_tag) {
@@ -3640,6 +3642,12 @@ const OptionDef options[] = {
 { "autorotate",   HAS_ARG | OPT_BOOL | OPT_SPEC |
   OPT_EXPERT | OPT_INPUT,  
  { .off = OFFSET(autorotate) },
 "automatically insert correct rotate filters" },
+{ "autoscale",HAS_ARG | OPT_BOOL | OPT_SPEC |
+  OPT_EXPERT | OPT_INPUT,  
  { .off = OFFSET(autoscale) },
+"automatically insert a scale filter at the end of the filter graph if 
a resolution"
+"change is de

[FFmpeg-devel] [PATCH, RFC 2/2] fftools/ffmpeg: add dynamic resolution encode support for libvpx-vp9

[Linjie Fu]

According to spec, vp9 should support dynamic resolution changes.

Add dynamic resolution encoding support in libvpx-vp9, and flush
encoders when resolution change happens.

Format change should also be supported, but I didn't test it so just
leave it open.

cmdline:
ffmpeg -noautoscale -y -i ./reinit-large_420_8-to-small_420_8.h264
 -pix_fmt yuv420p -c:v libvpx-vp9 lena.ivf

Signed-off-by: Linjie Fu 
---
 fftools/ffmpeg.c   | 9 +
 libavcodec/libvpxenc.c | 9 +
 2 files changed, 18 insertions(+)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 5d52430..e091117 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -64,6 +64,7 @@
 #include "libavutil/thread.h"
 #include "libavutil/threadmessage.h"
 #include "libavcodec/mathops.h"
+#include "libavcodec/internal.h"
 #include "libavformat/os_support.h"
 
 # include "libavfilter/avfilter.h"
@@ -130,6 +131,7 @@ static void do_video_stats(OutputStream *ost, int 
frame_size);
 static BenchmarkTimeStamps get_benchmark_time_stamps(void);
 static int64_t getmaxrss(void);
 static int ifilter_has_all_input_formats(FilterGraph *fg);
+static void flush_encoders(void);
 
 static int run_as_daemon  = 0;
 static int nb_frames_dup = 0;
@@ -1067,6 +1069,13 @@ static void do_video_out(OutputFile *of,
 InputStream *ist = NULL;
 AVFilterContext *filter = ost->filter->filter;
 
+/* flush encoders in dynamic resolution encode */
+if (next_picture && (enc->width != next_picture->width ||
+ enc->height != next_picture->height)) {
+flush_encoders();
+enc->internal->draining = 0;
+}
+
 if (ost->source_index >= 0)
 ist = input_streams[ost->source_index];
 
diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index feb52ea..54ac365 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -1067,6 +1067,15 @@ static int vpx_encode(AVCodecContext *avctx, AVPacket 
*pkt,
 int res, coded_size;
 vpx_enc_frame_flags_t flags = 0;
 
+if (frame && (avctx->width != frame->width ||
+  avctx->height != frame->height)) {
+avctx->width  = frame->width;
+avctx->height = frame->height;
+
+avctx->codec->close(avctx);
+avctx->codec->init(avctx);
+}
+
 if (frame) {
 rawimg  = &ctx->rawimg;
 rawimg->planes[VPX_PLANE_Y] = frame->data[0];
-- 
2.7.4

___
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, RFC 2/2] fftools/ffmpeg: add dynamic resolution encode support for libvpx-vp9

[Nicolas George]

Linjie Fu (12019-07-28):
> +enc->internal->draining = 0;

"internal" means you should not be doing that.

Regards,

-- 
  Nicolas George


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, v3] fftools/ffmpeg_filter: add -autoscale to disable/enable the default scale

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Paul B Mahol
> Sent: Wednesday, July 24, 2019 21:17
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add -
> autoscale to disable/enable the default scale
> 
> On 7/24/19, Fu, Linjie  wrote:
> >> -Original Message-
> >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> >> Of Paul B Mahol
> >> Sent: Wednesday, July 24, 2019 17:42
> >> To: FFmpeg development discussions and patches  >> de...@ffmpeg.org>
> >> Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add -
> >> autoscale to disable/enable the default scale
> >>
> >> On 7/24/19, Fu, Linjie  wrote:
> >> >> -Original Message-
> >> >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> >> Behalf
> >> >> Of Gyan
> >> >> Sent: Wednesday, July 24, 2019 12:28
> >> >> To: ffmpeg-devel@ffmpeg.org
> >> >> Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add -
> >> >> autoscale to disable/enable the default scale
> >> >>
> >> >>
> >> >>
> >> >> On 24-07-2019 08:15 AM, Fu, Linjie wrote:
> >> >> >> -Original Message-
> >> >> >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org]
> On
> >> >> Behalf
> >> >> >> Of Gyan
> >> >> >> Sent: Wednesday, July 24, 2019 00:49
> >> >> >> To: ffmpeg-devel@ffmpeg.org
> >> >> >> Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add
> >> >> >> -
> >> >> >> autoscale to disable/enable the default scale
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> On 22-07-2019 01:40 PM, Fu, Linjie wrote:
> >> >>  -Original Message-
> >> >>  From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org]
> >> On
> >> >> >> Behalf
> >> >>  Of Gyan
> >> >>  Sent: Saturday, July 20, 2019 13:29
> >> >>  To: ffmpeg-devel@ffmpeg.org
> >> >>  Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter:
> >> >>  add
> >> -
> >> >>  autoscale to disable/enable the default scale
> >> >> > diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
> >> >> > index cd35eb49c8..99121b6981 100644
> >> >> > --- a/doc/ffmpeg.texi
> >> >> > +++ b/doc/ffmpeg.texi
> >> >> > +@item -autoscale
> >> >> > +Automatically scale the video according to the resolution of
> >> >> > first
> >> >> frame.
> >> >> > +Enabled by default, use @option{-noautoscale} to disable it.
> >> When
> >> >>  autoscale is
> >> >> > +disabled, all output frames might not be in the same
> resolution
> >> >> > and
> >> >> >> may
> >> >>  require
> >> >> > +some additional explicit processing according to your final
> >> >>  rendering/output
> >> >> > +destination. Disabling autoscale may not work in all
> >> >> > situations.
> >> >> >> Therefore,
> >> >>  it
> >> >> > +is not recommended to disable it unless you really know what
> >> you
> >> >> are
> >> >>  doing.
> >> >> > +Disable autoscale at your own risk.
> >> >>  Since the auto scaling happens at the end of the graph, what may
> >> the
> >> >>  "additional explicit processing" be?
> >> >> >>> Vpp processing may not be influenced,  a warning in transcode is
> >> >> >>> needed.
> >> >> >>> The expression seems to be improper, how about:
> >> >> >>>
> >> >> >>> "When autoscale is disabled, all output frames of filter graph
> >> >> >>> might
> >> >> >>> not
> >> >> be
> >> >> >> in the same
> >> >> >>> resolution and may be inadequate for encoder/muxer."
> >> >> >>>
> >> >> >>> or other suggestions?
> >> >> >>>
> >> >> > @@ -3640,6 +3642,12 @@ const OptionDef options[] = {
> >> >> > { "autorotate",   HAS_ARG | OPT_BOOL | OPT_SPEC |
> >> >> >   OPT_EXPERT | OPT_INPUT,
> >> >> > { .off =
> >> >>  OFFSET(autorotate) },
> >> >> > "automatically insert correct rotate filters" },
> >> >> > +{ "autoscale",HAS_ARG | OPT_BOOL | OPT_SPEC |
> >> >> > +  OPT_EXPERT | OPT_INPUT,
> >> >> >  { .off =
> >> >>  OFFSET(autoscale) },
> >> >> > +"automatically insert a scale filter at the end of the
> >> >> > filter graph if
> >> >> a
> >> >>  resolution"
> >> >> > +"change is detected. This ensures all frames are the
> >> >> > same
> >> >> >> resolution
> >> >>  as the first frame"
> >> >> > +"when they leave the filter chain (this option is
> >> >> > enabled
> >> >> > by
> >> >> >> default)."
> >> >> > +"If disabled, some encoders/muxers may not support this
> >> >> mode."},
> >> >>  Which muxers can detect or check for prop changes within coded
> >> >>  bitstreams? Which encoders are known to be able to handle
> >> >>  changing resolution?
> >> >> >>> It's not supported currently (even in libvpx-vp9, since vp9
> >> >> >>> su

Re: [FFmpeg-devel] [PATCH, RFC 2/2] fftools/ffmpeg: add dynamic resolution encode support for libvpx-vp9

[Fu, Linjie]

> -Original Message-
> From: Nicolas George [mailto:geo...@nsup.org]
> Sent: Sunday, July 28, 2019 17:58
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Cc: Fu, Linjie 
> Subject: Re: [FFmpeg-devel] [PATCH, RFC 2/2] fftools/ffmpeg: add dynamic
> resolution encode support for libvpx-vp9
> 
> Linjie Fu (12019-07-28):
> > +enc->internal->draining = 0;
> 
> "internal" means you should not be doing that.
> 
Sure,  will address this, thanks.
___
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, RFC 2/2] fftools/ffmpeg: add dynamic resolution encode support for libvpx-vp9

[Gyan]

On 28-07-2019 03:24 PM, Linjie Fu wrote:

According to spec, vp9 should support dynamic resolution changes.

Add dynamic resolution encoding support in libvpx-vp9, and flush
encoders when resolution change happens.

Format change should also be supported, but I didn't test it so just
leave it open.

cmdline:
ffmpeg -noautoscale -y -i ./reinit-large_420_8-to-small_420_8.h264
  -pix_fmt yuv420p -c:v libvpx-vp9 lena.ivf

Signed-off-by: Linjie Fu 
---
  fftools/ffmpeg.c   | 9 +
  libavcodec/libvpxenc.c | 9 +
  2 files changed, 18 insertions(+)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 5d52430..e091117 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -64,6 +64,7 @@
  #include "libavutil/thread.h"
  #include "libavutil/threadmessage.h"
  #include "libavcodec/mathops.h"
+#include "libavcodec/internal.h"
  #include "libavformat/os_support.h"
  
  # include "libavfilter/avfilter.h"

@@ -130,6 +131,7 @@ static void do_video_stats(OutputStream *ost, int 
frame_size);
  static BenchmarkTimeStamps get_benchmark_time_stamps(void);
  static int64_t getmaxrss(void);
  static int ifilter_has_all_input_formats(FilterGraph *fg);
+static void flush_encoders(void);
  
  static int run_as_daemon  = 0;

  static int nb_frames_dup = 0;
@@ -1067,6 +1069,13 @@ static void do_video_out(OutputFile *of,
  InputStream *ist = NULL;
  AVFilterContext *filter = ost->filter->filter;
  
+/* flush encoders in dynamic resolution encode */

+if (next_picture && (enc->width != next_picture->width ||
+ enc->height != next_picture->height)) {
+flush_encoders();
+enc->internal->draining = 0;
+}
+
  if (ost->source_index >= 0)
  ist = input_streams[ost->source_index];
  
diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c

index feb52ea..54ac365 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -1067,6 +1067,15 @@ static int vpx_encode(AVCodecContext *avctx, AVPacket 
*pkt,
  int res, coded_size;
  vpx_enc_frame_flags_t flags = 0;
  
+if (frame && (avctx->width != frame->width ||

+  avctx->height != frame->height)) {
+avctx->width  = frame->width;
+avctx->height = frame->height;
+
+avctx->codec->close(avctx);
+avctx->codec->init(avctx);
+}
+
  if (frame) {
  rawimg  = &ctx->rawimg;
  rawimg->planes[VPX_PLANE_Y] = frame->data[0];


The avcodec and fftools changes should be in separate patches.

Gyan
___
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/4] libavfilter/dnn: move dnn files from libavfilter to libavfilter/dnn

[Guo, Yejun]

> -Original Message-
> From: Pedro Arthur [mailto:bygran...@gmail.com]
> Sent: Saturday, July 27, 2019 12:10 AM
> To: FFmpeg development discussions and patches 
> Cc: Guo, Yejun 
> Subject: Re: [FFmpeg-devel] [PATCH 1/4] libavfilter/dnn: move dnn files from
> libavfilter to libavfilter/dnn
> 
> Em sex, 26 de jul de 2019 às 13:02, Pedro Arthur 
> escreveu:
> >
> > Hi,
> > It fails fate source guard header tests,
> > The headers should be changed from AVFILTER_DNN_BACKEND_xxx to
> > AVFILTER_DNN_DNN_BACKEND_xxx.
> Changed locally and pushed.

thanks!
___
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/2] avcodec/lcldec: Optimize YUV422 case

[Michael Niedermayer]

On Sun, Jul 28, 2019 at 12:45:36AM +0200, Reimar Döffinger wrote:
> 
> 
> On 28.07.2019, at 00:31, Michael Niedermayer  wrote:
> 
> > This merges several byte operations and avoids some shifts inside the loop
> > 
> > Improves: Timeout (330sec -> 134sec)
> > Improves: 
> > 15599/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MSZH_fuzzer-5658127116009472
> > 
> > Found-by: continuous fuzzing process 
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer 
> > ---
> > libavcodec/lcldec.c | 10 +-
> > 1 file changed, 5 insertions(+), 5 deletions(-)
> > 
> > diff --git a/libavcodec/lcldec.c b/libavcodec/lcldec.c
> > index 104defa5f5..c3787b3cbe 100644
> > --- a/libavcodec/lcldec.c
> > +++ b/libavcodec/lcldec.c
> > @@ -391,13 +391,13 @@ static int decode_frame(AVCodecContext *avctx, void 
> > *data, int *got_frame, AVPac
> > break;
> > case IMGTYPE_YUV422:
> > for (row = 0; row < height; row++) {
> > -for (col = 0; col < width - 3; col += 4) {
> > +for (col = 0; col < (width - 2)>>1; col += 2) {
> > memcpy(y_out + col, encoded, 4);
> > encoded += 4;
> > -u_out[ col >> 1 ] = *encoded++ + 128;
> > -u_out[(col >> 1) + 1] = *encoded++ + 128;
> > -v_out[ col >> 1 ] = *encoded++ + 128;
> > -v_out[(col >> 1) + 1] = *encoded++ + 128;
> > +AV_WN16(u_out + col, AV_RN16(encoded) ^ 0x8080);
> > +encoded += 2;
> > +AV_WN16(v_out + col, AV_RN16(encoded) ^ 0x8080);
> > +encoded += 2;
> 
> Huh? Surely the pixel stride used for y_out still needs to be double of the 
> u/v one?
> I suspect doing only the AV_RN16/xor optimization might be best, the one 
> shift saved seems not worth the risk/complexity...

will fix and retest while ensuring this code is actually tested

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Whats the most studid thing your enemy could do ? Blow himself up
Whats the most studid thing you could do ? Give up your rights and
freedom because your enemy blew himself up.



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".

[FFmpeg-devel] [PATCH] avcodec/adpcm: check also extradata_size

[Paul B Mahol]

Hi,

patch attached.


0001-avcodec-adpcm-check-also-extradata_size.patch
Description: Binary data
___
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/2] dnn: add layer pad which is equivalent to tf.pad

[Guo, Yejun]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Pedro Arthur
> Sent: Friday, July 26, 2019 10:36 PM
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] [PATCH 1/2] dnn: add layer pad which is equivalent
> to tf.pad
> 
> Hi,
> 
> Em seg, 1 de jul de 2019 às 05:10, Guo, Yejun 
> escreveu:
> >

> > +// handle the first dimension
> > +before_paddings = params->paddings[0][0];
> > +after_paddings = params->paddings[0][1];
> > +for (int n = 0; n < before_paddings; n++) {
> > +float *dst = output + n * new_hwc_stride;
> > +if (params->mode == LPMP_CONSTANT) {
> > +for (int i = 0; i < new_hwc_stride; i++) {
> > +*dst = params->constant_values;
> I suppose it is missing a pointer increase in dst ptr?
> I found this same pattern in all loops below.

thanks, nice catch.

I just checked my unit test for LPMP_CONSTANT and found it happened to test the 
fourth dimension which does not need the pointer increasing.

will send out a new patch together with unit test improved.
___
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/2] avcodec/lcldec: Optimize YUV422 case

[Michael Niedermayer]

On Sun, Jul 28, 2019 at 12:45:36AM +0200, Reimar Döffinger wrote:
> 
> 
> On 28.07.2019, at 00:31, Michael Niedermayer  wrote:
> 
> > This merges several byte operations and avoids some shifts inside the loop
> > 
> > Improves: Timeout (330sec -> 134sec)
> > Improves: 
> > 15599/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MSZH_fuzzer-5658127116009472
> > 
> > Found-by: continuous fuzzing process 
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer 
> > ---
> > libavcodec/lcldec.c | 10 +-
> > 1 file changed, 5 insertions(+), 5 deletions(-)
> > 
> > diff --git a/libavcodec/lcldec.c b/libavcodec/lcldec.c
> > index 104defa5f5..c3787b3cbe 100644
> > --- a/libavcodec/lcldec.c
> > +++ b/libavcodec/lcldec.c
> > @@ -391,13 +391,13 @@ static int decode_frame(AVCodecContext *avctx, void 
> > *data, int *got_frame, AVPac
> > break;
> > case IMGTYPE_YUV422:
> > for (row = 0; row < height; row++) {
> > -for (col = 0; col < width - 3; col += 4) {
> > +for (col = 0; col < (width - 2)>>1; col += 2) {
> > memcpy(y_out + col, encoded, 4);
> > encoded += 4;
> > -u_out[ col >> 1 ] = *encoded++ + 128;
> > -u_out[(col >> 1) + 1] = *encoded++ + 128;
> > -v_out[ col >> 1 ] = *encoded++ + 128;
> > -v_out[(col >> 1) + 1] = *encoded++ + 128;
> > +AV_WN16(u_out + col, AV_RN16(encoded) ^ 0x8080);
> > +encoded += 2;
> > +AV_WN16(v_out + col, AV_RN16(encoded) ^ 0x8080);
> > +encoded += 2;
> 
> Huh? Surely the pixel stride used for y_out still needs to be double of the 
> u/v one?

> I suspect doing only the AV_RN16/xor optimization might be best, the one 
> shift saved seems not worth the risk/complexity...

if you want i can remove the shift change ?
with the fixed shift change its 155sec, if i remove the shift optimization its 
170sec

patch for the 155 case below:

commit 56998b7d57a2cd0ed7f53981c50e76fd419cd86f (HEAD)
Author: Michael Niedermayer 
Date:   Sat Jul 27 22:46:34 2019 +0200

avcodec/lcldec: Optimize YUV422 case

This merges several byte operations and avoids some shifts inside the loop

Improves: Timeout (330sec -> 155sec)
Improves: 
15599/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MSZH_fuzzer-5658127116009472

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 

diff --git a/libavcodec/lcldec.c b/libavcodec/lcldec.c
index 104defa5f5..9e018ff5a9 100644
--- a/libavcodec/lcldec.c
+++ b/libavcodec/lcldec.c
@@ -391,13 +391,13 @@ static int decode_frame(AVCodecContext *avctx, void 
*data, int *got_frame, AVPac
 break;
 case IMGTYPE_YUV422:
 for (row = 0; row < height; row++) {
-for (col = 0; col < width - 3; col += 4) {
-memcpy(y_out + col, encoded, 4);
+for (col = 0; col < (width - 2)>>1; col += 2) {
+memcpy(y_out + 2 * col, encoded, 4);
 encoded += 4;
-u_out[ col >> 1 ] = *encoded++ + 128;
-u_out[(col >> 1) + 1] = *encoded++ + 128;
-v_out[ col >> 1 ] = *encoded++ + 128;
-v_out[(col >> 1) + 1] = *encoded++ + 128;
+AV_WN16(u_out + col, AV_RN16(encoded) ^ 0x8080);
+encoded += 2;
+AV_WN16(v_out + col, AV_RN16(encoded) ^ 0x8080);
+encoded += 2;
 }
 y_out -= frame->linesize[0];
 u_out -= frame->linesize[1];
[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf


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 1/2] avcodec/lcldec: Optimize YUV422 case

[Reimar Döffinger]

On 28.07.2019, at 13:56, Michael Niedermayer  wrote:

> On Sun, Jul 28, 2019 at 12:45:36AM +0200, Reimar Döffinger wrote:
>> 
>> 
>> On 28.07.2019, at 00:31, Michael Niedermayer  wrote:
>> 
>>> This merges several byte operations and avoids some shifts inside the loop
>>> 
>>> Improves: Timeout (330sec -> 134sec)
>>> Improves: 
>>> 15599/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MSZH_fuzzer-5658127116009472
>>> 
>>> Found-by: continuous fuzzing process 
>>> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>>> Signed-off-by: Michael Niedermayer 
>>> ---
>>> libavcodec/lcldec.c | 10 +-
>>> 1 file changed, 5 insertions(+), 5 deletions(-)
>>> 
>>> diff --git a/libavcodec/lcldec.c b/libavcodec/lcldec.c
>>> index 104defa5f5..c3787b3cbe 100644
>>> --- a/libavcodec/lcldec.c
>>> +++ b/libavcodec/lcldec.c
>>> @@ -391,13 +391,13 @@ static int decode_frame(AVCodecContext *avctx, void 
>>> *data, int *got_frame, AVPac
>>>break;
>>>case IMGTYPE_YUV422:
>>>for (row = 0; row < height; row++) {
>>> -for (col = 0; col < width - 3; col += 4) {
>>> +for (col = 0; col < (width - 2)>>1; col += 2) {
>>>memcpy(y_out + col, encoded, 4);
>>>encoded += 4;
>>> -u_out[ col >> 1 ] = *encoded++ + 128;
>>> -u_out[(col >> 1) + 1] = *encoded++ + 128;
>>> -v_out[ col >> 1 ] = *encoded++ + 128;
>>> -v_out[(col >> 1) + 1] = *encoded++ + 128;
>>> +AV_WN16(u_out + col, AV_RN16(encoded) ^ 0x8080);
>>> +encoded += 2;
>>> +AV_WN16(v_out + col, AV_RN16(encoded) ^ 0x8080);
>>> +encoded += 2;
>> 
>> Huh? Surely the pixel stride used for y_out still needs to be double of the 
>> u/v one?
> 
>> I suspect doing only the AV_RN16/xor optimization might be best, the one 
>> shift saved seems not worth the risk/complexity...
> 
> if you want i can remove the shift change ?
> with the fixed shift change its 155sec, if i remove the shift optimization 
> its 170sec
> 
> patch for the 155 case below:

I can't decide, it's a little uglier but a little faster...
Unless someone else has an opinion, go with whatever you prefer.
___
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/2] avcodec/lcldec: Optimize YUV422 case

[James Almer]

On 7/28/2019 8:56 AM, Michael Niedermayer wrote:
> On Sun, Jul 28, 2019 at 12:45:36AM +0200, Reimar Döffinger wrote:
>>
>>
>> On 28.07.2019, at 00:31, Michael Niedermayer  wrote:
>>
>>> This merges several byte operations and avoids some shifts inside the loop
>>>
>>> Improves: Timeout (330sec -> 134sec)
>>> Improves: 
>>> 15599/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MSZH_fuzzer-5658127116009472
>>>
>>> Found-by: continuous fuzzing process 
>>> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>>> Signed-off-by: Michael Niedermayer 
>>> ---
>>> libavcodec/lcldec.c | 10 +-
>>> 1 file changed, 5 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/libavcodec/lcldec.c b/libavcodec/lcldec.c
>>> index 104defa5f5..c3787b3cbe 100644
>>> --- a/libavcodec/lcldec.c
>>> +++ b/libavcodec/lcldec.c
>>> @@ -391,13 +391,13 @@ static int decode_frame(AVCodecContext *avctx, void 
>>> *data, int *got_frame, AVPac
>>> break;
>>> case IMGTYPE_YUV422:
>>> for (row = 0; row < height; row++) {
>>> -for (col = 0; col < width - 3; col += 4) {
>>> +for (col = 0; col < (width - 2)>>1; col += 2) {
>>> memcpy(y_out + col, encoded, 4);
>>> encoded += 4;
>>> -u_out[ col >> 1 ] = *encoded++ + 128;
>>> -u_out[(col >> 1) + 1] = *encoded++ + 128;
>>> -v_out[ col >> 1 ] = *encoded++ + 128;
>>> -v_out[(col >> 1) + 1] = *encoded++ + 128;
>>> +AV_WN16(u_out + col, AV_RN16(encoded) ^ 0x8080);
>>> +encoded += 2;
>>> +AV_WN16(v_out + col, AV_RN16(encoded) ^ 0x8080);
>>> +encoded += 2;
>>
>> Huh? Surely the pixel stride used for y_out still needs to be double of the 
>> u/v one?
> 
>> I suspect doing only the AV_RN16/xor optimization might be best, the one 
>> shift saved seems not worth the risk/complexity...
> 
> if you want i can remove the shift change ?
> with the fixed shift change its 155sec, if i remove the shift optimization 
> its 170sec
> 
> patch for the 155 case below:
> 
> commit 56998b7d57a2cd0ed7f53981c50e76fd419cd86f (HEAD)
> Author: Michael Niedermayer 
> Date:   Sat Jul 27 22:46:34 2019 +0200
> 
> avcodec/lcldec: Optimize YUV422 case
> 
> This merges several byte operations and avoids some shifts inside the loop
> 
> Improves: Timeout (330sec -> 155sec)
> Improves: 
> 15599/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MSZH_fuzzer-5658127116009472
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> 
> diff --git a/libavcodec/lcldec.c b/libavcodec/lcldec.c
> index 104defa5f5..9e018ff5a9 100644
> --- a/libavcodec/lcldec.c
> +++ b/libavcodec/lcldec.c
> @@ -391,13 +391,13 @@ static int decode_frame(AVCodecContext *avctx, void 
> *data, int *got_frame, AVPac
>  break;
>  case IMGTYPE_YUV422:
>  for (row = 0; row < height; row++) {
> -for (col = 0; col < width - 3; col += 4) {
> -memcpy(y_out + col, encoded, 4);
> +for (col = 0; col < (width - 2)>>1; col += 2) {
> +memcpy(y_out + 2 * col, encoded, 4);
>  encoded += 4;
> -u_out[ col >> 1 ] = *encoded++ + 128;
> -u_out[(col >> 1) + 1] = *encoded++ + 128;
> -v_out[ col >> 1 ] = *encoded++ + 128;
> -v_out[(col >> 1) + 1] = *encoded++ + 128;
> +AV_WN16(u_out + col, AV_RN16(encoded) ^ 0x8080);
> +encoded += 2;
> +AV_WN16(v_out + col, AV_RN16(encoded) ^ 0x8080);
> +encoded += 2;
>  }
>  y_out -= frame->linesize[0];
>  u_out -= frame->linesize[1];
> [...]

As others pointed before, this kind of optimization is usually meant for
the SIMD implementations and not the C boilerplate/reference. So
prioritize readability above speed if possible when choosing which
version to apply.
___
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 v2] avcodec/mips: [loongson] refine process of setting block as 0 in h264dsp_mmi.

[Reimar Döffinger]

I have no MIPS experience, but for what little it is worth thus: it looks fine 
to me.

On 28.07.2019, at 06:42, Shiyou Yin  wrote:

> In function ff_h264_add_pixels4_8_mmi, there is no need to reset '%[ftmp0]'
> to 0, because it's value has never changed since the start of the asm block.
> This patch remove the redundant 'xor' and set src to zero once it was loaded.
> 
> In function ff_h264_idct_add_8_mmi, 'block' is seted to zero twice.
> This patch removed the first setting zero operation and move the second one
> after the load operation of block.
> 
> In function ff_h264_idct8_add_8_mmi, 'block' is seted to zero twice too.
> This patch just removed the second setting zero operation.
> 
> This patch mainly simplifies the implementation of functions above,
> the effect on the performance of whole h264 decoding process is not obvious.
> According to the perf data, proportion of ff_h264_idct_add_8_mmi decreased 
> from
> 0.29% to 0.26% and ff_h264_idct8_add_8_mmi decreased from 0.62% to 0.59% when 
> decoding
> H264 format on loongson 3A3000(For reference only , not very stable.).
> ---
> libavcodec/mips/h264dsp_mmi.c | 44 +--
> 1 file changed, 13 insertions(+), 31 deletions(-)
> 
> diff --git a/libavcodec/mips/h264dsp_mmi.c b/libavcodec/mips/h264dsp_mmi.c
> index ac65a20..0459711 100644
> --- a/libavcodec/mips/h264dsp_mmi.c
> +++ b/libavcodec/mips/h264dsp_mmi.c
> @@ -38,6 +38,9 @@ void ff_h264_add_pixels4_8_mmi(uint8_t *dst, int16_t *src, 
> int stride)
> MMI_LDC1(%[ftmp2], %[src], 0x08)
> MMI_LDC1(%[ftmp3], %[src], 0x10)
> MMI_LDC1(%[ftmp4], %[src], 0x18)
> +/* memset(src, 0, 32); */
> +"gssqc1 %[ftmp0],   %[ftmp0],   0x00(%[src])\n\t"
> +"gssqc1 %[ftmp0],   %[ftmp0],   0x10(%[src])\n\t"
> MMI_ULWC1(%[ftmp5], %[dst0], 0x00)
> MMI_ULWC1(%[ftmp6], %[dst1], 0x00)
> MMI_ULWC1(%[ftmp7], %[dst2], 0x00)
> @@ -58,11 +61,6 @@ void ff_h264_add_pixels4_8_mmi(uint8_t *dst, int16_t *src, 
> int stride)
> MMI_SWC1(%[ftmp2], %[dst1], 0x00)
> MMI_SWC1(%[ftmp3], %[dst2], 0x00)
> MMI_SWC1(%[ftmp4], %[dst3], 0x00)
> -
> -/* memset(src, 0, 32); */
> -"xor%[ftmp0],   %[ftmp0],   %[ftmp0]\n\t"
> -"gssqc1 %[ftmp0],   %[ftmp0],   0x00(%[src])\n\t"
> -"gssqc1 %[ftmp0],   %[ftmp0],   0x10(%[src])\n\t"
> : [ftmp0]"=&f"(ftmp[0]),[ftmp1]"=&f"(ftmp[1]),
>   [ftmp2]"=&f"(ftmp[2]),[ftmp3]"=&f"(ftmp[3]),
>   [ftmp4]"=&f"(ftmp[4]),[ftmp5]"=&f"(ftmp[5]),
> @@ -85,15 +83,19 @@ void ff_h264_idct_add_8_mmi(uint8_t *dst, int16_t *block, 
> int stride)
> DECLARE_VAR_ADDRT;
> 
> __asm__ volatile (
> -"dli%[tmp0],0x01\n\t"
> MMI_LDC1(%[ftmp0], %[block], 0x00)
> -"mtc1   %[tmp0],%[ftmp8]\n\t"
> MMI_LDC1(%[ftmp1], %[block], 0x08)
> -"dli%[tmp0],0x06\n\t"
> MMI_LDC1(%[ftmp2], %[block], 0x10)
> +MMI_LDC1(%[ftmp3], %[block], 0x18)
> +/* memset(block, 0, 32) */
> +"xor%[ftmp4],   %[ftmp4],   %[ftmp4]\n\t"
> +"gssqc1 %[ftmp4],   %[ftmp4],   0x00(%[block])  \n\t"
> +"gssqc1 %[ftmp4],   %[ftmp4],   0x10(%[block])  \n\t"
> +"dli%[tmp0],0x01\n\t"
> +"mtc1   %[tmp0],%[ftmp8]\n\t"
> +"dli%[tmp0],0x06\n\t"
> "mtc1   %[tmp0],%[ftmp9]\n\t"
> "psrah  %[ftmp4],   %[ftmp1],   %[ftmp8]\n\t"
> -MMI_LDC1(%[ftmp3], %[block], 0x18)
> "psrah  %[ftmp5],   %[ftmp3],   %[ftmp8]\n\t"
> "psubh  %[ftmp4],   %[ftmp4],   %[ftmp3]\n\t"
> "paddh  %[ftmp5],   %[ftmp5],   %[ftmp1]\n\t"
> @@ -121,15 +123,11 @@ void ff_h264_idct_add_8_mmi(uint8_t *dst, int16_t 
> *block, int stride)
> "paddh  %[ftmp10],  %[ftmp3],   %[ftmp1]\n\t"
> "psubh  %[ftmp1],   %[ftmp1],   %[ftmp3]\n\t"
> "paddh  %[ftmp11],  %[ftmp4],   %[ftmp5]\n\t"
> -"xor%[ftmp7],   %[ftmp7],   %[ftmp7]\n\t"
> "psubh  %[ftmp5],   %[ftmp5],   %[ftmp4]\n\t"
> -MMI_SDC1(%[ftmp7], %[block], 0x00)
> -MMI_SDC1(%[ftmp7], %[block], 0x08)
> -MMI_SDC1(%[ftmp7], %[block], 0x10)
> -MMI_SDC1(%[ftmp7], %[block], 0x18)
> MMI_ULWC1(%[ftmp2], %[dst], 0x00)
> -"psrah  %[ftmp3

Re: [FFmpeg-devel] [PATCH v7 2/2] lavc/tiff: Decode embedded JPEGs in DNG images

[Reimar Döffinger]

On 28.07.2019, at 10:40, Nick Renieris  wrote:

> Actually, I checked a more accurate version of my loop, and GCC
> optimizes away the LUT check anyway:
> https://godbolt.org/z/G1e1R4
> As you can see it's smart enough to create 2 versions of my functions
> (started at L3 with a lookup and L7 without it) and it does the check
> outside.
> 
> There's no guarantee this is happening with the actual version of
> course (it could be slower, or even faster if it also optimizes it
> through dng_blit).
> I could check the actual disasm in FFmpeg, but I don't think it's
> worth it at this point (my mentor agrees).

Sorry, I did not know you already had discussions with an FFmpeg developer 
about the design.
I tend to review in a way that I just comment on anything I feel is not optimal.
I understand that much of it might not be reasonable to do differently in the 
end,
but feel that it is often enough to make it worth discussing things.
But I realize it can come across the wrong way, so sorry if I gave you a bad 
review experience,
and thanks for considering my comments.

Best regards,
Reimar
___
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 v7 2/2] lavc/tiff: Decode embedded JPEGs in DNG images

[Reimar Döffinger]

On 28.07.2019, at 08:55, Paul B Mahol  wrote:

>> 
>> Just provide as metadata and leave to e.g. libavfilter.
>> 
> 
> That does not follow DNG specification.
> I really do not have time to comment on other irrelevant stuff you pointed
> in your review.

If you had just told me that I should back off in a polite manner instead of 
this dismissive-insulting
way it would have taken me much less effort to acknowledge your point.
And over time you could save a lot of time thanks to not having to complain
about people being biased against you.
___
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] libavformat/mpegtsenc: fix incorrect PCR with multiple programs [v2]

[Michael Niedermayer]

On Sat, Jul 27, 2019 at 08:41:02PM +, Andreas Håkon wrote:
> Hi,
> 
> This newversion fixes all the problems commented in
> https://patchwork.ffmpeg.org/patch/14036/
> 
> Now, it works with/without video streams.
> 
> Regards.
> A.H.
> 
> ---

> From c9b295c49828f31bba3879de887c7b2ed0e2641c Mon Sep 17 00:00:00 2001
> From: Andreas Hakon 
> Date: Sat, 27 Jul 2019 21:28:32 +0100
> Subject: [PATCH] libavformat/mpegtsenc: fix incorrect PCR with multiple
>  programs [v2]
> 
> The MPEG-TS muxer has a serious bug related to the PCR pid selection.
> This bug appears when more than one program is used. The root cause is because
> the current code targets only one program when selecting the stream for the 
> PCR.
> 
> This patch solves this problem and select correct streams for each program.
> 
> You can check it with this command:
> 
> $ ./ffmpeg -loglevel verbose -y -f data -i /dev/zero \
>  -filter_complex "nullsrc=s=60x60,split=2[v0][v1],anullsrc[a]" \
>  -map [v0] -c:v:0 rawvideo \
>  -map [v1] -c:v:1 rawvideo \
>  -map [a]  -c:a:0 pcm_s8 \
>  -program st=0 -program st=1 -program st=2 -f mpegts out.ts
> 
> And you will see something like:
> 
> [mpegts @ 0x562f388cd800] service 1 using PCR in pid=256
> [mpegts @ 0x562f388cd800] service 2 using PCR in pid=257
> [mpegts @ 0x562f388cd800] service 3 using PCR in pid=258
> 
> 
> Signed-off-by: Andreas Hakon 
> ---
>  libavformat/mpegtsenc.c |  111 
> ++-
>  1 file changed, 61 insertions(+), 50 deletions(-)

This causes the stream from ticket/3714 to become noticably bigger

./ffmpeg -i 3714/FFmpeg\ Sample_cut.ts -vcodec copy -acodec copy -pat_period 1 
-sdt_period 1 this_was_less_than_256.ts

-rw-r- 1 michael michael 2700056 Jul 28 16:12 this_was_less_than_256.ts

before:
-rw-r- 1 michael michael 2559808 Jul 28 16:13 this_was_less_than_256.ts

-rw-r- 1 michael michael 256 Jun 11  2014 3714/FFmpeg Sample_cut.ts

sample should be here: 
https://trac.ffmpeg.org/raw-attachment/ticket/3714/FFmpeg%20Sample_cut.ts

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle


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 v7 2/2] lavc/tiff: Decode embedded JPEGs in DNG images

[Paul B Mahol]

On Sun, Jul 28, 2019 at 4:39 PM Reimar Döffinger 
wrote:

> On 28.07.2019, at 08:55, Paul B Mahol  wrote:
>
> >>
> >> Just provide as metadata and leave to e.g. libavfilter.
> >>
> >
> > That does not follow DNG specification.
> > I really do not have time to comment on other irrelevant stuff you
> pointed
> > in your review.
>
> If you had just told me that I should back off in a polite manner instead
> of this dismissive-insulting
> way it would have taken me much less effort to acknowledge your point.
> And over time you could save a lot of time thanks to not having to complain
> about people being biased against you.


Sorry if you feel attacked, but I simply do not like it.
Instead of complaining you could send patch one or two.
___
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 v7 2/2] lavc/tiff: Decode embedded JPEGs in DNG images

[Reimar Döffinger]

On 28.07.2019, at 16:45, Paul B Mahol  wrote:

> On Sun, Jul 28, 2019 at 4:39 PM Reimar Döffinger 
> wrote:
> 
>> On 28.07.2019, at 08:55, Paul B Mahol  wrote:
>> 
 
 Just provide as metadata and leave to e.g. libavfilter.
 
>>> 
>>> That does not follow DNG specification.
>>> I really do not have time to comment on other irrelevant stuff you
>> pointed
>>> in your review.
>> 
>> If you had just told me that I should back off in a polite manner instead
>> of this dismissive-insulting
>> way it would have taken me much less effort to acknowledge your point.
>> And over time you could save a lot of time thanks to not having to complain
>> about people being biased against you.
> 
> 
> Sorry if you feel attacked, but I simply do not like it.

That is fine to tell me. I'll at least make an effort. Just the wording 
discourages from doing so.

> Instead of complaining you could send patch one or two.

(Assuming you mean the review by "complaining")
Sorry, it was just meant to be a review, not complaining, but I know I tend to 
write in a way that is too much like complaining.
There are quite a few patches that go unreviewed because (I assume) there are 
not enough reviewers as usual, so I've rather been reviewing than developing.
Plus I have no personal itch to scratch to send a patch for currently.
But if more people think there are more useful ways to contribute I'll 
certainly listen.
___
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/2] avcodec/lcldec: Optimize YUV422 case

[Michael Niedermayer]

On Sun, Jul 28, 2019 at 11:06:16AM -0300, James Almer wrote:
> On 7/28/2019 8:56 AM, Michael Niedermayer wrote:
> > On Sun, Jul 28, 2019 at 12:45:36AM +0200, Reimar Döffinger wrote:
> >>
> >>
> >> On 28.07.2019, at 00:31, Michael Niedermayer  
> >> wrote:
> >>
> >>> This merges several byte operations and avoids some shifts inside the loop
> >>>
> >>> Improves: Timeout (330sec -> 134sec)
> >>> Improves: 
> >>> 15599/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MSZH_fuzzer-5658127116009472
> >>>
> >>> Found-by: continuous fuzzing process 
> >>> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> >>> Signed-off-by: Michael Niedermayer 
> >>> ---
> >>> libavcodec/lcldec.c | 10 +-
> >>> 1 file changed, 5 insertions(+), 5 deletions(-)
> >>>
> >>> diff --git a/libavcodec/lcldec.c b/libavcodec/lcldec.c
> >>> index 104defa5f5..c3787b3cbe 100644
> >>> --- a/libavcodec/lcldec.c
> >>> +++ b/libavcodec/lcldec.c
> >>> @@ -391,13 +391,13 @@ static int decode_frame(AVCodecContext *avctx, void 
> >>> *data, int *got_frame, AVPac
> >>> break;
> >>> case IMGTYPE_YUV422:
> >>> for (row = 0; row < height; row++) {
> >>> -for (col = 0; col < width - 3; col += 4) {
> >>> +for (col = 0; col < (width - 2)>>1; col += 2) {
> >>> memcpy(y_out + col, encoded, 4);
> >>> encoded += 4;
> >>> -u_out[ col >> 1 ] = *encoded++ + 128;
> >>> -u_out[(col >> 1) + 1] = *encoded++ + 128;
> >>> -v_out[ col >> 1 ] = *encoded++ + 128;
> >>> -v_out[(col >> 1) + 1] = *encoded++ + 128;
> >>> +AV_WN16(u_out + col, AV_RN16(encoded) ^ 0x8080);
> >>> +encoded += 2;
> >>> +AV_WN16(v_out + col, AV_RN16(encoded) ^ 0x8080);
> >>> +encoded += 2;
> >>
> >> Huh? Surely the pixel stride used for y_out still needs to be double of 
> >> the u/v one?
> > 
> >> I suspect doing only the AV_RN16/xor optimization might be best, the one 
> >> shift saved seems not worth the risk/complexity...
> > 
> > if you want i can remove the shift change ?
> > with the fixed shift change its 155sec, if i remove the shift optimization 
> > its 170sec
> > 
> > patch for the 155 case below:
> > 
> > commit 56998b7d57a2cd0ed7f53981c50e76fd419cd86f (HEAD)
> > Author: Michael Niedermayer 
> > Date:   Sat Jul 27 22:46:34 2019 +0200
> > 
> > avcodec/lcldec: Optimize YUV422 case
> > 
> > This merges several byte operations and avoids some shifts inside the 
> > loop
> > 
> > Improves: Timeout (330sec -> 155sec)
> > Improves: 
> > 15599/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MSZH_fuzzer-5658127116009472
> > 
> > Found-by: continuous fuzzing process 
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer 
> > 
> > diff --git a/libavcodec/lcldec.c b/libavcodec/lcldec.c
> > index 104defa5f5..9e018ff5a9 100644
> > --- a/libavcodec/lcldec.c
> > +++ b/libavcodec/lcldec.c
> > @@ -391,13 +391,13 @@ static int decode_frame(AVCodecContext *avctx, void 
> > *data, int *got_frame, AVPac
> >  break;
> >  case IMGTYPE_YUV422:
> >  for (row = 0; row < height; row++) {
> > -for (col = 0; col < width - 3; col += 4) {
> > -memcpy(y_out + col, encoded, 4);
> > +for (col = 0; col < (width - 2)>>1; col += 2) {
> > +memcpy(y_out + 2 * col, encoded, 4);
> >  encoded += 4;
> > -u_out[ col >> 1 ] = *encoded++ + 128;
> > -u_out[(col >> 1) + 1] = *encoded++ + 128;
> > -v_out[ col >> 1 ] = *encoded++ + 128;
> > -v_out[(col >> 1) + 1] = *encoded++ + 128;
> > +AV_WN16(u_out + col, AV_RN16(encoded) ^ 0x8080);
> > +encoded += 2;
> > +AV_WN16(v_out + col, AV_RN16(encoded) ^ 0x8080);
> > +encoded += 2;
> >  }
> >  y_out -= frame->linesize[0];
> >  u_out -= frame->linesize[1];
> > [...]
> 
> As others pointed before, this kind of optimization is usually meant for
> the SIMD implementations and not the C boilerplate/reference. So
> prioritize readability above speed if possible when choosing which
> version to apply.

I think its not a big difference, a shift of width vs. a shift of col
so ill go with what was faster in this testcase but iam happy to
do something else if people prefer

Thanks

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

Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf


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

Re: [FFmpeg-devel] [PATCH, v4 1/2] fftools/ffmpeg_filter: add -autoscale to disable/enable the default scale

[Michael Niedermayer]

On Sun, Jul 28, 2019 at 05:54:24PM +0800, Linjie Fu wrote:
> Currently, ffmpeg inserts scale filter by default in the filter graph
> to force the whole decoded stream to scale into the same size with the
> first frame. It's not quite make sense in resolution changing cases if
> user wants the rawvideo without any scale.
> 
> Using autoscale/noautoscale to indicate whether auto inserting the scale
> filter in the filter graph:
> -noautoscale or -autoscale 0:
> disable the default auto scale filter inserting.
> 
> Update docs.
> 
> Signed-off-by: U. Artie Eoff 
> Signed-off-by: Linjie Fu 
> ---
>  doc/ffmpeg.texi | 16 
>  fftools/ffmpeg.c|  1 +
>  fftools/ffmpeg.h|  4 
>  fftools/ffmpeg_filter.c |  2 +-
>  fftools/ffmpeg_opt.c|  8 
>  5 files changed, 26 insertions(+), 5 deletions(-)

I think this is ok-ish but it would be more robust if encoders would
have a CODEC_CAP listing if they actually support changing resolution

Thanks

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

Old school: Use the lowest level language in which you can solve the problem
conveniently.
New school: Use the highest level language in which the latest supercomputer
can solve the problem without the user falling asleep waiting.


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] avcodec: add a WavPack DSD decoder

[Paul B Mahol]

On Sun, Jul 28, 2019 at 6:02 AM David Bryant  wrote:

> On 7/24/19 12:26 AM, Paul B Mahol wrote:
> > On 7/23/19, David Bryant  wrote:
> >> On 7/23/19 12:47 AM, Paul B Mahol wrote:
> >>> On 7/23/19, David Bryant  wrote:
>  On 7/21/19 11:23 PM, Paul B Mahol wrote:
> > On 7/22/19, David Bryant  wrote:
> >> Hi,
> >>
> >> As I promised late last year, here is a patch to add a WavPack DSD
> >> decoder.
> >>
> >> Thanks!
> >>
> >> -David Bryant
> >>
> >>
> > Please correct me if I'm wrong, but why this uses new codec id?
> > Apparently is also copies some logic from other files.
>  Yes, I created a new codec ID for WavPack DSD. It would be possible to
>  just
>  piggyback on the existing WavPack codec by silently
>  decimating the DSD to PCM, but that seemed weird and wrong to me. For
> one
>  thing, the user would have no idea that the file was
>  actually DSD and not high sample-rate PCM.
> 
>  Also, since regular WavPack has threading enabled but WavPack DSD
> can't
>  (because of the dsd2pcm conversion) I would have to turn
>  off threading for all WavPack (unless there's some way of making that
>  conditional at runtime). It would also mean that regular
>  WavPack would be dependent on the dsd2pcm component even if DSD was
> not
>  required (not everyone needs DSD). And of course I was
>  looking closely at the only other DSD codec in FFmpeg (DST) which has
> its
>  own codec ID.
> 
>  Because regular WavPack PCM and DSD share the same block format and
>  metadata
>  structure, there is a little code that is shared
>  between the two codecs (although they are no longer identical because
> of
>  the
>  threading difference). Is this a problem? I could
>  combine the two codecs into one file and sprinkle in a few
> conditionals,
>  but
>  I don't think it would be as clean or clear (but
>  might save a little duplicate code).
> 
>  That's my thinking, but obviously I am not as familiar with the FFmpeg
>  philosophy as you guys.
> >>> Looking carefully at dsd2pcm code in your patch, it appears it would
> >>> work only with 1 or 2 channels.
> >>> Is this correct?
> >> Individual WavPack blocks can only be 1 or 2 channels. Multichannel
> files
> >> contains sequences of blocks which ends up creating
> >> multiple frame contexts. This was originally implemented for PCM WavPack
> >> years ago and so it "just works" for DSD WavPack
> >> because I didn't touch any of that.
> >>
> >> I have tested this extensively with multichannel DSD files and it works
> >> great, including seeking.
> > Than I fail to see why it could not work for multi-threading too.
>
> Really? Because I just looked back at the FFmpeg devel archives (May 2016)
> and you supplied the patch for the DST codec, the
> only other DSD compression codec in existence before my recent
> development. And dstdec.c does not enable multi-threading
> because, of course, you get clicks. This seems like an unlikely oversight
> since DST is a well-documented CPU hog and would
> benefit greatly from multi-threading.
>

Well, how you explain fact that you use same dsd context in wavpack for
different channels.
IMHO you should use separate context for each channel. Am I missing
something here?
___
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 23/31] cbs_mpeg2: Remove zero byte stuffing

[Mark Thompson]

On 20/06/2019 00:45, Andreas Rheinhardt wrote:
> Remove superfluous trailing zeros from slices. Because MPEG-2 slices
> can end with zero bits a safe number of trailing zero bits is always
> kept.
> 
> More explicitly, 6 + max{f_code[i][1] - 1, i = 0,1, f_code[i][1] != 0xf}
> is an upper bound for the number of possible trailing zeros that are
> part of the slice. Here f_code[i][1] is the relevant value of the
> picture coding extension the slice belongs to and the maximum of the
> empty set is zero.
> It is this number of trailing zero bits that is actually kept.
> 
> That this is really an upper bound can be seen as follows:
> 
> a) Every slice actually ends with a macroblock.
> 
> b) If the last macroblock of a slice ends with a block(i) structure
> with pattern_code[i] != 0, then the slice ends with an "End of block"
> VLC code (namely the "End of block" code of the last block with
> pattern_code[i] != 0).
> These codes are 10 and 0110, so that in this case there is exactly one
> trailing zero bit.
> 
> c) Otherwise, all pattern_code[i] are zero. In this case,
> if macroblock_pattern is set for the last macroblock of the slice, then
> by the definition of pattern_code[i] in 6.3.17.4 cbp (derived
> according to table B.9) must be zero and also the
> coded_block_pattern_1/2 (if existing) must consist of zeros alone. The
> value zero for cbp is coded by   1 so that the maximum number of
> trailing zeros in this case is the length of coded_block_pattern_1/2 which
> have a length of two resp. six bits. So six trailing zero bits at most.
> 
> d) Otherwise, if the slice actually ends with the marker bit of the
> last macroblock, then there are certainly no trailing zero bits at
> all.
> 
> e) Otherwise, if the slice ends with a motion_vectors(s) structure
> (with s = 0 or 1 -- it doesn't matter which one), then it ends with a
> motion_vector(r,s) (r, s = 0, 1 -- it doesn't matter) structure. This
> structure ends with motion_code[r][s][1] (always existing) potentially
> followed by motion_residual[r][s][1] and dmvector[1]. If dmvector[1]
> exists, and contains a bit different from 0, there is at most one
> trailing zero bit; if dmvector[1] consists of zeros alone, its length
> is one according to B.11. motion_residual[r][s][1] (if it exists) has
> a length of f_code[s][1] - 1 bits and can consist of zero bits alone.
> Given that the value 0xf for f_code indicates that there is no motion
> vector of the mentioned type, the length of motion_residual[r][s][1] is
> bounded by max{f_code[i][1] - 1, i=1,2, f_code[i][1] != 0xf}. The
> motion_code[r][s][1] can end with at most five zero bits (see B.10)
> and always contains a bit set to one, so that in this case there are
> at most 5 + max{f_code[i][1] - 1, i=1,2, f_code[i][1] != 0xf} + 1
> zero trailing bits.
> 
> f) Otherwise, if the last macroblock of the slice ends with a
> quantiser_scale_code, then there are at most four trailing zero bits,
> because quantiser_scale_code has a length of five bits and must not
> attain the value zero.
> 
> g) Otherwise, the last macroblock ends with the macroblock_modes
> syntax structure. The potentially existing dct_type at the end might
> be a zero bit; the frame/field_motion_type isn't present here, because
> otherwise we would have a motion_vectors(i) (i = 0 or 1 or both) syntax
> structure, so that e) (or b)-d)) would have applied.
> spatial_temporal_weight_code might entirely consist of two zero bits.
> The macroblock_type VLC code always contains a 1 bit and ends with two
> zero bits at most (see B.2-B.8 for this), so we have maximally 2+2+1
> trailing zero bits.
> 
> The fate test cbs-mpeg2-sony-ct3 had to be adapted because the input
> file contains trailing zeros that were stripped away; the filesize is
> reduced from 135 KB to 117 KB. Of course, decoding the smaller output
> still produces the same frames.
> Most of these savings happen in between slices rather than after the
> last slice: The chomp bitstream filter can only reduce the filesize
> by 50 bytes.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/cbs_mpeg2.c| 26 --
>  tests/ref/fate/cbs-mpeg2-sony-ct3 |  2 +-
>  2 files changed, 25 insertions(+), 3 deletions(-)
> 
> diff --git a/libavcodec/cbs_mpeg2.c b/libavcodec/cbs_mpeg2.c
> index 516b728a64..0630fe17d8 100644
> --- a/libavcodec/cbs_mpeg2.c
> +++ b/libavcodec/cbs_mpeg2.c
> @@ -170,7 +170,7 @@ static int cbs_mpeg2_split_fragment(CodedBitstreamContext 
> *ctx,
>  uint8_t *unit_data;
>  uint32_t start_code = -1, next_start_code = -1;
>  size_t unit_size;
> -int err, i, unit_type;
> +int err, i, unit_type, max_trailing_bits = 14;
>  
>  start = avpriv_find_start_code(frag->data, frag->data + frag->data_size,
> &start_code);
> @@ -187,10 +187,32 @@ static int 
> cbs_mpeg2_split_fragment(CodedBitstreamContext *ctx,
>  unit_size = end - (start - 1);
>  } else {
>  /

Re: [FFmpeg-devel] avcodec: add a WavPack DSD decoder

[Paul B Mahol]

On Sun, Jul 28, 2019 at 7:18 PM Paul B Mahol  wrote:

>
>
> On Sun, Jul 28, 2019 at 6:02 AM David Bryant  wrote:
>
>> On 7/24/19 12:26 AM, Paul B Mahol wrote:
>> > On 7/23/19, David Bryant  wrote:
>> >> On 7/23/19 12:47 AM, Paul B Mahol wrote:
>> >>> On 7/23/19, David Bryant  wrote:
>>  On 7/21/19 11:23 PM, Paul B Mahol wrote:
>> > On 7/22/19, David Bryant  wrote:
>> >> Hi,
>> >>
>> >> As I promised late last year, here is a patch to add a WavPack DSD
>> >> decoder.
>> >>
>> >> Thanks!
>> >>
>> >> -David Bryant
>> >>
>> >>
>> > Please correct me if I'm wrong, but why this uses new codec id?
>> > Apparently is also copies some logic from other files.
>>  Yes, I created a new codec ID for WavPack DSD. It would be possible
>> to
>>  just
>>  piggyback on the existing WavPack codec by silently
>>  decimating the DSD to PCM, but that seemed weird and wrong to me.
>> For one
>>  thing, the user would have no idea that the file was
>>  actually DSD and not high sample-rate PCM.
>> 
>>  Also, since regular WavPack has threading enabled but WavPack DSD
>> can't
>>  (because of the dsd2pcm conversion) I would have to turn
>>  off threading for all WavPack (unless there's some way of making that
>>  conditional at runtime). It would also mean that regular
>>  WavPack would be dependent on the dsd2pcm component even if DSD was
>> not
>>  required (not everyone needs DSD). And of course I was
>>  looking closely at the only other DSD codec in FFmpeg (DST) which
>> has its
>>  own codec ID.
>> 
>>  Because regular WavPack PCM and DSD share the same block format and
>>  metadata
>>  structure, there is a little code that is shared
>>  between the two codecs (although they are no longer identical
>> because of
>>  the
>>  threading difference). Is this a problem? I could
>>  combine the two codecs into one file and sprinkle in a few
>> conditionals,
>>  but
>>  I don't think it would be as clean or clear (but
>>  might save a little duplicate code).
>> 
>>  That's my thinking, but obviously I am not as familiar with the
>> FFmpeg
>>  philosophy as you guys.
>> >>> Looking carefully at dsd2pcm code in your patch, it appears it would
>> >>> work only with 1 or 2 channels.
>> >>> Is this correct?
>> >> Individual WavPack blocks can only be 1 or 2 channels. Multichannel
>> files
>> >> contains sequences of blocks which ends up creating
>> >> multiple frame contexts. This was originally implemented for PCM
>> WavPack
>> >> years ago and so it "just works" for DSD WavPack
>> >> because I didn't touch any of that.
>> >>
>> >> I have tested this extensively with multichannel DSD files and it works
>> >> great, including seeking.
>> > Than I fail to see why it could not work for multi-threading too.
>>
>> Really? Because I just looked back at the FFmpeg devel archives (May
>> 2016) and you supplied the patch for the DST codec, the
>> only other DSD compression codec in existence before my recent
>> development. And dstdec.c does not enable multi-threading
>> because, of course, you get clicks. This seems like an unlikely oversight
>> since DST is a well-documented CPU hog and would
>> benefit greatly from multi-threading.
>>
>
> Well, how you explain fact that you use same dsd context in wavpack for
> different channels.
> IMHO you should use separate context for each channel. Am I missing
> something here?
>

I just looked again at patch, and I see that it is used as I expected it
should be.
So that part is handled fine.
___
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] avcodec: add a WavPack DSD decoder

[Paul B Mahol]

On Sun, Jul 28, 2019 at 6:02 AM David Bryant  wrote:

> On 7/24/19 12:26 AM, Paul B Mahol wrote:
> > On 7/23/19, David Bryant  wrote:
> >> On 7/23/19 12:47 AM, Paul B Mahol wrote:
> >>> On 7/23/19, David Bryant  wrote:
>  On 7/21/19 11:23 PM, Paul B Mahol wrote:
> > On 7/22/19, David Bryant  wrote:
> >> Hi,
> >>
> >> As I promised late last year, here is a patch to add a WavPack DSD
> >> decoder.
> >>
> >> Thanks!
> >>
> >> -David Bryant
> >>
> >>
> > Please correct me if I'm wrong, but why this uses new codec id?
> > Apparently is also copies some logic from other files.
>  Yes, I created a new codec ID for WavPack DSD. It would be possible to
>  just
>  piggyback on the existing WavPack codec by silently
>  decimating the DSD to PCM, but that seemed weird and wrong to me. For
> one
>  thing, the user would have no idea that the file was
>  actually DSD and not high sample-rate PCM.
> 
>  Also, since regular WavPack has threading enabled but WavPack DSD
> can't
>  (because of the dsd2pcm conversion) I would have to turn
>  off threading for all WavPack (unless there's some way of making that
>  conditional at runtime). It would also mean that regular
>  WavPack would be dependent on the dsd2pcm component even if DSD was
> not
>  required (not everyone needs DSD). And of course I was
>  looking closely at the only other DSD codec in FFmpeg (DST) which has
> its
>  own codec ID.
> 
>  Because regular WavPack PCM and DSD share the same block format and
>  metadata
>  structure, there is a little code that is shared
>  between the two codecs (although they are no longer identical because
> of
>  the
>  threading difference). Is this a problem? I could
>  combine the two codecs into one file and sprinkle in a few
> conditionals,
>  but
>  I don't think it would be as clean or clear (but
>  might save a little duplicate code).
> 
>  That's my thinking, but obviously I am not as familiar with the FFmpeg
>  philosophy as you guys.
> >>> Looking carefully at dsd2pcm code in your patch, it appears it would
> >>> work only with 1 or 2 channels.
> >>> Is this correct?
> >> Individual WavPack blocks can only be 1 or 2 channels. Multichannel
> files
> >> contains sequences of blocks which ends up creating
> >> multiple frame contexts. This was originally implemented for PCM WavPack
> >> years ago and so it "just works" for DSD WavPack
> >> because I didn't touch any of that.
> >>
> >> I have tested this extensively with multichannel DSD files and it works
> >> great, including seeking.
> > Than I fail to see why it could not work for multi-threading too.
>
> Really? Because I just looked back at the FFmpeg devel archives (May 2016)
> and you supplied the patch for the DST codec, the
> only other DSD compression codec in existence before my recent
> development. And dstdec.c does not enable multi-threading
> because, of course, you get clicks. This seems like an unlikely oversight
> since DST is a well-documented CPU hog and would
> benefit greatly from multi-threading.
>

You are right, it can not use frame-multi-threading. But can use
slice-multi-threading as each channel is independent.
Thanks for pointing this for DST, I will implement this slice-threading
soon, unless someone beat me first.
___
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 24/31] av1/h264_metadata: Don't reinitialize data

[Mark Thompson]

On 20/06/2019 00:45, Andreas Rheinhardt wrote:
> If the relevant elements (the color description elements for AV1 and the
> VUI elements in general for H.264 (since 1156b507)) are absent, then their
> correct values (usually meaning unknown) have already been inferred by
> the reading process, so that it is unnecessary to initialize them again
> in the av1/h264_metadata filters even when they were initially absent.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/av1_metadata_bsf.c  |  7 +--
>  libavcodec/h264_metadata_bsf.c | 37 ++
>  2 files changed, 12 insertions(+), 32 deletions(-)
> 
> diff --git a/libavcodec/av1_metadata_bsf.c b/libavcodec/av1_metadata_bsf.c
> index 9345095277..7d9d15b1a0 100644
> --- a/libavcodec/av1_metadata_bsf.c
> +++ b/libavcodec/av1_metadata_bsf.c
> @@ -61,12 +61,7 @@ static int 
> av1_metadata_update_sequence_header(AVBSFContext *bsf,
>  if (ctx->color_primaries >= 0  ||
>  ctx->transfer_characteristics >= 0 ||
>  ctx->matrix_coefficients >= 0) {
> -if (!clc->color_description_present_flag) {
> -clc->color_description_present_flag = 1;
> -clc->color_primaries  = AVCOL_PRI_UNSPECIFIED;
> -clc->transfer_characteristics = AVCOL_TRC_UNSPECIFIED;
> -clc->matrix_coefficients  = AVCOL_SPC_UNSPECIFIED;
> -}
> +clc->color_description_present_flag = 1;
>  
>  if (ctx->color_primaries >= 0)
>  clc->color_primaries = ctx->color_primaries;
> diff --git a/libavcodec/h264_metadata_bsf.c b/libavcodec/h264_metadata_bsf.c
> index d760ee3182..40886bdde0 100644
> --- a/libavcodec/h264_metadata_bsf.c
> +++ b/libavcodec/h264_metadata_bsf.c
> @@ -122,13 +122,12 @@ static int h264_metadata_update_sps(AVBSFContext *bsf,
>  need_vui = 1;
>  }
>  
> -#define SET_OR_INFER(field, value, present_flag, infer) do { \
> -if (value >= 0) { \
> -field = value; \
> +#define SET_IF_SET(field) do { \

The name SET_IF_SET felt unnecessarily confusing, so I changed it to 
SET_VUI_FIELD.

Applied along with 20-22.

Thanks,

- Mark
___
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 25/31] cbs: Add function to update video codec parameters

[Mark Thompson]

On 20/06/2019 00:45, Andreas Rheinhardt wrote:
> If any of the *_metadata filter based upon cbs currently updates a video
> codec parameter like color information, the AVCodecParameters are not
> updated accordingly, so that e.g. muxers write header values based upon
> outdated information that may precede and thereby nullify the new values
> on the bitstream level.
> This commit adds a function to also update the video codec parameters
> so that the above situation can be fixed in a unified manner.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/cbs.c | 35 +++
>  libavcodec/cbs.h | 15 +++
>  2 files changed, 50 insertions(+)
> 
> diff --git a/libavcodec/cbs.c b/libavcodec/cbs.c
> index 47679eca1b..37b080b5ba 100644
> --- a/libavcodec/cbs.c
> +++ b/libavcodec/cbs.c
> @@ -342,6 +342,41 @@ int ff_cbs_write_extradata(CodedBitstreamContext *ctx,
>  return 0;
>  }
>  
> +void ff_cbs_update_video_parameters(CodedBitstreamContext *ctx,

The context argument isn't used at all.

> +AVCodecParameters *par, int profile,
> +int level, int width, int height,
> +int field_order, int color_range,
> +int color_primaries, int color_trc,
> +int color_space, int chroma_location,
> +int video_delay)
> +{
> +#define SET_IF_NONNEGATIVE(elem) \
> +if (elem >= 0) \
> +par->elem = elem;
> +SET_IF_NONNEGATIVE(profile)
> +SET_IF_NONNEGATIVE(level)
> +SET_IF_NONNEGATIVE(width)
> +SET_IF_NONNEGATIVE(height)
> +SET_IF_NONNEGATIVE(field_order)
> +SET_IF_NONNEGATIVE(video_delay)
> +#undef SET_IF_NONNEGATIVE
> +
> +#define SET_IF_VALID(elem, upper_bound) \
> +if (0 <= elem && elem < upper_bound) \
> +par->elem = elem;
> +SET_IF_VALID(color_range, AVCOL_RANGE_NB)
> +SET_IF_VALID(color_trc,   AVCOL_TRC_NB)
> +SET_IF_VALID(color_space, AVCOL_SPC_NB)

I think we generally want to admit future values for the 23001-8 / H.273 fields 
(see range ..255 on all the metadata filters).

> +SET_IF_VALID(chroma_location, AVCHROMA_LOC_NB)
> +#undef SET_IF_VALID
> +
> +if (0 <= color_primaries && color_primaries <= AVCOL_PRI_SMPTE432
> + || color_primaries == AVCOL_PRI_JEDEC_P22)
> +par->color_primaries = color_primaries;
> +
> +return;
> +}
> +
>  int ff_cbs_write_packet(CodedBitstreamContext *ctx,
>  AVPacket *pkt,
>  CodedBitstreamFragment *frag)
> diff --git a/libavcodec/cbs.h b/libavcodec/cbs.h
> index e1e6055ceb..1655f790cd 100644
> --- a/libavcodec/cbs.h
> +++ b/libavcodec/cbs.h
> @@ -304,6 +304,21 @@ int ff_cbs_write_extradata(CodedBitstreamContext *ctx,
> AVCodecParameters *par,
> CodedBitstreamFragment *frag);
>  
> +/**
> + * Update the parameters of an AVCodecParameters structure
> + *
> + * If a parameter is negative, the corresponding member is not
> + * modified. For the color/chroma parameters, only values that
> + * are part of the relevant enumeration are written.
> + */
> +void ff_cbs_update_video_parameters(CodedBitstreamContext *ctx,
> +AVCodecParameters *par, int profile,
> +int level, int width, int height,
> +int field_order, int color_range,
> +int color_primaries, int color_trc,
> +int color_space, int chroma_location,
> +int video_delay);

I find the calls with -1, -1, -1 pretty horrible, and all the extra pointer 
arguments being passed around in the metadata filters are not very nice either.

To avoid both of those, how about something like this:

typedef struct foo {
int profile;
int level;
int width;
...
} foo;

init_foo(foo *p)
{
set all fields to minus one (or some other placeholder value)
}

update_codecpar_with_foo(AVCodecPar *par, const foo *p)
{
as above
}

Then in each BSF:

struct BarMetadataContext {
...
foo parameters;
} BarMetadataContext;

update_stuff()
{
...
ctx->parameters.whatever = not-minus-one
}

init()
{
init_foo(&ctx->parameters);
update_stuff()
update_codecpar_with_foo(bsf->par_out, &ctx->foo);
}

What do you think?

Thanks,

- Mark
___
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 28/31] vp9_metadata: Improve spec-compliance and warnings

[Mark Thompson]

On 09/07/2019 02:10, Andreas Rheinhardt wrote:
> The earlier version had three deficits:
> 1. It allowed to set the stream to RGB although this is not allowed when
> the profile is 0 or 2.
> 2. If it set the stream to RGB, then it did not automatically set the
> range to full range; the result was that one got a warning every time a
> frame with color_config element was processed if the frame originally
> had TV range and the user didn't explicitly choose PC range. Now one
> gets only one warning in such a situation.
> 3. Intra-only frames in profile 0 are automatically BT.601, but if the
> user wished another color space, he was not informed about his wishes
> being unfulfillable.
> 
> The commit also improves the documentation about this.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  doc/bitstream_filters.texi|  8 ---
>  libavcodec/vp9_metadata_bsf.c | 40 ---
>  2 files changed, 33 insertions(+), 15 deletions(-)
> 
> diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
> index a6a5a331f5..47de4c7116 100644
> --- a/doc/bitstream_filters.texi
> +++ b/doc/bitstream_filters.texi
> @@ -657,7 +657,9 @@ Modify metadata embedded in a VP9 stream.
>  
>  @table @option
>  @item color_space
> -Set the color space value in the frame header.
> +Set the color space value in the frame header. Note that any frame
> +set to RGB will be implicitly set to PC range and that RGB is
> +incompatible with profiles 0 and 2.
>  @table @samp
>  @item unknown
>  @item bt601
> @@ -669,8 +671,8 @@ Set the color space value in the frame header.
>  @end table
>  
>  @item color_range
> -Set the color range value in the frame header.  Note that this cannot
> -be set in RGB streams.
> +Set the color range value in the frame header. Note that any value
> +imposed by the color space will take precedence over this value.
>  @table @samp
>  @item tv
>  @item pc
> diff --git a/libavcodec/vp9_metadata_bsf.c b/libavcodec/vp9_metadata_bsf.c
> index 1bde1b96aa..52e962b1c0 100644
> --- a/libavcodec/vp9_metadata_bsf.c
> +++ b/libavcodec/vp9_metadata_bsf.c
> @@ -33,7 +33,7 @@ typedef struct VP9MetadataContext {
>  int color_space;
>  int color_range;
>  
> -int color_range_rgb_warned;
> +int color_warnings;
>  } VP9MetadataContext;
>  
>  
> @@ -56,20 +56,36 @@ static int vp9_metadata_filter(AVBSFContext *bsf, 
> AVPacket *pkt)
>  for (i = 0; i < frag->nb_units; i++) {
>  VP9RawFrame *frame = frag->units[i].content;
>  VP9RawFrameHeader *header = &frame->header;
> +int profile = (header->profile_high_bit << 1) + 
> header->profile_low_bit;
> +
> +if (header->frame_type == VP9_KEY_FRAME ||
> +header->intra_only && profile > 0) {
> +if (ctx->color_space >= 0) {
> +if (!(profile & 1) && ctx->color_space == VP9_CS_RGB) {
> +if (!(ctx->color_warnings & 2)) {
> +av_log(bsf, AV_LOG_WARNING, "Warning: RGB "
> +   "incompatible with profiles 0 and 2.\n");
> +ctx->color_warnings |= 2;
> +}
> +} else
> +header->color_space = ctx->color_space;
> +}
>  
> -if (ctx->color_space >= 0) {
> -header->color_space = ctx->color_space;
> -}
> -if (ctx->color_range >= 0) {
> -if (ctx->color_range == 0 &&
> -header->color_space == VP9_CS_RGB &&
> -!ctx->color_range_rgb_warned) {
> -av_log(bsf, AV_LOG_WARNING, "Warning: color_range cannot "
> -   "be set to limited in RGB streams.\n");
> -ctx->color_range_rgb_warned = 1;
> -} else {
> +if (ctx->color_range >= 0)
>  header->color_range = ctx->color_range;
> +if (header->color_space == VP9_CS_RGB) {
> +if (!(ctx->color_warnings & 1) && !header->color_range) {
> +av_log(bsf, AV_LOG_WARNING, "Warning: Color space RGB "
> +   "implicitly sets color range to PC range.\n");
> +ctx->color_warnings |= 1;
> +}
> +header->color_range = 1;
>  }
> +} else if (!(ctx->color_warnings & 4) && header->intra_only && 
> !profile &&
> +   ctx->color_space >= 0 && ctx->color_space != 
> VP9_CS_BT_601) {
> +av_log(bsf, AV_LOG_WARNING, "Warning: Intra-only frames in "
> +   "profile 0 are automatically BT.601.\n");
> +ctx->color_warnings |= 4;
>  }
>  }
>  
> 

LGTM, applied.

Thanks,

- Mark
___
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 1/2] cbs_h264: Fix missing inferred colour description fields

[Mark Thompson]

With video_signal_type_present_flag set but colour_description_present_flag
unset the colour fields would not have had their correct values inferred.
---
 libavcodec/cbs_h264_syntax_template.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavcodec/cbs_h264_syntax_template.c 
b/libavcodec/cbs_h264_syntax_template.c
index 26be6e590f..1671a15d33 100644
--- a/libavcodec/cbs_h264_syntax_template.c
+++ b/libavcodec/cbs_h264_syntax_template.c
@@ -137,6 +137,10 @@ static int FUNC(vui_parameters)(CodedBitstreamContext 
*ctx, RWContext *rw,
 ub(8, colour_primaries);
 ub(8, transfer_characteristics);
 ub(8, matrix_coefficients);
+} else {
+infer(colour_primaries, 2);
+infer(transfer_characteristics, 2);
+infer(matrix_coefficients,  2);
 }
 } else {
 infer(video_format, 5);
-- 
2.20.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 2/2] h264_metadata: Support overscan_appropriate_flag

[Mark Thompson]

Fixes #8041.
---
Requested in .


 doc/bitstream_filters.texi |  4 
 libavcodec/h264_metadata_bsf.c | 11 +++
 2 files changed, 15 insertions(+)

diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
index 023945e9be..50a1679fc7 100644
--- a/doc/bitstream_filters.texi
+++ b/doc/bitstream_filters.texi
@@ -224,6 +224,10 @@ Insert or remove AUD NAL units in all access units of the 
stream.
 @item sample_aspect_ratio
 Set the sample aspect ratio of the stream in the VUI parameters.
 
+@item overscan_appropriate_flag
+Set whether the stream is suitable for display using overscan
+or not (see H.264 section E.2.1).
+
 @item video_format
 @item video_full_range_flag
 Set the video format in the stream (see H.264 section E.2.1 and
diff --git a/libavcodec/h264_metadata_bsf.c b/libavcodec/h264_metadata_bsf.c
index 3684e6bf7f..5de74be9d6 100644
--- a/libavcodec/h264_metadata_bsf.c
+++ b/libavcodec/h264_metadata_bsf.c
@@ -57,6 +57,8 @@ typedef struct H264MetadataContext {
 
 AVRational sample_aspect_ratio;
 
+int overscan_appropriate_flag;
+
 int video_format;
 int video_full_range_flag;
 int colour_primaries;
@@ -129,6 +131,11 @@ static int h264_metadata_update_sps(AVBSFContext *bsf,
 } \
 } while (0)
 
+if (ctx->overscan_appropriate_flag >= 0) {
+SET_VUI_FIELD(overscan_appropriate_flag);
+sps->vui.overscan_info_present_flag = 1;
+}
+
 if (ctx->video_format >= 0 ||
 ctx->video_full_range_flag>= 0 ||
 ctx->colour_primaries >= 0 ||
@@ -630,6 +637,10 @@ static const AVOption h264_metadata_options[] = {
 OFFSET(sample_aspect_ratio), AV_OPT_TYPE_RATIONAL,
 { .dbl = 0.0 }, 0, 65535, FLAGS },
 
+{ "overscan_appropriate_flag", "Set VUI overscan appropriate flag",
+OFFSET(overscan_appropriate_flag), AV_OPT_TYPE_INT,
+{ .i64 = -1 }, -1, 1, FLAGS },
+
 { "video_format", "Set video format (table E-2)",
 OFFSET(video_format), AV_OPT_TYPE_INT,
 { .i64 = -1 }, -1, 7, FLAGS},
-- 
2.20.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 v2] avcodec/mips: [loongson] refine process of setting block as 0 in h264dsp_mmi.

[Michael Niedermayer]

On Sun, Jul 28, 2019 at 04:07:40PM +0200, Reimar Döffinger wrote:
> I have no MIPS experience, but for what little it is worth thus: it looks 
> fine to me.

will apply

thanks

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

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.


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".

[FFmpeg-devel] libavformat/mpegtsenc: fix incorrect PCR with multiple programs [v3]

[Andreas Håkon]

Hi,

This last version fixes the small bug discovered by Michael Niedermayer:
https://patchwork.ffmpeg.org/patch/14099/

This version is finally clean.

Regards.
A.H.

---From 08565b81aa2b6d75043e5e984da143480891c3b0 Mon Sep 17 00:00:00 2001
From: Andreas Hakon 
Date: Sun, 28 Jul 2019 19:59:51 +0100
Subject: [PATCH] libavformat/mpegtsenc: fix incorrect PCR with multiple
 programs [v3]

The MPEG-TS muxer has a serious bug related to the PCR pid selection.
This bug appears when more than one program is used. The root cause is because
the current code targets only one program when selecting the stream for the PCR.

This patch solves this problem and select correct streams for each program.
Furthermore, it passes all the checks and doesn't generate any regression.

You can check it with this command:

$ ./ffmpeg -loglevel verbose -y -f data -i /dev/zero \
 -filter_complex "nullsrc=s=60x60,split=2[v0][v1],anullsrc[a]" \
 -map [v0] -c:v:0 rawvideo \
 -map [v1] -c:v:1 rawvideo \
 -map [a]  -c:a:0 pcm_s8 \
 -program st=0 -program st=1 -program st=2 -f mpegts out.ts

And you will see something like:

[mpegts @ 0x562f388cd800] service 1 using PCR in pid=256
[mpegts @ 0x562f388cd800] service 2 using PCR in pid=257
[mpegts @ 0x562f388cd800] service 3 using PCR in pid=258


Signed-off-by: Andreas Hakon 
---
 libavformat/mpegtsenc.c |  103 ---
 1 file changed, 62 insertions(+), 41 deletions(-)

diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index fc0ea22..fc340cd 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -60,6 +60,7 @@ typedef struct MpegTSService {
 int pcr_packet_count;
 int pcr_packet_period;
 AVProgram *program;
+AVStream *pcr_st;
 } MpegTSService;
 
 // service_type values as defined in ETSI 300 468
@@ -774,7 +775,7 @@ static int mpegts_init(AVFormatContext *s)
 MpegTSWrite *ts = s->priv_data;
 MpegTSWriteStream *ts_st;
 MpegTSService *service;
-AVStream *st, *pcr_st = NULL;
+AVStream *st;
 AVDictionaryEntry *title, *provider;
 int i, j;
 const char *service_name;
@@ -831,6 +832,11 @@ static int mpegts_init(AVFormatContext *s)
 }
 }
 
+for (i = 0; i < ts->nb_services; i++) {
+service = ts->services[i];
+service->pcr_st = NULL;
+}
+
 ts->pat.pid  = PAT_PID;
 /* Initialize at 15 so that it wraps and is equal to 0 for the
  * first packet we write. */
@@ -917,7 +923,12 @@ static int mpegts_init(AVFormatContext *s)
 if (st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO &&
 service->pcr_pid == 0x1fff) {
 service->pcr_pid = ts_st->pid;
-pcr_st   = st;
+service->pcr_st  = st;
+}
+/* store this stream as a candidate PCR if the service doesn't have 
any */
+if (service->pcr_pid == 0x1fff &&
+!service->pcr_st) {
+service->pcr_st  = st;
 }
 if (st->codecpar->codec_id == AV_CODEC_ID_AAC &&
 st->codecpar->extradata_size > 0) {
@@ -951,50 +962,62 @@ static int mpegts_init(AVFormatContext *s)
 }
 }
 
-av_freep(&pids);
+for (i = 0; i < ts->nb_services; i++) {
+service = ts->services[i];
 
-/* if no video stream, use the first stream as PCR */
-if (service->pcr_pid == 0x1fff && s->nb_streams > 0) {
-pcr_st   = s->streams[0];
-ts_st= pcr_st->priv_data;
-service->pcr_pid = ts_st->pid;
-} else
-ts_st = pcr_st->priv_data;
-
-if (ts->mux_rate > 1) {
-service->pcr_packet_period = (int64_t)ts->mux_rate * ts->pcr_period /
- (TS_PACKET_SIZE * 8 * 1000);
-ts->sdt_packet_period  = (int64_t)ts->mux_rate * SDT_RETRANS_TIME /
- (TS_PACKET_SIZE * 8 * 1000);
-ts->pat_packet_period  = (int64_t)ts->mux_rate * PAT_RETRANS_TIME /
- (TS_PACKET_SIZE * 8 * 1000);
-
-if (ts->copyts < 1)
-ts->first_pcr = av_rescale(s->max_delay, PCR_TIME_BASE, 
AV_TIME_BASE);
-} else {
-/* Arbitrary values, PAT/PMT will also be written on video key frames 
*/
-ts->sdt_packet_period = 200;
-ts->pat_packet_period = 40;
-if (pcr_st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO) {
-int frame_size = av_get_audio_frame_duration2(pcr_st->codecpar, 0);
-if (!frame_size) {
-av_log(s, AV_LOG_WARNING, "frame size not set\n");
-service->pcr_packet_period =
-pcr_st->codecpar->sample_rate / (10 * 512);
+/* get the PCR stream (real or candidate) */
+if (!service->pcr_st) {
+av_log(s, AV_LOG_ERROR, "no PCR selected for the service %i", 
service->sid);
+ret = AVERROR(EINVAL);
+goto fail;
+}
+ts_st = service->pcr_st->priv_data;
+
+/* 

Re: [FFmpeg-devel] libavformat/mpegtsenc: fix incorrect PCR with multiple programs [v2]

[Andreas Håkon]

Hi Michael,


‐‐‐ Original Message ‐‐‐
On Sunday, 28 de July de 2019 16:39, Michael Niedermayer 
 wrote:

> On Sat, Jul 27, 2019 at 08:41:02PM +, Andreas Håkon wrote:
>
> > Hi,
> > This newversion fixes all the problems commented in
> > https://patchwork.ffmpeg.org/patch/14036/
> > Now, it works with/without video streams.
> > Regards.
> > A.H.
>
> This causes the stream from ticket/3714 to become noticably bigger
>
> ./ffmpeg -i 3714/FFmpeg\ Sample_cut.ts -vcodec copy -acodec copy -pat_period 
> 1 -sdt_period 1 this_was_less_than_256.ts
>
> -rw-r- 1 michael michael 2700056 Jul 28 16:12 
> this_was_less_than_256.ts
>
> before:
> -rw-r- 1 michael michael 2559808 Jul 28 16:13 
> this_was_less_than_256.ts
> -rw-r- 1 michael michael 256 Jun 11 2014 3714/FFmpeg Sample_cut.ts
>
> sample should be here: 
> https://trac.ffmpeg.org/raw-attachment/ticket/3714/FFmpeg Sample_cut.ts
>
> [...]

OMG!
Thank you Michael for finding this mistake... I missed a previous code block.

A new fixed version is here:
https://patchwork.ffmpeg.org/patch/14109/

And this new version pass the check with the file "FFmpeg Sample_cut.ts". 
Identical file size output.

Regards.
A.H.

---

___
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] avcodec/dstdec: add slice threading support

[Paul B Mahol]

Hi,

patch attached.


0001-avcodec-dstdec-add-slice-threading-support.patch
Description: Binary data
___
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] avcodec/dsddec: add slice threading support

[Paul B Mahol]

Hi,

patch attached.


0002-avcodec-dsddec-add-slice-threading-support.patch
Description: Binary data
___
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] avcodec/arm/sbcenc: save callee preserved vfp registers

[James Cowgill]

When compiling FFmpeg with GCC-9, some very random segfaults were
observed in code which had previously called down into the SBC encoder
NEON assembly routines. This was caused by these functions clobbering
some of the vfp callee saved registers (d8 - d15 aka q4 - q7). GCC was
using these registers to save local variables, but after these
functions returned, they would contain garbage.

Fix by saving the relevant registers on the stack in the affected
functions.

Signed-off-by: James Cowgill 
---
 libavcodec/arm/sbcdsp_neon.S | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/libavcodec/arm/sbcdsp_neon.S b/libavcodec/arm/sbcdsp_neon.S
index d83d21d202..aa03800096 100644
--- a/libavcodec/arm/sbcdsp_neon.S
+++ b/libavcodec/arm/sbcdsp_neon.S
@@ -38,6 +38,8 @@ function ff_sbc_analyze_4_neon, export=1
 /* TODO: merge even and odd cases (or even merge all four calls to this
  * function) in order to have only aligned reads from 'in' array
  * and reduce number of load instructions */
+vpush   {d8-d11}
+
 vld1.16 {d4, d5}, [r0, :64]!
 vld1.16 {d8, d9}, [r2, :128]!
 
@@ -84,6 +86,7 @@ function ff_sbc_analyze_4_neon, export=1
 
 vst1.32 {d0, d1}, [r1, :128]
 
+vpop{d8-d11}
 bx  lr
 endfunc
 
@@ -91,6 +94,8 @@ function ff_sbc_analyze_8_neon, export=1
 /* TODO: merge even and odd cases (or even merge all four calls to this
  * function) in order to have only aligned reads from 'in' array
  * and reduce number of load instructions */
+vpush   {d8-d15}
+
 vld1.16 {d4, d5}, [r0, :64]!
 vld1.16 {d8, d9}, [r2, :128]!
 
@@ -188,6 +193,7 @@ function ff_sbc_analyze_8_neon, export=1
 
 vst1.32 {d0, d1, d2, d3}, [r1, :128]
 
+vpop{d8-d15}
 bx  lr
 endfunc
 
-- 
2.22.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".

Re: [FFmpeg-devel] [PATCH v4 1/2] vaapi_encode: Add ROI support

[Mark Thompson]

On 16/07/2019 08:19, Guo, Yejun wrote:>> -Original Message-
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
>> Mark Thompson
>> Sent: Monday, July 08, 2019 3:27 AM
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: [FFmpeg-devel] [PATCH v4 1/2] vaapi_encode: Add ROI support
>>
>> ---
>>  libavcodec/vaapi_encode.c   | 118
>> 
>>  libavcodec/vaapi_encode.h   |  18 +
>>  libavcodec/vaapi_encode_h264.c  |   2 +
>>  libavcodec/vaapi_encode_h265.c  |   2 +
>>  libavcodec/vaapi_encode_mpeg2.c |   2 +
>>  libavcodec/vaapi_encode_vp8.c   |   2 +
>>  libavcodec/vaapi_encode_vp9.c   |   2 +
>>  7 files changed, 146 insertions(+)
>>
>> ...
>> @@ -948,6 +1016,19 @@ static int
>> vaapi_encode_check_frame(AVCodecContext *avctx,
>>  ctx->crop_warned = 1;
>>  }
>>
>> +if (!ctx->roi_allowed) {
>> +AVFrameSideData *sd =
>> +av_frame_get_side_data(frame,
>> AV_FRAME_DATA_REGIONS_OF_INTEREST);
>> +
>> +if (sd && !ctx->roi_warned) {
>> +if (sd && !ctx->roi_warned) {
> 
> looks good except this duplicate code

Good catch, fixed.

>> +av_log(avctx, AV_LOG_WARNING, "ROI side data on input
>> "
>> +   "frames ignored due to lack of driver
>> support.\n");
>> +ctx->roi_warned = 1;
>> +}
>> +}
>> +}
>> +
>>  return 0;
>>  }

And set applied with that.

Thank you for reviewing!

- Mark
___
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 3/3] avformat/mpsubdec: Check pts / duration before cast

[Michael Niedermayer]

Fixes: 3e+47 is outside the range of representable values of type 'int'
Fixes: 
16057/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-569307214848

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavformat/mpsubdec.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/libavformat/mpsubdec.c b/libavformat/mpsubdec.c
index 4ff49ba3cf..a8217a4a61 100644
--- a/libavformat/mpsubdec.c
+++ b/libavformat/mpsubdec.c
@@ -83,13 +83,20 @@ static int mpsub_read_header(AVFormatContext *s)
 
 ff_subtitles_read_chunk(s->pb, &buf);
 if (buf.len) {
+double ts = current_pts + start*multiplier;
 sub = ff_subtitles_queue_insert(&mpsub->q, buf.str, buf.len, 
0);
 if (!sub) {
 res = AVERROR(ENOMEM);
 goto end;
 }
-sub->pts = (int64_t)(current_pts + start*multiplier);
-sub->duration = (int)(duration * multiplier);
+if (!isfinite(ts) || ts < INT64_MIN || ts > INT64_MAX) {
+avpriv_request_sample(s, "Invalid ts\n");
+} else
+sub->pts = (int64_t)ts;
+if (!isfinite(duration) || duration * multiplier > INT_MAX || 
duration < 0) {
+avpriv_request_sample(s, "Invalid duration\n");
+} else
+sub->duration = (int)(duration * multiplier);
 current_pts += (start + duration) * multiplier;
 sub->pos = pos;
 }
-- 
2.22.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] [PATCH 2/3] avcodec/eatqi: Check for minimum frame size

[Michael Niedermayer]

The minimum header is 8 bytes, the smallest bitstream that is passed to
the MB decode code is 4 bytes

Fixes: Timeout (35sec -> 18sec)
Fixes: 
15800/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_EATQI_fuzzer-5684154517159936

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/eatqi.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavcodec/eatqi.c b/libavcodec/eatqi.c
index 0002d45457..96536b1a08 100644
--- a/libavcodec/eatqi.c
+++ b/libavcodec/eatqi.c
@@ -131,6 +131,9 @@ static int tqi_decode_frame(AVCodecContext *avctx,
 AVFrame *frame = data;
 int ret, w, h;
 
+if (buf_size < 12)
+return AVERROR_INVALIDDATA;
+
 t->avctx = avctx;
 
 w = AV_RL16(&buf[0]);
-- 
2.22.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] [PATCH 1/3] avcodec/eatgv: Check remaining size after the keyframe header

[Michael Niedermayer]

The minimal size which unpack() will not fail on is 5 bytes
Fixes: Timeout (14sec -> 77ms) (testcase 15508)
Fixes: 
15508/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_EATGV_fuzzer-5700053513011200
Fixes: 
15996/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_EATGV_fuzzer-5751353223151616

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/eatgv.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavcodec/eatgv.c b/libavcodec/eatgv.c
index 93e291f053..77b5da1f14 100644
--- a/libavcodec/eatgv.c
+++ b/libavcodec/eatgv.c
@@ -300,6 +300,10 @@ static int tgv_decode_frame(AVCodecContext *avctx,
 s->palette[i] = 0xFFU << 24 | AV_RB24(buf);
 buf += 3;
 }
+if (buf_end - buf < 5) {
+av_log(avctx, AV_LOG_WARNING, "packed data truncated\n");
+return AVERROR_INVALIDDATA;
+}
 }
 
 if ((ret = ff_get_buffer(avctx, frame, AV_GET_BUFFER_FLAG_REF)) < 0)
-- 
2.22.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".

Re: [FFmpeg-devel] [PATCH 1/2] cbs_h264: Fix missing inferred colour description fields

[Andreas Rheinhardt]

Mark Thompson:
> With video_signal_type_present_flag set but colour_description_present_flag
> unset the colour fields would not have had their correct values inferred.
> ---
>  libavcodec/cbs_h264_syntax_template.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/libavcodec/cbs_h264_syntax_template.c 
> b/libavcodec/cbs_h264_syntax_template.c
> index 26be6e590f..1671a15d33 100644
> --- a/libavcodec/cbs_h264_syntax_template.c
> +++ b/libavcodec/cbs_h264_syntax_template.c
> @@ -137,6 +137,10 @@ static int FUNC(vui_parameters)(CodedBitstreamContext 
> *ctx, RWContext *rw,
>  ub(8, colour_primaries);
>  ub(8, transfer_characteristics);
>  ub(8, matrix_coefficients);
> +} else {
> +infer(colour_primaries, 2);
> +infer(transfer_characteristics, 2);
> +infer(matrix_coefficients,  2);
>  }
>  } else {
>  infer(video_format, 5);
> 
LGTM. And sorry for not catching this before 43a18884.

- 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/2] h264_metadata: Support overscan_appropriate_flag

[Andreas Rheinhardt]

Mark Thompson:
> Fixes #8041.
> ---
> Requested in .
> 
> 
>  doc/bitstream_filters.texi |  4 
>  libavcodec/h264_metadata_bsf.c | 11 +++
>  2 files changed, 15 insertions(+)
> 
> diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
> index 023945e9be..50a1679fc7 100644
> --- a/doc/bitstream_filters.texi
> +++ b/doc/bitstream_filters.texi
> @@ -224,6 +224,10 @@ Insert or remove AUD NAL units in all access units of 
> the stream.
>  @item sample_aspect_ratio
>  Set the sample aspect ratio of the stream in the VUI parameters.
>  
> +@item overscan_appropriate_flag
> +Set whether the stream is suitable for display using overscan
> +or not (see H.264 section E.2.1).
> +
>  @item video_format
>  @item video_full_range_flag
>  Set the video format in the stream (see H.264 section E.2.1 and
> diff --git a/libavcodec/h264_metadata_bsf.c b/libavcodec/h264_metadata_bsf.c
> index 3684e6bf7f..5de74be9d6 100644
> --- a/libavcodec/h264_metadata_bsf.c
> +++ b/libavcodec/h264_metadata_bsf.c
> @@ -57,6 +57,8 @@ typedef struct H264MetadataContext {
>  
>  AVRational sample_aspect_ratio;
>  
> +int overscan_appropriate_flag;
> +
>  int video_format;
>  int video_full_range_flag;
>  int colour_primaries;
> @@ -129,6 +131,11 @@ static int h264_metadata_update_sps(AVBSFContext *bsf,
>  } \
>  } while (0)
>  
> +if (ctx->overscan_appropriate_flag >= 0) {
> +SET_VUI_FIELD(overscan_appropriate_flag);

LGTM. But just to make sure: You are aware that the check contained in
SET_VUI_FIELD is redundant here?

> +sps->vui.overscan_info_present_flag = 1;
> +}
> +
>  if (ctx->video_format >= 0 ||
>  ctx->video_full_range_flag>= 0 ||
>  ctx->colour_primaries >= 0 ||
> @@ -630,6 +637,10 @@ static const AVOption h264_metadata_options[] = {
>  OFFSET(sample_aspect_ratio), AV_OPT_TYPE_RATIONAL,
>  { .dbl = 0.0 }, 0, 65535, FLAGS },
>  
> +{ "overscan_appropriate_flag", "Set VUI overscan appropriate flag",
> +OFFSET(overscan_appropriate_flag), AV_OPT_TYPE_INT,
> +{ .i64 = -1 }, -1, 1, FLAGS },
> +
>  { "video_format", "Set video format (table E-2)",
>  OFFSET(video_format), AV_OPT_TYPE_INT,
>  { .i64 = -1 }, -1, 7, FLAGS},
> 

___
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 25/31] cbs: Add function to update video codec parameters

[Andreas Rheinhardt]

Mark Thompson:
> On 20/06/2019 00:45, Andreas Rheinhardt wrote:
>> If any of the *_metadata filter based upon cbs currently updates a video
>> codec parameter like color information, the AVCodecParameters are not
>> updated accordingly, so that e.g. muxers write header values based upon
>> outdated information that may precede and thereby nullify the new values
>> on the bitstream level.
>> This commit adds a function to also update the video codec parameters
>> so that the above situation can be fixed in a unified manner.
>>
>> Signed-off-by: Andreas Rheinhardt 
>> ---
>>  libavcodec/cbs.c | 35 +++
>>  libavcodec/cbs.h | 15 +++
>>  2 files changed, 50 insertions(+)
>>
>> diff --git a/libavcodec/cbs.c b/libavcodec/cbs.c
>> index 47679eca1b..37b080b5ba 100644
>> --- a/libavcodec/cbs.c
>> +++ b/libavcodec/cbs.c
>> @@ -342,6 +342,41 @@ int ff_cbs_write_extradata(CodedBitstreamContext *ctx,
>>  return 0;
>>  }
>>  
>> +void ff_cbs_update_video_parameters(CodedBitstreamContext *ctx,
> 
> The context argument isn't used at all.
> 
I know. I thought that's how you wanted the API to look like. After
all, ff_cbs_fragment_uninit always used a context argument without
needing it (cbs_unit_uninit doesn't use its context argument at all
and it is the only place where ff_cbs_fragment_uninit used it; I of
course kept this behaviour when replacing ff_cbs_fragment_uninit). Now
that it seems that this was unintentional, I will send a patch to
remove the argument.

>> +AVCodecParameters *par, int profile,
>> +int level, int width, int height,
>> +int field_order, int color_range,
>> +int color_primaries, int color_trc,
>> +int color_space, int chroma_location,
>> +int video_delay)
>> +{
>> +#define SET_IF_NONNEGATIVE(elem) \
>> +if (elem >= 0) \
>> +par->elem = elem;
>> +SET_IF_NONNEGATIVE(profile)
>> +SET_IF_NONNEGATIVE(level)
>> +SET_IF_NONNEGATIVE(width)
>> +SET_IF_NONNEGATIVE(height)
>> +SET_IF_NONNEGATIVE(field_order)
>> +SET_IF_NONNEGATIVE(video_delay)
>> +#undef SET_IF_NONNEGATIVE
>> +
>> +#define SET_IF_VALID(elem, upper_bound) \
>> +if (0 <= elem && elem < upper_bound) \
>> +par->elem = elem;
>> +SET_IF_VALID(color_range, AVCOL_RANGE_NB)
>> +SET_IF_VALID(color_trc,   AVCOL_TRC_NB)
>> +SET_IF_VALID(color_space, AVCOL_SPC_NB)
> 
> I think we generally want to admit future values for the 23001-8 / H.273 
> fields (see range ..255 on all the metadata filters).
> 
Do you want to omit checking entirely? Or should I still check against
the sentinel? I prefer the latter. I dislike setting an enum to
something else than an enum constant and moreover, if a future
standard would allow (say) color_range > 255 (or a bsf would simply
forget to check the value), but libavcodec does not, then it might be
that the compiler uses char as underlying type for the enum which of
course could not hold such a value.

>> +SET_IF_VALID(chroma_location, AVCHROMA_LOC_NB)
>> +#undef SET_IF_VALID
>> +
>> +if (0 <= color_primaries && color_primaries <= AVCOL_PRI_SMPTE432
>> + || color_primaries == AVCOL_PRI_JEDEC_P22)
>> +par->color_primaries = color_primaries;
>> +
And how about the gap in the color_primaries values?

>> +return;
>> +}
>> +
>>  int ff_cbs_write_packet(CodedBitstreamContext *ctx,
>>  AVPacket *pkt,
>>  CodedBitstreamFragment *frag)
>> diff --git a/libavcodec/cbs.h b/libavcodec/cbs.h
>> index e1e6055ceb..1655f790cd 100644
>> --- a/libavcodec/cbs.h
>> +++ b/libavcodec/cbs.h
>> @@ -304,6 +304,21 @@ int ff_cbs_write_extradata(CodedBitstreamContext *ctx,
>> AVCodecParameters *par,
>> CodedBitstreamFragment *frag);
>>  
>> +/**
>> + * Update the parameters of an AVCodecParameters structure
>> + *
>> + * If a parameter is negative, the corresponding member is not
>> + * modified. For the color/chroma parameters, only values that
>> + * are part of the relevant enumeration are written.
>> + */
>> +void ff_cbs_update_video_parameters(CodedBitstreamContext *ctx,
>> +AVCodecParameters *par, int profile,
>> +int level, int width, int height,
>> +int field_order, int color_range,
>> +int color_primaries, int color_trc,
>> +int color_space, int chroma_location,
>> +int video_delay);
> 
> I find the calls with -1, -1, -1 pretty horrible, and all the extra pointer 
> arguments being passed around in the metadata filters are not very nice 
> either.
> 
> To

[FFmpeg-devel] [PATCH V2 2/3] fate: add unit test for dnn-layer-pad

[Guo, Yejun]

'make fate-dnn-layer-pad' to run the test

Signed-off-by: Guo, Yejun 
---
 tests/Makefile |   5 +-
 tests/dnn/Makefile |  11 +++
 tests/dnn/dnn-layer-pad-test.c | 203 +
 tests/fate/dnn.mak |   8 ++
 4 files changed, 226 insertions(+), 1 deletion(-)
 create mode 100644 tests/dnn/Makefile
 create mode 100644 tests/dnn/dnn-layer-pad-test.c
 create mode 100644 tests/fate/dnn.mak

diff --git a/tests/Makefile b/tests/Makefile
index 624292d..0ef571b 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -10,7 +10,8 @@ FFMPEG=ffmpeg$(PROGSSUF)$(EXESUF)
 $(AREF): CMP=
 
 APITESTSDIR := tests/api
-FATE_OUTDIRS = tests/data tests/data/fate tests/data/filtergraphs 
tests/data/lavf tests/data/lavf-fate tests/data/pixfmt tests/vsynth1 
$(APITESTSDIR)
+DNNTESTSDIR := tests/dnn
+FATE_OUTDIRS = tests/data tests/data/fate tests/data/filtergraphs 
tests/data/lavf tests/data/lavf-fate tests/data/pixfmt tests/vsynth1 
$(APITESTSDIR) $(DNNTESTSDIR)
 OUTDIRS += $(FATE_OUTDIRS)
 
 $(VREF): tests/videogen$(HOSTEXESUF) | tests/vsynth1
@@ -85,6 +86,7 @@ FILTERDEMDECENCMUX = $(call ALLYES, $(1:%=%_FILTER) 
$(2)_DEMUXER $(3)_DECODER $(
 PARSERDEMDEC   = $(call ALLYES, $(1)_PARSER $(2)_DEMUXER $(3)_DECODER)
 
 include $(SRC_PATH)/$(APITESTSDIR)/Makefile
+include $(SRC_PATH)/$(DNNTESTSDIR)/Makefile
 
 include $(SRC_PATH)/tests/fate/acodec.mak
 include $(SRC_PATH)/tests/fate/vcodec.mak
@@ -118,6 +120,7 @@ include $(SRC_PATH)/tests/fate/cover-art.mak
 include $(SRC_PATH)/tests/fate/dca.mak
 include $(SRC_PATH)/tests/fate/demux.mak
 include $(SRC_PATH)/tests/fate/dfa.mak
+include $(SRC_PATH)/tests/fate/dnn.mak
 include $(SRC_PATH)/tests/fate/dnxhd.mak
 include $(SRC_PATH)/tests/fate/dpcm.mak
 include $(SRC_PATH)/tests/fate/ea.mak
diff --git a/tests/dnn/Makefile b/tests/dnn/Makefile
new file mode 100644
index 000..b2e6680
--- /dev/null
+++ b/tests/dnn/Makefile
@@ -0,0 +1,11 @@
+DNNTESTPROGS += dnn-layer-pad
+
+DNNTESTOBJS  := $(DNNTESTOBJS:%=$(DNNTESTSDIR)%) 
$(DNNTESTPROGS:%=$(DNNTESTSDIR)/%-test.o)
+DNNTESTPROGS := $(DNNTESTPROGS:%=$(DNNTESTSDIR)/%-test$(EXESUF))
+-include $(wildcard $(DNNTESTOBJS:.o=.d))
+
+$(DNNTESTPROGS): %$(EXESUF): %.o $(FF_DEP_LIBS)
+   $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $(filter %.o,$^) $(FF_EXTRALIBS) 
$(ELIBS)
+
+testclean::
+   $(RM) $(addprefix $(DNNTESTSDIR)/,$(CLEANSUFFIXES) *-test$(EXESUF))
diff --git a/tests/dnn/dnn-layer-pad-test.c b/tests/dnn/dnn-layer-pad-test.c
new file mode 100644
index 000..28a49eb
--- /dev/null
+++ b/tests/dnn/dnn-layer-pad-test.c
@@ -0,0 +1,203 @@
+/*
+ * Copyright (c) 2019 Guo Yejun
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include 
+#include 
+#include 
+#include "libavfilter/dnn/dnn_backend_native_layer_pad.h"
+
+#define EPSON 0.1
+
+static int test_with_mode_symmetric(void)
+{
+// the input data and expected data are generated with below python code.
+/*
+x = tf.placeholder(tf.float32, shape=[1, None, None, 3])
+y = tf.pad(x, [[0, 0], [2, 3], [3, 2], [0, 0]], 'SYMMETRIC')
+data = np.arange(48).reshape(1, 4, 4, 3);
+
+sess=tf.Session()
+sess.run(tf.global_variables_initializer())
+output = sess.run(y, feed_dict={x: data})
+
+print(list(data.flatten()))
+print(list(output.flatten()))
+print(data.shape)
+print(output.shape)
+*/
+
+LayerPadParams params;
+float input[1*4*4*3] = {
+0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 
20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 
40, 41, 42, 43, 44, 45, 46, 47
+};
+float expected_output[1*9*9*3] = {
+18.0, 19.0, 20.0, 15.0, 16.0, 17.0, 12.0, 13.0, 14.0, 12.0, 13.0, 
14.0, 15.0, 16.0, 17.0, 18.0, 19.0, 20.0, 21.0, 22.0, 23.0, 21.0, 22.0, 23.0, 
18.0, 19.0, 20.0, 6.0, 7.0, 8.0, 3.0,
+4.0, 5.0, 0.0, 1.0, 2.0, 0.0, 1.0, 2.0, 3.0, 4.0, 5.0, 6.0, 7.0, 8.0, 
9.0, 10.0, 11.0, 9.0, 10.0, 11.0, 6.0, 7.0, 8.0, 6.0, 7.0, 8.0, 3.0, 4.0, 5.0, 
0.0, 1.0, 2.0, 0.0, 1.0, 2.0, 3.0,
+4.0, 5.0, 6.0, 7.0, 8.0, 9.0, 10.0, 11.0, 9.0, 10.0, 11.0, 6.0, 7.0, 
8.0, 18.0, 19.0, 20.0, 15.0, 16.0, 17.0, 12.0, 13.0, 14.0, 12.0, 13.0, 14.0, 
15.0, 16.0, 17.0, 18.0, 19.0, 20.0,
+   

[FFmpeg-devel] [PATCH V2 1/3] dnn: add layer pad which is equivalent to tf.pad

[Guo, Yejun]

the reason to add this layer first is that vf_sr uses it in its
tensorflow model, and the next plan is to update the python script
to convert tf.pad into native model.

Signed-off-by: Guo, Yejun 
---
 libavfilter/dnn/Makefile   |   1 +
 libavfilter/dnn/dnn_backend_native_layer_pad.c | 211 +
 libavfilter/dnn/dnn_backend_native_layer_pad.h |  40 +
 3 files changed, 252 insertions(+)
 create mode 100644 libavfilter/dnn/dnn_backend_native_layer_pad.c
 create mode 100644 libavfilter/dnn/dnn_backend_native_layer_pad.h

diff --git a/libavfilter/dnn/Makefile b/libavfilter/dnn/Makefile
index 1d12ade..83938e5 100644
--- a/libavfilter/dnn/Makefile
+++ b/libavfilter/dnn/Makefile
@@ -1,5 +1,6 @@
 OBJS-$(CONFIG_DNN)   += dnn/dnn_interface.o
 OBJS-$(CONFIG_DNN)   += dnn/dnn_backend_native.o
+OBJS-$(CONFIG_DNN)   += 
dnn/dnn_backend_native_layer_pad.o
 
 DNN-OBJS-$(CONFIG_LIBTENSORFLOW) += dnn/dnn_backend_tf.o
 
diff --git a/libavfilter/dnn/dnn_backend_native_layer_pad.c 
b/libavfilter/dnn/dnn_backend_native_layer_pad.c
new file mode 100644
index 000..5417d73
--- /dev/null
+++ b/libavfilter/dnn/dnn_backend_native_layer_pad.c
@@ -0,0 +1,211 @@
+/*
+ * Copyright (c) 2019 Guo Yejun
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include 
+#include "libavutil/avassert.h"
+#include "dnn_backend_native_layer_pad.h"
+
+static int before_get_buddy(int given, int paddings, LayerPadModeParam mode)
+{
+if (mode == LPMP_SYMMETRIC) {
+return (2 * paddings - 1 - given);
+} else if (mode == LPMP_REFLECT) {
+return (2 * paddings - given);
+} else {
+av_assert0(!"should not reach here");
+return 0;
+}
+}
+
+static int after_get_buddy(int given, int border, LayerPadModeParam mode)
+{
+if (mode == LPMP_SYMMETRIC) {
+int offset = given - border;
+return (border - 1 - offset);
+} else if (mode == LPMP_REFLECT) {
+int offset = given - border;
+return (border - 2 - offset);
+} else {
+av_assert0(!"should not reach here");
+return 0;
+}
+}
+
+void dnn_execute_layer_pad(const float *input, float *output, const 
LayerPadParams *params, int number, int height, int width, int channel)
+{
+int32_t before_paddings;
+int32_t after_paddings;
+
+// suppose format is 
+int new_number = number + params->paddings[0][0] + params->paddings[0][1];
+int new_height = height + params->paddings[1][0] + params->paddings[1][1];
+int new_width = width + params->paddings[2][0] + params->paddings[2][1];
+int new_channel = channel + params->paddings[3][0] + 
params->paddings[3][1];
+
+int c_stride = channel;
+int wc_stride = c_stride * width;
+int hwc_stride = wc_stride * height;
+
+int new_c_stride = new_channel;
+int new_wc_stride = new_c_stride * new_width;
+int new_hwc_stride = new_wc_stride * new_height;
+
+// copy the original data
+for (int n = 0; n < number; n++) {
+for (int h = 0; h < height; h++) {
+for (int w = 0; w < width; w++) {
+const float *src = input + n * hwc_stride + h * wc_stride + w 
* c_stride;
+float *dst = output + (n + params->paddings[0][0]) * 
new_hwc_stride
++ (h + params->paddings[1][0]) * 
new_wc_stride
++ (w + params->paddings[2][0]) * 
new_c_stride
++ params->paddings[3][0];
+memcpy(dst, src, channel * sizeof(float));
+}
+}
+}
+
+// handle the first dimension
+before_paddings = params->paddings[0][0];
+after_paddings = params->paddings[0][1];
+for (int n = 0; n < before_paddings; n++) {
+float *dst = output + n * new_hwc_stride;
+if (params->mode == LPMP_CONSTANT) {
+for (int i = 0; i < new_hwc_stride; i++) {
+dst[i] = params->constant_values;
+}
+}
+else {
+int buddy = before_get_buddy(n, before_paddings, params->mode);
+float *src = output + buddy * new_hwc_stride;
+memcpy(dst, src, new_hwc_str

[FFmpeg-devel] [PATCH V2 3/3] dnn: convert tf.pad to native model in python script, and load/execute it in the c code.

[Guo, Yejun]

since tf.pad is enabled, the conv2d(valid) changes back to its original 
behavior.

Signed-off-by: Guo, Yejun 
---
 libavfilter/dnn/dnn_backend_native.c| 35 +
 libavfilter/dnn/dnn_backend_native.h|  2 +-
 tools/python/convert_from_tensorflow.py | 23 +-
 3 files changed, 54 insertions(+), 6 deletions(-)

diff --git a/libavfilter/dnn/dnn_backend_native.c 
b/libavfilter/dnn/dnn_backend_native.c
index 82e900b..09c583b 100644
--- a/libavfilter/dnn/dnn_backend_native.c
+++ b/libavfilter/dnn/dnn_backend_native.c
@@ -25,6 +25,7 @@
 
 #include "dnn_backend_native.h"
 #include "libavutil/avassert.h"
+#include "dnn_backend_native_layer_pad.h"
 
 static DNNReturnType set_input_output_native(void *model, DNNInputData *input, 
const char *input_name, const char **output_names, uint32_t nb_output)
 {
@@ -32,6 +33,7 @@ static DNNReturnType set_input_output_native(void *model, 
DNNInputData *input, c
 InputParams *input_params;
 ConvolutionalParams *conv_params;
 DepthToSpaceParams *depth_to_space_params;
+LayerPadParams *pad_params;
 int cur_width, cur_height, cur_channels;
 int32_t layer;
 
@@ -77,6 +79,12 @@ static DNNReturnType set_input_output_native(void *model, 
DNNInputData *input, c
 cur_height *= depth_to_space_params->block_size;
 cur_width *= depth_to_space_params->block_size;
 break;
+case MIRROR_PAD:
+pad_params = (LayerPadParams *)network->layers[layer].params;
+cur_height = cur_height + pad_params->paddings[1][0] + 
pad_params->paddings[1][1];
+cur_width = cur_width + pad_params->paddings[2][0] + 
pad_params->paddings[2][1];
+cur_channels = cur_channels + pad_params->paddings[3][0] + 
pad_params->paddings[3][1];
+break;
 default:
 return DNN_ERROR;
 }
@@ -110,6 +118,7 @@ DNNModel *ff_dnn_load_model_native(const char 
*model_filename)
 DNNLayerType layer_type;
 ConvolutionalParams *conv_params;
 DepthToSpaceParams *depth_to_space_params;
+LayerPadParams *pad_params;
 
 model = av_malloc(sizeof(DNNModel));
 if (!model){
@@ -207,6 +216,23 @@ DNNModel *ff_dnn_load_model_native(const char 
*model_filename)
 network->layers[layer].type = DEPTH_TO_SPACE;
 network->layers[layer].params = depth_to_space_params;
 break;
+case MIRROR_PAD:
+pad_params = av_malloc(sizeof(LayerPadParams));
+if (!pad_params){
+avio_closep(&model_file_context);
+ff_dnn_free_model_native(&model);
+return NULL;
+}
+pad_params->mode = (int32_t)avio_rl32(model_file_context);
+dnn_size += 4;
+for (i = 0; i < 4; ++i) {
+pad_params->paddings[i][0] = avio_rl32(model_file_context);
+pad_params->paddings[i][1] = avio_rl32(model_file_context);
+dnn_size += 8;
+}
+network->layers[layer].type = MIRROR_PAD;
+network->layers[layer].params = pad_params;
+break;
 default:
 avio_closep(&model_file_context);
 ff_dnn_free_model_native(&model);
@@ -314,6 +340,7 @@ DNNReturnType ff_dnn_execute_model_native(const DNNModel 
*model, DNNData *output
 InputParams *input_params;
 ConvolutionalParams *conv_params;
 DepthToSpaceParams *depth_to_space_params;
+LayerPadParams *pad_params;
 
 if (network->layers_num <= 0 || network->layers[0].type != INPUT || 
!network->layers[0].output){
 return DNN_ERROR;
@@ -348,6 +375,14 @@ DNNReturnType ff_dnn_execute_model_native(const DNNModel 
*model, DNNData *output
 cur_width *= depth_to_space_params->block_size;
 cur_channels /= depth_to_space_params->block_size * 
depth_to_space_params->block_size;
 break;
+case MIRROR_PAD:
+pad_params = (LayerPadParams *)network->layers[layer].params;
+dnn_execute_layer_pad(network->layers[layer - 1].output, 
network->layers[layer].output,
+  pad_params, 1, cur_height, cur_width, 
cur_channels);
+cur_height = cur_height + pad_params->paddings[1][0] + 
pad_params->paddings[1][1];
+cur_width = cur_width + pad_params->paddings[2][0] + 
pad_params->paddings[2][1];
+cur_channels = cur_channels + pad_params->paddings[3][0] + 
pad_params->paddings[3][1];
+break;
 case INPUT:
 return DNN_ERROR;
 }
diff --git a/libavfilter/dnn/dnn_backend_native.h 
b/libavfilter/dnn/dnn_backend_native.h
index 8ef1855..b6f9533 100644
--- a/libavfilter/dnn/dnn_backend_native.h
+++ b/libavfilter/dnn/dnn_backend_native.h
@@ -30,7 +30,7 @@
 #include "../dnn_interface.h"
 #include "libavformat/avio.h"
 
-typedef enum {INPUT, CONV, DEPTH_TO_SPACE} DNNLayerType;
+typedef enum {INPUT, CONV, DEPTH_TO_SPACE

[FFmpeg-devel] [PATCH] avfilter/fade: don't allow nb_frames == 0

[Gyan]

Fixes crash when user inputs a sub-unit fractional number for nb_frames.

Gyan
From b3e463c6514eabb1081a22e32dce33d62f5278ce Mon Sep 17 00:00:00 2001
From: Gyan Doshi 
Date: Mon, 29 Jul 2019 10:53:12 +0530
Subject: [PATCH] avfilter/fade: don't allow nb_frames == 0

In filter init, there's a division by nb_frames but value isn't checked.
---
 libavfilter/vf_fade.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavfilter/vf_fade.c b/libavfilter/vf_fade.c
index 17eca109b6..bec765a09e 100644
--- a/libavfilter/vf_fade.c
+++ b/libavfilter/vf_fade.c
@@ -381,9 +381,9 @@ static const AVOption fade_options[] = {
 { "s",   "Number of the first frame to which to apply the effect.",
 OFFSET(start_frame), 
AV_OPT_TYPE_INT, { .i64 = 0 }, 0, INT_MAX, FLAGS },
 { "nb_frames",   "Number of frames to which the effect should be applied.",
-OFFSET(nb_frames),   
AV_OPT_TYPE_INT, { .i64 = 25 }, 0, INT_MAX, FLAGS },
+OFFSET(nb_frames),   
AV_OPT_TYPE_INT, { .i64 = 25 }, 1, INT_MAX, FLAGS },
 { "n",   "Number of frames to which the effect should be applied.",
-OFFSET(nb_frames),   
AV_OPT_TYPE_INT, { .i64 = 25 }, 0, INT_MAX, FLAGS },
+OFFSET(nb_frames),   
AV_OPT_TYPE_INT, { .i64 = 25 }, 1, INT_MAX, FLAGS },
 { "alpha",   "fade alpha if it is available on the input", 
OFFSET(alpha),   AV_OPT_TYPE_BOOL, {.i64 = 0}, 0,   1, FLAGS },
 { "start_time",  "Number of seconds of the beginning of the effect.",
 OFFSET(start_time),  
AV_OPT_TYPE_DURATION, {.i64 = 0. }, 0, INT64_MAX, FLAGS },
-- 
2.22.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] [PATCH v15 1/2] lavc/svt_hevc: add libsvt hevc encoder wrapper

[Jing Sun]

Signed-off-by: Zhengxu Huang 
Signed-off-by: Hassene Tmar 
Signed-off-by: Jun Zhao 
Signed-off-by: Jing Sun 
---
 configure|   4 +
 libavcodec/Makefile  |   1 +
 libavcodec/allcodecs.c   |   1 +
 libavcodec/libsvt_hevc.c | 501 +++
 libavcodec/version.h |   2 +-
 5 files changed, 508 insertions(+), 1 deletion(-)
 create mode 100644 libavcodec/libsvt_hevc.c

diff --git a/configure b/configure
index 7cea9d4..8f2f065 100755
--- a/configure
+++ b/configure
@@ -264,6 +264,7 @@ External library support:
   --enable-libspeexenable Speex de/encoding via libspeex [no]
   --enable-libsrt  enable Haivision SRT protocol via libsrt [no]
   --enable-libssh  enable SFTP protocol via libssh [no]
+  --enable-libsvthevc  enable HEVC encoding via svt [no]
   --enable-libtensorflow   enable TensorFlow as a DNN module backend
for DNN based filters like sr [no]
   --enable-libtesseractenable Tesseract, needed for ocr filter [no]
@@ -1787,6 +1788,7 @@ EXTERNAL_LIBRARY_LIST="
 libspeex
 libsrt
 libssh
+libsvthevc
 libtensorflow
 libtesseract
 libtheora
@@ -3180,6 +3182,7 @@ libshine_encoder_select="audio_frame_queue"
 libspeex_decoder_deps="libspeex"
 libspeex_encoder_deps="libspeex"
 libspeex_encoder_select="audio_frame_queue"
+libsvt_hevc_encoder_deps="libsvthevc"
 libtheora_encoder_deps="libtheora"
 libtwolame_encoder_deps="libtwolame"
 libvo_amrwbenc_encoder_deps="libvo_amrwbenc"
@@ -6226,6 +6229,7 @@ enabled libsoxr   && require libsoxr soxr.h 
soxr_create -lsoxr
 enabled libssh&& require_pkg_config libssh libssh libssh/sftp.h 
sftp_init
 enabled libspeex  && require_pkg_config libspeex speex speex/speex.h 
speex_decoder_init
 enabled libsrt&& require_pkg_config libsrt "srt >= 1.3.0" 
srt/srt.h srt_socket
+enabled libsvthevc&& require_pkg_config libsvthevc SvtHevcEnc EbApi.h 
EbInitHandle
 enabled libtensorflow && require libtensorflow tensorflow/c/c_api.h 
TF_Version -ltensorflow
 enabled libtesseract  && require_pkg_config libtesseract tesseract 
tesseract/capi.h TessBaseAPICreate
 enabled libtheora && require libtheora theora/theoraenc.h th_info_init 
-ltheoraenc -ltheoradec -logg
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index edccd73..7eb13de 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -991,6 +991,7 @@ OBJS-$(CONFIG_LIBOPUS_ENCODER)+= libopusenc.o 
libopus.o \
 OBJS-$(CONFIG_LIBSHINE_ENCODER)   += libshine.o
 OBJS-$(CONFIG_LIBSPEEX_DECODER)   += libspeexdec.o
 OBJS-$(CONFIG_LIBSPEEX_ENCODER)   += libspeexenc.o
+OBJS-$(CONFIG_LIBSVT_HEVC_ENCODER)+= libsvt_hevc.o
 OBJS-$(CONFIG_LIBTHEORA_ENCODER)  += libtheoraenc.o
 OBJS-$(CONFIG_LIBTWOLAME_ENCODER) += libtwolame.o
 OBJS-$(CONFIG_LIBVO_AMRWBENC_ENCODER) += libvo-amrwbenc.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index d2f9a39..d8788a7 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -707,6 +707,7 @@ extern AVCodec ff_librsvg_decoder;
 extern AVCodec ff_libshine_encoder;
 extern AVCodec ff_libspeex_encoder;
 extern AVCodec ff_libspeex_decoder;
+extern AVCodec ff_libsvt_hevc_encoder;
 extern AVCodec ff_libtheora_encoder;
 extern AVCodec ff_libtwolame_encoder;
 extern AVCodec ff_libvo_amrwbenc_encoder;
diff --git a/libavcodec/libsvt_hevc.c b/libavcodec/libsvt_hevc.c
new file mode 100644
index 000..d9ac04c
--- /dev/null
+++ b/libavcodec/libsvt_hevc.c
@@ -0,0 +1,501 @@
+/*
+* Scalable Video Technology for HEVC encoder library plugin
+*
+* Copyright (c) 2019 Intel Corporation
+*
+* This file is part of FFmpeg.
+*
+* FFmpeg is free software; you can redistribute it and/or
+* modify it under the terms of the GNU Lesser General Public
+* License as published by the Free Software Foundation; either
+* version 2.1 of the License, or (at your option) any later version.
+*
+* FFmpeg is distributed in the hope that it will be useful,
+* but WITHOUT ANY WARRANTY; without even the implied warranty of
+* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+* Lesser General Public License for more details.
+*
+* You should have received a copy of the GNU Lesser General Public
+* License along with this program; if not, write to the Free Software
+* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+*/
+
+#include "EbErrorCodes.h"
+#include "EbTime.h"
+#include "EbApi.h"
+
+#include "libavutil/common.h"
+#include "libavutil/frame.h"
+#include "libavutil/opt.h"
+
+#include "internal.h"
+#include "avcodec.h"
+
+typedef enum eos_status {
+EOS_NOT_REACHED = 0,
+EOS_SENT,
+EOS_RECEIVED
+}EOS_STATUS;
+
+typedef struct SvtContext {
+AVClass *class;
+
+EB_H265_ENC_CONFIGURATION enc_params;
+EB_COMPONENTTYPE *svt_handle;
+EB_BUFFERHEADERTYPE in_buf;
+EOS_STATUS eos_flag;
+

Re: [FFmpeg-devel] [PATCH 1/3] avcodec/eatgv: Check remaining size after the keyframe header

[Paul B Mahol]

LGTM

On Mon, Jul 29, 2019 at 1:11 AM Michael Niedermayer 
wrote:

> The minimal size which unpack() will not fail on is 5 bytes
> Fixes: Timeout (14sec -> 77ms) (testcase 15508)
> Fixes:
> 15508/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_EATGV_fuzzer-5700053513011200
> Fixes:
> 15996/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_EATGV_fuzzer-5751353223151616
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by
> :
> Michael Niedermayer 
> ---
>  libavcodec/eatgv.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/libavcodec/eatgv.c b/libavcodec/eatgv.c
> index 93e291f053..77b5da1f14 100644
> --- a/libavcodec/eatgv.c
> +++ b/libavcodec/eatgv.c
> @@ -300,6 +300,10 @@ static int tgv_decode_frame(AVCodecContext *avctx,
>  s->palette[i] = 0xFFU << 24 | AV_RB24(buf);
>  buf += 3;
>  }
> +if (buf_end - buf < 5) {
> +av_log(avctx, AV_LOG_WARNING, "packed data truncated\n");
> +return AVERROR_INVALIDDATA;
> +}
>  }
>
>  if ((ret = ff_get_buffer(avctx, frame, AV_GET_BUFFER_FLAG_REF)) < 0)
> --
> 2.22.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 v15 1/2] lavc/svt_hevc: add libsvt hevc encoder wrapper

[Sun, Jing A]

The just updated one fixed such typo:
  .pix_fmts   = (const enum AVPixelFormat[]){ AV_PIX_FMT_YUV420P,
  AV_PIX_FMT_YUV420P10,
  AV_PIX_FMT_YUV422P,
- AV_PIX_FMT_YUV420P10,
+AV_PIX_FMT_YUV422P10,
  AV_PIX_FMT_YUV444P,
  AV_PIX_FMT_YUV444P10,
  AV_PIX_FMT_NONE },

Regards,
Sun, Jing
___
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] avcodec/eatgv: Check remaining size after the keyframe header

[Paul B Mahol]

Actually remove log message completely. It is invalid because it is warning
while you return error immediately.

On Mon, Jul 29, 2019 at 8:48 AM Paul B Mahol  wrote:

> LGTM
>
> On Mon, Jul 29, 2019 at 1:11 AM Michael Niedermayer 
> wrote:
>
>> The minimal size which unpack() will not fail on is 5 bytes
>> Fixes: Timeout (14sec -> 77ms) (testcase 15508)
>> Fixes:
>> 15508/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_EATGV_fuzzer-5700053513011200
>> Fixes:
>> 15996/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_EATGV_fuzzer-5751353223151616
>>
>> Found-by: continuous fuzzing process
>> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>> Signed-off-by
>> :
>> Michael Niedermayer 
>> ---
>>  libavcodec/eatgv.c | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/libavcodec/eatgv.c b/libavcodec/eatgv.c
>> index 93e291f053..77b5da1f14 100644
>> --- a/libavcodec/eatgv.c
>> +++ b/libavcodec/eatgv.c
>> @@ -300,6 +300,10 @@ static int tgv_decode_frame(AVCodecContext *avctx,
>>  s->palette[i] = 0xFFU << 24 | AV_RB24(buf);
>>  buf += 3;
>>  }
>> +if (buf_end - buf < 5) {
>> +av_log(avctx, AV_LOG_WARNING, "packed data truncated\n");
>> +return AVERROR_INVALIDDATA;
>> +}
>>  }
>>
>>  if ((ret = ff_get_buffer(avctx, frame, AV_GET_BUFFER_FLAG_REF)) < 0)
>> --
>> 2.22.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] libavformat/mpegtsenc: fix incorrect PCR with multiple programs [v3]

[Andriy Gelman]

Andreas,

On Sun, 28. Jul 19:07, Andreas Håkon wrote:
> Hi,
> 
> This last version fixes the small bug discovered by Michael Niedermayer:
> https://patchwork.ffmpeg.org/patch/14099/
> 
> This version is finally clean.
> 
> Regards.
> A.H.
> 
> ---

> From 08565b81aa2b6d75043e5e984da143480891c3b0 Mon Sep 17 00:00:00 2001
> From: Andreas Hakon 
> Date: Sun, 28 Jul 2019 19:59:51 +0100
> Subject: [PATCH] libavformat/mpegtsenc: fix incorrect PCR with multiple
>  programs [v3]
> 
> The MPEG-TS muxer has a serious bug related to the PCR pid selection.
> This bug appears when more than one program is used. The root cause is because
> the current code targets only one program when selecting the stream for the 
> PCR.

I'd suggest to update the commit message because pid selection is not the main
issue. 

> 
> This patch solves this problem and select correct streams for each program.
> Furthermore, it passes all the checks and doesn't generate any regression.
> 
> You can check it with this command:
> 
> $ ./ffmpeg -loglevel verbose -y -f data -i /dev/zero \
>  -filter_complex "nullsrc=s=60x60,split=2[v0][v1],anullsrc[a]" \
>  -map [v0] -c:v:0 rawvideo \
>  -map [v1] -c:v:1 rawvideo \
>  -map [a]  -c:a:0 pcm_s8 \
>  -program st=0 -program st=1 -program st=2 -f mpegts out.ts
> 
> And you will see something like:
> 
> [mpegts @ 0x562f388cd800] service 1 using PCR in pid=256
> [mpegts @ 0x562f388cd800] service 2 using PCR in pid=257
> [mpegts @ 0x562f388cd800] service 3 using PCR in pid=258
> 
> 
> Signed-off-by: Andreas Hakon 
> ---
>  libavformat/mpegtsenc.c |  103 
> ---
>  1 file changed, 62 insertions(+), 41 deletions(-)
> 
> diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
> index fc0ea22..fc340cd 100644
> --- a/libavformat/mpegtsenc.c
> +++ b/libavformat/mpegtsenc.c
> @@ -60,6 +60,7 @@ typedef struct MpegTSService {
>  int pcr_packet_count;
>  int pcr_packet_period;
>  AVProgram *program;
> +AVStream *pcr_st;
>  } MpegTSService;
>  
>  // service_type values as defined in ETSI 300 468
> @@ -774,7 +775,7 @@ static int mpegts_init(AVFormatContext *s)
>  MpegTSWrite *ts = s->priv_data;
>  MpegTSWriteStream *ts_st;
>  MpegTSService *service;
> -AVStream *st, *pcr_st = NULL;
> +AVStream *st;
>  AVDictionaryEntry *title, *provider;
>  int i, j;
>  const char *service_name;
> @@ -831,6 +832,11 @@ static int mpegts_init(AVFormatContext *s)
>  }
>  }
>  
> +for (i = 0; i < ts->nb_services; i++) {
> +service = ts->services[i];
> +service->pcr_st = NULL;
> +}
> +
>  ts->pat.pid  = PAT_PID;
>  /* Initialize at 15 so that it wraps and is equal to 0 for the
>   * first packet we write. */
> @@ -917,7 +923,12 @@ static int mpegts_init(AVFormatContext *s)
>  if (st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO &&
>  service->pcr_pid == 0x1fff) {
>  service->pcr_pid = ts_st->pid;
> -pcr_st   = st;
> +service->pcr_st  = st;
> +}
> +/* store this stream as a candidate PCR if the service doesn't have 
> any */
> +if (service->pcr_pid == 0x1fff &&
> +!service->pcr_st) {
> +service->pcr_st  = st;
>  }
>  if (st->codecpar->codec_id == AV_CODEC_ID_AAC &&
>  st->codecpar->extradata_size > 0) {
> @@ -951,50 +962,62 @@ static int mpegts_init(AVFormatContext *s)
>  }
>  }
>  
> -av_freep(&pids);
> +for (i = 0; i < ts->nb_services; i++) {
> +service = ts->services[i];
>  
> -/* if no video stream, use the first stream as PCR */
> -if (service->pcr_pid == 0x1fff && s->nb_streams > 0) {
> -pcr_st   = s->streams[0];
> -ts_st= pcr_st->priv_data;
> -service->pcr_pid = ts_st->pid;
> -} else
> -ts_st = pcr_st->priv_data;
> -
> -if (ts->mux_rate > 1) {
> -service->pcr_packet_period = (int64_t)ts->mux_rate * ts->pcr_period /
> - (TS_PACKET_SIZE * 8 * 1000);
> -ts->sdt_packet_period  = (int64_t)ts->mux_rate * 
> SDT_RETRANS_TIME /
> - (TS_PACKET_SIZE * 8 * 1000);
> -ts->pat_packet_period  = (int64_t)ts->mux_rate * 
> PAT_RETRANS_TIME /
> - (TS_PACKET_SIZE * 8 * 1000);
> -
> -if (ts->copyts < 1)
> -ts->first_pcr = av_rescale(s->max_delay, PCR_TIME_BASE, 
> AV_TIME_BASE);
> -} else {
> -/* Arbitrary values, PAT/PMT will also be written on video key 
> frames */
> -ts->sdt_packet_period = 200;
> -ts->pat_packet_period = 40;
> -if (pcr_st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO) {
> -int frame_size = av_get_audio_frame_duration2(pcr_st->codecpar, 
> 0);
> -if (!frame_size) {
> -av_log(s, AV_LOG_WARNING, "frame size not set\n");
>

Re: [FFmpeg-devel] [PATCH] avfilter/fade: don't allow nb_frames == 0

[Paul B Mahol]

LGTM

On Mon, Jul 29, 2019 at 7:30 AM Gyan  wrote:

>
> Fixes crash when user inputs a sub-unit fractional number for nb_frames.
>
> Gyan
> ___
> 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 2/3] avcodec/eatqi: Check for minimum frame size

[Paul B Mahol]

LGTM

On Mon, Jul 29, 2019 at 1:11 AM Michael Niedermayer 
wrote:

> The minimum header is 8 bytes, the smallest bitstream that is passed to
> the MB decode code is 4 bytes
>
> Fixes: Timeout (35sec -> 18sec)
> Fixes:
> 15800/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_EATQI_fuzzer-5684154517159936
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by
> :
> Michael Niedermayer 
> ---
>  libavcodec/eatqi.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/libavcodec/eatqi.c b/libavcodec/eatqi.c
> index 0002d45457..96536b1a08 100644
> --- a/libavcodec/eatqi.c
> +++ b/libavcodec/eatqi.c
> @@ -131,6 +131,9 @@ static int tqi_decode_frame(AVCodecContext *avctx,
>  AVFrame *frame = data;
>  int ret, w, h;
>
> +if (buf_size < 12)
> +return AVERROR_INVALIDDATA;
> +
>  t->avctx = avctx;
>
>  w = AV_RL16(&buf[0]);
> --
> 2.22.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".