Re: [FFmpeg-devel] [PATCH v1] libavutil: add A2R10G10B10 & A2B10G10R10

[Zhou, Zachary]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Carl
> Eugen Hoyos
> Sent: Wednesday, September 11, 2019 7:30 AM
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] [PATCH v1] libavutil: add A2R10G10B10 &
> A2B10G10R10
> 
> Am Di., 10. Sept. 2019 um 11:35 Uhr schrieb Zachary Zhou
> :
> >
> > ---
> >  libavutil/hwcontext_vaapi.c | 6 ++
> >  libavutil/pixfmt.h  | 3 +++
> >  2 files changed, 9 insertions(+)
> >
> > diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
> > index cf117640f2..9838250b66 100644
> > --- a/libavutil/hwcontext_vaapi.c
> > +++ b/libavutil/hwcontext_vaapi.c
> > @@ -125,6 +125,12 @@ static const VAAPIFormatDescriptor
> > vaapi_format_map[] = {  #endif
> >  MAP(BGRA, RGB32,   BGRA, 0),
> >  MAP(BGRX, RGB32,   BGR0, 0),
> > +#ifdef VA_FOURCC_A2R10G10B10
> > +MAP(A2R10G10B10, RGB32_10, A2R10G10B10, 0), #endif #ifdef
> > +VA_FOURCC_A2B10G10R10
> > +MAP(A2B10G10R10, RGB32_10, A2B10G10R10, 0), #endif
> >  MAP(RGBA, RGB32,   RGBA, 0),
> >  MAP(RGBX, RGB32,   RGB0, 0),
> >  #ifdef VA_FOURCC_ABGR
> > diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h index
> > d78e863d4b..e00f129b46 100644
> > --- a/libavutil/pixfmt.h
> > +++ b/libavutil/pixfmt.h
> > @@ -348,6 +348,9 @@ enum AVPixelFormat {
> >  AV_PIX_FMT_NV24,  ///< planar YUV 4:4:4, 24bpp, 1 plane for Y and 1
> plane for the UV components, which are interleaved (first byte U and the
> following byte V)
> >  AV_PIX_FMT_NV42,  ///< as above, but U and V bytes are swapped
> >
> > +AV_PIX_FMT_A2R10G10B10, ///< 10-bit Pixel RGB formats.
> > +AV_PIX_FMT_A2B10G10R10, ///< 10-bit Pixel BGR formats.
> 
> The patch looks insufficient, see the patch to add AYUV and other packed
> formats.

Thank you for the review, I will refer these patches.

> 
> The more important question imo is: Why are these formats needed, which
> hardware produces them for which input?

These formats target to Intel Ice Lake platform. will be use in HDR tone 
mapping filter.
input is P010.

welcome to review my HDR patch: https://patchwork.ffmpeg.org/patch/15018/
I appreciate any comments.

-Zachary

> 
> Carl Eugen
> ___
> 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 v4 1/2] libavuitl: add A2R10G10B10 & A2B10G10R10

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Zachary Zhou
> Sent: Wednesday, September 11, 2019 13:40
> To: ffmpeg-devel@ffmpeg.org
> Cc: Zhou, Zachary 
> Subject: [FFmpeg-devel] [PATCH v4 1/2] libavuitl: add A2R10G10B10 &
> A2B10G10R10
> 
> ---
>  libavutil/hwcontext_vaapi.c | 6 ++
>  libavutil/pixfmt.h  | 3 +++
>  2 files changed, 9 insertions(+)

Didn't see the difference compared with your V1 patch:
https://patchwork.ffmpeg.org/patch/14998/

Is there something mixed up?

- linjie
___
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 2/2] avfilter: Add tonemap vaapi filter

[Zachary Zhou]

It supports ICL platform.
H2H (HDR to HDR): P010 -> A2R10G10B10
H2S (HDR to SDR): P010 -> ARGB
---
 configure  |   2 +
 doc/filters.texi   |  72 +
 libavfilter/Makefile   |   1 +
 libavfilter/allfilters.c   |   1 +
 libavfilter/vaapi_vpp.c|   5 +
 libavfilter/vf_tonemap_vaapi.c | 575 +
 6 files changed, 656 insertions(+)
 create mode 100644 libavfilter/vf_tonemap_vaapi.c

diff --git a/configure b/configure
index 8413826f9e..c9bd4bfcd8 100755
--- a/configure
+++ b/configure
@@ -3551,6 +3551,7 @@ tinterlace_merge_test_deps="tinterlace_filter"
 tinterlace_pad_test_deps="tinterlace_filter"
 tonemap_filter_deps="const_nan"
 tonemap_opencl_filter_deps="opencl const_nan"
+tonemap_vaapi_filter_deps="vaapi 
VAProcPipelineParameterBuffer_output_hdr_metadata"
 transpose_opencl_filter_deps="opencl"
 transpose_vaapi_filter_deps="vaapi VAProcPipelineCaps_rotation_flags"
 unsharp_opencl_filter_deps="opencl"
@@ -6544,6 +6545,7 @@ if enabled vaapi; then
 
 check_type "va/va.h va/va_dec_hevc.h" "VAPictureParameterBufferHEVC"
 check_struct "va/va.h" "VADecPictureParameterBufferVP9" bit_depth
+check_struct "va/va.h va/va_vpp.h" "VAProcPipelineParameterBuffer" 
output_hdr_metadata
 check_struct "va/va.h va/va_vpp.h" "VAProcPipelineCaps" rotation_flags
 check_type "va/va.h va/va_enc_hevc.h" "VAEncPictureParameterBufferHEVC"
 check_type "va/va.h va/va_enc_jpeg.h" "VAEncPictureParameterBufferJPEG"
diff --git a/doc/filters.texi b/doc/filters.texi
index 9d500e44a9..3a3e259f8d 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -20140,6 +20140,78 @@ Convert HDR(PQ/HLG) video to 
bt2020-transfer-characteristic p010 format using li
 @end example
 @end itemize
 
+@section tonemap_vappi
+
+Perform HDR(High Dynamic Range) to HDR and HDR to SDR conversion with 
tone-mapping.
+It maps the dynamic range of HDR10 content to the dynamic range of the
+display panel.
+
+It accepts the following parameters:
+
+@table @option
+@item type
+Specify the tone-mapping operator to be used.
+
+Possible values are:
+@table @var
+@item h2h
+Perform H2H(HDR to HDR), convert from p010 to r10g10b10a2
+@item h2s
+Perform H2S(HDR to SDR), convert from p010 to argb
+@end table
+
+@item display
+Set mastering display metadata for H2H
+
+Can assume the following values:
+@table @var
+@item G
+Green primary G(x|y).
+The value for x and y shall be in the range of 0 to 5 inclusive.
+@item B
+Blue primary B(x|y).
+The value for x and y shall be in the range of 0 to 5 inclusive.
+@item R
+Red primary R(x|y).
+The value for x and y shall be in the range of 0 to 5 inclusive.
+@item WP
+White point WP(x|y).
+The value for x and y shall be in the range of 0 to 5 inclusive.
+@item L
+Display mastering luminance L(min|max).
+The value is in units of 0.0001 candelas per square metre.
+@end table
+
+@item light
+Set content light level for H2H
+
+Can assume the following values:
+@table @var
+@item CLL
+Max content light level.
+The value is in units of 0.0001 candelas per square metre.
+@item FALL
+Max average light level per frame.
+The value is in units of 0.0001 candelas per square metre.
+@end table
+
+@end table
+
+@subsection Example
+
+@itemize
+@item
+Convert HDR video to HDR video from p010 format to r10g10b10a format.
+@example
+-i INPUT -vf 
"tonemap_vaapi=h2h:display=G(13250|34500)B(7500|3000)R(34000|16000)WP(15635|16450)L(2000|12000):light=CLL(1)FALL(1000)"
 OUTPUT
+@end example
+@item
+Convert HDR video to SDR video from p010 format to argb format.
+@example
+-i INPUT -vf "tonemap_vaapi=h2s" OUTPUT
+@end example
+@end itemize
+
 @section unsharp_opencl
 
 Sharpen or blur the input video.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 3ef4191d9a..2d0151b182 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -401,6 +401,7 @@ OBJS-$(CONFIG_TMIX_FILTER)   += vf_mix.o 
framesync.o
 OBJS-$(CONFIG_TONEMAP_FILTER)+= vf_tonemap.o colorspace.o
 OBJS-$(CONFIG_TONEMAP_OPENCL_FILTER) += vf_tonemap_opencl.o 
colorspace.o opencl.o \
 opencl/tonemap.o 
opencl/colorspace_common.o
+OBJS-$(CONFIG_TONEMAP_VAAPI_FILTER)  += vf_tonemap_vaapi.o vaapi_vpp.o
 OBJS-$(CONFIG_TPAD_FILTER)   += vf_tpad.o
 OBJS-$(CONFIG_TRANSPOSE_FILTER)  += vf_transpose.o
 OBJS-$(CONFIG_TRANSPOSE_NPP_FILTER)  += vf_transpose_npp.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index b675c688ee..f0da9ac16e 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -381,6 +381,7 @@ extern AVFilter ff_vf_tlut2;
 extern AVFilter ff_vf_tmix;
 extern AVFilter ff_vf_tonemap;
 extern AVFilter ff_vf_tonemap_opencl;
+extern AVFilter ff_vf_tonemap_vaapi;
 extern AVFilter ff_vf_tpad;
 extern AVFilter ff_vf_transpose;
 extern AVFilter ff_vf_transpose_npp;
diff --git a/libavfilter/vaapi_vpp.c 

[FFmpeg-devel] [PATCH v4 1/2] libavuitl: add A2R10G10B10 & A2B10G10R10

[Zachary Zhou]

---
 libavutil/hwcontext_vaapi.c | 6 ++
 libavutil/pixfmt.h  | 3 +++
 2 files changed, 9 insertions(+)

diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index cf117640f2..9838250b66 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -125,6 +125,12 @@ static const VAAPIFormatDescriptor vaapi_format_map[] = {
 #endif
 MAP(BGRA, RGB32,   BGRA, 0),
 MAP(BGRX, RGB32,   BGR0, 0),
+#ifdef VA_FOURCC_A2R10G10B10
+MAP(A2R10G10B10, RGB32_10, A2R10G10B10, 0),
+#endif
+#ifdef VA_FOURCC_A2B10G10R10
+MAP(A2B10G10R10, RGB32_10, A2B10G10R10, 0),
+#endif
 MAP(RGBA, RGB32,   RGBA, 0),
 MAP(RGBX, RGB32,   RGB0, 0),
 #ifdef VA_FOURCC_ABGR
diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
index d78e863d4b..e00f129b46 100644
--- a/libavutil/pixfmt.h
+++ b/libavutil/pixfmt.h
@@ -348,6 +348,9 @@ enum AVPixelFormat {
 AV_PIX_FMT_NV24,  ///< planar YUV 4:4:4, 24bpp, 1 plane for Y and 1 
plane for the UV components, which are interleaved (first byte U and the 
following byte V)
 AV_PIX_FMT_NV42,  ///< as above, but U and V bytes are swapped
 
+AV_PIX_FMT_A2R10G10B10, ///< 10-bit Pixel RGB formats.
+AV_PIX_FMT_A2B10G10R10, ///< 10-bit Pixel BGR formats.
+
 AV_PIX_FMT_NB ///< number of pixel formats, DO NOT USE THIS if you 
want to link with shared libav* because the number of formats might differ 
between versions
 };
 
-- 
2.17.1

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

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

Re: [FFmpeg-devel] [PATCH 2/6] swscale: add swscale support for 422/444 decode outputs

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: Wednesday, September 11, 2019 03:32
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 2/6] swscale: add swscale support for
> 422/444 decode outputs
> 
> Am Di., 10. Sept. 2019 um 18:09 Uhr schrieb Linjie Fu :
> 
> > --- a/libswscale/output.c
> > +++ b/libswscale/output.c
> > @@ -2403,6 +2403,53 @@ yuv2ya8_X_c(SwsContext *c, const int16_t
> *lumFilter,
> >  }
> >
> >  static void
> > +yuv2ayuv_X_c(SwsContext *c, const int16_t *lumFilter,
> > + const int16_t **lumSrc, int lumFilterSize,
> > + const int16_t *chrFilter, const int16_t **chrUSrc,
> > + const int16_t **chrVSrc, int chrFilterSize,
> > + const int16_t **alpSrc, uint8_t *dest, int dstW, int y)
> 
> The commit message does not match this change.
> Do I understand correctly that encoding is expected from AYUV
> but not from the other formats?
> Or is this the result of an earlier comment?

+[AV_PIX_FMT_Y210BE]  = { 1, 0 },
+[AV_PIX_FMT_Y210LE]  = { 1, 0 },
+[AV_PIX_FMT_AYUV]= { 1, 1 },

This patch aims at adding swscale input support  for Y210/AYUV and
output/encoding support for AYUV only.

IMHO swscale input support for these packed pixel format is good 
at current stage.(since there is no requirement for software
CSC to these packed pixel formats)

For Y410, it's kind of different:
https://docs.microsoft.com/en-us/windows/win32/medfound/10-bit-and-16-bit-yuv-video-formats#y410

Bits 0-9 contain the U sample, bits 10-19 contain the Y sample, bits 20-29
contain the V sample, and bits 30-31 contain the alpha value.

Some attempts have been made locally to support swscale input for Y410:
https://github.com/fulinjie/ffmpeg/commits/pr-y410

And I think the swscale input support for Y410 could be held.

> I don't know if splitting the patch would make it clearer.
Sure, will split it for each pixel format.

Regards,
Linjie


___
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/6] lavu/pixfmt: add new pixel format ayuv/y210/y410

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: Wednesday, September 11, 2019 03:25
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 1/6] lavu/pixfmt: add new pixel format
> ayuv/y210/y410
> 
> Am Di., 10. Sept. 2019 um 18:08 Uhr schrieb Linjie Fu :
> >
> > Add some packed pixel formats for hardware decode support
> > in VAAPI and QSV:
> >
> > 4:2:2 10 bit: Y210
> > 4:4:4  8 bit: AYUV
> > 4:4:4 10 bit: Y410
> 
> Please add a short explanation (either in the commit message or
> only in this thread) for which kind of samples these pixel formats
> are needed.
> 
> Or to say it differently: Why is the hardware outputting planar
> formats for some samples and packed for others?

I kind of remember that it was discussed in previous patch thread:
Previously, media driver provided planar format(like 420 8 bit),
but for HEVC Range Extension (422/444 8/10 bit), the decoded image
is produced in packed format. And the reason is " because Windows
expects it" as you have pointed.

It could be updated in the commit message if this is good enough.

> I see you added LE and BE versions: Why are both needed?
> And if they are needed, why is there only AYUV and not AYUV
> and VUYA?

I noticed LE and BE versions are added for some of the added pixel
format, out of the compatibility for big-endian and little-endian(IMHO).
And that's the reason I add it for Y210 and Y410. 

I'm not sure I understood it correctly, LE/BE version is necessary for
newly added pixel format right?

> > Signed-off-by: Linjie Fu 
> > ---
> >  libavutil/pixdesc.c   | 62
> +++
> >  libavutil/pixfmt.h|  9 +++
> >  libavutil/tests/pixfmt_best.c |  1 +
> >  libavutil/version.h   |  2 +-
> >  4 files changed, 73 insertions(+), 1 deletion(-)
> 
> > diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
> > index d78e863..0176a2a 100644
> > --- a/libavutil/pixfmt.h
> > +++ b/libavutil/pixfmt.h
> > @@ -348,6 +348,12 @@ enum AVPixelFormat {
> >  AV_PIX_FMT_NV24,  ///< planar YUV 4:4:4, 24bpp, 1 plane for Y and 1
> plane for the UV components, which are interleaved (first byte U and the
> following byte V)
> >  AV_PIX_FMT_NV42,  ///< as above, but U and V bytes are swapped
> >
> > +AV_PIX_FMT_Y210BE,///< packed YUV 4:2:2, 32bpp, Y0 Cb Y1 Cr, big-
> endian
> > +AV_PIX_FMT_Y210LE,///< packed YUV 4:2:2, 32bpp, Y0 Cb Y1 Cr, 
> > little-
> endian
> 
> I believe they are 16bpp.

Thanks for pointing out this, and since Y210 is a 10 bit 4:2:2 format, IMHO 
20bpp
is expected information. (see AV_PIX_FMT_YUV422P10LE,///< planar YUV 4:2:2, 
20bpp)

Regards,
linjie
___
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 V1 2/4] lavfi/sinc: fix memory leak in error handling path

[myp...@gmail.com]

On Tue, Sep 10, 2019 at 9:06 PM Paul B Mahol  wrote:
>
> lgtm
>
Will apply, 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 V1 1/4] lavfi/anequalizer: fix memory leak in error handling path

[myp...@gmail.com]

On Tue, Sep 10, 2019 at 9:06 PM Paul B Mahol  wrote:
>
> lgtm
>
Will apply, 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 V1 4/4] lavf/mux: remove unnecessary packet reset

[myp...@gmail.com]

On Tue, Sep 10, 2019 at 8:05 PM Andreas Rheinhardt
 wrote:
