[FFmpeg-devel] [PATCH] avformat/oggenc: ignore empty packets
Some encoders, like flac, can send side data only packets at the end.
Eventually, said extradata update should ideally be used to update the header
when writting to seekable output, but for now, ignore them.
Should fix the undefined behavior of passing NULL to memcpy().
Signed-off-by: James Almer
---
libavformat/oggenc.c | 2 +-
tests/ref/lavf/ogg | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/oggenc.c b/libavformat/oggenc.c
index ae0705ba54..5003314adb 100644
--- a/libavformat/oggenc.c
+++ b/libavformat/oggenc.c
@@ -687,7 +687,7 @@ static int ogg_write_packet(AVFormatContext *s, AVPacket
*pkt)
{
int i;
-if (pkt)
+if (pkt && pkt->size)
return ogg_write_packet_internal(s, pkt);
for (i = 0; i < s->nb_streams; i++) {
diff --git a/tests/ref/lavf/ogg b/tests/ref/lavf/ogg
index 3ac10e6f7c..0796ff568a 100644
--- a/tests/ref/lavf/ogg
+++ b/tests/ref/lavf/ogg
@@ -1,3 +1,3 @@
-81b9366cacb23644c2803585dced9996 *tests/data/lavf/lavf.ogg
+507a906a705d16f3a3b0c4114c738110 *tests/data/lavf/lavf.ogg
13516 tests/data/lavf/lavf.ogg
tests/data/lavf/lavf.ogg CRC=0x3a1da17e
--
2.38.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 2/2] avcodec/nvdec: make explicit copy of frames unless user requested otherwise
On 09.12.2022 20:20, Philip Langdale wrote:
On Fri, 9 Dec 2022 15:16:17 +0100
Timo Rothenpieler wrote:
---
libavcodec/nvdec.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/libavcodec/nvdec.c b/libavcodec/nvdec.c
index fbaedf0b6b..a477449d14 100644
--- a/libavcodec/nvdec.c
+++ b/libavcodec/nvdec.c
@@ -51,6 +51,8 @@ typedef struct NVDECDecoder {
CudaFunctions *cudl;
CuvidFunctions *cvdl;
+
+int unsafe_output;
} NVDECDecoder;
typedef struct NVDECFramePool {
@@ -344,6 +346,8 @@ int ff_nvdec_decode_init(AVCodecContext *avctx)
int cuvid_codec_type, cuvid_chroma_format, chroma_444;
int ret = 0;
+int unsafe_output = !!(avctx->hwaccel_flags &
AV_HWACCEL_FLAG_UNSAFE_OUTPUT); +
sw_desc = av_pix_fmt_desc_get(avctx->sw_pix_fmt);
if (!sw_desc)
return AVERROR_BUG;
@@ -402,7 +406,7 @@ int ff_nvdec_decode_init(AVCodecContext *avctx)
params.CodecType = cuvid_codec_type;
params.ChromaFormat= cuvid_chroma_format;
params.ulNumDecodeSurfaces = frames_ctx->initial_pool_size;
-params.ulNumOutputSurfaces = frames_ctx->initial_pool_size;
+params.ulNumOutputSurfaces = unsafe_output ?
frames_ctx->initial_pool_size : 1;
ret = nvdec_decoder_create(>decoder_ref,
frames_ctx->device_ref, , avctx); if (ret < 0) {
@@ -417,6 +421,7 @@ int ff_nvdec_decode_init(AVCodecContext *avctx)
}
decoder = (NVDECDecoder*)ctx->decoder_ref->data;
+decoder->unsafe_output = unsafe_output;
decoder->real_hw_frames_ref = real_hw_frames_ref;
real_hw_frames_ref = NULL;
@@ -554,7 +559,11 @@ copy_fail:
finish:
CHECK_CU(decoder->cudl->cuCtxPopCurrent());
-return ret;
+
+if (ret < 0 || decoder->unsafe_output)
+return ret;
+
+return av_frame_make_writable(frame);
}
int ff_nvdec_start_frame(AVCodecContext *avctx, AVFrame *frame)
LGTM
applied
___
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] lavc: convert frame threading to the receive_frame() pattern
On Fri, Dec 09, 2022 at 02:37:04PM +0100, Timo Rothenpieler wrote: > From: Anton Khirnov > > Reorganize the code such that the frame threading code does not call the > decoders directly, but instead calls back into the generic decoding > code. This avoids duplicating the logic that wraps the decoder > invocation and will be useful in the following commits. > --- > libavcodec/decode.c| 58 + > libavcodec/decode.h| 7 + > libavcodec/internal.h | 7 + > libavcodec/pthread_frame.c | 256 - > libavcodec/thread.h| 18 +-- > 5 files changed, 223 insertions(+), 123 deletions(-) this patch changes the output with this: ./ffmpeg -ss 1 -i Enigma_Principles_of_Lust.flv -t 1 -bitexact -f framecrc If someone wants to look into this ill send him the file, it should be online but i failed to find it. --- /tmp/test 2022-12-10 00:29:18.585089416 +0100 +++ /tmp/ref2022-12-10 00:21:14.177412007 +0100 @@ -11,46 +11,53 @@ 0, 0, 0,1, 153360, 0x887a0c84 1, 0, 0, 482, 1928, 0x9228f7f2 1,485,485, 1024, 4096, 0x60c21370 +0, 1, 1,1, 153360, 0x49c60bc4 0, 2, 2,1, 153360, 0x22740bd4 1, 1509, 1509, 1024, 4096, 0x77933b11 0, 3, 3,1, 153360, 0x244d0bb4 1, 2536, 2536, 1024, 4096, 0xe15e8d59 +0, 4, 4,1, 153360, 0x5f660b94 1, 3560, 3560, 1024, 4096, 0x545cdd61 0, 5, 5,1, 153360, 0xb628fd45 0, 6, 6,1, 153360, 0x3839e5cd 1, 4576, 4576, 1024, 4096, 0x47154132 +0, 7, 7,1, 153360, 0xf015da05 1, 5601, 5601, 1024, 4096, 0x7822f57e 0, 8, 8,1, 153360, 0x70f1d8db 0, 9, 9,1, 153360, 0x8968d203 1, 6625, 6625, 1024, 4096, 0xb786e7ff -0, 10, 10,1, 153360, 0x5902c6cb +0, 10, 10,1, 153360, 0x9e73caed 1, 7651, 7651, 1024, 4096, 0x0b467ce8 -0, 11, 11,1, 153360, 0x68e43893 +0, 11, 11,1, 153360, 0x5902c6cb 1, 8675, 8675, 1024, 4096, 0x79229a46 -0, 12, 12,1, 153360, 0x065c5e22 -0, 13, 13,1, 153360, 0x6c2962a9 +0, 12, 12,1, 153360, 0x68e43893 +0, 13, 13,1, 153360, 0x065c5e22 1, 9702, 9702, 1024, 4096, 0x63b1e107 +0, 14, 14,1, 153360, 0x6c2962a9 1, 10726, 10726, 1024, 4096, 0x9f4355eb 0, 15, 15,1, 153360, 0xff0a88e3 1, 11753, 11753, 1024, 4096, 0xcdbae3fe -0, 16, 16,1, 153360, 0xd1395d5c -0, 17, 17,1, 153360, 0x0e1f6bc5 +0, 16, 16,1, 153360, 0x07025790 +0, 17, 17,1, 153360, 0xd1395d5c 1, 12777, 12777, 1024, 4096, 0x48a38fc7 -0, 18, 18,1, 153360, 0x1972db1e +0, 18, 18,1, 153360, 0x0e1f6bc5 1, 13793, 13793, 1024, 4096, 0x3baef67f +0, 19, 19,1, 153360, 0x1972db1e 0, 20, 20,1, 153360, 0x1d6eef56 1, 14818, 14818, 1024, 4096, 0x1009f25c 0, 21, 21,1, 153360, 0x7581f07c 1, 15842, 15842, 1024, 4096, 0x01bedb12 -0, 22, 22,1, 153360, 0xae79cdac +0, 22, 22,1, 153360, 0xe1a9d022 1, 16868, 16868, 1024, 4096, 0xa00c62b0 +0, 23, 23,1, 153360, 0xae79cdac 0, 24, 24,1, 153360, 0x9d05ebf3 1, 17892, 17892, 1024, 4096, 0x9e2f639e 0, 25, 25,1, 153360, 0x48e4e890 1, 18919, 18919, 1024, 4096, 0x0a627322 -0, 26, 26,1, 153360, 0x37e0e5d7 -0, 27, 27,1, 153360, 0x6c20f174 +0, 26, 26,1, 153360, 0x0b35e41a +0, 27, 27,1, 153360, 0x37e0e5d7 1, 19943, 19943, 1024, 4096, 0x5f670b1d -0, 28, 28,1, 153360, 0x727bf68a +0, 28, 28,1, 153360, 0x6c20f174 1, 20959, 20959, 1024, 4096, 0xb6486ba8 +0, 29, 29,1, 153360, 0x727bf68a 1, 21984, 21984, 66, 264, 0x [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are best at talking, realize last or never when they are wrong. signature.asc Description: PGP signature
Re: [FFmpeg-devel] [PATCH v2 2/2] avcodec/nvdec: make explicit copy of frames unless user requested otherwise
On Fri, 9 Dec 2022 15:16:17 +0100
Timo Rothenpieler wrote:
> ---
> libavcodec/nvdec.c | 13 +++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/nvdec.c b/libavcodec/nvdec.c
> index fbaedf0b6b..a477449d14 100644
> --- a/libavcodec/nvdec.c
> +++ b/libavcodec/nvdec.c
> @@ -51,6 +51,8 @@ typedef struct NVDECDecoder {
>
> CudaFunctions *cudl;
> CuvidFunctions *cvdl;
> +
> +int unsafe_output;
> } NVDECDecoder;
>
> typedef struct NVDECFramePool {
> @@ -344,6 +346,8 @@ int ff_nvdec_decode_init(AVCodecContext *avctx)
> int cuvid_codec_type, cuvid_chroma_format, chroma_444;
> int ret = 0;
>
> +int unsafe_output = !!(avctx->hwaccel_flags &
> AV_HWACCEL_FLAG_UNSAFE_OUTPUT); +
> sw_desc = av_pix_fmt_desc_get(avctx->sw_pix_fmt);
> if (!sw_desc)
> return AVERROR_BUG;
> @@ -402,7 +406,7 @@ int ff_nvdec_decode_init(AVCodecContext *avctx)
> params.CodecType = cuvid_codec_type;
> params.ChromaFormat= cuvid_chroma_format;
> params.ulNumDecodeSurfaces = frames_ctx->initial_pool_size;
> -params.ulNumOutputSurfaces = frames_ctx->initial_pool_size;
> +params.ulNumOutputSurfaces = unsafe_output ?
> frames_ctx->initial_pool_size : 1;
> ret = nvdec_decoder_create(>decoder_ref,
> frames_ctx->device_ref, , avctx); if (ret < 0) {
> @@ -417,6 +421,7 @@ int ff_nvdec_decode_init(AVCodecContext *avctx)
> }
>
> decoder = (NVDECDecoder*)ctx->decoder_ref->data;
> +decoder->unsafe_output = unsafe_output;
> decoder->real_hw_frames_ref = real_hw_frames_ref;
> real_hw_frames_ref = NULL;
>
> @@ -554,7 +559,11 @@ copy_fail:
>
> finish:
> CHECK_CU(decoder->cudl->cuCtxPopCurrent());
> -return ret;
> +
> +if (ret < 0 || decoder->unsafe_output)
> +return ret;
> +
> +return av_frame_make_writable(frame);
> }
>
> int ff_nvdec_start_frame(AVCodecContext *avctx, AVFrame *frame)
LGTM
--phil
___
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/2] lavc: add new unsafe_output hwaccel_flag
On Fri, 9 Dec 2022 15:16:16 +0100
Timo Rothenpieler wrote:
> ---
> doc/APIchanges | 3 +++
> libavcodec/avcodec.h | 16
> libavcodec/options_table.h | 1 +
> libavcodec/version.h | 4 ++--
> 4 files changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/doc/APIchanges b/doc/APIchanges
> index ab7ce15fae..328028f293 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -14,6 +14,9 @@ libavutil: 2021-04-27
>
> API changes, most recent first:
>
> +2022-12-xx - xx - lavc 59.55.100 - avcodec.h
> + Add AV_HWACCEL_FLAG_UNSAFE_OUTPUT.
> +
> 2022-11-xx - xx - lavu 57.43.100 - tx.h
>Add AV_TX_FLOAT_DCT, AV_TX_DOUBLE_DCT and AV_TX_INT32_DCT.
>
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 3edd8e2636..0ac581d660 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -2253,6 +2253,22 @@ typedef struct AVHWAccel {
> */
> #define AV_HWACCEL_FLAG_ALLOW_PROFILE_MISMATCH (1 << 2)
>
> +/**
> + * Some hardware decoders (namely nvdec) can either output direct
> decoder
> + * surfaces, or make an on-device copy and return said copy.
> + * There is a hard limit on how many decoder surfaces there can be,
> and it
> + * cannot be accurately guessed ahead of time.
> + * For some processing chains, this can be okay, but others will run
> into the
> + * limit and in turn produce very confusing errors that require fine
> tuning of
> + * more or less obscure options by the user, or in extreme cases
> cannot be
> + * resolved at all without inserting an avfilter that forces a copy.
> + *
> + * Thus, the hwaccel will by default make a copy for safety and
> resilience.
> + * If a users really wants to minimize the amount of copies, they
> can set this
> + * flag and ensure their processing chain does not exhaust the
> surface pool.
> + */
> +#define AV_HWACCEL_FLAG_UNSAFE_OUTPUT (1 << 3)
> +
> /**
> * @}
> */
> diff --git a/libavcodec/options_table.h b/libavcodec/options_table.h
> index cd02f5096f..7924ca6144 100644
> --- a/libavcodec/options_table.h
> +++ b/libavcodec/options_table.h
> @@ -399,6 +399,7 @@ static const AVOption avcodec_options[] = {
> {"ignore_level", "ignore level even if the codec level used is
> unknown or higher than the maximum supported level reported by the
> hardware driver", 0, AV_OPT_TYPE_CONST, { .i64 =
> AV_HWACCEL_FLAG_IGNORE_LEVEL }, INT_MIN, INT_MAX, V | D,
> "hwaccel_flags" }, {"allow_high_depth", "allow to output YUV pixel
> formats with a different chroma sampling than 4:2:0 and/or other than
> 8 bits per component", 0, AV_OPT_TYPE_CONST, {.i64 =
> AV_HWACCEL_FLAG_ALLOW_HIGH_DEPTH }, INT_MIN, INT_MAX, V | D,
> "hwaccel_flags"}, {"allow_profile_mismatch", "attempt to decode
> anyway if HW accelerated decoder's supported profiles do not exactly
> match the stream", 0, AV_OPT_TYPE_CONST, {.i64 =
> AV_HWACCEL_FLAG_ALLOW_PROFILE_MISMATCH }, INT_MIN, INT_MAX, V | D,
> "hwaccel_flags"}, +{"unsafe_output", "allow potentially unsafe
> hwaccel frame output that might require special care to process
> successfully", 0, AV_OPT_TYPE_CONST, {.i64 =
> AV_HWACCEL_FLAG_UNSAFE_OUTPUT }, INT_MIN, INT_MAX, V | D,
> "hwaccel_flags"}, {"extra_hw_frames", "Number of extra hardware
> frames to allocate for the user", OFFSET(extra_hw_frames),
> AV_OPT_TYPE_INT, { .i64 = -1 }, -1, INT_MAX, V|D },
> {"discard_damaged_percentage", "Percentage of damaged samples to
> discard a frame", OFFSET(discard_damaged_percentage),
> AV_OPT_TYPE_INT, {.i64 = 95 }, 0, 100, V|D }, {NULL}, diff --git
> a/libavcodec/version.h b/libavcodec/version.h index
> 9e66920593..9f42f09f4e 100644 --- a/libavcodec/version.h +++
> b/libavcodec/version.h @@ -29,8 +29,8 @@ #include "version_major.h"
> -#define LIBAVCODEC_VERSION_MINOR 54 -#define
> LIBAVCODEC_VERSION_MICRO 101 +#define LIBAVCODEC_VERSION_MINOR 55
> +#define LIBAVCODEC_VERSION_MICRO 100 #define LIBAVCODEC_VERSION_INT
> AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \ LIBAVCODEC_VERSION_MINOR, \
LGTM
--phil
___
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] AVX512 NUCs for FATE and development
On Thu, Dec 08, 2022 at 09:40:12PM +, Kieran Kunhya wrote: > I intend to buy this RAM: > https://www.amazon.co.uk/Crucial-CT2K16G4SFRA32A-PC4-25600-SODIMM-260-Pin/dp/B08C4X9VR5 > > 2x £529 for NUCs > 2x £102.48 for RAM > 2x £69 for M.2 NVMe SSD > > £1400 total. iam in favor of this too I would also recommand to use (SPI or FFIS) FFmpeg funds as these seem to increase each year and i presume people who donate want their donation to be used. also note that SPI will own the hardware legally for us IIRC if SPI/FFmpeg funds are used. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you drop bombs on a foreign country and kill a hundred thousand innocent people, expect your government to call the consequence "unprovoked inhuman terrorist attacks" and use it to justify dropping more bombs and killing more people. The technology changed, the idea is old. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Towards YUVJ removal
On Fri, Dec 09, 2022 at 12:49:41PM +0100, Niklas Haas wrote: > So, as was discussed at the last meeting, we should move towards > removing YUVJ. I want to gather feedback on what appears to be to the > major hurdle, and possible ways to solve it. > > The basic major issue is how to handle the case of combining limited > range input with an encoder for a format that only accepts full range > data. The common case, for example, would be converting a frame from a > typical video file to a JPEG: > > $ ffmpeg -f lavfi -i smptebars -vframes 1 output.jpg > > Currently, this works because the JPEG encoder only advertises YUVJ > pixel formats, and therefore ffmpeg auto-inserts swscaler to convert > from limited range to full range. But this depends on conflating color > range and pixel formats, which is exactly what has been marked > deprecated for an eternity. > > Now, there are some solutions I can see for how to handle this case in > a non-YUVJ world: > > 1. Simply output an error, and rely on the user to insert a conversion >filter, e.g.: > >$ ffmpeg -f lavfi -i smptebars -vframes 1 output.jpg >error: inputs to jpeg encoder must be full range > >$ ffmpeg -f lavfi -i smptebars -vframes 1 -vf scale=out_range=jpeg > output.jpg >... works > > 2. Have the JPEG encoder take care of range conversion internally, by >using sws to convert limited to full range. > > 3. Allow filters to start exposing color space metadata as part of >filter negotiation, and then auto-insert swscaler whenever colorspace >conversion needs to happen as a result of filters not accepting the >corresponding color metadata. This would also allow more than just >conversion between limited/full range. > > 4. Combine approach 1 with an encoder flag for "supports full range >only", and have ffmpeg.c auto-insert a scale filter as the last step >before the encoder if this flag is set (and input is limited range). > > 1 would be the most explicit but would break any existing pipeline that > includes conversion to jpeg, which is probably a very large number. > > 2 would be the least work, but violates abstraction boundaries. > > 3 would be the most work and is, IMO, of questionable gain. > > 4 would be both explicit and not break existing workflows. 3 is nice but is hard as it draws filter negotiation in and that has to do something even for non trivial filter networks. 4 with the complexity in jpeg as disscussed elsewhere in this thread also may or may not be as clean as it sounds here but both 3 and 4 with some amendment sound reasonable to me another option would be to either improve A. general "supported value" information a encoder should be able to tell the caller what it supports depending on some parameter, for example depending on profile and level or std compliance. This would mean implementing AVClass.query_ranges() and using av_opt_query_ranges() IIRC B. error reporting so that failures become machiene readable. aka, "this failed because color range is not X || std complicance is > Y" the lib user could then retry by applying the change if that is within what the usecase wants Both A and B obvioulsy have a much broader use than YUVJ removal thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 2 "100% positive feedback" - "All either got their money back or didnt complain" "Best seller ever, very honest" - "Seller refunded buyer after failed scam" 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] lavc: convert frame threading to the receive_frame() pattern
On Fri, Dec 09, 2022 at 02:09:45PM +0100, Timo Rothenpieler wrote: > On 07/12/2022 23:22, Michael Niedermayer wrote: > > On Wed, Dec 07, 2022 at 02:20:23PM +0100, Timo Rothenpieler wrote: > > > From: Anton Khirnov > > > > > > Reorganize the code such that the frame threading code does not call the > > > decoders directly, but instead calls back into the generic decoding > > > code. This avoids duplicating the logic that wraps the decoder > > > invocation and will be useful in the following commits. > > > --- > > > libavcodec/decode.c| 57 + > > > libavcodec/decode.h| 7 + > > > libavcodec/internal.h | 7 + > > > libavcodec/pthread_frame.c | 256 - > > > libavcodec/thread.h| 18 +-- > > > 5 files changed, 222 insertions(+), 123 deletions(-) > > > > This breaks on arm (probably lack of pthread support) in this env > > > > libavcodec/libavcodec.a(decode.o): In function > > `decode_receive_frame_internal': > > arm/src/libavcodec/decode.c:616: undefined reference to > > `ff_thread_receive_frame' > > arm/src/libavcodec/decode.c:616: undefined reference to > > `ff_thread_receive_frame' > > collect2: error: ld returned 1 exit status > > Makefile:131: recipe for target 'ffprobe_g' failed > > make: *** [ffprobe_g] Error 1 > > Probably just missing an #if somewhere. > Why does arm not support pthreads though? > Or is that just this specific configuration? just this specific environment i could fix that but then noone will test the lack of pthreads so i think its better if i leave it :) thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When the tyrant has disposed of foreign enemies by conquest or treaty, and there is nothing more to fear from them, then he is always stirring up some war or other, in order that the people may require a leader. -- Plato signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat: Rename IPFS to IPFS gateway
Derek Buitenhuis (12022-12-09): > My intent was to rename in case we ever got an actual IPFS implementation, > but I have no strong opinion on whether to keep this part of the patch or > not. Even if we do, the names are local, they do not conflict. > My personal preference is verbosity here, but it's not a strong preference. I do not insist on this. Maybe verbosity is best. 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".
Re: [FFmpeg-devel] [PATCH] avformat: Rename IPFS to IPFS gateway
On 12/9/2022 3:45 PM, Nicolas George wrote:
>> -static int ipfs_read(URLContext *h, unsigned char *buf, int size)
>> +static int ipfs_gateway_read(URLContext *h, unsigned char *buf, int size)
>
> There is no need to rename local symbols.
My intent was to rename in case we ever got an actual IPFS implementation,
but I have no strong opinion on whether to keep this part of the patch or
not.
>> +const URLProtocol ff_ipfs_gateway_protocol = {
>> +.name = "ipfs_gateway",
>
> It is a bit of a mouthful. Maybe "ipfsgw"?
My personal preference is verbosity here, but it's not a strong preference.
- Derek
___
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: Rename IPFS to IPFS gateway
Derek Buitenhuis (12022-12-09):
> It is a URL rewriter for IPFS gateways, not an actual implementation of
> IPFS, and naming it as such was both incorrect and misleading.
>
> Signed-off-by: Derek Buitenhuis
> ---
> As was discussed at the developer meeting last week, presented here for
> comments.
>
> Personally I think libavformat is no place for URL rewriters pretending to be
> protocols, and think that URLs should be rewritten at the layer above avformat
> (i.e. nuke this entirely), but I figure this is less likely to get me abusive
> hate emails again to my personal mail - or at least fewer.
I rather agree.
> ---
> Changelog | 2 +-
> configure | 4 ++--
> libavformat/Makefile | 4 ++--
> libavformat/ipfsgateway.c | 34 +-
> libavformat/protocols.c | 4 ++--
> 5 files changed, 24 insertions(+), 24 deletions(-)
>
> diff --git a/Changelog b/Changelog
> index af2dd65f8f..1e9e862406 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -30,7 +30,7 @@ version :
>
>
> version 5.1:
> -- add ipfs/ipns protocol support
> +- add ipfs/ipns gateway support
> - dialogue enhance audio filter
> - dropped obsolete XvMC hwaccel
> - pcm-bluray encoder
> diff --git a/configure b/configure
> index f4eedfc207..af78d79716 100755
> --- a/configure
> +++ b/configure
> @@ -3597,8 +3597,8 @@ udp_protocol_select="network"
> udplite_protocol_select="network"
> unix_protocol_deps="sys_un_h"
> unix_protocol_select="network"
> -ipfs_protocol_select="https_protocol"
> -ipns_protocol_select="https_protocol"
> +ipfs_gateway_protocol_select="https_protocol"
> +ipns_gateway_protocol_select="https_protocol"
>
> # external library protocols
> libamqp_protocol_deps="librabbitmq"
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index d7f198bf39..2699409e43 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -672,8 +672,8 @@ OBJS-$(CONFIG_SRTP_PROTOCOL) += srtpproto.o
> srtp.o
> OBJS-$(CONFIG_SUBFILE_PROTOCOL) += subfile.o
> OBJS-$(CONFIG_TEE_PROTOCOL) += teeproto.o tee_common.o
> OBJS-$(CONFIG_TCP_PROTOCOL) += tcp.o
> -OBJS-$(CONFIG_IPFS_PROTOCOL) += ipfsgateway.o
> -OBJS-$(CONFIG_IPNS_PROTOCOL) += ipfsgateway.o
> +OBJS-$(CONFIG_IPFS_GATEWAY_PROTOCOL) += ipfsgateway.o
> +OBJS-$(CONFIG_IPNS_GATEWAY_PROTOCOL) += ipfsgateway.o
> TLS-OBJS-$(CONFIG_GNUTLS)+= tls_gnutls.o
> TLS-OBJS-$(CONFIG_LIBTLS)+= tls_libtls.o
> TLS-OBJS-$(CONFIG_MBEDTLS) += tls_mbedtls.o
> diff --git a/libavformat/ipfsgateway.c b/libavformat/ipfsgateway.c
> index ce69d9055a..336a2603db 100644
> --- a/libavformat/ipfsgateway.c
> +++ b/libavformat/ipfsgateway.c
> @@ -304,19 +304,19 @@ err:
> return ret;
> }
>
> -static int ipfs_read(URLContext *h, unsigned char *buf, int size)
> +static int ipfs_gateway_read(URLContext *h, unsigned char *buf, int size)
There is no need to rename local symbols.
> {
> IPFSGatewayContext *c = h->priv_data;
> return ffurl_read(c->inner, buf, size);
> }
>
> -static int64_t ipfs_seek(URLContext *h, int64_t pos, int whence)
> +static int64_t ipfs_gateway_seek(URLContext *h, int64_t pos, int whence)
> {
> IPFSGatewayContext *c = h->priv_data;
> return ffurl_seek(c->inner, pos, whence);
> }
>
> -static int ipfs_close(URLContext *h)
> +static int ipfs_gateway_close(URLContext *h)
> {
> IPFSGatewayContext *c = h->priv_data;
> return ffurl_closep(>inner);
> @@ -329,29 +329,29 @@ static const AVOption options[] = {
> {NULL},
> };
>
> -static const AVClass ipfs_context_class = {
> -.class_name = "IPFS",
> +static const AVClass ipfs_gateway_context_class = {
> +.class_name = "IPFS Gateway",
> .item_name = av_default_item_name,
> .option = options,
> .version= LIBAVUTIL_VERSION_INT,
> };
>
> -const URLProtocol ff_ipfs_protocol = {
> -.name = "ipfs",
> +const URLProtocol ff_ipfs_gateway_protocol = {
> +.name = "ipfs_gateway",
It is a bit of a mouthful. Maybe "ipfsgw"?
> .url_open2 = translate_ipfs_to_http,
> -.url_read = ipfs_read,
> -.url_seek = ipfs_seek,
> -.url_close = ipfs_close,
> +.url_read = ipfs_gateway_read,
> +.url_seek = ipfs_gateway_seek,
> +.url_close = ipfs_gateway_close,
> .priv_data_size = sizeof(IPFSGatewayContext),
> -.priv_data_class= _context_class,
> +.priv_data_class= _gateway_context_class,
> };
>
> -const URLProtocol ff_ipns_protocol = {
> -.name = "ipns",
> +const URLProtocol ff_ipns_gateway_protocol = {
> +.name = "ipns_gateway",
> .url_open2 = translate_ipfs_to_http,
> -.url_read = ipfs_read,
> -.url_seek = ipfs_seek,
> -.url_close
[FFmpeg-devel] [PATCH] avformat: Rename IPFS to IPFS gateway
It is a URL rewriter for IPFS gateways, not an actual implementation of
IPFS, and naming it as such was both incorrect and misleading.
Signed-off-by: Derek Buitenhuis
---
As was discussed at the developer meeting last week, presented here for
comments.
Personally I think libavformat is no place for URL rewriters pretending to be
protocols, and think that URLs should be rewritten at the layer above avformat
(i.e. nuke this entirely), but I figure this is less likely to get me abusive
hate emails again to my personal mail - or at least fewer.
---
Changelog | 2 +-
configure | 4 ++--
libavformat/Makefile | 4 ++--
libavformat/ipfsgateway.c | 34 +-
libavformat/protocols.c | 4 ++--
5 files changed, 24 insertions(+), 24 deletions(-)
diff --git a/Changelog b/Changelog
index af2dd65f8f..1e9e862406 100644
--- a/Changelog
+++ b/Changelog
@@ -30,7 +30,7 @@ version :
version 5.1:
-- add ipfs/ipns protocol support
+- add ipfs/ipns gateway support
- dialogue enhance audio filter
- dropped obsolete XvMC hwaccel
- pcm-bluray encoder
diff --git a/configure b/configure
index f4eedfc207..af78d79716 100755
--- a/configure
+++ b/configure
@@ -3597,8 +3597,8 @@ udp_protocol_select="network"
udplite_protocol_select="network"
unix_protocol_deps="sys_un_h"
unix_protocol_select="network"
-ipfs_protocol_select="https_protocol"
-ipns_protocol_select="https_protocol"
+ipfs_gateway_protocol_select="https_protocol"
+ipns_gateway_protocol_select="https_protocol"
# external library protocols
libamqp_protocol_deps="librabbitmq"
diff --git a/libavformat/Makefile b/libavformat/Makefile
index d7f198bf39..2699409e43 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -672,8 +672,8 @@ OBJS-$(CONFIG_SRTP_PROTOCOL) += srtpproto.o
srtp.o
OBJS-$(CONFIG_SUBFILE_PROTOCOL) += subfile.o
OBJS-$(CONFIG_TEE_PROTOCOL) += teeproto.o tee_common.o
OBJS-$(CONFIG_TCP_PROTOCOL) += tcp.o
-OBJS-$(CONFIG_IPFS_PROTOCOL) += ipfsgateway.o
-OBJS-$(CONFIG_IPNS_PROTOCOL) += ipfsgateway.o
+OBJS-$(CONFIG_IPFS_GATEWAY_PROTOCOL) += ipfsgateway.o
+OBJS-$(CONFIG_IPNS_GATEWAY_PROTOCOL) += ipfsgateway.o
TLS-OBJS-$(CONFIG_GNUTLS)+= tls_gnutls.o
TLS-OBJS-$(CONFIG_LIBTLS)+= tls_libtls.o
TLS-OBJS-$(CONFIG_MBEDTLS) += tls_mbedtls.o
diff --git a/libavformat/ipfsgateway.c b/libavformat/ipfsgateway.c
index ce69d9055a..336a2603db 100644
--- a/libavformat/ipfsgateway.c
+++ b/libavformat/ipfsgateway.c
@@ -304,19 +304,19 @@ err:
return ret;
}
-static int ipfs_read(URLContext *h, unsigned char *buf, int size)
+static int ipfs_gateway_read(URLContext *h, unsigned char *buf, int size)
{
IPFSGatewayContext *c = h->priv_data;
return ffurl_read(c->inner, buf, size);
}
-static int64_t ipfs_seek(URLContext *h, int64_t pos, int whence)
+static int64_t ipfs_gateway_seek(URLContext *h, int64_t pos, int whence)
{
IPFSGatewayContext *c = h->priv_data;
return ffurl_seek(c->inner, pos, whence);
}
-static int ipfs_close(URLContext *h)
+static int ipfs_gateway_close(URLContext *h)
{
IPFSGatewayContext *c = h->priv_data;
return ffurl_closep(>inner);
@@ -329,29 +329,29 @@ static const AVOption options[] = {
{NULL},
};
-static const AVClass ipfs_context_class = {
-.class_name = "IPFS",
+static const AVClass ipfs_gateway_context_class = {
+.class_name = "IPFS Gateway",
.item_name = av_default_item_name,
.option = options,
.version= LIBAVUTIL_VERSION_INT,
};
-const URLProtocol ff_ipfs_protocol = {
-.name = "ipfs",
+const URLProtocol ff_ipfs_gateway_protocol = {
+.name = "ipfs_gateway",
.url_open2 = translate_ipfs_to_http,
-.url_read = ipfs_read,
-.url_seek = ipfs_seek,
-.url_close = ipfs_close,
+.url_read = ipfs_gateway_read,
+.url_seek = ipfs_gateway_seek,
+.url_close = ipfs_gateway_close,
.priv_data_size = sizeof(IPFSGatewayContext),
-.priv_data_class= _context_class,
+.priv_data_class= _gateway_context_class,
};
-const URLProtocol ff_ipns_protocol = {
-.name = "ipns",
+const URLProtocol ff_ipns_gateway_protocol = {
+.name = "ipns_gateway",
.url_open2 = translate_ipfs_to_http,
-.url_read = ipfs_read,
-.url_seek = ipfs_seek,
-.url_close = ipfs_close,
+.url_read = ipfs_gateway_read,
+.url_seek = ipfs_gateway_seek,
+.url_close = ipfs_gateway_close,
.priv_data_size = sizeof(IPFSGatewayContext),
-.priv_data_class= _context_class,
+.priv_data_class= _gateway_context_class,
};
diff --git a/libavformat/protocols.c b/libavformat/protocols.c
index
[FFmpeg-devel] [PATCH 2/2] doc/protocols: Remove IPFS urls to specific content in examples
We shouldn't be providing links to unverified and non-FFmpeg-controlled
content in our documentation.
Signed-off-by: Derek Buitenhuis
---
doc/protocols.texi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/protocols.texi b/doc/protocols.texi
index b9c9485646..d1c6fced7b 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -635,12 +635,12 @@ and @code{$HOME/.ipfs/}, in that order.
One can use this protocol in 2 ways. Using IPFS:
@example
-ffplay ipfs://QmbGtJg23skhvFmu9mJiePVByhfzu5rwo74MEkVDYAmF5T
+ffplay ipfs://
@end example
Or the IPNS protocol (IPNS is mutable IPFS):
@example
-ffplay ipns://QmbGtJg23skhvFmu9mJiePVByhfzu5rwo74MEkVDYAmF5T
+ffplay ipns://
@end example
@section mmst
--
2.38.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/file: add fd protocol
Quoting Zhao Zhili (2022-11-18 19:48:02) > From: Zhao Zhili > > Unlike the pipe protocol, fd protocol has seek support if it > corresponding to a regular file. > --- > Sometimes it's the only way to access files via file descriptor, e.g., > requesting a shared file on Android: > https://developer.android.com/training/secure-file-sharing/request-file > Wouldn't dup()ing the file descriptor be safer? -- 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".
[FFmpeg-devel] [PATCH v2 2/2] avcodec/nvdec: make explicit copy of frames unless user requested otherwise
---
libavcodec/nvdec.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/libavcodec/nvdec.c b/libavcodec/nvdec.c
index fbaedf0b6b..a477449d14 100644
--- a/libavcodec/nvdec.c
+++ b/libavcodec/nvdec.c
@@ -51,6 +51,8 @@ typedef struct NVDECDecoder {
CudaFunctions *cudl;
CuvidFunctions *cvdl;
+
+int unsafe_output;
} NVDECDecoder;
typedef struct NVDECFramePool {
@@ -344,6 +346,8 @@ int ff_nvdec_decode_init(AVCodecContext *avctx)
int cuvid_codec_type, cuvid_chroma_format, chroma_444;
int ret = 0;
+int unsafe_output = !!(avctx->hwaccel_flags &
AV_HWACCEL_FLAG_UNSAFE_OUTPUT);
+
sw_desc = av_pix_fmt_desc_get(avctx->sw_pix_fmt);
if (!sw_desc)
return AVERROR_BUG;
@@ -402,7 +406,7 @@ int ff_nvdec_decode_init(AVCodecContext *avctx)
params.CodecType = cuvid_codec_type;
params.ChromaFormat= cuvid_chroma_format;
params.ulNumDecodeSurfaces = frames_ctx->initial_pool_size;
-params.ulNumOutputSurfaces = frames_ctx->initial_pool_size;
+params.ulNumOutputSurfaces = unsafe_output ? frames_ctx->initial_pool_size
: 1;
ret = nvdec_decoder_create(>decoder_ref, frames_ctx->device_ref,
, avctx);
if (ret < 0) {
@@ -417,6 +421,7 @@ int ff_nvdec_decode_init(AVCodecContext *avctx)
}
decoder = (NVDECDecoder*)ctx->decoder_ref->data;
+decoder->unsafe_output = unsafe_output;
decoder->real_hw_frames_ref = real_hw_frames_ref;
real_hw_frames_ref = NULL;
@@ -554,7 +559,11 @@ copy_fail:
finish:
CHECK_CU(decoder->cudl->cuCtxPopCurrent());
-return ret;
+
+if (ret < 0 || decoder->unsafe_output)
+return ret;
+
+return av_frame_make_writable(frame);
}
int ff_nvdec_start_frame(AVCodecContext *avctx, AVFrame *frame)
--
2.34.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 v2 1/2] lavc: add new unsafe_output hwaccel_flag
---
doc/APIchanges | 3 +++
libavcodec/avcodec.h | 16
libavcodec/options_table.h | 1 +
libavcodec/version.h | 4 ++--
4 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index ab7ce15fae..328028f293 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -14,6 +14,9 @@ libavutil: 2021-04-27
API changes, most recent first:
+2022-12-xx - xx - lavc 59.55.100 - avcodec.h
+ Add AV_HWACCEL_FLAG_UNSAFE_OUTPUT.
+
2022-11-xx - xx - lavu 57.43.100 - tx.h
Add AV_TX_FLOAT_DCT, AV_TX_DOUBLE_DCT and AV_TX_INT32_DCT.
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 3edd8e2636..0ac581d660 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -2253,6 +2253,22 @@ typedef struct AVHWAccel {
*/
#define AV_HWACCEL_FLAG_ALLOW_PROFILE_MISMATCH (1 << 2)
+/**
+ * Some hardware decoders (namely nvdec) can either output direct decoder
+ * surfaces, or make an on-device copy and return said copy.
+ * There is a hard limit on how many decoder surfaces there can be, and it
+ * cannot be accurately guessed ahead of time.
+ * For some processing chains, this can be okay, but others will run into the
+ * limit and in turn produce very confusing errors that require fine tuning of
+ * more or less obscure options by the user, or in extreme cases cannot be
+ * resolved at all without inserting an avfilter that forces a copy.
+ *
+ * Thus, the hwaccel will by default make a copy for safety and resilience.
+ * If a users really wants to minimize the amount of copies, they can set this
+ * flag and ensure their processing chain does not exhaust the surface pool.
+ */
+#define AV_HWACCEL_FLAG_UNSAFE_OUTPUT (1 << 3)
+
/**
* @}
*/
diff --git a/libavcodec/options_table.h b/libavcodec/options_table.h
index cd02f5096f..7924ca6144 100644
--- a/libavcodec/options_table.h
+++ b/libavcodec/options_table.h
@@ -399,6 +399,7 @@ static const AVOption avcodec_options[] = {
{"ignore_level", "ignore level even if the codec level used is unknown or
higher than the maximum supported level reported by the hardware driver", 0,
AV_OPT_TYPE_CONST, { .i64 = AV_HWACCEL_FLAG_IGNORE_LEVEL }, INT_MIN, INT_MAX, V
| D, "hwaccel_flags" },
{"allow_high_depth", "allow to output YUV pixel formats with a different
chroma sampling than 4:2:0 and/or other than 8 bits per component", 0,
AV_OPT_TYPE_CONST, {.i64 = AV_HWACCEL_FLAG_ALLOW_HIGH_DEPTH }, INT_MIN,
INT_MAX, V | D, "hwaccel_flags"},
{"allow_profile_mismatch", "attempt to decode anyway if HW accelerated
decoder's supported profiles do not exactly match the stream", 0,
AV_OPT_TYPE_CONST, {.i64 = AV_HWACCEL_FLAG_ALLOW_PROFILE_MISMATCH }, INT_MIN,
INT_MAX, V | D, "hwaccel_flags"},
+{"unsafe_output", "allow potentially unsafe hwaccel frame output that might
require special care to process successfully", 0, AV_OPT_TYPE_CONST, {.i64 =
AV_HWACCEL_FLAG_UNSAFE_OUTPUT }, INT_MIN, INT_MAX, V | D, "hwaccel_flags"},
{"extra_hw_frames", "Number of extra hardware frames to allocate for the
user", OFFSET(extra_hw_frames), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, INT_MAX,
V|D },
{"discard_damaged_percentage", "Percentage of damaged samples to discard a
frame", OFFSET(discard_damaged_percentage), AV_OPT_TYPE_INT, {.i64 = 95 }, 0,
100, V|D },
{NULL},
diff --git a/libavcodec/version.h b/libavcodec/version.h
index 9e66920593..9f42f09f4e 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -29,8 +29,8 @@
#include "version_major.h"
-#define LIBAVCODEC_VERSION_MINOR 54
-#define LIBAVCODEC_VERSION_MICRO 101
+#define LIBAVCODEC_VERSION_MINOR 55
+#define LIBAVCODEC_VERSION_MICRO 100
#define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
LIBAVCODEC_VERSION_MINOR, \
--
2.34.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] Towards YUVJ removal
On Fri, Dec 9, 2022 at 1:45 PM Niklas Haas wrote: > Oh, you are right. So that presents an alternative to 4 - rather than an > encoder flag, we can tie the auto-conversion in fftools to be tied to > the strict_std_compliance check. > > I will try implementing this approach, it may be the best compromise in > that it presents a clear upgrade path that doesn't break the common > case. > > That said, there still is an encoder that has this problem: "amv". > Currently, this only advertises YUVJ, but after YUVJ removal, it would > be treated equivalently to mjpeg when `strict_std_compliance` is enabled. > > But given that this is a less common format, I think, such a regression > would not be as big a concern. (And we can still special-case it in > fftools, if we want to) > As a user of the API, I do not think hacking fftools is the way to go. I vote option 3, filter negotiation also takes color_range (etc) info into account, and auto-inserts a scale where needed. But that is only half the solution, and actually not the important part. If i have a frame source and another sink that both have declared pixel formats, i can easily check whether conversion needs to happen at all, and if so, just set up an empty filter chain and have it auto-insert the required scale filter (super!). Now i would have to also be able to: 1. have settings in the filter context (i guess) for color_range, etc, and corresponding syntax for the args argument of avfilter_graph_create_filter() and/or corresponding options to set, so that filter input and output sides can be provided with correct info 2. query my sink for what it actually provides (a bunch more functions ala av_buffersink_get_format() are needed to get color_range, etc) I probably don't oversee the problem, so may be missing more that needs to be done, or be off the mark here. I also agree with Henrik that a way to query encoders for what they support besides formats is critical, and that this should ideally be context-senstive (so you can set certain options, and then query what remains of supported pix_fmts, color_range, etc). All the best, Dee ___ 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] lavc: convert frame threading to the receive_frame() pattern
From: Anton Khirnov
Reorganize the code such that the frame threading code does not call the
decoders directly, but instead calls back into the generic decoding
code. This avoids duplicating the logic that wraps the decoder
invocation and will be useful in the following commits.
---
libavcodec/decode.c| 58 +
libavcodec/decode.h| 7 +
libavcodec/internal.h | 7 +
libavcodec/pthread_frame.c | 256 -
libavcodec/thread.h| 18 +--
5 files changed, 223 insertions(+), 123 deletions(-)
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index b184c3f55b..f1be0d7876 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -180,6 +180,11 @@ fail:
return ret;
}
+#if !HAVE_THREADS
+#define ff_thread_get_packet(avctx, pkt) (AVERROR_BUG)
+#define ff_thread_receive_frame(avctx, frame) (AVERROR_BUG)
+#endif
+
int ff_decode_get_packet(AVCodecContext *avctx, AVPacket *pkt)
{
AVCodecInternal *avci = avctx->internal;
@@ -188,7 +193,14 @@ int ff_decode_get_packet(AVCodecContext *avctx, AVPacket
*pkt)
if (avci->draining)
return AVERROR_EOF;
-ret = av_bsf_receive_packet(avci->bsf, pkt);
+/* If we are a worker thread, get the next packet from the threading
+ * context. Otherwise we are the main (user-facing) context, so we get the
+ * next packet from the input filterchain.
+ */
+if (avctx->internal->is_frame_mt)
+ret = ff_thread_get_packet(avctx, pkt);
+else
+ret = av_bsf_receive_packet(avci->bsf, pkt);
if (ret == AVERROR_EOF)
avci->draining = 1;
if (ret < 0)
@@ -273,30 +285,25 @@ static inline int decode_simple_internal(AVCodecContext
*avctx, AVFrame *frame,
return AVERROR_EOF;
if (!pkt->data &&
-!(avctx->codec->capabilities & AV_CODEC_CAP_DELAY ||
- avctx->active_thread_type & FF_THREAD_FRAME))
+!(avctx->codec->capabilities & AV_CODEC_CAP_DELAY))
return AVERROR_EOF;
got_frame = 0;
-if (HAVE_THREADS && avctx->active_thread_type & FF_THREAD_FRAME) {
-ret = ff_thread_decode_frame(avctx, frame, _frame, pkt);
-} else {
-ret = codec->cb.decode(avctx, frame, _frame, pkt);
-
-if (!(codec->caps_internal & FF_CODEC_CAP_SETS_PKT_DTS))
-frame->pkt_dts = pkt->dts;
-if (avctx->codec->type == AVMEDIA_TYPE_VIDEO) {
-if(!avctx->has_b_frames)
-frame->pkt_pos = pkt->pos;
-//FIXME these should be under if(!avctx->has_b_frames)
-/* get_buffer is supposed to set frame parameters */
-if (!(avctx->codec->capabilities & AV_CODEC_CAP_DR1)) {
-if (!frame->sample_aspect_ratio.num)
frame->sample_aspect_ratio = avctx->sample_aspect_ratio;
-if (!frame->width)frame->width
= avctx->width;
-if (!frame->height) frame->height
= avctx->height;
-if (frame->format == AV_PIX_FMT_NONE) frame->format
= avctx->pix_fmt;
-}
+ret = codec->cb.decode(avctx, frame, _frame, pkt);
+
+if (!(codec->caps_internal & FF_CODEC_CAP_SETS_PKT_DTS))
+frame->pkt_dts = pkt->dts;
+if (avctx->codec->type == AVMEDIA_TYPE_VIDEO) {
+if(!avctx->has_b_frames)
+frame->pkt_pos = pkt->pos;
+//FIXME these should be under if(!avctx->has_b_frames)
+/* get_buffer is supposed to set frame parameters */
+if (!(avctx->codec->capabilities & AV_CODEC_CAP_DR1)) {
+if (!frame->sample_aspect_ratio.num) frame->sample_aspect_ratio =
avctx->sample_aspect_ratio;
+if (!frame->width)frame->width =
avctx->width;
+if (!frame->height) frame->height =
avctx->height;
+if (frame->format == AV_PIX_FMT_NONE) frame->format =
avctx->pix_fmt;
}
}
emms_c();
@@ -546,7 +553,7 @@ static int decode_simple_receive_frame(AVCodecContext
*avctx, AVFrame *frame)
return 0;
}
-static int decode_receive_frame_internal(AVCodecContext *avctx, AVFrame *frame)
+int ff_decode_receive_frame_internal(AVCodecContext *avctx, AVFrame *frame)
{
AVCodecInternal *avci = avctx->internal;
const FFCodec *const codec = ffcodec(avctx->codec);
@@ -604,6 +611,13 @@ FF_ENABLE_DEPRECATION_WARNINGS
return ret;
}
+static int decode_receive_frame_internal(AVCodecContext *avctx, AVFrame *frame)
+{
+if (avctx->active_thread_type & FF_THREAD_FRAME)
+return ff_thread_receive_frame(avctx, frame);
+return ff_decode_receive_frame_internal(avctx, frame);
+}
+
int attribute_align_arg avcodec_send_packet(AVCodecContext *avctx, const
AVPacket *avpkt)
{
AVCodecInternal *avci = avctx->internal;
diff --git a/libavcodec/decode.h b/libavcodec/decode.h
index 5d95369b5e..34beb70f97 100644
---
Re: [FFmpeg-devel] [PATCH v3] lavc: convert frame threading to the receive_frame() pattern
On 12/9/2022 10:09 AM, Timo Rothenpieler wrote:
On 07/12/2022 23:22, Michael Niedermayer wrote:
On Wed, Dec 07, 2022 at 02:20:23PM +0100, Timo Rothenpieler wrote:
From: Anton Khirnov
Reorganize the code such that the frame threading code does not call the
decoders directly, but instead calls back into the generic decoding
code. This avoids duplicating the logic that wraps the decoder
invocation and will be useful in the following commits.
---
libavcodec/decode.c | 57 +
libavcodec/decode.h | 7 +
libavcodec/internal.h | 7 +
libavcodec/pthread_frame.c | 256 -
libavcodec/thread.h | 18 +--
5 files changed, 222 insertions(+), 123 deletions(-)
This breaks on arm (probably lack of pthread support) in this env
libavcodec/libavcodec.a(decode.o): In function
`decode_receive_frame_internal':
arm/src/libavcodec/decode.c:616: undefined reference to
`ff_thread_receive_frame'
arm/src/libavcodec/decode.c:616: undefined reference to
`ff_thread_receive_frame'
collect2: error: ld returned 1 exit status
Makefile:131: recipe for target 'ffprobe_g' failed
make: *** [ffprobe_g] Error 1
Probably just missing an #if somewhere.
Yes.
+static int decode_receive_frame_internal(AVCodecContext *avctx, AVFrame *frame)
+{
+if (avctx->active_thread_type & FF_THREAD_FRAME)
Should be if (HAVE_THREADS && ...
+return ff_thread_receive_frame(avctx, frame);
+return ff_decode_receive_frame_internal(avctx, frame);
+}
___
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] lavc: convert frame threading to the receive_frame() pattern
On 07/12/2022 23:22, Michael Niedermayer wrote: On Wed, Dec 07, 2022 at 02:20:23PM +0100, Timo Rothenpieler wrote: From: Anton Khirnov Reorganize the code such that the frame threading code does not call the decoders directly, but instead calls back into the generic decoding code. This avoids duplicating the logic that wraps the decoder invocation and will be useful in the following commits. --- libavcodec/decode.c| 57 + libavcodec/decode.h| 7 + libavcodec/internal.h | 7 + libavcodec/pthread_frame.c | 256 - libavcodec/thread.h| 18 +-- 5 files changed, 222 insertions(+), 123 deletions(-) This breaks on arm (probably lack of pthread support) in this env libavcodec/libavcodec.a(decode.o): In function `decode_receive_frame_internal': arm/src/libavcodec/decode.c:616: undefined reference to `ff_thread_receive_frame' arm/src/libavcodec/decode.c:616: undefined reference to `ff_thread_receive_frame' collect2: error: ld returned 1 exit status Makefile:131: recipe for target 'ffprobe_g' failed make: *** [ffprobe_g] Error 1 Probably just missing an #if somewhere. Why does arm not support pthreads though? Or is that just this specific configuration? ___ 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] Towards YUVJ removal
On Fri, Dec 9, 2022 at 12:49 PM Niklas Haas wrote: > > So, as was discussed at the last meeting, we should move towards > removing YUVJ. I want to gather feedback on what appears to be to the > major hurdle, and possible ways to solve it. > > The basic major issue is how to handle the case of combining limited > range input with an encoder for a format that only accepts full range > data. The common case, for example, would be converting a frame from a > typical video file to a JPEG: > > $ ffmpeg -f lavfi -i smptebars -vframes 1 output.jpg > > Currently, this works because the JPEG encoder only advertises YUVJ > pixel formats, and therefore ffmpeg auto-inserts swscaler to convert > from limited range to full range. But this depends on conflating color > range and pixel formats, which is exactly what has been marked > deprecated for an eternity. > > Now, there are some solutions I can see for how to handle this case in > a non-YUVJ world: > > 1. Simply output an error, and rely on the user to insert a conversion >filter, e.g.: > >$ ffmpeg -f lavfi -i smptebars -vframes 1 output.jpg >error: inputs to jpeg encoder must be full range > >$ ffmpeg -f lavfi -i smptebars -vframes 1 -vf scale=out_range=jpeg > output.jpg >... works > > 2. Have the JPEG encoder take care of range conversion internally, by >using sws to convert limited to full range. > > 3. Allow filters to start exposing color space metadata as part of >filter negotiation, and then auto-insert swscaler whenever colorspace >conversion needs to happen as a result of filters not accepting the >corresponding color metadata. This would also allow more than just >conversion between limited/full range. > > 4. Combine approach 1 with an encoder flag for "supports full range >only", and have ffmpeg.c auto-insert a scale filter as the last step >before the encoder if this flag is set (and input is limited range). > > 1 would be the most explicit but would break any existing pipeline that > includes conversion to jpeg, which is probably a very large number. > > 2 would be the least work, but violates abstraction boundaries. > > 3 would be the most work and is, IMO, of questionable gain. > > 4 would be both explicit and not break existing workflows. > Some sort of metadata has to be present to indicate this. It is not reasonable to assume users magically know what range a codec accepts, and then go out of their way to hardcode a list that might need full range. So 1 alone is entirely not reasonable, especially if you think eg. about an API user, who might create an app that may not show the immediate error message, or even have a button to insert a scaler. Instead the API should contain all the information for an application to make the right choices if necessary. Of course I already see people argue that JPEG accepts both depending on standards compliance etc, but the metadata should allow me to make the encoder work without needing to set standard compliance to some value. Or in other words, it should just work the most straight-forward way, without needing special knowledge about the encoder or even format. For mjpegenc this probably means it should only advertise full range. Or this information needs to somehow be context-sensitive and allow me to indicate the standards compliance value I care for. If the encoder indicates both limited and full, but errors out on limited, thats not useful. - 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".
Re: [FFmpeg-devel] Towards YUVJ removal
On 12/9/22, Niklas Haas wrote:
> On Fri, 09 Dec 2022 13:10:02 +0100 Andreas Rheinhardt
> wrote:
>> This is incorrect: Here are the pixel formats advertised by the mjpeg
>> encoder:
>>
>> .p.pix_fmts = (const enum AVPixelFormat[]) {
>> 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
>> },
>>
>> ffmpeg only inserts the swscale filters, because said list is overridden
>> in get_compliance_normal_pix_fmts() in fftools/ffmpeg_filter.c. See
>> 059fc2d9da5364627613fb3e6424079e14dbdfd3.
>> Also notice that the encoder errors out if fed with limited range data
>> depending upon strict_std_compliance (see
>> ff_mjpeg_encode_check_pix_fmt()), which is very similar to the first
>> approach below; the override being in fftools implies that the breakage
>> of the first approach would be confined to users of fftools.
>
> Oh, you are right. So that presents an alternative to 4 - rather than an
> encoder flag, we can tie the auto-conversion in fftools to be tied to
> the strict_std_compliance check.
>
> I will try implementing this approach, it may be the best compromise in
> that it presents a clear upgrade path that doesn't break the common
> case.
>
> That said, there still is an encoder that has this problem: "amv".
> Currently, this only advertises YUVJ, but after YUVJ removal, it would
> be treated equivalently to mjpeg when `strict_std_compliance` is enabled.
>
> But given that this is a less common format, I think, such a regression
> would not be as big a concern. (And we can still special-case it in
> fftools, if we want to)
Sounds too much hackish.
___
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] Towards YUVJ removal
On Fri, 09 Dec 2022 13:10:02 +0100 Andreas Rheinhardt
wrote:
> This is incorrect: Here are the pixel formats advertised by the mjpeg
> encoder:
>
> .p.pix_fmts = (const enum AVPixelFormat[]) {
> 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
> },
>
> ffmpeg only inserts the swscale filters, because said list is overridden
> in get_compliance_normal_pix_fmts() in fftools/ffmpeg_filter.c. See
> 059fc2d9da5364627613fb3e6424079e14dbdfd3.
> Also notice that the encoder errors out if fed with limited range data
> depending upon strict_std_compliance (see
> ff_mjpeg_encode_check_pix_fmt()), which is very similar to the first
> approach below; the override being in fftools implies that the breakage
> of the first approach would be confined to users of fftools.
Oh, you are right. So that presents an alternative to 4 - rather than an
encoder flag, we can tie the auto-conversion in fftools to be tied to
the strict_std_compliance check.
I will try implementing this approach, it may be the best compromise in
that it presents a clear upgrade path that doesn't break the common
case.
That said, there still is an encoder that has this problem: "amv".
Currently, this only advertises YUVJ, but after YUVJ removal, it would
be treated equivalently to mjpeg when `strict_std_compliance` is enabled.
But given that this is a less common format, I think, such a regression
would not be as big a concern. (And we can still special-case it in
fftools, if we want to)
___
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] Towards YUVJ removal
3. :) On Fri, 9 Dec 2022, at 12:49, Niklas Haas wrote: > So, as was discussed at the last meeting, we should move towards > removing YUVJ. I want to gather feedback on what appears to be to the > major hurdle, and possible ways to solve it. > > The basic major issue is how to handle the case of combining limited > range input with an encoder for a format that only accepts full range > data. The common case, for example, would be converting a frame from a > typical video file to a JPEG: > > $ ffmpeg -f lavfi -i smptebars -vframes 1 output.jpg > > Currently, this works because the JPEG encoder only advertises YUVJ > pixel formats, and therefore ffmpeg auto-inserts swscaler to convert > from limited range to full range. But this depends on conflating color > range and pixel formats, which is exactly what has been marked > deprecated for an eternity. > > Now, there are some solutions I can see for how to handle this case in > a non-YUVJ world: > > 1. Simply output an error, and rely on the user to insert a conversion >filter, e.g.: > >$ ffmpeg -f lavfi -i smptebars -vframes 1 output.jpg >error: inputs to jpeg encoder must be full range > >$ ffmpeg -f lavfi -i smptebars -vframes 1 -vf scale=out_range=jpeg > output.jpg >... works > > 2. Have the JPEG encoder take care of range conversion internally, by >using sws to convert limited to full range. > > 3. Allow filters to start exposing color space metadata as part of >filter negotiation, and then auto-insert swscaler whenever colorspace >conversion needs to happen as a result of filters not accepting the >corresponding color metadata. This would also allow more than just >conversion between limited/full range. > > 4. Combine approach 1 with an encoder flag for "supports full range >only", and have ffmpeg.c auto-insert a scale filter as the last step >before the encoder if this flag is set (and input is limited range). > > 1 would be the most explicit but would break any existing pipeline that > includes conversion to jpeg, which is probably a very large number. > > 2 would be the least work, but violates abstraction boundaries. > > 3 would be the most work and is, IMO, of questionable gain. > > 4 would be both explicit and not break existing workflows. > > Thoughts? > ___ > 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". -- Jean-Baptiste Kempf - President +33 672 704 734 ___ 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] Towards YUVJ removal
So, as was discussed at the last meeting, we should move towards removing YUVJ. I want to gather feedback on what appears to be to the major hurdle, and possible ways to solve it. The basic major issue is how to handle the case of combining limited range input with an encoder for a format that only accepts full range data. The common case, for example, would be converting a frame from a typical video file to a JPEG: $ ffmpeg -f lavfi -i smptebars -vframes 1 output.jpg Currently, this works because the JPEG encoder only advertises YUVJ pixel formats, and therefore ffmpeg auto-inserts swscaler to convert from limited range to full range. But this depends on conflating color range and pixel formats, which is exactly what has been marked deprecated for an eternity. Now, there are some solutions I can see for how to handle this case in a non-YUVJ world: 1. Simply output an error, and rely on the user to insert a conversion filter, e.g.: $ ffmpeg -f lavfi -i smptebars -vframes 1 output.jpg error: inputs to jpeg encoder must be full range $ ffmpeg -f lavfi -i smptebars -vframes 1 -vf scale=out_range=jpeg output.jpg ... works 2. Have the JPEG encoder take care of range conversion internally, by using sws to convert limited to full range. 3. Allow filters to start exposing color space metadata as part of filter negotiation, and then auto-insert swscaler whenever colorspace conversion needs to happen as a result of filters not accepting the corresponding color metadata. This would also allow more than just conversion between limited/full range. 4. Combine approach 1 with an encoder flag for "supports full range only", and have ffmpeg.c auto-insert a scale filter as the last step before the encoder if this flag is set (and input is limited range). 1 would be the most explicit but would break any existing pipeline that includes conversion to jpeg, which is probably a very large number. 2 would be the least work, but violates abstraction boundaries. 3 would be the most work and is, IMO, of questionable gain. 4 would be both explicit and not break existing workflows. Thoughts? ___ 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 3/7] avcodec/mediacodecenc: use bsf to handle crop
From: Zhao Zhili
It's well known that mediacodec encoder requires 16x16 alignment.
Use our bsf to fix the crop info.
---
v3: don't change the dimension for AV_PIX_FMT_MEDIACODEC. It can have
side effect.
configure | 2 +
libavcodec/mediacodecenc.c | 78 +++---
2 files changed, 75 insertions(+), 5 deletions(-)
diff --git a/configure b/configure
index f4eedfc207..2180ebb4f1 100755
--- a/configure
+++ b/configure
@@ -3169,6 +3169,7 @@ h264_mediacodec_decoder_extralibs="-landroid"
h264_mediacodec_decoder_select="h264_mp4toannexb_bsf h264_parser"
h264_mediacodec_encoder_deps="mediacodec"
h264_mediacodec_encoder_extralibs="-landroid"
+h264_mediacodec_encoder_select="h264_metadata"
h264_mf_encoder_deps="mediafoundation"
h264_mmal_decoder_deps="mmal"
h264_nvenc_encoder_deps="nvenc"
@@ -3190,6 +3191,7 @@ hevc_mediacodec_decoder_extralibs="-landroid"
hevc_mediacodec_decoder_select="hevc_mp4toannexb_bsf hevc_parser"
hevc_mediacodec_encoder_deps="mediacodec"
hevc_mediacodec_encoder_extralibs="-landroid"
+hevc_mediacodec_encoder_select="hevc_metadata"
hevc_mf_encoder_deps="mediafoundation"
hevc_nvenc_encoder_deps="nvenc"
hevc_nvenc_encoder_select="atsc_a53"
diff --git a/libavcodec/mediacodecenc.c b/libavcodec/mediacodecenc.c
index 2f78567451..4e8716e3a5 100644
--- a/libavcodec/mediacodecenc.c
+++ b/libavcodec/mediacodecenc.c
@@ -28,6 +28,7 @@
#include "libavutil/opt.h"
#include "avcodec.h"
+#include "bsf.h"
#include "codec_internal.h"
#include "encode.h"
#include "hwconfig.h"
@@ -78,6 +79,7 @@ typedef struct MediaCodecEncContext {
int eof_sent;
AVFrame *frame;
+AVBSFContext *bsf;
int bitrate_mode;
int level;
@@ -119,6 +121,42 @@ static void mediacodec_output_format(AVCodecContext *avctx)
ff_AMediaFormat_delete(out_format);
}
+static int mediacodec_init_bsf(AVCodecContext *avctx)
+{
+MediaCodecEncContext *s = avctx->priv_data;
+char str[128];
+int ret;
+int crop_right = s->width - avctx->width;
+int crop_bottom = s->height - avctx->height;
+
+if (!crop_right && !crop_bottom)
+return 0;
+
+if (avctx->codec_id == AV_CODEC_ID_H264)
+ret = snprintf(str, sizeof(str),
"h264_metadata=crop_right=%d:crop_bottom=%d",
+ crop_right, crop_bottom);
+else if (avctx->codec_id == AV_CODEC_ID_HEVC)
+ret = snprintf(str, sizeof(str),
"hevc_metadata=crop_right=%d:crop_bottom=%d",
+ crop_right, crop_bottom);
+else
+return 0;
+
+if (ret >= sizeof(str))
+return AVERROR_BUFFER_TOO_SMALL;
+
+ret = av_bsf_list_parse_str(str, >bsf);
+if (ret < 0)
+return ret;
+
+ret = avcodec_parameters_from_context(s->bsf->par_in, avctx);
+if (ret < 0)
+return ret;
+s->bsf->time_base_in = avctx->time_base;
+ret = av_bsf_init(s->bsf);
+
+return ret;
+}
+
static av_cold int mediacodec_init(AVCodecContext *avctx)
{
const char *codec_mime = NULL;
@@ -158,8 +196,19 @@ static av_cold int mediacodec_init(AVCodecContext *avctx)
}
ff_AMediaFormat_setString(format, "mime", codec_mime);
-s->width = FFALIGN(avctx->width, 16);
-s->height = avctx->height;
+// Workaround the alignment requirement of mediacodec. We can't do it
+// silently for AV_PIX_FMT_MEDIACODEC.
+if (avctx->pix_fmt != AV_PIX_FMT_MEDIACODEC) {
+s->width = FFALIGN(avctx->width, 16);
+s->height = FFALIGN(avctx->height, 16);
+} else {
+s->width = avctx->width;
+s->height = avctx->height;
+if (s->width % 16 || s->height % 16)
+av_log(avctx, AV_LOG_WARNING,
+"Video size %dx%d isn't align to 16, it may have device
compatibility issue\n",
+s->width, s->height);
+}
ff_AMediaFormat_setInt32(format, "width", s->width);
ff_AMediaFormat_setInt32(format, "height", s->height);
@@ -252,6 +301,10 @@ static av_cold int mediacodec_init(AVCodecContext *avctx)
goto bailout;
}
+ret = mediacodec_init_bsf(avctx);
+if (ret)
+goto bailout;
+
mediacodec_output_format(avctx);
s->frame = av_frame_alloc();
@@ -444,10 +497,24 @@ static int mediacodec_encode(AVCodecContext *avctx,
AVPacket *pkt)
// 2. Got a packet success
// 3. No AVFrame is available yet (don't return if get_frame return EOF)
while (1) {
+if (s->bsf) {
+ret = av_bsf_receive_packet(s->bsf, pkt);
+if (!ret)
+return 0;
+if (ret != AVERROR(EAGAIN))
+return ret;
+}
+
ret = mediacodec_receive(avctx, pkt, _packet);
-if (!ret)
-return 0;
-else if (ret != AVERROR(EAGAIN))
+if (s->bsf) {
+if (!ret || ret == AVERROR_EOF)
+ret = av_bsf_send_packet(s->bsf, pkt);
+} else {
+if (!ret)
+return 0;
+}
+
+if (ret
