Re: [FFmpeg-devel] [PATCH] Added Closed caption support for cuviddec for preserving a53 data n GPU decoding

2021-04-13 Thread Timo Rothenpieler

On 13.04.2021 01:41, James Almer wrote:

You have ff_parse_a53_cc() in atsc_a53.c for this


I'm pretty sure I NAKed this or a very similar patch in the past, asking 
to not re-implement an entire parser in cuviddec.


Same applies here: I'm not going to accept a patch that implements a 
complex, or really any, parsers into cuviddec.


If this can be done by simply calling an internal ff_ functions, that'd 
much more likely be acceptable.




smime.p7s
Description: S/MIME Cryptographic 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] Added Closed caption support for cuviddec for preserving a53 data n GPU decoding

2021-04-13 Thread Dhanish Vijayan
I used the patch provided here -
https://github.com/tea/FFmpeg/commit/ba3df26047ca2e2c2a79c4cab436ace032c73d57
With this patch I was able to get the Closed caption issue fixed with the
cuvid.

After seeing your message, I am trying to figure out how I can use
the ff_parse_a53_cc for parsing.
The implementation seems to be different, and I am beginner in this. Will
let you know if I can implement the parsing using this function.



On Tue, Apr 13, 2021 at 1:02 PM Timo Rothenpieler 
wrote:

> On 13.04.2021 01:41, James Almer wrote:
> > You have ff_parse_a53_cc() in atsc_a53.c for this
>
> I'm pretty sure I NAKed this or a very similar patch in the past, asking
> to not re-implement an entire parser in cuviddec.
>
> Same applies here: I'm not going to accept a patch that implements a
> complex, or really any, parsers into cuviddec.
>
> If this can be done by simply calling an internal ff_ functions, that'd
> much more likely be acceptable.
>
> ___
> 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".



-- 

Thank you,
warm regards,

[image: Logo]

Dhanish Vijayan

Chief Technical Officer

Elementz Engineers Guild Pvt Ltd

Email: dhan...@elementzonline.com

Website: www.elementzonline.in, www.elementzonline.com

Mob: +91-8129025513

Off: +91-471-2300804


Elementz Engineers Guild Pvt Ltd
TC 25/1655/5, Rema Plaza,
SS Kovil Road, Thampanoor,
Thiruvananthapuram
Kerala - 695001

Phone:  0471-2329699

Elementz Engineers Guild Pvt Ltd
TC 12/78(11), Capital Heights,
PMG Plamoodu road,
Pattom P. O.,Thiruvananthapuram,
Kerala - 695004

Phone: 0471-2300804

Elementz Engineers Guild Pvt Ltd
SBC 3, Thejaswini,
Technopark Campus,
Thiruvananthapuram - 695581
Kerala

Phone: 0471-271

Elementz Engineers Guild Pvt Ltd
No.131, 4th Cross,
2nd main, RHB Colony,
Opposite Phoenix Marketcity,
Mahadevapura,
Bangalore - 560048



Connect with us :
  [image: FB]    [image: Twitter]
   [image: Twitter]



Disclaimer: : This message and any files transmitted with it are
confidential and intended solely for the use of the individual or entity to
whom they are addressed. No Liability is attached to the originator or
Elementz Engineers Guild Pvt. Ltd. Views or opinions presented in this
email is of the author and may not necessarily reflect the opinions of
Elementz Engineers Guild Pvt. Ltd.

This message contains confidential information. If you have received this
e-mail by mistake, please notify the sender immediately by e-mail and
delete this e-mail and its contents from your system.
___
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] lavc/aarch64: change h264pred_init structure

2021-04-13 Thread Mikhail Nitenko
Change structure to allow addition of other bit depths.
---
 libavcodec/aarch64/h264pred_init.c | 57 ++
 1 file changed, 27 insertions(+), 30 deletions(-)