>
> Jun Zhao:
> > From: Jun Zhao 
> >
> > remove unnecessary packet reset in av_interleaved_write_frame
> >
> > Signed-off-by: Jun Zhao 
> > ---
> >  libavformat/mux.c |6 ++
> >  1 files changed, 2 insertions(+), 4 deletions(-)
> >
> > diff --git a/libavformat/mux.c b/libavformat/mux.c
> > index 0227c0d..9bac252 100644
> > --- a/libavformat/mux.c
> > +++ b/libavformat/mux.c
> > @@ -1227,11 +1227,9 @@ int av_interleaved_write_frame(AVFormatContext *s, 
> > AVPacket *pkt)
> >  for (;; ) {
> >  AVPacket opkt;
> >  int ret = interleave_packet(s, , pkt, flush);
> > -if (pkt) {
> > -memset(pkt, 0, sizeof(*pkt));
> > -av_init_packet(pkt);
> > +if (pkt)
> >  pkt = NULL;
> > -}
> > +
> >  if (ret <= 0) //FIXME cleanup needed for ret<0 ?
> >  return ret;
> >
> I made a patchset [1] (that has already been partially pushed) whose
> patch 11 deals with the memleak that happens on error in the above
> code and also removes the unnecessary packet reset on success.
>
> - Andreas
>
> [1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2019-August/248140.html
> [2]: https://ffmpeg.org/pipermail/ffmpeg-devel/2019-August/248145.html
>
I didn't notice that pathset details, please goto the patchset, will
drop the patch, 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".

[FFmpeg-devel] [PATCH V8] avcodec/libvpxenc: add ROI-based encoding support for VP8/VP9

[Guo, Yejun]

example command line to verify it:
./ffmpeg -i input.stream -vf addroi=0:0:iw/3:ih/3:-0.8 -c:v libvpx -b:v 2M 
tmp.webm

Signed-off-by: Guo, Yejun 
---
 libavcodec/libvpxenc.c | 188 +
 libavcodec/version.h   |   2 +-
 2 files changed, 189 insertions(+), 1 deletion(-)

diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index feb52ea..4e360ca 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -116,6 +116,9 @@ typedef struct VPxEncoderContext {
 int tune_content;
 int corpus_complexity;
 int tpl_model;
+// If the driver does not support ROI then warn the first time we
+// encounter a frame with ROI side data.
+int roi_warned;
 } VPxContext;
 
 /** String mappings for enum vp8e_enc_control_id */
@@ -1057,6 +1060,183 @@ static int queue_frames(AVCodecContext *avctx, AVPacket 
*pkt_out)
 return size;
 }
 
+static int set_roi_map(AVCodecContext *avctx, const AVFrameSideData *sd, int 
frame_width, int frame_height,
+   vpx_roi_map_t *roi_map, int block_size, int segment_cnt)
+{
+/* range of vpx_roi_map_t.delta_q[i] is [-63, 63] */
+#define MAX_DELTA_Q 63
+
+const AVRegionOfInterest *roi = NULL;
+int nb_rois;
+uint32_t self_size;
+int segment_id;
+
+/* record the mapping from delta_q to "segment id + 1" in 
segment_mapping[].
+ * the range of delta_q is [-MAX_DELTA_Q, MAX_DELTA_Q],
+ * and its corresponding array index is [0, 2 * MAX_DELTA_Q],
+ * and so the length of the mapping array is 2 * MAX_DELTA_Q + 1.
+ * "segment id + 1", so we can say there's no mapping if the value of 
array element is zero.
+ */
+int segment_mapping[2 * MAX_DELTA_Q + 1] = { 0 };
+
+memset(roi_map, 0, sizeof(*roi_map));
+
+/* segment id 0 in roi_map is reserved for the areas not covered by 
AVRegionOfInterest.
+ * segment id 0 in roi_map is also for the areas with 
AVRegionOfInterest.qoffset near 0.
+ * (delta_q of segment id 0 is 0).
+ */
+segment_mapping[MAX_DELTA_Q] = 1;
+segment_id = 1;
+
+roi = (const AVRegionOfInterest*)sd->data;
+self_size = roi->self_size;
+if (!self_size || sd->size % self_size != 0) {
+av_log(avctx, AV_LOG_ERROR, "Invalid AVRegionOfInterest.self_size.\n");
+return AVERROR(EINVAL);
+}
+nb_rois = sd->size / self_size;
+
+/* This list must be iterated from zero because regions are
+ * defined in order of decreasing importance. So discard less
+ * important areas if they exceed the segment count.
+ */
+for (int i = 0; i < nb_rois; i++) {
+int delta_q;
+int mapping_index;
+
+roi = (const AVRegionOfInterest*)(sd->data + self_size * i);
+if (roi->qoffset.den == 0) {
+av_log(avctx, AV_LOG_ERROR, "AVRegionOfInterest.qoffset.den must 
not be zero.\n");
+return AVERROR(EINVAL);
+}
+
+delta_q = (int)(roi->qoffset.num * 1.0f / roi->qoffset.den * 
MAX_DELTA_Q);
+delta_q = av_clip(delta_q, -MAX_DELTA_Q, MAX_DELTA_Q);
+
+mapping_index = delta_q + MAX_DELTA_Q;
+if (!segment_mapping[mapping_index]) {
+if (segment_id == segment_cnt) {
+av_log(avctx, AV_LOG_WARNING,
+   "ROI only supports %d segments (and segment 0 is 
reserved for non-ROIs), skipping the left ones.\n",
+   segment_cnt);
+break;
+}
+
+segment_mapping[mapping_index] = segment_id + 1;
+roi_map->delta_q[segment_id] = delta_q;
+segment_id++;
+}
+}
+
+roi_map->rows = (frame_height + block_size - 1) / block_size;
+roi_map->cols = (frame_width  + block_size - 1) / block_size;
+roi_map->roi_map = av_mallocz_array(roi_map->rows * roi_map->cols, 
sizeof(*roi_map->roi_map));
+if (!roi_map->roi_map) {
+av_log(avctx, AV_LOG_ERROR, "roi_map alloc failed.\n");
+return AVERROR(ENOMEM);
+}
+
+/* This list must be iterated in reverse, so for the case that
+ * two regions are overlapping, the more important area takes effect.
+ */
+for (int i = nb_rois - 1; i >= 0; i--) {
+int delta_q;
+int mapping_value;
+int starty, endy, startx, endx;
+
+roi = (const AVRegionOfInterest*)(sd->data + self_size * i);
+
+starty = av_clip(roi->top / block_size, 0, roi_map->rows);
+endy   = av_clip((roi->bottom + block_size - 1) / block_size, 0, 
roi_map->rows);
+startx = av_clip(roi->left / block_size, 0, roi_map->cols);
+endx   = av_clip((roi->right + block_size - 1) / block_size, 0, 
roi_map->cols);
+
+delta_q = (int)(roi->qoffset.num * 1.0f / roi->qoffset.den * 
MAX_DELTA_Q);
+delta_q = av_clip(delta_q, -MAX_DELTA_Q, MAX_DELTA_Q);
+
+mapping_value = segment_mapping[delta_q + MAX_DELTA_Q];
+if (mapping_value) {
+for (int y = starty; y < endy; y++)
+

Re: [FFmpeg-devel] [PATCH V7] avcodec/libvpxenc: add ROI-based encoding support for VP8/VP9

[Guo, Yejun]

please ignore this patch since the version number in libavcodec/version.h has 
been changed,
and so conflicts, I'll rebase it and send out a new V8 patch.

> -Original Message-
> From: Guo, Yejun
> Sent: Thursday, August 29, 2019 10:35 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Guo, Yejun 
> Subject: [PATCH V7] avcodec/libvpxenc: add ROI-based encoding support for
> VP8/VP9
> 
> example command line to verify it:
> ./ffmpeg -i input.stream -vf addroi=0:0:iw/3:ih/3:-0.8 -c:v libvpx -b:v 2M
> tmp.webm
> 
> Signed-off-by: Guo, Yejun 
> ---
>  libavcodec/libvpxenc.c | 189
> +
>  libavcodec/version.h   |   2 +-
>  2 files changed, 190 insertions(+), 1 deletion(-)
> 
> diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
> index feb52ea..dfee5cc 100644
> --- a/libavcodec/libvpxenc.c
> +++ b/libavcodec/libvpxenc.c
> @@ -116,6 +116,9 @@ typedef struct VPxEncoderContext {
>  int tune_content;
>  int corpus_complexity;
>  int tpl_model;
> +// If the driver does not support ROI then warn the first time we
> +// encounter a frame with ROI side data.
> +int roi_warned;
>  } VPxContext;
> 
>  /** String mappings for enum vp8e_enc_control_id */
> @@ -1057,6 +1060,184 @@ static int queue_frames(AVCodecContext *avctx,
> AVPacket *pkt_out)
>  return size;
>  }
> 
> +static int set_roi_map(AVCodecContext *avctx, const AVFrameSideData *sd,
> int frame_width, int frame_height,
> +   vpx_roi_map_t *roi_map, int block_size, int
> segment_cnt)
> +{
> +/* range of vpx_roi_map_t.delta_q[i] is [-63, 63] */
> +#define MAX_DELTA_Q 63
> +
> +const AVRegionOfInterest *roi = NULL;
> +int nb_rois;
> +uint32_t self_size;
> +int segment_id;
> +
> +/* record the mapping from delta_q to "segment id + 1" in
> segment_mapping[].
> + * the range of delta_q is [-MAX_DELTA_Q, MAX_DELTA_Q],
> + * and its corresponding array index is [0, 2 * MAX_DELTA_Q],
> + * and so the length of the mapping array is 2 * MAX_DELTA_Q + 1.
> + * "segment id + 1", so we can say there's no mapping if the value of
> array element is zero.
> + */
> +int segment_mapping[2 * MAX_DELTA_Q + 1] = { 0 };
> +
> +memset(roi_map, 0, sizeof(*roi_map));
> +
> +/* segment id 0 in roi_map is reserved for the areas not covered by
> AVRegionOfInterest.
> + * segment id 0 in roi_map is also for the areas with
> AVRegionOfInterest.qoffset near 0.
> + * (delta_q of segment id 0 is 0).
> + */
> +segment_mapping[MAX_DELTA_Q] = 1;
> +segment_id = 1;
> +
> +roi = (const AVRegionOfInterest*)sd->data;
> +self_size = roi->self_size;
> +if (!self_size || sd->size % self_size != 0) {
> +av_log(avctx, AV_LOG_ERROR, "Invalid
> AVRegionOfInterest.self_size.\n");
> +return AVERROR(EINVAL);
> +}
> +nb_rois = sd->size / self_size;
> +
> +/* This list must be iterated from zero because regions are
> + * defined in order of decreasing importance. So discard less
> + * important areas if they exceed the segment count.
> + */
> +for (int i = 0; i < nb_rois; i++) {
> +int delta_q;
> +int mapping_index;
> +
> +roi = (const AVRegionOfInterest*)(sd->data + self_size * i);
> +if (roi->qoffset.den == 0) {
> +av_log(avctx, AV_LOG_ERROR,
> "AVRegionOfInterest.qoffset.den must not be zero.\n");
> +return AVERROR(EINVAL);
> +}
> +
> +delta_q = (int)(roi->qoffset.num * 1.0f / roi->qoffset.den *
> MAX_DELTA_Q);
> +delta_q = av_clip(delta_q, -MAX_DELTA_Q, MAX_DELTA_Q);
> +
> +mapping_index = delta_q + MAX_DELTA_Q;
> +if (!segment_mapping[mapping_index]) {
> +if (segment_id == segment_cnt) {
> +av_log(avctx, AV_LOG_WARNING,
> +   "ROI only supports %d segments (and segment 0
> is reserved for non-ROIs), skipping the left ones.\n",
> +   segment_cnt);
> +break;
> +}
> +
> +segment_mapping[mapping_index] = segment_id + 1;
> +roi_map->delta_q[segment_id] = delta_q;
> +segment_id++;
> +}
> +}
> +
> +
> +roi_map->rows = (frame_height + block_size - 1) / block_size;
> +roi_map->cols = (frame_width  + block_size - 1) / block_size;
> +roi_map->roi_map = av_mallocz_array(roi_map->rows * roi_map->cols,
> sizeof(*roi_map->roi_map));
> +if (!roi_map->roi_map) {
> +av_log(avctx, AV_LOG_ERROR, "roi_map alloc failed.\n");
> +return AVERROR(ENOMEM);
> +}
> +
> +/* This list must be iterated in reverse, so for the case that
> + * two regions are overlapping, the more important area takes effect.
> + */
> +for (int i = nb_rois - 1; i >= 0; i--) {
> +int delta_q;
> +int mapping_value;
> +int starty, endy, startx, endx;
> +
> +roi = (const AVRegionOfInterest*)(sd->data + self_size * 

Re: [FFmpeg-devel] [PATCH] libavcodec/libx264 and libx265: add a flag to output ROI warnings only once.

[Guo, Yejun]

> -Original Message-
> From: Guo, Yejun
> Sent: Monday, September 02, 2019 12:38 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Guo, Yejun 
> Subject: [PATCH] libavcodec/libx264 and libx265: add a flag to output ROI
> warnings only once.
> 
> Signed-off-by: Guo, Yejun 
> ---
>  libavcodec/libx264.c | 14 --
>  libavcodec/libx265.c |  9 -
>  2 files changed, 20 insertions(+), 3 deletions(-)

this patch ask for review, thanks.

> 
> diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
> index 86e3530..62316e6 100644
> --- a/libavcodec/libx264.c
> +++ b/libavcodec/libx264.c
> @@ -99,6 +99,10 @@ typedef struct X264Context {
> 
>  int nb_reordered_opaque, next_reordered_opaque;
>  int64_t *reordered_opaque;
> +
> +// If the encoder does not support ROI then warn the first time we
> +// encounter a frame with ROI side data.
> +int roi_warned;
>  } X264Context;
> 
>  static void X264_log(void *p, int level, const char *fmt, va_list args)
> @@ -356,7 +360,10 @@ static int X264_frame(AVCodecContext *ctx,
> AVPacket *pkt, const AVFrame *frame,
>  sd = av_frame_get_side_data(frame,
> AV_FRAME_DATA_REGIONS_OF_INTEREST);
>  if (sd) {
>  if (x4->params.rc.i_aq_mode == X264_AQ_NONE) {
> -av_log(ctx, AV_LOG_WARNING, "Adaptive quantization
> must be enabled to use ROI encoding, skipping ROI.\n");
> +if (!x4->roi_warned) {
> +x4->roi_warned = 1;
> +av_log(ctx, AV_LOG_WARNING, "Adaptive
> quantization must be enabled to use ROI encoding, skipping ROI.\n");
> +}
>  } else {
>  if (frame->interlaced_frame == 0) {
>  int mbx = (frame->width + MB_SIZE - 1) / MB_SIZE;
> @@ -410,7 +417,10 @@ static int X264_frame(AVCodecContext *ctx,
> AVPacket *pkt, const AVFrame *frame,
>  x4->pic.prop.quant_offsets = qoffsets;
>  x4->pic.prop.quant_offsets_free = av_free;
>  } else {
> -av_log(ctx, AV_LOG_WARNING, "interlaced_frame
> not supported for ROI encoding yet, skipping ROI.\n");
> +if (!x4->roi_warned) {
> +x4->roi_warned = 1;
> +av_log(ctx, AV_LOG_WARNING,
> "interlaced_frame not supported for ROI encoding yet, skipping ROI.\n");
> +}
>  }
>  }
>  }
> diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
> index 665b780..15fc4e7 100644
> --- a/libavcodec/libx265.c
> +++ b/libavcodec/libx265.c
> @@ -47,6 +47,10 @@ typedef struct libx265Context {
>  char *tune;
>  char *profile;
>  char *x265_opts;
> +
> +// If the encoder does not support ROI then warn the first time we
> +// encounter a frame with ROI side data.
> +int roi_warned;
>  } libx265Context;
> 
>  static int is_keyframe(NalUnitType naltype)
> @@ -310,7 +314,10 @@ static av_cold int
> libx265_encode_set_roi(libx265Context *ctx, const AVFrame *fr
>  AVFrameSideData *sd = av_frame_get_side_data(frame,
> AV_FRAME_DATA_REGIONS_OF_INTEREST);
>  if (sd) {
>  if (ctx->params->rc.aqMode == X265_AQ_NONE) {
> -av_log(ctx, AV_LOG_WARNING, "Adaptive quantization must
> be enabled to use ROI encoding, skipping ROI.\n");
> +if (!ctx->roi_warned) {
> +ctx->roi_warned = 1;
> +av_log(ctx, AV_LOG_WARNING, "Adaptive quantization
> must be enabled to use ROI encoding, skipping ROI.\n");
> +}
>  } else {
>  /* 8x8 block when qg-size is 8, 16*16 block otherwise. */
>  int mb_size = (ctx->params->rc.qgSize == 8) ? 8 : 16;
> --
> 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".

[FFmpeg-devel] [PATCH 2/3] avcodec/vc1_pred: Fix invalid shifts in scaleforopp()

[Michael Niedermayer]

Fixes: left shift of negative value -2
Fixes: 
16964/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VC1IMAGE_fuzzer-5757853565976576

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

diff --git a/libavcodec/vc1_pred.c b/libavcodec/vc1_pred.c
index e1ad0e1d7d..f70956e739 100644
--- a/libavcodec/vc1_pred.c
+++ b/libavcodec/vc1_pred.c
@@ -191,9 +191,9 @@ static av_always_inline int scaleforopp(VC1Context *v, int 
n /* MV */,
 n >>= hpel;
 if (v->s.pict_type == AV_PICTURE_TYPE_B && !v->second_field && dir == 1) {
 if (dim)
-n = scaleforopp_y(v, n, dir) << hpel;
+n = scaleforopp_y(v, n, dir) * (1 << hpel);
 else
-n = scaleforopp_x(v, n) << hpel;
+n = scaleforopp_x(v, n)  * (1 << hpel);
 return n;
 }
 if (v->s.pict_type != AV_PICTURE_TYPE_B)
-- 
2.23.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/vc1_block: Fix invalid shift with rangeredfrm

[Michael Niedermayer]

Fixes: left shift of negative value -7
Fixes: 
16959/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WMV3_fuzzer-5200360825683968

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

diff --git a/libavcodec/vc1_block.c b/libavcodec/vc1_block.c
index 514206f6d2..fe7dbf8b1d 100644
--- a/libavcodec/vc1_block.c
+++ b/libavcodec/vc1_block.c
@@ -1997,7 +1997,7 @@ static int vc1_decode_b_mb(VC1Context *v)
 v->vc1dsp.vc1_inv_trans_8x8(s->block[i]);
 if (v->rangeredfrm)
 for (j = 0; j < 64; j++)
-s->block[i][j] <<= 1;
+s->block[i][j] *= 2;
 s->idsp.put_signed_pixels_clamped(s->block[i],
   s->dest[dst_idx] + off,
   i & 4 ? s->uvlinesize
-- 
2.23.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 3/3] vcodec/vc1: compute rangex/y only for P/B frames

[Michael Niedermayer]

Fixes: left shift of 1073741824 by 1 places cannot be represented in type 'int'
Fixes: 
16976/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VC1_fuzzer-4847262047404032

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

diff --git a/libavcodec/vc1.c b/libavcodec/vc1.c
index e102b931d8..e0580a6ee4 100644
--- a/libavcodec/vc1.c
+++ b/libavcodec/vc1.c
@@ -1313,16 +1313,17 @@ int ff_vc1_parse_frame_header_adv(VC1Context *v, 
GetBitContext* gb)
 break;
 }
 
-if (v->fcm != PROGRESSIVE && !v->s.quarter_sample) {
-v->range_x <<= 1;
-v->range_y <<= 1;
-}
 
 /* AC Syntax */
 v->c_ac_table_index = decode012(gb);
 if (v->s.pict_type == AV_PICTURE_TYPE_I || v->s.pict_type == 
AV_PICTURE_TYPE_BI) {
 v->y_ac_table_index = decode012(gb);
 }
+else if (v->fcm != PROGRESSIVE && !v->s.quarter_sample) {
+v->range_x <<= 1;
+v->range_y <<= 1;
+}
+
 /* DC Syntax */
 v->s.dc_table_index = get_bits1(gb);
 if ((v->s.pict_type == AV_PICTURE_TYPE_I || v->s.pict_type == 
AV_PICTURE_TYPE_BI)
-- 
2.23.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 v2] avcodec/tscc: fix the warning: assigning to 'Bytef *' (aka 'unsigned char *') from 'const uint8_t *

[Carl Eugen Hoyos]

Am Do., 5. Sept. 2019 um 00:45 Uhr schrieb :
>
> From: Limin Wang 
>
> Signed-off-by: Limin Wang 
> ---
>  libavcodec/tscc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/tscc.c b/libavcodec/tscc.c
> index 6d03081..b0dbef4 100644
> --- a/libavcodec/tscc.c
> +++ b/libavcodec/tscc.c
> @@ -88,7 +88,7 @@ static int decode_frame(AVCodecContext *avctx, void *data, 
> int *got_frame,
>  av_log(avctx, AV_LOG_ERROR, "Inflate reset error: %d\n", ret);
>  return AVERROR_UNKNOWN;
>  }
> -c->zstream.next_in   = buf;
> +c->zstream.next_in   = (uint8_t*)buf;

Iirc, the warning also happens when compiling for android and the reason
is that their zlib header is different / old and therefore doesn't mark the
input as const (as the zlib header does on different systems here, both
new and old). I therefore believe this line should not be changed.

If it is changed, the commit message should first state was is done
("cast a pointer to avoid a warning") and the actual complete warning
should be part of the commit message.

Carl Eugen

(Checking Android sources seems to show that they have fixed
this issue in more recent versions.)
___
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 v1] libavutil: add A2R10G10B10 & A2B10G10R10

[Carl Eugen Hoyos]

Am Di., 10. Sept. 2019 um 11:35 Uhr schrieb Zachary Zhou
:
>
> ---
>  libavutil/hwcontext_vaapi.c | 6 ++
>  libavutil/pixfmt.h  | 3 +++
>  2 files changed, 9 insertions(+)
>
> diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
> index cf117640f2..9838250b66 100644
> --- a/libavutil/hwcontext_vaapi.c
> +++ b/libavutil/hwcontext_vaapi.c
> @@ -125,6 +125,12 @@ static const VAAPIFormatDescriptor vaapi_format_map[] = {
>  #endif
>  MAP(BGRA, RGB32,   BGRA, 0),
>  MAP(BGRX, RGB32,   BGR0, 0),
> +#ifdef VA_FOURCC_A2R10G10B10
> +MAP(A2R10G10B10, RGB32_10, A2R10G10B10, 0),
> +#endif
> +#ifdef VA_FOURCC_A2B10G10R10
> +MAP(A2B10G10R10, RGB32_10, A2B10G10R10, 0),
> +#endif
>  MAP(RGBA, RGB32,   RGBA, 0),
>  MAP(RGBX, RGB32,   RGB0, 0),
>  #ifdef VA_FOURCC_ABGR
> diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
> index d78e863d4b..e00f129b46 100644
> --- a/libavutil/pixfmt.h
> +++ b/libavutil/pixfmt.h
> @@ -348,6 +348,9 @@ enum AVPixelFormat {
>  AV_PIX_FMT_NV24,  ///< planar YUV 4:4:4, 24bpp, 1 plane for Y and 1 
> plane for the UV components, which are interleaved (first byte U and the 
> following byte V)
>  AV_PIX_FMT_NV42,  ///< as above, but U and V bytes are swapped
>
> +AV_PIX_FMT_A2R10G10B10, ///< 10-bit Pixel RGB formats.
> +AV_PIX_FMT_A2B10G10R10, ///< 10-bit Pixel BGR formats.

The patch looks insufficient, see the patch to add AYUV and other
packed formats.

The more important question imo is: Why are these formats needed,
which hardware produces them for which input?

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

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

Re: [FFmpeg-devel] [PATCH] avcodec/webp: avoid trying to decode trailing junk in bitstreams

[Pascal Massimino]

On Tue, Sep 10, 2019 at 5:12 PM Michael Niedermayer 
wrote:

> On Mon, Sep 09, 2019 at 11:13:53AM +0200, Pascal Massimino wrote:
> > Michael,
> >
> > On Fri, Sep 6, 2019 at 6:21 PM Michael Niedermayer
> 
> > wrote:
> >
> > > On Fri, Sep 06, 2019 at 01:11:50PM +0200, Pascal Massimino wrote:
> > > > Michael,
> > > >
> > > > On Thu, Sep 5, 2019 at 6:20 PM Michael Niedermayer
> > > 
> > > > wrote:
> > > >
> > > > > On Wed, Sep 04, 2019 at 07:43:15AM +0200, Pascal Massimino wrote:
> > > [...]
> > >
> > > > >
> > > > > i would guess its not a known chunk but rather hits the default
> > > > > is that just a bunch of 0 or 0xFF bytes ?
> > > > > detecting before we read into the end feels more robust if
> > > > > we can simply detect the "junk"
> > > > >
> > > >
> > > > As i mentioned in the description, a possibly more robust solution
> would
> > > be
> > > > just stopping the loop as soon as 'chunk_size' bytes have been
> consumed
> > > > (leading to *got_frame = 1) and no more. This current patch is
> > > minimalist,
> > > > though.
> > >
> > > well, which solution do you prefer ?
> > >
> >
> > the one in the patch is fine.
>
> ok, will apply
>

thx


>
> thx
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> If you drop bombs on a foreign country and kill a hundred thousand
> innocent people, expect your government to call the consequence
> "unprovoked inhuman terrorist attacks" and use it to justify dropping
> more bombs and killing more people. The technology changed, the idea is
> old.
> ___
> 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 1/2] lavc/qsv: Fix MSDK initialization failure in system memory mode

[Mark Thompson]

On 04/09/2019 16:40, Zhong Li wrote:
> MSDK does not create internal acceleration device on Linux,
> So MFXVideoCORE_SetHandle() is necessary.
> It has been added for ff_qsv_init_session_device().
> But missed for ff_qsv_init_internal_session() due to commit
> 1f26a23 overwrited commit db89f45
> 
> Fix #7030

Huh.  I think I see the problem - the standalone dispatcher does try to create 
a VA connection to fix common cases on simple devices 
(), but 
that seems to have been lost in the full open source media SDK.

Given that the D3D code does find a device automatically it's tempting to 
suggest that this should be fixed on the media SDK side instead for 
consistency, but I don't really mind.

> Signed-off-by: Zhong Li 
> ---
>  libavcodec/qsv.c  | 105 
> --
>  libavcodec/qsv_internal.h |  27 +++-
>  libavcodec/qsvdec.c   |  29 +++--
>  libavcodec/qsvdec.h   |   2 +-
>  libavcodec/qsvenc.c   |  17 
>  libavcodec/qsvenc.h   |   2 +-
>  6 files changed, 151 insertions(+), 31 deletions(-)
> 
> diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
> index 65ad070..126182b 100644
> --- a/libavcodec/qsv.c
> +++ b/libavcodec/qsv.c
> @@ -348,7 +348,79 @@ load_plugin_fail:
>  
>  }
>  
> -int ff_qsv_init_internal_session(AVCodecContext *avctx, mfxSession *session,
> +//This code is only required for Linux since a display handle is required.
> +//For Windows the session is complete and ready to use.
> +//For releases of Media Server Studio >= 2015 R4 the
> +//render nodes interface is preferred (/dev/dri/renderD).
> +//Using Media Server Studio 2015 R4 or newer is recommended
> +//but the older /dev/dri/card interface is also searched for broader 
> compatibility.
> +
> +#ifdef AVCODEC_QSV_LINUX_SESSION_HANDLE
> +static int ff_qsv_set_display_handle(AVCodecContext *avctx, QSVSession *qs)
> +{
> +// VAAPI display handle
> +int ret = 0;
> +VADisplay va_dpy = NULL;
> +VAStatus va_res = VA_STATUS_SUCCESS;
> +int major_version = 0, minor_version = 0;
> +int fd = -1;
> +char adapterpath[256];
> +int adapter_num;
> +
> +qs->fd_display = -1;
> +qs->va_display = NULL;
> +
> +//search for valid graphics device
> +for (adapter_num = 0;adapter_num < 6;adapter_num++) {
> +
> +if (adapter_num<3) {
> +snprintf(adapterpath,sizeof(adapterpath),
> +"/dev/dri/renderD%d", adapter_num+128);
> +} else {
> +snprintf(adapterpath,sizeof(adapterpath),
> +"/dev/dri/card%d", adapter_num-3);
> +}
> +
> +fd = open(adapterpath, O_RDWR);
> +if (fd < 0) {
> +av_log(avctx, AV_LOG_ERROR,
> +"mfx init: %s fd open failed\n", adapterpath);
> +continue;
> +}
> +
> +va_dpy = vaGetDisplayDRM(fd);
> +if (!va_dpy) {
> +av_log(avctx, AV_LOG_ERROR,
> +"mfx init: %s vaGetDisplayDRM failed\n", adapterpath);
> +close(fd);
> +continue;
> +}
> +
> +va_res = vaInitialize(va_dpy, _version, _version);
> +if (VA_STATUS_SUCCESS != va_res) {
> +av_log(avctx, AV_LOG_ERROR,
> +"mfx init: %s vaInitialize failed\n", adapterpath);
> +close(fd);
> +fd = -1;
> +continue;

Just call av_hwdevice_ctx_create(VAAPI, { "kernel_driver": "i915", "driver": 
"iHD" }) like hwcontext_qsv does rather than writing an incomplete copy.

> +} else {
> +av_log(avctx, AV_LOG_VERBOSE,
> +"mfx initialization: %s vaInitialize successful\n",adapterpath);
> +qs->fd_display = fd;
> +qs->va_display = va_dpy;
> +ret = MFXVideoCORE_SetHandle(qs->session,
> +  (mfxHandleType)MFX_HANDLE_VA_DISPLAY, (mfxHDL)va_dpy);
> +if (ret < 0) {
> +return ff_qsv_print_error(avctx, ret, "Error %d during set 
> display handle\n");
> +}
> +break;
> +}
> +}
> +return 0;
> +}
> +#endif //AVCODEC_QSV_LINUX_SESSION_HANDLE
> +
> ...
For the rest, probably ok?

All of the session setup stuff is rather horrible, though - it would be nice if 
we could push more of it into hwcontext_qsv instead of messing with the 
sessions like this in lavc.  Can we turn the no-device-provided case into 
approximately the same as an hw_device_ctx case by just calling 
av_hwdevice_ctx_create() early on?  (That would avoid this code entirely, since 
hwcontext_qsv always creates a subdevice.)

- 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 V2] lavu/qsv: remove the redundant libmfx init code

[Mark Thompson]

On 05/09/2019 06:24, Zhong Li wrote:
> Signed-off-by: Zhong Li 
> ---
>  libavutil/hwcontext_qsv.c | 24 ++--
>  1 file changed, 2 insertions(+), 22 deletions(-)
> 
> diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c
> index 0329a81..1c0e4ff 100644
> --- a/libavutil/hwcontext_qsv.c
> +++ b/libavutil/hwcontext_qsv.c
> @@ -1145,27 +1145,6 @@ static int 
> qsv_device_derive_from_child(AVHWDeviceContext *ctx,
>  
>  err = MFXInit(implementation, , >session);
>  if (err != MFX_ERR_NONE) {
> -av_log(ctx, AV_LOG_ERROR, "Error initializing an MFX session: "
> -   "%d.\n", err);
> -ret = AVERROR_UNKNOWN;
> -goto fail;
> -}
> -
> -err = MFXQueryVersion(hwctx->session, );
> -if (err != MFX_ERR_NONE) {
> -av_log(ctx, AV_LOG_ERROR, "Error querying an MFX session: %d.\n", 
> err);
> -ret = AVERROR_UNKNOWN;
> -goto fail;
> -}
> -
> -av_log(ctx, AV_LOG_VERBOSE,
> -   "Initialize MFX session: API version is %d.%d, implementation 
> version is %d.%d\n",
> -   MFX_VERSION_MAJOR, MFX_VERSION_MINOR, ver.Major, ver.Minor);
> -
> -MFXClose(hwctx->session);
> -
> -err = MFXInit(implementation, , >session);
> -if (err != MFX_ERR_NONE) {
>  av_log(ctx, AV_LOG_ERROR,
> "Error initializing an MFX session: %d.\n", err);
>  ret = AVERROR_UNKNOWN;
> @@ -1182,7 +1161,8 @@ static int 
> qsv_device_derive_from_child(AVHWDeviceContext *ctx,
>  
>  ret = MFXQueryVersion(hwctx->session,);
>  if (ret == MFX_ERR_NONE) {
> -av_log(ctx, AV_LOG_VERBOSE, "MFX compile/runtime API: %d.%d/%d.%d\n",
> +av_log(ctx, AV_LOG_VERBOSE,
> +   "Initialize MFX session: API version is %d.%d, implementation 
> version is %d.%d\n",
> MFX_VERSION_MAJOR, MFX_VERSION_MINOR, ver.Major, ver.Minor);
>  }
>  return 0;
> 

Can you add some more explanation?  The extra session checking the version is 
not obviously redundant, and the commit log does indicate that the setup was 
deliberate:

commit ccbb31c14b766ef666ef2daa8c467e478183a957
Author: Luca Barbato 
Date:   Mon Sep 25 09:57:30 2017 +

qsv: Make sure the session is set with the latest version

It is needed to have the calls to MFXJoinSession succeed.


- 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 2/6] swscale: add swscale support for 422/444 decode outputs

[Carl Eugen Hoyos]

Am Di., 10. Sept. 2019 um 18:09 Uhr schrieb Linjie Fu :

> --- a/libswscale/output.c
> +++ b/libswscale/output.c
> @@ -2403,6 +2403,53 @@ yuv2ya8_X_c(SwsContext *c, const int16_t *lumFilter,
>  }
>
>  static void
> +yuv2ayuv_X_c(SwsContext *c, const int16_t *lumFilter,
> + const int16_t **lumSrc, int lumFilterSize,
> + const int16_t *chrFilter, const int16_t **chrUSrc,
> + const int16_t **chrVSrc, int chrFilterSize,
> + const int16_t **alpSrc, uint8_t *dest, int dstW, int y)

The commit message does not match this change.
Do I understand correctly that encoding is expected from AYUV
but not from the other formats?
Or is this the result of an earlier comment?
I don't know if splitting the patch would make it clearer.

Carl Eugen
___
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/6] lavu/pixfmt: add new pixel format ayuv/y210/y410

[Carl Eugen Hoyos]

Am Di., 10. Sept. 2019 um 18:08 Uhr schrieb Linjie Fu :
>
> Add some packed pixel formats for hardware decode support
> in VAAPI and QSV:
>
> 4:2:2 10 bit: Y210
> 4:4:4  8 bit: AYUV
> 4:4:4 10 bit: Y410

Please add a short explanation (either in the commit message or
only in this thread) for which kind of samples these pixel formats
are needed.

Or to say it differently: Why is the hardware outputting planar
formats for some samples and packed for others?

I see you added LE and BE versions: Why are both needed?
And if they are needed, why is there only AYUV and not AYUV
and VUYA?

> Signed-off-by: Linjie Fu 
> ---
>  libavutil/pixdesc.c   | 62 
> +++
>  libavutil/pixfmt.h|  9 +++
>  libavutil/tests/pixfmt_best.c |  1 +
>  libavutil/version.h   |  2 +-
>  4 files changed, 73 insertions(+), 1 deletion(-)

> diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
> index d78e863..0176a2a 100644
> --- a/libavutil/pixfmt.h
> +++ b/libavutil/pixfmt.h
> @@ -348,6 +348,12 @@ enum AVPixelFormat {
>  AV_PIX_FMT_NV24,  ///< planar YUV 4:4:4, 24bpp, 1 plane for Y and 1 
> plane for the UV components, which are interleaved (first byte U and the 
> following byte V)
>  AV_PIX_FMT_NV42,  ///< as above, but U and V bytes are swapped
>
> +AV_PIX_FMT_Y210BE,///< packed YUV 4:2:2, 32bpp, Y0 Cb Y1 Cr, 
> big-endian
> +AV_PIX_FMT_Y210LE,///< packed YUV 4:2:2, 32bpp, Y0 Cb Y1 Cr, 
> little-endian

I believe they are 16bpp.

Carl Eugen
___
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] avformat/movenc: split empty text sample when duration overflow

[Jun Li]

On Tue, Sep 10, 2019 at 12:12 PM Jun Li  wrote:

> Fix #7637
> One empty/end sample is created and inserted between two caption lines
> when there is a gap.
> This patch is to split the sample into multiple ones when its duration is
> too long (>= INT_MAX).
> ---
>  libavformat/movenc.c  | 24 ++-
>  tests/fate/subtitles.mak  |  6 +
>  tests/ref/fate/binsub-movtextenc-long-dur |  1 +
>  .../fate/binsub-movtextenc-long-dur-timebase  |  1 +
>  4 files changed, 26 insertions(+), 6 deletions(-)
>  create mode 100644 tests/ref/fate/binsub-movtextenc-long-dur
>  create mode 100644 tests/ref/fate/binsub-movtextenc-long-dur-timebase
>
> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> index edddfeeb00..aeb7de351f 100644
> --- a/libavformat/movenc.c
> +++ b/libavformat/movenc.c
> @@ -5746,7 +5746,8 @@ static int mov_write_packet(AVFormatContext *s,
> AVPacket *pkt)
>   *
>   * 2) For each subtitle track, check if the current packet's
>   * dts is past the duration of the last subtitle sample. If
> - * so, we now need to write an end sample for that subtitle.
> + * so, we now need to write one or multiple end samples for
> + * that subtitle.
>   *
>   * This must be done conditionally to allow for subtitles that
>   * immediately replace each other, in which case an end sample
> @@ -5760,11 +5761,22 @@ static int mov_write_packet(AVFormatContext *s,
> AVPacket *pkt)
>  int ret;
>
>  if (trk->par->codec_id == AV_CODEC_ID_MOV_TEXT &&
> -trk->track_duration < pkt->dts &&
> -(trk->entry == 0 || !trk->last_sample_is_subtitle_end)) {
> -ret = mov_write_subtitle_end_packet(s, i,
> trk->track_duration);
> -if (ret < 0) return ret;
> -trk->last_sample_is_subtitle_end = 1;
> +trk->track_duration < pkt->dts) {
> +int max_duration = INT_MAX - 1;
> +if (trk->entry == 0 || !trk->last_sample_is_subtitle_end)
> {
> +ret = mov_write_subtitle_end_packet(s, i,
> trk->track_duration);
> +if (ret < 0) return ret;
> +trk->last_sample_is_subtitle_end = 1;
> +}
> +if (trk->last_sample_is_subtitle_end &&
> +pkt->dts - trk->track_duration > max_duration) {
> +int64_t dts = trk->track_duration;
> +while(pkt->dts - dts > max_duration) {
> +dts += max_duration;
> +ret = mov_write_subtitle_end_packet(s, i, dts);
> +if (ret < 0) return ret;
> +}
> +}
>  }
>  }
>
> diff --git a/tests/fate/subtitles.mak b/tests/fate/subtitles.mak
> index 0042902161..4c2b34c431 100644
> --- a/tests/fate/subtitles.mak
> +++ b/tests/fate/subtitles.mak
> @@ -34,6 +34,12 @@ fate-sub-movtext: CMD = fmtstdout ass -i
> $(TARGET_SAMPLES)/sub/MovText_capabilit
>  FATE_SUBTITLES-$(call ENCDEC, MOVTEXT, MOV) += fate-binsub-movtextenc
>  fate-binsub-movtextenc: CMD = md5 -i
> $(TARGET_SAMPLES)/sub/MovText_capability_tester.mp4 -map 0 -scodec mov_text
> -f mp4 -flags +bitexact -fflags +bitexact -movflags frag_keyframe+empty_moov
>
> +FATE_SUBTITLES-$(call ENCDEC, MOVTEXT, MOV) +=
> fate-binsub-movtextenc-long-dur
> +fate-binsub-movtextenc-long-dur: CMD = md5 -i
> $(TARGET_SAMPLES)/sub/WebVTT_movtext_long_dur.vtt -map 0 -scodec mov_text
> -f mp4 -flags +bitexact -fflags +bitexact -movflags frag_keyframe+empty_moov
> +
> +FATE_SUBTITLES-$(call ENCDEC, MOVTEXT, MOV) +=
> fate-binsub-movtextenc-long-dur-timebase
> +fate-binsub-movtextenc-long-dur-timebase: CMD = md5 -i
> $(TARGET_SAMPLES)/sub/WebVTT_movtext_long_dur.vtt -map 0 -scodec mov_text
> -time_base 1000 -f mp4 -flags +bitexact -fflags +bitexact -movflags
> frag_keyframe+empty_moov
> +
>  FATE_SUBTITLES_ASS-$(call DEMDEC, MPL2, MPL2) += fate-sub-mpl2
>  fate-sub-mpl2: CMD = fmtstdout ass -i
> $(TARGET_SAMPLES)/sub/MPL2_capability_tester.txt
>
> diff --git a/tests/ref/fate/binsub-movtextenc-long-dur
> b/tests/ref/fate/binsub-movtextenc-long-dur
> new file mode 100644
> index 00..eb8a3f8fc7
> --- /dev/null
> +++ b/tests/ref/fate/binsub-movtextenc-long-dur
> @@ -0,0 +1 @@
> +7f78c11bb4a6b16335540ef31ba10219
> diff --git a/tests/ref/fate/binsub-movtextenc-long-dur-timebase
> b/tests/ref/fate/binsub-movtextenc-long-dur-timebase
> new file mode 100644
> index 00..185dcc0aab
> --- /dev/null
> +++ b/tests/ref/fate/binsub-movtextenc-long-dur-timebase
> @@ -0,0 +1 @@
> +349d78698cc1226d33d4e6699dbf46d9
> --
> 2.17.1
>
>
Fate test passed, the attachment is the new added sample file.
Will send email to samples-request@ if the patch is approved.
WEBVTT

00:35:47.484 --> 00:35:50.000
Durations that exceed the signed
int max value break the program

[FFmpeg-devel] [PATCH v3] avformat/movenc: split empty text sample when duration overflow

[Jun Li]

Fix #7637
One empty/end sample is created and inserted between two caption lines when 
there is a gap.
This patch is to split the sample into multiple ones when its duration is too 
long (>= INT_MAX).
---
 libavformat/movenc.c  | 24 ++-
 tests/fate/subtitles.mak  |  6 +
 tests/ref/fate/binsub-movtextenc-long-dur |  1 +
 .../fate/binsub-movtextenc-long-dur-timebase  |  1 +
 4 files changed, 26 insertions(+), 6 deletions(-)
 create mode 100644 tests/ref/fate/binsub-movtextenc-long-dur
 create mode 100644 tests/ref/fate/binsub-movtextenc-long-dur-timebase

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index edddfeeb00..aeb7de351f 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -5746,7 +5746,8 @@ static int mov_write_packet(AVFormatContext *s, AVPacket 
*pkt)
  *
  * 2) For each subtitle track, check if the current packet's
  * dts is past the duration of the last subtitle sample. If
- * so, we now need to write an end sample for that subtitle.
+ * so, we now need to write one or multiple end samples for
+ * that subtitle.
  *
  * This must be done conditionally to allow for subtitles that
  * immediately replace each other, in which case an end sample
@@ -5760,11 +5761,22 @@ static int mov_write_packet(AVFormatContext *s, 
AVPacket *pkt)
 int ret;
 
 if (trk->par->codec_id == AV_CODEC_ID_MOV_TEXT &&
-trk->track_duration < pkt->dts &&
-(trk->entry == 0 || !trk->last_sample_is_subtitle_end)) {
-ret = mov_write_subtitle_end_packet(s, i, trk->track_duration);
-if (ret < 0) return ret;
-trk->last_sample_is_subtitle_end = 1;
+trk->track_duration < pkt->dts) {
+int max_duration = INT_MAX - 1;
+if (trk->entry == 0 || !trk->last_sample_is_subtitle_end) {
+ret = mov_write_subtitle_end_packet(s, i, 
trk->track_duration);
+if (ret < 0) return ret;
+trk->last_sample_is_subtitle_end = 1;
+}
+if (trk->last_sample_is_subtitle_end &&
+pkt->dts - trk->track_duration > max_duration) {
+int64_t dts = trk->track_duration;
+while(pkt->dts - dts > max_duration) {
+dts += max_duration;
+ret = mov_write_subtitle_end_packet(s, i, dts);
+if (ret < 0) return ret;
+}
+}
 }
 }
 
diff --git a/tests/fate/subtitles.mak b/tests/fate/subtitles.mak
index 0042902161..4c2b34c431 100644
--- a/tests/fate/subtitles.mak
+++ b/tests/fate/subtitles.mak
@@ -34,6 +34,12 @@ fate-sub-movtext: CMD = fmtstdout ass -i 
$(TARGET_SAMPLES)/sub/MovText_capabilit
 FATE_SUBTITLES-$(call ENCDEC, MOVTEXT, MOV) += fate-binsub-movtextenc
 fate-binsub-movtextenc: CMD = md5 -i 
$(TARGET_SAMPLES)/sub/MovText_capability_tester.mp4 -map 0 -scodec mov_text -f 
mp4 -flags +bitexact -fflags +bitexact -movflags frag_keyframe+empty_moov
 
+FATE_SUBTITLES-$(call ENCDEC, MOVTEXT, MOV) += fate-binsub-movtextenc-long-dur
+fate-binsub-movtextenc-long-dur: CMD = md5 -i 
$(TARGET_SAMPLES)/sub/WebVTT_movtext_long_dur.vtt -map 0 -scodec mov_text -f 
mp4 -flags +bitexact -fflags +bitexact -movflags frag_keyframe+empty_moov
+
+FATE_SUBTITLES-$(call ENCDEC, MOVTEXT, MOV) += 
fate-binsub-movtextenc-long-dur-timebase
+fate-binsub-movtextenc-long-dur-timebase: CMD = md5 -i 
$(TARGET_SAMPLES)/sub/WebVTT_movtext_long_dur.vtt -map 0 -scodec mov_text 
-time_base 1000 -f mp4 -flags +bitexact -fflags +bitexact -movflags 
frag_keyframe+empty_moov
+
 FATE_SUBTITLES_ASS-$(call DEMDEC, MPL2, MPL2) += fate-sub-mpl2
 fate-sub-mpl2: CMD = fmtstdout ass -i 
$(TARGET_SAMPLES)/sub/MPL2_capability_tester.txt
 
diff --git a/tests/ref/fate/binsub-movtextenc-long-dur 
b/tests/ref/fate/binsub-movtextenc-long-dur
new file mode 100644
index 00..eb8a3f8fc7
--- /dev/null
+++ b/tests/ref/fate/binsub-movtextenc-long-dur
@@ -0,0 +1 @@
+7f78c11bb4a6b16335540ef31ba10219
diff --git a/tests/ref/fate/binsub-movtextenc-long-dur-timebase 
b/tests/ref/fate/binsub-movtextenc-long-dur-timebase
new file mode 100644
index 00..185dcc0aab
--- /dev/null
+++ b/tests/ref/fate/binsub-movtextenc-long-dur-timebase
@@ -0,0 +1 @@
+349d78698cc1226d33d4e6699dbf46d9
-- 
2.17.1

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

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

[FFmpeg-devel] [PATCH] qsv: get FrameInfo.Shift by desc->comp[0].shift

[Linjie Fu]

Since Y410 is a pixel format with depth > 8 but shift = 0, get Shift
info by depth is not quite accurate.

Signed-off-by: Linjie Fu 
---
 libavcodec/qsvenc.c   | 4 ++--
 libavutil/hwcontext_qsv.c | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index 9bf8574..912f2a8 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -437,7 +437,7 @@ static int init_video_param_jpeg(AVCodecContext *avctx, 
QSVEncContext *q)
 q->param.mfx.FrameInfo.ChromaFormat   = MFX_CHROMAFORMAT_YUV420;
 q->param.mfx.FrameInfo.BitDepthLuma   = desc->comp[0].depth;
 q->param.mfx.FrameInfo.BitDepthChroma = desc->comp[0].depth;
-q->param.mfx.FrameInfo.Shift  = desc->comp[0].depth > 8;
+q->param.mfx.FrameInfo.Shift  = desc->comp[0].shift > 0;
 
 q->param.mfx.FrameInfo.Width  = FFALIGN(avctx->width, 16);
 q->param.mfx.FrameInfo.Height = FFALIGN(avctx->height, 16);
@@ -532,7 +532,7 @@ static int init_video_param(AVCodecContext *avctx, 
QSVEncContext *q)
 q->param.mfx.FrameInfo.ChromaFormat   = MFX_CHROMAFORMAT_YUV420;
 q->param.mfx.FrameInfo.BitDepthLuma   = desc->comp[0].depth;
 q->param.mfx.FrameInfo.BitDepthChroma = desc->comp[0].depth;
-q->param.mfx.FrameInfo.Shift  = desc->comp[0].depth > 8;
+q->param.mfx.FrameInfo.Shift  = desc->comp[0].shift > 0;
 
 // If the minor version is greater than or equal to 19,
 // then can use the same alignment settings as H.264 for HEVC
diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c
index 7f8f2de..d722c9a 100644
--- a/libavutil/hwcontext_qsv.c
+++ b/libavutil/hwcontext_qsv.c
@@ -323,7 +323,7 @@ static int qsv_init_surface(AVHWFramesContext *ctx, 
mfxFrameSurface1 *surf)
 
 surf->Info.BitDepthLuma   = desc->comp[0].depth;
 surf->Info.BitDepthChroma = desc->comp[0].depth;
-surf->Info.Shift  = desc->comp[0].depth > 8;
+surf->Info.Shift  = desc->comp[0].shift > 0;
 
 if (desc->log2_chroma_w && desc->log2_chroma_h)
 surf->Info.ChromaFormat   = MFX_CHROMAFORMAT_YUV420;
-- 
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".

[FFmpeg-devel] [PATCH 6/6] lavu/hwcontext_qsv: add frame map support for HEVC rext support

[Linjie Fu]

Signed-off-by: Linjie Fu 
---
 libavutil/hwcontext_qsv.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c
index 0329a81..7f8f2de 100644
--- a/libavutil/hwcontext_qsv.c
+++ b/libavutil/hwcontext_qsv.c
@@ -103,6 +103,14 @@ static const struct {
 { AV_PIX_FMT_BGRA, MFX_FOURCC_RGB4 },
 { AV_PIX_FMT_P010, MFX_FOURCC_P010 },
 { AV_PIX_FMT_PAL8, MFX_FOURCC_P8   },
+{ AV_PIX_FMT_YUYV422,
+   MFX_FOURCC_YUY2 },
+{ AV_PIX_FMT_Y210,
+   MFX_FOURCC_Y210 },
+{ AV_PIX_FMT_AYUV,
+   MFX_FOURCC_AYUV },
+{ AV_PIX_FMT_Y410,
+   MFX_FOURCC_Y410 },
 };
 
 static uint32_t qsv_fourcc_from_pix_fmt(enum AVPixelFormat pix_fmt)
@@ -768,12 +776,29 @@ static int map_frame_to_surface(const AVFrame *frame, 
mfxFrameSurface1 *surface)
 break;
 
 case AV_PIX_FMT_BGRA:
+case AV_PIX_FMT_AYUV:
 surface->Data.B = frame->data[0];
 surface->Data.G = frame->data[0] + 1;
 surface->Data.R = frame->data[0] + 2;
 surface->Data.A = frame->data[0] + 3;
 break;
 
+case AV_PIX_FMT_YUYV422:
+surface->Data.Y = frame->data[0];
+surface->Data.U = frame->data[0] + 1;
+surface->Data.V = frame->data[0] + 3;
+break;
+
+case AV_PIX_FMT_Y210:
+surface->Data.Y16 = frame->data[0];
+surface->Data.U16 = frame->data[0] + 2;
+surface->Data.V16 = frame->data[0] + 6;
+break;
+
+case AV_PIX_FMT_Y410:
+surface->Data.U = frame->data[0];
+break;
+
 default:
 return MFX_ERR_UNSUPPORTED;
 }
-- 
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".

[FFmpeg-devel] [PATCH 5/6] lavc/qsv: add pixfmt fourcc map for AYUV/Y210/Y410

[Linjie Fu]

Signed-off-by: Linjie Fu 
---
 libavcodec/qsv.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
index 65ad070..adfe09a 100644
--- a/libavcodec/qsv.c
+++ b/libavcodec/qsv.c
@@ -218,6 +218,9 @@ enum AVPixelFormat ff_qsv_map_fourcc(uint32_t fourcc)
 case MFX_FOURCC_NV12: return AV_PIX_FMT_NV12;
 case MFX_FOURCC_P010: return AV_PIX_FMT_P010;
 case MFX_FOURCC_P8:   return AV_PIX_FMT_PAL8;
+case MFX_FOURCC_Y210: return AV_PIX_FMT_Y210;
+case MFX_FOURCC_AYUV: return AV_PIX_FMT_AYUV;
+case MFX_FOURCC_Y410: return AV_PIX_FMT_Y410;
 }
 return AV_PIX_FMT_NONE;
 }
@@ -230,6 +233,18 @@ int ff_qsv_map_pixfmt(enum AVPixelFormat format, uint32_t 
*fourcc)
 case AV_PIX_FMT_NV12:
 *fourcc = MFX_FOURCC_NV12;
 return AV_PIX_FMT_NV12;
+case AV_PIX_FMT_YUV422P:
+*fourcc = MFX_FOURCC_YUY2;
+return AV_PIX_FMT_YUYV422;
+case AV_PIX_FMT_YUV422P10:
+*fourcc = MFX_FOURCC_Y210;
+return AV_PIX_FMT_Y210;
+case AV_PIX_FMT_YUV444P:
+*fourcc = MFX_FOURCC_AYUV;
+return AV_PIX_FMT_AYUV;
+case AV_PIX_FMT_YUV444P10:
+*fourcc = MFX_FOURCC_Y410;
+return AV_PIX_FMT_Y410;
 case AV_PIX_FMT_YUV420P10:
 case AV_PIX_FMT_P010:
 *fourcc = MFX_FOURCC_P010;
-- 
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".

[FFmpeg-devel] [PATCH 4/6] lavu/hwcontext_vaapi: add vaapi_format_map support for AYUV/Y210/Y410

[Linjie Fu]

There is no VA_RT_FORMAT_AYUV in defined in libva, and currently in
media-driver, VA_FOURCC_AYUV is used to represent VA_RT_FORMAT_AYUV.

Another patch could be sent to refine the code after this issue is
addressed:
https://github.com/intel/libva/issues/335

Signed-off-by: Linjie Fu 
---
 libavutil/hwcontext_vaapi.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index cf11764..724bbeb 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -116,6 +116,15 @@ static const VAAPIFormatDescriptor vaapi_format_map[] = {
 #endif
 MAP(UYVY, YUV422,  UYVY422, 0),
 MAP(YUY2, YUV422,  YUYV422, 0),
+#ifdef VA_FOURCC_Y210
+MAP(Y210, YUV422_10,Y210, 0),
+#endif
+#define VA_RT_FORMAT_AYUV VA_FOURCC_AYUV
+MAP(AYUV,   AYUV, AYUV, 0),
+#undef VA_RT_FORMAT_AYUV
+#ifdef VA_FOURCC_Y410
+MAP(Y410, YUV444_10,Y410, 0),
+#endif
 MAP(411P, YUV411,  YUV411P, 0),
 MAP(422V, YUV422,  YUV440P, 0),
 MAP(444P, YUV444,  YUV444P, 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".

[FFmpeg-devel] [PATCH 3/6] fate: add tests support for AYUV/Y210/Y410

[Linjie Fu]

Signed-off-by: Linjie Fu 
---
 tests/ref/fate/filter-pixdesc-ayuv   |  1 +
 tests/ref/fate/filter-pixfmts-copy   |  1 +
 tests/ref/fate/filter-pixfmts-crop   |  1 +
 tests/ref/fate/filter-pixfmts-field  |  1 +
 tests/ref/fate/filter-pixfmts-fieldorder |  1 +
 tests/ref/fate/filter-pixfmts-hflip  |  1 +
 tests/ref/fate/filter-pixfmts-il |  1 +
 tests/ref/fate/filter-pixfmts-null   |  1 +
 tests/ref/fate/filter-pixfmts-pad|  1 +
 tests/ref/fate/filter-pixfmts-scale  |  1 +
 tests/ref/fate/filter-pixfmts-transpose  |  1 +
 tests/ref/fate/filter-pixfmts-vflip  |  1 +
 tests/ref/fate/pixfmt_best   |  2 +-
 tests/ref/fate/sws-pixdesc-query | 19 +++
 14 files changed, 32 insertions(+), 1 deletion(-)
 create mode 100644 tests/ref/fate/filter-pixdesc-ayuv

diff --git a/tests/ref/fate/filter-pixdesc-ayuv 
b/tests/ref/fate/filter-pixdesc-ayuv
new file mode 100644
index 000..8e26ac8
--- /dev/null
+++ b/tests/ref/fate/filter-pixdesc-ayuv
@@ -0,0 +1 @@
+pixdesc-ayuva27703ac894af1a90df131dc3c590833
diff --git a/tests/ref/fate/filter-pixfmts-copy 
b/tests/ref/fate/filter-pixfmts-copy
index 4675b6e..18b4746 100644
--- a/tests/ref/fate/filter-pixfmts-copy
+++ b/tests/ref/fate/filter-pixfmts-copy
@@ -2,6 +2,7 @@
 0rgb527ef3d164c8fd0700493733959689c2
 abgr023ecf6396d324edb113e4a483b79ba2
 argbf003b555ef429222005d33844cca9325
+ayuv0af13a42f9d0932c5a9bb6a8a5d1c5ee
 ayuv64le07b9c969dfbe4add4c0626773b151d4f
 bgr06fcd67c8e6cec723dab21c70cf53dc16
 bgr24   4cff3814819f02ecf5824edfd768d2b1
diff --git a/tests/ref/fate/filter-pixfmts-crop 
b/tests/ref/fate/filter-pixfmts-crop
index 4b9f67c..7a4430c 100644
--- a/tests/ref/fate/filter-pixfmts-crop
+++ b/tests/ref/fate/filter-pixfmts-crop
@@ -2,6 +2,7 @@
 0rgb974833c777e6abe6d84dc59af2ca5625
 abgr1d21f5b8a20186ac9dd54459c986a2a7
 argb8b822972049a1e207000763f2564d6e0
+ayuv615241c5406eb556fca0ad8606c23a02
 ayuv64leab2f7bc8f150af47c42c778e3ea28bce
 bgr038a84849a9198667c348c686802e3b52
 bgr24   1dacd8e04bf0eff163e82250d01a9cc7
diff --git a/tests/ref/fate/filter-pixfmts-field 
b/tests/ref/fate/filter-pixfmts-field
index 059347e..b8adb8a 100644
--- a/tests/ref/fate/filter-pixfmts-field
+++ b/tests/ref/fate/filter-pixfmts-field
@@ -2,6 +2,7 @@
 0rgbe2c35753a2271d1f9455b1809bc0e907
 abgrc0eb95959edf5d40ff8af315e62d0f8a
 argb6dca4f2987b49b7d63f702d17bace630
+ayuv3d02eeab336d0a8106f6fdd91be61073
 ayuv64led9836decca6323ba88b3b3d02257c0b6
 bgr01da3fdbac616b3b410d081e39ed7a1f6
 bgr24   573c76d77b1cbe6534ea7c0267dc1b13
diff --git a/tests/ref/fate/filter-pixfmts-fieldorder 
b/tests/ref/fate/filter-pixfmts-fieldorder
index 066b944..ea35c41 100644
--- a/tests/ref/fate/filter-pixfmts-fieldorder
+++ b/tests/ref/fate/filter-pixfmts-fieldorder
@@ -2,6 +2,7 @@
 0rgb2b0f066cfa0bef378a492875d541de8f
 abgr832924b5351361db68dbdbb96c60ae55
 argb80d08e68cb91bc8f2f817516e65f0bd0
+ayuv9e4480c5fcb7c091ec3e517420764ef3
 ayuv64le84ef6260fe02427da946d4a2207fb54c
 bgr0d2c676224ea80ac3ce01afde325ea1a0
 bgr24   b7fdbcd10f20e6ea2d40aae0f329f80d
diff --git a/tests/ref/fate/filter-pixfmts-hflip 
b/tests/ref/fate/filter-pixfmts-hflip
index 100dd70..839dc71 100644
--- a/tests/ref/fate/filter-pixfmts-hflip
+++ b/tests/ref/fate/filter-pixfmts-hflip
@@ -2,6 +2,7 @@
 0rgbada57572ee2b35f86edac9b911ce8523
 abgrd2da6c3ee72e4a89a7cd011dd08566b2
 argb36cf791c52c5463bfc52a070de54337e
+ayuvf1d087284fb1556d76e6def5f94bf273
 ayuv64le4cedbc38b3d4dcb26cdab170ce6d667b
 bgr066e9fda4e658d73bfe4fc9d792542271
 bgr24   db074979bd684ca4547e28681ad3f6ab
diff --git a/tests/ref/fate/filter-pixfmts-il b/tests/ref/fate/filter-pixfmts-il
index 979eb0c..d3027b2 100644
--- a/tests/ref/fate/filter-pixfmts-il
+++ b/tests/ref/fate/filter-pixfmts-il
@@ -2,6 +2,7 @@
 0rgb53efe0182723cd1dedfdbf56357c76f5
 abgr97603869e6248a8e5d8501563a11b114
 argb9e50e6ef02c83f28e97865a1f46ddfcd
+ayuv4251d94ee49e6a3cc1c10c09cd331308
 ayuv64le6f45f683e99ddf4180c7c7f47719efcc
 bgr0590dcd1297d1dd4541eea217381db604
 bgr24   73afe7b447b083a7c2d682abe8dd451a
diff --git a/tests/ref/fate/filter-pixfmts-null 
b/tests/ref/fate/filter-pixfmts-null
index 4675b6e..18b4746 100644
--- a/tests/ref/fate/filter-pixfmts-null
+++ b/tests/ref/fate/filter-pixfmts-null
@@ -2,6 +2,7 @@
 0rgb527ef3d164c8fd0700493733959689c2
 abgr023ecf6396d324edb113e4a483b79ba2
 argb  

[FFmpeg-devel] [PATCH 2/6] swscale: add swscale support for 422/444 decode outputs

[Linjie Fu]

Signed-off-by: Linjie Fu 
---
 libswscale/input.c   | 74 
 libswscale/output.c  | 50 +++
 libswscale/utils.c   |  3 +++
 libswscale/version.h |  2 +-
 4 files changed, 128 insertions(+), 1 deletion(-)

diff --git a/libswscale/input.c b/libswscale/input.c
index 064f8da..1642807 100644
--- a/libswscale/input.c
+++ b/libswscale/input.c
@@ -552,6 +552,61 @@ static void yvy2ToUV_c(uint8_t *dstU, uint8_t *dstV, const 
uint8_t *unused0, con
 av_assert1(src1 == src2);
 }
 
+static void y210le_UV_c(uint8_t *dstU, uint8_t *dstV, const uint8_t *unused0, 
const uint8_t *src,
+const uint8_t *unused1, int width, uint32_t *unused2)
+{
+int i;
+for (i = 0; i < width; i++) {
+AV_WN16(dstU + i * 2, AV_RL16(src + i * 8 + 2) >> 6);
+AV_WN16(dstV + i * 2, AV_RL16(src + i * 8 + 6) >> 6);
+}
+}
+
+static void y210be_UV_c(uint8_t *dstU, uint8_t *dstV, const uint8_t *unused0, 
const uint8_t *src,
+const uint8_t *unused1, int width, uint32_t *unused2)
+{
+int i;
+for (i = 0; i < width; i++) {
+AV_WN16(dstU + i * 2, AV_RB16(src + i * 8 + 2) >> 6);
+AV_WN16(dstV + i * 2, AV_RB16(src + i * 8 + 6) >> 6);
+}
+}
+
+static void y210le_Y_c(uint8_t *dst, const uint8_t *src, const uint8_t 
*unused0,
+   const uint8_t *unused1, int width, uint32_t *unused2)
+{
+int i;
+for (i = 0; i < width; i++)
+AV_WN16(dst + i * 2, AV_RL16(src + i * 4) >> 6);
+}
+
+static void y210be_Y_c(uint8_t *dst, const uint8_t *src, const uint8_t 
*unused0,
+   const uint8_t *unused1, int width, uint32_t *unused2)
+{
+int i;
+for (i = 0; i < width; i++)
+AV_WN16(dst + i * 2 ,AV_RB16(src + i * 4) >> 6);
+}
+
+static void ayuvToY_c(uint8_t *dst, const uint8_t *src, const uint8_t 
*unused1, const uint8_t *unused2,  int width,
+  uint32_t *unused)
+{
+int i;
+for (i = 0; i < width; i++)
+dst[i] = src[4 * i + 2];
+}
+
+static void ayuvToUV_c(uint8_t *dstU, uint8_t *dstV, const uint8_t *unused0, 
const uint8_t *src1,
+   const uint8_t *src2, int width, uint32_t *unused)
+{
+int i;
+for (i = 0; i < width; i++) {
+dstV[i] = src1[4 * i];
+dstU[i] = src1[4 * i + 1];
+}
+av_assert1(src1 == src2);
+}
+
 static void bswap16Y_c(uint8_t *_dst, const uint8_t *_src, const uint8_t 
*unused1, const uint8_t *unused2, int width,
uint32_t *unused)
 {
@@ -1154,6 +1209,15 @@ av_cold void ff_sws_init_input_funcs(SwsContext *c)
 case AV_PIX_FMT_P016BE:
 c->chrToYV12 = p016BEToUV_c;
 break;
+case AV_PIX_FMT_Y210LE:
+c->chrToYV12 = y210le_UV_c;
+break;
+case AV_PIX_FMT_Y210BE:
+c->chrToYV12 = y210be_UV_c;
+break;
+case AV_PIX_FMT_AYUV:
+c->chrToYV12 = ayuvToUV_c;
+break;
 }
 if (c->chrSrcHSubSample) {
 switch (srcFormat) {
@@ -1586,6 +1650,15 @@ av_cold void ff_sws_init_input_funcs(SwsContext *c)
 c->lumToYV12 = grayf32ToY16_bswap_c;
 #endif
 break;
+case AV_PIX_FMT_Y210LE:
+c->lumToYV12 = y210le_Y_c;
+break;
+case AV_PIX_FMT_Y210BE:
+c->chrToYV12 = y210be_Y_c;
+break;
+case AV_PIX_FMT_AYUV:
+c->lumToYV12 = ayuvToY_c;
+break;
 }
 if (c->needAlpha) {
 if (is16BPS(srcFormat) || isNBPS(srcFormat)) {
@@ -1599,6 +1672,7 @@ av_cold void ff_sws_init_input_funcs(SwsContext *c)
 case AV_PIX_FMT_RGBA64BE:  c->alpToYV12 = rgba64beToA_c; break;
 case AV_PIX_FMT_BGRA:
 case AV_PIX_FMT_RGBA:
+case AV_PIX_FMT_AYUV:
 c->alpToYV12 = rgbaToA_c;
 break;
 case AV_PIX_FMT_ABGR:
diff --git a/libswscale/output.c b/libswscale/output.c
index 7eb4644..ebd4f93 100644
--- a/libswscale/output.c
+++ b/libswscale/output.c
@@ -2403,6 +2403,53 @@ yuv2ya8_X_c(SwsContext *c, const int16_t *lumFilter,
 }
 
 static void
+yuv2ayuv_X_c(SwsContext *c, const int16_t *lumFilter,
+ const int16_t **lumSrc, int lumFilterSize,
+ const int16_t *chrFilter, const int16_t **chrUSrc,
+ const int16_t **chrVSrc, int chrFilterSize,
+ const int16_t **alpSrc, uint8_t *dest, int dstW, int y)
+{
+int hasAlpha = !!alpSrc;
+int i;
+
+for (i = 0; i < dstW; i++) {
+int j;
+int A = 1 << 18;
+int Y = 1 << 18;
+int U = 1 << 18;
+int V = 1 << 18;
+
+for (j = 0; j < lumFilterSize; j++) {
+Y += lumSrc[j][i]  * lumFilter[j];
+}
+for (j = 0; j < chrFilterSize; j++) {
+U += chrUSrc[j][i] * chrFilter[j];
+V += chrVSrc[j][i] * chrFilter[j];
+}
+if (hasAlpha)
+for (j = 0; j < lumFilterSize; j++)
+A += alpSrc[j][i] * lumFilter[j];
+ 

[FFmpeg-devel] [PATCH 1/6] lavu/pixfmt: add new pixel format ayuv/y210/y410

[Linjie Fu]

Add some packed pixel formats for hardware decode support in VAAPI
and QSV:

4:2:2 10 bit: Y210
4:4:4  8 bit: AYUV
4:4:4 10 bit: Y410

Signed-off-by: Linjie Fu 
---
 libavutil/pixdesc.c   | 62 +++
 libavutil/pixfmt.h|  9 +++
 libavutil/tests/pixfmt_best.c |  1 +
 libavutil/version.h   |  2 +-
 4 files changed, 73 insertions(+), 1 deletion(-)

diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
index 05dd4a1..c2de0d8 100644
--- a/libavutil/pixdesc.c
+++ b/libavutil/pixdesc.c
@@ -205,6 +205,68 @@ static const AVPixFmtDescriptor 
av_pix_fmt_descriptors[AV_PIX_FMT_NB] = {
 { 0, 4, 1, 0, 8, 3, 7, 2 },/* V */
 },
 },
+[AV_PIX_FMT_Y210LE] = {
+.name = "y210le",
+.nb_components = 3,
+.log2_chroma_w = 1,
+.log2_chroma_h = 0,
+.comp = {
+{ 0, 4, 0, 6, 10, 3, 9, 1 },/* Y */
+{ 0, 8, 2, 6, 10, 7, 9, 3 },/* U */
+{ 0, 8, 6, 6, 10, 7, 9, 7 },/* V */
+},
+},
+[AV_PIX_FMT_Y210BE] = {
+.name = "y210be",
+.nb_components = 3,
+.log2_chroma_w = 1,
+.log2_chroma_h = 0,
+.comp = {
+{ 0, 4, 0, 6, 10, 3, 9, 1 },/* Y */
+{ 0, 8, 2, 6, 10, 7, 9, 3 },/* U */
+{ 0, 8, 6, 6, 10, 7, 9, 7 },/* V */
+},
+.flags = AV_PIX_FMT_FLAG_BE,
+},
+[AV_PIX_FMT_AYUV] = {
+.name = "ayuv",
+.nb_components = 4,
+.log2_chroma_w = 0,
+.log2_chroma_h = 0,
+.comp = {
+{ 0, 4, 1, 0, 8, 3, 7, 2 },/* Y */
+{ 0, 4, 2, 0, 8, 3, 7, 3 },/* U */
+{ 0, 4, 3, 0, 8, 3, 7, 4 },/* V */
+{ 0, 4, 0, 0, 8, 3, 7, 1 },/* A */
+},
+.flags = AV_PIX_FMT_FLAG_ALPHA,
+},
+[AV_PIX_FMT_Y410LE] = {
+.name = "y410le",
+.nb_components = 4,
+.log2_chroma_w = 0,
+.log2_chroma_h = 0,
+.comp = {
+{ 0, 32, 10, 0, 10, 31, 9, 11 },/* Y */
+{ 0, 32,  0, 0, 10, 31, 9,  1 },/* U */
+{ 0, 32, 20, 0, 10, 31, 9, 21 },/* V */
+{ 0, 32, 30, 0,  2, 31, 1, 31 },/* A */
+},
+.flags = AV_PIX_FMT_FLAG_ALPHA | AV_PIX_FMT_FLAG_BITSTREAM,
+},
+[AV_PIX_FMT_Y410BE] = {
+.name = "y410be",
+.nb_components = 4,
+.log2_chroma_w = 0,
+.log2_chroma_h = 0,
+.comp = {
+{ 0, 32, 10, 0, 10, 31, 9, 11 },/* Y */
+{ 0, 32,  0, 0, 10, 31, 9,  1 },/* U */
+{ 0, 32, 20, 0, 10, 31, 9, 21 },/* V */
+{ 0, 32, 30, 0,  2, 31, 1, 31 },/* A */
+},
+.flags = AV_PIX_FMT_FLAG_ALPHA | AV_PIX_FMT_FLAG_BITSTREAM | 
AV_PIX_FMT_FLAG_BE,
+},
 [AV_PIX_FMT_RGB24] = {
 .name = "rgb24",
 .nb_components = 3,
diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
index d78e863..0176a2a 100644
--- a/libavutil/pixfmt.h
+++ b/libavutil/pixfmt.h
@@ -348,6 +348,12 @@ enum AVPixelFormat {
 AV_PIX_FMT_NV24,  ///< planar YUV 4:4:4, 24bpp, 1 plane for Y and 1 
plane for the UV components, which are interleaved (first byte U and the 
following byte V)
 AV_PIX_FMT_NV42,  ///< as above, but U and V bytes are swapped
 
+AV_PIX_FMT_Y210BE,///< packed YUV 4:2:2, 32bpp, Y0 Cb Y1 Cr, big-endian
+AV_PIX_FMT_Y210LE,///< packed YUV 4:2:2, 32bpp, Y0 Cb Y1 Cr, 
little-endian
+AV_PIX_FMT_AYUV,  ///< packed YUV 4:4:4, 32bpp,  A  Y Cb Cr,
+AV_PIX_FMT_Y410LE,///< packed YUV 4:4:4, 32bpp, Cr  Y Cb  A, 
little-endian
+AV_PIX_FMT_Y410BE,///< packed YUV 4:4:4, 32bpp, Cr  Y Cb  A, big-endian
+
 AV_PIX_FMT_NB ///< number of pixel formats, DO NOT USE THIS if you 
want to link with shared libav* because the number of formats might differ 
between versions
 };
 
@@ -436,6 +442,9 @@ enum AVPixelFormat {
 #define AV_PIX_FMT_P010   AV_PIX_FMT_NE(P010BE,  P010LE)
 #define AV_PIX_FMT_P016   AV_PIX_FMT_NE(P016BE,  P016LE)
 
+#define AV_PIX_FMT_Y210   AV_PIX_FMT_NE(Y210BE,  Y210LE)
+#define AV_PIX_FMT_Y410   AV_PIX_FMT_NE(Y410BE,  Y410LE)
+
 /**
   * Chromaticity coordinates of the source primaries.
   * These values match the ones defined by ISO/IEC 23001-8_2013 ?? 7.1.
diff --git a/libavutil/tests/pixfmt_best.c b/libavutil/tests/pixfmt_best.c
index 53f7264..2939e48 100644
--- a/libavutil/tests/pixfmt_best.c
+++ b/libavutil/tests/pixfmt_best.c
@@ -91,6 +91,7 @@ int main(void)
 TEST(AV_PIX_FMT_YUVA420P,  AV_PIX_FMT_YUV420P);
 TEST(AV_PIX_FMT_YUVA422P,  AV_PIX_FMT_YUV422P);
 TEST(AV_PIX_FMT_YUVA444P,  AV_PIX_FMT_YUV444P);
+TEST(AV_PIX_FMT_AYUV,  AV_PIX_FMT_YUV444P);
 TEST(AV_PIX_FMT_AYUV64,AV_PIX_FMT_YUV444P16);
 TEST(AV_PIX_FMT_RGBA,  AV_PIX_FMT_RGB24);
 TEST(AV_PIX_FMT_ABGR,  

Re: [FFmpeg-devel] [PATCH, v2 2/2] lavc/vaapi_decode: recreate hw_frames_ctx for vp9 without destroy va_context

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Mark Thompson
> Sent: Tuesday, September 10, 2019 08:02
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH, v2 2/2] lavc/vaapi_decode: recreate
> hw_frames_ctx for vp9 without destroy va_context
> 
> On 09/09/2019 16:40, Fu, Linjie wrote:
> >> -Original Message-
> >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> >> Of Fu, Linjie
> >> Sent: Friday, August 30, 2019 16:05
> >> To: FFmpeg development discussions and patches  >> de...@ffmpeg.org>
> >> Subject: Re: [FFmpeg-devel] [PATCH, v2 2/2] lavc/vaapi_decode: recreate
> >> hw_frames_ctx for vp9 without destroy va_context
> >>
> >>> -Original Message-
> >>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> >> Behalf
> >>> Of Fu, Linjie
> >>> Sent: Friday, August 9, 2019 19:47
> >>> To: FFmpeg development discussions and patches  >>> de...@ffmpeg.org>
> >>> Subject: Re: [FFmpeg-devel] [PATCH, v2 2/2] lavc/vaapi_decode:
> recreate
> >>> hw_frames_ctx for vp9 without destroy va_context
> >>>
>  -Original Message-
>  From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> >>> Behalf
>  Of Hendrik Leppkes
>  Sent: Friday, August 9, 2019 17:40
>  To: FFmpeg development discussions and patches   de...@ffmpeg.org>
>  Subject: Re: [FFmpeg-devel] [PATCH, v2 2/2] lavc/vaapi_decode:
> >> recreate
>  hw_frames_ctx for vp9 without destroy va_context
> 
>  On Tue, Aug 6, 2019 at 10:55 AM Fu, Linjie  wrote:
> >
> >> -Original Message-
> >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org]
> On
>  Behalf
> >> Of Hendrik Leppkes
> >> Sent: Tuesday, August 6, 2019 16:27
> >> To: FFmpeg development discussions and patches  >> de...@ffmpeg.org>
> >> Subject: Re: [FFmpeg-devel] [PATCH, v2 2/2] lavc/vaapi_decode:
>  recreate
> >> hw_frames_ctx for vp9 without destroy va_context
> >>
> >> On Thu, Jul 11, 2019 at 10:20 AM Linjie Fu 
> wrote:
> >>>
> >>> VP9 allows resolution changes per frame. Currently in VAAPI,
> >>> resolution
> >>> changes leads to va context destroy and reinit. This will cause
> >>> reference frame surface lost and produce garbage.
> >>>
> >>> Though refs surface id could be passed to media driver and found
> in
> >>> RTtbl, vp9RefList[] in hal layer has already been destroyed. Thus
> the
> >>> new created VaContext could only got an empty RefList.
> >>>
> >>> As libva allows re-create surface separately without changing the
> >>> context, this issue could be handled by only recreating
> >>> hw_frames_ctx.
> >>>
> >>> Set hwaccel_priv_data_keeping flag for vp9 to only recreating
> >>> hw_frame_ctx when dynamic resolution changing happens.
> >>>
> >>> Could be verified by:
> >>> ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -i
> >>>   ./resolutions.ivf -pix_fmt p010le -f rawvideo -vframes 20 -y
> >> vaapi.yuv
> >>>
> >>> Signed-off-by: Linjie Fu 
> >>> ---
> >>>  libavcodec/decode.c| 10 +-
> >>>  libavcodec/internal.h  |  1 +
> >>>  libavcodec/pthread_frame.c |  2 ++
> >>>  libavcodec/vaapi_decode.c  | 40 ++--
> -
> >> --
> >>> --
>  -
> >> --
> >>>  libavcodec/vaapi_vp9.c |  4 
> >>>  5 files changed, 34 insertions(+), 23 deletions(-)
> >>>
> >>> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> >>> index 0863b82..7b15fa5 100644
> >>> --- a/libavcodec/decode.c
> >>> +++ b/libavcodec/decode.c
> >>> @@ -1254,7 +1254,6 @@ int
> >> ff_decode_get_hw_frames_ctx(AVCodecContext *avctx,
> >>>
> >>>  frames_ctx = (AVHWFramesContext*)avctx->hw_frames_ctx-
>  data;
> >>>
> >>> -
> >>>  if (frames_ctx->initial_pool_size) {
> >>>  // We guarantee 4 base work surfaces. The function above
>  guarantees
> >> 1
> >>>  // (the absolute minimum), so add the missing count.
> >>
> >> Unrelated whitespace change
> >
> > There is  a redundant whitespace here, so I removed it within this
> patch.
> >
> >>> @@ -1333,7 +1332,7 @@ static int hwaccel_init(AVCodecContext
>  *avctx,
> >>>  return AVERROR_PATCHWELCOME;
> >>>  }
> >>>
> >>> -if (hwaccel->priv_data_size) {
> >>> +if (hwaccel->priv_data_size && !avctx->internal-
> > hwaccel_priv_data) {
> >>>  avctx->internal->hwaccel_priv_data =
> >>>  av_mallocz(hwaccel->priv_data_size);
> >>>  if (!avctx->internal->hwaccel_priv_data)
> >>> @@ -1396,9 +1395,10 @@ int ff_get_format(AVCodecContext
> >> *avctx,
> >> const enum AVPixelFormat *fmt)
> >>>  memcpy(choices, fmt, (n + 1) * sizeof(*choices));
> >>>
> >>>  for (;;) {
> 

Re: [FFmpeg-devel] [PATCH 3/4] avcodec/dxv: Check op_offset in both directions

[Paul B Mahol]

On 9/10/19, Michael Niedermayer  wrote:
> On Mon, Sep 09, 2019 at 10:29:14PM +0200, Paul B Mahol wrote:
>> On 9/9/19, Michael Niedermayer  wrote:
>> > On Fri, Jul 19, 2019 at 09:53:34PM +0200, Michael Niedermayer wrote:
>> >> On Fri, Jul 19, 2019 at 03:36:43PM +0200, Paul B Mahol wrote:
>> >> > On 7/19/19, Michael Niedermayer  wrote:
>> >> > > On Thu, Jun 27, 2019 at 09:32:44AM +0200, Paul B Mahol wrote:
>> >> > >> On 6/27/19, Michael Niedermayer  wrote:
>> >> > >> > Fixes: signed integer overflow: 61 + 2147483647 cannot be
>> >> > >> > represented
>> >> > >> > in
>> >> > >> > type 'int'
>> >> > >> > Fixes:
>> >> > >> > 15311/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DXV_fuzzer-5742552826773504
>> >> > >> >
>> >> > >> > Found-by: continuous fuzzing process
>> >> > >> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>> >> > >> > Signed-off-by: Michael Niedermayer 
>> >> > >> > ---
>> >> > >> >  libavcodec/dxv.c | 2 +-
>> >> > >> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >> > >> >
>> >> > >> > diff --git a/libavcodec/dxv.c b/libavcodec/dxv.c
>> >> > >> > index 5fd1844094..3506775560 100644
>> >> > >> > --- a/libavcodec/dxv.c
>> >> > >> > +++ b/libavcodec/dxv.c
>> >> > >> > @@ -745,7 +745,7 @@ static int dxv_decompress_cocg(DXVContext
>> >> > >> > *ctx,
>> >> > >> > GetByteContext *gb,
>> >> > >> >  int skip0, skip1, oi0 = 0, oi1 = 0;
>> >> > >> >  int ret, state0 = 0, state1 = 0;
>> >> > >> >
>> >> > >> > -if (op_offset < 12)
>> >> > >> > +if (op_offset < 12 || op_offset - 12 >
>> >> > >> > bytestream2_get_bytes_left(gb))
>> >> > >> >  return AVERROR_INVALIDDATA;
>> >> > >> >
>> >> > >> >  dst = tex_data;
>> >> > >> > --
>> >> > >> > 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".
>> >> > >>
>> >> > >> Make sure this does not break any files.
>> >> > >
>> >> > > Do you have any specific files i should test ?
>> >> > >
>> >> > > I of course cannot test every file on earth ...
>> >> >
>> >> > I'm on vacation, so when I get back I will give you some files.
>> >>
>> >> ok, ill wait, no hurry, enjoy your vacation!
>> >
>> > ping, this issue is reaching its deadline, so i would like to
>> > fix it
>>
>> What deadline? Is this some kind of fancy corporation?
>
> first link for googling ossfuzz deadline explains it like this:
>
> "Once a project is signed up for OSS-Fuzz, it is automatically subject to
> the 90-day disclosure deadline for newly reported bugs ..."
>

Irrelevant, this is not security issue at all.

> thx
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> "I am not trying to be anyone's saviour, I'm trying to think about the
>  future and not be sad" - Elon Musk
>
>
___
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 v1] avformat/dashdec: remove the unnecessary type conversion

[lance . lmwang]

From: Limin Wang 

Signed-off-by: Limin Wang 
---
 libavformat/dashdec.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index a6f7551..4db61d8 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -694,11 +694,11 @@ static int parse_manifest_segmenttimeline(AVFormatContext 
*s, struct representat
 }
 
 if (!av_strcasecmp(attr->name, (const char *)"t")) {
-tml->starttime = (int64_t)strtoll(val, NULL, 10);
+tml->starttime = strtoll(val, NULL, 10);
 } else if (!av_strcasecmp(attr->name, (const char *)"r")) {
-tml->repeat =(int64_t) strtoll(val, NULL, 10);
+tml->repeat = strtoll(val, NULL, 10);
 } else if (!av_strcasecmp(attr->name, (const char *)"d")) {
-tml->duration = (int64_t)strtoll(val, NULL, 10);
+tml->duration = strtoll(val, NULL, 10);
 }
 attr = attr->next;
 xmlFree(val);
@@ -943,22 +943,22 @@ static int parse_manifest_representation(AVFormatContext 
*s, const char *url,
 }
 
 if (presentation_timeoffset_val) {
-rep->presentation_timeoffset = (int64_t) 
strtoll(presentation_timeoffset_val, NULL, 10);
+rep->presentation_timeoffset = 
strtoll(presentation_timeoffset_val, NULL, 10);
 av_log(s, AV_LOG_TRACE, "rep->presentation_timeoffset = 
[%"PRId64"]\n", rep->presentation_timeoffset);
 xmlFree(presentation_timeoffset_val);
 }
 if (duration_val) {
-rep->fragment_duration = (int64_t) strtoll(duration_val, NULL, 
10);
+rep->fragment_duration = strtoll(duration_val, NULL, 10);
 av_log(s, AV_LOG_TRACE, "rep->fragment_duration = 
[%"PRId64"]\n", rep->fragment_duration);
 xmlFree(duration_val);
 }
 if (timescale_val) {
-rep->fragment_timescale = (int64_t) strtoll(timescale_val, 
NULL, 10);
+rep->fragment_timescale = strtoll(timescale_val, NULL, 10);
 av_log(s, AV_LOG_TRACE, "rep->fragment_timescale = 
[%"PRId64"]\n", rep->fragment_timescale);
 xmlFree(timescale_val);
 }
 if (startnumber_val) {
-rep->first_seq_no = (int64_t) strtoll(startnumber_val, NULL, 
10);
+rep->first_seq_no = strtoll(startnumber_val, NULL, 10);
 av_log(s, AV_LOG_TRACE, "rep->first_seq_no = [%"PRId64"]\n", 
rep->first_seq_no);
 xmlFree(startnumber_val);
 }
@@ -968,7 +968,7 @@ static int parse_manifest_representation(AVFormatContext 
*s, const char *url,
 if (!val) {
 av_log(s, AV_LOG_ERROR, "Missing value attribute in 
adaptionset_supplementalproperty_node\n");
 } else {
-rep->last_seq_no =(int64_t) strtoll(val, NULL, 10) - 1;
+rep->last_seq_no = strtoll(val, NULL, 10) - 1;
 xmlFree(val);
 }
 }
@@ -1017,12 +1017,12 @@ static int 
parse_manifest_representation(AVFormatContext *s, const char *url,
 duration_val = get_val_from_nodes_tab(segmentlists_tab, 3, 
"duration");
 timescale_val = get_val_from_nodes_tab(segmentlists_tab, 3, 
"timescale");
 if (duration_val) {
-rep->fragment_duration = (int64_t) strtoll(duration_val, NULL, 
10);
+rep->fragment_duration = strtoll(duration_val, NULL, 10);
 av_log(s, AV_LOG_TRACE, "rep->fragment_duration = 
[%"PRId64"]\n", rep->fragment_duration);
 xmlFree(duration_val);
 }
 if (timescale_val) {
-rep->fragment_timescale = (int64_t) strtoll(timescale_val, 
NULL, 10);
+rep->fragment_timescale = strtoll(timescale_val, NULL, 10);
 av_log(s, AV_LOG_TRACE, "rep->fragment_timescale = 
[%"PRId64"]\n", rep->fragment_timescale);
 xmlFree(timescale_val);
 }
-- 
2.6.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] avcodec/mips: Fix a warnning of indentation not reflect the block structure.

[Michael Niedermayer]

On Mon, Sep 09, 2019 at 11:50:51AM +0800, Shiyou Yin wrote:
> The indentation of code dose not reflect the if block structure in
> 'apply_ltp_mips', and this will generate a warnning when build with
> '-Wall' or '-Wmisleading-indentation'.
> ---
>  libavcodec/mips/aacdec_mips.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

will apply

thx

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

Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato


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

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

Re: [FFmpeg-devel] [PATCH V1 3/4] lavf/avidec: fix memory leak in error handling path

[Michael Niedermayer]

On Tue, Sep 10, 2019 at 07:39:27PM +0800, Jun Zhao wrote:
> From: Jun Zhao 
> 
> free the value in error handling path to avoid the memory leak.
> 
> Signed-off-by: Jun Zhao 
> ---
>  libavformat/avidec.c |4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)
> 
> diff --git a/libavformat/avidec.c b/libavformat/avidec.c
> index df78925..e3cd844 100644
> --- a/libavformat/avidec.c
> +++ b/libavformat/avidec.c
> @@ -306,8 +306,10 @@ static int avi_read_tag(AVFormatContext *s, AVStream 
> *st, uint32_t tag,
>  value = av_malloc(size + 1);
>  if (!value)
>  return AVERROR(ENOMEM);
> -if (avio_read(pb, value, size) != size)
> +if (avio_read(pb, value, size) != size) {
> +av_freep();
>  return AVERROR_INVALIDDATA;
> +}
>  value[size] = 0;

will apply

thx

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

I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates


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] avcodec/webp: avoid trying to decode trailing junk in bitstreams

[Michael Niedermayer]

On Mon, Sep 09, 2019 at 11:13:53AM +0200, Pascal Massimino wrote:
> Michael,
> 
> On Fri, Sep 6, 2019 at 6:21 PM Michael Niedermayer 
> wrote:
> 
> > On Fri, Sep 06, 2019 at 01:11:50PM +0200, Pascal Massimino wrote:
> > > Michael,
> > >
> > > On Thu, Sep 5, 2019 at 6:20 PM Michael Niedermayer
> > 
> > > wrote:
> > >
> > > > On Wed, Sep 04, 2019 at 07:43:15AM +0200, Pascal Massimino wrote:
> > [...]
> >
> > > >
> > > > i would guess its not a known chunk but rather hits the default
> > > > is that just a bunch of 0 or 0xFF bytes ?
> > > > detecting before we read into the end feels more robust if
> > > > we can simply detect the "junk"
> > > >
> > >
> > > As i mentioned in the description, a possibly more robust solution would
> > be
> > > just stopping the loop as soon as 'chunk_size' bytes have been consumed
> > > (leading to *got_frame = 1) and no more. This current patch is
> > minimalist,
> > > though.
> >
> > well, which solution do you prefer ?
> >
> 
> the one in the patch is fine.

ok, will apply

thx

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

If you drop bombs on a foreign country and kill a hundred thousand
innocent people, expect your government to call the consequence
"unprovoked inhuman terrorist attacks" and use it to justify dropping
more bombs and killing more people. The technology changed, the idea is old.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
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 3/4] avcodec/dxv: Check op_offset in both directions

[Michael Niedermayer]

On Mon, Sep 09, 2019 at 10:29:14PM +0200, Paul B Mahol wrote:
> On 9/9/19, Michael Niedermayer  wrote:
> > On Fri, Jul 19, 2019 at 09:53:34PM +0200, Michael Niedermayer wrote:
> >> On Fri, Jul 19, 2019 at 03:36:43PM +0200, Paul B Mahol wrote:
> >> > On 7/19/19, Michael Niedermayer  wrote:
> >> > > On Thu, Jun 27, 2019 at 09:32:44AM +0200, Paul B Mahol wrote:
> >> > >> On 6/27/19, Michael Niedermayer  wrote:
> >> > >> > Fixes: signed integer overflow: 61 + 2147483647 cannot be
> >> > >> > represented
> >> > >> > in
> >> > >> > type 'int'
> >> > >> > Fixes:
> >> > >> > 15311/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DXV_fuzzer-5742552826773504
> >> > >> >
> >> > >> > Found-by: continuous fuzzing process
> >> > >> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> >> > >> > Signed-off-by: Michael Niedermayer 
> >> > >> > ---
> >> > >> >  libavcodec/dxv.c | 2 +-
> >> > >> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >> > >> >
> >> > >> > diff --git a/libavcodec/dxv.c b/libavcodec/dxv.c
> >> > >> > index 5fd1844094..3506775560 100644
> >> > >> > --- a/libavcodec/dxv.c
> >> > >> > +++ b/libavcodec/dxv.c
> >> > >> > @@ -745,7 +745,7 @@ static int dxv_decompress_cocg(DXVContext
> >> > >> > *ctx,
> >> > >> > GetByteContext *gb,
> >> > >> >  int skip0, skip1, oi0 = 0, oi1 = 0;
> >> > >> >  int ret, state0 = 0, state1 = 0;
> >> > >> >
> >> > >> > -if (op_offset < 12)
> >> > >> > +if (op_offset < 12 || op_offset - 12 >
> >> > >> > bytestream2_get_bytes_left(gb))
> >> > >> >  return AVERROR_INVALIDDATA;
> >> > >> >
> >> > >> >  dst = tex_data;
> >> > >> > --
> >> > >> > 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".
> >> > >>
> >> > >> Make sure this does not break any files.
> >> > >
> >> > > Do you have any specific files i should test ?
> >> > >
> >> > > I of course cannot test every file on earth ...
> >> >
> >> > I'm on vacation, so when I get back I will give you some files.
> >>
> >> ok, ill wait, no hurry, enjoy your vacation!
> >
> > ping, this issue is reaching its deadline, so i would like to
> > fix it
> 
> What deadline? Is this some kind of fancy corporation?

first link for googling ossfuzz deadline explains it like this:

"Once a project is signed up for OSS-Fuzz, it is automatically subject to the 
90-day disclosure deadline for newly reported bugs ..."

thx

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

"I am not trying to be anyone's saviour, I'm trying to think about the
 future and not be sad" - Elon Musk



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

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

Re: [FFmpeg-devel] [PATCH] avfilter/vf_fps: Avoid inlink fifo build up.

[Michael Niedermayer]

On Mon, Sep 09, 2019 at 09:19:06AM +0200, Paul B Mahol wrote:
> lgtm

will apply

thx

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

Take away the freedom of one citizen and you will be jailed, take away
the freedom of all citizens and you will be congratulated by your peers
in Parliament.


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

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

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: ffio_free_dyn_buf the oc->pb at hls_write_trailer

[Limin Wang]

Maybe it's better to change the subject from:
avformat/hlsenc: ffio_free_dyn_buf the oc->pb at hls_write_trailer
to
avformat/hlsenc: fix memleak at hls_write_trailer

On Mon, Sep 09, 2019 at 02:15:21PM +0800, Steven Liu wrote:
> fix memleak at hls_write_trailer
> 
> Found-by: Andreas Rheinhardt 
> Signed-off-by: Steven Liu 
> ---
>  libavformat/hlsenc.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index f881bb9d60..218bfb2cba 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -2641,6 +2641,7 @@ failed:
>  ff_format_io_close(s, >out);
>  hls_window(s, 1, vs);
>  }
> +ffio_free_dyn_buf(>pb);
>  avformat_free_context(oc);
>  
>  vs->avf = NULL;
> -- 
> 2.17.2 (Apple Git-113)
> 
> 
> 
> ___
> 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 v2] avcodec/tscc: fix the warning: assigning to 'Bytef *' (aka 'unsigned char *') from 'const uint8_t *

[Limin Wang]

On Thu, Sep 05, 2019 at 06:44:55AM +0800, lance.lmw...@gmail.com wrote:

ping

> From: Limin Wang 
> 
> Signed-off-by: Limin Wang 
> ---
>  libavcodec/tscc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/tscc.c b/libavcodec/tscc.c
> index 6d03081..b0dbef4 100644
> --- a/libavcodec/tscc.c
> +++ b/libavcodec/tscc.c
> @@ -88,7 +88,7 @@ static int decode_frame(AVCodecContext *avctx, void *data, 
> int *got_frame,
>  av_log(avctx, AV_LOG_ERROR, "Inflate reset error: %d\n", ret);
>  return AVERROR_UNKNOWN;
>  }
> -c->zstream.next_in   = buf;
> +c->zstream.next_in   = (uint8_t*)buf;
>  c->zstream.avail_in  = buf_size;
>  c->zstream.next_out = c->decomp_buf;
>  c->zstream.avail_out = c->decomp_size;
> -- 
> 2.6.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".

[FFmpeg-devel] [PATCH v1] avcodec/pngenc: fix the warning: assigning to 'Bytef *' (aka 'unsigned char *') from 'const uint8_t *

[lance . lmwang]

From: Limin Wang 

Signed-off-by: Limin Wang 
---
 libavcodec/pngenc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/pngenc.c b/libavcodec/pngenc.c
index d4d8dc8..e78a829 100644
--- a/libavcodec/pngenc.c
+++ b/libavcodec/pngenc.c
@@ -274,7 +274,7 @@ static int png_write_row(AVCodecContext *avctx, const 
uint8_t *data, int size)
 int ret;
 
 s->zstream.avail_in = size;
-s->zstream.next_in  = data;
+s->zstream.next_in  = (uint8_t*)data;
 while (s->zstream.avail_in > 0) {
 ret = deflate(>zstream, Z_NO_FLUSH);
 if (ret != Z_OK)
-- 
2.6.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 2/2] avcodec/g2meet: Check for end of input in jpg_decode_block()

[Michael Niedermayer]

On Mon, Sep 09, 2019 at 11:04:32PM +0200, Tomas Härdin wrote:
> mån 2019-09-09 klockan 22:16 +0200 skrev Michael Niedermayer:
> > Fixes: Timeout (100sec -> 0.7sec)
> > Fixes: 
> > 8668/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_G2M_fuzzer-5174143888130048
> > 
> > Found-by: continuous fuzzing process 
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/g2meet.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/libavcodec/g2meet.c b/libavcodec/g2meet.c
> > index 19e1c130ce..731d29a5d4 100644
> > --- a/libavcodec/g2meet.c
> > +++ b/libavcodec/g2meet.c
> > @@ -244,6 +244,9 @@ static int jpg_decode_block(JPGContext *c, 
> > GetBitContext *gb,
> >  const int is_chroma = !!plane;
> >  const uint8_t *qmat = is_chroma ? chroma_quant : luma_quant;
> >  
> > +if (get_bits_left(gb) < 1)
> > +return AVERROR_INVALIDDATA;
> > +
> >  c->bdsp.clear_block(block);
> >  dc = get_vlc2(gb, c->dc_vlc[is_chroma].table, 9, 3);
> 
> Why doesn't the VLC stuff have EOF handling? 

Because it doesnt need it in most of the cases and the get_vlc code
is quite speed critical in some codecs.
Also it would add a error return to cases that previously never
could receive an error. That would require callers to be changed
and check for this error in some cases


> There's bound to be a
> metric bajillion of cases like this strewn across the codebase..

if that was the case, the fuzzer would have likely found more cases.

thx

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

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact


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/g2meet: Check if adjusted pixel was on the stack

[Michael Niedermayer]

On Mon, Sep 09, 2019 at 11:03:48PM +0200, Tomas Härdin wrote:
> mån 2019-09-09 klockan 22:16 +0200 skrev Michael Niedermayer:
> > This basically checks if a pixel that was coded with prediction
> > and residual could have been stored using a previous case.
> > This avoids basically a string of 0 symbols stored in less than
> > 50 bytes to hit a O(n²) codepath.
> > 
> > Fixes: Timeout (too slow to wait -> immedeatly)
> > Fixes: 
> > 8668/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_G2M_fuzzer-4895946310680576
> 
> go2unpleasantplaces indeed
> 

> Something tells me there are more ways than this to hit that codepath,

yes, certainly, the question is how much input bytes that needs.
Because if it needs alot this is still a significant improvment.
Now why could it need more bytes?
The cache loops over all values in an entry and if the same value
is in it multiple times that is rather slow and causes no symbol
to be read. But if there are different values in an entry each
will cause a symbol to be read moving the bitstream forward a tiny
bit.
We eliminate/reduce (or at least thats the idea) to have duplicate values
in the cache. So that should change the input symbols from n to n*n
still how much that is in bytes would require further analysis,

But do you have a better idea than this patch ?
If not i would suggest to apply it and see what the fuzzer finds
with this.
Or we could add a counter and a threshold to the cache and
if its used more than constant*width*height then error out

The problem with g2m is its cache and stack design is integrated
into the bitstream. So fixing this in an obvious way would
change the bitstream, which of course doesnt work...

thx

> and I've made my feelings about hacks like this known already.
> 
> /Tomas
> 
> ___
> 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".

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire


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 V1 2/4] lavfi/sinc: fix memory leak in error handling path

[Paul B Mahol]

lgtm

On 9/10/19, Jun Zhao  wrote:
> From: Jun Zhao 
>
> free work_wraps in error handling path to avoid memory leak.
>
> Signed-off-by: Jun Zhao 
> ---
>  libavfilter/asrc_sinc.c |5 -
>  1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/libavfilter/asrc_sinc.c b/libavfilter/asrc_sinc.c
> index 0135eb9..90f043d 100644
> --- a/libavfilter/asrc_sinc.c
> +++ b/libavfilter/asrc_sinc.c
> @@ -239,8 +239,11 @@ static int fir_to_phase(SincContext *s, float **h, int
> *len, int *post_len, floa
>  s->rdft = s->irdft = NULL;
>  s->rdft  = av_rdft_init(av_log2(work_len), DFT_R2C);
>  s->irdft = av_rdft_init(av_log2(work_len), IDFT_C2R);
> -if (!s->rdft || !s->irdft)
> +if (!s->rdft || !s->irdft) {
> +av_free(pi_wraps);
> +av_free(work);
>  return AVERROR(ENOMEM);
> +}
>
>  av_rdft_calc(s->rdft, work);   /* Cepstral: */
>  UNPACK(work, work_len);
> --
> 1.7.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 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 V1 1/4] lavfi/anequalizer: fix memory leak in error handling path

[Paul B Mahol]

lgtm

On 9/10/19, Jun Zhao  wrote:
> From: Jun Zhao 
>
> free the pad.name in error handling path to avoid memory leak.
>
> Signed-off-by: Jun Zhao 
> ---
>  libavfilter/af_anequalizer.c |4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/libavfilter/af_anequalizer.c b/libavfilter/af_anequalizer.c
> index 03d939f..ee82474 100644
> --- a/libavfilter/af_anequalizer.c
> +++ b/libavfilter/af_anequalizer.c
> @@ -205,8 +205,10 @@ static av_cold int init(AVFilterContext *ctx)
>  .type = AVMEDIA_TYPE_VIDEO,
>  .config_props = config_video,
>  };
> -if (!vpad.name)
> +if (!vpad.name) {
> +av_freep();
>  return AVERROR(ENOMEM);
> +}
>  }
>
>  ret = ff_insert_outpad(ctx, 0, );
> --
> 1.7.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 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] Add sample_aspect_ratio and frame_rate to AVCodecParserContext

[Markus Pfau]

we use av_parser to extract stream information for custom demuxers (e.g. 
live-tv broadcasts) to extract stream information the custom demuxer 
does not provide.
This is for example codec extra data / width / height for video, and 
sample rate for audio: 
https://github.com/xbmc/xbmc/blob/master/xbmc/cores/VideoPlayer/DVDDemuxers/DVDDemuxClient.cpp#L134-L182


To set up the initial display properly (even for h/w decoders where 
ffmpeg does not do the decoding, android MediaCodec for example), we 
would like to have the pixel_aspect_ratio and if possible the frame_rate.
av_parser already resolves SPS / VUI to put width / height into the 
AVCodecParserContext. from technical POV its a few lines of code to add 
the fields.


I want to start the discussion here, and if there are chances for 
implementation, I could do this.

___
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 V1 4/4] lavf/mux: remove unnecessary packet reset

[Andreas Rheinhardt]

Jun Zhao:
> From: Jun Zhao 
> 
> remove unnecessary packet reset in av_interleaved_write_frame
> 
> Signed-off-by: Jun Zhao 
> ---
>  libavformat/mux.c |6 ++
>  1 files changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/libavformat/mux.c b/libavformat/mux.c
> index 0227c0d..9bac252 100644
> --- a/libavformat/mux.c
> +++ b/libavformat/mux.c
> @@ -1227,11 +1227,9 @@ int av_interleaved_write_frame(AVFormatContext *s, 
> AVPacket *pkt)
>  for (;; ) {
>  AVPacket opkt;
>  int ret = interleave_packet(s, , pkt, flush);
> -if (pkt) {
> -memset(pkt, 0, sizeof(*pkt));
> -av_init_packet(pkt);
> +if (pkt)
>  pkt = NULL;
> -}
> +
>  if (ret <= 0) //FIXME cleanup needed for ret<0 ?
>  return ret;
>  
I made a patchset [1] (that has already been partially pushed) whose
patch 11 deals with the memleak that happens on error in the above
code and also removes the unnecessary packet reset on success.

- Andreas

[1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2019-August/248140.html
[2]: https://ffmpeg.org/pipermail/ffmpeg-devel/2019-August/248145.html

___
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 V1 1/4] lavfi/anequalizer: fix memory leak in error handling path

[Jun Zhao]

From: Jun Zhao 

free the pad.name in error handling path to avoid memory leak.

Signed-off-by: Jun Zhao 
---
 libavfilter/af_anequalizer.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/libavfilter/af_anequalizer.c b/libavfilter/af_anequalizer.c
index 03d939f..ee82474 100644
--- a/libavfilter/af_anequalizer.c
+++ b/libavfilter/af_anequalizer.c
@@ -205,8 +205,10 @@ static av_cold int init(AVFilterContext *ctx)
 .type = AVMEDIA_TYPE_VIDEO,
 .config_props = config_video,
 };
-if (!vpad.name)
+if (!vpad.name) {
+av_freep();
 return AVERROR(ENOMEM);
+}
 }
 
 ret = ff_insert_outpad(ctx, 0, );
-- 
1.7.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 V1 3/4] lavf/avidec: fix memory leak in error handling path

[Jun Zhao]

From: Jun Zhao 

free the value in error handling path to avoid the memory leak.

Signed-off-by: Jun Zhao 
---
 libavformat/avidec.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/libavformat/avidec.c b/libavformat/avidec.c
index df78925..e3cd844 100644
--- a/libavformat/avidec.c
+++ b/libavformat/avidec.c
@@ -306,8 +306,10 @@ static int avi_read_tag(AVFormatContext *s, AVStream *st, 
uint32_t tag,
 value = av_malloc(size + 1);
 if (!value)
 return AVERROR(ENOMEM);
-if (avio_read(pb, value, size) != size)
+if (avio_read(pb, value, size) != size) {
+av_freep();
 return AVERROR_INVALIDDATA;
+}
 value[size] = 0;
 
 AV_WL32(key, tag);
-- 
1.7.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 V1 4/4] lavf/mux: remove unnecessary packet reset

[Jun Zhao]

From: Jun Zhao 

remove unnecessary packet reset in av_interleaved_write_frame

Signed-off-by: Jun Zhao 
---
 libavformat/mux.c |6 ++
 1 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/libavformat/mux.c b/libavformat/mux.c
index 0227c0d..9bac252 100644
--- a/libavformat/mux.c
+++ b/libavformat/mux.c
@@ -1227,11 +1227,9 @@ int av_interleaved_write_frame(AVFormatContext *s, 
AVPacket *pkt)
 for (;; ) {
 AVPacket opkt;
 int ret = interleave_packet(s, , pkt, flush);
-if (pkt) {
-memset(pkt, 0, sizeof(*pkt));
-av_init_packet(pkt);
+if (pkt)
 pkt = NULL;
-}
+
 if (ret <= 0) //FIXME cleanup needed for ret<0 ?
 return ret;
 
-- 
1.7.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 V1 2/4] lavfi/sinc: fix memory leak in error handling path

[Jun Zhao]

From: Jun Zhao 

free work_wraps in error handling path to avoid memory leak.

Signed-off-by: Jun Zhao 
---
 libavfilter/asrc_sinc.c |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/libavfilter/asrc_sinc.c b/libavfilter/asrc_sinc.c
index 0135eb9..90f043d 100644
--- a/libavfilter/asrc_sinc.c
+++ b/libavfilter/asrc_sinc.c
@@ -239,8 +239,11 @@ static int fir_to_phase(SincContext *s, float **h, int 
*len, int *post_len, floa
 s->rdft = s->irdft = NULL;
 s->rdft  = av_rdft_init(av_log2(work_len), DFT_R2C);
 s->irdft = av_rdft_init(av_log2(work_len), IDFT_C2R);
-if (!s->rdft || !s->irdft)
+if (!s->rdft || !s->irdft) {
+av_free(pi_wraps);
+av_free(work);
 return AVERROR(ENOMEM);
+}
 
 av_rdft_calc(s->rdft, work);   /* Cepstral: */
 UNPACK(work, work_len);
-- 
1.7.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 1/1] avcodec/h264: Fix poc_lsb in open gop context

[Paul B Mahol]

On 9/10/19, Gaullier Nicolas  wrote:
>>De : ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] De la part de
>> Kieran Kunhya
>>Envoyé : lundi 2 septembre 2019 18:12
>>Objet : Re: [FFmpeg-devel] [PATCH 1/1] avcodec/h264: Fix poc_lsb in open
>> gop context
>>
>>Patch seems good.
>>
>>Kieran
>
> Can someone please apply the patch ?
> Thanks

applied.

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

[FFmpeg-devel] [PATCH 1/1] avcodec/h264: Fix poc_lsb in open gop context

[Gaullier Nicolas]

>De : ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] De la part de 
>Kieran Kunhya
>Envoyé : lundi 2 septembre 2019 18:12
>Objet : Re: [FFmpeg-devel] [PATCH 1/1] avcodec/h264: Fix poc_lsb in open gop 
>context
>
>Patch seems good.
>
>Kieran

Can someone please apply the patch ?
Thanks
Nicolas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] avcodec/h2645_parse: simplify memset call

[Andriy Gelman]

On Sat, 07. Sep 15:55, Andriy Gelman wrote:
> From: Andriy Gelman 
> 
> Removed (new_size - pkt->nals_allocated) because this value is always 1
> during the call.
> ---
>  libavcodec/h2645_parse.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
> index 307e8643e6..ef6a6b4b4f 100644
> --- a/libavcodec/h2645_parse.c
> +++ b/libavcodec/h2645_parse.c
> @@ -461,8 +461,7 @@ int ff_h2645_packet_split(H2645Packet *pkt, const uint8_t 
> *buf, int length,
>  return AVERROR(ENOMEM);
>  
>  pkt->nals = tmp;
> -memset(pkt->nals + pkt->nals_allocated, 0,
> -   (new_size - pkt->nals_allocated) * sizeof(*pkt->nals));
> +memset(pkt->nals + pkt->nals_allocated, 0, sizeof(*pkt->nals));
>  
>  nal = >nals[pkt->nb_nals];
>  nal->skipped_bytes_pos_size = 1024; // initial buffer size
> -- 
> 2.23.0
> 

ping
___
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 v1] libavutil: add A2R10G10B10 & A2B10G10R10

[Zachary Zhou]

---
 libavutil/hwcontext_vaapi.c | 6 ++
 libavutil/pixfmt.h  | 3 +++
 2 files changed, 9 insertions(+)

diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index cf117640f2..9838250b66 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -125,6 +125,12 @@ static const VAAPIFormatDescriptor vaapi_format_map[] = {
 #endif
 MAP(BGRA, RGB32,   BGRA, 0),
 MAP(BGRX, RGB32,   BGR0, 0),
+#ifdef VA_FOURCC_A2R10G10B10
+MAP(A2R10G10B10, RGB32_10, A2R10G10B10, 0),
+#endif
+#ifdef VA_FOURCC_A2B10G10R10
+MAP(A2B10G10R10, RGB32_10, A2B10G10R10, 0),
+#endif
 MAP(RGBA, RGB32,   RGBA, 0),
 MAP(RGBX, RGB32,   RGB0, 0),
 #ifdef VA_FOURCC_ABGR
diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
index d78e863d4b..e00f129b46 100644
--- a/libavutil/pixfmt.h
+++ b/libavutil/pixfmt.h
@@ -348,6 +348,9 @@ enum AVPixelFormat {
 AV_PIX_FMT_NV24,  ///< planar YUV 4:4:4, 24bpp, 1 plane for Y and 1 
plane for the UV components, which are interleaved (first byte U and the 
following byte V)
 AV_PIX_FMT_NV42,  ///< as above, but U and V bytes are swapped
 
+AV_PIX_FMT_A2R10G10B10, ///< 10-bit Pixel RGB formats.
+AV_PIX_FMT_A2B10G10R10, ///< 10-bit Pixel BGR formats.
+
 AV_PIX_FMT_NB ///< number of pixel formats, DO NOT USE THIS if you 
want to link with shared libav* because the number of formats might differ 
between versions
 };
 
-- 
2.17.1

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

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

Re: [FFmpeg-devel] [PATCH v2] avcodec/h2645_parse: refine the code for better readiablity

[Andriy Gelman]

On Tue, 10. Sep 13:38, lance.lmw...@gmail.com wrote:
> From: Limin Wang 
> 
> Signed-off-by: Limin Wang 
> ---
>  libavcodec/h2645_parse.c | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)
> 
> diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
> index 307e8643e6..f077900617 100644
> --- a/libavcodec/h2645_parse.c
> +++ b/libavcodec/h2645_parse.c
> @@ -453,16 +453,15 @@ int ff_h2645_packet_split(H2645Packet *pkt, const 
> uint8_t *buf, int length,
>  }
>  }
>  
> -if (pkt->nals_allocated < pkt->nb_nals + 1) {
> -int new_size = pkt->nals_allocated + 1;
> -void *tmp = av_realloc_array(pkt->nals, new_size, 
> sizeof(*pkt->nals));
> +if (pkt->nb_nals >= pkt->nals_allocated) {
> +void *tmp = av_realloc_array(pkt->nals, pkt->nals_allocated + 1, 
> sizeof(*pkt->nals));
>  
>  if (!tmp)
>  return AVERROR(ENOMEM);
>  
>  pkt->nals = tmp;
> -memset(pkt->nals + pkt->nals_allocated, 0,
> -   (new_size - pkt->nals_allocated) * sizeof(*pkt->nals));

> +memset(pkt->nals + pkt->nals_allocated, 0, sizeof(*pkt->nals));

if you review a patch you should send comments, not submit your own version. 

Andriy

> +pkt->nals_allocated++;
>  
>  nal = >nals[pkt->nb_nals];
>  nal->skipped_bytes_pos_size = 1024; // initial buffer size
> @@ -470,7 +469,6 @@ int ff_h2645_packet_split(H2645Packet *pkt, const uint8_t 
> *buf, int length,
>  if (!nal->skipped_bytes_pos)
>  return AVERROR(ENOMEM);
>  
> -pkt->nals_allocated = new_size;
>  }
>  nal = >nals[pkt->nb_nals];
>  
> -- 
> 2.21.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 2/3] avcodec/pnm_parser: Use memchr() in pnm_parse()

[Paul B Mahol]

lgtm

On 9/10/19, Michael Niedermayer  wrote:
> Fixes: Timeout (45sec -> 0.5sec)
> Fixes:
> 16942/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PPM_fuzzer-5085393073995776
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/pnm_parser.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/pnm_parser.c b/libavcodec/pnm_parser.c
> index 94777d2cca..d19dbfe98c 100644
> --- a/libavcodec/pnm_parser.c
> +++ b/libavcodec/pnm_parser.c
> @@ -95,8 +95,11 @@ retry:
>  sync = bs;
>  c = *bs++;
>  if (c == '#')  {
> -while (c != '\n' && bs < end)
> -c = *bs++;
> +uint8_t *match = memchr(bs, '\n', end-bs);
> +if (match)
> +bs = match + 1;
> +else
> +break;
>  } else if (c == 'P') {
>  next = bs - pnmctx.bytestream_start + skip - 1;
>  pnmpc->ascii_scan = 0;
> --
> 2.23.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".

[FFmpeg-devel] Looking for someone who is interested in some (paid!) freelance/consulting work around/in the FFmpeg (C-)codebase.

[Thies C. Arntzen]

Hi,

First of all -> THANK YOU FOR FFMPEG!

We are currently building some software on macOS that basically does
screen recording. Today
 we use the
AVFoundation framework for all
compression and movie-file writing. We currently use the macOS VideoToolbox
and
H.265 and H.264 (on older hardware).

We have run across several shortcomings of AVFoundation and are
considering using ffmpeg in certain areas of our work. My initial
tests show that ffmpeg outperforms AVFoundation for our task (no
re-encoding, just reading and writing files) by 10x(!).

Those are the things that are top of my list

- replace file-writing with ffmpeg in our app.
- replace our own av-file concat (many small into one big) with a
ffmpeg based one.
- replace all our analysis/file read tools with ffmpeg based versions.


Having played with the ffmpg-binary on my system I have found the
following problems:

- ffmpeg does not support the "prof" sub type in the "colr" Atom (I
might be using the wrong terminology - sorry for that):

> ffmpeg -i 2019.09.05-17.05.53.2180-1680x1050/movie-small-250x156.mov
-c:v copy out.mov

[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f8f9d801a00] unsupported
color_parameter_type prof


This means that the destination file will not carry the correct
icc-profile and will not playback showing correct colors.

- ffmpeg does not copy the timescale that we use in our files (we have
settled at 600) - I believe that I might just be missing some
parameter?

Stream #0:0(und): Video: hevc (Main) (hvc1 / 0x31637668),
yuv420p(tv, progressive), 250x156 [SAR 1:1 DAR 125:78], 456 kb/s, 60
fps, 60 tbr, 600 tbn, 600 tbc (default)
becomes:
Stream #0:0(und): Video: hevc (Main) (hvc1 / 0x31637668),
yuv420p(tv, progressive), 250x156 [SAR 1:1 DAR 125:78], q=2-31, 456
kb/s, 60 fps, 60 tbr, 19200 tbn, 600 tbc (default)


dumping the files and printing pkt.pts, pkt.dts, pkt.duration shows:

original:
n # pts dts dur
1 0 0 -10 10 [key]
2 0 20 0 10
3 0 10 10 10
4 0 40 20 10

after copy:
n # pts dts dur
1 0 0 -320 320 [key]
2 0 640 0 320
3 0 320 320 320
4 0 1280 640 320


- using concat on certain files I get interesting error messages that
I'd like to reconcile:

[mov @ 0x7f8fc7818c00] Non-monotonous DTS in output stream 0:0;
previous: 10851200, current: 10851200; changing to 10851201. This may
result in incorrect timestamps in the output file.

- after concat certain files have broken frames. Concatenating the
same files using my AVFoundation based tool does mot produce broken
frames.

So - Are you interested in working with us and what would be your
conditions?

Best regards from Hamburg/Germany

Thies
+49 160 8455642
___
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] lavc/qsv: Fix MSDK initialization failure in system memory mode

[Li, Zhong]

> From: Li, Zhong
> Sent: Wednesday, September 4, 2019 11:41 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Li, Zhong 
> Subject: [PATCH 1/2] lavc/qsv: Fix MSDK initialization failure in system 
> memory
> mode
> 
> MSDK does not create internal acceleration device on Linux, So
> MFXVideoCORE_SetHandle() is necessary.
> It has been added for ff_qsv_init_session_device().
> But missed for ff_qsv_init_internal_session() due to commit
> 1f26a23 overwrited commit db89f45
> 
> Fix #7030
> 
> Signed-off-by: Zhong Li 
> ---
>  libavcodec/qsv.c  | 105
> --
>  libavcodec/qsv_internal.h |  27 +++-
>  libavcodec/qsvdec.c   |  29 +++--
>  libavcodec/qsvdec.h   |   2 +-
>  libavcodec/qsvenc.c   |  17 
>  libavcodec/qsvenc.h   |   2 +-
>  6 files changed, 151 insertions(+), 31 deletions(-)
> 
> diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c index 65ad070..126182b 100644
> --- a/libavcodec/qsv.c
> +++ b/libavcodec/qsv.c
> @@ -348,7 +348,79 @@ load_plugin_fail:
> 
>  }
> 
> -int ff_qsv_init_internal_session(AVCodecContext *avctx, mfxSession *session,
> +//This code is only required for Linux since a display handle is required.
> +//For Windows the session is complete and ready to use.
> +//For releases of Media Server Studio >= 2015 R4 the //render nodes
> +interface is preferred (/dev/dri/renderD).
> +//Using Media Server Studio 2015 R4 or newer is recommended //but the
> +older /dev/dri/card interface is also searched for broader compatibility.
> +
> +#ifdef AVCODEC_QSV_LINUX_SESSION_HANDLE static int
> +ff_qsv_set_display_handle(AVCodecContext *avctx, QSVSession *qs) {
> +// VAAPI display handle
> +int ret = 0;
> +VADisplay va_dpy = NULL;
> +VAStatus va_res = VA_STATUS_SUCCESS;
> +int major_version = 0, minor_version = 0;
> +int fd = -1;
> +char adapterpath[256];
> +int adapter_num;
> +
> +qs->fd_display = -1;
> +qs->va_display = NULL;
> +
> +//search for valid graphics device
> +for (adapter_num = 0;adapter_num < 6;adapter_num++) {
> +
> +if (adapter_num<3) {
> +snprintf(adapterpath,sizeof(adapterpath),
> +"/dev/dri/renderD%d", adapter_num+128);
> +} else {
> +snprintf(adapterpath,sizeof(adapterpath),
> +"/dev/dri/card%d", adapter_num-3);
> +}
> +
> +fd = open(adapterpath, O_RDWR);
> +if (fd < 0) {
> +av_log(avctx, AV_LOG_ERROR,
> +"mfx init: %s fd open failed\n", adapterpath);
> +continue;
> +}
> +
> +va_dpy = vaGetDisplayDRM(fd);
> +if (!va_dpy) {
> +av_log(avctx, AV_LOG_ERROR,
> +"mfx init: %s vaGetDisplayDRM failed\n", adapterpath);
> +close(fd);
> +continue;
> +}
> +
> +va_res = vaInitialize(va_dpy, _version, _version);
> +if (VA_STATUS_SUCCESS != va_res) {
> +av_log(avctx, AV_LOG_ERROR,
> +"mfx init: %s vaInitialize failed\n", adapterpath);
> +close(fd);
> +fd = -1;
> +continue;
> +} else {
> +av_log(avctx, AV_LOG_VERBOSE,
> +"mfx initialization: %s vaInitialize successful\n",adapterpath);
> +qs->fd_display = fd;
> +qs->va_display = va_dpy;
> +ret = MFXVideoCORE_SetHandle(qs->session,
> +  (mfxHandleType)MFX_HANDLE_VA_DISPLAY, (mfxHDL)va_dpy);
> +if (ret < 0) {
> +return ff_qsv_print_error(avctx, ret, "Error %d during set 
> display
> handle\n");
> +}
> +break;
> +}
> +}
> +return 0;
> +}
> +#endif //AVCODEC_QSV_LINUX_SESSION_HANDLE
> +
> +int ff_qsv_init_internal_session(AVCodecContext *avctx, QSVSession *qs,
>   const char *load_plugins)  {
>  mfxIMPL impl   = MFX_IMPL_AUTO_ANY;
> @@ -357,18 +429,24 @@ int ff_qsv_init_internal_session(AVCodecContext
> *avctx, mfxSession *session,
>  const char *desc;
>  int ret;
> 
> -ret = MFXInit(impl, , session);
> +ret = MFXInit(impl, , >session);
>  if (ret < 0)
>  return ff_qsv_print_error(avctx, ret,
>"Error initializing an internal MFX 
> session");
> 
> -ret = qsv_load_plugins(*session, load_plugins, avctx);
> +#ifdef AVCODEC_QSV_LINUX_SESSION_HANDLE
> +ret = ff_qsv_set_display_handle(avctx, qs);
> +if (ret < 0)
> +return ret;
> +#endif
> +
> +ret = qsv_load_plugins(qs->session, load_plugins, avctx);
>  if (ret < 0) {
>  av_log(avctx, AV_LOG_ERROR, "Error loading plugins\n");
>  return ret;
>  }
> 
> -MFXQueryIMPL(*session, );
> +MFXQueryIMPL(qs->session, );
> 
>  switch (MFX_IMPL_BASETYPE(impl)) {
>  case MFX_IMPL_SOFTWARE:
> @@ -758,3 +836,22 @@ int ff_qsv_init_session_frames(AVCodecContext *avctx,
> mfxSession *psession,
>