Re: [FFmpeg-devel] [PATCH v2 1/3] lavu/pix_fmt: add new pixel format x2rgb10
> -Original Message-
> From: Wang, Fei W
> Sent: Wednesday, April 22, 2020 1:23 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Wang, Fei W
> Subject: [PATCH v2 1/3] lavu/pix_fmt: add new pixel format x2rgb10
>
> The format is packed RGB with each channel 10 bits available and include 2
> bits unused.
>
> Signed-off-by: Fei Wang
> ---
> libavutil/pixdesc.c | 24
> libavutil/pixfmt.h | 3 +++
> libavutil/version.h | 2 +-
> tests/ref/fate/filter-pixdesc-x2rgb10le | 1 +
> tests/ref/fate/sws-pixdesc-query| 11 +++
> 5 files changed, 40 insertions(+), 1 deletion(-) create mode 100644
> tests/ref/fate/filter-pixdesc-x2rgb10le
>
> diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c index 9d61c52..23ec1ab
> 100644
> --- a/libavutil/pixdesc.c
> +++ b/libavutil/pixdesc.c
> @@ -252,6 +252,30 @@ static const AVPixFmtDescriptor
> av_pix_fmt_descriptors[AV_PIX_FMT_NB] = {
> },
> .flags = AV_PIX_FMT_FLAG_RGB,
> },
> +[AV_PIX_FMT_X2RGB10LE] = {
> +.name = "x2rgb10le",
> +.nb_components= 3,
> +.log2_chroma_w= 0,
> +.log2_chroma_h= 0,
> +.comp = {
> +{ 0, 4, 2, 4, 10, 3, 9, 2 },/* R */
> +{ 0, 4, 1, 2, 10, 3, 9, 3 },/* G */
> +{ 0, 4, 0, 0, 10, 3, 9, 4 },/* B */
> +},
> +.flags = AV_PIX_FMT_FLAG_RGB,
> +},
> +[AV_PIX_FMT_X2RGB10BE] = {
> +.name = "x2rgb10be",
> +.nb_components= 3,
> +.log2_chroma_w= 0,
> +.log2_chroma_h= 0,
> +.comp = {
> +{ 0, 4, 0, 4, 10, 3, 9, 2 },/* R */
> +{ 0, 4, 1, 2, 10, 3, 9, 3 },/* G */
> +{ 0, 4, 2, 0, 10, 3, 9, 4 },/* B */
> +},
> +.flags = AV_PIX_FMT_FLAG_RGB | AV_PIX_FMT_FLAG_BE,
> +},
> [AV_PIX_FMT_YUV422P] = {
> .name = "yuv422p",
> .nb_components = 3,
> diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h index 1c625cf..71058d7
> 100644
> --- a/libavutil/pixfmt.h
> +++ b/libavutil/pixfmt.h
> @@ -358,6 +358,8 @@ enum AVPixelFormat {
> AV_PIX_FMT_Y210BE,///< packed YUV 4:2:2 like YUYV422, 20bpp, data
> in the high bits, big-endian
> AV_PIX_FMT_Y210LE,///< packed YUV 4:2:2 like YUYV422, 20bpp, data
> in the high bits, little-endian
>
> +AV_PIX_FMT_X2RGB10LE,///< packed RGB 10:10:10, 30bpp, (msb)2X
> 10R 10G 10B(lsb), little-endian, X=unused/undefined
> +AV_PIX_FMT_X2RGB10BE,///< packed RGB 10:10:10, 30bpp, (msb)2X
> 10R 10G 10B(lsb), big-endian, X=unused/undefined
> 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
> };
>
> @@ -447,6 +449,7 @@ enum AVPixelFormat {
> #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_X2RGB10 AV_PIX_FMT_NE(X2RGB10BE,
> X2RGB10LE)
>
> /**
>* Chromaticity coordinates of the source primaries.
> diff --git a/libavutil/version.h b/libavutil/version.h index 70836a5..e4fa0a9
> 100644
> --- a/libavutil/version.h
> +++ b/libavutil/version.h
> @@ -79,7 +79,7 @@
> */
>
> #define LIBAVUTIL_VERSION_MAJOR 56
> -#define LIBAVUTIL_VERSION_MINOR 42
> +#define LIBAVUTIL_VERSION_MINOR 43
> #define LIBAVUTIL_VERSION_MICRO 102
>
> #define LIBAVUTIL_VERSION_INT
> AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
> diff --git a/tests/ref/fate/filter-pixdesc-x2rgb10le b/tests/ref/fate/filter-
> pixdesc-x2rgb10le
> new file mode 100644
> index 000..94c8640
> --- /dev/null
> +++ b/tests/ref/fate/filter-pixdesc-x2rgb10le
> @@ -0,0 +1 @@
> +pixdesc-x2rgb10le98d697ed4668daf535163d5e08c903bb
> diff --git a/tests/ref/fate/sws-pixdesc-query b/tests/ref/fate/sws-pixdesc-
> query
> index bc9a0d8..c3cccfa 100644
> --- a/tests/ref/fate/sws-pixdesc-query
> +++ b/tests/ref/fate/sws-pixdesc-query
> @@ -57,6 +57,8 @@ isNBPS:
>nv20le
>p010be
>p010le
> + x2rgb10be
> + x2rgb10le
>xyz12be
>xyz12le
>y210be
> @@ -141,6 +143,7 @@ isBE:
>rgb555be
>rgb565be
>rgba64be
> + x2rgb10be
>xyz12be
>y210be
>ya16be
> @@ -436,6 +439,8 @@ isRGB:
>rgb8
>rgba64be
>rgba64le
> + x2rgb10be
> + x2rgb10le
>
> Gray:
>gray
> @@ -582,6 +587,8 @@ AnyRGB:
>rgb8
>rgba64be
>rgba64le
> + x2rgb10be
> + x2rgb10le
>
> ALPHA:
>ayuv64be
> @@ -689,6 +696,8 @@ Packed:
>rgba64le
>uyvy422
>uyyvyy411
> + x2rgb10be
> + x2rgb10le
>xyz12be
>xyz12le
>y210be
> @@ -853,6 +862,8 @@ PackedRGB:
>rgb8
>rgba64be
>rgba64le
> + x2rgb10be
> + x2rgb10le
>
> PlanarRGB:
>gbrap
> --
> 2.7.4
V2: fixed FATE fail for separate patch in this patch series.
___
ffmpeg-devel mailing list
Re: [FFmpeg-devel] [PATCH v4 2/7] lavutil: add DOVI related header
On Tue, Apr 21, 2020 at 2:23 PM Anton Khirnov wrote: > > Quoting myp...@gmail.com (2020-04-21 04:47:42) > > On Mon, Apr 20, 2020 at 9:08 PM Anton Khirnov wrote: > > > > > > Quoting Jean-Baptiste Kempf (2020-04-19 10:25:07) > > > > I'd like to ask opinions whether a installed header for just one > > > > structure is a good idea. > > > > > > I see no problem with it. More smaller headers is better that a few big > > > headers. > > > > > > Another issue is that this struct has no constructor and thus cannot be > > > extended without breaking ABI. > > > > > This structure is part of API, so I can't find a simple way to extend > > without break the ABI, I believe there are similar problems for > > AVSphericalMapping > > No, AVSphericalMapping does not have that problem since it has a > constructor. > Will add a constructor av_dovi_alloc with static inline in the header for this comment ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 3/3] lavu/hwcontext_vaapi: add vaapi_format_map support for x2rgb10
Signed-off-by: Fei Wang
---
libavutil/hwcontext_vaapi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index b306965..50727fb 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -136,6 +136,9 @@ static const VAAPIFormatDescriptor vaapi_format_map[] = {
#endif
MAP(ARGB, RGB32, ARGB, 0),
MAP(XRGB, RGB32, 0RGB, 0),
+#ifdef VA_FOURCC_X2R10G10B10
+MAP(X2R10G10B10, RGB32_10, X2RGB10, 0),
+#endif
};
#undef MAP
--
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 v2 2/3] swscale: Add swscale input/output support for X2RGB10LE
Signed-off-by: Fei Wang
---
libswscale/input.c | 13 -
libswscale/output.c | 14 ++
libswscale/utils.c | 1 +
libswscale/yuv2rgb.c | 22 ++
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 +
15 files changed, 60 insertions(+), 1 deletion(-)
diff --git a/libswscale/input.c b/libswscale/input.c
index 099661c..05fdc2f 100644
--- a/libswscale/input.c
+++ b/libswscale/input.c
@@ -244,7 +244,8 @@ rgb48funcs(bgr, BE, AV_PIX_FMT_BGR48BE)
#define input_pixel(i) ((origin == AV_PIX_FMT_RGBA || \
origin == AV_PIX_FMT_BGRA || \
origin == AV_PIX_FMT_ARGB || \
- origin == AV_PIX_FMT_ABGR)\
+ origin == AV_PIX_FMT_ABGR || \
+ origin == AV_PIX_FMT_X2RGB10)\
? AV_RN32A([(i) * 4]) \
: (isBE(origin) ? AV_RB16([(i) * 2])\
: AV_RL16([(i) * 2])))
@@ -391,6 +392,7 @@ rgb16_32_wrapper(AV_PIX_FMT_BGR444BE, bgr12be, 0, 0, 0, 0,
0x000F, 0x00F0,
rgb16_32_wrapper(AV_PIX_FMT_RGB565BE, rgb16be, 0, 0, 0, 0, 0xF800, 0x07E0,
0x001F, 0, 5, 11, RGB2YUV_SHIFT + 8)
rgb16_32_wrapper(AV_PIX_FMT_RGB555BE, rgb15be, 0, 0, 0, 0, 0x7C00, 0x03E0,
0x001F, 0, 5, 10, RGB2YUV_SHIFT + 7)
rgb16_32_wrapper(AV_PIX_FMT_RGB444BE, rgb12be, 0, 0, 0, 0, 0x0F00, 0x00F0,
0x000F, 0, 4, 8, RGB2YUV_SHIFT + 4)
+rgb16_32_wrapper(AV_PIX_FMT_X2RGB10LE, rgb30le, 16, 6, 0, 0, 0x3FF0,
0xFFC00, 0x3FF, 0, 0, 4, RGB2YUV_SHIFT + 6)
static void gbr24pToUV_half_c(uint8_t *_dstU, uint8_t *_dstV,
const uint8_t *gsrc, const uint8_t *bsrc, const
uint8_t *rsrc,
@@ -1260,6 +1262,9 @@ av_cold void ff_sws_init_input_funcs(SwsContext *c)
case AV_PIX_FMT_RGB444BE:
c->chrToYV12 = rgb12beToUV_half_c;
break;
+case AV_PIX_FMT_X2RGB10LE:
+c->chrToYV12 = rgb30leToUV_half_c;
+break;
}
} else {
switch (srcFormat) {
@@ -1341,6 +1346,9 @@ av_cold void ff_sws_init_input_funcs(SwsContext *c)
case AV_PIX_FMT_RGB444BE:
c->chrToYV12 = rgb12beToUV_c;
break;
+case AV_PIX_FMT_X2RGB10LE:
+c->chrToYV12 = rgb30leToUV_c;
+break;
}
}
@@ -1610,6 +1618,9 @@ av_cold void ff_sws_init_input_funcs(SwsContext *c)
case AV_PIX_FMT_Y210LE:
c->lumToYV12 = y210le_Y_c;
break;
+case AV_PIX_FMT_X2RGB10LE:
+c->lumToYV12 =rgb30leToY_c;
+break;
}
if (c->needAlpha) {
if (is16BPS(srcFormat) || isNBPS(srcFormat)) {
diff --git a/libswscale/output.c b/libswscale/output.c
index 68f43ff..f9528af 100644
--- a/libswscale/output.c
+++ b/libswscale/output.c
@@ -1602,6 +1602,13 @@ yuv2rgb_write(uint8_t *_dest, int i, int Y1, int Y2,
dest[i * 2 + 0] = r[Y1 + dr1] + g[Y1 + dg1] + b[Y1 + db1];
dest[i * 2 + 1] = r[Y2 + dr2] + g[Y2 + dg2] + b[Y2 + db2];
+} else if (target == AV_PIX_FMT_X2RGB10) {
+uint32_t *dest = (uint32_t *) _dest;
+const uint32_t *r = (const uint32_t *) _r;
+const uint32_t *g = (const uint32_t *) _g;
+const uint32_t *b = (const uint32_t *) _b;
+dest[i * 2 + 0] = r[Y1] + g[Y1] + b[Y1];
+dest[i * 2 + 1] = r[Y2] + g[Y2] + b[Y2];
} else /* 8/4 bits */ {
uint8_t *dest = (uint8_t *) _dest;
const uint8_t *r = (const uint8_t *) _r;
@@ -1839,6 +1846,7 @@ YUV2RGBWRAPPER(yuv2rgb,, 12,AV_PIX_FMT_RGB444,0)
YUV2RGBWRAPPER(yuv2rgb,, 8,AV_PIX_FMT_RGB8, 0)
YUV2RGBWRAPPER(yuv2rgb,, 4,AV_PIX_FMT_RGB4, 0)
YUV2RGBWRAPPER(yuv2rgb,, 4b, AV_PIX_FMT_RGB4_BYTE, 0)
+YUV2RGBWRAPPER(yuv2, rgb, x2rgb10, AV_PIX_FMT_X2RGB10, 0)
static av_always_inline void yuv2rgb_write_full(SwsContext *c,
uint8_t *dest, int i, int Y, int A, int U, int V,
@@ -2892,6 +2900,12 @@ av_cold void ff_sws_init_output_funcs(SwsContext *c,
*yuv2packed2 = yuv2rgb4b_2_c;
*yuv2packedX = yuv2rgb4b_X_c;
break;
+case AV_PIX_FMT_X2RGB10LE:
+case AV_PIX_FMT_X2RGB10BE:
+*yuv2packed1 = yuv2x2rgb10_1_c;
+
[FFmpeg-devel] [PATCH v2 1/3] lavu/pix_fmt: add new pixel format x2rgb10
The format is packed RGB with each channel 10 bits available and
include 2 bits unused.
Signed-off-by: Fei Wang
---
libavutil/pixdesc.c | 24
libavutil/pixfmt.h | 3 +++
libavutil/version.h | 2 +-
tests/ref/fate/filter-pixdesc-x2rgb10le | 1 +
tests/ref/fate/sws-pixdesc-query| 11 +++
5 files changed, 40 insertions(+), 1 deletion(-)
create mode 100644 tests/ref/fate/filter-pixdesc-x2rgb10le
diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
index 9d61c52..23ec1ab 100644
--- a/libavutil/pixdesc.c
+++ b/libavutil/pixdesc.c
@@ -252,6 +252,30 @@ static const AVPixFmtDescriptor
av_pix_fmt_descriptors[AV_PIX_FMT_NB] = {
},
.flags = AV_PIX_FMT_FLAG_RGB,
},
+[AV_PIX_FMT_X2RGB10LE] = {
+.name = "x2rgb10le",
+.nb_components= 3,
+.log2_chroma_w= 0,
+.log2_chroma_h= 0,
+.comp = {
+{ 0, 4, 2, 4, 10, 3, 9, 2 }, /* R */
+{ 0, 4, 1, 2, 10, 3, 9, 3 }, /* G */
+{ 0, 4, 0, 0, 10, 3, 9, 4 }, /* B */
+},
+.flags = AV_PIX_FMT_FLAG_RGB,
+},
+[AV_PIX_FMT_X2RGB10BE] = {
+.name = "x2rgb10be",
+.nb_components= 3,
+.log2_chroma_w= 0,
+.log2_chroma_h= 0,
+.comp = {
+{ 0, 4, 0, 4, 10, 3, 9, 2 }, /* R */
+{ 0, 4, 1, 2, 10, 3, 9, 3 }, /* G */
+{ 0, 4, 2, 0, 10, 3, 9, 4 }, /* B */
+},
+.flags = AV_PIX_FMT_FLAG_RGB | AV_PIX_FMT_FLAG_BE,
+},
[AV_PIX_FMT_YUV422P] = {
.name = "yuv422p",
.nb_components = 3,
diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
index 1c625cf..71058d7 100644
--- a/libavutil/pixfmt.h
+++ b/libavutil/pixfmt.h
@@ -358,6 +358,8 @@ enum AVPixelFormat {
AV_PIX_FMT_Y210BE,///< packed YUV 4:2:2 like YUYV422, 20bpp, data in
the high bits, big-endian
AV_PIX_FMT_Y210LE,///< packed YUV 4:2:2 like YUYV422, 20bpp, data in
the high bits, little-endian
+AV_PIX_FMT_X2RGB10LE,///< packed RGB 10:10:10, 30bpp, (msb)2X 10R 10G
10B(lsb), little-endian, X=unused/undefined
+AV_PIX_FMT_X2RGB10BE,///< packed RGB 10:10:10, 30bpp, (msb)2X 10R 10G
10B(lsb), big-endian, X=unused/undefined
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
};
@@ -447,6 +449,7 @@ enum AVPixelFormat {
#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_X2RGB10 AV_PIX_FMT_NE(X2RGB10BE, X2RGB10LE)
/**
* Chromaticity coordinates of the source primaries.
diff --git a/libavutil/version.h b/libavutil/version.h
index 70836a5..e4fa0a9 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -79,7 +79,7 @@
*/
#define LIBAVUTIL_VERSION_MAJOR 56
-#define LIBAVUTIL_VERSION_MINOR 42
+#define LIBAVUTIL_VERSION_MINOR 43
#define LIBAVUTIL_VERSION_MICRO 102
#define LIBAVUTIL_VERSION_INT AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
diff --git a/tests/ref/fate/filter-pixdesc-x2rgb10le
b/tests/ref/fate/filter-pixdesc-x2rgb10le
new file mode 100644
index 000..94c8640
--- /dev/null
+++ b/tests/ref/fate/filter-pixdesc-x2rgb10le
@@ -0,0 +1 @@
+pixdesc-x2rgb10le98d697ed4668daf535163d5e08c903bb
diff --git a/tests/ref/fate/sws-pixdesc-query b/tests/ref/fate/sws-pixdesc-query
index bc9a0d8..c3cccfa 100644
--- a/tests/ref/fate/sws-pixdesc-query
+++ b/tests/ref/fate/sws-pixdesc-query
@@ -57,6 +57,8 @@ isNBPS:
nv20le
p010be
p010le
+ x2rgb10be
+ x2rgb10le
xyz12be
xyz12le
y210be
@@ -141,6 +143,7 @@ isBE:
rgb555be
rgb565be
rgba64be
+ x2rgb10be
xyz12be
y210be
ya16be
@@ -436,6 +439,8 @@ isRGB:
rgb8
rgba64be
rgba64le
+ x2rgb10be
+ x2rgb10le
Gray:
gray
@@ -582,6 +587,8 @@ AnyRGB:
rgb8
rgba64be
rgba64le
+ x2rgb10be
+ x2rgb10le
ALPHA:
ayuv64be
@@ -689,6 +696,8 @@ Packed:
rgba64le
uyvy422
uyyvyy411
+ x2rgb10be
+ x2rgb10le
xyz12be
xyz12le
y210be
@@ -853,6 +862,8 @@ PackedRGB:
rgb8
rgba64be
rgba64le
+ x2rgb10be
+ x2rgb10le
PlanarRGB:
gbrap
--
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 v5 3/7] lavf/mpegts: support DOVI Video Stream Descriptor
From: vacingfang
support DOVI Video Stream Descriptor from Dolby Vision Streams
Within the MPEG-2 Transport Stream Format V1.2
From the spec: https://www.dolby.com/us/en/technologies/\
dolby-vision/dolby-vision-bitstreams-in-mpeg-2-transport-\
stream-multiplex-v1.2.pdf.
export the DOVI information with sidedata.
Signed-off-by: vacingfang
---
libavformat/mpegts.c | 48
1 file changed, 48 insertions(+)
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index a4ecb2e..ff3898c 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -28,6 +28,7 @@
#include "libavutil/mathematics.h"
#include "libavutil/opt.h"
#include "libavutil/avassert.h"
+#include "libavutil/dovi_meta.h"
#include "libavcodec/bytestream.h"
#include "libavcodec/get_bits.h"
#include "libavcodec/opus.h"
@@ -2146,6 +2147,53 @@ int ff_parse_mpeg2_descriptor(AVFormatContext *fc,
AVStream *st, int stream_type
st->request_probe= 0;
}
break;
+case 0xb0: /* DOVI video stream descriptor */
+{
+uint32_t buf;
+AVDOVIDecoderConfigurationRecord *dovi;
+size_t dovi_size;
+int ret;
+if (desc_end - *pp < 4) // (8 + 8 + 7 + 6 + 1 + 1 + 1) / 8
+return AVERROR_INVALIDDATA;
+
+dovi = av_dovi_alloc(_size);
+if (!dovi)
+return AVERROR(ENOMEM);
+
+dovi->dv_version_major = get8(pp, desc_end);
+dovi->dv_version_minor = get8(pp, desc_end);
+buf = get16(pp, desc_end);
+dovi->dv_profile= (buf >> 9) & 0x7f;// 7 bits
+dovi->dv_level = (buf >> 3) & 0x3f;// 6 bits
+dovi->rpu_present_flag = (buf >> 2) & 0x01;// 1 bit
+dovi->el_present_flag = (buf >> 1) & 0x01;// 1 bit
+dovi->bl_present_flag = buf & 0x01;// 1 bit
+if (desc_end - *pp >= 20) { // 4 + 4 * 4
+buf = get8(pp, desc_end);
+dovi->dv_bl_signal_compatibility_id = (buf >> 4) & 0x0f; // 4
bits
+} else {
+// 0 stands for None
+// Dolby Vision V1.2.93 profiles and levels
+dovi->dv_bl_signal_compatibility_id = 0;
+}
+
+ret = av_stream_add_side_data(st, AV_PKT_DATA_DOVI_CONF,
+ (uint8_t *)dovi, dovi_size);
+if (ret < 0) {
+av_freep(dovi);
+return ret;
+}
+
+av_log(fc, AV_LOG_TRACE, "DOVI, version: %d.%d, profile: %d,
level: %d, "
+ "rpu flag: %d, el flag: %d, bl flag: %d, compatibility id:
%d\n",
+ dovi->dv_version_major, dovi->dv_version_minor,
+ dovi->dv_profile, dovi->dv_level,
+ dovi->rpu_present_flag,
+ dovi->el_present_flag,
+ dovi->bl_present_flag,
+ dovi->dv_bl_signal_compatibility_id);
+}
+break;
default:
break;
}
--
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 v5 1/7] lavc: add a new sidedata type for DOVI
From: Jun Zhao
add a new sidedata type for DOVI.
Signed-off-by: Jun Zhao
---
libavcodec/avpacket.c | 1 +
libavcodec/packet.h | 9 +
2 files changed, 10 insertions(+)
diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
index ad020ee..1b53451 100644
--- a/libavcodec/avpacket.c
+++ b/libavcodec/avpacket.c
@@ -396,6 +396,7 @@ const char *av_packet_side_data_name(enum
AVPacketSideDataType type)
case AV_PKT_DATA_ENCRYPTION_INFO:return "Encryption info";
case AV_PKT_DATA_AFD:return "Active Format
Description data";
case AV_PKT_DATA_ICC_PROFILE:return "ICC Profile";
+case AV_PKT_DATA_DOVI_CONF: return "DOVI configuration
record";
}
return NULL;
}
diff --git a/libavcodec/packet.h b/libavcodec/packet.h
index e53abe6..41485f4 100644
--- a/libavcodec/packet.h
+++ b/libavcodec/packet.h
@@ -274,6 +274,15 @@ enum AVPacketSideDataType {
AV_PKT_DATA_ICC_PROFILE,
/**
+ * DOVI configuration
+ * ref:
+ * dolby-vision-bitstreams-within-the-iso-base-media-file-format-v2.1.2,
section 2.2
+ * dolby-vision-bitstreams-in-mpeg-2-transport-stream-multiplex-v1.2,
section 3.3
+ * Tags are stored in struct AVDOVIDecoderConfigurationRecord.
+ */
+AV_PKT_DATA_DOVI_CONF,
+
+/**
* The number of side data types.
* This is not part of the public API/ABI in the sense that it may
* change when new side data types are added.
--
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 v5 2/7] lavutil: add DOVI related header
From: vacingfang
add DOVI related struct
Signed-off-by: vacingfang
---
libavutil/Makefile| 1 +
libavutil/dovi_meta.h | 80 +++
2 files changed, 81 insertions(+)
create mode 100644 libavutil/dovi_meta.h
diff --git a/libavutil/Makefile b/libavutil/Makefile
index 8feb029..1aac84c 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -23,6 +23,7 @@ HEADERS = adler32.h
\
des.h \
dict.h\
display.h \
+ dovi_meta.h \
downmix_info.h\
encryption_info.h \
error.h \
diff --git a/libavutil/dovi_meta.h b/libavutil/dovi_meta.h
new file mode 100644
index 000..41be214
--- /dev/null
+++ b/libavutil/dovi_meta.h
@@ -0,0 +1,80 @@
+/*
+ * Copyright (c) 2020 Vacing Fang
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file
+ * DOVI configuration
+ */
+
+
+#ifndef AVUTIL_DOVI_META_H
+#define AVUTIL_DOVI_META_H
+
+#include
+#include "mem.h"
+
+/*
+ * DOVI configuration
+ * ref: dolby-vision-bitstreams-within-the-iso-base-media-file-format-v2.1.2
+dolby-vision-bitstreams-in-mpeg-2-transport-stream-multiplex-v1.2
+ * @code
+ * uint8_t dv_version_major, the major version number that the stream
complies with
+ * uint8_t dv_version_minor, the minor version number that the stream
complies with
+ * uint8_t dv_profile, the Dolby Vision profile
+ * uint8_t dv_level, the Dolby Vision level
+ * uint8_t rpu_present_flag
+ * uint8_t el_present_flag
+ * uint8_t bl_present_flag
+ * uint8_t dv_bl_signal_compatibility_id
+ * @endcode
+ *
+ * @note The struct must be allocated with av_dovi_alloc() and
+ * its size is not a part of the public ABI.
+ */
+typedef struct AVDOVIDecoderConfigurationRecord {
+uint8_t dv_version_major;
+uint8_t dv_version_minor;
+uint8_t dv_profile;
+uint8_t dv_level;
+uint8_t rpu_present_flag;
+uint8_t el_present_flag;
+uint8_t bl_present_flag;
+uint8_t dv_bl_signal_compatibility_id;
+} AVDOVIDecoderConfigurationRecord;
+
+/**
+ * Allocate a AVDOVIDecoderConfigurationRecord structure and initialize its
+ * fields to default values.
+ *
+ * @return the newly allocated struct or NULL on failure
+ */
+static inline AVDOVIDecoderConfigurationRecord *av_dovi_alloc(size_t *size)
+{
+AVDOVIDecoderConfigurationRecord *dovi =
+av_mallocz(sizeof(AVDOVIDecoderConfigurationRecord));
+if (!dovi)
+return NULL;
+
+ if (size)
+*size = sizeof(*dovi);
+
+return dovi;
+}
+#endif /* AVUTIL_DOVI_META_H */
--
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 v5 0/7] Support Dolby Vision
From: Jun Zhao V5: - add a constructor for DOVI (tks Anton Khirnov) - some minor coding style clean V4: - change the DOVI dump message (tks Jan Ekström) - fix the file order in Makefile V3: - rename the file name for Dolby Vision trademark risk(tks Jean-Baptiste Kempf) - fix other typo issue V2: - used sidedata for Dolby Vision information (tks Jan Ekström's suggestion) - enabled dumping Dolby Vision sidedata for ffmpeg/ffprobe tools - enabled dvcC/dvvC box from Dolby Vision sidedata Jun Zhao (4): lavc: add a new sidedata type for DOVI lavf/dump: dump DOVI side data fftools/ffprobe: support DOVI sidedata lavf/movenc: enable dvcC/dvvC box support from DOVI sidedata vacingfang (3): lavutil: add DOVI related header lavf/mpegts: support DOVI Video Stream Descriptor lavf/mov: support dvcC/dvvC box for DOVI fftools/ffprobe.c | 11 +++ libavcodec/avpacket.c | 1 + libavcodec/packet.h | 9 ++ libavformat/dump.c| 23 +++ libavformat/mov.c | 60 ++ libavformat/movenc.c | 35 ++ libavformat/mpegts.c | 48 +++ libavutil/Makefile| 1 + libavutil/dovi_meta.h | 80 +++ 9 files changed, 268 insertions(+) create mode 100644 libavutil/dovi_meta.h -- 2.7.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] lavf/tls_mbedtls: fix resource leak
On Mon, Apr 20, 2020 at 4:24 PM Jun Zhao wrote: > > From: Jun Zhao > > fix resource leak in mbedtls part. > > fix #8614 > > Signed-off-by: Jun Zhao > --- > libavformat/tls_mbedtls.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/libavformat/tls_mbedtls.c b/libavformat/tls_mbedtls.c > index 9b80a1e..965adf1 100644 > --- a/libavformat/tls_mbedtls.c > +++ b/libavformat/tls_mbedtls.c > @@ -62,6 +62,7 @@ static int tls_close(URLContext *h) > mbedtls_ctr_drbg_free(_ctx->ctr_drbg_context); > mbedtls_entropy_free(_ctx->entropy_context); > > +ffurl_closep(_ctx->tls_shared.tcp); > return 0; > } > > -- > 2.7.4 > Will apply the patch, tks ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/3] lavu/pix_fmt: add new pixel format x2rgb10
> -Original Message- > From: ffmpeg-devel On Behalf Of > Vittorio Giovara > Sent: Wednesday, April 22, 2020 11:02 AM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH 1/3] lavu/pix_fmt: add new pixel format > x2rgb10 > > On Tue, Apr 21, 2020 at 10:32 PM Wang, Fei W > wrote: > > > > > > > > -Original Message- > > > From: ffmpeg-devel On Behalf Of > > > Hendrik Leppkes > > > Sent: Tuesday, April 21, 2020 4:08 PM > > > To: FFmpeg development discussions and patches > > de...@ffmpeg.org> > > > Subject: Re: [FFmpeg-devel] [PATCH 1/3] lavu/pix_fmt: add new pixel > > format > > > x2rgb10 > > > > > > On Tue, Apr 21, 2020 at 9:53 AM Fei Wang > wrote: > > > > > > > > The format is packed RGB with each channel 10 bits available and > > > > include 2 bits unused. > > > > > > > > > > The name of this pix_fmt seems very confusing, and the entire format > > seems > > > very specific. What is such a packed RGB format really good for in > > ffmpeg? > > This format is named as X2R10G10B10 in libva, but I think X2RGB10 is > > more concise. There is similar format name defined in Gstreamer like > RGB10A2. > > Because there are lots of Codec/Filter based on third-party library in > > ffmpeg, while in these library they may support some specific format > > like P010/Y210/Y410.., so in Ffmpeg side it should support this kinds > > of formats first, at least the definition. > > > > In my opinion, unless it's needed by a ffmpeg features or it's fully supported > in swscale so that ffmpeg users may use it, it should not go in. Yes, this format is need in ffmpeg-vaapi. And my another 2 patches is the implementation of swscale and ffmpeg-vaapi csc for this format. > -- > Vittorio > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org > with subject "unsubscribe". ___ ffmpeg-devel 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 v5 7/7] lavf/movenc: enable dvcC/dvvC box support from DOVI sidedata
From: Jun Zhao
enable dvcC/dvvC box support from DOVI sidedata.
Signed-off-by: Jun Zhao
---
libavformat/movenc.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 253cff8..556dd06 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -51,6 +51,7 @@
#include "libavutil/pixdesc.h"
#include "libavutil/stereo3d.h"
#include "libavutil/timecode.h"
+#include "libavutil/dovi_meta.h"
#include "libavutil/color_utils.h"
#include "hevc.h"
#include "rtpenc.h"
@@ -1814,6 +1815,36 @@ static int mov_write_sv3d_tag(AVFormatContext *s,
AVIOContext *pb, AVSphericalMa
return update_size(pb, sv3d_pos);
}
+static int mov_write_dvcc_dvvc_tag(AVFormatContext *s, AVIOContext *pb,
AVDOVIDecoderConfigurationRecord *dovi)
+{
+avio_wb32(pb, 32); /* size = 8 + 24 */
+if (dovi->dv_profile > 7)
+ffio_wfourcc(pb, "dvvC");
+else
+ffio_wfourcc(pb, "dvcC");
+avio_w8(pb, dovi->dv_version_major);
+avio_w8(pb, dovi->dv_version_minor);
+avio_wb16(pb, (dovi->dv_profile << 9) | (dovi->dv_level << 3) |
+ (dovi->rpu_present_flag << 2) | (dovi->el_present_flag << 1) |
+ dovi->bl_present_flag);
+avio_wb32(pb, (dovi->dv_bl_signal_compatibility_id << 28) | 0);
+
+avio_wb32(pb, 0); /* reserved */
+avio_wb32(pb, 0); /* reserved */
+avio_wb32(pb, 0); /* reserved */
+avio_wb32(pb, 0); /* reserved */
+av_log(s, AV_LOG_DEBUG, "DOVI in %s box, version: %d.%d, profile: %d,
level: %d, "
+ "rpu flag: %d, el flag: %d, bl flag: %d, compatibility id: %d\n",
+ dovi->dv_profile > 7 ? "dvvC" : "dvcC",
+ dovi->dv_version_major, dovi->dv_version_minor,
+ dovi->dv_profile, dovi->dv_level,
+ dovi->rpu_present_flag,
+ dovi->el_present_flag,
+ dovi->bl_present_flag,
+ dovi->dv_bl_signal_compatibility_id);
+return 32; /* 8 + 24 */
+}
+
static int mov_write_clap_tag(AVIOContext *pb, MOVTrack *track)
{
avio_wb32(pb, 40);
@@ -2147,11 +2178,15 @@ static int mov_write_video_tag(AVFormatContext *s,
AVIOContext *pb, MOVMuxContex
if (track->mode == MODE_MP4 && mov->fc->strict_std_compliance <=
FF_COMPLIANCE_UNOFFICIAL) {
AVStereo3D* stereo_3d = (AVStereo3D*)
av_stream_get_side_data(track->st, AV_PKT_DATA_STEREO3D, NULL);
AVSphericalMapping* spherical_mapping =
(AVSphericalMapping*)av_stream_get_side_data(track->st, AV_PKT_DATA_SPHERICAL,
NULL);
+AVDOVIDecoderConfigurationRecord *dovi =
(AVDOVIDecoderConfigurationRecord *)
+
av_stream_get_side_data(track->st, AV_PKT_DATA_DOVI_CONF, NULL);;
if (stereo_3d)
mov_write_st3d_tag(s, pb, stereo_3d);
if (spherical_mapping)
mov_write_sv3d_tag(mov->fc, pb, spherical_mapping);
+if (dovi)
+mov_write_dvcc_dvvc_tag(s, pb, dovi);
}
if (track->par->sample_aspect_ratio.den &&
track->par->sample_aspect_ratio.num) {
--
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 v5 4/7] lavf/mov: support dvcC/dvvC box for DOVI
From: vacingfang
support dvcC/dvcC box from spec Dolby Vision Streams Within the
ISO Base MediaFile Format Version 2.1.2
(https://www.dolby.com/in/en/technologies/dolby-vision/dolby-vision\
-bitstreams-within-the-iso-base-media-file-format-v2.1.2.pdf)
export the DOVI information to sidedata.
Signed-off-by: vacingfang
---
libavformat/mov.c | 60 +++
1 file changed, 60 insertions(+)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 8e8aba7..3d6fef6 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -46,6 +46,7 @@
#include "libavutil/spherical.h"
#include "libavutil/stereo3d.h"
#include "libavutil/timecode.h"
+#include "libavutil/dovi_meta.h"
#include "libavcodec/ac3tab.h"
#include "libavcodec/flac.h"
#include "libavcodec/mpegaudiodecheader.h"
@@ -6786,6 +6787,63 @@ static int mov_read_dmlp(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
return 0;
}
+static int mov_read_dvcc_dvvc(MOVContext *c, AVIOContext *pb, MOVAtom atom)
+{
+AVStream *st;
+uint32_t buf;
+AVDOVIDecoderConfigurationRecord *dovi;
+size_t dovi_size;
+int ret;
+
+if (c->fc->nb_streams < 1)
+return 0;
+st = c->fc->streams[c->fc->nb_streams-1];
+
+if ((uint64_t)atom.size > (1<<30) || atom.size < 4)
+return AVERROR_INVALIDDATA;
+
+dovi = av_dovi_alloc(_size);
+if (!dovi)
+return AVERROR(ENOMEM);
+
+dovi->dv_version_major = avio_r8(pb);
+dovi->dv_version_minor = avio_r8(pb);
+
+buf = avio_rb16(pb);
+dovi->dv_profile= (buf >> 9) & 0x7f;// 7 bits
+dovi->dv_level = (buf >> 3) & 0x3f;// 6 bits
+dovi->rpu_present_flag = (buf >> 2) & 0x01;// 1 bit
+dovi->el_present_flag = (buf >> 1) & 0x01;// 1 bit
+dovi->bl_present_flag = buf & 0x01;// 1 bit
+if (atom.size >= 24) { // 4 + 4 + 4 * 4
+buf = avio_r8(pb);
+dovi->dv_bl_signal_compatibility_id = (buf >> 4) & 0x0f; // 4 bits
+} else {
+// 0 stands for None
+// Dolby Vision V1.2.93 profiles and levels
+dovi->dv_bl_signal_compatibility_id = 0;
+}
+
+ret = av_stream_add_side_data(st, AV_PKT_DATA_DOVI_CONF,
+ (uint8_t *)dovi, dovi_size);
+if (ret < 0) {
+av_freep(dovi);
+return ret;
+}
+
+av_log(c, AV_LOG_TRACE, "DOVI in dvcC/dvvC box, version: %d.%d, profile:
%d, level: %d, "
+ "rpu flag: %d, el flag: %d, bl flag: %d, compatibility id: %d\n",
+ dovi->dv_version_major, dovi->dv_version_minor,
+ dovi->dv_profile, dovi->dv_level,
+ dovi->rpu_present_flag,
+ dovi->el_present_flag,
+ dovi->bl_present_flag,
+ dovi->dv_bl_signal_compatibility_id
+);
+
+return 0;
+}
+
static const MOVParseTableEntry mov_default_parse_table[] = {
{ MKTAG('A','C','L','R'), mov_read_aclr },
{ MKTAG('A','P','R','G'), mov_read_avid },
@@ -6881,6 +6939,8 @@ static const MOVParseTableEntry mov_default_parse_table[]
= {
{ MKTAG('v','p','c','C'), mov_read_vpcc },
{ MKTAG('m','d','c','v'), mov_read_mdcv },
{ MKTAG('c','l','l','i'), mov_read_clli },
+{ MKTAG('d','v','c','C'), mov_read_dvcc_dvvc },
+{ MKTAG('d','v','v','C'), mov_read_dvcc_dvvc },
{ 0, NULL }
};
--
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 v5 5/7] lavf/dump: dump DOVI side data
From: Jun Zhao
dump DOVI side data.
Signed-off-by: Jun Zhao
---
libavformat/dump.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/libavformat/dump.c b/libavformat/dump.c
index 220f404..9578b88 100644
--- a/libavformat/dump.c
+++ b/libavformat/dump.c
@@ -27,6 +27,7 @@
#include "libavutil/intreadwrite.h"
#include "libavutil/log.h"
#include "libavutil/mastering_display_metadata.h"
+#include "libavutil/dovi_meta.h"
#include "libavutil/mathematics.h"
#include "libavutil/opt.h"
#include "libavutil/avstring.h"
@@ -387,6 +388,24 @@ static void dump_spherical(void *ctx, AVCodecParameters
*par, AVPacketSideData *
}
}
+static void dump_dovi_conf(void *ctx, AVPacketSideData* sd)
+{
+AVDOVIDecoderConfigurationRecord *dovi = (AVDOVIDecoderConfigurationRecord
*)sd->data;
+if (sd->size < sizeof(*dovi)) {
+av_log(ctx, AV_LOG_ERROR, "invalid data");
+return;
+}
+
+av_log(ctx, AV_LOG_INFO, "version: %d.%d, profile: %d, level: %d, "
+ "rpu flag: %d, el flag: %d, bl flag: %d, compatibility id: %d",
+ dovi->dv_version_major, dovi->dv_version_minor,
+ dovi->dv_profile, dovi->dv_level,
+ dovi->rpu_present_flag,
+ dovi->el_present_flag,
+ dovi->bl_present_flag,
+ dovi->dv_bl_signal_compatibility_id);
+}
+
static void dump_sidedata(void *ctx, AVStream *st, const char *indent)
{
int i;
@@ -449,6 +468,10 @@ static void dump_sidedata(void *ctx, AVStream *st, const
char *indent)
case AV_PKT_DATA_ICC_PROFILE:
av_log(ctx, AV_LOG_INFO, "ICC Profile");
break;
+case AV_PKT_DATA_DOVI_CONF:
+av_log(ctx, AV_LOG_INFO, "DOVI configuration record: ");
+dump_dovi_conf(ctx, );
+break;
default:
av_log(ctx, AV_LOG_INFO,
"unknown side data type %d (%d bytes)", sd.type, sd.size);
--
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 v5 6/7] fftools/ffprobe: support DOVI sidedata
From: Jun Zhao
support DOVI sidedata.
Signed-off-by: Jun Zhao
---
fftools/ffprobe.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index e3f221f..840fcb7 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -36,6 +36,7 @@
#include "libavutil/display.h"
#include "libavutil/hash.h"
#include "libavutil/mastering_display_metadata.h"
+#include "libavutil/dovi_meta.h"
#include "libavutil/opt.h"
#include "libavutil/pixdesc.h"
#include "libavutil/spherical.h"
@@ -1928,6 +1929,16 @@ static void print_pkt_side_data(WriterContext *w,
AVContentLightMetadata *metadata = (AVContentLightMetadata
*)sd->data;
print_int("max_content", metadata->MaxCLL);
print_int("max_average", metadata->MaxFALL);
+} else if (sd->type == AV_PKT_DATA_DOVI_CONF) {
+AVDOVIDecoderConfigurationRecord *dovi =
(AVDOVIDecoderConfigurationRecord *)sd->data;
+print_int("dv_version_major", dovi->dv_version_major);
+print_int("dv_version_minor", dovi->dv_version_minor);
+print_int("dv_profile", dovi->dv_profile);
+print_int("dv_level", dovi->dv_level);
+print_int("rpu_present_flag", dovi->rpu_present_flag);
+print_int("el_present_flag", dovi->el_present_flag);
+print_int("bl_present_flag", dovi->bl_present_flag);
+print_int("dv_bl_signal_compatibility_id",
dovi->dv_bl_signal_compatibility_id);
}
writer_print_section_footer(w);
}
--
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] mpeg4videoenc: Don't crash with -fsanitize=bounds
Also the patch makes this code consistent with mpeg4videodec.c
---
libavcodec/mpeg4videoenc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/mpeg4videoenc.c b/libavcodec/mpeg4videoenc.c
index f6a5992df7..2cd5a8c015 100644
--- a/libavcodec/mpeg4videoenc.c
+++ b/libavcodec/mpeg4videoenc.c
@@ -104,7 +104,7 @@ static inline void restore_ac_coeffs(MpegEncContext *s,
int16_t block[6][64],
memcpy(s->block_last_index, zigzag_last_index, sizeof(int) * 6);
for (n = 0; n < 6; n++) {
-int16_t *ac_val = s->ac_val[0][0] + s->block_index[n] * 16;
+int16_t *ac_val = >ac_val[0][0][0] + s->block_index[n] * 16;
st[n] = s->intra_scantable.permutated;
if (dir[n]) {
@@ -143,7 +143,7 @@ static inline int decide_ac_pred(MpegEncContext *s, int16_t
block[6][64],
score -= get_block_rate(s, block[n], s->block_last_index[n],
s->intra_scantable.permutated);
-ac_val = s->ac_val[0][0] + s->block_index[n] * 16;
+ac_val = >ac_val[0][0][0] + s->block_index[n] * 16;
ac_val1 = ac_val;
if (dir[n]) {
const int xy = s->mb_x + s->mb_y * s->mb_stride - s->mb_stride;
--
2.26.2.303.gf8c07b1a785-goog
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/3] lavu/pix_fmt: add new pixel format x2rgb10
On Tue, Apr 21, 2020 at 10:32 PM Wang, Fei W wrote: > > > > -Original Message- > > From: ffmpeg-devel On Behalf Of > > Hendrik Leppkes > > Sent: Tuesday, April 21, 2020 4:08 PM > > To: FFmpeg development discussions and patches > de...@ffmpeg.org> > > Subject: Re: [FFmpeg-devel] [PATCH 1/3] lavu/pix_fmt: add new pixel > format > > x2rgb10 > > > > On Tue, Apr 21, 2020 at 9:53 AM Fei Wang wrote: > > > > > > The format is packed RGB with each channel 10 bits available and > > > include 2 bits unused. > > > > > > > The name of this pix_fmt seems very confusing, and the entire format > seems > > very specific. What is such a packed RGB format really good for in > ffmpeg? > This format is named as X2R10G10B10 in libva, but I think X2RGB10 is more > concise. There is similar format name defined in Gstreamer like RGB10A2. > Because there are lots of Codec/Filter based on third-party library in > ffmpeg, while > in these library they may support some specific format like > P010/Y210/Y410.., so in > Ffmpeg side it should support this kinds of formats first, at least the > definition. > In my opinion, unless it's needed by a ffmpeg features or it's fully supported in swscale so that ffmpeg users may use it, it should not go in. -- Vittorio ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] libavcodec/jpeg2000dec.c: ROI marker support
On Wed, Apr 22, 2020 at 3:04 AM Michael Niedermayer
wrote:
>
> On Tue, Apr 21, 2020 at 01:07:39AM +0530, gautamr...@gmail.com wrote:
> > From: Gautam Ramakrishnan
> >
> > This patch adds support for decoding images
> > with a Region of Interest. Allows decoding
> > samples such as p0_03.j2k. This patch should
> > fix ticket #4681.
> > ---
> > libavcodec/jpeg2000.h| 1 +
> > libavcodec/jpeg2000dec.c | 57 +++-
> > 2 files changed, 51 insertions(+), 7 deletions(-)
> >
> > diff --git a/libavcodec/jpeg2000.h b/libavcodec/jpeg2000.h
> > index 7b78c0193e..0f82716981 100644
> > --- a/libavcodec/jpeg2000.h
> > +++ b/libavcodec/jpeg2000.h
> > @@ -210,6 +210,7 @@ typedef struct Jpeg2000Component {
> > int *i_data;
> > int coord[2][2]; // border coordinates {{x0, x1}, {y0, y1}} -- can
> > be reduced with lowres option
> > int coord_o[2][2]; // border coordinates {{x0, x1}, {y0, y1}} --
> > original values from jpeg2000 headers
> > +uint8_t roi_shift; // ROI scaling value for the component
> > } Jpeg2000Component;
> >
> > /* misc tools */
> > diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
> > index 5a7d9e7882..da19345ee7 100644
> > --- a/libavcodec/jpeg2000dec.c
> > +++ b/libavcodec/jpeg2000dec.c
> > @@ -117,6 +117,7 @@ typedef struct Jpeg2000DecoderContext {
> > Jpeg2000CodingStyle codsty[4];
> > Jpeg2000QuantStyle qntsty[4];
> > Jpeg2000POC poc;
>
> > +uint8_t roi_shift[4];
> >
> > int bit_index;
> >
> > @@ -598,6 +599,29 @@ static int get_coc(Jpeg2000DecoderContext *s,
> > Jpeg2000CodingStyle *c,
> > return 0;
> > }
> >
> > +static int get_rgn(Jpeg2000DecoderContext *s, int n)
> > +{
> > +uint16_t compno;
> > +compno = (s->ncomponents < 257)? bytestream2_get_byte(>g):
> > + bytestream2_get_be16u(>g);
> > +if (bytestream2_get_byte(>g)) {
> > +av_log(s->avctx, AV_LOG_ERROR, "Invalid RGN header.\n");
> > +return AVERROR_INVALIDDATA; // SRgn field value is 0
> > +}
> > +// SPrgn field
> > +if (compno < s->ncomponents) {
> > +if (s->curtileno == -1)
> > +s->roi_shift[compno] = bytestream2_get_byte(>g);
>
> theres a check for s->ncomponents < 257 implying that if this check is not a
> dead check ncomponents can be bigger and then compno is just checked by that
> before being used to index into a 4 entry array (roi_shift)
>
> something in here is not entirely correct
For our decoder, it is a dead check as we are supposed to return an error
before this marker reaches if the number of components is greater than 4.
However, I have still kept this check keeping in mind support for more than
4 components in the future.
>
>
>
> > +else {
> > +if (s->tile[s->curtileno].tp_idx != 0)
> > +return AVERROR_INVALIDDATA; // marker occurs only in first
> > tile part of tile
> > +s->tile[s->curtileno].comp[compno].roi_shift =
> > bytestream2_get_byte(>g);
> > +}
> > +return 0;
> > +}
> > +return AVERROR_INVALIDDATA;
> > +}
> > +
> > /* Get common part for QCD and QCC segments. */
> > static int get_qcx(Jpeg2000DecoderContext *s, int n, Jpeg2000QuantStyle *q)
> > {
> > @@ -947,6 +971,9 @@ static int init_tile(Jpeg2000DecoderContext *s, int
> > tileno)
> > comp->coord[1][0] = ff_jpeg2000_ceildivpow2(comp->coord_o[1][0],
> > s->reduction_factor);
> > comp->coord[1][1] = ff_jpeg2000_ceildivpow2(comp->coord_o[1][1],
> > s->reduction_factor);
> >
> > +if (!comp->roi_shift)
> > +comp->roi_shift = s->roi_shift[compno];
> > +
> > if (ret = ff_jpeg2000_init_component(comp, codsty, qntsty,
> > s->cbps[compno],
> > s->cdx[compno],
> > s->cdy[compno], s->avctx))
> > @@ -1615,9 +1642,9 @@ static void decode_clnpass(Jpeg2000DecoderContext *s,
> > Jpeg2000T1Context *t1,
> >
> > static int decode_cblk(Jpeg2000DecoderContext *s, Jpeg2000CodingStyle
> > *codsty,
> > Jpeg2000T1Context *t1, Jpeg2000Cblk *cblk,
> > - int width, int height, int bandpos)
> > + int width, int height, int bandpos, uint8_t
> > roi_shift)
> > {
> > -int passno = cblk->npasses, pass_t = 2, bpno = cblk->nonzerobits - 1;
> > +int passno = cblk->npasses, pass_t = 2, bpno = cblk->nonzerobits - 1 +
> > roi_shift;
> > int pass_cnt = 0;
> > int vert_causal_ctx_csty_symbol = codsty->cblk_style &
> > JPEG2000_CBLK_VSC;
> > int term_cnt = 0;
>
> > @@ -1691,6 +1718,19 @@ static int decode_cblk(Jpeg2000DecoderContext *s,
> > Jpeg2000CodingStyle *codsty,
> > return 1;
> > }
> >
> > +static inline int roi_shift_param(Jpeg2000Component *comp,
> > + int quan_parameter)
> > +{
> > +uint8_t roi_shift;
Re: [FFmpeg-devel] [PATCH 1/3] lavu/pix_fmt: add new pixel format x2rgb10
> -Original Message- > From: ffmpeg-devel On Behalf Of > Hendrik Leppkes > Sent: Tuesday, April 21, 2020 4:08 PM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH 1/3] lavu/pix_fmt: add new pixel format > x2rgb10 > > On Tue, Apr 21, 2020 at 9:53 AM Fei Wang wrote: > > > > The format is packed RGB with each channel 10 bits available and > > include 2 bits unused. > > > > The name of this pix_fmt seems very confusing, and the entire format seems > very specific. What is such a packed RGB format really good for in ffmpeg? This format is named as X2R10G10B10 in libva, but I think X2RGB10 is more concise. There is similar format name defined in Gstreamer like RGB10A2. Because there are lots of Codec/Filter based on third-party library in ffmpeg, while in these library they may support some specific format like P010/Y210/Y410.., so in Ffmpeg side it should support this kinds of formats first, at least the definition. > > - Hendrik > ___ > 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] avcodec/utils: use av_rescale()
On Tue, Apr 21, 2020 at 11:05:59PM +0200, Michael Niedermayer wrote: > On Mon, Apr 20, 2020 at 07:00:55PM +0800, lance.lmw...@gmail.com wrote: > > From: Limin Wang > > > > Signed-off-by: Limin Wang > > --- > > libavcodec/utils.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/libavcodec/utils.c b/libavcodec/utils.c > > index 26c038dfd9..005d596dfd 100644 > > --- a/libavcodec/utils.c > > +++ b/libavcodec/utils.c > > @@ -2229,8 +2229,8 @@ int64_t ff_guess_coded_bitrate(AVCodecContext *avctx) > > const AVPixFmtDescriptor *desc = > > av_pix_fmt_desc_get(avctx->pix_fmt); > > bits_per_coded_sample = av_get_bits_per_pixel(desc); > > } > > -bitrate = (int64_t)bits_per_coded_sample * avctx->width * > > avctx->height * > > - framerate.num / framerate.den; > > +bitrate = av_rescale(avctx->width * avctx->height, > > +bits_per_coded_sample * framerate.num, framerate.den); > > why this change ? I recall mp3dec.c, avidec.c etc always use av_scale to get the bitrate, so I think it's more general to use av_rescale. If I'm misunderstanding, please ignore the patch. > > also > bits_per_coded_sample * framerate.num > could possibly overflow after this i think It seems that the int64_t is necessary still. Then I prefer to: +bitrate = av_rescale((int64_t)bits_per_coded_sample * avctx->width * avctx->height, +framerate.num, framerate.den); > > thx > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Nations do behave wisely once they have exhausted all other alternatives. > -- Abba Eban > ___ > 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". -- Thanks, Limin Wang ___ 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 2/2] libavcodec/libaomenc.c: Support lossless encoding
On Fri, Apr 17, 2020 at 9:57 AM Ryo Hirafuji wrote:
>
> I see, Thanks.
> I'm looking forward to the answer.
>
There is some benefit to using cq-level as many of the encoder
decisions are based on this (reference frame structure, speed
features, etc) and so it's better tuned than quality mode. In both
cases the output is lossless so either will work, but given the
structure of the options to the library it might make sense to match
vp9 in libvpxenc.c and use cq-level.
> (If you are OK, please CC to me. I also would like to know about lossless
> mode in libaom, because I also use my software)
>
Sorry, I missed this comment. I don't have any results that would be
visible publicly.
> 2020年4月15日(水) 10:00 James Zern :
>
> > On Tue, Apr 7, 2020 at 5:14 PM Ryo Hirafuji
> > wrote:
> > >
> > > From: Ryo Hirafuji
> > >
> > > AV1 support lossless encoding.
> > > In this patch, I added a command line flag to enable it.
> > >
> > > Fixes ticket #7600
> > > ---
> > > libavcodec/libaomenc.c | 14 +++---
> > > 1 file changed, 11 insertions(+), 3 deletions(-)
> > >
> > > [...]
> > > @@ -574,7 +577,9 @@ static av_cold int aom_init(AVCodecContext *avctx,
> > > if (avctx->rc_min_rate == avctx->rc_max_rate &&
> > > avctx->rc_min_rate == avctx->bit_rate && avctx->bit_rate) {
> > > enccfg.rc_end_usage = AOM_CBR;
> > > -} else if (ctx->crf >= 0) {
> > > +} else if (ctx->crf == 0) {
> > > +enccfg.rc_end_usage = AOM_Q;
> >
> > I saw the earlier comments around using crf=0 as the trigger for this.
> > libaom will behave differently with q vs cq mode. This also differs
> > from the -lossless in libvpxenc where this feature originated; mostly
> > we've been mapping options one to one with vpx/aomenc. Let me ask
> > around about the preference for lossless usage in libaom.
> > ___
> > 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 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] libavcodec/jpeg2000dec.c: ROI marker support
On Tue, Apr 21, 2020 at 01:07:39AM +0530, gautamr...@gmail.com wrote:
> From: Gautam Ramakrishnan
>
> This patch adds support for decoding images
> with a Region of Interest. Allows decoding
> samples such as p0_03.j2k. This patch should
> fix ticket #4681.
> ---
> libavcodec/jpeg2000.h| 1 +
> libavcodec/jpeg2000dec.c | 57 +++-
> 2 files changed, 51 insertions(+), 7 deletions(-)
>
> diff --git a/libavcodec/jpeg2000.h b/libavcodec/jpeg2000.h
> index 7b78c0193e..0f82716981 100644
> --- a/libavcodec/jpeg2000.h
> +++ b/libavcodec/jpeg2000.h
> @@ -210,6 +210,7 @@ typedef struct Jpeg2000Component {
> int *i_data;
> int coord[2][2]; // border coordinates {{x0, x1}, {y0, y1}} -- can be
> reduced with lowres option
> int coord_o[2][2]; // border coordinates {{x0, x1}, {y0, y1}} --
> original values from jpeg2000 headers
> +uint8_t roi_shift; // ROI scaling value for the component
> } Jpeg2000Component;
>
> /* misc tools */
> diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
> index 5a7d9e7882..da19345ee7 100644
> --- a/libavcodec/jpeg2000dec.c
> +++ b/libavcodec/jpeg2000dec.c
> @@ -117,6 +117,7 @@ typedef struct Jpeg2000DecoderContext {
> Jpeg2000CodingStyle codsty[4];
> Jpeg2000QuantStyle qntsty[4];
> Jpeg2000POC poc;
> +uint8_t roi_shift[4];
>
> int bit_index;
>
> @@ -598,6 +599,29 @@ static int get_coc(Jpeg2000DecoderContext *s,
> Jpeg2000CodingStyle *c,
> return 0;
> }
>
> +static int get_rgn(Jpeg2000DecoderContext *s, int n)
> +{
> +uint16_t compno;
> +compno = (s->ncomponents < 257)? bytestream2_get_byte(>g):
> + bytestream2_get_be16u(>g);
> +if (bytestream2_get_byte(>g)) {
> +av_log(s->avctx, AV_LOG_ERROR, "Invalid RGN header.\n");
> +return AVERROR_INVALIDDATA; // SRgn field value is 0
> +}
> +// SPrgn field
> +if (compno < s->ncomponents) {
> +if (s->curtileno == -1)
> +s->roi_shift[compno] = bytestream2_get_byte(>g);
theres a check for s->ncomponents < 257 implying that if this check is not a
dead check ncomponents can be bigger and then compno is just checked by that
before being used to index into a 4 entry array (roi_shift)
something in here is not entirely correct
> +else {
> +if (s->tile[s->curtileno].tp_idx != 0)
> +return AVERROR_INVALIDDATA; // marker occurs only in first
> tile part of tile
> +s->tile[s->curtileno].comp[compno].roi_shift =
> bytestream2_get_byte(>g);
> +}
> +return 0;
> +}
> +return AVERROR_INVALIDDATA;
> +}
> +
> /* Get common part for QCD and QCC segments. */
> static int get_qcx(Jpeg2000DecoderContext *s, int n, Jpeg2000QuantStyle *q)
> {
> @@ -947,6 +971,9 @@ static int init_tile(Jpeg2000DecoderContext *s, int
> tileno)
> comp->coord[1][0] = ff_jpeg2000_ceildivpow2(comp->coord_o[1][0],
> s->reduction_factor);
> comp->coord[1][1] = ff_jpeg2000_ceildivpow2(comp->coord_o[1][1],
> s->reduction_factor);
>
> +if (!comp->roi_shift)
> +comp->roi_shift = s->roi_shift[compno];
> +
> if (ret = ff_jpeg2000_init_component(comp, codsty, qntsty,
> s->cbps[compno], s->cdx[compno],
> s->cdy[compno], s->avctx))
> @@ -1615,9 +1642,9 @@ static void decode_clnpass(Jpeg2000DecoderContext *s,
> Jpeg2000T1Context *t1,
>
> static int decode_cblk(Jpeg2000DecoderContext *s, Jpeg2000CodingStyle
> *codsty,
> Jpeg2000T1Context *t1, Jpeg2000Cblk *cblk,
> - int width, int height, int bandpos)
> + int width, int height, int bandpos, uint8_t roi_shift)
> {
> -int passno = cblk->npasses, pass_t = 2, bpno = cblk->nonzerobits - 1;
> +int passno = cblk->npasses, pass_t = 2, bpno = cblk->nonzerobits - 1 +
> roi_shift;
> int pass_cnt = 0;
> int vert_causal_ctx_csty_symbol = codsty->cblk_style & JPEG2000_CBLK_VSC;
> int term_cnt = 0;
> @@ -1691,6 +1718,19 @@ static int decode_cblk(Jpeg2000DecoderContext *s,
> Jpeg2000CodingStyle *codsty,
> return 1;
> }
>
> +static inline int roi_shift_param(Jpeg2000Component *comp,
> + int quan_parameter)
> +{
> +uint8_t roi_shift;
> +int val;
> +roi_shift = comp->roi_shift;
> +val = (quan_parameter < 0)?-quan_parameter:quan_parameter;
> +
> +if (val > (1 << roi_shift))
> +return (quan_parameter < 0)?-(val >> roi_shift):(val >> roi_shift);
> +return quan_parameter;
> +}
> +
> /* TODO: Verify dequantization for lossless case
> * comp->data can be float or int
> * band->stepsize can be float or int
> @@ -1708,7 +1748,7 @@ static void dequantization_float(int x, int y,
> Jpeg2000Cblk *cblk,
> float *datap =
Re: [FFmpeg-devel] [PATCH v1] avcodec/utils: use av_rescale()
On Mon, Apr 20, 2020 at 07:00:55PM +0800, lance.lmw...@gmail.com wrote: > From: Limin Wang > > Signed-off-by: Limin Wang > --- > libavcodec/utils.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/libavcodec/utils.c b/libavcodec/utils.c > index 26c038dfd9..005d596dfd 100644 > --- a/libavcodec/utils.c > +++ b/libavcodec/utils.c > @@ -2229,8 +2229,8 @@ int64_t ff_guess_coded_bitrate(AVCodecContext *avctx) > const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(avctx->pix_fmt); > bits_per_coded_sample = av_get_bits_per_pixel(desc); > } > -bitrate = (int64_t)bits_per_coded_sample * avctx->width * avctx->height * > - framerate.num / framerate.den; > +bitrate = av_rescale(avctx->width * avctx->height, > +bits_per_coded_sample * framerate.num, framerate.den); why this change ? also bits_per_coded_sample * framerate.num could possibly overflow after this i think thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Nations do behave wisely once they have exhausted all other alternatives. -- Abba Eban signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/gopher: Support 'g' type
Am Di., 21. Apr. 2020 um 22:13 Uhr schrieb Marton Balint :
>
>
>
> On Tue, 21 Apr 2020, parazyd wrote:
>
> > This adds support for the gif gopher type. Since ffmpeg can work with GIF
> > files, it makes sense to support it in the Gopher protocol.
> >
> > Signed-off-by: parazyd
> > ---
> > libavformat/gopher.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/libavformat/gopher.c b/libavformat/gopher.c
> > index 3070b24caf..3420abd8fb 100644
> > --- a/libavformat/gopher.c
> > +++ b/libavformat/gopher.c
> > @@ -46,6 +46,7 @@ static int gopher_connect(URLContext *h, const char *path)
> > switch (*++path) {
> > case '5':
> > case '9':
> > +case 'g':
>
> 'I' should also be added, no?
I suggested the same but 'g' fails here with "Input/output error"
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] avformat/gopher: Support 'g' type
On Tue, 21 Apr 2020, parazyd wrote:
This adds support for the gif gopher type. Since ffmpeg can work with GIF
files, it makes sense to support it in the Gopher protocol.
Signed-off-by: parazyd
---
libavformat/gopher.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/gopher.c b/libavformat/gopher.c
index 3070b24caf..3420abd8fb 100644
--- a/libavformat/gopher.c
+++ b/libavformat/gopher.c
@@ -46,6 +46,7 @@ static int gopher_connect(URLContext *h, const char *path)
switch (*++path) {
case '5':
case '9':
+case 'g':
'I' should also be added, no?
(I never imagined somebody is still using this :P)
Thanks,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/gopher: Support 'g' type
This adds support for the gif gopher type. Since ffmpeg can work with GIF
files, it makes sense to support it in the Gopher protocol.
Signed-off-by: parazyd
---
libavformat/gopher.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/gopher.c b/libavformat/gopher.c
index 3070b24caf..3420abd8fb 100644
--- a/libavformat/gopher.c
+++ b/libavformat/gopher.c
@@ -46,6 +46,7 @@ static int gopher_connect(URLContext *h, const char *path)
switch (*++path) {
case '5':
case '9':
+case 'g':
path = strchr(path, '/');
if (!path) return AVERROR(EINVAL);
break;
--
2.26.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 4/4] avformat/mpegtsenc: use the correct stream_types and write HDMV descriptors for m2ts
Am Di., 21. Apr. 2020 um 21:44 Uhr schrieb Marton Balint : > > > > On Mon, 20 Apr 2020, Marton Balint wrote: > > > > > > > On Thu, 16 Apr 2020, Carl Eugen Hoyos wrote: > > > >> Am Mo., 13. Apr. 2020 um 02:17 Uhr schrieb Marton Balint : > >>> > >>> > >>> > >>> On Mon, 13 Apr 2020, Carl Eugen Hoyos wrote: > >>> > >>> > Am Mo., 13. Apr. 2020 um 00:38 Uhr schrieb Marton Balint > > : > >>> >> > >>> >> Fixes ticket #2622. > >>> >> > >>> >> Signed-off-by: Marton Balint > >>> >> --- > >>> >> Changelog | 1 + > >>> >> libavformat/mpegtsenc.c | 58 > > - > >>> >> 2 files changed, 58 insertions(+), 1 deletion(-) > >>> >> > >>> >> diff --git a/Changelog b/Changelog > >>> >> index 6dfe750d81..4ba44e5e2d 100644 > >>> >> --- a/Changelog > >>> >> +++ b/Changelog > >>> >> @@ -58,6 +58,7 @@ version : > >>> >> - switch from AvxSynth to AviSynth+ on Linux > >>> >> - mv30 decoder > >>> >> - Expanded styling support for 3GPP Timed Text Subtitles (movtext) > >>> >> +- use the correct stream types for m2ts output > >>> > > >>> > Don't you agree that "Support pcm audio when muxing m2ts" > >>> > or "Support BluRay muxing" is a stronger wording? > >>> > >>> That is not true, m2ts mode is nowhere near Blu-ray compatible yet, so it > >>> would be misleading to say that. Also it is not just about PCM audio, the > >>> ticket was opened for PGS subtitles as far as I remember. > >> > >> I think there is enough room for "Support for muxing pcm and pgs in m2ts" > > > > Ok, will apply soon the series with that line in the changelog. > > Applied the series. Thank you! 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] avformat/mpegtsenc: don't print warning for DVB text streams
On Mon, 20 Apr 2020, Gyan Doshi wrote: They can be demuxed by ffmpeg. --- libavformat/mpegtsenc.c | 4 1 file changed, 4 insertions(+) diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c index ccb631d746..3818001976 100644 --- a/libavformat/mpegtsenc.c +++ b/libavformat/mpegtsenc.c @@ -381,6 +381,10 @@ static int mpegts_write_pmt(AVFormatContext *s, MpegTSService *service) case AV_CODEC_ID_TIMED_ID3: stream_type = STREAM_TYPE_METADATA; break; +case AV_CODEC_ID_DVB_SUBTITLE: +case AV_CODEC_ID_DVB_TELETEXT: +stream_type = STREAM_TYPE_PRIVATE_DATA; +break; LGTM. default: av_log(s, AV_LOG_WARNING, "Stream %d, codec %s, is muxed as a private data stream " "and may not be recognized upon reading.\n", i, avcodec_get_name(st->codecpar->codec_id)); Preferably av_log_once should be used here with a state variable stored in MpegTSWriteStream because it is logged for every PMT... Thanks, Marton ___ 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 4/4] avformat/mpegtsenc: use the correct stream_types and write HDMV descriptors for m2ts
On Mon, 20 Apr 2020, Marton Balint wrote: On Thu, 16 Apr 2020, Carl Eugen Hoyos wrote: Am Mo., 13. Apr. 2020 um 02:17 Uhr schrieb Marton Balint : On Mon, 13 Apr 2020, Carl Eugen Hoyos wrote: > Am Mo., 13. Apr. 2020 um 00:38 Uhr schrieb Marton Balint : >> >> Fixes ticket #2622. >> >> Signed-off-by: Marton Balint >> --- >> Changelog | 1 + >> libavformat/mpegtsenc.c | 58 - >> 2 files changed, 58 insertions(+), 1 deletion(-) >> >> diff --git a/Changelog b/Changelog >> index 6dfe750d81..4ba44e5e2d 100644 >> --- a/Changelog >> +++ b/Changelog >> @@ -58,6 +58,7 @@ version : >> - switch from AvxSynth to AviSynth+ on Linux >> - mv30 decoder >> - Expanded styling support for 3GPP Timed Text Subtitles (movtext) >> +- use the correct stream types for m2ts output > > Don't you agree that "Support pcm audio when muxing m2ts" > or "Support BluRay muxing" is a stronger wording? That is not true, m2ts mode is nowhere near Blu-ray compatible yet, so it would be misleading to say that. Also it is not just about PCM audio, the ticket was opened for PGS subtitles as far as I remember. I think there is enough room for "Support for muxing pcm and pgs in m2ts" Ok, will apply soon the series with that line in the changelog. Applied the series. Regards Marton ___ 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] lavf/mux: bypass interleave delay early when waiting on subtitle streams
On Wed, Mar 11, 2020 at 11:36 PM rcombs wrote: > > This avoids long delays when converting live streams that have sparse > subtitles > --- > libavformat/avformat.h | 9 + > libavformat/mux.c | 25 + > libavformat/options_table.h | 1 + > libavformat/version.h | 2 +- > 4 files changed, 32 insertions(+), 5 deletions(-) For the record, was debugging a case of rather bursty muxing of a live stream from a live TV source to fragmented mp4 with keyframe-based fragmentation and subtitles in the mux. For easier debugging I utilized fix_sub_duration with ffmpeg.c, static 2 second GOPs, and added av_gettime_relative logging calls at the end of mov_flush_fragment. It showed things like 2-3 2 second fragments happening in very quick succession, and then a pause for a while. Making the process rather jittery. Haven't yet really been able to look at this patch code wise, but clearly with this patch the output fragmentation becomes much, much more stable (nice ~2 second timings all way through while I was running my tests). Best regards, Jan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v1] avformat/mux: Set AV_PKT_FLAG_KEY for is_intra_only packet
On Tue, Apr 21, 2020 at 9:05 PM Nicolas George wrote: > > Derek Buitenhuis (12020-04-17): > > Can you elaborate on why it's an abomination? It's so far been the only > > thing > > that has kept people from breaking movenc API use several times, > > specifically > > in relation to how it behaves for outputting fragments - and ffmpeg.c does > > not > > necessarily exercise these paths. API unit tests are good thing in my books, > > as an API-only user who has seen unintentional API breaks because ffmpeg.c > > doesn't use something specifically. > > I had not understood that it was an API test. Actually, I am rather > surprised that we have a "movenc API", I thought our muxers where mostly > interchangeable. > > Regards, > I think he means a minimal application doing various things that test the muxer within the libavformat API, as opposed to utilizing a full-blown ffmpeg.c command line with an actual (or runtime generated) input, actual encoders etc. It tests movenc's logic according to various use cases that were implemented into the muxer. Jan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavf/tls_gnutls: check for interrupt inside handshake loop
On Mon, Apr 20, 2020 at 8:07 PM Jan Ekström wrote:
>
> On Thu, Sep 5, 2019 at 6:13 PM Michael Niedermayer
> wrote:
> >
> > On Fri, Aug 16, 2019 at 10:38:46AM +0200, Błażej Szczygieł wrote:
> > > fixes #8080
> > >
> > > Signed-off-by: Błażej Szczygieł
> > > ---
> > > libavformat/tls_gnutls.c | 4
> > > 1 file changed, 4 insertions(+)
> > >
> > > diff --git a/libavformat/tls_gnutls.c b/libavformat/tls_gnutls.c
> > > index f32bc2821b..f507b7d044 100644
> > > --- a/libavformat/tls_gnutls.c
> > > +++ b/libavformat/tls_gnutls.c
> > > @@ -184,6 +184,10 @@ static int tls_open(URLContext *h, const char *uri,
> > > int flags, AVDictionary **op
> > > gnutls_priority_set_direct(p->session, "NORMAL", NULL);
> > > do {
> > > ret = gnutls_handshake(p->session);
> > > +if (ff_check_interrupt(>interrupt_callback)) {
> > > +ret = AVERROR_EXIT;
> > > +goto fail;
> > > +}
> > > if (gnutls_error_is_fatal(ret)) {
> > > ret = print_tls_error(h, ret);
> > > goto fail;
> >
> > probably ok
> >
> > Thanks
> >
>
> I've been meaning to look at this (and apply if it looks good), and
> while the other TLS wrappers don't seem to have this (I guess their
> handshake doesn't base on a loop?), it seems to almost match examples
> found in f.ex. libavformat/network.c, libavformat/libzmq.c or
> libavformat/libsrt.c.
>
> The only point I notice is that usually the interrupt check is the
> first thing done a loop, and unless people see any issues with it, I
> will apply this patch with that change during today or so?
>
Re-checked with Michael and pushed with the minor modification of
moving the interrupt handling to the beginning of the loop (as that is
how various similar I/O loops elsewhere in the code base seem to
handle these interrupts).
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v1] avformat/mux: Set AV_PKT_FLAG_KEY for is_intra_only packet
Derek Buitenhuis (12020-04-17): > Can you elaborate on why it's an abomination? It's so far been the only thing > that has kept people from breaking movenc API use several times, specifically > in relation to how it behaves for outputting fragments - and ffmpeg.c does not > necessarily exercise these paths. API unit tests are good thing in my books, > as an API-only user who has seen unintentional API breaks because ffmpeg.c > doesn't use something specifically. I had not understood that it was an API test. Actually, I am rather surprised that we have a "movenc API", I thought our muxers where mostly interchangeable. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 4/4] avcodec/cbs_h265: add missing support for reserved_payload_extension_data SEI bits
On 4/20/2020 6:45 PM, James Almer wrote:
> Fixes ticket #8622
>
> Signed-off-by: James Almer
> ---
> It fixes it assuming the Picture Timing in that sample is not being misparsed
> by cbs_h265.
> We're compliant with the latest revision of the spec, so any
> reserved_payload_extension_data found in a sample created today is almost
> guaranteed to be bogus. But the spec states that they should be skipped if
> found, for forward compatibility reasons.
> Would be worth checking if the nvenc encoder is at fault, writing faulty SEI
> messages.
>
> This patch could for that matter make many potential cases of undiscovered
> cbs_h265 SEI misparsing be handled as if the remaining bits were these
> reserved
> bits.
>
> libavcodec/cbs_h265.h | 1 +
> libavcodec/cbs_h265_syntax_template.c | 44 +--
> 2 files changed, 43 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/cbs_h265.h b/libavcodec/cbs_h265.h
> index 2c1e153ad9..73897f77a4 100644
> --- a/libavcodec/cbs_h265.h
> +++ b/libavcodec/cbs_h265.h
> @@ -715,6 +715,7 @@ typedef struct H265RawSEIPayload {
> AVBufferRef *data_ref;
> } other;
> } payload;
> +H265RawExtensionData extension_data;
Added an av_buffer_unref() call in cbs_h265_free_sei_payload()
cbs_h2645.c locally. Else the buffer will leak.
> } H265RawSEIPayload;
>
> typedef struct H265RawSEI {
> diff --git a/libavcodec/cbs_h265_syntax_template.c
> b/libavcodec/cbs_h265_syntax_template.c
> index f978e16549..ef3254d27f 100644
> --- a/libavcodec/cbs_h265_syntax_template.c
> +++ b/libavcodec/cbs_h265_syntax_template.c
> @@ -2054,11 +2054,43 @@ static int
> FUNC(sei_alpha_channel_info)(CodedBitstreamContext *ctx,
> return 0;
> }
>
> +static int FUNC(payload_extension)(CodedBitstreamContext *ctx, RWContext *rw,
> + H265RawExtensionData *current, uint32_t
> payload_size,
> + int cur_pos)
> +{
> +int err, i;
> +
> +#ifdef READ
> +if (cbs_h265_payload_extension_present(rw, payload_size, cur_pos)) {
> +GetBitContext tmp = *rw;
> +int payload_zero_bits, bits_left = 8 * payload_size - cur_pos;
> +if (bits_left > 8)
> +skip_bits_long(, bits_left - 8);
> +payload_zero_bits = ff_ctz(get_bits(, FFMIN(bits_left, 8)));
> +if (payload_zero_bits >= bits_left - 1)
> +return AVERROR_INVALIDDATA;
> +current->bit_length = bits_left - payload_zero_bits - 1;
> +allocate(current->data, (current->bit_length + 7) / 8);
> +for (i = 0; i < current->bit_length; i++) {
> +uint8_t bit;
> +xu(1, reserved_payload_extension_data, bit, 0, 1, 0);
> +current->data[i / 8] |= bit << (7 - i % 8);
> +}
> +}
> +#else
> +for (i = 0; i < current->bit_length; i++)
> +xu(1, reserved_payload_extension_data,
> + current->data[i / 8] >> (7 - i % 8) & 1, 0, 1, 0);
> +#endif
> +
> +return 0;
> +}
> +
> static int FUNC(sei_payload)(CodedBitstreamContext *ctx, RWContext *rw,
> H265RawSEIPayload *current, int prefix)
> {
> int err, i;
> -int start_position, end_position;
> +int start_position, current_position, end_position;
>
> #ifdef READ
> start_position = get_bits_count(rw);
> @@ -2122,7 +2154,15 @@ static int FUNC(sei_payload)(CodedBitstreamContext
> *ctx, RWContext *rw,
> }
> }
>
> -if (byte_alignment(rw)) {
> +#ifdef READ
> +current_position = get_bits_count(rw) - start_position;
> +if (current_position != 8 * current->payload_size) {
> +#else
> +current_position = put_bits_count(rw) - start_position;
> +if (byte_alignment(rw) || current->extension_data.bit_length) {
> +#endif
> +CHECK(FUNC(payload_extension)(ctx, rw, >extension_data,
> + current->payload_size,
> current_position));
> fixed(1, bit_equal_to_one, 1);
> while (byte_alignment(rw))
> fixed(1, bit_equal_to_zero, 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 v3 2/2] avformat/mux: Set AV_PKT_FLAG_KEY for is_intra_only packet
On Tue, Apr 21, 2020 at 04:21:38PM +0200, Nicolas George wrote: > Limin Wang (12020-04-21): > > Thanks, I'll try to build the tool to use. By the ffmpeg trace log, the > > difference is frag flags of tfhd: > > The trace log is still seeing things from the inside. If there is a bug > after the trace point, it will not be detected. It is important to test > the RESULTING FILE with a DIFFERENT TOOL. I have checked the result files with boxtool and have updated the commit message, please check and review it. thanks. > > Regards, > > -- > Nicolas George > ___ > 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". -- Thanks, Limin Wang ___ 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] avformat/mux: Set AV_PKT_FLAG_KEY for is_intra_only packet
From: Limin Wang
The patch will make audio and subtitle packets be marked as AV_PKT_FLAG_KEY.
For audio, it'll caused the audio sample to be sync sample.
To verify ref/fate/movenc results:
1. Get the movenc test data
[lmwang@vpn ffmpeg]$ libavformat/tests/movenc -w && mkdir -p audio_old && mv
*.mp4 audio_old_
After applied the patch:
[lmwang@vpn ffmpeg]$ make fate-movenc SAMPLES=../fate-suite
[lmwang@vpn ffmpeg]$ libavformat/tests/movenc -w && mkdir -p audio_key && mv
*.mp4 audio_key
2. Get l-smash and build boxdumper
https://github.com/l-smash/l-smash.git
3. dump the box of crc change mp4 and diff -u
[lmwang@vpn ffmpeg]$ ../l-smash/cli/boxdumper --box
audio_key/non-empty-moov-no-elst.mp4 > audio_key/non-empty-moov-no-elst.log
[lmwang@vpn ffmpeg]$ ../l-smash/cli/boxdumper --box
audio_old/non-empty-moov-no-elst.mp4 > audio_old/non-empty-moov-no-elst.log
[lmwang@vpn ffmpeg]$ diff -u audio_key/non-empty-moov-no-elst.log
audio_old/non-empty-moov-no-elst.log
-default_sample_flags = 0x0200
-independent
-sync sample
+default_sample_flags = 0x0101
+dependent
+non-sync sample
4. have checked the change of crc are caused by default_sample_flags
non-empty-moov.mp4, non-empty-moov-elst.mp4,
non-empty-moov-no-elst.mp4, empty-moov.mp4, delay-moov-content.mp4,
empty-moov-second-frag.mp4, empty-moov-second-frag-discont.mp4,
delay-moov-second-frag-discont.mp4, delay-moov-elst-second-frag.mp4
etc
5 For subtitle, it'll effect for tests/ref/fate/binsub-movtextenc and
tests/ref/fate/sub2video, that's expecting result for the subtitle is
marked as keyframe. Below is the checking result of binsub-movtextenc:
[lmwang@vpn ffmpeg]$ ./ffmpeg -i
../fate-suite/sub/MovText_capability_tester.mp4 -map 0 -scodec mov_text -f mp4
-flags +bitexact -fflags +bitexact -movflags frag_keyframe+empty_moov
audio_key/binsub-movtextenc.mp4
[lmwang@vpn ffmpeg]$ ./ffmpeg -i
../fate-suite/sub/MovText_capability_tester.mp4 -map 0 -scodec mov_text -f mp4
-flags +bitexact -fflags +bitexact -movflags frag_keyframe+empty_moov
audio_old/binsub-movtextenc.mp4
[lmwang@vpn ffmpeg]$../l-smash/cli/boxdumper audio_key/binsub-movtextenc.mp4 >
audio_key/binsub-movtextenc.log
[lmwang@vpn ffmpeg]$../l-smash/cli/boxdumper audio_old/binsub-movtextenc.mp4 >
audio_old/binsub-movtextenc.log
[lmwang@vpn ffmpeg]$ diff -u audio_key/binsub-movtextenc.log
audio_old/binsub-movtextenc.log
// the key difference is the flag for sync sample
-flags = 0x000701
+flags = 0x000301
data-offset-present
sample-duration-present
sample-size-present
-sample-flags-present
sample_count = 6
-data_offset = 188
+data_offset = 164
sample[0]
sample_duration = 157
sample_size = 21
-sample_flags = 0x0200
-independent
-sync sample
-degradation_priority = 0
sample[1]
sample_duration = 51
sample_size = 2
-sample_flags = 0x0101
-dependent
-non-sync sample
-degradation_priority = 0
sample[2]
sample_duration = 169
sample_size = 9
-sample_flags = 0x0200
-independent
-sync sample
-degradation_priority = 0
Signed-off-by: Limin Wang
---
libavformat/internal.h | 2 +
libavformat/mux.c| 7 +++-
tests/ref/fate/binsub-movtextenc | 2 +-
tests/ref/fate/movenc| 50 +++
tests/ref/fate/sub2video | 86
5 files changed, 77 insertions(+), 70 deletions(-)
diff --git a/libavformat/internal.h b/libavformat/internal.h
index 716e42c..c4fac5c 100644
--- a/libavformat/internal.h
+++ b/libavformat/internal.h
@@ -189,6 +189,8 @@ struct AVStreamInternal {
*/
int need_context_update;
+int is_intra_only;
+
FFFrac *priv_pts;
};
diff --git a/libavformat/mux.c b/libavformat/mux.c
index a6253f5..ea6524f 100644
--- a/libavformat/mux.c
+++ b/libavformat/mux.c
@@ -357,6 +357,8 @@ FF_ENABLE_DEPRECATION_WARNINGS
if (desc && desc->props & AV_CODEC_PROP_REORDER)
st->internal->reorder = 1;
+st->internal->is_intra_only = ff_is_intra_only(par->codec_id);
+
if (of->codec_tag) {
if ( par->codec_tag
&& par->codec_id == AV_CODEC_ID_RAWVIDEO
@@ -773,6 +775,7 @@ static int check_packet(AVFormatContext *s, AVPacket *pkt)
static int prepare_input_packet(AVFormatContext
[FFmpeg-devel] [PATCH v4 1/2] avformat/utils: move is_intra_only() to header and rename to ff_is_intra_only()
From: Limin Wang
Signed-off-by: Limin Wang
---
libavformat/internal.h | 2 ++
libavformat/utils.c| 4 ++--
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavformat/internal.h b/libavformat/internal.h
index 329b2e9..716e42c 100644
--- a/libavformat/internal.h
+++ b/libavformat/internal.h
@@ -521,6 +521,8 @@ unsigned int ff_codec_get_tag(const AVCodecTag *tags, enum
AVCodecID id);
enum AVCodecID ff_codec_get_id(const AVCodecTag *tags, unsigned int tag);
+int ff_is_intra_only(enum AVCodecID id);
+
/**
* Select a PCM codec based on the given parameters.
*
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 2fb2309..259b2f0 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -1016,7 +1016,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
}
}
-static int is_intra_only(enum AVCodecID id)
+int ff_is_intra_only(enum AVCodecID id)
{
const AVCodecDescriptor *d = avcodec_descriptor_get(id);
if (!d)
@@ -1415,7 +1415,7 @@ static void compute_pkt_fields(AVFormatContext *s,
AVStream *st,
presentation_delayed, delay, av_ts2str(pkt->pts),
av_ts2str(pkt->dts), av_ts2str(st->cur_dts), st->index, st->id);
/* update flags */
-if (st->codecpar->codec_type == AVMEDIA_TYPE_DATA ||
is_intra_only(st->codecpar->codec_id))
+if (st->codecpar->codec_type == AVMEDIA_TYPE_DATA ||
ff_is_intra_only(st->codecpar->codec_id))
pkt->flags |= AV_PKT_FLAG_KEY;
#if FF_API_CONVERGENCE_DURATION
FF_DISABLE_DEPRECATION_WARNINGS
--
2.9.5
___
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 6/8] avcodec/dump_extradata_bsf: Remove unnecessary header
Anton Khirnov: > Quoting Andreas Rheinhardt (2020-04-21 04:31:51) >> Since 33d18982fa03feb061c8f744a4f0a9175c1f63ab (the commit that >> introduced the new bsf API) allocating an enlarged buffer in case >> extradata needs to be added to a packet is done via av_new_packet(), >> so that libavutil/mem.h is no longer needed. >> >> Furthermore, remove libavutil/log.h. This function uses something >> provided by it (an AVClass), yet it does so only for AVOptions, not >> for logging purposes (there is no av_log() here), so only including >> libavutil/opt.h seems appropriate. > > IMO each file should include the headers for all the definitions it uses > directly. I.e. if a file uses AVClass, it should include log.h. > My test for inclusion is more like "What API does this file use and which header provides it?" In this case: This bsf only uses the AVOption API, not the logging API. That the former is built on top of a structure that is also used by the latter (and that happens to be provided by the header for the latter) does not imply (for me) that one should include the header for the latter. Another example where our opinions will likely differ is the following: The muxing/demuxing APIs use AVPackets a lot and for this reason avformat.h includes enough so that AVPackets are directly usable for everyone including avformat.h. That's fine by me (although I'd really like to see the amount of stuff unnecessarily included (it currently includes avcodec.h) reduced), but not for you I presume. Your approach would instead include packet.h (and stdint.h) almost everywhere. Furthermore, what counts as "use" for you (and others, of course)? Right now we have a lot of dependencies among headers and lots of files include lots of unnecessary stuff (which also means that it is easy to forget to add a header when making use of it for the first time because it might already be included indirectly), because our headers include other headers to avoid forward declarations even when all they use from another header are actually incomplete types (we only use forward declarations when it is unavoidable because of cyclic dependencies or in order to hide a private struct). Should we try to cut the dependencies among headers and thereby force users to include what they use directly by using more incomplete types/forward declarations in our headers? > But I suppose it does not matter much in pracice (in this case > especially), so feel free to ignore me. > - Andreas PS: Examples where we probably agree on exist, too: I don't think that mem.h should be included basically everywhere via avcodec.h (via libavutil/avutil.h and libavutil/common.h -- there might be other paths); and cpu.h should be removed from avcodec.h, but that probably requires a public announcement and grace period first. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] avfilter/vf_v360: adjustment out_pad and in_pad maximum value to 1/10
Because not every user know about in_pad and out_pad reasonable value range
so maybe try to set 1.0, but setting 1.0 is so hugh to get an fatal error.
Suggested-by: Paul B Mahol
Signed-off-by: Steven Liu
---
doc/filters.texi | 1 +
libavfilter/vf_v360.c | 4 ++--
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 80c33f5edb..740aba0642 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -18956,6 +18956,7 @@ No padding.
@end table
Default value is @b{@samp{0}}.
+Maximum value is @b{@samp{0.1}}.
@item fin_pad
@item fout_pad
diff --git a/libavfilter/vf_v360.c b/libavfilter/vf_v360.c
index ebc281dfca..e5b75c7226 100644
--- a/libavfilter/vf_v360.c
+++ b/libavfilter/vf_v360.c
@@ -133,8 +133,8 @@ static const AVOption v360_options[] = {
{"out_forder", "output cubemap face order", OFFSET(out_forder),
AV_OPT_TYPE_STRING, {.str="rludfb"},0, NB_DIRECTIONS-1, FLAGS,
"out_forder"},
{ "in_frot", "input cubemap face rotation", OFFSET(in_frot),
AV_OPT_TYPE_STRING, {.str="00"},0, NB_DIRECTIONS-1, FLAGS,
"in_frot"},
{ "out_frot", "output cubemap face rotation",OFFSET(out_frot),
AV_OPT_TYPE_STRING, {.str="00"},0, NB_DIRECTIONS-1, FLAGS,
"out_frot"},
-{"in_pad", "percent input cubemap pads",OFFSET(in_pad),
AV_OPT_TYPE_FLOAT, {.dbl=0.f}, 0.f, 1.f,TFLAGS,
"in_pad"},
-{ "out_pad", "percent output cubemap pads", OFFSET(out_pad),
AV_OPT_TYPE_FLOAT, {.dbl=0.f}, 0.f, 1.f,TFLAGS,
"out_pad"},
+{"in_pad", "percent input cubemap pads",OFFSET(in_pad),
AV_OPT_TYPE_FLOAT, {.dbl=0.f}, 0.f, 0.1,TFLAGS,
"in_pad"},
+{ "out_pad", "percent output cubemap pads", OFFSET(out_pad),
AV_OPT_TYPE_FLOAT, {.dbl=0.f}, 0.f, 0.1,TFLAGS,
"out_pad"},
{ "fin_pad", "fixed input cubemap pads", OFFSET(fin_pad),
AV_OPT_TYPE_INT,{.i64=0}, 0, 100,TFLAGS,
"fin_pad"},
{ "fout_pad", "fixed output cubemap pads", OFFSET(fout_pad),
AV_OPT_TYPE_INT,{.i64=0}, 0, 100,TFLAGS,
"fout_pad"},
{ "yaw", "yaw rotation", OFFSET(yaw),
AV_OPT_TYPE_FLOAT, {.dbl=0.f},-180.f, 180.f,TFLAGS,
"yaw"},
--
2.25.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 v3 2/2] avformat/mux: Set AV_PKT_FLAG_KEY for is_intra_only packet
On Tue, Apr 21, 2020 at 05:34:09PM +0300, Jan Ekström wrote: > On Tue, Apr 21, 2020 at 5:19 PM Limin Wang wrote: > > > > On Tue, Apr 21, 2020 at 04:52:16PM +0300, Jan Ekström wrote: > > > On Tue, Apr 21, 2020 at 4:19 PM Limin Wang wrote: > > > > > > > > On Tue, Apr 21, 2020 at 01:08:05PM +0200, Nicolas George wrote: > > > > > Limin Wang (12020-04-21): > > > > > > OK, below is the commit log, please help to review whether it's > > > > > > your expected log: > > > > > > > > > > > > NOTE about the testing effect: > > > > > > subtitle packet will be marked as keyframe, it'll change below > > > > > > testing reference > > > > > > files: > > > > > > tests/ref/fate/binsub-movtextenc and tests/ref/fate/sub2video > > > > > > > > > > > > audio packet will be marked as keyframe, it'll change below testing > > > > > > reference file > > > > > > tests/ref/fate/movenc > > > > > > > > > > You are writing in the future tense, meaning you are making a > > > > > prediction. > > > > > > > > > > You need to explain what you did, and the results. For example, did > > > > > you > > > > > re-run the tests with -w, as suggested in > > > > > https://ffmpeg.org/pipermail/ffmpeg-devel/2020-April/260837.html > > > > > to examine the files before and after the change? > > > > > > > > I have checked with one of non-empty-moov.mp4, and have observed one > > > > byte difference > > > > only(02 and 01). I haven't tool to dump every box in detail. If you > > > > think it's necessary, > > > > I can looked at the movenc muxer further and figure out which field > > > > it's. > > > > > > > > [lmwang@vpn ffmpeg]$ hexdump -C non-empty-moov.mp4 > non-empty-moov.hex > > > > [lmwang@vpn ffmpeg]$ hexdump -C non-empty-moov1.mp4 > > > > > non-empty-moov1.hex > > > > [lmwang@vpn ffmpeg]$ diff non-empty-moov.hex non-empty-moov1.hex > > > > 162c162 > > > > < 0a10 08 02 00 00 00 00 00 00 14 74 66 64 74 01 00 00 > > > > |.tfdt...| > > > > --- > > > > > 0a10 08 01 01 00 00 00 00 00 14 74 66 64 74 01 00 00 > > > > > |.tfdt...| > > > > > > > > > > As noted elsewhere before in a related thread, L-SMASH's > > > (https://github.com/l-smash/l-smash) boxdumper is a nice tool to get a > > > text representation of MOV/MP4/etc boxes. utilize the --box parameter > > > and dump stdout to a file. Then you can diff -u or otherwise. > > Thanks, I'll try to build the tool to use. By the ffmpeg trace log, the > > difference is frag flags of tfhd: > > > > [mov,mp4,m4a,3gp,3g2,mj2 @ 0x2ff02c0] type:'tfhd' parent:'traf' sz: 36 8 76 > > [mov,mp4,m4a,3gp,3g2,mj2 @ 0x2ff02c0] frag flags 0x101 > > > > > > [mov,mp4,m4a,3gp,3g2,mj2 @ 0x295c2c0] type:'tfhd' parent:'traf' sz: 36 8 76 > > [mov,mp4,m4a,3gp,3g2,mj2 @ 0x295c2c0] frag flags 0x200 > > > > If I recall correctly, boxdumper will give you what these flags mean > in a more readable manner. Yes, I have download and build it, below is the different result. For audio packet is set as keyframe, so it'll look as sync sample. [lmwang@vpn ffmpeg]$ ../l-smash/cli/boxdumper --box non-empty-moov.mp4 > non-empty-moov.box [lmwang@vpn ffmpeg]$ ../l-smash/cli/boxdumper --box non-empty-moov1.mp4 > non-empty-moov1.box [lmwang@vpn ffmpeg]$ diff -u non-empty-moov.box non-empty-moov1.box --- non-empty-moov.box 2020-04-21 22:39:30.502512430 +0800 +++ non-empty-moov1.box 2020-04-21 22:39:43.992870378 +0800 @@ -661,9 +661,9 @@ base_data_offset = 2425 default_sample_duration = 1024 default_sample_size = 8 -default_sample_flags = 0x0200 -independent -sync sample +default_sample_flags = 0x0101 +dependent +non-sync sample degradation_priority = 0 [tfdt: Track Fragment Base Media Decode Time Box] position = 2581 > > Jan > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". -- Thanks, Limin Wang ___ 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_v360: check the limit of in_pad and out_pad
On 4/21/20, Steven Liu wrote:
>
>
>> 2020年4月21日 下午10:28，Paul B Mahol 写道：
>>
>> On 4/21/20, Steven Liu wrote:
>>> When i set out_pad=1 it will Segmentation fault
>>> so i think it should check the limit value of the in_pad and out_pad
>>
>> So huge pads do not make sense.
> Yes, just don’t know how to use it, and try to set it to 1, so get the
> exception. :D
>> Limit it to 1/10 in via options.
> What about modify the limit looks like this ?
> { "out_pad", "percent output cubemap pads", OFFSET(out_pad),
> AV_OPT_TYPE_FLOAT, {.dbl=0.f}, 0.f, 0.1,TFLAGS,
Yes, like that.
> "out_pad"},
>> ___
>> 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".
>
> Thanks
>
> Steven Liu
>
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 2/2] avformat/mux: Set AV_PKT_FLAG_KEY for is_intra_only packet
On Tue, Apr 21, 2020 at 5:19 PM Limin Wang wrote: > > On Tue, Apr 21, 2020 at 04:52:16PM +0300, Jan Ekström wrote: > > On Tue, Apr 21, 2020 at 4:19 PM Limin Wang wrote: > > > > > > On Tue, Apr 21, 2020 at 01:08:05PM +0200, Nicolas George wrote: > > > > Limin Wang (12020-04-21): > > > > > OK, below is the commit log, please help to review whether it's your > > > > > expected log: > > > > > > > > > > NOTE about the testing effect: > > > > > subtitle packet will be marked as keyframe, it'll change below > > > > > testing reference > > > > > files: > > > > > tests/ref/fate/binsub-movtextenc and tests/ref/fate/sub2video > > > > > > > > > > audio packet will be marked as keyframe, it'll change below testing > > > > > reference file > > > > > tests/ref/fate/movenc > > > > > > > > You are writing in the future tense, meaning you are making a > > > > prediction. > > > > > > > > You need to explain what you did, and the results. For example, did you > > > > re-run the tests with -w, as suggested in > > > > https://ffmpeg.org/pipermail/ffmpeg-devel/2020-April/260837.html > > > > to examine the files before and after the change? > > > > > > I have checked with one of non-empty-moov.mp4, and have observed one byte > > > difference > > > only(02 and 01). I haven't tool to dump every box in detail. If you > > > think it's necessary, > > > I can looked at the movenc muxer further and figure out which field it's. > > > > > > [lmwang@vpn ffmpeg]$ hexdump -C non-empty-moov.mp4 > non-empty-moov.hex > > > [lmwang@vpn ffmpeg]$ hexdump -C non-empty-moov1.mp4 > non-empty-moov1.hex > > > [lmwang@vpn ffmpeg]$ diff non-empty-moov.hex non-empty-moov1.hex > > > 162c162 > > > < 0a10 08 02 00 00 00 00 00 00 14 74 66 64 74 01 00 00 > > > |.tfdt...| > > > --- > > > > 0a10 08 01 01 00 00 00 00 00 14 74 66 64 74 01 00 00 > > > > |.tfdt...| > > > > > > > As noted elsewhere before in a related thread, L-SMASH's > > (https://github.com/l-smash/l-smash) boxdumper is a nice tool to get a > > text representation of MOV/MP4/etc boxes. utilize the --box parameter > > and dump stdout to a file. Then you can diff -u or otherwise. > Thanks, I'll try to build the tool to use. By the ffmpeg trace log, the > difference is frag flags of tfhd: > > [mov,mp4,m4a,3gp,3g2,mj2 @ 0x2ff02c0] type:'tfhd' parent:'traf' sz: 36 8 76 > [mov,mp4,m4a,3gp,3g2,mj2 @ 0x2ff02c0] frag flags 0x101 > > > [mov,mp4,m4a,3gp,3g2,mj2 @ 0x295c2c0] type:'tfhd' parent:'traf' sz: 36 8 76 > [mov,mp4,m4a,3gp,3g2,mj2 @ 0x295c2c0] frag flags 0x200 > If I recall correctly, boxdumper will give you what these flags mean in a more readable manner. Jan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/vf_v360: check the limit of in_pad and out_pad
> 2020年4月21日 下午10:28，Paul B Mahol 写道：
>
> On 4/21/20, Steven Liu wrote:
>> When i set out_pad=1 it will Segmentation fault
>> so i think it should check the limit value of the in_pad and out_pad
>
> So huge pads do not make sense.
Yes, just don’t know how to use it, and try to set it to 1, so get the
exception. :D
> Limit it to 1/10 in via options.
What about modify the limit looks like this ?
{ "out_pad", "percent output cubemap pads", OFFSET(out_pad),
AV_OPT_TYPE_FLOAT, {.dbl=0.f}, 0.f, 0.1,TFLAGS,
"out_pad"},
> ___
> 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".
Thanks
Steven Liu
___
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_v360: check the limit of in_pad and out_pad
On 4/21/20, Steven Liu wrote: > When i set out_pad=1 it will Segmentation fault > so i think it should check the limit value of the in_pad and out_pad So huge pads do not make sense. Limit it to 1/10 in via options. ___ 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 2/2] avformat/mux: Set AV_PKT_FLAG_KEY for is_intra_only packet
Limin Wang (12020-04-21): > Thanks, I'll try to build the tool to use. By the ffmpeg trace log, the > difference is frag flags of tfhd: The trace log is still seeing things from the inside. If there is a bug after the trace point, it will not be detected. It is important to test the RESULTING FILE with a DIFFERENT TOOL. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 2/2] avformat/mux: Set AV_PKT_FLAG_KEY for is_intra_only packet
On Tue, Apr 21, 2020 at 04:52:16PM +0300, Jan Ekström wrote: > On Tue, Apr 21, 2020 at 4:19 PM Limin Wang wrote: > > > > On Tue, Apr 21, 2020 at 01:08:05PM +0200, Nicolas George wrote: > > > Limin Wang (12020-04-21): > > > > OK, below is the commit log, please help to review whether it's your > > > > expected log: > > > > > > > > NOTE about the testing effect: > > > > subtitle packet will be marked as keyframe, it'll change below testing > > > > reference > > > > files: > > > > tests/ref/fate/binsub-movtextenc and tests/ref/fate/sub2video > > > > > > > > audio packet will be marked as keyframe, it'll change below testing > > > > reference file > > > > tests/ref/fate/movenc > > > > > > You are writing in the future tense, meaning you are making a > > > prediction. > > > > > > You need to explain what you did, and the results. For example, did you > > > re-run the tests with -w, as suggested in > > > https://ffmpeg.org/pipermail/ffmpeg-devel/2020-April/260837.html > > > to examine the files before and after the change? > > > > I have checked with one of non-empty-moov.mp4, and have observed one byte > > difference > > only(02 and 01). I haven't tool to dump every box in detail. If you think > > it's necessary, > > I can looked at the movenc muxer further and figure out which field it's. > > > > [lmwang@vpn ffmpeg]$ hexdump -C non-empty-moov.mp4 > non-empty-moov.hex > > [lmwang@vpn ffmpeg]$ hexdump -C non-empty-moov1.mp4 > non-empty-moov1.hex > > [lmwang@vpn ffmpeg]$ diff non-empty-moov.hex non-empty-moov1.hex > > 162c162 > > < 0a10 08 02 00 00 00 00 00 00 14 74 66 64 74 01 00 00 > > |.tfdt...| > > --- > > > 0a10 08 01 01 00 00 00 00 00 14 74 66 64 74 01 00 00 > > > |.tfdt...| > > > > As noted elsewhere before in a related thread, L-SMASH's > (https://github.com/l-smash/l-smash) boxdumper is a nice tool to get a > text representation of MOV/MP4/etc boxes. utilize the --box parameter > and dump stdout to a file. Then you can diff -u or otherwise. Thanks, I'll try to build the tool to use. By the ffmpeg trace log, the difference is frag flags of tfhd: [mov,mp4,m4a,3gp,3g2,mj2 @ 0x2ff02c0] type:'tfhd' parent:'traf' sz: 36 8 76 [mov,mp4,m4a,3gp,3g2,mj2 @ 0x2ff02c0] frag flags 0x101 [mov,mp4,m4a,3gp,3g2,mj2 @ 0x295c2c0] type:'tfhd' parent:'traf' sz: 36 8 76 [mov,mp4,m4a,3gp,3g2,mj2 @ 0x295c2c0] frag flags 0x200 > > Best regards, > Jan > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". -- Thanks, Limin Wang ___ 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 2/2] avformat/mux: Set AV_PKT_FLAG_KEY for is_intra_only packet
On Tue, Apr 21, 2020 at 4:19 PM Limin Wang wrote: > > On Tue, Apr 21, 2020 at 01:08:05PM +0200, Nicolas George wrote: > > Limin Wang (12020-04-21): > > > OK, below is the commit log, please help to review whether it's your > > > expected log: > > > > > > NOTE about the testing effect: > > > subtitle packet will be marked as keyframe, it'll change below testing > > > reference > > > files: > > > tests/ref/fate/binsub-movtextenc and tests/ref/fate/sub2video > > > > > > audio packet will be marked as keyframe, it'll change below testing > > > reference file > > > tests/ref/fate/movenc > > > > You are writing in the future tense, meaning you are making a > > prediction. > > > > You need to explain what you did, and the results. For example, did you > > re-run the tests with -w, as suggested in > > https://ffmpeg.org/pipermail/ffmpeg-devel/2020-April/260837.html > > to examine the files before and after the change? > > I have checked with one of non-empty-moov.mp4, and have observed one byte > difference > only(02 and 01). I haven't tool to dump every box in detail. If you think > it's necessary, > I can looked at the movenc muxer further and figure out which field it's. > > [lmwang@vpn ffmpeg]$ hexdump -C non-empty-moov.mp4 > non-empty-moov.hex > [lmwang@vpn ffmpeg]$ hexdump -C non-empty-moov1.mp4 > non-empty-moov1.hex > [lmwang@vpn ffmpeg]$ diff non-empty-moov.hex non-empty-moov1.hex > 162c162 > < 0a10 08 02 00 00 00 00 00 00 14 74 66 64 74 01 00 00 > |.tfdt...| > --- > > 0a10 08 01 01 00 00 00 00 00 14 74 66 64 74 01 00 00 > > |.tfdt...| > As noted elsewhere before in a related thread, L-SMASH's (https://github.com/l-smash/l-smash) boxdumper is a nice tool to get a text representation of MOV/MP4/etc boxes. utilize the --box parameter and dump stdout to a file. Then you can diff -u or otherwise. Best regards, Jan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/vf_v360: check the limit of in_pad and out_pad
Steven Liu (12020-04-21): > When i set out_pad=1 it will Segmentation fault > so i think it should check the limit value of the in_pad and out_pad > > Signed-off-by: Steven Liu > --- > libavfilter/vf_v360.c | 4 > 1 file changed, 4 insertions(+) Please don't guess. Find the exact cause of the crash. The value 1 is allowed by the option system, it is therefore a priori supposed to work, rejecting it somewhere else is not a proper fix. > +av_log(s, AV_LOG_ERROR, "pad should smaller than 1.0\n"); Also a missing verb. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avfilter/vf_v360: check the limit of in_pad and out_pad
When i set out_pad=1 it will Segmentation fault
so i think it should check the limit value of the in_pad and out_pad
Signed-off-by: Steven Liu
---
libavfilter/vf_v360.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavfilter/vf_v360.c b/libavfilter/vf_v360.c
index ebc281dfca..6aabbc11ff 100644
--- a/libavfilter/vf_v360.c
+++ b/libavfilter/vf_v360.c
@@ -3766,6 +3766,10 @@ static int config_output(AVFilterLink *outlink)
int (*prepare_out)(AVFilterContext *ctx);
int have_alpha;
+if (s->out_pad == 1.0 || s->in_pad == 1.0) {
+av_log(s, AV_LOG_ERROR, "pad should smaller than 1.0\n");
+return AVERROR(EINVAL);
+}
s->max_value = (1 << depth) - 1;
s->input_mirror_modifier[0] = s->ih_flip ? -1.f : 1.f;
s->input_mirror_modifier[1] = s->iv_flip ? -1.f : 1.f;
--
2.25.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 v10 0/2] Pro Pinball Series Soundbank demuxer + decoder.
On Sat, 18 Apr 2020 00:20:30 + "Zane van Iperen" wrote: > > Zane van Iperen (2): > avcodec: add support for Cunning Developments' ADPCM > avformat: add demuxer for Pro Pinball Series' Soundbanks > > Changelog| 2 + > doc/general.texi | 1 + > libavcodec/Makefile | 1 + > libavcodec/adpcm.c | 33 + > libavcodec/adpcm_data.c | 13 ++ > libavcodec/adpcm_data.h | 2 + > libavcodec/allcodecs.c | 1 + > libavcodec/codec_desc.c | 7 + > libavcodec/codec_id.h| 1 + > libavcodec/version.h | 2 +- > libavformat/Makefile | 1 + > libavformat/allformats.c | 1 + > libavformat/pp_bnk.c | 293 > +++ libavformat/version.h| > 2 +- 14 files changed, 358 insertions(+), 2 deletions(-) > create mode 100644 libavformat/pp_bnk.c > Ping. Zane ___ 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 2/2] avformat/mux: Set AV_PKT_FLAG_KEY for is_intra_only packet
Limin Wang (12020-04-21): > I have checked with one of non-empty-moov.mp4, and have observed one byte > difference > only(02 and 01). I haven't tool to dump every box in detail. If you think > it's necessary, > I can looked at the movenc muxer further and figure out which field it's. You can use ffprobe to check the difference to be sure it is what you think it is, no need for complex tools. If you do that for all the tests that have changed and write it in the commit message, I have no more objections. > > [lmwang@vpn ffmpeg]$ hexdump -C non-empty-moov.mp4 > non-empty-moov.hex > [lmwang@vpn ffmpeg]$ hexdump -C non-empty-moov1.mp4 > non-empty-moov1.hex > [lmwang@vpn ffmpeg]$ diff non-empty-moov.hex non-empty-moov1.hex As a side note, never use diff without the -u option, it is annoying to read. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 2/2] avformat/mux: Set AV_PKT_FLAG_KEY for is_intra_only packet
On Tue, Apr 21, 2020 at 01:08:05PM +0200, Nicolas George wrote: > Limin Wang (12020-04-21): > > OK, below is the commit log, please help to review whether it's your > > expected log: > > > > NOTE about the testing effect: > > subtitle packet will be marked as keyframe, it'll change below testing > > reference > > files: > > tests/ref/fate/binsub-movtextenc and tests/ref/fate/sub2video > > > > audio packet will be marked as keyframe, it'll change below testing > > reference file > > tests/ref/fate/movenc > > You are writing in the future tense, meaning you are making a > prediction. > > You need to explain what you did, and the results. For example, did you > re-run the tests with -w, as suggested in > https://ffmpeg.org/pipermail/ffmpeg-devel/2020-April/260837.html > to examine the files before and after the change? I have checked with one of non-empty-moov.mp4, and have observed one byte difference only(02 and 01). I haven't tool to dump every box in detail. If you think it's necessary, I can looked at the movenc muxer further and figure out which field it's. [lmwang@vpn ffmpeg]$ hexdump -C non-empty-moov.mp4 > non-empty-moov.hex [lmwang@vpn ffmpeg]$ hexdump -C non-empty-moov1.mp4 > non-empty-moov1.hex [lmwang@vpn ffmpeg]$ diff non-empty-moov.hex non-empty-moov1.hex 162c162 < 0a10 08 02 00 00 00 00 00 00 14 74 66 64 74 01 00 00 |.tfdt...| --- > 0a10 08 01 01 00 00 00 00 00 14 74 66 64 74 01 00 00 |.tfdt...| > > Regards, > > -- > Nicolas George > ___ > 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". -- Thanks, Limin Wang ___ 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 2/2] avformat/mux: Set AV_PKT_FLAG_KEY for is_intra_only packet
Limin Wang (12020-04-21): > OK, below is the commit log, please help to review whether it's your expected > log: > > NOTE about the testing effect: > subtitle packet will be marked as keyframe, it'll change below testing > reference > files: > tests/ref/fate/binsub-movtextenc and tests/ref/fate/sub2video > > audio packet will be marked as keyframe, it'll change below testing reference > file > tests/ref/fate/movenc You are writing in the future tense, meaning you are making a prediction. You need to explain what you did, and the results. For example, did you re-run the tests with -w, as suggested in https://ffmpeg.org/pipermail/ffmpeg-devel/2020-April/260837.html to examine the files before and after the change? Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 2/2] avformat/mux: Set AV_PKT_FLAG_KEY for is_intra_only packet
On Tue, Apr 21, 2020 at 12:35:39PM +0200, Nicolas George wrote: > lance.lmw...@gmail.com (12020-04-21): > > From: Limin Wang > > > > Signed-off-by: Limin Wang > > --- > > libavformat/internal.h | 2 + > > libavformat/mux.c| 7 +++- > > tests/ref/fate/binsub-movtextenc | 2 +- > > tests/ref/fate/movenc| 50 +++ > > tests/ref/fate/sub2video | 86 > > > > 5 files changed, 77 insertions(+), 70 deletions(-) > > I should have replied to this message: > > You forgot the part about writing the result of your examination of the > tests in the commit message. > > A commit that changes tests reference files should explain what changed. OK, below is the commit log, please help to review whether it's your expected log: NOTE about the testing effect: subtitle packet will be marked as keyframe, it'll change below testing reference files: tests/ref/fate/binsub-movtextenc and tests/ref/fate/sub2video audio packet will be marked as keyframe, it'll change below testing reference file tests/ref/fate/movenc > > > Regards, > > -- > Nicolas George -- Thanks, Limin Wang ___ 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 2/2] avformat/mux: Set AV_PKT_FLAG_KEY for is_intra_only packet
lance.lmw...@gmail.com (12020-04-21): > From: Limin Wang > > Signed-off-by: Limin Wang > --- > libavformat/internal.h | 2 + > libavformat/mux.c| 7 +++- > tests/ref/fate/binsub-movtextenc | 2 +- > tests/ref/fate/movenc| 50 +++ > tests/ref/fate/sub2video | 86 > > 5 files changed, 77 insertions(+), 70 deletions(-) I should have replied to this message: You forgot the part about writing the result of your examination of the tests in the commit message. A commit that changes tests reference files should explain what changed. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 1/4] fftools/ffmpeg: set AV_PKT_FLAG_KEY for the subtitle packet
Limin Wang (12020-04-21): > OK, Got it, I'll merge patch #1,#2,#4 into one patch and update the patch set. You forgot the part about writing the result of your examination of the tests in the commit message. A commit that changes tests reference files should explain what changed. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v3 2/2] avformat/mux: Set AV_PKT_FLAG_KEY for is_intra_only packet
From: Limin Wang
Signed-off-by: Limin Wang
---
libavformat/internal.h | 2 +
libavformat/mux.c| 7 +++-
tests/ref/fate/binsub-movtextenc | 2 +-
tests/ref/fate/movenc| 50 +++
tests/ref/fate/sub2video | 86
5 files changed, 77 insertions(+), 70 deletions(-)
diff --git a/libavformat/internal.h b/libavformat/internal.h
index 716e42c..c4fac5c 100644
--- a/libavformat/internal.h
+++ b/libavformat/internal.h
@@ -189,6 +189,8 @@ struct AVStreamInternal {
*/
int need_context_update;
+int is_intra_only;
+
FFFrac *priv_pts;
};
diff --git a/libavformat/mux.c b/libavformat/mux.c
index a6253f5..ea6524f 100644
--- a/libavformat/mux.c
+++ b/libavformat/mux.c
@@ -357,6 +357,8 @@ FF_ENABLE_DEPRECATION_WARNINGS
if (desc && desc->props & AV_CODEC_PROP_REORDER)
st->internal->reorder = 1;
+st->internal->is_intra_only = ff_is_intra_only(par->codec_id);
+
if (of->codec_tag) {
if ( par->codec_tag
&& par->codec_id == AV_CODEC_ID_RAWVIDEO
@@ -773,6 +775,7 @@ static int check_packet(AVFormatContext *s, AVPacket *pkt)
static int prepare_input_packet(AVFormatContext *s, AVPacket *pkt)
{
int ret;
+AVStream *st = s->streams[pkt->stream_index];
ret = check_packet(s, pkt);
if (ret < 0)
@@ -781,7 +784,6 @@ static int prepare_input_packet(AVFormatContext *s,
AVPacket *pkt)
#if !FF_API_COMPUTE_PKT_FIELDS2 || !FF_API_LAVF_AVCTX
/* sanitize the timestamps */
if (!(s->oformat->flags & AVFMT_NOTIMESTAMPS)) {
-AVStream *st = s->streams[pkt->stream_index];
/* when there is no reordering (so dts is equal to pts), but
* only one of them is set, set the other as well */
@@ -818,6 +820,9 @@ static int prepare_input_packet(AVFormatContext *s,
AVPacket *pkt)
}
}
#endif
+/* update flags */
+if (st->internal->is_intra_only)
+pkt->flags |= AV_PKT_FLAG_KEY;
return 0;
}
diff --git a/tests/ref/fate/binsub-movtextenc b/tests/ref/fate/binsub-movtextenc
index 78c05f4..a8f94b7 100644
--- a/tests/ref/fate/binsub-movtextenc
+++ b/tests/ref/fate/binsub-movtextenc
@@ -1 +1 @@
-35adf776cd73e808186ae7124445f4b8
+fc6d07679ac1f718aa50de687924cd97
diff --git a/tests/ref/fate/movenc b/tests/ref/fate/movenc
index 637a347..fb39b98 100644
--- a/tests/ref/fate/movenc
+++ b/tests/ref/fate/movenc
@@ -2,17 +2,17 @@ write_data len 36, time nopts, type header atom ftyp
write_data len 2389, time nopts, type header atom -
write_data len 788, time 100, type sync atom moof
write_data len 110, time nopts, type trailer atom -
-66cf48604f039aa9a51711786f5c8778 3323 non-empty-moov
+5f401347fc3c771b819e2449d69d4861 3323 non-empty-moov
write_data len 36, time nopts, type header atom ftyp
write_data len 2721, time nopts, type header atom -
write_data len 908, time 97, type sync atom moof
write_data len 110, time nopts, type trailer atom -
-04b2e86f455af94f9258b8d66dbf71f5 3775 non-empty-moov-elst
+4267feee527adf8cd4f7b36ac0fc0872 3775 non-empty-moov-elst
write_data len 36, time nopts, type header atom ftyp
write_data len 2629, time nopts, type header atom -
write_data len 908, time 100, type sync atom moof
write_data len 110, time nopts, type trailer atom -
-e9f6fa032d6d8265d67aef5de81a48bf 3683 non-empty-moov-no-elst
+44077b9ad45f3e16fafe4e5ada54e9b0 3683 non-empty-moov-no-elst
write_data len 24, time nopts, type header atom ftyp
write_data len 1171, time nopts, type header atom -
write_data len 728, time 0, type sync atom moof
@@ -20,35 +20,35 @@ write_data len 828, time nopts, type unknown atom -
write_data len 728, time 99, type sync atom moof
write_data len 812, time nopts, type unknown atom -
write_data len 148, time nopts, type trailer atom -
-da105e0b2c19079519c6eed7d5a1151c 4439 ismv
+92ce825ff40505ec8676191705adb7e7 4439 ismv
write_data len 36, time nopts, type header atom ftyp
write_data len 1123, time nopts, type header atom -
write_data len 796, time 0, type sync atom moof
write_data len 788, time 100, type sync atom moof
write_data len 148, time nopts, type trailer atom -
-e6a4b15443d006efd727a80f6624b7db 2891 empty-moov
+08f4b3ad3a3ea224b2ee731476b9056b 2891 empty-moov
write_data len 36, time nopts, type header atom ftyp
write_data len 1123, time nopts, type header atom -
write_data len 1068, time 0, type sync atom moof
write_data len 908, time 100, type sync atom moof
write_data len 148, time nopts, type trailer atom -
-800f854aff2ac76dfaddebd0562c75b9 3283 empty-moov-no-elst
+d7a2dcb43eb0f95f92669f55fc7adeba 3283 empty-moov-no-elst
write_data len 36, time nopts, type header atom ftyp
write_data len 1123, time nopts, type header atom -
write_data len 900, time -3, type sync atom moof
write_data len 908, time 97, type sync atom moof
write_data len 148, time nopts, type trailer atom -
Re: [FFmpeg-devel] [PATCH v2 3/4] libavcodec/qsv: enabling d3d11va support, added mfxhdlpair
Mostly the same remarks as for 2/4 regarding the uneeded loop and
uninitialized handle_type, plus comments below.
On 2020-04-15 15:07, artem.ga...@gmail.com wrote:
From: Artem Galin
Adding DX11 relevant device type checks and adjusting callbacks with
proper MediaSDK pair type support.
Extending structure for proper MediaSDK pair type support.
Signed-off-by: Artem Galin
---
libavcodec/qsv.c | 52 ---
libavcodec/qsv_internal.h | 1 +
2 files changed, 49 insertions(+), 4 deletions(-)
diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
index db98c75073..ceef1b7fd9 100644
--- a/libavcodec/qsv.c
+++ b/libavcodec/qsv.c
@@ -36,6 +36,8 @@
#include "avcodec.h"
#include "qsv_internal.h"
+#define MFX_IMPL_VIA_MASK(impl) (0x0f00 & (impl))
+
#if QSV_VERSION_ATLEAST(1, 12)
#include "mfx/mfxvp8.h"
#endif
@@ -221,8 +223,15 @@ int ff_qsv_find_surface_idx(QSVFramesContext *ctx,
QSVFrame *frame)
int i;
for (i = 0; i < ctx->nb_mids; i++) {
QSVMid *mid = >mids[i];
+#if CONFIG_VAAPI
if (mid->handle == frame->surface.Data.MemId)
return i;
+#else
+mfxHDLPair *pair = (mfxHDLPair*)frame->surface.Data.MemId;
+if ((mid->handle_pair.first == pair->first) &&
+(mid->handle_pair.second == pair->second))
+return i;
+#endif
}
return AVERROR_BUG;
}
@@ -362,7 +371,11 @@ static int ff_qsv_set_display_handle(AVCodecContext
*avctx, QSVSession *qs)
int ff_qsv_init_internal_session(AVCodecContext *avctx, QSVSession *qs,
const char *load_plugins, int gpu_copy)
{
+#ifdef AVCODEC_QSV_LINUX_SESSION_HANDLE
mfxIMPL impl = MFX_IMPL_AUTO_ANY;
+#else
+mfxIMPL impl = MFX_IMPL_AUTO_ANY | MFX_IMPL_VIA_D3D11;
Why is this needed ? If D3D11 is available it should pick it, no ? Does
it mean you can favor D3D11 over D3D9 ?
+#endif
mfxVersionver = { { QSV_VERSION_MINOR, QSV_VERSION_MAJOR } };
mfxInitParam init_par = { MFX_IMPL_AUTO_ANY };
@@ -449,11 +462,19 @@ static AVBufferRef *qsv_create_mids(AVBufferRef *hw_frames_ref)
return NULL;
}
+#if CONFIG_VAAPI
for (i = 0; i < nb_surfaces; i++) {
QSVMid *mid = [i];
mid->handle= frames_hwctx->surfaces[i].Data.MemId;
mid->hw_frames_ref = hw_frames_ref1;
}
+#else
+for (i = 0; i < nb_surfaces; i++) {
+QSVMid *mid = [i];
+mid->handle_pair =
*((mfxHDLPair*)frames_hwctx->surfaces[i].Data.MemId);
+mid->hw_frames_ref = hw_frames_ref1;
+}
+#endif
return mids_buf;
}
@@ -628,7 +649,11 @@ static mfxStatus qsv_frame_lock(mfxHDL pthis, mfxMemId
mid, mfxFrameData *ptr)
goto fail;
qsv_mid->surf.Info = hw_frames_hwctx->surfaces[0].Info;
+#if CONFIG_VAAPI
qsv_mid->surf.Data.MemId = qsv_mid->handle;
+#else
+qsv_mid->surf.Data.MemId = _mid->handle_pair;
+#endif
/* map the data to the system memory */
ret = av_hwframe_map(qsv_mid->locked_frame, qsv_mid->hw_frame,
@@ -661,7 +686,17 @@ static mfxStatus qsv_frame_unlock(mfxHDL pthis, mfxMemId
mid, mfxFrameData *ptr)
static mfxStatus qsv_frame_get_hdl(mfxHDL pthis, mfxMemId mid, mfxHDL *hdl)
{
QSVMid *qsv_mid = (QSVMid*)mid;
+#if CONFIG_VAAPI
*hdl = qsv_mid->handle;
+#else
+mfxHDLPair *pair_dst = (mfxHDLPair*)hdl;
+mfxHDLPair *pair_src = (mfxHDLPair*)_mid->handle_pair;
+
+pair_dst->first = pair_src->first;
+
+if (pair_src->second != (mfxMemId)MFX_INFINITE)
+pair_dst->second = pair_src->second;
+#endif
return MFX_ERR_NONE;
}
@@ -695,11 +730,20 @@ int ff_qsv_init_session_device(AVCodecContext *avctx, mfxSession *psession,
return ff_qsv_print_error(avctx, err,
"Error querying the session attributes");
+if (MFX_IMPL_VIA_D3D11 == MFX_IMPL_VIA_MASK(impl)) {
+handle_type = MFX_HANDLE_D3D11_DEVICE;
+} else if (MFX_IMPL_VIA_D3D9 == MFX_IMPL_VIA_MASK(impl)) {
+handle_type = MFX_HANDLE_D3D9_DEVICE_MANAGER;
+} else if (MFX_IMPL_VIA_VAAPI == MFX_IMPL_VIA_MASK(impl)) {
+handle_type = MFX_HANDLE_VA_DISPLAY;
+}
+
for (i = 0; i < FF_ARRAY_ELEMS(handle_types); i++) {
-err = MFXVideoCORE_GetHandle(parent_session, handle_types[i], );
-if (err == MFX_ERR_NONE) {
-handle_type = handle_types[i];
-break;
+if (handle_types[i] == handle_type) {
+err = MFXVideoCORE_GetHandle(parent_session, handle_types[i],
);
+if (err == MFX_ERR_NONE) {
+break;
+}
}
handle = NULL;
}
diff --git a/libavcodec/qsv_internal.h b/libavcodec/qsv_internal.h
index 6489836a67..7a4a66e9d6 100644
--- a/libavcodec/qsv_internal.h
+++ b/libavcodec/qsv_internal.h
@@ -61,6 +61,7 @@
typedef struct QSVMid {
AVBufferRef *hw_frames_ref;
mfxHDL
Re: [FFmpeg-devel] [PATCH v2 2/4] libavfilter/qsvvpp: enabling d3d11va support
Comments below.
On 2020-04-15 15:07, artem.ga...@gmail.com wrote:
From: Artem Galin
Adding DX11 relevant device type checks and adjusting callback with
proper MediaSDK pair type support.
Signed-off-by: Artem Galin
---
libavfilter/qsvvpp.c | 40 ++--
1 file changed, 30 insertions(+), 10 deletions(-)
diff --git a/libavfilter/qsvvpp.c b/libavfilter/qsvvpp.c
index 8d5ff2eb65..8c6c878bac 100644
--- a/libavfilter/qsvvpp.c
+++ b/libavfilter/qsvvpp.c
@@ -32,10 +32,11 @@
#include "qsvvpp.h"
#include "video.h"
-#define IS_VIDEO_MEMORY(mode) (mode & (MFX_MEMTYPE_VIDEO_MEMORY_DECODER_TARGET | \
+#define IS_VIDEO_MEMORY(mode) (mode &
(MFX_MEMTYPE_VIDEO_MEMORY_DECODER_TARGET | \
MFX_MEMTYPE_VIDEO_MEMORY_PROCESSOR_TARGET))
-#define IS_OPAQUE_MEMORY(mode) (mode & MFX_MEMTYPE_OPAQUE_FRAME)
-#define IS_SYSTEM_MEMORY(mode) (mode & MFX_MEMTYPE_SYSTEM_MEMORY)
+#define IS_OPAQUE_MEMORY(mode) (mode & MFX_MEMTYPE_OPAQUE_FRAME)
+#define IS_SYSTEM_MEMORY(mode) (mode & MFX_MEMTYPE_SYSTEM_MEMORY)
Not sure changing these lines just to add a space is worth.
+#define MFX_IMPL_VIA_MASK(impl) (0x0f00 & (impl))
typedef struct QSVFrame {
AVFrame *frame;
@@ -129,7 +130,17 @@ static mfxStatus frame_unlock(mfxHDL pthis, mfxMemId mid,
mfxFrameData *ptr)
static mfxStatus frame_get_hdl(mfxHDL pthis, mfxMemId mid, mfxHDL *hdl)
{
+#if CONFIG_VAAPI
*hdl = mid;
+#else
+mfxHDLPair *pair_dst = (mfxHDLPair*)hdl;
+mfxHDLPair *pair_src = (mfxHDLPair*)mid;
+
+pair_dst->first = pair_src->first;
+
+if (pair_src->second != (mfxMemId)MFX_INFINITE)
+pair_dst->second = pair_src->second;
+#endif
return MFX_ERR_NONE;
}
@@ -451,7 +462,7 @@ static int init_vpp_session(AVFilterContext *avctx, QSVVPPContext *s)
s->out_mem_mode = IS_OPAQUE_MEMORY(s->in_mem_mode) ?
MFX_MEMTYPE_OPAQUE_FRAME :
- MFX_MEMTYPE_VIDEO_MEMORY_DECODER_TARGET;
+ MFX_MEMTYPE_VIDEO_MEMORY_DECODER_TARGET |
MFX_MEMTYPE_FROM_VPPOUT;
What's the effect of this flag on VAAPI ?
out_frames_ctx = (AVHWFramesContext *)out_frames_ref->data;
out_frames_hwctx = out_frames_ctx->hwctx;
@@ -497,15 +508,24 @@ static int init_vpp_session(AVFilterContext *avctx,
QSVVPPContext *s)
return AVERROR_UNKNOWN;
}
+if (MFX_IMPL_VIA_D3D11 == MFX_IMPL_VIA_MASK(impl)) {
+handle_type = MFX_HANDLE_D3D11_DEVICE;
+} else if (MFX_IMPL_VIA_D3D9 == MFX_IMPL_VIA_MASK(impl)) {
+handle_type = MFX_HANDLE_D3D9_DEVICE_MANAGER;
+} else if (MFX_IMPL_VIA_VAAPI == MFX_IMPL_VIA_MASK(impl)) {
+handle_type = MFX_HANDLE_VA_DISPLAY;
+}
handle_type is potentially used initialized after that. You probably
want to return an error is the handle type is unknown.
+
for (i = 0; i < FF_ARRAY_ELEMS(handle_types); i++) {
-ret = MFXVideoCORE_GetHandle(device_hwctx->session, handle_types[i],
);
-if (ret == MFX_ERR_NONE) {
-handle_type = handle_types[i];
-break;
+if (handle_types[i] == handle_type) {
You're losing the possibility to pick whichever the system provides.
Although in real life it may not be an issue if you can only have VAAPI
or D3D9/D3D11 separately.
Also you don't need to do the for() loop since you only want to read the
handle of the type you want.
The title of the patch is misleading. MFX_HANDLE_D3D11_DEVICE was
already supported in the list of handles.
+ret = MFXVideoCORE_GetHandle(device_hwctx->session, handle_types[i],
);
+if (ret == MFX_ERR_NONE) {
+break;
+}
}
+handle = NULL;
}
-
-if (ret != MFX_ERR_NONE) {
+if (!handle) {
av_log(avctx, AV_LOG_ERROR, "Error getting the session handle\n");
return AVERROR_UNKNOWN;
}
--
2.26.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] [PATCH v3 1/2] avformat/utils: move is_intra_only() to header and rename to ff_is_intra_only()
From: Limin Wang
Signed-off-by: Limin Wang
---
libavformat/internal.h | 2 ++
libavformat/utils.c| 4 ++--
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavformat/internal.h b/libavformat/internal.h
index 329b2e9..716e42c 100644
--- a/libavformat/internal.h
+++ b/libavformat/internal.h
@@ -521,6 +521,8 @@ unsigned int ff_codec_get_tag(const AVCodecTag *tags, enum
AVCodecID id);
enum AVCodecID ff_codec_get_id(const AVCodecTag *tags, unsigned int tag);
+int ff_is_intra_only(enum AVCodecID id);
+
/**
* Select a PCM codec based on the given parameters.
*
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 2fb2309..259b2f0 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -1016,7 +1016,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
}
}
-static int is_intra_only(enum AVCodecID id)
+int ff_is_intra_only(enum AVCodecID id)
{
const AVCodecDescriptor *d = avcodec_descriptor_get(id);
if (!d)
@@ -1415,7 +1415,7 @@ static void compute_pkt_fields(AVFormatContext *s,
AVStream *st,
presentation_delayed, delay, av_ts2str(pkt->pts),
av_ts2str(pkt->dts), av_ts2str(st->cur_dts), st->index, st->id);
/* update flags */
-if (st->codecpar->codec_type == AVMEDIA_TYPE_DATA ||
is_intra_only(st->codecpar->codec_id))
+if (st->codecpar->codec_type == AVMEDIA_TYPE_DATA ||
ff_is_intra_only(st->codecpar->codec_id))
pkt->flags |= AV_PKT_FLAG_KEY;
#if FF_API_CONVERGENCE_DURATION
FF_DISABLE_DEPRECATION_WARNINGS
--
2.9.5
___
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 4/4] libavutil/qsv: enabling d3d11va support
On 2020-04-15 15:07, artem.ga...@gmail.com wrote:
From: Artem Galin
Makes selection of d3d11va device type by default and over DirectX 9,
which is still supported but requires explicit selection.
This enables usage of non-powered/headless GPU, better HDR support.
Pool of resources is allocated as one texture with array of slices.
I'm all for it ;)
Added d3d11va device selection by vendor id.
Example: --init_hw_device d3d11va:,vendor=0x8086
DirectX 9 usage.
Example: --init_hw_device qsv:hw,child_device_type=dxva2
Same remark as before on the possible uninitialized handle_type.
Signed-off-by: Artem Galin
---
libavutil/hwcontext_d3d11va.c | 82 +++-
libavutil/hwcontext_d3d11va.h | 8 +
libavutil/hwcontext_qsv.c | 339 +-
3 files changed, 371 insertions(+), 58 deletions(-)
diff --git a/libavutil/hwcontext_d3d11va.c b/libavutil/hwcontext_d3d11va.c
index c8ae58f908..9d7615eb55 100644
--- a/libavutil/hwcontext_d3d11va.c
+++ b/libavutil/hwcontext_d3d11va.c
@@ -72,7 +72,7 @@ static av_cold void load_functions(void)
}
typedef struct D3D11VAFramesContext {
-int nb_surfaces_used;
+int nb_surfaces;
Probably better as a size_t
DXGI_FORMAT format;
@@ -112,6 +112,8 @@ static void d3d11va_frames_uninit(AVHWFramesContext *ctx)
if (s->staging_texture)
ID3D11Texture2D_Release(s->staging_texture);
s->staging_texture = NULL;
+
+av_freep(_hwctx->texture_infos);
}
static int d3d11va_frames_get_constraints(AVHWDeviceContext *ctx,
@@ -152,8 +154,9 @@ static void free_texture(void *opaque, uint8_t *data)
av_free(data);
}
-static AVBufferRef *wrap_texture_buf(ID3D11Texture2D *tex, int index)
+static AVBufferRef *wrap_texture_buf(AVHWFramesContext *ctx, ID3D11Texture2D
*tex, int index)
{
+AVD3D11VAFramesContext *frames_hwctx = ctx->hwctx;
AVBufferRef *buf;
AVD3D11FrameDescriptor *desc = av_mallocz(sizeof(*desc));
if (!desc) {
@@ -161,6 +164,10 @@ static AVBufferRef *wrap_texture_buf(ID3D11Texture2D *tex,
int index)
return NULL;
}
+frames_hwctx->texture_infos[frames_hwctx->nb_surfaces_used].texture = tex;
+frames_hwctx->texture_infos[frames_hwctx->nb_surfaces_used].index = index;
+frames_hwctx->nb_surfaces_used++;
+
desc->texture = tex;
desc->index = index;
@@ -199,13 +206,12 @@ static AVBufferRef *d3d11va_alloc_single(AVHWFramesContext *ctx)
return NULL;
}
-return wrap_texture_buf(tex, 0);
+return wrap_texture_buf(ctx, tex, 0);
}
static AVBufferRef *d3d11va_pool_alloc(void *opaque, int size)
{
AVHWFramesContext*ctx = (AVHWFramesContext*)opaque;
-D3D11VAFramesContext *s = ctx->internal->priv;
AVD3D11VAFramesContext *hwctx = ctx->hwctx;
D3D11_TEXTURE2D_DESC texDesc;
@@ -214,13 +220,13 @@ static AVBufferRef *d3d11va_pool_alloc(void *opaque, int size)
ID3D11Texture2D_GetDesc(hwctx->texture, );
-if (s->nb_surfaces_used >= texDesc.ArraySize) {
+if (hwctx->nb_surfaces_used >= texDesc.ArraySize) {
av_log(ctx, AV_LOG_ERROR, "Static surface pool size exceeded.\n");
return NULL;
}
ID3D11Texture2D_AddRef(hwctx->texture);
-return wrap_texture_buf(hwctx->texture, s->nb_surfaces_used++);
+return wrap_texture_buf(ctx, hwctx->texture, hwctx->nb_surfaces_used);
}
static int d3d11va_frames_init(AVHWFramesContext *ctx)
@@ -267,7 +273,7 @@ static int d3d11va_frames_init(AVHWFramesContext *ctx)
av_log(ctx, AV_LOG_ERROR, "User-provided texture has mismatching
parameters\n");
return AVERROR(EINVAL);
}
-} else if (texDesc.ArraySize > 0) {
+} else if (!(texDesc.BindFlags & D3D11_BIND_RENDER_TARGET) &&
texDesc.ArraySize > 0) {
hr = ID3D11Device_CreateTexture2D(device_hwctx->device, , NULL,
>texture);
if (FAILED(hr)) {
av_log(ctx, AV_LOG_ERROR, "Could not create the texture (%lx)\n",
(long)hr);
@@ -275,6 +281,12 @@ static int d3d11va_frames_init(AVHWFramesContext *ctx)
}
}
+hwctx->texture_infos = av_mallocz_array(ctx->initial_pool_size, sizeof(*hwctx->texture_infos));
+if (!hwctx->texture_infos)
+return AVERROR(ENOMEM);
+
+s->nb_surfaces = ctx->initial_pool_size;
+
ctx->internal->pool_internal =
av_buffer_pool_init2(sizeof(AVD3D11FrameDescriptor),
ctx,
d3d11va_pool_alloc, NULL);
if (!ctx->internal->pool_internal)
@@ -511,15 +523,56 @@ static void d3d11va_device_uninit(AVHWDeviceContext
*hwdev)
}
}
+static int d3d11va_device_find_adapter_by_vendor_id(AVHWDeviceContext *ctx, UINT creationFlags, char *vendor)
+{
+HRESULT hr;
+IDXGIAdapter *adapter = NULL;
+int adapter_id = 0;
+IDXGIFactory2 *factory;
+long int vendor_id = strtol(vendor, NULL, 0);
+hr =
Re: [FFmpeg-devel] [PATCH v2 1/4] fftools/qsv: enabling d3d11va/dxva2 device selection
Hi,
On 2020-04-15 15:07, artem.ga...@gmail.com wrote:
From: Artem Galin
child_device_type argument is responsible for selection.
Usage examples: -init_hw_device qsv:hw,child_device_type=d3d11va
-init_hw_device qsv:hw,child_device_type=dxva2
Signed-off-by: Artem Galin
---
fftools/ffmpeg_opt.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index 95001a963f..82232c60b3 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -568,7 +568,17 @@ static int opt_init_hw_device(void *optctx, const char
*opt, const char *arg)
printf("\n");
exit_program(0);
} else {
-return hw_device_init_from_string(arg, NULL);
+HWDevice *dev;
+int err;
+if (!arg)
+return AVERROR(ENOMEM);
+err = hw_device_init_from_string(arg, );
+if (err < 0)
+return err;
+hw_device_ctx = av_buffer_ref(dev->device_ref);
+if (!hw_device_ctx)
+return AVERROR(ENOMEM);
+return 0;
This is very similar to what is done in opt_vaapi_device().
Maybe you could modify the "qsv_device" handling to support this ? It
will be ifdef'ed out when QSV is not enabled.
There might also be some side effects for other hardware devices.
Especially the hw_device_ctx reference doesn't seem to be released (but
it's the same in opt_vaapi_device so I might be missing something).
}
}
--
2.26.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 v2 1/4] fftools/ffmpeg: set AV_PKT_FLAG_KEY for the subtitle packet
On Tue, Apr 21, 2020 at 11:26:14AM +0200, Nicolas George wrote: > lance.lmw...@gmail.com (12020-04-21): > > From: Limin Wang > > > > For better code review, the patch is helping to update the fate tests result > > so the change of ffmpeg.c will be deleted in the last patch. > > > > Signed-off-by: Limin Wang > > You did not need to post it. You only needed to make it, run it, note > carefully the results, and the go back to your work and consign the > results in the relevant commit message. > > I mean, I do not know how you work, but personally I frequently add tons > of av_log() everywhere to track an issue. But they never get to the > mailing list. OK, Got it, I'll merge patch #1,#2,#4 into one patch and update the patch set. > > Regards, > > -- > Nicolas George -- Thanks, Limin Wang ___ 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 6/8] avcodec/dump_extradata_bsf: Remove unnecessary header
Quoting Andreas Rheinhardt (2020-04-21 04:31:51) > Since 33d18982fa03feb061c8f744a4f0a9175c1f63ab (the commit that > introduced the new bsf API) allocating an enlarged buffer in case > extradata needs to be added to a packet is done via av_new_packet(), > so that libavutil/mem.h is no longer needed. > > Furthermore, remove libavutil/log.h. This function uses something > provided by it (an AVClass), yet it does so only for AVOptions, not > for logging purposes (there is no av_log() here), so only including > libavutil/opt.h seems appropriate. IMO each file should include the headers for all the definitions it uses directly. I.e. if a file uses AVClass, it should include log.h. But I suppose it does not matter much in pracice (in this case especially), so feel free to ignore me. -- Anton Khirnov ___ 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] lavfi/vf_vpp_qsv: fix the infinite loop while framerate lower than input
> From: Zhong Li > Sent: Tuesday, April 21, 2020 17:10 > To: Fu, Linjie > Cc: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH] lavfi/vf_vpp_qsv: fix the infinite loop > while framerate lower than input > > > > I can't see the benefit to use MSDK framerate conversion function. Is > > > it a good idea to drop it and use ffmpeg native fps filter instead? > > > > The implementation of FRC inside MSDK is quite straight-forward or simple > > currently since it just drops or repeats frames, hence I think using native > fps > > filter is a good idea for decoding + FRC or FRC + encoding. > > > > However, for a pure hardware transcoding pipeline, there may be some > > performance issues if inserting a software filter, extra memory copy would > > be introduced in hwdownload/hwupload between system memory and > video > > memory, which would impact a lot for large resolutions. > IIRC, it is not necessary to insert hwdownload/upload to use fps filter. No ？ Ahh, you are right, the native fps filter would be fair enough for this case. Thanks for the elaborations. ___ 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 1/4] fftools/ffmpeg: set AV_PKT_FLAG_KEY for the subtitle packet
lance.lmw...@gmail.com (12020-04-21): > From: Limin Wang > > For better code review, the patch is helping to update the fate tests result > so the change of ffmpeg.c will be deleted in the last patch. > > Signed-off-by: Limin Wang You did not need to post it. You only needed to make it, run it, note carefully the results, and the go back to your work and consign the results in the relevant commit message. I mean, I do not know how you work, but personally I frequently add tons of av_log() everywhere to track an issue. But they never get to the mailing list. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavfi/vf_vpp_qsv: fix the infinite loop while framerate lower than input
> > I can't see the benefit to use MSDK framerate conversion function. Is > > it a good idea to drop it and use ffmpeg native fps filter instead? > > The implementation of FRC inside MSDK is quite straight-forward or simple > currently since it just drops or repeats frames, hence I think using native > fps > filter is a good idea for decoding + FRC or FRC + encoding. > > However, for a pure hardware transcoding pipeline, there may be some > performance issues if inserting a software filter, extra memory copy would > be introduced in hwdownload/hwupload between system memory and video > memory, which would impact a lot for large resolutions. IIRC, it is not necessary to insert hwdownload/upload to use fps filter. No ？ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/3] lavu/pix_fmt: add new pixel format x2rgb10
On Tue, Apr 21, 2020 at 9:53 AM Fei Wang wrote: > > The format is packed RGB with each channel 10 bits available and > include 2 bits unused. > The name of this pix_fmt seems very confusing, and the entire format seems very specific. What is such a packed RGB format really good for in ffmpeg? - Hendrik ___ 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] lavu/hwcontext_vaapi: add vaapi_format_map support for x2rgb10
Signed-off-by: Fei Wang
---
libavutil/hwcontext_vaapi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index b306965..50727fb 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -136,6 +136,9 @@ static const VAAPIFormatDescriptor vaapi_format_map[] = {
#endif
MAP(ARGB, RGB32, ARGB, 0),
MAP(XRGB, RGB32, 0RGB, 0),
+#ifdef VA_FOURCC_X2R10G10B10
+MAP(X2R10G10B10, RGB32_10, X2RGB10, 0),
+#endif
};
#undef MAP
--
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] swscale: Add swscale input/output support for X2RGB10LE
Signed-off-by: Fei Wang
---
libswscale/input.c | 13 -
libswscale/output.c | 14 ++
libswscale/utils.c | 1 +
libswscale/yuv2rgb.c | 22 ++
4 files changed, 49 insertions(+), 1 deletion(-)
diff --git a/libswscale/input.c b/libswscale/input.c
index 099661c..05fdc2f 100644
--- a/libswscale/input.c
+++ b/libswscale/input.c
@@ -244,7 +244,8 @@ rgb48funcs(bgr, BE, AV_PIX_FMT_BGR48BE)
#define input_pixel(i) ((origin == AV_PIX_FMT_RGBA || \
origin == AV_PIX_FMT_BGRA || \
origin == AV_PIX_FMT_ARGB || \
- origin == AV_PIX_FMT_ABGR)\
+ origin == AV_PIX_FMT_ABGR || \
+ origin == AV_PIX_FMT_X2RGB10)\
? AV_RN32A([(i) * 4]) \
: (isBE(origin) ? AV_RB16([(i) * 2])\
: AV_RL16([(i) * 2])))
@@ -391,6 +392,7 @@ rgb16_32_wrapper(AV_PIX_FMT_BGR444BE, bgr12be, 0, 0, 0, 0,
0x000F, 0x00F0,
rgb16_32_wrapper(AV_PIX_FMT_RGB565BE, rgb16be, 0, 0, 0, 0, 0xF800, 0x07E0,
0x001F, 0, 5, 11, RGB2YUV_SHIFT + 8)
rgb16_32_wrapper(AV_PIX_FMT_RGB555BE, rgb15be, 0, 0, 0, 0, 0x7C00, 0x03E0,
0x001F, 0, 5, 10, RGB2YUV_SHIFT + 7)
rgb16_32_wrapper(AV_PIX_FMT_RGB444BE, rgb12be, 0, 0, 0, 0, 0x0F00, 0x00F0,
0x000F, 0, 4, 8, RGB2YUV_SHIFT + 4)
+rgb16_32_wrapper(AV_PIX_FMT_X2RGB10LE, rgb30le, 16, 6, 0, 0, 0x3FF0,
0xFFC00, 0x3FF, 0, 0, 4, RGB2YUV_SHIFT + 6)
static void gbr24pToUV_half_c(uint8_t *_dstU, uint8_t *_dstV,
const uint8_t *gsrc, const uint8_t *bsrc, const
uint8_t *rsrc,
@@ -1260,6 +1262,9 @@ av_cold void ff_sws_init_input_funcs(SwsContext *c)
case AV_PIX_FMT_RGB444BE:
c->chrToYV12 = rgb12beToUV_half_c;
break;
+case AV_PIX_FMT_X2RGB10LE:
+c->chrToYV12 = rgb30leToUV_half_c;
+break;
}
} else {
switch (srcFormat) {
@@ -1341,6 +1346,9 @@ av_cold void ff_sws_init_input_funcs(SwsContext *c)
case AV_PIX_FMT_RGB444BE:
c->chrToYV12 = rgb12beToUV_c;
break;
+case AV_PIX_FMT_X2RGB10LE:
+c->chrToYV12 = rgb30leToUV_c;
+break;
}
}
@@ -1610,6 +1618,9 @@ av_cold void ff_sws_init_input_funcs(SwsContext *c)
case AV_PIX_FMT_Y210LE:
c->lumToYV12 = y210le_Y_c;
break;
+case AV_PIX_FMT_X2RGB10LE:
+c->lumToYV12 =rgb30leToY_c;
+break;
}
if (c->needAlpha) {
if (is16BPS(srcFormat) || isNBPS(srcFormat)) {
diff --git a/libswscale/output.c b/libswscale/output.c
index 68f43ff..f9528af 100644
--- a/libswscale/output.c
+++ b/libswscale/output.c
@@ -1602,6 +1602,13 @@ yuv2rgb_write(uint8_t *_dest, int i, int Y1, int Y2,
dest[i * 2 + 0] = r[Y1 + dr1] + g[Y1 + dg1] + b[Y1 + db1];
dest[i * 2 + 1] = r[Y2 + dr2] + g[Y2 + dg2] + b[Y2 + db2];
+} else if (target == AV_PIX_FMT_X2RGB10) {
+uint32_t *dest = (uint32_t *) _dest;
+const uint32_t *r = (const uint32_t *) _r;
+const uint32_t *g = (const uint32_t *) _g;
+const uint32_t *b = (const uint32_t *) _b;
+dest[i * 2 + 0] = r[Y1] + g[Y1] + b[Y1];
+dest[i * 2 + 1] = r[Y2] + g[Y2] + b[Y2];
} else /* 8/4 bits */ {
uint8_t *dest = (uint8_t *) _dest;
const uint8_t *r = (const uint8_t *) _r;
@@ -1839,6 +1846,7 @@ YUV2RGBWRAPPER(yuv2rgb,, 12,AV_PIX_FMT_RGB444,0)
YUV2RGBWRAPPER(yuv2rgb,, 8,AV_PIX_FMT_RGB8, 0)
YUV2RGBWRAPPER(yuv2rgb,, 4,AV_PIX_FMT_RGB4, 0)
YUV2RGBWRAPPER(yuv2rgb,, 4b, AV_PIX_FMT_RGB4_BYTE, 0)
+YUV2RGBWRAPPER(yuv2, rgb, x2rgb10, AV_PIX_FMT_X2RGB10, 0)
static av_always_inline void yuv2rgb_write_full(SwsContext *c,
uint8_t *dest, int i, int Y, int A, int U, int V,
@@ -2892,6 +2900,12 @@ av_cold void ff_sws_init_output_funcs(SwsContext *c,
*yuv2packed2 = yuv2rgb4b_2_c;
*yuv2packedX = yuv2rgb4b_X_c;
break;
+case AV_PIX_FMT_X2RGB10LE:
+case AV_PIX_FMT_X2RGB10BE:
+*yuv2packed1 = yuv2x2rgb10_1_c;
+*yuv2packed2 = yuv2x2rgb10_2_c;
+*yuv2packedX = yuv2x2rgb10_X_c;
+break;
}
}
switch (dstFormat) {
diff --git a/libswscale/utils.c b/libswscale/utils.c
index bb3495b..681d395 100644
--- a/libswscale/utils.c
+++ b/libswscale/utils.c
@@ -267,6 +267,7 @@ static const FormatEntry format_entries[] = {
[AV_PIX_FMT_NV24]= { 1, 1 },
[AV_PIX_FMT_NV42]= { 1, 1 },
[AV_PIX_FMT_Y210LE] = { 1, 0 },
+[AV_PIX_FMT_X2RGB10LE]= { 1, 1 },
};
int sws_isSupportedInput(enum AVPixelFormat pix_fmt)
diff --git a/libswscale/yuv2rgb.c b/libswscale/yuv2rgb.c
[FFmpeg-devel] [PATCH 1/3] lavu/pix_fmt: add new pixel format x2rgb10
The format is packed RGB with each channel 10 bits available and
include 2 bits unused.
Signed-off-by: Fei Wang
---
libavutil/pixdesc.c | 24
libavutil/pixfmt.h | 3 +++
libavutil/version.h | 2 +-
tests/ref/fate/filter-pixdesc-x2rgb10le | 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/sws-pixdesc-query | 11 +++
16 files changed, 51 insertions(+), 1 deletion(-)
create mode 100644 tests/ref/fate/filter-pixdesc-x2rgb10le
diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
index 9d61c52..23ec1ab 100644
--- a/libavutil/pixdesc.c
+++ b/libavutil/pixdesc.c
@@ -252,6 +252,30 @@ static const AVPixFmtDescriptor
av_pix_fmt_descriptors[AV_PIX_FMT_NB] = {
},
.flags = AV_PIX_FMT_FLAG_RGB,
},
+[AV_PIX_FMT_X2RGB10LE] = {
+.name = "x2rgb10le",
+.nb_components= 3,
+.log2_chroma_w= 0,
+.log2_chroma_h= 0,
+.comp = {
+{ 0, 4, 2, 4, 10, 3, 9, 2 }, /* R */
+{ 0, 4, 1, 2, 10, 3, 9, 3 }, /* G */
+{ 0, 4, 0, 0, 10, 3, 9, 4 }, /* B */
+},
+.flags = AV_PIX_FMT_FLAG_RGB,
+},
+[AV_PIX_FMT_X2RGB10BE] = {
+.name = "x2rgb10be",
+.nb_components= 3,
+.log2_chroma_w= 0,
+.log2_chroma_h= 0,
+.comp = {
+{ 0, 4, 0, 4, 10, 3, 9, 2 }, /* R */
+{ 0, 4, 1, 2, 10, 3, 9, 3 }, /* G */
+{ 0, 4, 2, 0, 10, 3, 9, 4 }, /* B */
+},
+.flags = AV_PIX_FMT_FLAG_RGB | AV_PIX_FMT_FLAG_BE,
+},
[AV_PIX_FMT_YUV422P] = {
.name = "yuv422p",
.nb_components = 3,
diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
index 1c625cf..71058d7 100644
--- a/libavutil/pixfmt.h
+++ b/libavutil/pixfmt.h
@@ -358,6 +358,8 @@ enum AVPixelFormat {
AV_PIX_FMT_Y210BE,///< packed YUV 4:2:2 like YUYV422, 20bpp, data in
the high bits, big-endian
AV_PIX_FMT_Y210LE,///< packed YUV 4:2:2 like YUYV422, 20bpp, data in
the high bits, little-endian
+AV_PIX_FMT_X2RGB10LE,///< packed RGB 10:10:10, 30bpp, (msb)2X 10R 10G
10B(lsb), little-endian, X=unused/undefined
+AV_PIX_FMT_X2RGB10BE,///< packed RGB 10:10:10, 30bpp, (msb)2X 10R 10G
10B(lsb), big-endian, X=unused/undefined
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
};
@@ -447,6 +449,7 @@ enum AVPixelFormat {
#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_X2RGB10 AV_PIX_FMT_NE(X2RGB10BE, X2RGB10LE)
/**
* Chromaticity coordinates of the source primaries.
diff --git a/libavutil/version.h b/libavutil/version.h
index 70836a5..e4fa0a9 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -79,7 +79,7 @@
*/
#define LIBAVUTIL_VERSION_MAJOR 56
-#define LIBAVUTIL_VERSION_MINOR 42
+#define LIBAVUTIL_VERSION_MINOR 43
#define LIBAVUTIL_VERSION_MICRO 102
#define LIBAVUTIL_VERSION_INT AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
diff --git a/tests/ref/fate/filter-pixdesc-x2rgb10le
b/tests/ref/fate/filter-pixdesc-x2rgb10le
new file mode 100644
index 000..94c8640
--- /dev/null
+++ b/tests/ref/fate/filter-pixdesc-x2rgb10le
@@ -0,0 +1 @@
+pixdesc-x2rgb10le98d697ed4668daf535163d5e08c903bb
diff --git a/tests/ref/fate/filter-pixfmts-copy
b/tests/ref/fate/filter-pixfmts-copy
index d19314b..c95ec33 100644
--- a/tests/ref/fate/filter-pixfmts-copy
+++ b/tests/ref/fate/filter-pixfmts-copy
@@ -76,6 +76,7 @@ rgbab6e1b441c365e03b5ffdf9b7b68d9a0c
rgba64beae2ae04b5efedca3505f47c4dd6ea6ea
rgba64leb91e1d77f799eb92241a2d2d28437b15
uyvy422 3bcf3c80047592f2211fae3260b1b65d
+x2rgb10le b0a0c8056521beeaa3fea4985ca87176
xyz12be a1ef56bf746d71f59669c28e48fc8450
xyz12le 831ff03c1ba4ef19374686f16a064d8c
ya16be 37c07787e544f900c87b853253bfc8dd
diff --git a/tests/ref/fate/filter-pixfmts-crop
b/tests/ref/fate/filter-pixfmts-crop
index ab89d06..35bff2d 100644
--- a/tests/ref/fate/filter-pixfmts-crop
+++ b/tests/ref/fate/filter-pixfmts-crop
@@ -73,6 +73,7 @@ rgb89b364a8f112ad9459fec47a51cc03b30
rgba9488ac85abceaf99a9309eac5a87697e
Re: [FFmpeg-devel] [PATCH v4 2/7] lavutil: add DOVI related header
Quoting myp...@gmail.com (2020-04-21 04:47:42) > On Mon, Apr 20, 2020 at 9:08 PM Anton Khirnov wrote: > > > > Quoting Jean-Baptiste Kempf (2020-04-19 10:25:07) > > > I'd like to ask opinions whether a installed header for just one > > > structure is a good idea. > > > > I see no problem with it. More smaller headers is better that a few big > > headers. > > > > Another issue is that this struct has no constructor and thus cannot be > > extended without breaking ABI. > > > This structure is part of API, so I can't find a simple way to extend > without break the ABI, I believe there are similar problems for > AVSphericalMapping No, AVSphericalMapping does not have that problem since it has a constructor. -- Anton Khirnov ___ 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".