diff --git a/libavcodec/aarch64/h264pred_init.c 
b/libavcodec/aarch64/h264pred_init.c
index b144376f90..fc8989ae0d 100644
--- a/libavcodec/aarch64/h264pred_init.c
+++ b/libavcodec/aarch64/h264pred_init.c
@@ -49,38 +49,35 @@ static av_cold void h264_pred_init_neon(H264PredContext *h, 
int codec_id,
 const int bit_depth,
 const int chroma_format_idc)
 {
-const int high_depth = bit_depth > 8;
-
-if (high_depth)
-return;
-
-if (chroma_format_idc <= 1) {
-h->pred8x8[VERT_PRED8x8 ] = ff_pred8x8_vert_neon;
-h->pred8x8[HOR_PRED8x8  ] = ff_pred8x8_hor_neon;
-if (codec_id != AV_CODEC_ID_VP7 && codec_id != AV_CODEC_ID_VP8)
-h->pred8x8[PLANE_PRED8x8] = ff_pred8x8_plane_neon;
-h->pred8x8[DC_128_PRED8x8   ] = ff_pred8x8_128_dc_neon;
-if (codec_id != AV_CODEC_ID_RV40 && codec_id != AV_CODEC_ID_VP7 &&
-codec_id != AV_CODEC_ID_VP8) {
-h->pred8x8[DC_PRED8x8 ] = ff_pred8x8_dc_neon;
-h->pred8x8[LEFT_DC_PRED8x8] = ff_pred8x8_left_dc_neon;
-h->pred8x8[TOP_DC_PRED8x8 ] = ff_pred8x8_top_dc_neon;
-h->pred8x8[ALZHEIMER_DC_L0T_PRED8x8] = ff_pred8x8_l0t_dc_neon;
-h->pred8x8[ALZHEIMER_DC_0LT_PRED8x8] = ff_pred8x8_0lt_dc_neon;
-h->pred8x8[ALZHEIMER_DC_L00_PRED8x8] = ff_pred8x8_l00_dc_neon;
-h->pred8x8[ALZHEIMER_DC_0L0_PRED8x8] = ff_pred8x8_0l0_dc_neon;
+if (bit_depth == 8) {
+if (chroma_format_idc <= 1) {
+h->pred8x8[VERT_PRED8x8 ] = ff_pred8x8_vert_neon;
+h->pred8x8[HOR_PRED8x8  ] = ff_pred8x8_hor_neon;
+if (codec_id != AV_CODEC_ID_VP7 && codec_id != AV_CODEC_ID_VP8)
+h->pred8x8[PLANE_PRED8x8] = ff_pred8x8_plane_neon;
+h->pred8x8[DC_128_PRED8x8   ] = ff_pred8x8_128_dc_neon;
+if (codec_id != AV_CODEC_ID_RV40 && codec_id != AV_CODEC_ID_VP7 &&
+codec_id != AV_CODEC_ID_VP8) {
+h->pred8x8[DC_PRED8x8 ] = ff_pred8x8_dc_neon;
+h->pred8x8[LEFT_DC_PRED8x8] = ff_pred8x8_left_dc_neon;
+h->pred8x8[TOP_DC_PRED8x8 ] = ff_pred8x8_top_dc_neon;
+h->pred8x8[ALZHEIMER_DC_L0T_PRED8x8] = ff_pred8x8_l0t_dc_neon;
+h->pred8x8[ALZHEIMER_DC_0LT_PRED8x8] = ff_pred8x8_0lt_dc_neon;
+h->pred8x8[ALZHEIMER_DC_L00_PRED8x8] = ff_pred8x8_l00_dc_neon;
+h->pred8x8[ALZHEIMER_DC_0L0_PRED8x8] = ff_pred8x8_0l0_dc_neon;
+}
 }
-}
 
-h->pred16x16[DC_PRED8x8 ] = ff_pred16x16_dc_neon;
-h->pred16x16[VERT_PRED8x8   ] = ff_pred16x16_vert_neon;
-h->pred16x16[HOR_PRED8x8] = ff_pred16x16_hor_neon;
-h->pred16x16[LEFT_DC_PRED8x8] = ff_pred16x16_left_dc_neon;
-h->pred16x16[TOP_DC_PRED8x8 ] = ff_pred16x16_top_dc_neon;
-h->pred16x16[DC_128_PRED8x8 ] = ff_pred16x16_128_dc_neon;
-if (codec_id != AV_CODEC_ID_SVQ3 && codec_id != AV_CODEC_ID_RV40 &&
-codec_id != AV_CODEC_ID_VP7 && codec_id != AV_CODEC_ID_VP8)
-h->pred16x16[PLANE_PRED8x8  ] = ff_pred16x16_plane_neon;
+h->pred16x16[DC_PRED8x8 ] = ff_pred16x16_dc_neon;
+h->pred16x16[VERT_PRED8x8   ] = ff_pred16x16_vert_neon;
+h->pred16x16[HOR_PRED8x8] = ff_pred16x16_hor_neon;
+h->pred16x16[LEFT_DC_PRED8x8] = ff_pred16x16_left_dc_neon;
+h->pred16x16[TOP_DC_PRED8x8 ] = ff_pred16x16_top_dc_neon;
+h->pred16x16[DC_128_PRED8x8 ] = ff_pred16x16_128_dc_neon;
+if (codec_id != AV_CODEC_ID_SVQ3 && codec_id != AV_CODEC_ID_RV40 &&
+codec_id != AV_CODEC_ID_VP7 && codec_id != AV_CODEC_ID_VP8)
+h->pred16x16[PLANE_PRED8x8  ] = ff_pred16x16_plane_neon;
+}
 }
 
 av_cold void ff_h264_pred_init_aarch64(H264PredContext *h, int codec_id,
-- 
2.31.1

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

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

[FFmpeg-devel] [PATCH v3 2/2] lavc/aarch64: add pred16x16 10-bit functions

2021-04-13 Thread Mikhail Nitenko
Benchmarks:
pred16x16_dc_10_c: 124.0
pred16x16_dc_10_neon: 97.2
pred16x16_horizontal_10_c: 71.7
pred16x16_horizontal_10_neon: 66.2
pred16x16_top_dc_10_c: 90.7
pred16x16_top_dc_10_neon: 71.5
pred16x16_vertical_10_c: 64.7
pred16x16_vertical_10_neon: 61.7

Some functions work slower than C and are left commented out.
---
 libavcodec/aarch64/h264pred_init.c |  12 +++
 libavcodec/aarch64/h264pred_neon.S | 117 +
 2 files changed, 129 insertions(+)

diff --git a/libavcodec/aarch64/h264pred_init.c 
b/libavcodec/aarch64/h264pred_init.c
index fc8989ae0d..9a1f13910d 100644
--- a/libavcodec/aarch64/h264pred_init.c
+++ b/libavcodec/aarch64/h264pred_init.c
@@ -45,6 +45,11 @@ void ff_pred8x8_0lt_dc_neon(uint8_t *src, ptrdiff_t stride);
 void ff_pred8x8_l00_dc_neon(uint8_t *src, ptrdiff_t stride);
 void ff_pred8x8_0l0_dc_neon(uint8_t *src, ptrdiff_t stride);
 
+void ff_pred16x16_top_dc_neon_10(uint8_t *src, ptrdiff_t stride);
+void ff_pred16x16_dc_neon_10(uint8_t *src, ptrdiff_t stride);
+void ff_pred16x16_hor_neon_10(uint8_t *src, ptrdiff_t stride);
+void ff_pred16x16_vert_neon_10(uint8_t *src, ptrdiff_t stride);
+
 static av_cold void h264_pred_init_neon(H264PredContext *h, int codec_id,
 const int bit_depth,
 const int chroma_format_idc)
@@ -78,6 +83,12 @@ static av_cold void h264_pred_init_neon(H264PredContext *h, 
int codec_id,
 codec_id != AV_CODEC_ID_VP7 && codec_id != AV_CODEC_ID_VP8)
 h->pred16x16[PLANE_PRED8x8  ] = ff_pred16x16_plane_neon;
 }
+if (bit_depth == 10) {
+h->pred16x16[DC_PRED8x8 ] = ff_pred16x16_dc_neon_10;
+h->pred16x16[VERT_PRED8x8   ] = ff_pred16x16_vert_neon_10;
+h->pred16x16[HOR_PRED8x8] = ff_pred16x16_hor_neon_10;
+h->pred16x16[TOP_DC_PRED8x8 ] = ff_pred16x16_top_dc_neon_10;
+}
 }
 
 av_cold void ff_h264_pred_init_aarch64(H264PredContext *h, int codec_id,
@@ -88,3 +99,4 @@ av_cold void ff_h264_pred_init_aarch64(H264PredContext *h, 
int codec_id,
 if (have_neon(cpu_flags))
 h264_pred_init_neon(h, codec_id, bit_depth, chroma_format_idc);
 }
+
diff --git a/libavcodec/aarch64/h264pred_neon.S 
b/libavcodec/aarch64/h264pred_neon.S
index 213b40b3e7..5ce50323f8 100644
--- a/libavcodec/aarch64/h264pred_neon.S
+++ b/libavcodec/aarch64/h264pred_neon.S
@@ -359,3 +359,120 @@ function ff_pred8x8_0l0_dc_neon, export=1
 dup v1.8b,  v1.b[0]
 b   .L_pred8x8_dc_end
 endfunc
+
+.macro ldcol.16  rd,  rs,  rt,  n=4,  hi=0
+.if \n >= 4 || \hi == 0
+ld1 {\rd\().h}[0],  [\rs], \rt
+ld1 {\rd\().h}[1],  [\rs], \rt
+.endif
+.if \n >= 4 || \hi == 1
+ld1 {\rd\().h}[2],  [\rs], \rt
+ld1 {\rd\().h}[3],  [\rs], \rt
+.endif
+.if \n == 8
+ld1 {\rd\().h}[4],  [\rs], \rt
+ld1 {\rd\().h}[5],  [\rs], \rt
+ld1 {\rd\().h}[6],  [\rs], \rt
+ld1 {\rd\().h}[7],  [\rs], \rt
+.endif
+.endm
+
+// slower than C
+/*
+function ff_pred16x16_128_dc_neon_10, export=1
+moviv0.8h, #2, lsl #8 // 512, 1 << (bit_depth - 1)
+
+b   .L_pred16x16_dc_10_end
+endfunc
+*/
+
+function ff_pred16x16_top_dc_neon_10, export=1
+sub x2,  x0,  x1
+
+ld1 {v0.8h, v1.8h},  [x2]
+
+addvh0,  v0.8h
+addvh1,  v1.8h
+
+add v0.4h, v0.4h, v1.4h
+
+rshrn   v0.4h,  v0.4s,  #4
+dup v0.8h, v0.h[0]
+b   .L_pred16x16_dc_10_end
+endfunc
+
+// slower than C
+/*
+function ff_pred16x16_left_dc_neon_10, export=1
+sub x2,  x0,  #2 // access to the "left" column
+ldcol.16v0,  x2,  x1,  8
+ldcol.16v1,  x2,  x1,  8 // load "left" column
+
+addvh0,  v0.8h
+addvh1,  v1.8h
+
+add v0.4h,  v0.4h,  v1.4h
+
+rshrn   v0.4h,  v0.4s,  #4
+dup v0.8h, v0.h[0]
+b   .L_pred16x16_dc_10_end
+endfunc
+*/
+
+function ff_pred16x16_dc_neon_10, export=1
+sub x2,  x0,  x1 // access to the "top" row
+sub x3,  x0,  #2 // access to the "left" column
+
+ld1 {v0.8h, v1.8h}, [x2]
+ldcol.16v2,  x3,  x1,  8
+ldcol.16v3,  x3,  x1,  8 // load pixels in "top" row and 
"left" col
+
+addvh0,  v0.8h
+addvh1,  v1.8h
+addvh2,  v2.8h // sum all pixels in the "top" row and 
"left" col
+addvh3,  v3.8h // (sum stays in h0-h3 registers)
+
+add v0.4h,  v0.4h,  v1.4h
+add v0.4h,  v0.4h,  v2.4h
+add v0.4h,  v0.4h,  v3.4h // sum registers h0-h3
+
+rshrn

Re: [FFmpeg-devel] [PATCH] checkasm: add (private) kperf timing for macOS

2021-04-13 Thread Martin Storsjö

On Tue, 13 Apr 2021, Lynne wrote:

Could you move this to libavutil and hook this up to libavutil/timer.h 
as well?


I'm a bit hesitant about that, as the API (just like the existing linux 
perf integration which is predecent for heavyweight timer APIs) requires a 
bit more setup than what libavutil/timer.h normally does.


// Martin

___
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] checkasm: add (private) kperf timing for macOS

2021-04-13 Thread Martin Storsjö

On Tue, 13 Apr 2021, Josh Dekker wrote:


Signed-off-by: Josh Dekker 
---
configure|   2 +
tests/checkasm/Makefile  |   1 +
tests/checkasm/checkasm.c|  19 -
tests/checkasm/checkasm.h|  10 ++-
tests/checkasm/macos_kperf.c | 143 +++
tests/checkasm/macos_kperf.h |  23 ++
6 files changed, 195 insertions(+), 3 deletions(-)
create mode 100644 tests/checkasm/macos_kperf.c
create mode 100644 tests/checkasm/macos_kperf.h

diff --git a/tests/checkasm/checkasm.h b/tests/checkasm/checkasm.h
index ef6645e3a2..4127081d74 100644
--- a/tests/checkasm/checkasm.h
+++ b/tests/checkasm/checkasm.h
@@ -31,6 +31,8 @@
#include 
#include 
#include 
+#elif CONFIG_MACOS_KPERF
+#include "macos_kperf.h"
#endif

#include "libavutil/avstring.h"
@@ -224,7 +226,7 @@ typedef struct CheckasmPerf {
int iterations;
} CheckasmPerf;

-#if defined(AV_READ_TIME) || CONFIG_LINUX_PERF
+#if defined(AV_READ_TIME) || CONFIG_LINUX_PERF || CONFIG_MACOS_KPERF

#if CONFIG_LINUX_PERF
#define PERF_START(t) do {  \
@@ -235,6 +237,12 @@ typedef struct CheckasmPerf {
ioctl(sysfd, PERF_EVENT_IOC_DISABLE, 0);\
read(sysfd, &t, sizeof(t)); \
} while (0)
+#elif CONFIG_MACOS_KPERF
+#define PERF_START(t) do {  \
+t = 0;  \
+ff_kperf_cycles(&t);\
+} while (0)
+#define PERF_STOP(t) ff_kperf_cycles(&t)
#else


I find this implicit subtraction in ff_kperf_cycles() highly surprising 
and hard to reason about.


E.g. if I do t=0; followed by ff_kperf_cycles(&t) three times - what value 
do I have in 't'? With the current code, the answer is "the difference 
between the absolute current timer minus the number of cycles it took 
between the first and second call", and that doesn't sound like something 
that is useful to anybody, ever.


Just make the function return the value as-is and do the subtraction here.



#define PERF_START(t) t = AV_READ_TIME()
#define PERF_STOP(t)  t = AV_READ_TIME() - t
diff --git a/tests/checkasm/macos_kperf.c b/tests/checkasm/macos_kperf.c
new file mode 100644
index 00..e6ae316608
--- /dev/null
+++ b/tests/checkasm/macos_kperf.c
@@ -0,0 +1,143 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 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 General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with FFmpeg; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+#include "macos_kperf.h"
+#include 
+#include 
+#include 
+
+#define KPERF_LIST \
+F(int, kpc_get_counting, void) \
+F(int, kpc_force_all_ctrs_set, int)\
+F(int, kpc_set_counting, uint32_t) \
+F(int, kpc_set_thread_counting, uint32_t)  \
+F(int, kpc_set_config, uint32_t, void *)   \
+F(int, kpc_get_config, uint32_t, void *)   \
+F(int, kpc_set_period, uint32_t, void *)   \
+F(int, kpc_get_period, uint32_t, void *)   \
+F(uint32_t, kpc_get_counter_count, uint32_t)   \
+F(uint32_t, kpc_get_config_count, uint32_t)\
+F(int, kperf_sample_get, int *)\
+F(int, kpc_get_thread_counters, int, unsigned int, void *)
+
+#define F(ret, name, ...)  \
+typedef ret name##proc(__VA_ARGS__);   \
+static name##proc *name = NULL;
+KPERF_LIST
+#undef F
+
+#define CFGWORD_EL0A32EN_MASK (0x1)
+#define CFGWORD_EL0A64EN_MASK (0x2)
+#define CFGWORD_EL1EN_MASK(0x4)
+#define CFGWORD_EL3EN_MASK(0x8)
+#define CFGWORD_ALLMODES_MASK (0xf)
+
+#define CPMU_NONE 0
+#define CPMU_CORE_CYCLE 0x02
+#define CPMU_INST_A64 0x8c
+#define CPMU_INST_BRANCH 0x8d
+#define CPMU_SYNC_DC_LOAD_MISS 0xbf
+#define CPMU_SYNC_DC_STORE_MISS 0xc0
+#define CPMU_SYNC_DTLB_MISS 0xc1
+#define CPMU_SYNC_ST_HIT_YNGR_LD 0xc4
+#define CPMU_SYNC_BR_ANY_MISP 0xcb
+#define CPMU_FED_IC_MISS_DEM 0xd3
+#define CPMU_FED_ITLB_MISS 0xd4
+
+#define KPC_CLASS_FIXED_MASK(1 << 0)
+#define KPC_CLASS_CONFIGURABLE_MASK (1 << 1)
+#define KPC_CLASS_POWER_MASK(1 << 2)
+#define KPC_CLASS_RAWPMU_MASK   (1 << 3)
+
+#define COUNTERS_COUNT 10
+#define CONFIG_COUNT 8


Is th

[FFmpeg-devel] [PATCH] Closed caption support for cuviddec with ff_parse_a53_cc preserving a53 data

2021-04-13 Thread Dhanish Vijayan
---
 libavcodec/cuviddec.c | 183 ++
 1 file changed, 183 insertions(+)

diff --git a/libavcodec/cuviddec.c b/libavcodec/cuviddec.c
index ec57afdefe..9967cb4c94 100644
--- a/libavcodec/cuviddec.c
+++ b/libavcodec/cuviddec.c
@@ -31,6 +31,8 @@
 #include "libavutil/opt.h"
 #include "libavutil/pixdesc.h"
 
+#include "get_bits.h"
+#include "atsc_a53.h"
 #include "avcodec.h"
 #include "decode.h"
 #include "hwconfig.h"
@@ -46,6 +48,9 @@
 #define CUVID_HAS_AV1_SUPPORT
 #endif
 
+#define MAX_FRAME_COUNT 25
+#define A53_QUEUE_SIZE (MAX_FRAME_COUNT + 8)
+
 typedef struct CuvidContext
 {
 AVClass *avclass;
@@ -89,6 +94,11 @@ typedef struct CuvidContext
 cudaVideoCodec codec_type;
 cudaVideoChromaFormat chroma_format;
 
+AVBufferRef* a53_caption;
+int a53_caption_size;
+uint8_t* a53_caption_queue[A53_QUEUE_SIZE];
+int a53_caption_size_queue[A53_QUEUE_SIZE];
+
 CUVIDDECODECAPS caps8, caps10, caps12;
 
 CUVIDPARSERPARAMS cuparseinfo;
@@ -103,6 +113,8 @@ typedef struct CuvidParsedFrame
 CUVIDPARSERDISPINFO dispinfo;
 int second_field;
 int is_deinterlacing;
+uint8_t* a53_caption;
+int a53_caption_size;
 } CuvidParsedFrame;
 
 #define CHECK_CU(x) FF_CUDA_CHECK_DL(avctx, ctx->cudl, x)
@@ -338,6 +350,24 @@ static int CUDAAPI cuvid_handle_picture_decode(void 
*opaque, CUVIDPICPARAMS* pic
 
 ctx->key_frame[picparams->CurrPicIdx] = picparams->intra_pic_flag;
 
+if (ctx->a53_caption)
+{
+
+if (picparams->CurrPicIdx >= A53_QUEUE_SIZE)
+{
+av_log(avctx, AV_LOG_WARNING, "CurrPicIdx too big: %d\n", 
picparams->CurrPicIdx);
+av_freep(&ctx->a53_caption);
+}
+else
+{
+int pos = picparams->CurrPicIdx;
+av_freep(&ctx->a53_caption_queue[pos]);
+ctx->a53_caption_queue[pos] = ctx->a53_caption;
+ctx->a53_caption_size_queue[pos] = ctx->a53_caption_size;
+ctx->a53_caption = NULL;
+}
+}
+
 ctx->internal_error = 
CHECK_CU(ctx->cvdl->cuvidDecodePicture(ctx->cudecoder, picparams));
 if (ctx->internal_error < 0)
 return 0;
@@ -350,6 +380,20 @@ static int CUDAAPI cuvid_handle_picture_display(void 
*opaque, CUVIDPARSERDISPINF
 AVCodecContext *avctx = opaque;
 CuvidContext *ctx = avctx->priv_data;
 CuvidParsedFrame parsed_frame = { { 0 } };
+uint8_t* a53_caption = NULL;
+int a53_caption_size = 0;
+
+if (dispinfo->picture_index >= A53_QUEUE_SIZE)
+{
+av_log(avctx, AV_LOG_WARNING, "picture_index too big: %d\n", 
dispinfo->picture_index);
+}
+else
+{
+int pos = dispinfo->picture_index;
+a53_caption = ctx->a53_caption_queue[pos];
+a53_caption_size = ctx->a53_caption_size_queue[pos];
+ctx->a53_caption_queue[pos] = NULL;
+}
 
 parsed_frame.dispinfo = *dispinfo;
 ctx->internal_error = 0;
@@ -358,11 +402,17 @@ static int CUDAAPI cuvid_handle_picture_display(void 
*opaque, CUVIDPARSERDISPINF
 parsed_frame.dispinfo.progressive_frame = ctx->progressive_sequence;
 
 if (ctx->deint_mode_current == cudaVideoDeinterlaceMode_Weave) {
+parsed_frame.a53_caption = a53_caption;
+parsed_frame.a53_caption_size = a53_caption_size;
 av_fifo_generic_write(ctx->frame_queue, &parsed_frame, 
sizeof(CuvidParsedFrame), NULL);
 } else {
 parsed_frame.is_deinterlacing = 1;
+parsed_frame.a53_caption = a53_caption;
+parsed_frame.a53_caption_size = a53_caption_size;
 av_fifo_generic_write(ctx->frame_queue, &parsed_frame, 
sizeof(CuvidParsedFrame), NULL);
 if (!ctx->drop_second_field) {
+parsed_frame.a53_caption = NULL;
+parsed_frame.a53_caption_size = 0;
 parsed_frame.second_field = 1;
 av_fifo_generic_write(ctx->frame_queue, &parsed_frame, 
sizeof(CuvidParsedFrame), NULL);
 }
@@ -382,6 +432,121 @@ static int cuvid_is_buffer_full(AVCodecContext *avctx)
 return (av_fifo_size(ctx->frame_queue) / sizeof(CuvidParsedFrame)) + delay 
>= ctx->nb_surfaces;
 }
 
+static void cuvid_mpeg_parse_a53(AVCodecContext *avctx, CuvidContext *ctx, 
const uint8_t* p, int buf_size)
+{
+const uint8_t* buf_end = p + buf_size;
+for(;;)
+{
+uint32_t start_code = -1;
+p = avpriv_find_start_code(p, buf_end, &start_code);
+if (start_code > 0x1ff)
+break;
+if (start_code != 0x1b2)
+continue;
+buf_size = buf_end - p;
+
+GetBitContext gb_payload;
+init_get_bits(&gb_payload, p, buf_size);
+
+uint32_t user_identifier = get_bits_long(&gb_payload, 32);
+switch (user_identifier) {
+case MKBETAG('D', 'T', 'G', '1'):   // afd_data
+av_log(avctx, AV_LOG_VERBOSE,
+   "Not implemented ITU-T T35 SEI message (atsc 
user_identifier = 0x%04x)\n",
+   user_identifier);
+   

[FFmpeg-devel] [PATCH 5/5] tools/target_dec_fuzzer: Adjust threshold for jpeg2000

2021-04-13 Thread Michael Niedermayer
Fixes: Timeout (25->4sec)
Fixes: 
32780/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEG2000_fuzzer-6017852583837696

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

diff --git a/tools/target_dec_fuzzer.c b/tools/target_dec_fuzzer.c
index 80da7afcb8..ed514772b4 100644
--- a/tools/target_dec_fuzzer.c
+++ b/tools/target_dec_fuzzer.c
@@ -172,6 +172,7 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t 
size) {
 case AV_CODEC_ID_IFF_ILBM:maxpixels  /= 128;   break;
 case AV_CODEC_ID_INDEO4:  maxpixels  /= 128;   break;
 case AV_CODEC_ID_INTERPLAY_ACM: maxsamples /= 16384;  break;
+case AV_CODEC_ID_JPEG2000:maxpixels  /= 16;break;
 case AV_CODEC_ID_LAGARITH:maxpixels  /= 1024;  break;
 case AV_CODEC_ID_LSCR:maxpixels  /= 16;break;
 case AV_CODEC_ID_MOTIONPIXELS:maxpixels  /= 256;   break;
-- 
2.17.1

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

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

[FFmpeg-devel] [PATCH 3/5] avformat/aaxdec: Check avio_seek() in inner loop for failure

2021-04-13 Thread Michael Niedermayer
Fixes: Timeout
Fixes: 
32450/clusterfuzz-testcase-minimized-ffmpeg_dem_AAX_fuzzer-4875522262827008

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

diff --git a/libavformat/aaxdec.c b/libavformat/aaxdec.c
index c6d2d1c8d1..ff9768efac 100644
--- a/libavformat/aaxdec.c
+++ b/libavformat/aaxdec.c
@@ -249,7 +249,10 @@ static int aax_read_header(AVFormatContext *s)
 goto fail;
 }
 
-avio_seek(pb, data_offset, SEEK_SET);
+ret = avio_seek(pb, data_offset, SEEK_SET);
+if (ret < 0)
+goto fail;
+
 if (type == COLUMN_TYPE_VLDATA) {
 int64_t start, size;
 
-- 
2.17.1

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

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

[FFmpeg-devel] [PATCH 2/5] avcodec/exr: increase vlc depth

2021-04-13 Thread Michael Niedermayer
Fixes: shift exponent -4 is negative
Fixes: 
32265/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_EXR_fuzzer-465133454137753

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

diff --git a/libavcodec/exr.c b/libavcodec/exr.c
index 65e5203c31..49c4774145 100644
--- a/libavcodec/exr.c
+++ b/libavcodec/exr.c
@@ -418,7 +418,7 @@ static int huf_decode(VLC *vlc, GetByteContext *gb, int 
nbits, int run_sym,
 
 init_get_bits(&gbit, gb->buffer, nbits);
 while (get_bits_left(&gbit) > 0 && oe < no) {
-uint16_t x = get_vlc2(&gbit, vlc->table, 12, 2);
+uint16_t x = get_vlc2(&gbit, vlc->table, 12, 3);
 
 if (x == run_sym) {
 int run = get_bits(&gbit, 8);
-- 
2.17.1

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

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

[FFmpeg-devel] [PATCH 1/5] avcodec/dpx: Check bits_per_color earlier

2021-04-13 Thread Michael Niedermayer
Fixes: shift exponent 251 is too large for 32-bit type 'int'
Fixes: 
32147/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DPX_fuzzer-5519111675314176

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

diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c
index 5372e3d586..b02996f04c 100644
--- a/libavcodec/dpx.c
+++ b/libavcodec/dpx.c
@@ -242,6 +242,9 @@ static int decode_frame(AVCodecContext *avctx,
 return AVERROR_PATCHWELCOME;
 }
 
+if (bits_per_color > 32)
+return AVERROR_INVALIDDATA;
+
 buf += 820;
 avctx->sample_aspect_ratio.num = read32(&buf, endian);
 avctx->sample_aspect_ratio.den = read32(&buf, endian);
-- 
2.17.1

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

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

[FFmpeg-devel] [PATCH 4/5] avformat/utils: Use 64bit earlier in r_frame_rate check

2021-04-13 Thread Michael Niedermayer
Fixes: signed integer overflow: 1406796319 * 2 cannot be represented in type 
'int'
Fixes: 
32777/clusterfuzz-testcase-minimized-ffmpeg_IO_DEMUXER_fuzzer-5632576913014784

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

diff --git a/libavformat/utils.c b/libavformat/utils.c
index d9971d7fd3..3ed01b2110 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -4109,7 +4109,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
 
 if (!st->r_frame_rate.num) {
 if (avctx->time_base.den * (int64_t) st->time_base.num
-<= avctx->time_base.num * avctx->ticks_per_frame * 
(uint64_t) st->time_base.den) {
+<= avctx->time_base.num * (uint64_t)avctx->ticks_per_frame 
* st->time_base.den) {
 av_reduce(&st->r_frame_rate.num, &st->r_frame_rate.den,
   avctx->time_base.den, 
(int64_t)avctx->time_base.num * avctx->ticks_per_frame, INT_MAX);
 } else {
-- 
2.17.1

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

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

Re: [FFmpeg-devel] [PATCH 3/5] avformat/aaxdec: Check avio_seek() in inner loop for failure

2021-04-13 Thread James Almer

On 4/13/2021 12:45 PM, Michael Niedermayer wrote:

Fixes: Timeout
Fixes: 
32450/clusterfuzz-testcase-minimized-ffmpeg_dem_AAX_fuzzer-4875522262827008

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

diff --git a/libavformat/aaxdec.c b/libavformat/aaxdec.c
index c6d2d1c8d1..ff9768efac 100644
--- a/libavformat/aaxdec.c
+++ b/libavformat/aaxdec.c
@@ -249,7 +249,10 @@ static int aax_read_header(AVFormatContext *s)
  goto fail;
  }
  
-avio_seek(pb, data_offset, SEEK_SET);

+ret = avio_seek(pb, data_offset, SEEK_SET);


There's another unchecked seek, and for both you should use an int64_t 
variable to store the return value, otherwise values > INT_MAX could be 
misinterpreted as errors.



+if (ret < 0)
+goto fail;
+
  if (type == COLUMN_TYPE_VLDATA) {
  int64_t start, size;
  



___
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/9] avcodec/mjpegenc: Include all supported pix_fmts in mpegenc pix_fmts

2021-04-13 Thread Eoff, Ullysses A
This commit breaks mjpeg_vaapi and mjpeg_qsv encoders.

https://trac.ffmpeg.org/ticket/9186

...please fix.

Thanks,
U. Artie

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Andreas 
> Rheinhardt
> Sent: Monday, April 05, 2021 10:40 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Andreas Rheinhardt 
> Subject: [FFmpeg-devel] [PATCH 6/9] avcodec/mjpegenc: Include all supported 
> pix_fmts in mpegenc pix_fmts
> 
> Currently said list contains only the pixel formats that are always
> supported irrespective of the range and the value of
> strict_std_compliance. This makes the MJPEG encoder an outlier as all
> other codecs put all potentially supported pixel formats into said list
> and error out if the chosen pixel format is unsupported. This commit
> brings it therefore in line with the other encoders.
> 
> The behaviour of fftools/ffmpeg_filter.c has been preserved. A more
> informed decision would be possible if colour range were available
> at this point, but it isn't.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  fftools/ffmpeg_filter.c  | 20 +++-
>  libavcodec/encode.c  |  4 +---
>  libavcodec/ljpegenc.c| 14 +++---
>  libavcodec/mjpegenc.c| 11 ++-
>  libavcodec/mjpegenc_common.c | 16 
>  libavcodec/mjpegenc_common.h |  2 ++
>  libavcodec/mpegvideo_enc.c   | 28 +---
>  7 files changed, 40 insertions(+), 55 deletions(-)
> 
> diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
> index 4ab769c07b..5c44b75eff 100644
> --- a/fftools/ffmpeg_filter.c
> +++ b/fftools/ffmpeg_filter.c
> @@ -39,22 +39,16 @@
>  #include "libavutil/imgutils.h"
>  #include "libavutil/samplefmt.h"
> 
> -static const enum AVPixelFormat *get_compliance_unofficial_pix_fmts(enum 
> AVCodecID codec_id, const enum AVPixelFormat
> default_formats[])
> +// FIXME: YUV420P etc. are actually supported with full color range,
> +// yet the latter information isn't available here.
> +static const enum AVPixelFormat *get_compliance_normal_pix_fmts(enum 
> AVCodecID codec_id, const enum AVPixelFormat
> default_formats[])
>  {
>  static const enum AVPixelFormat mjpeg_formats[] =
>  { AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_YUVJ422P, AV_PIX_FMT_YUVJ444P,
> -  AV_PIX_FMT_YUV420P,  AV_PIX_FMT_YUV422P,  AV_PIX_FMT_YUV444P,
>AV_PIX_FMT_NONE };
> -static const enum AVPixelFormat ljpeg_formats[] =
> -{ AV_PIX_FMT_BGR24   , AV_PIX_FMT_BGRA, AV_PIX_FMT_BGR0,
> -  AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_YUVJ444P, AV_PIX_FMT_YUVJ422P,
> -  AV_PIX_FMT_YUV420P , AV_PIX_FMT_YUV444P , AV_PIX_FMT_YUV422P,
> -  AV_PIX_FMT_NONE};
> 
>  if (codec_id == AV_CODEC_ID_MJPEG) {
>  return mjpeg_formats;
> -} else if (codec_id == AV_CODEC_ID_LJPEG) {
> -return ljpeg_formats;
>  } else {
>  return default_formats;
>  }
> @@ -70,8 +64,8 @@ static enum AVPixelFormat choose_pixel_fmt(AVStream *st, 
> AVCodecContext *enc_ctx
>  int has_alpha = desc ? desc->nb_components % 2 == 0 : 0;
>  enum AVPixelFormat best= AV_PIX_FMT_NONE;
> 
> -if (enc_ctx->strict_std_compliance <= FF_COMPLIANCE_UNOFFICIAL) {
> -p = get_compliance_unofficial_pix_fmts(enc_ctx->codec_id, p);
> +if (enc_ctx->strict_std_compliance > FF_COMPLIANCE_UNOFFICIAL) {
> +p = get_compliance_normal_pix_fmts(enc_ctx->codec_id, p);
>  }
>  for (; *p != AV_PIX_FMT_NONE; p++) {
>  best = av_find_best_pix_fmt_of_2(best, *p, target, has_alpha, 
> NULL);
> @@ -118,8 +112,8 @@ static char *choose_pix_fmts(OutputFilter *ofilter)
>  exit_program(1);
> 
>  p = ost->enc->pix_fmts;
> -if (ost->enc_ctx->strict_std_compliance <= FF_COMPLIANCE_UNOFFICIAL) 
> {
> -p = get_compliance_unofficial_pix_fmts(ost->enc_ctx->codec_id, 
> p);
> +if (ost->enc_ctx->strict_std_compliance > FF_COMPLIANCE_UNOFFICIAL) {
> +p = get_compliance_normal_pix_fmts(ost->enc_ctx->codec_id, p);
>  }
> 
>  for (; *p != AV_PIX_FMT_NONE; p++) {
> diff --git a/libavcodec/encode.c b/libavcodec/encode.c
> index 89df5235da..9a4140f91a 100644
> --- a/libavcodec/encode.c
> +++ b/libavcodec/encode.c
> @@ -564,9 +564,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
>  for (i = 0; avctx->codec->pix_fmts[i] != AV_PIX_FMT_NONE; i++)
>  if (avctx->pix_fmt == avctx->codec->pix_fmts[i])
>  break;
> -if (avctx->codec->pix_fmts[i] == AV_PIX_FMT_NONE
> -&& !(avctx->codec_id == AV_CODEC_ID_MJPEG
> - && avctx->strict_std_compliance <= 
> FF_COMPLIANCE_UNOFFICIAL)) {
> +if (avctx->codec->pix_fmts[i] == AV_PIX_FMT_NONE) {
>  char buf[128];
>  snprintf(buf, sizeof(buf), "%d", avctx->pix_fmt);
>  av_log(avctx, AV_LOG_ERROR, "Specified pixel format %s is 
> invalid or not supported\n",
> diff --git a/libavcodec/ljpegenc.c

Re: [FFmpeg-devel] [PATCH] libavdevice/gdigrab: fix capture window title contain non-ASCII chars

2021-04-13 Thread Jan Ekström
On Tue, Apr 13, 2021 at 12:35 AM Jan Ekström  wrote:
>
> On Sat, Mar 20, 2021 at 5:34 PM <1160386...@qq.com> wrote:
> >
> > From: He Yang <1160386...@qq.com>
> >
> > Signed-off-by: He Yang <1160386...@qq.com>
>
> Sorry for taking a while to respond, and thank you for the
> contribution. I have verified that this conversion and FindWindowW
> usage indeed fixes issues with non-ASCII window titles.
>
> Before:
> [gdigrab @ 01d1f24b2cc0] Can't find window 'ジャンキーナイトタウンオーケストラ _
> すりぃ feat.鏡音レン-sm36109943.mp4 - mpv', aborting.
> title=ジャンキーナイトタウンオーケストラ _ すりぃ feat.鏡音レン-sm36109943.mp4 - mpv: I/O error
>
> After:
> [gdigrab @ 017d298b2cc0] Found window ジャンキーナイトタウンオーケストラ _  すりぃ
> feat.鏡音レン-sm36109943.mp4 - mpv, capturing 1920x1080x32 at (0,0)
> Input #0, gdigrab, from 'title=ジャンキーナイトタウンオーケストラ _ すりぃ
> feat.鏡音レン-sm36109943.mp4 - mpv':
>
> Now, taking things step-by-step, first from the most clear things:
> 1. FFmpeg utilizes C99 features, but follows the rule that no
> declarations should happen after non-declaring code within a
> scope/context.
> src/libavdevice/gdigrab.c: In function 'gdigrab_read_header':
> src/libavdevice/gdigrab.c:249:9: warning: ISO C90 forbids mixed
> declarations and code [-Wdeclaration-after-statement]
>   249 | const wchar_t *name_w = NULL;
>   | ^
>
> -> Basically fixed by moving the new wchar_t as the first thing in the
> scope of that if branch.
>
> 2. Mismatch between function and the calling code in `const`ness.
> Const things are nice, but in this case the function takes in a
> non-const pointer.
>
> src/libavdevice/gdigrab.c:250:30: warning: passing argument 2 of
> 'utf8towchar' from incompatible pointer type
> [-Wincompatible-pointer-types]
>   250 | if(utf8towchar(name, &name_w)) {
>   |  ^~~
>   |  |
>   |  const wchar_t ** {aka const short
> unsigned int **}
> In file included from src/libavformat/os_support.h:148,
>  from src/libavformat/internal.h:28,
>  from src/libavdevice/gdigrab.c:32:
> src/libavutil/wchar_filename.h:27:68: note: expected 'wchar_t **' {aka
> 'short unsigned int **'} but argument is of type 'const wchar_t **'
> {aka 'const short unsigned int **'}
>27 | static inline int utf8towchar(const char *filename_utf8,
> wchar_t **filename_w)
>   |
> ~~^~
>
> -> Fixed by removing the const from the wchar_t pointer.
>
> Thus we move to actual review:
>
> 1. The libavutil header should be explicitly #included. That way users
> of headers should be more easily find'able.
> 2. When utf8towchar returns nonzero, ret should probably be set to
> AVERROR(errno). That way we are not re-guessing implementation
> specifics of the function. (noticed by Martin)
> 3. Some whitespace would be good between the variable
> declarations/setting, doing the conversion and finally the actual
> window finding.
>
> As I had to go through these points for the review process, I
> basically posted a version with these changes @
> https://github.com/jeeb/ffmpeg/commits/gdigrab_unicode_fix . I also
> took the liberty of rewording the commit message somewhat. If you
> think these changes are acceptable, then unless something new is
> noticed, I consider this LGTM.
>
> Best regards,
> Jan

Got an ack for these changes on both IRC and Github, thus applied as
707f9c9f475f612e196876708cdb5ead31f63525 .

Thank you once again for the contribution.

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

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

[FFmpeg-devel] [PATCH] fftools/ffmpeg_filter: Fix check for mjpeg encoder

2021-04-13 Thread Andreas Rheinhardt
The MJPEG encoder supports some pixel format/color range combinations
only when strictness is set to unofficial or less. Before commit
059fc2d9da5364627613fb3e6424079e14dbdfd3 said encoder's pix_fmts array
only included the pixel formats supported with default strictness.
When strictness was <= unofficial, fftools/ffmpeg_filter.c used
an extended list of pixel formats instead of the encoder's including
the pixel formats only supported when strictness <= unofficial.

Said commit turned the logic around: The encoder's pix_fmts array now
included all pixel formats and fftools/ffmpeg_filter.c instead used
a small list of all pixel formats supported when strictness is >
unofficial and the encoder's pixel formats instead. In particular,
the codec's pix_fmt is not used when strictness is normal.

This works for the mjpeg encoder; yet it did not work for other
(hardware-based) mjpeg encoders, because the check for whether one is
using the MJPEG encoder is wrong: It just checks the codec id.
So if one used strict unofficial with a hardware-accelerated MJPEG
encoder before commit 059fc2d9da53, the unofficial (non-hardware)
pixel formats of the MJPEG encoder would be used; since said commit
the codec's pixel formats are overridden at ordinary strictness
by the ordinary MJPEG pixel formats. This leads to format conversion
errors lateron which were reported in #9186.

The solution to this is to check AVCodec.name instead of its id.

Signed-off-by: Andreas Rheinhardt 
---
 fftools/ffmpeg_filter.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index 400f5a4188..e7c05eb3f9 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -41,13 +41,13 @@
 
 // FIXME: YUV420P etc. are actually supported with full color range,
 // yet the latter information isn't available here.
-static const enum AVPixelFormat *get_compliance_normal_pix_fmts(enum AVCodecID 
codec_id, const enum AVPixelFormat default_formats[])
+static const enum AVPixelFormat *get_compliance_normal_pix_fmts(const AVCodec 
*codec, const enum AVPixelFormat default_formats[])
 {
 static const enum AVPixelFormat mjpeg_formats[] =
 { AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_YUVJ422P, AV_PIX_FMT_YUVJ444P,
   AV_PIX_FMT_NONE };
 
-if (codec_id == AV_CODEC_ID_MJPEG) {
+if (!strcmp(codec->name, "mjpeg")) {
 return mjpeg_formats;
 } else {
 return default_formats;
@@ -65,7 +65,7 @@ static enum AVPixelFormat choose_pixel_fmt(AVStream *st, 
AVCodecContext *enc_ctx
 enum AVPixelFormat best= AV_PIX_FMT_NONE;
 
 if (enc_ctx->strict_std_compliance > FF_COMPLIANCE_UNOFFICIAL) {
-p = get_compliance_normal_pix_fmts(enc_ctx->codec_id, p);
+p = get_compliance_normal_pix_fmts(codec, p);
 }
 for (; *p != AV_PIX_FMT_NONE; p++) {
 best = av_find_best_pix_fmt_of_2(best, *p, target, has_alpha, 
NULL);
@@ -113,7 +113,7 @@ static char *choose_pix_fmts(OutputFilter *ofilter)
 
 p = ost->enc->pix_fmts;
 if (ost->enc_ctx->strict_std_compliance > FF_COMPLIANCE_UNOFFICIAL) {
-p = get_compliance_normal_pix_fmts(ost->enc_ctx->codec_id, p);
+p = get_compliance_normal_pix_fmts(ost->enc, p);
 }
 
 for (; *p != AV_PIX_FMT_NONE; p++) {
-- 
2.27.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 6/9] avcodec/mjpegenc: Include all supported pix_fmts in mpegenc pix_fmts

2021-04-13 Thread Andreas Rheinhardt
Eoff, Ullysses A:
> This commit breaks mjpeg_vaapi and mjpeg_qsv encoders.
> 
> https://trac.ffmpeg.org/ticket/9186
> 
> ...please fix.
> 

Please test this patch:
https://ffmpeg.org/pipermail/ffmpeg-devel/2021-April/279028.html
It should now work on all strictness levels (it was broken before said
commit when using -strict unofficial and is broken now on default
strictness).

- Andreas

> Thanks,
> U. Artie
> 
>> -Original Message-
>> From: ffmpeg-devel  On Behalf Of Andreas 
>> Rheinhardt
>> Sent: Monday, April 05, 2021 10:40 PM
>> To: ffmpeg-devel@ffmpeg.org
>> Cc: Andreas Rheinhardt 
>> Subject: [FFmpeg-devel] [PATCH 6/9] avcodec/mjpegenc: Include all supported 
>> pix_fmts in mpegenc pix_fmts
>>
>> Currently said list contains only the pixel formats that are always
>> supported irrespective of the range and the value of
>> strict_std_compliance. This makes the MJPEG encoder an outlier as all
>> other codecs put all potentially supported pixel formats into said list
>> and error out if the chosen pixel format is unsupported. This commit
>> brings it therefore in line with the other encoders.
>>
>> The behaviour of fftools/ffmpeg_filter.c has been preserved. A more
>> informed decision would be possible if colour range were available
>> at this point, but it isn't.
>>
>> Signed-off-by: Andreas Rheinhardt 
>> ---
>>  fftools/ffmpeg_filter.c  | 20 +++-
>>  libavcodec/encode.c  |  4 +---
>>  libavcodec/ljpegenc.c| 14 +++---
>>  libavcodec/mjpegenc.c| 11 ++-
>>  libavcodec/mjpegenc_common.c | 16 
>>  libavcodec/mjpegenc_common.h |  2 ++
>>  libavcodec/mpegvideo_enc.c   | 28 +---
>>  7 files changed, 40 insertions(+), 55 deletions(-)
>>
>> diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
>> index 4ab769c07b..5c44b75eff 100644
>> --- a/fftools/ffmpeg_filter.c
>> +++ b/fftools/ffmpeg_filter.c
>> @@ -39,22 +39,16 @@
>>  #include "libavutil/imgutils.h"
>>  #include "libavutil/samplefmt.h"
>>
>> -static const enum AVPixelFormat *get_compliance_unofficial_pix_fmts(enum 
>> AVCodecID codec_id, const enum AVPixelFormat
>> default_formats[])
>> +// FIXME: YUV420P etc. are actually supported with full color range,
>> +// yet the latter information isn't available here.
>> +static const enum AVPixelFormat *get_compliance_normal_pix_fmts(enum 
>> AVCodecID codec_id, const enum AVPixelFormat
>> default_formats[])
>>  {
>>  static const enum AVPixelFormat mjpeg_formats[] =
>>  { AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_YUVJ422P, AV_PIX_FMT_YUVJ444P,
>> -  AV_PIX_FMT_YUV420P,  AV_PIX_FMT_YUV422P,  AV_PIX_FMT_YUV444P,
>>AV_PIX_FMT_NONE };
>> -static const enum AVPixelFormat ljpeg_formats[] =
>> -{ AV_PIX_FMT_BGR24   , AV_PIX_FMT_BGRA, AV_PIX_FMT_BGR0,
>> -  AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_YUVJ444P, AV_PIX_FMT_YUVJ422P,
>> -  AV_PIX_FMT_YUV420P , AV_PIX_FMT_YUV444P , AV_PIX_FMT_YUV422P,
>> -  AV_PIX_FMT_NONE};
>>
>>  if (codec_id == AV_CODEC_ID_MJPEG) {
>>  return mjpeg_formats;
>> -} else if (codec_id == AV_CODEC_ID_LJPEG) {
>> -return ljpeg_formats;
>>  } else {
>>  return default_formats;
>>  }
>> @@ -70,8 +64,8 @@ static enum AVPixelFormat choose_pixel_fmt(AVStream *st, 
>> AVCodecContext *enc_ctx
>>  int has_alpha = desc ? desc->nb_components % 2 == 0 : 0;
>>  enum AVPixelFormat best= AV_PIX_FMT_NONE;
>>
>> -if (enc_ctx->strict_std_compliance <= FF_COMPLIANCE_UNOFFICIAL) {
>> -p = get_compliance_unofficial_pix_fmts(enc_ctx->codec_id, p);
>> +if (enc_ctx->strict_std_compliance > FF_COMPLIANCE_UNOFFICIAL) {
>> +p = get_compliance_normal_pix_fmts(enc_ctx->codec_id, p);
>>  }
>>  for (; *p != AV_PIX_FMT_NONE; p++) {
>>  best = av_find_best_pix_fmt_of_2(best, *p, target, has_alpha, 
>> NULL);
>> @@ -118,8 +112,8 @@ static char *choose_pix_fmts(OutputFilter *ofilter)
>>  exit_program(1);
>>
>>  p = ost->enc->pix_fmts;
>> -if (ost->enc_ctx->strict_std_compliance <= 
>> FF_COMPLIANCE_UNOFFICIAL) {
>> -p = get_compliance_unofficial_pix_fmts(ost->enc_ctx->codec_id, 
>> p);
>> +if (ost->enc_ctx->strict_std_compliance > FF_COMPLIANCE_UNOFFICIAL) 
>> {
>> +p = get_compliance_normal_pix_fmts(ost->enc_ctx->codec_id, p);
>>  }
>>
>>  for (; *p != AV_PIX_FMT_NONE; p++) {
>> diff --git a/libavcodec/encode.c b/libavcodec/encode.c
>> index 89df5235da..9a4140f91a 100644
>> --- a/libavcodec/encode.c
>> +++ b/libavcodec/encode.c
>> @@ -564,9 +564,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
>>  for (i = 0; avctx->codec->pix_fmts[i] != AV_PIX_FMT_NONE; i++)
>>  if (avctx->pix_fmt == avctx->codec->pix_fmts[i])
>>  break;
>> -if (avctx->codec->pix_fmts[i] == AV_PIX_FMT_NONE
>> -&& !(avctx->codec_id == AV_CODEC_ID_MJPEG
>>

Re: [FFmpeg-devel] [PATCH] mov: Prioritize aspect ratio values found in pasp atom

2021-04-13 Thread Vittorio Giovara
On Wed, Apr 7, 2021 at 10:00 PM Derek Buitenhuis 
wrote:

> On 07/04/2021 19:56, Vittorio Giovara wrote:
> > My OS doesn't even let me install Quicktime 7, if anybody could chime in
> > and help solve this point it would be much appreciated.
> > Alternatively, I'd say we shouldn't cargo cult broken files generated by
> 11
> > year old software, but if people disagree we can leave things as they
> are.
>
> For MP4, at least, there is a definitive answer from ISO/IEC
>
> The pixel aspect ratio and clean aperture of the video may be
> specified using the ‘pasp’ and ‘clap’
> sample entry boxes, respectively. These are both optional; if present,
> they over-ride the declarations (if any) in
> structures specific to the video codec, which structures should be
> examined if these boxes are absent. For
> maximum compatibility, these boxes should follow, not precede, any
> boxes defined in or required by derived
> specifications.
>

If no other comments/objections i'll fold this paragraph in the commit log
(thanks Derek) and push tomorrow.
-- 
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH] avcodec/encode: ensure encoders don't return empty packets

2021-04-13 Thread James Almer
The current checks ensured that if they contained data, it was refcounted, but
then wrongly assumed that side data was present if there was no data, instead
of checking for it.

Signed-off-by: James Almer 
---
 libavcodec/encode.c | 16 ++--
 1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/libavcodec/encode.c b/libavcodec/encode.c
index 9a4140f91a..aac32cd0f4 100644
--- a/libavcodec/encode.c
+++ b/libavcodec/encode.c
@@ -259,11 +259,6 @@ end:
 av_frame_unref(frame);
 }
 
-if (got_packet)
-// Encoders must always return ref-counted buffers.
-// Side-data only packets have no data and can be not ref-counted.
-av_assert0(!avpkt->data || avpkt->buf);
-
 return ret;
 }
 
@@ -301,14 +296,15 @@ static int encode_receive_packet_internal(AVCodecContext 
*avctx, AVPacket *avpkt
 ret = avctx->codec->receive_packet(avctx, avpkt);
 if (ret < 0)
 av_packet_unref(avpkt);
-else
-// Encoders must always return ref-counted buffers.
-// Side-data only packets have no data and can be not ref-counted.
-av_assert0(!avpkt->data || avpkt->buf);
 } else
 ret = encode_simple_receive_packet(avctx, avpkt);
 
-if (ret == AVERROR_EOF)
+if (!ret) {
+// Encoders must always return ref-counted buffers.
+av_assert0(!avpkt->data || avpkt->buf);
+// Side-data only packets have no data and can be not ref-counted.
+av_assert0(avpkt->data || avpkt->side_data);
+} else if (ret == AVERROR_EOF)
 avci->draining_done = 1;
 
 return ret;
-- 
2.31.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] avformat/dashdec: Also fetch final partial segment

2021-04-13 Thread Matt Robinson
On Tue, 6 Apr 2021 at 02:36, Steven Liu  wrote:
>
> > 2021年4月6日 上午1:45,Matt Robinson  写道:
> >
> > Currently, the DASH demuxer omits the final segment for a non-live
> > stream (using SegmentTemplate) if it is shorter than the other segments.
> >
> > Correct calc_max_seg_no to round up when calulating the number of
> > segments instead of rounding down to resolve this issue.
> >
> > Signed-off-by: Matt Robinson 
> > ---
> > libavformat/dashdec.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
> > index 6f3f28dcc7..73effd85db 100644
> > --- a/libavformat/dashdec.c
> > +++ b/libavformat/dashdec.c
> > @@ -1445,7 +1445,7 @@ static int64_t calc_max_seg_no(struct representation 
> > *pls, DASHContext *c)
> > } else if (c->is_live && pls->fragment_duration) {
> > num = pls->first_seq_no + (((get_current_time_in_sec() - 
> > c->availability_start_time)) * pls->fragment_timescale)  / 
> > pls->fragment_duration;
> > } else if (pls->fragment_duration) {
> > -num = pls->first_seq_no + (c->media_presentation_duration * 
> > pls->fragment_timescale) / pls->fragment_duration;
> > +num = pls->first_seq_no + av_rescale_rnd(1, 
> > c->media_presentation_duration * pls->fragment_timescale, 
> > pls->fragment_duration, AV_ROUND_UP);
> > }
> >
> > return num;
> > --
> > 2.25.1
>
> LGTM
>
>
> Thanks
>
> Steven Liu

Perfect, thank you Steven.

Does anyone else have any comments on the patch, or would somebody be
okay to commit it?

Many Thanks,

Matt
___
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/9] avcodec/mjpegenc: Include all supported pix_fmts in mpegenc pix_fmts

2021-04-13 Thread Eoff, Ullysses A
> -Original Message-
> From: ffmpeg-devel  On Behalf Of Andreas 
> Rheinhardt
> Sent: Tuesday, April 13, 2021 10:34 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 6/9] avcodec/mjpegenc: Include all 
> supported pix_fmts in mpegenc pix_fmts
> 
> Eoff, Ullysses A:
> > This commit breaks mjpeg_vaapi and mjpeg_qsv encoders.
> >
> > https://trac.ffmpeg.org/ticket/9186
> >
> > ...please fix.
> >
> 
> Please test this patch:
> https://ffmpeg.org/pipermail/ffmpeg-devel/2021-April/279028.html
> It should now work on all strictness levels (it was broken before said
> commit when using -strict unofficial and is broken now on default
> strictness).
> 

Yes, that patch fixes it for me.  Thanks for the quick response!

> - Andreas
> 
> > Thanks,
> > U. Artie
> >
> >> -Original Message-
> >> From: ffmpeg-devel  On Behalf Of Andreas 
> >> Rheinhardt
> >> Sent: Monday, April 05, 2021 10:40 PM
> >> To: ffmpeg-devel@ffmpeg.org
> >> Cc: Andreas Rheinhardt 
> >> Subject: [FFmpeg-devel] [PATCH 6/9] avcodec/mjpegenc: Include all 
> >> supported pix_fmts in mpegenc pix_fmts
> >>
> >> Currently said list contains only the pixel formats that are always
> >> supported irrespective of the range and the value of
> >> strict_std_compliance. This makes the MJPEG encoder an outlier as all
> >> other codecs put all potentially supported pixel formats into said list
> >> and error out if the chosen pixel format is unsupported. This commit
> >> brings it therefore in line with the other encoders.
> >>
> >> The behaviour of fftools/ffmpeg_filter.c has been preserved. A more
> >> informed decision would be possible if colour range were available
> >> at this point, but it isn't.
> >>
> >> Signed-off-by: Andreas Rheinhardt 
> >> ---
> >>  fftools/ffmpeg_filter.c  | 20 +++-
> >>  libavcodec/encode.c  |  4 +---
> >>  libavcodec/ljpegenc.c| 14 +++---
> >>  libavcodec/mjpegenc.c| 11 ++-
> >>  libavcodec/mjpegenc_common.c | 16 
> >>  libavcodec/mjpegenc_common.h |  2 ++
> >>  libavcodec/mpegvideo_enc.c   | 28 +---
> >>  7 files changed, 40 insertions(+), 55 deletions(-)
> >>
> >> diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
> >> index 4ab769c07b..5c44b75eff 100644
> >> --- a/fftools/ffmpeg_filter.c
> >> +++ b/fftools/ffmpeg_filter.c
> >> @@ -39,22 +39,16 @@
> >>  #include "libavutil/imgutils.h"
> >>  #include "libavutil/samplefmt.h"
> >>
> >> -static const enum AVPixelFormat *get_compliance_unofficial_pix_fmts(enum 
> >> AVCodecID codec_id, const enum AVPixelFormat
> >> default_formats[])
> >> +// FIXME: YUV420P etc. are actually supported with full color range,
> >> +// yet the latter information isn't available here.
> >> +static const enum AVPixelFormat *get_compliance_normal_pix_fmts(enum 
> >> AVCodecID codec_id, const enum AVPixelFormat
> >> default_formats[])
> >>  {
> >>  static const enum AVPixelFormat mjpeg_formats[] =
> >>  { AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_YUVJ422P, AV_PIX_FMT_YUVJ444P,
> >> -  AV_PIX_FMT_YUV420P,  AV_PIX_FMT_YUV422P,  AV_PIX_FMT_YUV444P,
> >>AV_PIX_FMT_NONE };
> >> -static const enum AVPixelFormat ljpeg_formats[] =
> >> -{ AV_PIX_FMT_BGR24   , AV_PIX_FMT_BGRA, AV_PIX_FMT_BGR0,
> >> -  AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_YUVJ444P, AV_PIX_FMT_YUVJ422P,
> >> -  AV_PIX_FMT_YUV420P , AV_PIX_FMT_YUV444P , AV_PIX_FMT_YUV422P,
> >> -  AV_PIX_FMT_NONE};
> >>
> >>  if (codec_id == AV_CODEC_ID_MJPEG) {
> >>  return mjpeg_formats;
> >> -} else if (codec_id == AV_CODEC_ID_LJPEG) {
> >> -return ljpeg_formats;
> >>  } else {
> >>  return default_formats;
> >>  }
> >> @@ -70,8 +64,8 @@ static enum AVPixelFormat choose_pixel_fmt(AVStream *st, 
> >> AVCodecContext *enc_ctx
> >>  int has_alpha = desc ? desc->nb_components % 2 == 0 : 0;
> >>  enum AVPixelFormat best= AV_PIX_FMT_NONE;
> >>
> >> -if (enc_ctx->strict_std_compliance <= FF_COMPLIANCE_UNOFFICIAL) {
> >> -p = get_compliance_unofficial_pix_fmts(enc_ctx->codec_id, p);
> >> +if (enc_ctx->strict_std_compliance > FF_COMPLIANCE_UNOFFICIAL) {
> >> +p = get_compliance_normal_pix_fmts(enc_ctx->codec_id, p);
> >>  }
> >>  for (; *p != AV_PIX_FMT_NONE; p++) {
> >>  best = av_find_best_pix_fmt_of_2(best, *p, target, has_alpha, 
> >> NULL);
> >> @@ -118,8 +112,8 @@ static char *choose_pix_fmts(OutputFilter *ofilter)
> >>  exit_program(1);
> >>
> >>  p = ost->enc->pix_fmts;
> >> -if (ost->enc_ctx->strict_std_compliance <= 
> >> FF_COMPLIANCE_UNOFFICIAL) {
> >> -p = 
> >> get_compliance_unofficial_pix_fmts(ost->enc_ctx->codec_id, p);
> >> +if (ost->enc_ctx->strict_std_compliance > 
> >> FF_COMPLIANCE_UNOFFICIAL) {
> >> +p = get_compliance_normal_pix_fmts(ost->enc_ctx->codec_id, p);
> >>  

Re: [FFmpeg-devel] [PATCH] fftools/ffmpeg_filter: Fix check for mjpeg encoder

2021-04-13 Thread Eoff, Ullysses A
Fixes #9186 for me.

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Andreas 
> Rheinhardt
> Sent: Tuesday, April 13, 2021 10:32 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Andreas Rheinhardt 
> Subject: [FFmpeg-devel] [PATCH] fftools/ffmpeg_filter: Fix check for mjpeg 
> encoder
> 
> The MJPEG encoder supports some pixel format/color range combinations
> only when strictness is set to unofficial or less. Before commit
> 059fc2d9da5364627613fb3e6424079e14dbdfd3 said encoder's pix_fmts array
> only included the pixel formats supported with default strictness.
> When strictness was <= unofficial, fftools/ffmpeg_filter.c used
> an extended list of pixel formats instead of the encoder's including
> the pixel formats only supported when strictness <= unofficial.
> 
> Said commit turned the logic around: The encoder's pix_fmts array now
> included all pixel formats and fftools/ffmpeg_filter.c instead used
> a small list of all pixel formats supported when strictness is >
> unofficial and the encoder's pixel formats instead. In particular,
> the codec's pix_fmt is not used when strictness is normal.
> 
> This works for the mjpeg encoder; yet it did not work for other
> (hardware-based) mjpeg encoders, because the check for whether one is
> using the MJPEG encoder is wrong: It just checks the codec id.
> So if one used strict unofficial with a hardware-accelerated MJPEG
> encoder before commit 059fc2d9da53, the unofficial (non-hardware)
> pixel formats of the MJPEG encoder would be used; since said commit
> the codec's pixel formats are overridden at ordinary strictness
> by the ordinary MJPEG pixel formats. This leads to format conversion
> errors lateron which were reported in #9186.
> 
> The solution to this is to check AVCodec.name instead of its id.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  fftools/ffmpeg_filter.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
> index 400f5a4188..e7c05eb3f9 100644
> --- a/fftools/ffmpeg_filter.c
> +++ b/fftools/ffmpeg_filter.c
> @@ -41,13 +41,13 @@
> 
>  // FIXME: YUV420P etc. are actually supported with full color range,
>  // yet the latter information isn't available here.
> -static const enum AVPixelFormat *get_compliance_normal_pix_fmts(enum 
> AVCodecID codec_id, const enum AVPixelFormat
> default_formats[])
> +static const enum AVPixelFormat *get_compliance_normal_pix_fmts(const 
> AVCodec *codec, const enum AVPixelFormat
> default_formats[])
>  {
>  static const enum AVPixelFormat mjpeg_formats[] =
>  { AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_YUVJ422P, AV_PIX_FMT_YUVJ444P,
>AV_PIX_FMT_NONE };
> 
> -if (codec_id == AV_CODEC_ID_MJPEG) {
> +if (!strcmp(codec->name, "mjpeg")) {
>  return mjpeg_formats;
>  } else {
>  return default_formats;
> @@ -65,7 +65,7 @@ static enum AVPixelFormat choose_pixel_fmt(AVStream *st, 
> AVCodecContext *enc_ctx
>  enum AVPixelFormat best= AV_PIX_FMT_NONE;
> 
>  if (enc_ctx->strict_std_compliance > FF_COMPLIANCE_UNOFFICIAL) {
> -p = get_compliance_normal_pix_fmts(enc_ctx->codec_id, p);
> +p = get_compliance_normal_pix_fmts(codec, p);
>  }
>  for (; *p != AV_PIX_FMT_NONE; p++) {
>  best = av_find_best_pix_fmt_of_2(best, *p, target, has_alpha, 
> NULL);
> @@ -113,7 +113,7 @@ static char *choose_pix_fmts(OutputFilter *ofilter)
> 
>  p = ost->enc->pix_fmts;
>  if (ost->enc_ctx->strict_std_compliance > FF_COMPLIANCE_UNOFFICIAL) {
> -p = get_compliance_normal_pix_fmts(ost->enc_ctx->codec_id, p);
> +p = get_compliance_normal_pix_fmts(ost->enc, p);
>  }
> 
>  for (; *p != AV_PIX_FMT_NONE; p++) {
> --
> 2.27.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 1/4] avcodec/h264dec: add missing flags to is_avc and nal_length_size AVOptions

2021-04-13 Thread James Almer

On 4/11/2021 10:25 AM, James Almer wrote:

On 4/11/2021 6:56 AM, Anton Khirnov wrote:

Quoting James Almer (2021-04-10 23:00:20)

Signed-off-by: James Almer 
---
  libavcodec/h264dec.c  | 5 +++--
  tests/ref/fate/mov-zombie | 2 +-
  2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
index 47b9abbc5c..f44c8c8175 100644
--- a/libavcodec/h264dec.c
+++ b/libavcodec/h264dec.c
@@ -1027,9 +1027,10 @@ static int h264_decode_frame(AVCodecContext 
*avctx, void *data,

  #define OFFSET(x) offsetof(H264Context, x)
  #define VD AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_DECODING_PARAM
+#define VDE VD | AV_OPT_FLAG_EXPORT
  static const AVOption h264_options[] = {
-    { "is_avc", "is avc", OFFSET(is_avc), AV_OPT_TYPE_BOOL, {.i64 = 
0}, 0, 1, 0 },
-    { "nal_length_size", "nal_length_size", OFFSET(nal_length_size), 
AV_OPT_TYPE_INT, {.i64 = 0}, 0, 4, 0 },
+    { "is_avc", "is avc", OFFSET(is_avc), AV_OPT_TYPE_BOOL, {.i64 = 
0}, 0, 1, VDE },
+    { "nal_length_size", "nal_length_size", OFFSET(nal_length_size), 
AV_OPT_TYPE_INT, {.i64 = 0}, 0, 4, VDE },


Not objecting to the patch, but does anyone know how these fields are
useful to callers?


When i asked if these two were meant to be exported at all on IRC, Jan 
Ekström argued that as exported avoptions they could be useful for 
callers to know if the stream being decoded is annexb or size delimited, 
so i figured i might as well keep them as is.
As for being input options, if there's no extradata during init or 
propagated as packet side data, situation where decoder will not 
overwrite them but still use them when splitting NALUs, the caller can 
set them manually and decoding could in theory succeed.


I don't know if the user that opened ticket #9176 cared about and used 
them, or just noticed ffprobe printed different values in his own tests, 
and reported it.


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

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

[FFmpeg-devel] [PATCH] avcodec/libaomdec: export frame pict_type

2021-04-13 Thread James Almer
Should fix ticket #9180

Signed-off-by: James Almer 
---
 libavcodec/libaomdec.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/libavcodec/libaomdec.c b/libavcodec/libaomdec.c
index 1fc0a0001d..6de3bcc5c3 100644
--- a/libavcodec/libaomdec.c
+++ b/libavcodec/libaomdec.c
@@ -161,6 +161,7 @@ static int aom_decode(AVCodecContext *avctx, void *data, 
int *got_frame,
 AVFrame *picture  = data;
 const void *iter  = NULL;
 struct aom_image *img;
+aom_codec_frame_flags_t av_unused flags;
 int ret;
 
 if (aom_codec_decode(&ctx->decoder, avpkt->data, avpkt->size, NULL) !=
@@ -198,6 +199,19 @@ static int aom_decode(AVCodecContext *avctx, void *data, 
int *got_frame,
 if ((ret = ff_get_buffer(avctx, picture, 0)) < 0)
 return ret;
 
+#ifdef AOM_CTRL_AOMD_GET_FRAME_FLAGS
+ret = aom_codec_control(&ctx->decoder, AOMD_GET_FRAME_FLAGS, &flags);
+if (ret == AOM_CODEC_OK) {
+picture->key_frame = !!(flags & AOM_FRAME_IS_KEY);
+if (flags & (AOM_FRAME_IS_KEY | AOM_FRAME_IS_INTRAONLY))
+picture->pict_type = AV_PICTURE_TYPE_I;
+else if (flags & AOM_FRAME_IS_SWITCH)
+picture->pict_type = AV_PICTURE_TYPE_SP;
+else
+picture->pict_type = AV_PICTURE_TYPE_P;
+}
+#endif
+
 av_reduce(&picture->sample_aspect_ratio.num,
   &picture->sample_aspect_ratio.den,
   picture->height * img->r_w,
-- 
2.31.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 V8 1/3] lavu: add side data AV_FRAME_DATA_DETECTION_BBOXES for object detection/classification

2021-04-13 Thread myp...@gmail.com
On Tue, Apr 13, 2021 at 1:26 PM Guo, Yejun  wrote:
>
> ---
>  doc/APIchanges |   2 +
>  libavutil/Makefile |   2 +
>  libavutil/detection_bbox.c |  73 +
>  libavutil/detection_bbox.h | 107 +
>  libavutil/frame.c  |   1 +
>  libavutil/frame.h  |   6 +++
>  6 files changed, 191 insertions(+)
>  create mode 100644 libavutil/detection_bbox.c
>  create mode 100644 libavutil/detection_bbox.h
>
> diff --git a/doc/APIchanges b/doc/APIchanges
> index 9dfcc97d5c..30bd235691 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -14,6 +14,8 @@ libavutil: 2017-10-21
>
>
>  API changes, most recent first:
> +2021-04-xx - xx - lavu 56.xx.100 - frame.h detection_bbox.h
> +  Add AV_FRAME_DATA_DETECTION_BBOXES
>
>  2021-04-06 - xx - lavf 58.78.100 - avformat.h
>Add avformat_index_get_entries_count(), avformat_index_get_entry(),
> diff --git a/libavutil/Makefile b/libavutil/Makefile
> index 27bafe9e12..47efb718d2 100644
> --- a/libavutil/Makefile
> +++ b/libavutil/Makefile
> @@ -21,6 +21,7 @@ HEADERS = adler32.h 
> \
>cpu.h \
>crc.h \
>des.h \
> +  detection_bbox.h  \
>dict.h\
>display.h \
>dovi_meta.h   \
> @@ -113,6 +114,7 @@ OBJS = adler32.o  
>   \
> cpu.o\
> crc.o\
> des.o\
> +   detection_bbox.o \
> dict.o   \
> display.o\
> dovi_meta.o  \
> diff --git a/libavutil/detection_bbox.c b/libavutil/detection_bbox.c
> new file mode 100644
> index 00..c54a30d9e5
> --- /dev/null
> +++ b/libavutil/detection_bbox.c
> @@ -0,0 +1,73 @@
> +/*
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
> + */
> +
> +#include "detection_bbox.h"
> +
> +AVDetectionBBoxHeader *av_detection_bbox_alloc(uint32_t nb_bboxes, size_t 
> *out_size)
> +{
> +size_t size;
> +struct {
> +   AVDetectionBBoxHeader header;
> +   AVDetectionBBox boxes[1];
> +} *ret;
> +
> +size = sizeof(*ret);
> +if (nb_bboxes - 1 > (SIZE_MAX - size) / sizeof(*ret->boxes))
> +return NULL;
> +size += sizeof(*ret->boxes) * (nb_bboxes - 1);
> +
> +ret = av_mallocz(size);
> +if (!ret)
> +return NULL;
> +
> +ret->header.nb_bboxes = nb_bboxes;
> +ret->header.bbox_size = sizeof(*ret->boxes);
> +ret->header.bboxes_offset = (char *)&ret->boxes - (char *)&ret->header;
> +
> +if (out_size)
> +*out_size = size;
> +
> +return &ret->header;
> +}
> +
> +AVDetectionBBoxHeader *av_detection_bbox_create_side_data(AVFrame *frame, 
> uint32_t nb_bboxes)
> +{
> +AVBufferRef *buf;
> +AVDetectionBBoxHeader *header;
> +size_t size;
> +
> +header = av_detection_bbox_alloc(nb_bboxes, &size);
> +if (!header)
> +return NULL;
> +if (size > INT_MAX) {
I think need to use SIZE_MAX, not INT_MAX in this case
> +av_freep(&header);
> +return NULL;
> +}
> +buf = av_buffer_create((uint8_t *)header, size, NULL, NULL, 0);
> +if (!buf) {
> +av_freep(&header);
> +return NULL;
> +}
> +
> +if (!av_frame_new_side_data_from_buf(frame, 
> AV_FRAME_DATA_DETECTION_BBOXES, buf)) {
> +av_buffer_unref(&buf);
> +return NULL;
> +}
> +
> +return header;
> +}
> diff --git a/libavutil/

Re: [FFmpeg-devel] [PATCH V8 1/3] lavu: add side data AV_FRAME_DATA_DETECTION_BBOXES for object detection/classification

2021-04-13 Thread Guo, Yejun


> -Original Message-
> From: myp...@gmail.com 
> Sent: 2021年4月14日 9:29
> To: FFmpeg development discussions and patches
> 
> Cc: Guo, Yejun 
> Subject: Re: [FFmpeg-devel] [PATCH V8 1/3] lavu: add side data
> AV_FRAME_DATA_DETECTION_BBOXES for object detection/classification
> 
> On Tue, Apr 13, 2021 at 1:26 PM Guo, Yejun  wrote:
> >
> > ---
> >  doc/APIchanges |   2 +
> >  libavutil/Makefile |   2 +
> >  libavutil/detection_bbox.c |  73 +
> >  libavutil/detection_bbox.h | 107
> +
> > +
> > +#include "detection_bbox.h"
> > +
> > +AVDetectionBBoxHeader *av_detection_bbox_alloc(uint32_t nb_bboxes,
> size_t *out_size)
> > +{
> > +size_t size;
> > +struct {
> > +   AVDetectionBBoxHeader header;
> > +   AVDetectionBBox boxes[1];
> > +} *ret;
> > +
> > +size = sizeof(*ret);
> > +if (nb_bboxes - 1 > (SIZE_MAX - size) / sizeof(*ret->boxes))
> > +return NULL;
> > +size += sizeof(*ret->boxes) * (nb_bboxes - 1);
> > +
> > +ret = av_mallocz(size);
> > +if (!ret)
> > +return NULL;
> > +
> > +ret->header.nb_bboxes = nb_bboxes;
> > +ret->header.bbox_size = sizeof(*ret->boxes);
> > +ret->header.bboxes_offset = (char *)&ret->boxes - (char
> *)&ret->header;
> > +
> > +if (out_size)
> > +*out_size = size;
> > +
> > +return &ret->header;
> > +}
> > +
> > +AVDetectionBBoxHeader
> *av_detection_bbox_create_side_data(AVFrame *frame, uint32_t
> nb_bboxes)
> > +{
> > +AVBufferRef *buf;
> > +AVDetectionBBoxHeader *header;
> > +size_t size;
> > +
> > +header = av_detection_bbox_alloc(nb_bboxes, &size);
> > +if (!header)
> > +return NULL;
> > +if (size > INT_MAX) {
> I think need to use SIZE_MAX, not INT_MAX in this case

thanks for the review, I think 'size_t size' could not larger than SIZE_MAX.

actually, the check is referenced from video_enc_params.

btw, this check will be removed after the bump, see more at
http://ffmpeg.org/pipermail/ffmpeg-devel/2021-April/278779.html

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

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