Re: [FFmpeg-devel] [PATCH v2 1/2] doc/examples/transcode_aac: Don't ignore last encoded frame
Am 22.03.2022 um 18:47 schrieb Andreas Unterweger:
The last encoded frame is now fetched on EOF. It was previously left in the encoder and
caused a "1 frame left in queue" warning.
Signed-off-by: Andreas Unterweger
---
doc/examples/transcode_aac.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/doc/examples/transcode_aac.c b/doc/examples/transcode_aac.c
index 9102e55f16..c9b93f6439 100644
--- a/doc/examples/transcode_aac.c
+++ b/doc/examples/transcode_aac.c
@@ -377,6 +377,8 @@ static int decode_audio_frame(AVFrame *frame,
if (error < 0)
return error;
+ *data_present = 0;
+ *finished = 0;
/* Read one audio frame from the input file into a temporary packet. */
if ((error = av_read_frame(input_format_context, input_packet)) < 0) {
/* If we are at the end of the file, flush the decoder below. */
@@ -555,7 +557,7 @@ static int read_decode_convert_and_store(AVAudioFifo *fifo,
AVFrame *input_frame = NULL;
/* Temporary storage for the converted input samples. */
uint8_t **converted_input_samples = NULL;
- int data_present = 0;
+ int data_present;
int ret = AVERROR_EXIT;
/* Initialize temporary storage for one input frame. */
@@ -675,18 +677,17 @@ static int encode_audio_frame(AVFrame *frame,
frame->pts = pts;
pts += frame->nb_samples;
}
-
+
+ *data_present = 0;
/* Send the audio frame stored in the temporary packet to the encoder.
* The output audio stream encoder is used to do this. */
error = avcodec_send_frame(output_codec_context, frame);
- /* The encoder signals that it has nothing more to encode. */
- if (error == AVERROR_EOF) {
- error = 0;
- goto cleanup;
- } else if (error < 0) {
- fprintf(stderr, "Could not send packet for encoding (error '%s')\n",
- av_err2str(error));
- goto cleanup;
+ /* Check for errors, but proceed with fetching encoded samples if the
+ * encoder signals that it has nothing more to encode. */
+ if (error < 0 && error != AVERROR_EOF) {
+ fprintf(stderr, "Could not send packet for encoding (error '%s')\n",
+ av_err2str(error));
+ goto cleanup;
}
/* Receive one encoded frame from the encoder. */
@@ -857,7 +858,6 @@ int main(int argc, char **argv)
int data_written;
/* Flush the encoder as it may have delayed frames. */
do {
- data_written = 0;
if (encode_audio_frame(NULL, output_format_context,
output_codec_context, _written))
goto cleanup;
Ping.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/1] librtmp: make flashVer case consistent
This is basically a cosmetic change (no functional difference).
---
libavformat/librtmp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/librtmp.c b/libavformat/librtmp.c
index 43013e46e0..b23adb9593 100644
--- a/libavformat/librtmp.c
+++ b/libavformat/librtmp.c
@@ -115,7 +115,7 @@ static int rtmp_open(URLContext *s, const char *uri, int
flags)
if (ctx->app) len += strlen(ctx->app) + sizeof(" app=");
if (ctx->tcurl)len += strlen(ctx->tcurl)+ sizeof(" tcUrl=");
if (ctx->pageurl) len += strlen(ctx->pageurl) + sizeof(" pageUrl=");
-if (ctx->flashver) len += strlen(ctx->flashver) + sizeof(" flashver=");
+if (ctx->flashver) len += strlen(ctx->flashver) + sizeof(" flashVer=");
if (ctx->conn) {
char *sep, *p = ctx->conn;
--
2.32.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 v7 09/10] qsv: use a new method to create mfx session when using oneVPL
On Mon, 2022-04-04 at 11:46 +0200, Hendrik Leppkes wrote:
> On Tue, Mar 15, 2022 at 8:24 AM Xiang, Haihao
> wrote:
> >
> > On Fri, 2022-03-11 at 15:00 +0100, Hendrik Leppkes wrote:
> > > On Fri, Mar 11, 2022 at 2:43 PM Xiang, Haihao
> > > wrote:
> > > >
> > > > On Fri, 2022-03-11 at 09:35 +0100, Hendrik Leppkes wrote:
> > > > > On Fri, Mar 11, 2022 at 9:18 AM Xiang, Haihao
> > > > > wrote:
> > > > > > diff --git a/libavutil/hwcontext_d3d11va.c
> > > > > > b/libavutil/hwcontext_d3d11va.c
> > > > > > index 8ab96bad25..e0e820f164 100644
> > > > > > --- a/libavutil/hwcontext_d3d11va.c
> > > > > > +++ b/libavutil/hwcontext_d3d11va.c
> > > > > > @@ -525,6 +525,13 @@ static void
> > > > > > d3d11va_device_uninit(AVHWDeviceContext
> > > > > > *hwdev)
> > > > > > }
> > > > > > }
> > > > > >
> > > > > > +static void d3d11va_device_free(AVHWDeviceContext *ctx)
> > > > > > +{
> > > > > > +AVD3D11VADeviceContext *hwctx = ctx->hwctx;
> > > > > > +
> > > > > > +av_free(hwctx->device_name);
> > > > > > +}
> > > > > > +
> > > > > > static int d3d11va_device_create(AVHWDeviceContext *ctx, const char
> > > > > > *device,
> > > > > > AVDictionary *opts, int flags)
> > > > > > {
> > > > > > @@ -537,6 +544,8 @@ static int
> > > > > > d3d11va_device_create(AVHWDeviceContext
> > > > > > *ctx,
> > > > > > const char *device,
> > > > > > int is_debug = !!av_dict_get(opts, "debug", NULL, 0);
> > > > > > int ret;
> > > > > >
> > > > > > +ctx->free = d3d11va_device_free;
> > > > > > +
> > > > > > // (On UWP we can't check this.)
> > > > > > #if !HAVE_UWP
> > > > > > if (!LoadLibrary("d3d11_1sdklayers.dll"))
> > > > > > @@ -561,6 +570,10 @@ static int
> > > > > > d3d11va_device_create(AVHWDeviceContext
> > > > > > *ctx, const char *device,
> > > > > > if (FAILED(IDXGIFactory2_EnumAdapters(pDXGIFactory,
> > > > > > adapter,
> > > > > > )))
> > > > > > pAdapter = NULL;
> > > > > > IDXGIFactory2_Release(pDXGIFactory);
> > > > > > +
> > > > > > +device_hwctx->device_name = av_strdup(device);
> > > > > > +if (!device_hwctx->device_name)
> > > > > > +return AVERROR(ENOMEM);
> > > > > > }
> > > > > > }
> > > > > >
> > > > > > diff --git a/libavutil/hwcontext_d3d11va.h
> > > > > > b/libavutil/hwcontext_d3d11va.h
> > > > > > index 77d2d72f1b..41a315b9e6 100644
> > > > > > --- a/libavutil/hwcontext_d3d11va.h
> > > > > > +++ b/libavutil/hwcontext_d3d11va.h
> > > > > > @@ -94,6 +94,11 @@ typedef struct AVD3D11VADeviceContext {
> > > > > > void (*lock)(void *lock_ctx);
> > > > > > void (*unlock)(void *lock_ctx);
> > > > > > void *lock_ctx;
> > > > > > +
> > > > > > +/**
> > > > > > + * The string for the used adapter
> > > > > > + */
> > > > > > +char *device_name;
> > > > > > } AVD3D11VADeviceContext;
> > > > > >
> > > > > > /**
> > > > > > diff --git a/libavutil/hwcontext_dxva2.c
> > > > > > b/libavutil/hwcontext_dxva2.c
> > > > > > index 53d00fa815..6967357093 100644
> > > > > > --- a/libavutil/hwcontext_dxva2.c
> > > > > > +++ b/libavutil/hwcontext_dxva2.c
> > > > > > @@ -431,6 +431,7 @@ static void dxva2_device_free(AVHWDeviceContext
> > > > > > *ctx)
> > > > > > dlclose(priv->dxva2lib);
> > > > > >
> > > > > > av_freep(>user_opaque);
> > > > > > +av_free(hwctx->device_name);
> > > > > > }
> > > > > >
> > > > > > static int dxva2_device_create9(AVHWDeviceContext *ctx, UINT
> > > > > > adapter)
> > > > > > @@ -571,6 +572,13 @@ static int
> > > > > > dxva2_device_create(AVHWDeviceContext
> > > > > > *ctx,
> > > > > > const char *device,
> > > > > > return AVERROR_UNKNOWN;
> > > > > > }
> > > > > >
> > > > > > +if (device) {
> > > > > > +hwctx->device_name = av_strdup(device);
> > > > > > +
> > > > > > +if (!hwctx->device_name)
> > > > > > +return AVERROR(ENOMEM);
> > > > > > +}
> > > > > > +
> > > > > > return 0;
> > > > > > }
> > > > > >
> > > > > > diff --git a/libavutil/hwcontext_dxva2.h
> > > > > > b/libavutil/hwcontext_dxva2.h
> > > > > > index e1b79bc0de..253ddbed51 100644
> > > > > > --- a/libavutil/hwcontext_dxva2.h
> > > > > > +++ b/libavutil/hwcontext_dxva2.h
> > > > > > @@ -38,6 +38,10 @@
> > > > > > */
> > > > > > typedef struct AVDXVA2DeviceContext {
> > > > > > IDirect3DDeviceManager9 *devmgr;
> > > > > > +/**
> > > > > > + * The string for the used adapter
> > > > > > + */
> > > > > > +char *device_name;
> > > > > > } AVDXVA2DeviceContext;
> > > > > >
> > > > > > /**
> > > > >
> > > > > Why are these device names required? I would think deriving a child
> > > > > device would use the actual device, eg. ID3D11Device or
> > > > > IDirect3DDeviceManager9 (and whatever for VAAPI), and not some string
> > > > > (that may or may not even be set).
> > > > > It feels quite a bit icky to store these in the context
Re: [FFmpeg-devel] [PATCH v7 05/10] qsv: build audio related code when MFX_VERSION < 2.0
On Tue, 2022-04-05 at 13:50 +0200, Anton Khirnov wrote: > Quoting Xiang, Haihao (2022-03-11 09:16:25) > > From: Haihao Xiang > > > > Audio isn't supported for MFX_VERSION >= 2.0[1][2]. This is in > > preparation for oneVPL support > > > > [1]: > > https://spec.oneapi.io/versions/latest/elements/oneVPL/source/VPL_intel_media_sdk.html#msdk-full-name-feature-removals > > [2]: https://github.com/oneapi-src/oneVPL > > --- > > libavcodec/qsv.c | 5 + > > libavfilter/qsvvpp.c | 6 ++ > > libavfilter/qsvvpp.h | 2 ++ > > 3 files changed, 13 insertions(+) > > Why not just remove this completely? > None of our QSV code does anything with audio. It was removed in an older version, however someone objected the removal of this. See https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200819061023.443304-2-haihao.xi...@intel.com/ Thanks Haihao ___ 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 v12 1/1] avformat: Add IPFS protocol support.
> On Apr 6, 2022, at 5:34 AM, Mark Gaiser wrote:
>
> On Tue, Apr 5, 2022 at 11:27 PM Mark Gaiser wrote:
>
>>
>>
>> On Tue, Apr 5, 2022 at 11:01 PM Michael Niedermayer <
>> mich...@niedermayer.cc> wrote:
>>
>>> On Mon, Apr 04, 2022 at 12:38:25AM +0200, Mark Gaiser wrote:
This patch adds support for:
- ffplay ipfs://
- ffplay ipns://
IPFS data can be played from so called "ipfs gateways".
A gateway is essentially a webserver that gives access to the
distributed IPFS network.
This protocol support (ipfs and ipns) therefore translates
ipfs:// and ipns:// to a http:// url. This resulting url is
then handled by the http protocol. It could also be https
depending on the gateway provided.
To use this protocol, a gateway must be provided.
If you do nothing it will try to find it in your
$HOME/.ipfs/gateway file. The ways to set it manually are:
1. Define a -gateway to the gateway.
2. Define $IPFS_GATEWAY with the full http link to the gateway.
3. Define $IPFS_PATH and point it to the IPFS data path.
4. Have IPFS running in your local user folder (under $HOME/.ipfs).
>>> [...]
>>>
+goto err;
+}
+
+// Read a single line (fgets stops at new line mark).
+if (!fgets(c->gateway_buffer, sizeof(c->gateway_buffer) - 1,
>>> gateway_file)) {
+ av_log(h, AV_LOG_WARNING, "Unable to read from file (full uri:
>>> %s).\n",
+ ipfs_gateway_file);
+ ret = AVERROR(ENOENT);
+ goto err;
+}
>>>
>>> The indention is not consistent
>>>
>>
>> What's the intended indentation here?
>> In my editor (QtCreator, it's set to 2 spaces for tabs) the
>> "ipfs_gateway_file" is aligned directly underneath the first argument of
>> av_log.
>> That is as it should be, right?
>>
>> For this and your other comments, I see no issue on my side. Also no
>> trailing whitespace.
>>
>> Here's an image of what i see with spaces visualizes:
>> https://i.imgur.com/37k68RH.png
>> Is there something wrong on my end?
>>
>
> Just checked patchwork:
> https://patchwork.ffmpeg.org/project/ffmpeg/patch/20220403223825.26764-2-mark...@gmail.com/
> It also shows the indentation as I intended which should be according to
> the ffmpeg coding style guidelines.
Indent size is 4. I use git log -p to do one more check before sending
patches.
>
> Same with:
> https://ffmpeg.org/pipermail/ffmpeg-devel/2022-April/294932.html
>
>
>>
>>
>>>
>>>
>>> [...]
+// Populate c->gateway_buffer with whatever is in c->gateway
+if (c->gateway != NULL) {
+if (snprintf(c->gateway_buffer, sizeof(c->gateway_buffer),
>>> "%s",
+ c->gateway) >= sizeof(c->gateway_buffer)) {
+av_log(h, AV_LOG_WARNING, "The -gateway parameter is too
>>> long. "
+ "We allow a max of %zu
>>> characters\n",
+ sizeof(c->gateway_buffer));
+ret = AVERROR(EINVAL);
+goto err;
+}
+} else {
+// Populate the IPFS gateway if we have any.
+// If not, inform the user how to properly set one.
+ret = populate_ipfs_gateway(h);
+
+if (ret < 1) {
+// We fallback on dweb.link (managed by Protocol Labs).
+snprintf(c->gateway_buffer, sizeof(c->gateway_buffer), "
>>> https://dweb.link;);
+
+av_log(h, AV_LOG_WARNING, "IPFS does not appear to be
>>> running. "
+ "You’re now using the public
>>> gateway at dweb.link.\n");
+av_log(h, AV_LOG_INFO, "Installing IPFS locally is
>>> recommended to "
+ "improve performance and
>>> reliability, "
+ "and not share all your activity
>>> with a single IPFS gateway.\n"
+ "There are multiple options to define this
>>> gateway.\n"
+ "1. Call ffmpeg with a gateway param, "
+ "without a trailing slash: -gateway
>>> .\n"
+ "2. Define an $IPFS_GATEWAY environment variable
>>> with the "
+ "full HTTP URL to the gateway "
+ "without trailing forward slash.\n"
+ "3. Define an $IPFS_PATH environment variable "
+ "and point it to the IPFS data path
>>> "
+ "- this is typically ~/.ipfs\n");
+}
+}
>>>
>>> This will print the warning every time a ipfs url is opened. Not just once
>>> is that intended ?
>>>
>>
>> Yes.
>>
>> Or rather, I don't see how to make it persistent in a nice intuitive way.
>> By nice intuitive I mean showing it for, lets say,
Re: [FFmpeg-devel] [PATCH] avcodec/ituh263enc: Add AV_CODEC_CAP_SLICE_THREADS to old H.263
Michael Niedermayer:
> On Tue, Apr 05, 2022 at 05:07:22PM +0200, Andreas Rheinhardt wrote:
>> Michael Niedermayer:
>>> It is supported by the H.263+ AVCodec already
>>>
>>> Is there any case where this does not work ?
>>>
>>> Fixes regression of some command lines
>>>
>>> Signed-off-by: Michael Niedermayer
>>> ---
>>> libavcodec/ituh263enc.c | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/libavcodec/ituh263enc.c b/libavcodec/ituh263enc.c
>>> index db7cdf1fcb..82dce05e36 100644
>>> --- a/libavcodec/ituh263enc.c
>>> +++ b/libavcodec/ituh263enc.c
>>> @@ -908,6 +908,7 @@ const FFCodec ff_h263_encoder = {
>>> .p.id = AV_CODEC_ID_H263,
>>> .p.pix_fmts = (const enum AVPixelFormat[]){AV_PIX_FMT_YUV420P,
>>> AV_PIX_FMT_NONE},
>>> .p.priv_class = _class,
>>> +.p.capabilities = AV_CODEC_CAP_SLICE_THREADS,
>>> .caps_internal = FF_CODEC_CAP_INIT_THREADSAFE |
>>> FF_CODEC_CAP_INIT_CLEANUP,
>>> .priv_data_size = sizeof(MpegEncContext),
>>> .init = ff_mpv_encode_init,
>>
>> 1. If you claim that there is a regression, you should mention the
>> commit that introduced them in the commit message (it's obviously
>> 8ca4b515e73079cda068e253853654db394b8171 in this case).
>> 2. What command lines regressed exactly? The only command lines that
>> should be affected by said commit are command lines that set the slices
>> option to a value > 1.
>> 3. As the commit message of 8ca4b515e73079cda068e253853654db394b8171
>> explains, this was intentional, as the H.263 encoder produces broken
>> files with multiple slices (whether with slice-threading or not). One
>> gets all kinds of error messages when decoding such a file: "I cbpy
>> damaged at 1 7", "Error at MB: 316", "illegal ac vlc code at 0x29",
>> "slice end not reached but screenspace end (7 left 80, score=
>> -125)", "run overflow at 0x7 i:1". Of course, there are visual
>> artifacts, too.
>> 4. With this patch, this encoder will by default (at least, by the
>> defaults of the ffmpeg command line tool) produce broken files.
>> 5. "Is there any case where this does not work ?": Is there any where it
>> works?
>
> The testcases i had where these:
> ./ffmpeg -threads 1 -i fate-suite/svq3/Vertical400kbit.sorenson3.mov -t 1
> -bitexact -qscale 2 -slices 1 -y -threads 1 -vcodec h263 -s 352x288 -an
> /tmp/file-h263-s1t1.h263
> ./ffmpeg -threads 1 -i fate-suite/svq3/Vertical400kbit.sorenson3.mov -t 1
> -bitexact -qscale 2 -slices 2 -y -threads 1 -vcodec h263 -s 352x288 -an
> /tmp/file-h263-s2t1.h263
> ./ffmpeg -threads 1 -i fate-suite/svq3/Vertical400kbit.sorenson3.mov -t 1
> -bitexact -qscale 2 -slices 1 -y -threads 2 -vcodec h263 -s 352x288 -an
> /tmp/file-h263-s1t2.h263
> ./ffmpeg -threads 1 -i fate-suite/svq3/Vertical400kbit.sorenson3.mov -t 1
> -bitexact -qscale 2 -slices 2 -y -threads 2 -vcodec h263 -s 352x288 -an
> /tmp/file-h263-s2t2.h263
>
> The files seem to play fine
> i did not try to find a case that fails
>
./ffmpeg -threads 1 -i fate-suite/svq3/Vertical400kbit.sorenson3.mov -t
1 -bitexact -qscale 2 -slices 4 -y -threads 4 -vcodec h263 -s 1408x1152
-an /tmp/file-h263-s2t2.h263
produces garbage; also with -s 704x576. slices < 4 seem fine. If one
uses too many slices with smaller resolutions, the file is no longer
correctly probed, but can be correctly decoded with -f h263.
I don't know what is wrong with the bigger resolutions and too many
slices; I don't know H.263 at all. My first (and admittedly only) test
for whether using multiple slices with a single thread works produced
garbage, so I put this codec in the "multiple slices not supported" box.
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/libvpxenc: enable dynamic max quantizer parameter reconfiguration
On Thu, Mar 31, 2022 at 10:31 AM James Zern wrote: > > On Wed, Mar 30, 2022 at 11:25 AM Danil Chapovalov > wrote: > > > > --- > > doc/encoders.texi | 3 +++ > > libavcodec/libvpxenc.c | 6 ++ > > 2 files changed, 9 insertions(+) > > > > lgtm. I'll submit this with a patch version bump soon if there aren't > any further comments. Applied with some additional error checking. Thanks for the patch. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/libvpxenc: return quantizer parameter for an encoded frame
On Tue, Apr 5, 2022 at 7:23 AM Danil Chapovalov
wrote:
>
> I've rechecked documentation for the "vpx_codec_control" - can't find
> any guarantee about the last parameter when the function fails, thus
> prefer to be on the safe side.
>
The check is fine, though the function can only fail due to invalid
arguments and won't modify the value in that case.
As an aside, try to avoid top posting on this list:
https://ffmpeg.org/contact.html#MailingLists
> On Tue, Apr 5, 2022 at 3:59 PM James Almer wrote:
> >
> > On 4/5/2022 9:15 AM, Danil Chapovalov wrote:
> > > ---
> > > libavcodec/libvpxenc.c | 9 -
> > > 1 file changed, 8 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
> > > index dff1d06b0e..0705863450 100644
> > > --- a/libavcodec/libvpxenc.c
> > > +++ b/libavcodec/libvpxenc.c
> > > @@ -1250,6 +1250,8 @@ static int storeframe(AVCodecContext *avctx, struct
> > > FrameListData *cx_frame,
> > > int ret = ff_get_encode_buffer(avctx, pkt, cx_frame->sz, 0);
> > > uint8_t *side_data;
> > > int pict_type;
> > > +int quality;
> > > +VPxContext *ctx = avctx->priv_data;
> > >
> > > if (ret < 0)
> > > return ret;
> > > @@ -1264,7 +1266,12 @@ static int storeframe(AVCodecContext *avctx,
> > > struct FrameListData *cx_frame,
> > > pict_type = AV_PICTURE_TYPE_P;
> > > }
> > >
> > > -ff_side_data_set_encoder_stats(pkt, 0, cx_frame->sse + 1,
> > > +ret = vpx_codec_control(>encoder, VP8E_GET_LAST_QUANTIZER_64,
> > > );
> > > +if (ret != VPX_CODEC_OK) {
> >
> > Is the last argument guaranteed to be untouched when the return value of
> > vpx_codec_control() is not VPX_CODEC_OK? If so, you can initialize
> > quality to 0 above, and remove this part.
> >
> > > +quality = 0;
> > > +}
> > > +
> > > +ff_side_data_set_encoder_stats(pkt, quality * FF_QP2LAMBDA,
> > > cx_frame->sse + 1,
> > > cx_frame->have_sse ? 3 : 0,
> > > pict_type);
> > >
> > > if (cx_frame->have_sse) {
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> > To unsubscribe, visit link above, or email
> > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 1/5] avutil: add ambient viewing environment metadata side data
On Tue, Apr 05, 2022 at 05:32:12PM +0200, Andreas Rheinhardt wrote:
> lance.lmw...@gmail.com:
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavutil/frame.c | 1 +
> > libavutil/frame.h | 6 +
> > libavutil/mastering_display_metadata.c | 23 +
> > libavutil/mastering_display_metadata.h | 45
> > ++
> > libavutil/version.h| 2 +-
> > 5 files changed, 76 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavutil/frame.c b/libavutil/frame.c
> > index fbb869f..8882da2 100644
> > --- a/libavutil/frame.c
> > +++ b/libavutil/frame.c
> > @@ -815,6 +815,7 @@ const char *av_frame_side_data_name(enum
> > AVFrameSideDataType type)
> > case AV_FRAME_DATA_DETECTION_BBOXES:return "Bounding boxes
> > for object detection and classification";
> > case AV_FRAME_DATA_DOVI_RPU_BUFFER: return "Dolby Vision
> > RPU Data";
> > case AV_FRAME_DATA_DOVI_METADATA: return "Dolby Vision
> > Metadata";
> > +case AV_FRAME_DATA_AMBIENT_VIEWING_ENV: return "Ambient
> > Viewing Environment";
> > }
> > return NULL;
> > }
> > diff --git a/libavutil/frame.h b/libavutil/frame.h
> > index 33fac20..92413c9 100644
> > --- a/libavutil/frame.h
> > +++ b/libavutil/frame.h
> > @@ -209,6 +209,12 @@ enum AVFrameSideDataType {
> > * volume transform - CUVA 005.1-2021.
> > */
> > AV_FRAME_DATA_DYNAMIC_HDR_VIVID,
> > +
> > +/**
> > + * ambient viewing environment for a video frame, as described by
> > + * the AVAmbientViewingEnv
> > + */
> > +AV_FRAME_DATA_AMBIENT_VIEWING_ENV,
> > };
> >
> > enum AVActiveFormatDescription {
> > diff --git a/libavutil/mastering_display_metadata.c
> > b/libavutil/mastering_display_metadata.c
> > index 6069347..f094eab 100644
> > --- a/libavutil/mastering_display_metadata.c
> > +++ b/libavutil/mastering_display_metadata.c
> > @@ -64,3 +64,26 @@ AVContentLightMetadata
> > *av_content_light_metadata_create_side_data(AVFrame *fram
> >
> > return (AVContentLightMetadata *)side_data->data;
> > }
> > +
> > +AVAmbientViewingEnv *av_ambient_viewing_env_alloc(size_t *size)
> > +{
> > +AVAmbientViewingEnv *metadata = av_mallocz(sizeof(*metadata));
> > +
> > +if (size)
> > +*size = sizeof(*metadata);
> > +
> > +return metadata;
> > +}
> > +
> > +AVAmbientViewingEnv *av_ambient_viewing_env_create_side_data(AVFrame
> > *frame)
> > +{
> > +AVFrameSideData *side_data = av_frame_new_side_data(frame,
> > +AV_FRAME_DATA_AMBIENT_VIEWING_ENV,
> > +sizeof(AVAmbientViewingEnv));
> > +if (!side_data)
> > +return NULL;
> > +
> > +memset(side_data->data, 0, sizeof(AVAmbientViewingEnv));
> > +
> > +return (AVAmbientViewingEnv *)side_data->data;
> > +}
> > diff --git a/libavutil/mastering_display_metadata.h
> > b/libavutil/mastering_display_metadata.h
> > index c23b07c..c1ba659 100644
> > --- a/libavutil/mastering_display_metadata.h
> > +++ b/libavutil/mastering_display_metadata.h
> > @@ -125,4 +125,49 @@ AVContentLightMetadata
> > *av_content_light_metadata_alloc(size_t *size);
> > */
> > AVContentLightMetadata *av_content_light_metadata_create_side_data(AVFrame
> > *frame);
> >
> > +/**
> > + * The characteristics of the nominal ambient viewing environment for
> > + * the display of the associated video content.
> > + * To be used as payload of a AVFrameSideData the appropriate type.
> > + *
> > + * @note The struct should be allocated with av_ambient_viewing_env_alloc()
> > + * and its size is not a part of the public ABI.
> > + */
> > +typedef struct AVAmbientViewingEnv {
> > +/**
> > + * specifies the environmental illuminance of the ambient viewing
> > + * environment in units of 0.0001 lux.
> > + * ambient_illuminance shall not be equal to 0.
> > + */
> > +uint32_t ambient_illuminance;
> > +/**
> > + * specify the normalized x and y chromaticity coordinates,
> > respectively,
> > + * of the environmental ambient light in the nominal viewing
> > environment,
> > + * according to the CIE 1931 definition of x and y as specified in ISO
> > + * 11664-1 (see also ISO 11664-3 and CIE 15), in normalized increments
> > of
> > + * 0.2. The values of ambient_light_x and ambient_light_y shall be
> > in
> > + * the range of 0 to 5
> > + */
> > +uint16_t ambient_light_x;
> > +uint16_t ambient_light_y;
> > +} AVAmbientViewingEnv;
> > +
> > +/**
> > + * Allocate an AVAmbientViewingEnv structure and set its fields to
> > + * default values. The resulting struct can be freed using av_freep().
> > + *
> > + * @return An AVAmbientViewingEnv filled with default values or NULL
> > + * on failure.
> > + */
> > +AVAmbientViewingEnv *av_ambient_viewing_env_alloc(size_t *size);
> > +
> > +/**
> > + * Allocate a complete
Re: [FFmpeg-devel] [PATCH 3/3] tests: add README.md file with simple instructions
On date Monday 2022-04-04 10:30:27 +0200, Thilo Borgmann wrote:
> Hi,
>
> Am 03.04.22 um 15:59 schrieb Stefano Sabatini:
> > ---
> > tests/README.md | 48
> > 1 file changed, 48 insertions(+)
> > create mode 100644 tests/README.md
> >
> > diff --git a/tests/README.md b/tests/README.md
> > new file mode 100644
> > index 00..4bcae0b403
> > --- /dev/null
> > +++ b/tests/README.md
>
> currently we got part of that in doc/fate.texi. Doesn't it make more sense to
> add that there?
Makes sense, totally missed it, updated.
>From b17625eeddf7083286b529e56050d5dafd7c7680 Mon Sep 17 00:00:00 2001
From: Stefano Sabatini
Date: Sun, 3 Apr 2022 15:22:09 +0200
Subject: [PATCH] doc/fate: add note about showing test names and running a
tests subset
---
doc/fate.texi | 15 +++
1 file changed, 15 insertions(+)
diff --git a/doc/fate.texi b/doc/fate.texi
index c3550785a1..8450856015 100644
--- a/doc/fate.texi
+++ b/doc/fate.texi
@@ -79,6 +79,21 @@ Do not put a '~' character in the samples path to indicate a home
directory. Because of shell nuances, this will cause FATE to fail.
@end float
+To get the complete list of tests, run the command:
+@example
+make fate-list
+@end example
+
+You can specify a subset of tests to run by specifying the
+corresponding elements from the list with the @code{fate-} prefix,
+e.g. as in:
+@example
+make fate-ffprobe_compact fate-ffprobe_xml
+@end example
+
+This makes it easier to run a few tests in case of failure without
+running the complete test suite.
+
To use a custom wrapper to run the test, pass @option{--target-exec} to
@command{configure} or set the @var{TARGET_EXEC} Make variable.
--
2.25.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 v12 1/1] avformat: Add IPFS protocol support.
On Tue, Apr 5, 2022 at 11:27 PM Mark Gaiser wrote:
>
>
> On Tue, Apr 5, 2022 at 11:01 PM Michael Niedermayer <
> mich...@niedermayer.cc> wrote:
>
>> On Mon, Apr 04, 2022 at 12:38:25AM +0200, Mark Gaiser wrote:
>> > This patch adds support for:
>> > - ffplay ipfs://
>> > - ffplay ipns://
>> >
>> > IPFS data can be played from so called "ipfs gateways".
>> > A gateway is essentially a webserver that gives access to the
>> > distributed IPFS network.
>> >
>> > This protocol support (ipfs and ipns) therefore translates
>> > ipfs:// and ipns:// to a http:// url. This resulting url is
>> > then handled by the http protocol. It could also be https
>> > depending on the gateway provided.
>> >
>> > To use this protocol, a gateway must be provided.
>> > If you do nothing it will try to find it in your
>> > $HOME/.ipfs/gateway file. The ways to set it manually are:
>> > 1. Define a -gateway to the gateway.
>> > 2. Define $IPFS_GATEWAY with the full http link to the gateway.
>> > 3. Define $IPFS_PATH and point it to the IPFS data path.
>> > 4. Have IPFS running in your local user folder (under $HOME/.ipfs).
>> >
>> [...]
>>
>> > +goto err;
>> > +}
>> > +
>> > +// Read a single line (fgets stops at new line mark).
>> > +if (!fgets(c->gateway_buffer, sizeof(c->gateway_buffer) - 1,
>> gateway_file)) {
>> > + av_log(h, AV_LOG_WARNING, "Unable to read from file (full uri:
>> %s).\n",
>> > + ipfs_gateway_file);
>> > + ret = AVERROR(ENOENT);
>> > + goto err;
>> > +}
>>
>> The indention is not consistent
>>
>
> What's the intended indentation here?
> In my editor (QtCreator, it's set to 2 spaces for tabs) the
> "ipfs_gateway_file" is aligned directly underneath the first argument of
> av_log.
> That is as it should be, right?
>
> For this and your other comments, I see no issue on my side. Also no
> trailing whitespace.
>
> Here's an image of what i see with spaces visualizes:
> https://i.imgur.com/37k68RH.png
> Is there something wrong on my end?
>
Just checked patchwork:
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20220403223825.26764-2-mark...@gmail.com/
It also shows the indentation as I intended which should be according to
the ffmpeg coding style guidelines.
Same with:
https://ffmpeg.org/pipermail/ffmpeg-devel/2022-April/294932.html
>
>
>>
>>
>> [...]
>> > +// Populate c->gateway_buffer with whatever is in c->gateway
>> > +if (c->gateway != NULL) {
>> > +if (snprintf(c->gateway_buffer, sizeof(c->gateway_buffer),
>> "%s",
>> > + c->gateway) >= sizeof(c->gateway_buffer)) {
>> > +av_log(h, AV_LOG_WARNING, "The -gateway parameter is too
>> long. "
>> > + "We allow a max of %zu
>> characters\n",
>> > + sizeof(c->gateway_buffer));
>> > +ret = AVERROR(EINVAL);
>> > +goto err;
>> > +}
>> > +} else {
>> > +// Populate the IPFS gateway if we have any.
>> > +// If not, inform the user how to properly set one.
>> > +ret = populate_ipfs_gateway(h);
>> > +
>> > +if (ret < 1) {
>> > +// We fallback on dweb.link (managed by Protocol Labs).
>> > +snprintf(c->gateway_buffer, sizeof(c->gateway_buffer), "
>> https://dweb.link;);
>> > +
>> > +av_log(h, AV_LOG_WARNING, "IPFS does not appear to be
>> running. "
>> > + "You’re now using the public
>> gateway at dweb.link.\n");
>> > +av_log(h, AV_LOG_INFO, "Installing IPFS locally is
>> recommended to "
>> > + "improve performance and
>> reliability, "
>> > + "and not share all your activity
>> with a single IPFS gateway.\n"
>> > + "There are multiple options to define this
>> gateway.\n"
>> > + "1. Call ffmpeg with a gateway param, "
>> > + "without a trailing slash: -gateway
>> .\n"
>> > + "2. Define an $IPFS_GATEWAY environment variable
>> with the "
>> > + "full HTTP URL to the gateway "
>> > + "without trailing forward slash.\n"
>> > + "3. Define an $IPFS_PATH environment variable "
>> > + "and point it to the IPFS data path
>> "
>> > + "- this is typically ~/.ipfs\n");
>> > +}
>> > +}
>>
>> This will print the warning every time a ipfs url is opened. Not just once
>> is that intended ?
>>
>
> Yes.
>
> Or rather, I don't see how to make it persistent in a nice intuitive way.
> By nice intuitive I mean showing it for, lets say, 10 times you use ffmpeg
> to be "sure" you've seen it before it can stop annoying the user about it.
>
> Adding complexity for that doesn't seem to be worth it to me.
>
>
>>
>>
>>
>> > +
>> > +// Test if the gateway starts with
Re: [FFmpeg-devel] [PATCH v12 1/1] avformat: Add IPFS protocol support.
On Tue, Apr 5, 2022 at 11:01 PM Michael Niedermayer
wrote:
> On Mon, Apr 04, 2022 at 12:38:25AM +0200, Mark Gaiser wrote:
> > This patch adds support for:
> > - ffplay ipfs://
> > - ffplay ipns://
> >
> > IPFS data can be played from so called "ipfs gateways".
> > A gateway is essentially a webserver that gives access to the
> > distributed IPFS network.
> >
> > This protocol support (ipfs and ipns) therefore translates
> > ipfs:// and ipns:// to a http:// url. This resulting url is
> > then handled by the http protocol. It could also be https
> > depending on the gateway provided.
> >
> > To use this protocol, a gateway must be provided.
> > If you do nothing it will try to find it in your
> > $HOME/.ipfs/gateway file. The ways to set it manually are:
> > 1. Define a -gateway to the gateway.
> > 2. Define $IPFS_GATEWAY with the full http link to the gateway.
> > 3. Define $IPFS_PATH and point it to the IPFS data path.
> > 4. Have IPFS running in your local user folder (under $HOME/.ipfs).
> >
> [...]
>
> > +goto err;
> > +}
> > +
> > +// Read a single line (fgets stops at new line mark).
> > +if (!fgets(c->gateway_buffer, sizeof(c->gateway_buffer) - 1,
> gateway_file)) {
> > + av_log(h, AV_LOG_WARNING, "Unable to read from file (full uri:
> %s).\n",
> > + ipfs_gateway_file);
> > + ret = AVERROR(ENOENT);
> > + goto err;
> > +}
>
> The indention is not consistent
>
What's the intended indentation here?
In my editor (QtCreator, it's set to 2 spaces for tabs) the
"ipfs_gateway_file" is aligned directly underneath the first argument of
av_log.
That is as it should be, right?
For this and your other comments, I see no issue on my side. Also no
trailing whitespace.
Here's an image of what i see with spaces visualizes:
https://i.imgur.com/37k68RH.png
Is there something wrong on my end?
>
>
> [...]
> > +// Populate c->gateway_buffer with whatever is in c->gateway
> > +if (c->gateway != NULL) {
> > +if (snprintf(c->gateway_buffer, sizeof(c->gateway_buffer), "%s",
> > + c->gateway) >= sizeof(c->gateway_buffer)) {
> > +av_log(h, AV_LOG_WARNING, "The -gateway parameter is too
> long. "
> > + "We allow a max of %zu
> characters\n",
> > + sizeof(c->gateway_buffer));
> > +ret = AVERROR(EINVAL);
> > +goto err;
> > +}
> > +} else {
> > +// Populate the IPFS gateway if we have any.
> > +// If not, inform the user how to properly set one.
> > +ret = populate_ipfs_gateway(h);
> > +
> > +if (ret < 1) {
> > +// We fallback on dweb.link (managed by Protocol Labs).
> > +snprintf(c->gateway_buffer, sizeof(c->gateway_buffer), "
> https://dweb.link;);
> > +
> > +av_log(h, AV_LOG_WARNING, "IPFS does not appear to be
> running. "
> > + "You’re now using the public
> gateway at dweb.link.\n");
> > +av_log(h, AV_LOG_INFO, "Installing IPFS locally is
> recommended to "
> > + "improve performance and
> reliability, "
> > + "and not share all your activity
> with a single IPFS gateway.\n"
> > + "There are multiple options to define this
> gateway.\n"
> > + "1. Call ffmpeg with a gateway param, "
> > + "without a trailing slash: -gateway
> .\n"
> > + "2. Define an $IPFS_GATEWAY environment variable
> with the "
> > + "full HTTP URL to the gateway "
> > + "without trailing forward slash.\n"
> > + "3. Define an $IPFS_PATH environment variable "
> > + "and point it to the IPFS data path "
> > + "- this is typically ~/.ipfs\n");
> > +}
> > +}
>
> This will print the warning every time a ipfs url is opened. Not just once
> is that intended ?
>
Yes.
Or rather, I don't see how to make it persistent in a nice intuitive way.
By nice intuitive I mean showing it for, lets say, 10 times you use ffmpeg
to be "sure" you've seen it before it can stop annoying the user about it.
Adding complexity for that doesn't seem to be worth it to me.
>
>
>
> > +
> > +// Test if the gateway starts with either http:// or https://
> > +if (av_stristart(c->gateway_buffer, "http://;, NULL) == 0
> > +&& av_stristart(c->gateway_buffer, "https://;, NULL) == 0) {
> > +av_log(h, AV_LOG_WARNING, "The gateway URL didn't start with
> http:// or "
> > + "https:// and is therefore
> invalid.\n");
> > +ret = AVERROR(EILSEQ);
> > +goto err;
> > +}
> > +
> > +// Concatenate the url.
> > +// This ends up with something like:
> http://localhost:8080/ipfs/Qm.
> > +
Re: [FFmpeg-devel] [PATCH] ffmpeg: document -d option
On date Tuesday 2022-04-05 07:23:27 +0200, Anton Khirnov wrote: > Quoting Stefano Sabatini (2022-04-03 17:27:06) > > Option was added in commit 39aafa5ee90e10382e. > > > > Fix trac issue: http://trac.ffmpeg.org/ticket/1698 > > --- > > doc/ffmpeg.texi | 12 > > fftools/ffmpeg_opt.c | 3 +++ > > 2 files changed, 15 insertions(+) > > Does this option do anything useful? Shouldn't it rather be removed? Works for me. Do we have a use case for this? This basically disables logs and detaches ffmpeg from the terminal. @Michael, can you comment about this (this was added by you)? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded architecture
> -Original Message- > From: ffmpeg-devel On Behalf Of Paul > B Mahol > Sent: Tuesday, April 5, 2022 11:19 PM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded > architecture > > On Tue, Apr 5, 2022 at 11:06 PM Soft Works > wrote: > > > > > > > > -Original Message- > > > From: ffmpeg-devel On Behalf Of > > > Anton Khirnov > > > Sent: Tuesday, April 5, 2022 9:46 PM > > > To: FFmpeg development discussions and patches > > de...@ffmpeg.org> > > > Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded > > > architecture > > > > > > Quoting Michael Niedermayer (2022-04-05 21:15:42) > > > > On Mon, Apr 04, 2022 at 01:29:48PM +0200, Anton Khirnov wrote: > > > > > Hi, > > > > > this WIP patchset is the first major part of my ongoing work > to > > > change > > > > > ffmpeg.c architecture such that every > > > > > - demuxer > > > > > - decoder > > > > > - filtergraph > > > > > - encoder > > > > > - muxer > > > > > lives in its own thread. The advantages of doing this, beyond > > > increased > > > > > throughput, would be enforced separation between these > components, > > > > > making the code more local and easier to reason about. > > > > > > > > > > This set implements threading for muxers. My tentative plan is > to > > > > > continue with encoders and then filters. The patches still > need > > > some > > > > > polishing, especially the last one. Two FATE tests do not yet > > > pass, this > > > > > will be fixed in later iterations. > > > > > > > > > > Meanwhile, comments on the overall approach are especially > > > welcome. > > > > > > > > I agree that cleanup/modularization to make the code easier to > > > > understand is a good idea! > > > > Didnt really look at the patchset yet. > > > > I assume these changes have no real disadvantage ? > > > > > > Playing the devil's advocate, I can think of the following: > > > 1) ffmpeg.c will hard-depend on threads > > > 2) execution flow will become non-deterministic > > > 3) overall resource usage will likely go up due to inter-thread > > >synchronization and overhead related to new objects > > > 4) large-scale code changes always carry a higher risk of > regressions > > > > > > re 1): should not be a problem for any serious system > > > re 2): I spent a lot of effort to ensure the _output_ remains > > >deterministic (it actually becomes more predictable for > some > > >cases) > > > re 3): I expect the impact to be small and negligible, > respectively, > > > but > > >would have to be measured once the conversion is complete > > > re 4): the only way to avoid this completely would be to stop > > >development > > > > > > Overall, I believe the advantages far outweigh the potential > > > negatives. > > > > Hi, > > > > do I understand it right that there won't be a single-thread > > operation mode that replicates/corresponds the current behavior? > > > > Not that I wouldn't welcome the performance improvements, but one > > concern I have is debugging filtergraph operations. This is already > > a pretty tedious task in itself, because many relevant decisions > > are made in sub-sub-sub-sub-sub-functions, spread over many places. > > When adding an additional - not even deterministic - part to the > > game, it won't make things easier. It could even create situations > > where it could no longer be possible to replicate an error in a > > debugger - in case the existence of a debugger would cause a > variance > > within the constraints of the non-determinism range. > > > > > Can you elaborate more?, otherwise this is PEBKAC. You mean like WKOFAIT? ___ 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] [RFC] Switching ffmpeg.c to a threaded architecture
On Tue, Apr 5, 2022 at 11:06 PM Soft Works wrote: > > > > -Original Message- > > From: ffmpeg-devel On Behalf Of > > Anton Khirnov > > Sent: Tuesday, April 5, 2022 9:46 PM > > To: FFmpeg development discussions and patches > de...@ffmpeg.org> > > Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded > > architecture > > > > Quoting Michael Niedermayer (2022-04-05 21:15:42) > > > On Mon, Apr 04, 2022 at 01:29:48PM +0200, Anton Khirnov wrote: > > > > Hi, > > > > this WIP patchset is the first major part of my ongoing work to > > change > > > > ffmpeg.c architecture such that every > > > > - demuxer > > > > - decoder > > > > - filtergraph > > > > - encoder > > > > - muxer > > > > lives in its own thread. The advantages of doing this, beyond > > increased > > > > throughput, would be enforced separation between these components, > > > > making the code more local and easier to reason about. > > > > > > > > This set implements threading for muxers. My tentative plan is to > > > > continue with encoders and then filters. The patches still need > > some > > > > polishing, especially the last one. Two FATE tests do not yet > > pass, this > > > > will be fixed in later iterations. > > > > > > > > Meanwhile, comments on the overall approach are especially > > welcome. > > > > > > I agree that cleanup/modularization to make the code easier to > > > understand is a good idea! > > > Didnt really look at the patchset yet. > > > I assume these changes have no real disadvantage ? > > > > Playing the devil's advocate, I can think of the following: > > 1) ffmpeg.c will hard-depend on threads > > 2) execution flow will become non-deterministic > > 3) overall resource usage will likely go up due to inter-thread > >synchronization and overhead related to new objects > > 4) large-scale code changes always carry a higher risk of regressions > > > > re 1): should not be a problem for any serious system > > re 2): I spent a lot of effort to ensure the _output_ remains > >deterministic (it actually becomes more predictable for some > >cases) > > re 3): I expect the impact to be small and negligible, respectively, > > but > >would have to be measured once the conversion is complete > > re 4): the only way to avoid this completely would be to stop > >development > > > > Overall, I believe the advantages far outweigh the potential > > negatives. > > Hi, > > do I understand it right that there won't be a single-thread > operation mode that replicates/corresponds the current behavior? > > Not that I wouldn't welcome the performance improvements, but one > concern I have is debugging filtergraph operations. This is already > a pretty tedious task in itself, because many relevant decisions > are made in sub-sub-sub-sub-sub-functions, spread over many places. > When adding an additional - not even deterministic - part to the > game, it won't make things easier. It could even create situations > where it could no longer be possible to replicate an error in a > debugger - in case the existence of a debugger would cause a variance > within the constraints of the non-determinism range. > > Can you elaborate more?, otherwise this is PEBKAC. > From another point of view, this is a change, so fundamental like > ffmpeg(.c) hasn't seen in a long time. > I would at least suppose that this could cause issues at many ends, > and from experience, there may be additional ends where it's rather > unexpected to have effects. > > In that context, I think that doing a change of such a wide scope > in an irreversible way like this, would impose quite a burden on > many other developers, because sooner or later, other developers > will run into situations where something is no longer working like > before and you'll regularly wonder whether this might be a consequence > of ffmpeg.c threading change or caused by other changes. > But then, you won't be able anymore to bisect on that suspicion, > because the threading change can't be reverted and (as long as it's > not shortly after the change) there might have been too many other > changes to easily port them back to a state before the threading > change. > > I wonder whether this couldn't be done in a way that the current > behavior can be preserved and activated by option? > > Wouldn't it be possible to follow an approach like this: > > - Assuming the code would be fine and it would mark the desired > end result > - Put it aside and start over from the current HEAD > - Iteratively morph the code current code in a (possibly) long > sequence of refactoring operations where every single one > (and hence in sum) are semantically neutral - until the code > is turned more and more into what has already been developed > - eventually, only few differences will be left, and these can > be made switchable by an option - as a result, both - old and > new operation modes would be available. > > I don't know whether there's a name to this
Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded architecture
> -Original Message- > From: ffmpeg-devel On Behalf Of > Anton Khirnov > Sent: Tuesday, April 5, 2022 9:46 PM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded > architecture > > Quoting Michael Niedermayer (2022-04-05 21:15:42) > > On Mon, Apr 04, 2022 at 01:29:48PM +0200, Anton Khirnov wrote: > > > Hi, > > > this WIP patchset is the first major part of my ongoing work to > change > > > ffmpeg.c architecture such that every > > > - demuxer > > > - decoder > > > - filtergraph > > > - encoder > > > - muxer > > > lives in its own thread. The advantages of doing this, beyond > increased > > > throughput, would be enforced separation between these components, > > > making the code more local and easier to reason about. > > > > > > This set implements threading for muxers. My tentative plan is to > > > continue with encoders and then filters. The patches still need > some > > > polishing, especially the last one. Two FATE tests do not yet > pass, this > > > will be fixed in later iterations. > > > > > > Meanwhile, comments on the overall approach are especially > welcome. > > > > I agree that cleanup/modularization to make the code easier to > > understand is a good idea! > > Didnt really look at the patchset yet. > > I assume these changes have no real disadvantage ? > > Playing the devil's advocate, I can think of the following: > 1) ffmpeg.c will hard-depend on threads > 2) execution flow will become non-deterministic > 3) overall resource usage will likely go up due to inter-thread >synchronization and overhead related to new objects > 4) large-scale code changes always carry a higher risk of regressions > > re 1): should not be a problem for any serious system > re 2): I spent a lot of effort to ensure the _output_ remains >deterministic (it actually becomes more predictable for some >cases) > re 3): I expect the impact to be small and negligible, respectively, > but >would have to be measured once the conversion is complete > re 4): the only way to avoid this completely would be to stop >development > > Overall, I believe the advantages far outweigh the potential > negatives. Hi, do I understand it right that there won't be a single-thread operation mode that replicates/corresponds the current behavior? Not that I wouldn't welcome the performance improvements, but one concern I have is debugging filtergraph operations. This is already a pretty tedious task in itself, because many relevant decisions are made in sub-sub-sub-sub-sub-functions, spread over many places. When adding an additional - not even deterministic - part to the game, it won't make things easier. It could even create situations where it could no longer be possible to replicate an error in a debugger - in case the existence of a debugger would cause a variance within the constraints of the non-determinism range. >From another point of view, this is a change, so fundamental like ffmpeg(.c) hasn't seen in a long time. I would at least suppose that this could cause issues at many ends, and from experience, there may be additional ends where it's rather unexpected to have effects. In that context, I think that doing a change of such a wide scope in an irreversible way like this, would impose quite a burden on many other developers, because sooner or later, other developers will run into situations where something is no longer working like before and you'll regularly wonder whether this might be a consequence of ffmpeg.c threading change or caused by other changes. But then, you won't be able anymore to bisect on that suspicion, because the threading change can't be reverted and (as long as it's not shortly after the change) there might have been too many other changes to easily port them back to a state before the threading change. I wonder whether this couldn't be done in a way that the current behavior can be preserved and activated by option? Wouldn't it be possible to follow an approach like this: - Assuming the code would be fine and it would mark the desired end result - Put it aside and start over from the current HEAD - Iteratively morph the code current code in a (possibly) long sequence of refactoring operations where every single one (and hence in sum) are semantically neutral - until the code is turned more and more into what has already been developed - eventually, only few differences will be left, and these can be made switchable by an option - as a result, both - old and new operation modes would be available. I don't know whether there's a name to this approach, probably there is, yet I never cared. Way more important is that I always had good results following this methodology. The funny thing about it is, that when you have a reliable tooling for refactoring, you can even stop thinking (well, sort of..) while transforming the code. Also, when you can't
Re: [FFmpeg-devel] [PATCH v12 1/1] avformat: Add IPFS protocol support.
On Mon, Apr 04, 2022 at 12:38:25AM +0200, Mark Gaiser wrote:
> This patch adds support for:
> - ffplay ipfs://
> - ffplay ipns://
>
> IPFS data can be played from so called "ipfs gateways".
> A gateway is essentially a webserver that gives access to the
> distributed IPFS network.
>
> This protocol support (ipfs and ipns) therefore translates
> ipfs:// and ipns:// to a http:// url. This resulting url is
> then handled by the http protocol. It could also be https
> depending on the gateway provided.
>
> To use this protocol, a gateway must be provided.
> If you do nothing it will try to find it in your
> $HOME/.ipfs/gateway file. The ways to set it manually are:
> 1. Define a -gateway to the gateway.
> 2. Define $IPFS_GATEWAY with the full http link to the gateway.
> 3. Define $IPFS_PATH and point it to the IPFS data path.
> 4. Have IPFS running in your local user folder (under $HOME/.ipfs).
>
[...]
> +goto err;
> +}
> +
> +// Read a single line (fgets stops at new line mark).
> +if (!fgets(c->gateway_buffer, sizeof(c->gateway_buffer) - 1,
> gateway_file)) {
> + av_log(h, AV_LOG_WARNING, "Unable to read from file (full uri: %s).\n",
> + ipfs_gateway_file);
> + ret = AVERROR(ENOENT);
> + goto err;
> +}
The indention is not consistent
[...]
> +// Populate c->gateway_buffer with whatever is in c->gateway
> +if (c->gateway != NULL) {
> +if (snprintf(c->gateway_buffer, sizeof(c->gateway_buffer), "%s",
> + c->gateway) >= sizeof(c->gateway_buffer)) {
> +av_log(h, AV_LOG_WARNING, "The -gateway parameter is too long. "
> + "We allow a max of %zu characters\n",
> + sizeof(c->gateway_buffer));
> +ret = AVERROR(EINVAL);
> +goto err;
> +}
> +} else {
> +// Populate the IPFS gateway if we have any.
> +// If not, inform the user how to properly set one.
> +ret = populate_ipfs_gateway(h);
> +
> +if (ret < 1) {
> +// We fallback on dweb.link (managed by Protocol Labs).
> +snprintf(c->gateway_buffer, sizeof(c->gateway_buffer),
> "https://dweb.link;);
> +
> +av_log(h, AV_LOG_WARNING, "IPFS does not appear to be running. "
> + "You’re now using the public gateway
> at dweb.link.\n");
> +av_log(h, AV_LOG_INFO, "Installing IPFS locally is recommended
> to "
> + "improve performance and reliability, "
> + "and not share all your activity with a
> single IPFS gateway.\n"
> + "There are multiple options to define this gateway.\n"
> + "1. Call ffmpeg with a gateway param, "
> + "without a trailing slash: -gateway
> .\n"
> + "2. Define an $IPFS_GATEWAY environment variable with the
> "
> + "full HTTP URL to the gateway "
> + "without trailing forward slash.\n"
> + "3. Define an $IPFS_PATH environment variable "
> + "and point it to the IPFS data path "
> + "- this is typically ~/.ipfs\n");
> +}
> +}
This will print the warning every time a ipfs url is opened. Not just once
is that intended ?
> +
> +// Test if the gateway starts with either http:// or https://
> +if (av_stristart(c->gateway_buffer, "http://;, NULL) == 0
> +&& av_stristart(c->gateway_buffer, "https://;, NULL) == 0) {
> +av_log(h, AV_LOG_WARNING, "The gateway URL didn't start with http://
> or "
> + "https:// and is therefore invalid.\n");
> +ret = AVERROR(EILSEQ);
> +goto err;
> +}
> +
> +// Concatenate the url.
> +// This ends up with something like: http://localhost:8080/ipfs/Qm.
> +// The format of "%s%s%s%s" is the following:
> +// 1st %s = The gateway.
> +// 2nd %s = If the gateway didn't end in a slash, add a "/". Otherwise
> it's an empty string
> +// 3rd %s = Either ipns/ or ipfs/.
> +// 4th %s = The IPFS CID (Qm..., bafy..., ...).
> +fulluri = av_asprintf("%s%s%s%s",
> + c->gateway_buffer,
> + (c->gateway_buffer[strlen(c->gateway_buffer) - 1]
> == '/') ? "" : "/",
> + (is_ipns) ? "ipns/" : "ipfs/",
> + ipfs_cid);
> +
> +if (!fulluri) {
> + av_log(h, AV_LOG_ERROR, "Failed to compose the URL\n");
> + ret = AVERROR(ENOMEM);
> + goto err;
> +}
another indention case
Theres also some trailing whitespace in the patch left
No more comments from me. LGTM after these to me i think
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Many that live deserve
[FFmpeg-devel] [PATCH] avfilter/f_ebur128: multiply in integer first, before dividing in float
Restores the order of operations from before 15a1104, which reduces
errors from floating point calculations, and fixes FATE on mingw64.
---
libavfilter/f_ebur128.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavfilter/f_ebur128.c b/libavfilter/f_ebur128.c
index 1b1bcf1bff..a036aa0c86 100644
--- a/libavfilter/f_ebur128.c
+++ b/libavfilter/f_ebur128.c
@@ -768,7 +768,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
*insamples)
/* get lower loudness to consider */
n = 0;
-nb_pow = LRA_LOWER_PRC * 0.01 * nb_powers + 0.5;
+nb_pow = LRA_LOWER_PRC * nb_powers * 0.01 + 0.5;
for (i = gate_hist_pos; i < HIST_SIZE; i++) {
n += ebur128->i3000.histogram[i].count;
if (n >= nb_pow) {
@@ -779,7 +779,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
*insamples)
/* get higher loudness to consider */
n = nb_powers;
-nb_pow = LRA_HIGHER_PRC * 0.01 * nb_powers + 0.5;
+nb_pow = LRA_HIGHER_PRC * nb_powers * 0.01 + 0.5;
for (i = HIST_SIZE - 1; i >= 0; i--) {
n -= FFMIN(n, ebur128->i3000.histogram[i].count);
if (n < nb_pow) {
--
2.33.0.windows.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/ituh263enc: Add AV_CODEC_CAP_SLICE_THREADS to old H.263
On Tue, Apr 05, 2022 at 05:07:22PM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > It is supported by the H.263+ AVCodec already
> >
> > Is there any case where this does not work ?
> >
> > Fixes regression of some command lines
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/ituh263enc.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/libavcodec/ituh263enc.c b/libavcodec/ituh263enc.c
> > index db7cdf1fcb..82dce05e36 100644
> > --- a/libavcodec/ituh263enc.c
> > +++ b/libavcodec/ituh263enc.c
> > @@ -908,6 +908,7 @@ const FFCodec ff_h263_encoder = {
> > .p.id = AV_CODEC_ID_H263,
> > .p.pix_fmts = (const enum AVPixelFormat[]){AV_PIX_FMT_YUV420P,
> > AV_PIX_FMT_NONE},
> > .p.priv_class = _class,
> > +.p.capabilities = AV_CODEC_CAP_SLICE_THREADS,
> > .caps_internal = FF_CODEC_CAP_INIT_THREADSAFE |
> > FF_CODEC_CAP_INIT_CLEANUP,
> > .priv_data_size = sizeof(MpegEncContext),
> > .init = ff_mpv_encode_init,
>
> 1. If you claim that there is a regression, you should mention the
> commit that introduced them in the commit message (it's obviously
> 8ca4b515e73079cda068e253853654db394b8171 in this case).
> 2. What command lines regressed exactly? The only command lines that
> should be affected by said commit are command lines that set the slices
> option to a value > 1.
> 3. As the commit message of 8ca4b515e73079cda068e253853654db394b8171
> explains, this was intentional, as the H.263 encoder produces broken
> files with multiple slices (whether with slice-threading or not). One
> gets all kinds of error messages when decoding such a file: "I cbpy
> damaged at 1 7", "Error at MB: 316", "illegal ac vlc code at 0x29",
> "slice end not reached but screenspace end (7 left 80, score=
> -125)", "run overflow at 0x7 i:1". Of course, there are visual
> artifacts, too.
> 4. With this patch, this encoder will by default (at least, by the
> defaults of the ffmpeg command line tool) produce broken files.
> 5. "Is there any case where this does not work ?": Is there any where it
> works?
The testcases i had where these:
./ffmpeg -threads 1 -i fate-suite/svq3/Vertical400kbit.sorenson3.mov -t 1
-bitexact -qscale 2 -slices 1 -y -threads 1 -vcodec h263 -s 352x288 -an
/tmp/file-h263-s1t1.h263
./ffmpeg -threads 1 -i fate-suite/svq3/Vertical400kbit.sorenson3.mov -t 1
-bitexact -qscale 2 -slices 2 -y -threads 1 -vcodec h263 -s 352x288 -an
/tmp/file-h263-s2t1.h263
./ffmpeg -threads 1 -i fate-suite/svq3/Vertical400kbit.sorenson3.mov -t 1
-bitexact -qscale 2 -slices 1 -y -threads 2 -vcodec h263 -s 352x288 -an
/tmp/file-h263-s1t2.h263
./ffmpeg -threads 1 -i fate-suite/svq3/Vertical400kbit.sorenson3.mov -t 1
-bitexact -qscale 2 -slices 2 -y -threads 2 -vcodec h263 -s 352x288 -an
/tmp/file-h263-s2t2.h263
The files seem to play fine
i did not try to find a case that fails
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Dictatorship: All citizens are under surveillance, all their steps and
actions recorded, for the politicians to enforce control.
Democracy: All politicians are under surveillance, all their steps and
actions recorded, for the citizens to enforce control.
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] [RFC] Switching ffmpeg.c to a threaded architecture
Quoting Michael Niedermayer (2022-04-05 21:15:42) > On Mon, Apr 04, 2022 at 01:29:48PM +0200, Anton Khirnov wrote: > > Hi, > > this WIP patchset is the first major part of my ongoing work to change > > ffmpeg.c architecture such that every > > - demuxer > > - decoder > > - filtergraph > > - encoder > > - muxer > > lives in its own thread. The advantages of doing this, beyond increased > > throughput, would be enforced separation between these components, > > making the code more local and easier to reason about. > > > > This set implements threading for muxers. My tentative plan is to > > continue with encoders and then filters. The patches still need some > > polishing, especially the last one. Two FATE tests do not yet pass, this > > will be fixed in later iterations. > > > > Meanwhile, comments on the overall approach are especially welcome. > > I agree that cleanup/modularization to make the code easier to > understand is a good idea! > Didnt really look at the patchset yet. > I assume these changes have no real disadvantage ? Playing the devil's advocate, I can think of the following: 1) ffmpeg.c will hard-depend on threads 2) execution flow will become non-deterministic 3) overall resource usage will likely go up due to inter-thread synchronization and overhead related to new objects 4) large-scale code changes always carry a higher risk of regressions re 1): should not be a problem for any serious system re 2): I spent a lot of effort to ensure the _output_ remains deterministic (it actually becomes more predictable for some cases) re 3): I expect the impact to be small and negligible, respectively, but would have to be measured once the conversion is complete re 4): the only way to avoid this completely would be to stop development Overall, I believe the advantages far outweigh the potential negatives. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 1/5] avutil: add ambient viewing environment metadata side data
Lynne:
> 5 Apr 2022, 17:32 by andreas.rheinha...@outlook.com:
>
>> lance.lmw...@gmail.com:
>>
>>> From: Limin Wang
>>>
>>> Signed-off-by: Limin Wang
>>> ---
>>> libavutil/frame.c | 1 +
>>> libavutil/frame.h | 6 +
>>> libavutil/mastering_display_metadata.c | 23 +
>>> libavutil/mastering_display_metadata.h | 45
>>> ++
>>> libavutil/version.h| 2 +-
>>> 5 files changed, 76 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/libavutil/frame.c b/libavutil/frame.c
>>> index fbb869f..8882da2 100644
>>> --- a/libavutil/frame.c
>>> +++ b/libavutil/frame.c
>>> @@ -815,6 +815,7 @@ const char *av_frame_side_data_name(enum
>>> AVFrameSideDataType type)
>>> case AV_FRAME_DATA_DETECTION_BBOXES:return "Bounding boxes for
>>> object detection and classification";
>>> case AV_FRAME_DATA_DOVI_RPU_BUFFER: return "Dolby Vision RPU
>>> Data";
>>> case AV_FRAME_DATA_DOVI_METADATA: return "Dolby Vision
>>> Metadata";
>>> +case AV_FRAME_DATA_AMBIENT_VIEWING_ENV: return "Ambient
>>> Viewing Environment";
>>> }
>>> return NULL;
>>> }
>>> diff --git a/libavutil/frame.h b/libavutil/frame.h
>>> index 33fac20..92413c9 100644
>>> --- a/libavutil/frame.h
>>> +++ b/libavutil/frame.h
>>> @@ -209,6 +209,12 @@ enum AVFrameSideDataType {
>>> * volume transform - CUVA 005.1-2021.
>>> */
>>> AV_FRAME_DATA_DYNAMIC_HDR_VIVID,
>>> +
>>> +/**
>>> + * ambient viewing environment for a video frame, as described by
>>> + * the AVAmbientViewingEnv
>>> + */
>>> +AV_FRAME_DATA_AMBIENT_VIEWING_ENV,
>>> };
>>>
>>> enum AVActiveFormatDescription {
>>> diff --git a/libavutil/mastering_display_metadata.c
>>> b/libavutil/mastering_display_metadata.c
>>> index 6069347..f094eab 100644
>>> --- a/libavutil/mastering_display_metadata.c
>>> +++ b/libavutil/mastering_display_metadata.c
>>> @@ -64,3 +64,26 @@ AVContentLightMetadata
>>> *av_content_light_metadata_create_side_data(AVFrame *fram
>>>
>>> return (AVContentLightMetadata *)side_data->data;
>>> }
>>> +
>>> +AVAmbientViewingEnv *av_ambient_viewing_env_alloc(size_t *size)
>>> +{
>>> +AVAmbientViewingEnv *metadata = av_mallocz(sizeof(*metadata));
>>> +
>>> +if (size)
>>> +*size = sizeof(*metadata);
>>> +
>>> +return metadata;
>>> +}
>>> +
>>> +AVAmbientViewingEnv *av_ambient_viewing_env_create_side_data(AVFrame
>>> *frame)
>>> +{
>>> +AVFrameSideData *side_data = av_frame_new_side_data(frame,
>>> +AV_FRAME_DATA_AMBIENT_VIEWING_ENV,
>>> +sizeof(AVAmbientViewingEnv));
>>> +if (!side_data)
>>> +return NULL;
>>> +
>>> +memset(side_data->data, 0, sizeof(AVAmbientViewingEnv));
>>> +
>>> +return (AVAmbientViewingEnv *)side_data->data;
>>> +}
>>> diff --git a/libavutil/mastering_display_metadata.h
>>> b/libavutil/mastering_display_metadata.h
>>> index c23b07c..c1ba659 100644
>>> --- a/libavutil/mastering_display_metadata.h
>>> +++ b/libavutil/mastering_display_metadata.h
>>> @@ -125,4 +125,49 @@ AVContentLightMetadata
>>> *av_content_light_metadata_alloc(size_t *size);
>>> */
>>> AVContentLightMetadata *av_content_light_metadata_create_side_data(AVFrame
>>> *frame);
>>>
>>> +/**
>>> + * The characteristics of the nominal ambient viewing environment for
>>> + * the display of the associated video content.
>>> + * To be used as payload of a AVFrameSideData the appropriate type.
>>> + *
>>> + * @note The struct should be allocated with av_ambient_viewing_env_alloc()
>>> + * and its size is not a part of the public ABI.
>>> + */
>>> +typedef struct AVAmbientViewingEnv {
>>> +/**
>>> + * specifies the environmental illuminance of the ambient viewing
>>> + * environment in units of 0.0001 lux.
>>> + * ambient_illuminance shall not be equal to 0.
>>> + */
>>> +uint32_t ambient_illuminance;
>>> +/**
>>> + * specify the normalized x and y chromaticity coordinates,
>>> respectively,
>>> + * of the environmental ambient light in the nominal viewing
>>> environment,
>>> + * according to the CIE 1931 definition of x and y as specified in ISO
>>> + * 11664-1 (see also ISO 11664-3 and CIE 15), in normalized increments
>>> of
>>> + * 0.2. The values of ambient_light_x and ambient_light_y shall be
>>> in
>>> + * the range of 0 to 5
>>> + */
>>> +uint16_t ambient_light_x;
>>> +uint16_t ambient_light_y;
>>> +} AVAmbientViewingEnv;
>>> +
>>> +/**
>>> + * Allocate an AVAmbientViewingEnv structure and set its fields to
>>> + * default values. The resulting struct can be freed using av_freep().
>>> + *
>>> + * @return An AVAmbientViewingEnv filled with default values or NULL
>>> + * on failure.
>>> + */
>>> +AVAmbientViewingEnv *av_ambient_viewing_env_alloc(size_t *size);
>>> +
>>> +/**
>>> + * Allocate a complete AVAmbientViewingEnv and add it to the frame.
>>> + *
Re: [FFmpeg-devel] [PATCH 2/2] avformat/matroskadec: avoid integer overflows in SAR computation
On Tue, Apr 05, 2022 at 11:59:44AM +0200, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2022-04-01 12:46:08)
> > This ignores >64bit
> > Alternatively we could support that if it occurs in reality
> >
> > Fixes: negation of -9223372036854775808
> > Fixes: integer overflows
> > Fixes:
> > 46072/clusterfuzz-testcase-minimized-ffmpeg_dem_MATROSKA_fuzzer-5029840966778880
> >
> > Found-by: continuous fuzzing process
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavformat/matroskadec.c | 13 -
> > 1 file changed, 8 insertions(+), 5 deletions(-)
> >
> > diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
> > index d97fc33d44..069fba6cf7 100644
> > --- a/libavformat/matroskadec.c
> > +++ b/libavformat/matroskadec.c
> > @@ -2886,11 +2886,14 @@ static int matroska_parse_tracks(AVFormatContext *s)
> > mkv_stereo_mode_display_mul(track->video.stereo_mode,
> > _width_mul, _height_mul);
> >
> > if (track->video.display_unit <
> > MATROSKA_VIDEO_DISPLAYUNIT_UNKNOWN) {
> > -av_reduce(>sample_aspect_ratio.num,
> > - >sample_aspect_ratio.den,
> > - st->codecpar->height *
> > track->video.display_width * display_width_mul,
> > - st->codecpar->width *
> > track->video.display_height * display_height_mul,
> > - INT_MAX);
> > +if (track->video.display_width &&
> > track->video.display_height &&
> > +st->codecpar->height * (int64_t)display_width_mul <
> > INT64_MAX / track->video.display_width &&
> > +st->codecpar->width * (int64_t)display_height_mul <
> > INT64_MAX / track->video.display_height)
>
> Why not move display_{width,height}_mul to the other side of the
> comparison and avoid wordsize assumptions? This is header parsing, so
> division performance impact should be negligible.
will do
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Take away the freedom of one citizen and you will be jailed, take away
the freedom of all citizens and you will be congratulated by your peers
in Parliament.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded architecture
On Mon, Apr 04, 2022 at 01:29:48PM +0200, Anton Khirnov wrote: > Hi, > this WIP patchset is the first major part of my ongoing work to change > ffmpeg.c architecture such that every > - demuxer > - decoder > - filtergraph > - encoder > - muxer > lives in its own thread. The advantages of doing this, beyond increased > throughput, would be enforced separation between these components, > making the code more local and easier to reason about. > > This set implements threading for muxers. My tentative plan is to > continue with encoders and then filters. The patches still need some > polishing, especially the last one. Two FATE tests do not yet pass, this > will be fixed in later iterations. > > Meanwhile, comments on the overall approach are especially welcome. I agree that cleanup/modularization to make the code easier to understand is a good idea! Didnt really look at the patchset yet. I assume these changes have no real disadvantage ? thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws. -- Plato signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 1/5] avutil: add ambient viewing environment metadata side data
Quoting Lynne (2022-04-05 21:00:24) > 5 Apr 2022, 17:32 by andreas.rheinha...@outlook.com: > Why is this side data type allocated, rather than what used to be > the standard, making the side data struct size const? Copy-paste? > > Are new fields expected to be added in the future? HDR mastering > metadata is also allocated, but we've never added any fields since > it was merged. Better to have the option and not use it than the converse. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 1/5] avutil: add ambient viewing environment metadata side data
5 Apr 2022, 17:32 by andreas.rheinha...@outlook.com:
> lance.lmw...@gmail.com:
>
>> From: Limin Wang
>>
>> Signed-off-by: Limin Wang
>> ---
>> libavutil/frame.c | 1 +
>> libavutil/frame.h | 6 +
>> libavutil/mastering_display_metadata.c | 23 +
>> libavutil/mastering_display_metadata.h | 45
>> ++
>> libavutil/version.h| 2 +-
>> 5 files changed, 76 insertions(+), 1 deletion(-)
>>
>> diff --git a/libavutil/frame.c b/libavutil/frame.c
>> index fbb869f..8882da2 100644
>> --- a/libavutil/frame.c
>> +++ b/libavutil/frame.c
>> @@ -815,6 +815,7 @@ const char *av_frame_side_data_name(enum
>> AVFrameSideDataType type)
>> case AV_FRAME_DATA_DETECTION_BBOXES:return "Bounding boxes for
>> object detection and classification";
>> case AV_FRAME_DATA_DOVI_RPU_BUFFER: return "Dolby Vision RPU
>> Data";
>> case AV_FRAME_DATA_DOVI_METADATA: return "Dolby Vision
>> Metadata";
>> +case AV_FRAME_DATA_AMBIENT_VIEWING_ENV: return "Ambient Viewing
>> Environment";
>> }
>> return NULL;
>> }
>> diff --git a/libavutil/frame.h b/libavutil/frame.h
>> index 33fac20..92413c9 100644
>> --- a/libavutil/frame.h
>> +++ b/libavutil/frame.h
>> @@ -209,6 +209,12 @@ enum AVFrameSideDataType {
>> * volume transform - CUVA 005.1-2021.
>> */
>> AV_FRAME_DATA_DYNAMIC_HDR_VIVID,
>> +
>> +/**
>> + * ambient viewing environment for a video frame, as described by
>> + * the AVAmbientViewingEnv
>> + */
>> +AV_FRAME_DATA_AMBIENT_VIEWING_ENV,
>> };
>>
>> enum AVActiveFormatDescription {
>> diff --git a/libavutil/mastering_display_metadata.c
>> b/libavutil/mastering_display_metadata.c
>> index 6069347..f094eab 100644
>> --- a/libavutil/mastering_display_metadata.c
>> +++ b/libavutil/mastering_display_metadata.c
>> @@ -64,3 +64,26 @@ AVContentLightMetadata
>> *av_content_light_metadata_create_side_data(AVFrame *fram
>>
>> return (AVContentLightMetadata *)side_data->data;
>> }
>> +
>> +AVAmbientViewingEnv *av_ambient_viewing_env_alloc(size_t *size)
>> +{
>> +AVAmbientViewingEnv *metadata = av_mallocz(sizeof(*metadata));
>> +
>> +if (size)
>> +*size = sizeof(*metadata);
>> +
>> +return metadata;
>> +}
>> +
>> +AVAmbientViewingEnv *av_ambient_viewing_env_create_side_data(AVFrame *frame)
>> +{
>> +AVFrameSideData *side_data = av_frame_new_side_data(frame,
>> +AV_FRAME_DATA_AMBIENT_VIEWING_ENV,
>> +sizeof(AVAmbientViewingEnv));
>> +if (!side_data)
>> +return NULL;
>> +
>> +memset(side_data->data, 0, sizeof(AVAmbientViewingEnv));
>> +
>> +return (AVAmbientViewingEnv *)side_data->data;
>> +}
>> diff --git a/libavutil/mastering_display_metadata.h
>> b/libavutil/mastering_display_metadata.h
>> index c23b07c..c1ba659 100644
>> --- a/libavutil/mastering_display_metadata.h
>> +++ b/libavutil/mastering_display_metadata.h
>> @@ -125,4 +125,49 @@ AVContentLightMetadata
>> *av_content_light_metadata_alloc(size_t *size);
>> */
>> AVContentLightMetadata *av_content_light_metadata_create_side_data(AVFrame
>> *frame);
>>
>> +/**
>> + * The characteristics of the nominal ambient viewing environment for
>> + * the display of the associated video content.
>> + * To be used as payload of a AVFrameSideData the appropriate type.
>> + *
>> + * @note The struct should be allocated with av_ambient_viewing_env_alloc()
>> + * and its size is not a part of the public ABI.
>> + */
>> +typedef struct AVAmbientViewingEnv {
>> +/**
>> + * specifies the environmental illuminance of the ambient viewing
>> + * environment in units of 0.0001 lux.
>> + * ambient_illuminance shall not be equal to 0.
>> + */
>> +uint32_t ambient_illuminance;
>> +/**
>> + * specify the normalized x and y chromaticity coordinates,
>> respectively,
>> + * of the environmental ambient light in the nominal viewing
>> environment,
>> + * according to the CIE 1931 definition of x and y as specified in ISO
>> + * 11664-1 (see also ISO 11664-3 and CIE 15), in normalized increments
>> of
>> + * 0.2. The values of ambient_light_x and ambient_light_y shall be
>> in
>> + * the range of 0 to 5
>> + */
>> +uint16_t ambient_light_x;
>> +uint16_t ambient_light_y;
>> +} AVAmbientViewingEnv;
>> +
>> +/**
>> + * Allocate an AVAmbientViewingEnv structure and set its fields to
>> + * default values. The resulting struct can be freed using av_freep().
>> + *
>> + * @return An AVAmbientViewingEnv filled with default values or NULL
>> + * on failure.
>> + */
>> +AVAmbientViewingEnv *av_ambient_viewing_env_alloc(size_t *size);
>> +
>> +/**
>> + * Allocate a complete AVAmbientViewingEnv and add it to the frame.
>> + *
>> + * @param frame The frame which side data is added to.
>> + *
>> + * @return The AVAmbientViewingEnv structure to be filled by caller.
>> + */
>>
Re: [FFmpeg-devel] [PATCH] avfilter/alimiter: Add "flush_buffer" option to flush the remaining valid data to the output
On Mon, Apr 4, 2022 at 3:28 PM Marton Balint wrote: > > > On Mon, 4 Apr 2022, Paul B Mahol wrote: > > > On Sun, Mar 27, 2022 at 11:41 PM Marton Balint wrote: > > > >> > >> > >> On Sat, 26 Mar 2022, Wang Cao wrote: > >> > >>> The change in the commit will add some samples to the end of the audio > >>> stream. The intention is to add a "zero_delay" option eventually to not > >>> have the delay in the begining the output from alimiter due to > >>> lookahead. > >> > >> I was very much suprised to see that the alimiter filter actually delays > >> the audio - as in extra samples are inserted in the beginning and some > >> samples are cut in the end. This trashes A-V sync, so it is a bug IMHO. > >> > >> So unless somebody has some valid usecase for the legacy way of > operation > >> I'd just simply change it to be "zero delay" without any additional user > >> option, in a single patch. > >> > > > > > > This is done by this patch in very complicated way and also it really > > should be optional. > > But why does it make sense to keep the current (IMHO buggy) operational > mode which adds silence in the beginning and trims the end? I understand > that the original implementation worked like this, but libavfilter has > packet timestamps and N:M filtering so there is absolutely no reason to > use an 1:1 implementation and live with its limitations. > Hello Paul and Marton, thank you so much for taking time to review my patch. I totally understand that my patch may seem a little bit complicated but I can show with a FATE test that if we set the alimiter to behave as a passthrough filter, the output frames will be the same from "framecrc" with my patch. The existing behavior will not work for all gapless audio processing. The complete patch to fix this issue is at https://patchwork.ffmpeg.org/project/ffmpeg/patch/20220330210314.2055201-1-wang...@google.com/ Regarding Paul's concern, I personally don't have any preference whether to put the patch as an extra option or not. With respect to the implementation, the patch is the best I can think of by preserving as much information as possible from input frames. I also understand it may break concept that "filter_frame" outputs one frame at a time. For alimiter with my patch, depending on the size of the lookahead buffer, it may take a few frames before one output frame can be generated. This is inevitable to compensate for the delay of the lookahead buffer. Thanks again for reviewing my patch and I'm looking forward to hearing from you :) -- Wang Cao | Software Engineer | wang...@google.com | 650-203-7807 <(650)%20203-7807> ___ 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] Provided support for MPEG-5 EVC (Essential Video Coding) codec
On 4/4/2022 9:29 AM, Dawid Kozinski wrote:
diff --git a/Changelog b/Changelog
index 5a32cf0d5c..21ebc11ff4 100644
--- a/Changelog
+++ b/Changelog
@@ -106,7 +106,8 @@ version 5.0:
- VideoToolbox ProRes encoder
- anlmf audio filter
- IMF demuxer (experimental)
-
+- eXtra-fast Essential Video Encoder (XEVE)
+- eXtra-fast Essential Video Decoder (XEVD)
version 4.4:
- AudioToolbox output device
diff --git a/configure b/configure
index 7a62f0c248..7491d3af6b 100755
--- a/configure
+++ b/configure
@@ -289,6 +289,8 @@ External library support:
--enable-libwebp enable WebP encoding via libwebp [no]
--enable-libx264 enable H.264 encoding via x264 [no]
--enable-libx265 enable HEVC encoding via x265 [no]
+ --enable-libxeve enable XEVE encoding via xeve [no]
+ --enable-libxevd enable XEVD decoding via xevd [no]
--enable-libxavs enable AVS encoding via xavs [no]
--enable-libxavs2enable AVS2 encoding via xavs2 [no]
--enable-libxcb enable X11 grabbing using XCB [autodetect]
@@ -1880,6 +1882,8 @@ EXTERNAL_LIBRARY_LIST="
openssl
pocketsphinx
vapoursynth
+libxeve
+libxevd
"
HWACCEL_AUTODETECT_LIBRARY_LIST="
@@ -2453,6 +2457,7 @@ CONFIG_EXTRA="
h264pred
h264qpel
hevcparse
+evcparse
This is unused, so remove it from here and below.
hpeldsp
huffman
huffyuvdsp
@@ -3252,6 +3257,7 @@ mpegaudio_parser_select="mpegaudioheader"
mpegvideo_parser_select="mpegvideo"
mpeg4video_parser_select="h263dsp mpegvideo qpeldsp"
vc1_parser_select="vc1dsp"
+evc_parser_select="evcparse"
# bitstream_filters
aac_adtstoasc_bsf_select="adts_header mpeg4audio"
@@ -3377,6 +3383,8 @@ libx264_encoder_select="atsc_a53"
libx264rgb_encoder_deps="libx264"
libx264rgb_encoder_select="libx264_encoder"
libx265_encoder_deps="libx265"
+libxeve_encoder_deps="libxeve"
+libxevd_decoder_deps="libxevd"
libxavs_encoder_deps="libxavs"
libxavs2_encoder_deps="libxavs2"
libxvid_encoder_deps="libxvid"
@@ -6659,6 +6667,8 @@ enabled libx264 && { check_pkg_config libx264 x264
"stdint.h x264.h" x
check_cpp_condition libx262 x264.h "X264_MPEG2"
enabled libx265 && require_pkg_config libx265 x265 x265.h x265_api_get
&&
require_cpp_condition libx265 x265.h "X265_BUILD >=
70"
+enabled libxeve && require_pkg_config libxeve "xeve >= 1.0.0"
"xeve.h" xeve_encode
+enabled libxevd && require_pkg_config libxevd "xevd >= 1.0.0"
"xevd.h" xevd_decode
enabled libxavs && require libxavs "stdint.h xavs.h" xavs_encoder_encode
"-lxavs $pthreads_extralibs $libm_extralibs"
enabled libxavs2 && require_pkg_config libxavs2 "xavs2 >= 1.3.0"
"stdint.h xavs2.h" xavs2_api_get
enabled libxvid && require libxvid xvid.h xvid_global -lxvidcore
[...]
diff --git a/libavcodec/evc_parser.c b/libavcodec/evc_parser.c
new file mode 100644
index 00..f68c4cc3a0
--- /dev/null
+++ b/libavcodec/evc_parser.c
@@ -0,0 +1,452 @@
+/*
+ * EVC AVC format parser
+ *
+ * Copyright (C) 2021 Dawid Kozinski
+ *
+ * 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 "libavutil/common.h"
+
+#include "golomb.h"
+#include "parser.h"
+#include "xevd.h"
A parser must not depend on external libraries or headers.
+#include
+
+#define EVC_NAL_HEADER_SIZE 2 /* byte */
+#define MAX_SPS_CNT 16 /* defined value in EVC standard */
+
+typedef struct _EVCParserSPS {
+int sps_id;
+int profile_idc;
+int level_idc;
+int chroma_format_idc;
+int pic_width_in_luma_samples;
+int pic_height_in_luma_samples;
+int bit_depth_luma;
+int bit_depth_chroma;
+
+int picture_cropping_flag;
+int picture_crop_left_offset;
+int picture_crop_right_offset;
+int picture_crop_top_offset;
+int picture_crop_bottom_offset;
+} EVCParserSPS;
+
+typedef struct EVCParserContext {
+ParseContext pc;
+EVCParserSPS sps[MAX_SPS_CNT];
+int is_avc;
+int nal_length_size;
+int to_read;
+int incomplete_nalu_prefix_read; // The flag is set to 1 when incomplete
NAL unit prefix has been read
+
+int parsed_extradata;
+
+int
Re: [FFmpeg-devel] [PATCH] Provided support for MPEG-5 EVC (Essential Video Coding) codec
Dawid Kozinski: > ### > 1. Genaral info > ### > > The patch provided below contains integration layer between ffmpeg framework > and EVC codec implementation. > In nutshell it enable using EVC codec (encoding, decoding) by the means of > ffmpeg API. > I'd like to emphasize one more time, that (as mentioned before) that it isn't > codec implementation. The provided implementation serves as integration layer > between ffmpeg framework and EVC codec. > > EVC codec has been published as two separate libraries. > The first one called XEVE (eXtra-fast Essential Video Encoder) is an > opensource MPEG-5 EVC encoder. > The second one called XEVD (eXtra-fast Essential Video Decoder ) is an > opensource MPEG-5 EVC decoder. > For more information on both libraries please follow the links below: > * https://github.com/mpeg5/xeve > * https://github.com/mpeg5/xevd Patches for decoder and encoder should be separated; and the changes to libavformat should also be in a separate patch (or even patches). > > The patch provided below should be apply to FFmpeg 5.0 release (commit > 911d7f167c30f27a042b8558dfcf012b3c20e858 release/5.0) There is zero chance that new components are added to an already released branch. You need to rebase this patch on top of master if you want it mainlined. > > ### > 2. Building > ### > > 3.1. Download, build and install dependencies There is no need to duplicate the build instructions for external libraries in this commit message; providing the link to where the library can be found is enough. (This is not marked as WIP, so I am reviewing this as if you wanted this to be applied as is (with this commit message); if this is not the intention of this submission and you never intended for this to be part of the actually applied commit message, you can ignore this comment and the next comments.) > --- > 2.2. Build ffmpeg with libxeve and libxevd > --- > It is required ffmpeg to be configfured with --enable-libxeve and > --enable-libxevd Mentioning this in the commit message is unnecessary (the reader of ffmpeg commit messages is supposed to know a bit about ffmpeg). > ### > 3. Examples > ### > > Please find below examples on how to use EVC coded with ffmpeg commandline > tool. > > (All samples are available in > https://drive.google.com/drive/folders/1YtCLlSuTAjpLziTKI_QBuQrIOm2ss9LB?usp=sharing > ) > > #!/bin/bash > #=== > #(YUV420P) -> (EVC) > #=== > ffmpeg -f rawvideo -pix_fmt yuv420p -s:v 352x288 -r 30 -i Test_Video_cif.yuv > -c:v libxeve -f rawvideo Test_Video_cif.yuv.evc > ffplay -autoexit Test_Video_cif.yuv.evc These examples are excessive; and they are completely unnecessary, as they don't really provide anything useful given that a reader of ffmpeg's commit messages is supposed to know trivial ffmpeg command line usage. > > #=== > #(YUV420P10LE) -> (EVC) > #=== > ffmpeg -f rawvideo -pix_fmt yuv420p10le -s:v 352x288 -r 30 -i > Test_Video_cif_10le.yuv -c:v libxeve -f rawvideo Test_Video_cif_10le.yuv.evc > ffplay -autoexit Test_Video_cif_10le.yuv.evc > > #=== > #(EVC) -> (YUV420P) > #=== > ffmpeg -i Test_Video_cif.yuv.evc -pix_fmt yuv420p Test_Video_cif.evc.yuv > ffplay -autoexit -f rawvideo -pixel_format yuv420p -video_size 352x288 > Test_Video_cif.evc.yuv > > #=== > #(EVC) -> (YUV420Pi10LE) > #=== > ffmpeg -i Test_Video_cif_10le.yuv.evc -pix_fmt yuv420p10le > Test_Video_cif_10le.evc.yuv > ffplay -autoexit -f rawvideo -pixel_format yuv420p10le -video_size 352x288 > Test_Video_cif_10le.evc.yuv > > #=== > #(YUV420P) -> (MP4) > #=== > ffmpeg -f rawvideo -pix_fmt yuv420p -s:v 352x288 -r 30 -i Test_Video_cif.yuv > -c:v libxeve -f rawvideo Test_Video_cif.yuv.mp4 > ffplay -autoexit Test_Video_cif.yuv.mp4 > > #=== > #(YUV420P10LE) -> (MP4) > #=== > ffmpeg -f rawvideo -pix_fmt yuv420p10le -s:v 352x288 -r 30 -i > Test_Video_cif_10le.yuv -c:v libxeve -f rawvideo Test_Video_cif_10le.yuv.mp4 > ffplay -autoexit Test_Video_cif_10le.yuv.mp4 > > #=== > #(MP4) -> (YUV420P) > #=== > ffmpeg -i Test_Video_cif.yuv.mp4 -f rawvideo -pix_fmt yuv420p > Test_Video_cif.mp4.yuv > ffplay -autoexit -f rawvideo -pixel_format yuv420p -video_size 352x288 > Test_Video_cif.mp4.yuv > >
[FFmpeg-devel] [PATCH v13 4/4] avformat/image2: add Jpeg XL as image2 format
This commit adds support to libavformat for muxing
and demuxing Jpeg XL images as image2 streams.
---
MAINTAINERS| 1 +
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/img2.c | 1 +
libavformat/img2dec.c | 18 ++
libavformat/img2enc.c | 6 +-
libavformat/jpegxl_probe.c | 393 +
libavformat/jpegxl_probe.h | 32 +++
libavformat/mov.c | 1 +
libavformat/version.h | 4 +-
10 files changed, 453 insertions(+), 5 deletions(-)
create mode 100644 libavformat/jpegxl_probe.c
create mode 100644 libavformat/jpegxl_probe.h
diff --git a/MAINTAINERS b/MAINTAINERS
index faea84ebf1..46723972dc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -439,6 +439,7 @@ Muxers/Demuxers:
ipmovie.c Mike Melanson
ircam*Paul B Mahol
iss.c Stefan Gehrer
+ jpegxl_probe.*Leo Izen
jvdec.c Peter Ross
kvag.cZane van Iperen
libmodplug.c Clément Bœsch
diff --git a/libavformat/Makefile b/libavformat/Makefile
index d7182d6bd8..beecdf5a66 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -272,6 +272,7 @@ OBJS-$(CONFIG_IMAGE_GIF_PIPE_DEMUXER) += img2dec.o
img2.o
OBJS-$(CONFIG_IMAGE_J2K_PIPE_DEMUXER) += img2dec.o img2.o
OBJS-$(CONFIG_IMAGE_JPEG_PIPE_DEMUXER)+= img2dec.o img2.o
OBJS-$(CONFIG_IMAGE_JPEGLS_PIPE_DEMUXER) += img2dec.o img2.o
+OBJS-$(CONFIG_IMAGE_JPEGXL_PIPE_DEMUXER) += img2dec.o img2.o jpegxl_probe.o
OBJS-$(CONFIG_IMAGE_PAM_PIPE_DEMUXER) += img2dec.o img2.o
OBJS-$(CONFIG_IMAGE_PBM_PIPE_DEMUXER) += img2dec.o img2.o
OBJS-$(CONFIG_IMAGE_PCX_PIPE_DEMUXER) += img2dec.o img2.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 587ad59b3c..941f3643f8 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -510,6 +510,7 @@ extern const AVInputFormat ff_image_gif_pipe_demuxer;
extern const AVInputFormat ff_image_j2k_pipe_demuxer;
extern const AVInputFormat ff_image_jpeg_pipe_demuxer;
extern const AVInputFormat ff_image_jpegls_pipe_demuxer;
+extern const AVInputFormat ff_image_jpegxl_pipe_demuxer;
extern const AVInputFormat ff_image_pam_pipe_demuxer;
extern const AVInputFormat ff_image_pbm_pipe_demuxer;
extern const AVInputFormat ff_image_pcx_pipe_demuxer;
diff --git a/libavformat/img2.c b/libavformat/img2.c
index 4153102c92..13b1b997b8 100644
--- a/libavformat/img2.c
+++ b/libavformat/img2.c
@@ -87,6 +87,7 @@ const IdStrMap ff_img_tags[] = {
{ AV_CODEC_ID_GEM,"img" },
{ AV_CODEC_ID_GEM,"ximg" },
{ AV_CODEC_ID_GEM,"timg" },
+{ AV_CODEC_ID_JPEGXL, "jxl" },
{ AV_CODEC_ID_NONE, NULL }
};
diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c
index b9c06c5b54..560d464dff 100644
--- a/libavformat/img2dec.c
+++ b/libavformat/img2dec.c
@@ -36,6 +36,7 @@
#include "avio_internal.h"
#include "internal.h"
#include "img2.h"
+#include "jpegxl_probe.h"
#include "libavcodec/mjpeg.h"
#include "libavcodec/xwd.h"
#include "subtitles.h"
@@ -836,6 +837,22 @@ static int jpegls_probe(const AVProbeData *p)
return 0;
}
+static int jpegxl_probe(const AVProbeData *p)
+{
+const uint8_t *b = p->buf;
+
+/* ISOBMFF-based container */
+/* 0x4a584c20 == "JXL " */
+if (AV_RL64(b) == FF_JPEGXL_CONTAINER_SIGNATURE_LE)
+return AVPROBE_SCORE_EXTENSION + 1;
+/* Raw codestreams all start with 0xff0a */
+if (AV_RL16(b) != FF_JPEGXL_CODESTREAM_SIGNATURE_LE)
+return 0;
+if (ff_jpegxl_verify_codestream_header(p->buf, p->buf_size) >= 0)
+return AVPROBE_SCORE_MAX - 2;
+return 0;
+}
+
static int pcx_probe(const AVProbeData *p)
{
const uint8_t *b = p->buf;
@@ -1165,6 +1182,7 @@ IMAGEAUTO_DEMUXER(gif, GIF)
IMAGEAUTO_DEMUXER_EXT(j2k, JPEG2000, J2K)
IMAGEAUTO_DEMUXER_EXT(jpeg, MJPEG, JPEG)
IMAGEAUTO_DEMUXER(jpegls,JPEGLS)
+IMAGEAUTO_DEMUXER(jpegxl,JPEGXL)
IMAGEAUTO_DEMUXER(pam, PAM)
IMAGEAUTO_DEMUXER(pbm, PBM)
IMAGEAUTO_DEMUXER(pcx, PCX)
diff --git a/libavformat/img2enc.c b/libavformat/img2enc.c
index 9b3b8741c8..e6ec6a50aa 100644
--- a/libavformat/img2enc.c
+++ b/libavformat/img2enc.c
@@ -263,9 +263,9 @@ static const AVClass img2mux_class = {
const AVOutputFormat ff_image2_muxer = {
.name = "image2",
.long_name = NULL_IF_CONFIG_SMALL("image2 sequence"),
-.extensions =
"bmp,dpx,exr,jls,jpeg,jpg,ljpg,pam,pbm,pcx,pfm,pgm,pgmyuv,png,"
-
"ppm,sgi,tga,tif,tiff,jp2,j2c,j2k,xwd,sun,ras,rs,im1,im8,im24,"
- "sunras,xbm,xface,pix,y",
+.extensions =
"bmp,dpx,exr,jls,jpeg,jpg,jxl,ljpg,pam,pbm,pcx,pfm,pgm,pgmyuv,"
+
[FFmpeg-devel] [PATCH v13 3/4] avcodec/libjxl: add Jpeg XL encoding via libjxl
This commit adds encoding support to libavcodec
for Jpeg XL images via the external library libjxl.
---
configure | 3 +-
libavcodec/Makefile| 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/libjxlenc.c | 379 +
4 files changed, 383 insertions(+), 1 deletion(-)
create mode 100644 libavcodec/libjxlenc.c
diff --git a/configure b/configure
index 969b13eba3..85a1a8b53c 100755
--- a/configure
+++ b/configure
@@ -240,7 +240,7 @@ External library support:
--enable-libiec61883 enable iec61883 via libiec61883 [no]
--enable-libilbc enable iLBC de/encoding via libilbc [no]
--enable-libjack enable JACK audio sound server [no]
- --enable-libjxl enable JPEG XL decoding via libjxl [no]
+ --enable-libjxl enable JPEG XL de/encoding via libjxl [no]
--enable-libklvanc enable Kernel Labs VANC processing [no]
--enable-libkvazaar enable HEVC encoding via libkvazaar [no]
--enable-liblensfun enable lensfun lens correction [no]
@@ -3332,6 +3332,7 @@ libgsm_ms_encoder_deps="libgsm"
libilbc_decoder_deps="libilbc"
libilbc_encoder_deps="libilbc"
libjxl_decoder_deps="libjxl libjxl_threads"
+libjxl_encoder_deps="libjxl libjxl_threads"
libkvazaar_encoder_deps="libkvazaar"
libmodplug_demuxer_deps="libmodplug"
libmp3lame_encoder_deps="libmp3lame"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index c6d0ae4107..e18ad872b4 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1060,6 +1060,7 @@ OBJS-$(CONFIG_LIBGSM_MS_ENCODER) += libgsmenc.o
OBJS-$(CONFIG_LIBILBC_DECODER)+= libilbc.o
OBJS-$(CONFIG_LIBILBC_ENCODER)+= libilbc.o
OBJS-$(CONFIG_LIBJXL_DECODER) += libjxldec.o libjxl.o
+OBJS-$(CONFIG_LIBJXL_ENCODER) += libjxlenc.o libjxl.o
OBJS-$(CONFIG_LIBKVAZAAR_ENCODER) += libkvazaar.o
OBJS-$(CONFIG_LIBMP3LAME_ENCODER) += libmp3lame.o
OBJS-$(CONFIG_LIBOPENCORE_AMRNB_DECODER) += libopencore-amr.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index a9cd69dfce..db92fb7af5 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -750,6 +750,7 @@ extern const FFCodec ff_libgsm_ms_decoder;
extern const FFCodec ff_libilbc_encoder;
extern const FFCodec ff_libilbc_decoder;
extern const FFCodec ff_libjxl_decoder;
+extern const FFCodec ff_libjxl_encoder;
extern const FFCodec ff_libmp3lame_encoder;
extern const FFCodec ff_libopencore_amrnb_encoder;
extern const FFCodec ff_libopencore_amrnb_decoder;
diff --git a/libavcodec/libjxlenc.c b/libavcodec/libjxlenc.c
new file mode 100644
index 00..deacc0f1f8
--- /dev/null
+++ b/libavcodec/libjxlenc.c
@@ -0,0 +1,379 @@
+/*
+ * JPEG XL encoding support via libjxl
+ * Copyright (c) 2021 Leo Izen
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file
+ * JPEG XL encoder using libjxl
+ */
+
+#include "libavutil/avutil.h"
+#include "libavutil/error.h"
+#include "libavutil/frame.h"
+#include "libavutil/libm.h"
+#include "libavutil/opt.h"
+#include "libavutil/pixdesc.h"
+#include "libavutil/pixfmt.h"
+#include "libavutil/version.h"
+
+#include "avcodec.h"
+#include "codec_internal.h"
+
+#include
+#include
+#include "libjxl.h"
+
+typedef struct LibJxlEncodeContext {
+AVClass *class;
+void *runner;
+JxlEncoder *encoder;
+JxlEncoderFrameSettings *options;
+int effort;
+float distance;
+int modular;
+uint8_t *buffer;
+size_t buffer_size;
+} LibJxlEncodeContext;
+
+/**
+ * Map a quality setting for -qscale roughly from libjpeg
+ * quality numbers to libjxl's butteraugli distance for
+ * photographic content.
+ *
+ * Setting distance explicitly is preferred, but this will
+ * allow qscale to be used as a fallback.
+ *
+ * This function is continuous and injective on [0, 100] which
+ * makes it monotonic.
+ *
+ * @param quality 0.0 to 100.0 quality setting, libjpeg quality
+ * @return Butteraugli distance between 0.0 and 15.0
+ */
+static float quality_to_distance(float quality)
+{
+if (quality >= 100.0)
+return 0.0;
+else if (quality >= 90.0)
+return (100.0 - quality) * 0.10;
+else if (quality >= 30.0)
+return 0.1 + (100.0 - quality) * 0.09;
+
[FFmpeg-devel] [PATCH v13 2/4] avcodec/libjxl: add Jpeg XL decoding via libjxl
This commit adds decoding support to libavcodec
for Jpeg XL images via the external library libjxl.
---
MAINTAINERS | 1 +
configure | 5 +
doc/general_contents.texi | 7 +
libavcodec/Makefile | 1 +
libavcodec/allcodecs.c| 1 +
libavcodec/libjxl.c | 70 ++
libavcodec/libjxl.h | 48 +++
libavcodec/libjxldec.c| 276 ++
8 files changed, 409 insertions(+)
create mode 100644 libavcodec/libjxl.c
create mode 100644 libavcodec/libjxl.h
create mode 100644 libavcodec/libjxldec.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 859a5005d4..faea84ebf1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -194,6 +194,7 @@ Codecs:
libcodec2.c Tomas Härdin
libdirac* David Conrad
libdavs2.cHuiwen Ren
+ libjxl*.c, libjxl.h Leo Izen
libgsm.c Michel Bardiaux
libkvazaar.c Arttu Ylä-Outinen
libopenh264enc.c Martin Storsjo, Linjie Fu
diff --git a/configure b/configure
index e4d36aa639..969b13eba3 100755
--- a/configure
+++ b/configure
@@ -240,6 +240,7 @@ External library support:
--enable-libiec61883 enable iec61883 via libiec61883 [no]
--enable-libilbc enable iLBC de/encoding via libilbc [no]
--enable-libjack enable JACK audio sound server [no]
+ --enable-libjxl enable JPEG XL decoding via libjxl [no]
--enable-libklvanc enable Kernel Labs VANC processing [no]
--enable-libkvazaar enable HEVC encoding via libkvazaar [no]
--enable-liblensfun enable lensfun lens correction [no]
@@ -1833,6 +1834,7 @@ EXTERNAL_LIBRARY_LIST="
libiec61883
libilbc
libjack
+libjxl
libklvanc
libkvazaar
libmodplug
@@ -3329,6 +3331,7 @@ libgsm_ms_decoder_deps="libgsm"
libgsm_ms_encoder_deps="libgsm"
libilbc_decoder_deps="libilbc"
libilbc_encoder_deps="libilbc"
+libjxl_decoder_deps="libjxl libjxl_threads"
libkvazaar_encoder_deps="libkvazaar"
libmodplug_demuxer_deps="libmodplug"
libmp3lame_encoder_deps="libmp3lame"
@@ -6541,6 +6544,8 @@ enabled libgsm&& { for gsm_hdr in "gsm.h"
"gsm/gsm.h"; do
check_lib libgsm "${gsm_hdr}" gsm_create
-lgsm && break;
done || die "ERROR: libgsm not found"; }
enabled libilbc && require libilbc ilbc.h WebRtcIlbcfix_InitDecode
-lilbc $pthreads_extralibs
+enabled libjxl&& require_pkg_config libjxl "libjxl >= 0.7.0"
jxl/decode.h JxlDecoderVersion &&
+ require_pkg_config libjxl_threads "libjxl_threads
>= 0.7.0" jxl/thread_parallel_runner.h JxlThreadParallelRunner
enabled libklvanc && require libklvanc libklvanc/vanc.h
klvanc_context_create -lklvanc
enabled libkvazaar&& require_pkg_config libkvazaar "kvazaar >= 0.8.1"
kvazaar.h kvz_api_get
enabled liblensfun&& require_pkg_config liblensfun lensfun lensfun.h
lf_db_new
diff --git a/doc/general_contents.texi b/doc/general_contents.texi
index fcd9da1b34..a893347fbe 100644
--- a/doc/general_contents.texi
+++ b/doc/general_contents.texi
@@ -171,6 +171,13 @@ Go to @url{https://github.com/TimothyGu/libilbc} and
follow the instructions for
installing the library. Then pass @code{--enable-libilbc} to configure to
enable it.
+@section libjxl
+
+JPEG XL is an image format intended to fully replace legacy JPEG for an
extended
+period of life. See @url{https://jpegxl.info/} for more information, and see
+@url{https://github.com/libjxl/libjxl} for the library source. You can pass
+@code{--enable-libjxl} to configure in order enable the libjxl wrapper.
+
@section libvpx
FFmpeg can make use of the libvpx library for VP8/VP9 decoding and encoding.
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index fb8b0e824b..c6d0ae4107 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1059,6 +1059,7 @@ OBJS-$(CONFIG_LIBGSM_MS_DECODER) += libgsmdec.o
OBJS-$(CONFIG_LIBGSM_MS_ENCODER) += libgsmenc.o
OBJS-$(CONFIG_LIBILBC_DECODER)+= libilbc.o
OBJS-$(CONFIG_LIBILBC_ENCODER)+= libilbc.o
+OBJS-$(CONFIG_LIBJXL_DECODER) += libjxldec.o libjxl.o
OBJS-$(CONFIG_LIBKVAZAAR_ENCODER) += libkvazaar.o
OBJS-$(CONFIG_LIBMP3LAME_ENCODER) += libmp3lame.o
OBJS-$(CONFIG_LIBOPENCORE_AMRNB_DECODER) += libopencore-amr.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 22d56760ec..a9cd69dfce 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -749,6 +749,7 @@ extern const FFCodec ff_libgsm_ms_encoder;
extern const FFCodec ff_libgsm_ms_decoder;
extern const FFCodec ff_libilbc_encoder;
extern const FFCodec ff_libilbc_decoder;
+extern const FFCodec ff_libjxl_decoder;
extern const FFCodec ff_libmp3lame_encoder;
extern const FFCodec
[FFmpeg-devel] [PATCH v13 1/4] avcodec/jpegxl: add Jpeg XL image codec
This commit adds support to libavcodec to read
encoded Jpeg XL images. Jpeg XL is intended to be an
extended-life replacement to legacy mjpeg.
---
MAINTAINERS | 1 +
libavcodec/codec_desc.c | 9 +
libavcodec/codec_id.h | 1 +
libavcodec/version.h| 2 +-
4 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8c71605339..859a5005d4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -618,6 +618,7 @@ Haihao Xiang (haihao) 1F0C 31E8 B4FE F7A4 4DC1 DC99
E0F5 76D4 76FC 437F
Jaikrishnan Menon 61A1 F09F 01C9 2D45 78E1 C862 25DC 8831 AF70 D368
James Almer 7751 2E8C FD94 A169 57E6 9A7A 1463 01AD 7376 59E0
Jean Delvare 7CA6 9F44 60F1 BDC4 1FD2 C858 A552 6B9B B3CD 4E6A
+Leo Izen (thebombzen) B6FD 3CFC 7ACF 83FC 9137 6945 5A71 C331 FD2F A19A
Loren Merritt ABD9 08F4 C920 3F65 D8BE 35D7 1540 DAA7 060F 56DE
Lynne FE50 139C 6805 72CA FD52 1F8D A2FE A5F0 3F03 4464
Michael Niedermayer 9FF2 128B 147E F673 0BAD F133 611E C787 040B 0FAB
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 81f3b3c640..1b82870aaa 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -1863,6 +1863,15 @@ static const AVCodecDescriptor codec_descriptors[] = {
.long_name = NULL_IF_CONFIG_SMALL("GEM Raster image"),
.props = AV_CODEC_PROP_LOSSY,
},
+{
+.id= AV_CODEC_ID_JPEGXL,
+.type = AVMEDIA_TYPE_VIDEO,
+.name = "jpegxl",
+.long_name = NULL_IF_CONFIG_SMALL("JPEG XL"),
+.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSY |
+ AV_CODEC_PROP_LOSSLESS,
+.mime_types= MT("image/jxl"),
+},
/* various PCM "codecs" */
{
diff --git a/libavcodec/codec_id.h b/libavcodec/codec_id.h
index 3ffb9bd22e..dbc4f3a208 100644
--- a/libavcodec/codec_id.h
+++ b/libavcodec/codec_id.h
@@ -308,6 +308,7 @@ enum AVCodecID {
AV_CODEC_ID_SIMBIOSIS_IMX,
AV_CODEC_ID_SGA_VIDEO,
AV_CODEC_ID_GEM,
+AV_CODEC_ID_JPEGXL,
/* various PCM "codecs" */
AV_CODEC_ID_FIRST_AUDIO = 0x1, ///< A dummy id pointing at the
start of audio codecs
diff --git a/libavcodec/version.h b/libavcodec/version.h
index a744e7469f..26ee41eb1f 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -29,7 +29,7 @@
#include "version_major.h"
-#define LIBAVCODEC_VERSION_MINOR 25
+#define LIBAVCODEC_VERSION_MINOR 26
#define LIBAVCODEC_VERSION_MICRO 100
#define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
--
2.35.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 v13 0/4] Jpeg XL Patch Set
This patchset adds the Jpeg XL Image format as well as a decoder and encoder for it based on the external reference implementation library, libjxl. Changes: v13: - Make changes requested by Anton and Andreas from v12 v12: - Remove the parser in order to avoid avpriv in the ABI - Add a lightweight version of it to avformat to help the prober - Remove the FATE test for the parser which no longer exists v11: - Fix regression I introduced in v10 with skipping boxes v10: - Make changes requested by Andreas Reinhardt from v9 Leo Izen (4): avcodec/jpegxl: add Jpeg XL image codec avcodec/libjxl: add Jpeg XL decoding via libjxl avcodec/libjxl: add Jpeg XL encoding via libjxl avformat/image2: add Jpeg XL as image2 format MAINTAINERS| 3 + configure | 6 + doc/general_contents.texi | 7 + libavcodec/Makefile| 2 + libavcodec/allcodecs.c | 2 + libavcodec/codec_desc.c| 9 + libavcodec/codec_id.h | 1 + libavcodec/libjxl.c| 70 +++ libavcodec/libjxl.h| 48 + libavcodec/libjxldec.c | 276 ++ libavcodec/libjxlenc.c | 379 +++ libavcodec/version.h | 2 +- libavformat/Makefile | 1 + libavformat/allformats.c | 1 + libavformat/img2.c | 1 + libavformat/img2dec.c | 18 ++ libavformat/img2enc.c | 6 +- libavformat/jpegxl_probe.c | 393 + libavformat/jpegxl_probe.h | 32 +++ libavformat/mov.c | 1 + libavformat/version.h | 4 +- 21 files changed, 1256 insertions(+), 6 deletions(-) create mode 100644 libavcodec/libjxl.c create mode 100644 libavcodec/libjxl.h create mode 100644 libavcodec/libjxldec.c create mode 100644 libavcodec/libjxlenc.c create mode 100644 libavformat/jpegxl_probe.c create mode 100644 libavformat/jpegxl_probe.h -- 2.35.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 v12 1/1] avformat: Add IPFS protocol support.
On Mon, Apr 4, 2022 at 12:39 AM Mark Gaiser wrote: > This patch adds support for: > - ffplay ipfs:// > - ffplay ipns:// > > IPFS data can be played from so called "ipfs gateways". > A gateway is essentially a webserver that gives access to the > distributed IPFS network. > > This protocol support (ipfs and ipns) therefore translates > ipfs:// and ipns:// to a http:// url. This resulting url is > then handled by the http protocol. It could also be https > depending on the gateway provided. > > To use this protocol, a gateway must be provided. > If you do nothing it will try to find it in your > $HOME/.ipfs/gateway file. The ways to set it manually are: > 1. Define a -gateway to the gateway. > 2. Define $IPFS_GATEWAY with the full http link to the gateway. > 3. Define $IPFS_PATH and point it to the IPFS data path. > 4. Have IPFS running in your local user folder (under $HOME/.ipfs). > > Signed-off-by: Mark Gaiser > --- > configure | 2 + > doc/protocols.texi| 30 > libavformat/Makefile | 2 + > libavformat/ipfsgateway.c | 326 ++ > libavformat/protocols.c | 2 + > 5 files changed, 362 insertions(+) > create mode 100644 libavformat/ipfsgateway.c > > diff --git a/configure b/configure > index e4d36aa639..55af90957a 100755 > --- a/configure > +++ b/configure > @@ -3579,6 +3579,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" > > # external library protocols > libamqp_protocol_deps="librabbitmq" > diff --git a/doc/protocols.texi b/doc/protocols.texi > index d207df0b52..7c9c0a4808 100644 > --- a/doc/protocols.texi > +++ b/doc/protocols.texi > @@ -2025,5 +2025,35 @@ decoding errors. > > @end table > > +@section ipfs > + > +InterPlanetary File System (IPFS) protocol support. One can access files > stored > +on the IPFS network through so called gateways. Those are http(s) > endpoints. > +This protocol wraps the IPFS native protocols (ipfs:// and ipns://) to be > send > +to such a gateway. Users can (and should) host their own node which means > this > +protocol will use your local machine gateway to access files on the IPFS > network. > + > +If a user doesn't have a node of their own then the public gateway > dweb.link is > +used by default. > + > +You can use this protocol in 2 ways. Using IPFS: > +@example > +ffplay ipfs://QmbGtJg23skhvFmu9mJiePVByhfzu5rwo74MEkVDYAmF5T > +@end example > + > +Or the IPNS protocol (IPNS is mutable IPFS): > +@example > +ffplay ipns://QmbGtJg23skhvFmu9mJiePVByhfzu5rwo74MEkVDYAmF5T > +@end example > + > +You can also change the gateway to be used: > + > +@table @option > + > +@item gateway > +Defines the gateway to use. When nothing is provided the protocol will > first try > +your local gateway. If that fails dweb.link will be used. > + > +@end table > > @c man end PROTOCOLS > diff --git a/libavformat/Makefile b/libavformat/Makefile > index d7182d6bd8..e3233fd7ac 100644 > --- a/libavformat/Makefile > +++ b/libavformat/Makefile > @@ -660,6 +660,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 > 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 > new file mode 100644 > index 00..e01eb2f9a3 > --- /dev/null > +++ b/libavformat/ipfsgateway.c > @@ -0,0 +1,326 @@ > +/* > + * IPFS and IPNS protocol support through IPFS Gateway. > + * Copyright (c) 2022 Mark Gaiser > + * > + * 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 "libavutil/avstring.h" > +#include "libavutil/opt.h" > +#include > +#include "os_support.h" > +#include "url.h" > + > +typedef struct
Re: [FFmpeg-devel] [PATCH] lavc/flacdec: Increase residual limit from INT_MAX to UINT_MAX
Op di 5 apr. 2022 18:04 schreef Andreas Rheinhardt < andreas.rheinha...@outlook.com>: > > Wouldn't it be possible to use unsigned for real_limit? > The limit is passed to get_ur_golomb_jpegls which takes int. In that function, the limit is subtracted from, and the function is used by quite a few other codecs, so changing it seems risky. Besides creating a cleaner flacdec.c, it wouldn't achieve much either. For tmp = 0 or tmp = 1, reaching this limit means the file contains a INT_MAX or INT_MAX/2 unary coded, so a single symbol of either 2GiB or 1GiB in 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] lavc/flacdec: Increase residual limit from INT_MAX to UINT_MAX
Martijn van Beurden:
> ---
> libavcodec/flacdec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/flacdec.c b/libavcodec/flacdec.c
> index dd6026f9de..cb32d7cae8 100644
> --- a/libavcodec/flacdec.c
> +++ b/libavcodec/flacdec.c
> @@ -260,7 +260,7 @@ static int decode_residuals(FLACContext *s, int32_t
> *decoded, int pred_order)
> for (; i < samples; i++)
> *decoded++ = get_sbits_long(, tmp);
> } else {
> -int real_limit = tmp ? (INT_MAX >> tmp) + 2 : INT_MAX;
> +int real_limit = (tmp > 1) ? (INT_MAX >> (tmp - 1)) + 2 :
> INT_MAX;
> for (; i < samples; i++) {
> int v = get_sr_golomb_flac(, tmp, real_limit, 1);
> if (v == 0x8000){
Wouldn't it be possible to use unsigned for real_limit?
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] avfilter/src_movie: add option to set decoding thread type
On Tue, Apr 5, 2022 at 4:29 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Paul B Mahol:
> > Signed-off-by: Paul B Mahol
> > ---
> > doc/filters.texi| 3 +++
> > libavfilter/src_movie.c | 11 +--
> > 2 files changed, 12 insertions(+), 2 deletions(-)
> >
> > diff --git a/doc/filters.texi b/doc/filters.texi
> > index 636c80dbff..a13977edd8 100644
> > --- a/doc/filters.texi
> > +++ b/doc/filters.texi
> > @@ -29317,6 +29317,9 @@ timestamps.
> > @item dec_threads
> > Specifies the number of threads for decoding
> >
> > +@item dec_thread_type
> > +Specifies the thread type for decoding.
> > +
> > @item format_opts
> > Specify format options for the opened file. Format options can be
> specified
> > as a list of @var{key}=@var{value} pairs separated by ':'. The
> following example
> > diff --git a/libavfilter/src_movie.c b/libavfilter/src_movie.c
> > index bc7b0d37af..08cba437bf 100644
> > --- a/libavfilter/src_movie.c
> > +++ b/libavfilter/src_movie.c
> > @@ -72,6 +72,7 @@ typedef struct MovieContext {
> > int64_t discontinuity_threshold;
> > int64_t ts_offset;
> > int dec_threads;
> > +int thread_type;
> > int got_eagain;
> > int got_wanted;
> >
> > @@ -99,6 +100,10 @@ static const AVOption movie_options[]= {
> > { "loop", "set loop count", OFFSET(loop_count),
> AV_OPT_TYPE_INT,{.i64 = 1}, 0,INT_MAX, FLAGS },
> > { "discontinuity", "set discontinuity threshold",
> OFFSET(discontinuity_threshold), AV_OPT_TYPE_DURATION, {.i64 = 0}, 0,
> INT64_MAX, FLAGS },
> > { "dec_threads", "set the number of threads for decoding",
> OFFSET(dec_threads), AV_OPT_TYPE_INT, {.i64 = 0}, 0, INT_MAX, FLAGS },
> > +{ "dec_thread_type","set the type of threads for decoding",
> OFFSET(thread_type), AV_OPT_TYPE_INT, {.i64 = 0}, 0, 2, FLAGS, .unit =
> "thread_type" },
> > +{ "auto", "auto",0,
> AV_OPT_TYPE_CONST, {.i64 = 0}, 0, 0, FLAGS, .unit = "thread_type" },
> > +{ "frame","more than one frame at once", 0,
> AV_OPT_TYPE_CONST, {.i64 = 1}, 0, 0, FLAGS, .unit = "thread_type" },
> > +{ "slice","more than one part of single frame at once", 0,
> AV_OPT_TYPE_CONST, {.i64 = 2}, 0, 0, FLAGS, .unit = "thread_type" },
> > { "format_opts", "set format options for the opened file",
> OFFSET(format_opts), AV_OPT_TYPE_DICT, {.str = NULL}, 0, 0, FLAGS},
> > { NULL },
> > };
> > @@ -159,7 +164,7 @@ static AVStream *find_stream(void *log,
> AVFormatContext *avf, const char *spec)
> > return found;
> > }
> >
> > -static int open_stream(AVFilterContext *ctx, MovieStream *st, int
> dec_threads)
> > +static int open_stream(AVFilterContext *ctx, MovieStream *st, int
> dec_threads, int thread_type)
> > {
> > const AVCodec *codec;
> > int ret;
> > @@ -181,6 +186,8 @@ static int open_stream(AVFilterContext *ctx,
> MovieStream *st, int dec_threads)
> > if (!dec_threads)
> > dec_threads = ff_filter_get_nb_threads(ctx);
> > st->codec_ctx->thread_count = dec_threads;
> > +if (thread_type)
> > +st->codec_ctx->thread_type = thread_type;
> >
> > if ((ret = avcodec_open2(st->codec_ctx, codec, NULL)) < 0) {
> > av_log(ctx, AV_LOG_ERROR, "Failed to open codec\n");
> > @@ -325,7 +332,7 @@ static av_cold int movie_common_init(AVFilterContext
> *ctx)
> > if (ret < 0)
> > return ret;
> > }
> > -ret = open_stream(ctx, >st[i], movie->dec_threads);
> > +ret = open_stream(ctx, >st[i], movie->dec_threads,
> movie->thread_type);
> > if (ret < 0)
> > return ret;
> > }
>
> Why do you want to add an option for only this instead of a generic
> AV_OPT_TYPE_DICT option for a dict that will be passed to avcodec_open2()?
>
I think there is conflict if same option name is used.
>
> - Andreas
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
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 1/5] avutil: add ambient viewing environment metadata side data
lance.lmw...@gmail.com:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavutil/frame.c | 1 +
> libavutil/frame.h | 6 +
> libavutil/mastering_display_metadata.c | 23 +
> libavutil/mastering_display_metadata.h | 45
> ++
> libavutil/version.h| 2 +-
> 5 files changed, 76 insertions(+), 1 deletion(-)
>
> diff --git a/libavutil/frame.c b/libavutil/frame.c
> index fbb869f..8882da2 100644
> --- a/libavutil/frame.c
> +++ b/libavutil/frame.c
> @@ -815,6 +815,7 @@ const char *av_frame_side_data_name(enum
> AVFrameSideDataType type)
> case AV_FRAME_DATA_DETECTION_BBOXES:return "Bounding boxes
> for object detection and classification";
> case AV_FRAME_DATA_DOVI_RPU_BUFFER: return "Dolby Vision RPU
> Data";
> case AV_FRAME_DATA_DOVI_METADATA: return "Dolby Vision
> Metadata";
> +case AV_FRAME_DATA_AMBIENT_VIEWING_ENV: return "Ambient Viewing
> Environment";
> }
> return NULL;
> }
> diff --git a/libavutil/frame.h b/libavutil/frame.h
> index 33fac20..92413c9 100644
> --- a/libavutil/frame.h
> +++ b/libavutil/frame.h
> @@ -209,6 +209,12 @@ enum AVFrameSideDataType {
> * volume transform - CUVA 005.1-2021.
> */
> AV_FRAME_DATA_DYNAMIC_HDR_VIVID,
> +
> +/**
> + * ambient viewing environment for a video frame, as described by
> + * the AVAmbientViewingEnv
> + */
> +AV_FRAME_DATA_AMBIENT_VIEWING_ENV,
> };
>
> enum AVActiveFormatDescription {
> diff --git a/libavutil/mastering_display_metadata.c
> b/libavutil/mastering_display_metadata.c
> index 6069347..f094eab 100644
> --- a/libavutil/mastering_display_metadata.c
> +++ b/libavutil/mastering_display_metadata.c
> @@ -64,3 +64,26 @@ AVContentLightMetadata
> *av_content_light_metadata_create_side_data(AVFrame *fram
>
> return (AVContentLightMetadata *)side_data->data;
> }
> +
> +AVAmbientViewingEnv *av_ambient_viewing_env_alloc(size_t *size)
> +{
> +AVAmbientViewingEnv *metadata = av_mallocz(sizeof(*metadata));
> +
> +if (size)
> +*size = sizeof(*metadata);
> +
> +return metadata;
> +}
> +
> +AVAmbientViewingEnv *av_ambient_viewing_env_create_side_data(AVFrame *frame)
> +{
> +AVFrameSideData *side_data = av_frame_new_side_data(frame,
> +AV_FRAME_DATA_AMBIENT_VIEWING_ENV,
> +sizeof(AVAmbientViewingEnv));
> +if (!side_data)
> +return NULL;
> +
> +memset(side_data->data, 0, sizeof(AVAmbientViewingEnv));
> +
> +return (AVAmbientViewingEnv *)side_data->data;
> +}
> diff --git a/libavutil/mastering_display_metadata.h
> b/libavutil/mastering_display_metadata.h
> index c23b07c..c1ba659 100644
> --- a/libavutil/mastering_display_metadata.h
> +++ b/libavutil/mastering_display_metadata.h
> @@ -125,4 +125,49 @@ AVContentLightMetadata
> *av_content_light_metadata_alloc(size_t *size);
> */
> AVContentLightMetadata *av_content_light_metadata_create_side_data(AVFrame
> *frame);
>
> +/**
> + * The characteristics of the nominal ambient viewing environment for
> + * the display of the associated video content.
> + * To be used as payload of a AVFrameSideData the appropriate type.
> + *
> + * @note The struct should be allocated with av_ambient_viewing_env_alloc()
> + * and its size is not a part of the public ABI.
> + */
> +typedef struct AVAmbientViewingEnv {
> +/**
> + * specifies the environmental illuminance of the ambient viewing
> + * environment in units of 0.0001 lux.
> + * ambient_illuminance shall not be equal to 0.
> + */
> +uint32_t ambient_illuminance;
> +/**
> + * specify the normalized x and y chromaticity coordinates, respectively,
> + * of the environmental ambient light in the nominal viewing environment,
> + * according to the CIE 1931 definition of x and y as specified in ISO
> + * 11664-1 (see also ISO 11664-3 and CIE 15), in normalized increments of
> + * 0.2. The values of ambient_light_x and ambient_light_y shall be in
> + * the range of 0 to 5
> + */
> +uint16_t ambient_light_x;
> +uint16_t ambient_light_y;
> +} AVAmbientViewingEnv;
> +
> +/**
> + * Allocate an AVAmbientViewingEnv structure and set its fields to
> + * default values. The resulting struct can be freed using av_freep().
> + *
> + * @return An AVAmbientViewingEnv filled with default values or NULL
> + * on failure.
> + */
> +AVAmbientViewingEnv *av_ambient_viewing_env_alloc(size_t *size);
> +
> +/**
> + * Allocate a complete AVAmbientViewingEnv and add it to the frame.
> + *
> + * @param frame The frame which side data is added to.
> + *
> + * @return The AVAmbientViewingEnv structure to be filled by caller.
> + */
> +AVAmbientViewingEnv *av_ambient_viewing_env_create_side_data(AVFrame *frame);
All this boilerplate code for the various side-data--types makes me
wonder whether they
Re: [FFmpeg-devel] [PATCH] avcodec/ituh263enc: Add AV_CODEC_CAP_SLICE_THREADS to old H.263
Michael Niedermayer:
> It is supported by the H.263+ AVCodec already
>
> Is there any case where this does not work ?
>
> Fixes regression of some command lines
>
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/ituh263enc.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/libavcodec/ituh263enc.c b/libavcodec/ituh263enc.c
> index db7cdf1fcb..82dce05e36 100644
> --- a/libavcodec/ituh263enc.c
> +++ b/libavcodec/ituh263enc.c
> @@ -908,6 +908,7 @@ const FFCodec ff_h263_encoder = {
> .p.id = AV_CODEC_ID_H263,
> .p.pix_fmts = (const enum AVPixelFormat[]){AV_PIX_FMT_YUV420P,
> AV_PIX_FMT_NONE},
> .p.priv_class = _class,
> +.p.capabilities = AV_CODEC_CAP_SLICE_THREADS,
> .caps_internal = FF_CODEC_CAP_INIT_THREADSAFE |
> FF_CODEC_CAP_INIT_CLEANUP,
> .priv_data_size = sizeof(MpegEncContext),
> .init = ff_mpv_encode_init,
1. If you claim that there is a regression, you should mention the
commit that introduced them in the commit message (it's obviously
8ca4b515e73079cda068e253853654db394b8171 in this case).
2. What command lines regressed exactly? The only command lines that
should be affected by said commit are command lines that set the slices
option to a value > 1.
3. As the commit message of 8ca4b515e73079cda068e253853654db394b8171
explains, this was intentional, as the H.263 encoder produces broken
files with multiple slices (whether with slice-threading or not). One
gets all kinds of error messages when decoding such a file: "I cbpy
damaged at 1 7", "Error at MB: 316", "illegal ac vlc code at 0x29",
"slice end not reached but screenspace end (7 left 80, score=
-125)", "run overflow at 0x7 i:1". Of course, there are visual
artifacts, too.
4. With this patch, this encoder will by default (at least, by the
defaults of the ffmpeg command line tool) produce broken files.
5. "Is there any case where this does not work ?": Is there any where it
works?
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/7] avcodec/options: Fix AVClassCategory of decoders with .receive_frame
Andreas Rheinhardt:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/options.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/options.c b/libavcodec/options.c
> index 91ab994994..2e05d29e1e 100644
> --- a/libavcodec/options.c
> +++ b/libavcodec/options.c
> @@ -68,7 +68,7 @@ static const AVClass *codec_child_class_iterate(void **iter)
> static AVClassCategory get_category(void *ptr)
> {
> AVCodecContext* avctx = ptr;
> -if (avctx->codec && ffcodec(avctx->codec)->decode)
> +if (avctx->codec && av_codec_is_decoder(avctx->codec))
> return AV_CLASS_CATEGORY_DECODER;
> else
> return AV_CLASS_CATEGORY_ENCODER;
Will apply the first five patches of this patchset tonight unless there
are objections.
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/vp9_raw_reorder_bsf: Fix leak of cached packet
Andreas Rheinhardt:
> In case the BSF has not been drained before flushing/closing,
> the context's next_frame might be set; yet it is not freed
> in flush or close. The former only zeroes it (which automatically
> causes a leak in case it was set). So do this when closing
> and flushing.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/vp9_raw_reorder_bsf.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/vp9_raw_reorder_bsf.c
> b/libavcodec/vp9_raw_reorder_bsf.c
> index e7d301cb85..368dcb26c2 100644
> --- a/libavcodec/vp9_raw_reorder_bsf.c
> +++ b/libavcodec/vp9_raw_reorder_bsf.c
> @@ -396,7 +396,7 @@ static void vp9_raw_reorder_flush(AVBSFContext *bsf)
>
> for (int s = 0; s < FRAME_SLOTS; s++)
> vp9_raw_reorder_clear_slot(ctx, s);
> -ctx->next_frame = NULL;
> +vp9_raw_reorder_frame_free(>next_frame);
> ctx->sequence = 0;
> }
>
> @@ -407,6 +407,7 @@ static void vp9_raw_reorder_close(AVBSFContext *bsf)
>
> for (s = 0; s < FRAME_SLOTS; s++)
> vp9_raw_reorder_clear_slot(ctx, s);
> +vp9_raw_reorder_frame_free(>next_frame);
> }
>
> static const enum AVCodecID vp9_raw_reorder_codec_ids[] = {
Will apply this patchset tonight unless there are objections.
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/mpegenc: Fix ever growing FIFO and infinite loop on error
Andreas Rheinhardt:
> Since the switch to the new FIFO API in commit
> ea511196a6c85eb433e10cdbecb0b2c722faf20d, the FIFO is always
> grown by the amount of data intended to be written into it
> even in case the FIFO has enough free space. Fix this by
> only growing the FIFO if needed and then only by the amount that is
> actually needed.
>
> The allocation errors that resulted from this uncovered another bug:
> The context is left in an inconsistent state in case the FIFO can't
> be grown, because the FIFO does not contain as much data as the sizes
> contained in the PacketDesc list claim. This led to an infinite loop
> in output_packet() (called from mpeg_mux_end()).
>
> Fix this by growing the FIFO before adding a new PacketDesc element,
> thereby preventing the context from becoming inconsistent.
>
> Reported-by: Nicolas Gaullier
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/mpegenc.c | 13 +
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/libavformat/mpegenc.c b/libavformat/mpegenc.c
> index cc47a43288..62692bfcd1 100644
> --- a/libavformat/mpegenc.c
> +++ b/libavformat/mpegenc.c
> @@ -1152,6 +1152,7 @@ static int mpeg_mux_write_packet(AVFormatContext *ctx,
> AVPacket *pkt)
> int64_t pts, dts;
> PacketDesc *pkt_desc;
> int preload, ret;
> +size_t can_write;
> const int is_iframe = st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO &&
>(pkt->flags & AV_PKT_FLAG_KEY);
>
> @@ -1192,6 +1193,14 @@ static int mpeg_mux_write_packet(AVFormatContext *ctx,
> AVPacket *pkt)
> size -= 3;
> }
>
> +/* Enlarge the FIFO before adding a new PacketDesc
> + * in order to avoid inconsistencies on failure. */
> +can_write = av_fifo_can_write(stream->fifo);
> +if (can_write < size) {
> +ret = av_fifo_grow2(stream->fifo, size - can_write);
> +if (ret < 0)
> +return ret;
> +}
> pkt_desc = av_mallocz(sizeof(PacketDesc));
> if (!pkt_desc)
> return AVERROR(ENOMEM);
> @@ -1207,10 +1216,6 @@ static int mpeg_mux_write_packet(AVFormatContext *ctx,
> AVPacket *pkt)
> pkt_desc->unwritten_size =
> pkt_desc->size = size;
>
> -ret = av_fifo_grow2(stream->fifo, size);
> -if (ret < 0)
> -return ret;
> -
> if (s->is_dvd) {
> // min VOBU length 0.4 seconds (mpucoder)
> if (is_iframe &&
Will apply this tonight unless there are objections.
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] avfilter/src_movie: add option to set decoding thread type
Paul B Mahol:
> Signed-off-by: Paul B Mahol
> ---
> doc/filters.texi| 3 +++
> libavfilter/src_movie.c | 11 +--
> 2 files changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 636c80dbff..a13977edd8 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -29317,6 +29317,9 @@ timestamps.
> @item dec_threads
> Specifies the number of threads for decoding
>
> +@item dec_thread_type
> +Specifies the thread type for decoding.
> +
> @item format_opts
> Specify format options for the opened file. Format options can be specified
> as a list of @var{key}=@var{value} pairs separated by ':'. The following
> example
> diff --git a/libavfilter/src_movie.c b/libavfilter/src_movie.c
> index bc7b0d37af..08cba437bf 100644
> --- a/libavfilter/src_movie.c
> +++ b/libavfilter/src_movie.c
> @@ -72,6 +72,7 @@ typedef struct MovieContext {
> int64_t discontinuity_threshold;
> int64_t ts_offset;
> int dec_threads;
> +int thread_type;
> int got_eagain;
> int got_wanted;
>
> @@ -99,6 +100,10 @@ static const AVOption movie_options[]= {
> { "loop", "set loop count", OFFSET(loop_count),
> AV_OPT_TYPE_INT,{.i64 = 1}, 0,INT_MAX, FLAGS },
> { "discontinuity", "set discontinuity threshold",
> OFFSET(discontinuity_threshold), AV_OPT_TYPE_DURATION, {.i64 = 0}, 0,
> INT64_MAX, FLAGS },
> { "dec_threads", "set the number of threads for decoding",
> OFFSET(dec_threads), AV_OPT_TYPE_INT, {.i64 = 0}, 0, INT_MAX, FLAGS },
> +{ "dec_thread_type","set the type of threads for decoding",
> OFFSET(thread_type), AV_OPT_TYPE_INT, {.i64 = 0}, 0, 2, FLAGS, .unit =
> "thread_type" },
> +{ "auto", "auto",0, AV_OPT_TYPE_CONST,
> {.i64 = 0}, 0, 0, FLAGS, .unit = "thread_type" },
> +{ "frame","more than one frame at once", 0, AV_OPT_TYPE_CONST,
> {.i64 = 1}, 0, 0, FLAGS, .unit = "thread_type" },
> +{ "slice","more than one part of single frame at once", 0,
> AV_OPT_TYPE_CONST, {.i64 = 2}, 0, 0, FLAGS, .unit = "thread_type" },
> { "format_opts", "set format options for the opened file",
> OFFSET(format_opts), AV_OPT_TYPE_DICT, {.str = NULL}, 0, 0, FLAGS},
> { NULL },
> };
> @@ -159,7 +164,7 @@ static AVStream *find_stream(void *log, AVFormatContext
> *avf, const char *spec)
> return found;
> }
>
> -static int open_stream(AVFilterContext *ctx, MovieStream *st, int
> dec_threads)
> +static int open_stream(AVFilterContext *ctx, MovieStream *st, int
> dec_threads, int thread_type)
> {
> const AVCodec *codec;
> int ret;
> @@ -181,6 +186,8 @@ static int open_stream(AVFilterContext *ctx, MovieStream
> *st, int dec_threads)
> if (!dec_threads)
> dec_threads = ff_filter_get_nb_threads(ctx);
> st->codec_ctx->thread_count = dec_threads;
> +if (thread_type)
> +st->codec_ctx->thread_type = thread_type;
>
> if ((ret = avcodec_open2(st->codec_ctx, codec, NULL)) < 0) {
> av_log(ctx, AV_LOG_ERROR, "Failed to open codec\n");
> @@ -325,7 +332,7 @@ static av_cold int movie_common_init(AVFilterContext *ctx)
> if (ret < 0)
> return ret;
> }
> -ret = open_stream(ctx, >st[i], movie->dec_threads);
> +ret = open_stream(ctx, >st[i], movie->dec_threads,
> movie->thread_type);
> if (ret < 0)
> return ret;
> }
Why do you want to add an option for only this instead of a generic
AV_OPT_TYPE_DICT option for a dict that will be passed to avcodec_open2()?
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/libvpxenc: return quantizer parameter for an encoded frame
I've rechecked documentation for the "vpx_codec_control" - can't find
any guarantee about the last parameter when the function fails, thus
prefer to be on the safe side.
On Tue, Apr 5, 2022 at 3:59 PM James Almer wrote:
>
> On 4/5/2022 9:15 AM, Danil Chapovalov wrote:
> > ---
> > libavcodec/libvpxenc.c | 9 -
> > 1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
> > index dff1d06b0e..0705863450 100644
> > --- a/libavcodec/libvpxenc.c
> > +++ b/libavcodec/libvpxenc.c
> > @@ -1250,6 +1250,8 @@ static int storeframe(AVCodecContext *avctx, struct
> > FrameListData *cx_frame,
> > int ret = ff_get_encode_buffer(avctx, pkt, cx_frame->sz, 0);
> > uint8_t *side_data;
> > int pict_type;
> > +int quality;
> > +VPxContext *ctx = avctx->priv_data;
> >
> > if (ret < 0)
> > return ret;
> > @@ -1264,7 +1266,12 @@ static int storeframe(AVCodecContext *avctx, struct
> > FrameListData *cx_frame,
> > pict_type = AV_PICTURE_TYPE_P;
> > }
> >
> > -ff_side_data_set_encoder_stats(pkt, 0, cx_frame->sse + 1,
> > +ret = vpx_codec_control(>encoder, VP8E_GET_LAST_QUANTIZER_64,
> > );
> > +if (ret != VPX_CODEC_OK) {
>
> Is the last argument guaranteed to be untouched when the return value of
> vpx_codec_control() is not VPX_CODEC_OK? If so, you can initialize
> quality to 0 above, and remove this part.
>
> > +quality = 0;
> > +}
> > +
> > +ff_side_data_set_encoder_stats(pkt, quality * FF_QP2LAMBDA,
> > cx_frame->sse + 1,
> > cx_frame->have_sse ? 3 : 0, pict_type);
> >
> > if (cx_frame->have_sse) {
> ___
> 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".
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".
[FFmpeg-devel] [PATCH] avcodec/libvpxenc: return quantizer parameter for an encoded frame
---
libavcodec/libvpxenc.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index dff1d06b0e..b1d56d99b7 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -1250,6 +1250,8 @@ static int storeframe(AVCodecContext *avctx, struct
FrameListData *cx_frame,
int ret = ff_get_encode_buffer(avctx, pkt, cx_frame->sz, 0);
uint8_t *side_data;
int pict_type;
+int quality;
+VPxContext *ctx = avctx->priv_data;
if (ret < 0)
return ret;
@@ -1264,7 +1266,10 @@ static int storeframe(AVCodecContext *avctx, struct
FrameListData *cx_frame,
pict_type = AV_PICTURE_TYPE_P;
}
-ff_side_data_set_encoder_stats(pkt, 0, cx_frame->sse + 1,
+ret = vpx_codec_control(>encoder, VP8E_GET_LAST_QUANTIZER_64,
);
+if (ret != VPX_CODEC_OK)
+quality = 0;
+ff_side_data_set_encoder_stats(pkt, quality * FF_QP2LAMBDA, cx_frame->sse
+ 1,
cx_frame->have_sse ? 3 : 0, pict_type);
if (cx_frame->have_sse) {
--
2.35.1.1094.g7c7d902a7c-goog
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/3] hwcontext_vulkan: add queue and frame locking functions
5 Apr 2022, 11:38 by an...@khirnov.net:
> Quoting Lynne (2022-04-03 16:52:24)
>
>> +#include
>>
>
> Either make vulkan depend on threads or make this all conditional somehow.
>
I'll make it optional. The locking functions would do nothing in that case,
with a note for the API user.
>> @@ -4129,7 +4209,19 @@ static int vulkan_frames_derive_to(AVHWFramesContext
>> *dst_fc,
>>
>> AVVkFrame *av_vk_frame_alloc(void)
>> {
>> -return av_mallocz(sizeof(AVVkFrame));
>> +AVVkFrame *f = av_mallocz(sizeof(AVVkFrame));
>> +if (!f)
>> +return NULL;
>> +
>> +f->internal = av_mallocz(sizeof(*f->internal));
>>
>
> Doxy says AVVkFrame can be freed with av_free.
>
That's already been broken, since if an API user passed an AVVkFrame
to map from a CUDA, it would allocate the internal field anyway.
What about making the internal field its own struct which would
live in AVFrame->buf[1]? That way, it would get free'd on av_frame_free().
The AVVkFrame field would get deprecated.
> I'd expect some prescription for who calls this and when. Like
> "Any users accessing any queues associated with this device MUST call
> this callback before manipulating the queue and unlock_queue() after
> they are done."
>
> Same for lock_frame()
>
Will add stricter notes.
>> + */
>> +void (*lock_queue)(AVHWDeviceContext *ctx, int queue_family, int index);
>>
>
> any reason those are signed?
>
Not really, I can change them into uint32_t's, as that's what Vulkan
functions take.
>> +
>> +/**
>> + * Similar to lock_queue(), unlocks a queue. Must only be called after
>> it.
>>
> s/similar/complementary/
>
Fixed.
___
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 v12 2/4] avcodec/libjxl: add Jpeg XL decoding via libjxl
On 4/5/22 06:50, Anton Khirnov wrote: Quoting Leo Izen (2022-04-02 22:12:08) +case JXL_DEC_COLOR_ENCODING: +av_log(avctx, AV_LOG_DEBUG, "COLOR_ENCODING event emitted\n"); +jret = JxlDecoderGetICCProfileSize(ctx->decoder, >jxl_pixfmt, JXL_COLOR_PROFILE_TARGET_ORIGINAL, >iccp_len); Does iccp_len need to be a context variable? Seems to me it's only used in this block. Probably not, given that ctx->iccp is an AvBufferRef. +} +continue; +case JXL_DEC_FRAME: +case JXL_DEC_NEED_IMAGE_OUT_BUFFER: +/* + * We don't do this at basic info time + * because it will happen again when we + * rewind anyway + */ +av_log(avctx, AV_LOG_DEBUG, "%s event emitted\n", jret == JXL_DEC_FRAME ? "FRAME" : "NEED_IMAGE_OUT_BUFFER"); +ret = ff_get_buffer(avctx, frame, 0); Is it absolutely guaranteed that this will always happen before JXL_DEC_FULL_IMAGE in the same libjxl_decode_frame() invocation? Can it happen that you get JXL_DEC_NEED_IMAGE_OUT_BUFFER/JXL_DEC_FRAME, then JXL_DEC_NEED_MORE_INPUT, which causes you to return, then JXL_DEC_FULL_IMAGE on the next libjxl_decode_frame() call? I don't see why it couldn't, but what I don't understand is why this is necessarily a problem. +case JXL_DEC_SUCCESS: +av_log(avctx, AV_LOG_DEBUG, "SUCCESS event emitted\n"); +/* + * The file has finished decoding + * reset the decoder to let us + * reuse it again for the next image + */ +JxlDecoderReset(ctx->decoder); +libjxl_init_jxl_decoder(avctx); +buf = avpkt->data; +remaining = avpkt->size; Why reset buf? The same data is not going to be decoded again, is it? Decoding a single image will never fire the JXL_DEC_SUCCESS call since we return before then. If you decode an image2 sequence (e.g. input-%d.jxl), JXL_DEC_SUCCESS is fired before the start of the next frame. When this event is fired, the contents of avpkt->data and avpkt->size are the already the next frame's data, so this is indeed necessary. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/libvpxenc: return quantizer parameter for an encoded frame
On 4/5/2022 9:15 AM, Danil Chapovalov wrote:
---
libavcodec/libvpxenc.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index dff1d06b0e..0705863450 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -1250,6 +1250,8 @@ static int storeframe(AVCodecContext *avctx, struct
FrameListData *cx_frame,
int ret = ff_get_encode_buffer(avctx, pkt, cx_frame->sz, 0);
uint8_t *side_data;
int pict_type;
+int quality;
+VPxContext *ctx = avctx->priv_data;
if (ret < 0)
return ret;
@@ -1264,7 +1266,12 @@ static int storeframe(AVCodecContext *avctx, struct
FrameListData *cx_frame,
pict_type = AV_PICTURE_TYPE_P;
}
-ff_side_data_set_encoder_stats(pkt, 0, cx_frame->sse + 1,
+ret = vpx_codec_control(>encoder, VP8E_GET_LAST_QUANTIZER_64,
);
+if (ret != VPX_CODEC_OK) {
Is the last argument guaranteed to be untouched when the return value of
vpx_codec_control() is not VPX_CODEC_OK? If so, you can initialize
quality to 0 above, and remove this part.
+quality = 0;
+}
+
+ff_side_data_set_encoder_stats(pkt, quality * FF_QP2LAMBDA, cx_frame->sse
+ 1,
cx_frame->have_sse ? 3 : 0, pict_type);
if (cx_frame->have_sse) {
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/libvpxenc: return quantizer parameter for an encoded frame
On 4/5/2022 10:55 AM, Lynne wrote:
5 Apr 2022, 14:15 by danilchap-at-google@ffmpeg.org:
---
libavcodec/libvpxenc.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index dff1d06b0e..0705863450 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -1250,6 +1250,8 @@ static int storeframe(AVCodecContext *avctx, struct
FrameListData *cx_frame,
int ret = ff_get_encode_buffer(avctx, pkt, cx_frame->sz, 0);
uint8_t *side_data;
int pict_type;
+int quality;
+VPxContext *ctx = avctx->priv_data;
if (ret < 0)
return ret;
@@ -1264,7 +1266,12 @@ static int storeframe(AVCodecContext *avctx, struct
FrameListData *cx_frame,
pict_type = AV_PICTURE_TYPE_P;
}
-ff_side_data_set_encoder_stats(pkt, 0, cx_frame->sse + 1,
+ret = vpx_codec_control(>encoder, VP8E_GET_LAST_QUANTIZER_64,
);
+if (ret != VPX_CODEC_OK) {
+quality = 0;
+}
Fix the coding style.
You could just say to remove the brackets for one line statements.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/libvpxenc: return quantizer parameter for an encoded frame
5 Apr 2022, 14:15 by danilchap-at-google@ffmpeg.org:
> ---
> libavcodec/libvpxenc.c | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
> index dff1d06b0e..0705863450 100644
> --- a/libavcodec/libvpxenc.c
> +++ b/libavcodec/libvpxenc.c
> @@ -1250,6 +1250,8 @@ static int storeframe(AVCodecContext *avctx, struct
> FrameListData *cx_frame,
> int ret = ff_get_encode_buffer(avctx, pkt, cx_frame->sz, 0);
> uint8_t *side_data;
> int pict_type;
> +int quality;
> +VPxContext *ctx = avctx->priv_data;
>
> if (ret < 0)
> return ret;
> @@ -1264,7 +1266,12 @@ static int storeframe(AVCodecContext *avctx, struct
> FrameListData *cx_frame,
> pict_type = AV_PICTURE_TYPE_P;
> }
>
> -ff_side_data_set_encoder_stats(pkt, 0, cx_frame->sse + 1,
> +ret = vpx_codec_control(>encoder, VP8E_GET_LAST_QUANTIZER_64,
> );
> +if (ret != VPX_CODEC_OK) {
> +quality = 0;
> +}
>
Fix the coding style.
___
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 5/5] avfilter/vf_showinfo: fix unknown side data type for DOVI_RPU_BUFFER
From: Limin Wang Signed-off-by: Limin Wang --- libavfilter/vf_showinfo.c | 4 1 file changed, 4 insertions(+) diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c index 1e81d26..18ddf12 100644 --- a/libavfilter/vf_showinfo.c +++ b/libavfilter/vf_showinfo.c @@ -824,6 +824,10 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *frame) case AV_FRAME_DATA_AMBIENT_VIEWING_ENV: dump_ambient_viewing_env(ctx, sd); break; +case AV_FRAME_DATA_DOVI_RPU_BUFFER: +av_log(ctx, AV_LOG_INFO, "DOVI RPU raw data " +"(%"SIZE_SPECIFIER" bytes)", sd->size); +break; default: av_log(ctx, AV_LOG_WARNING, "unknown side data type %d " "(%"SIZE_SPECIFIER" bytes)\n", sd->type, sd->size); -- 1.8.3.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 4/5] fftools/ffprobe: add support for ambient viewing environment metadata
From: Limin Wang
Signed-off-by: Limin Wang
---
fftools/ffprobe.c | 5 +
tests/ref/fate/hevc-dv-rpu | 6 ++
2 files changed, 11 insertions(+)
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index 05c167e..a13b93e 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -2605,6 +2605,11 @@ static void show_frame(WriterContext *w, AVFrame *frame,
AVStream *stream,
AVContentLightMetadata *metadata = (AVContentLightMetadata
*)sd->data;
print_int("max_content", metadata->MaxCLL);
print_int("max_average", metadata->MaxFALL);
+} else if (sd->type == AV_FRAME_DATA_AMBIENT_VIEWING_ENV) {
+AVAmbientViewingEnv *metadata = (AVAmbientViewingEnv
*)sd->data;
+print_int("ambient_illuminance",
metadata->ambient_illuminance);
+print_int("ambient_light_x", metadata->ambient_light_x);
+print_int("ambient_light_y", metadata->ambient_light_y);
} else if (sd->type == AV_FRAME_DATA_ICC_PROFILE) {
const AVDictionaryEntry *tag = av_dict_get(sd->metadata,
"name", NULL, AV_DICT_MATCH_CASE);
if (tag)
diff --git a/tests/ref/fate/hevc-dv-rpu b/tests/ref/fate/hevc-dv-rpu
index 6879f71..4ad5436 100644
--- a/tests/ref/fate/hevc-dv-rpu
+++ b/tests/ref/fate/hevc-dv-rpu
@@ -119,6 +119,9 @@ source_diagonal=42
[/SIDE_DATA]
[SIDE_DATA]
side_data_type=Ambient Viewing Environment
+ambient_illuminance=314
+ambient_light_x=15635
+ambient_light_y=16450
[/SIDE_DATA]
[/FRAME]
[FRAME]
@@ -239,5 +242,8 @@ source_diagonal=42
[/SIDE_DATA]
[SIDE_DATA]
side_data_type=Ambient Viewing Environment
+ambient_illuminance=314
+ambient_light_x=15635
+ambient_light_y=16450
[/SIDE_DATA]
[/FRAME]
--
1.8.3.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 3/5] avfilter/vf_showinfo: add support for ambient viewing environment metadata
From: Limin Wang
Signed-off-by: Limin Wang
---
libavfilter/vf_showinfo.c | 12
1 file changed, 12 insertions(+)
diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c
index 12d3931..1e81d26 100644
--- a/libavfilter/vf_showinfo.c
+++ b/libavfilter/vf_showinfo.c
@@ -651,6 +651,15 @@ static void dump_color_property(AVFilterContext *ctx,
AVFrame *frame)
av_log(ctx, AV_LOG_INFO, "\n");
}
+static void dump_ambient_viewing_env(AVFilterContext *ctx, AVFrameSideData *sd)
+{
+const AVAmbientViewingEnv *metadata = (const AVAmbientViewingEnv
*)sd->data;
+
+av_log(ctx, AV_LOG_INFO, "Ambient Viewing Environment: \n");
+av_log(ctx, AV_LOG_INFO, "ambient_illuminance=%d, ambient_light_x=%d,
ambient_light_y=%d",
+ metadata->ambient_illuminance, metadata->ambient_light_x,
metadata->ambient_light_y);
+}
+
static void update_sample_stats_8(const uint8_t *src, int len, int64_t *sum,
int64_t *sum2)
{
int i;
@@ -812,6 +821,9 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
*frame)
case AV_FRAME_DATA_DOVI_METADATA:
dump_dovi_metadata(ctx, sd);
break;
+case AV_FRAME_DATA_AMBIENT_VIEWING_ENV:
+ dump_ambient_viewing_env(ctx, sd);
+break;
default:
av_log(ctx, AV_LOG_WARNING, "unknown side data type %d "
"(%"SIZE_SPECIFIER" bytes)\n", sd->type, sd->size);
--
1.8.3.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/5] avcodec: add support for hevc ambient viewing environment SEI message
From: Limin Wang
Signed-off-by: Limin Wang
---
libavcodec/hevc_sei.c | 19 +++
libavcodec/hevc_sei.h | 8
libavcodec/hevcdec.c | 10 ++
tests/ref/fate/hevc-dv-rpu | 6 ++
4 files changed, 43 insertions(+)
diff --git a/libavcodec/hevc_sei.c b/libavcodec/hevc_sei.c
index ec3036f..8c6daf5 100644
--- a/libavcodec/hevc_sei.c
+++ b/libavcodec/hevc_sei.c
@@ -497,6 +497,23 @@ static int
decode_film_grain_characteristics(HEVCSEIFilmGrainCharacteristics *h,
return 0;
}
+static int decode_ambient_viewing_env(HEVCSEIAmbientViewingEnvironment *s,
GetBitContext *gb, int size)
+{
+if (size < 8)
+return AVERROR_INVALIDDATA;
+
+s->ambient_illuminance = get_bits_long(gb, 32);
+s->ambient_light_x = get_bits(gb, 16);
+s->ambient_light_y = get_bits(gb, 16);
+size -= 8;
+
+s->present = 1;
+
+skip_bits_long(gb, 8 * size);
+return 0;
+}
+
+
static int decode_nal_sei_prefix(GetBitContext *gb, void *logctx, HEVCSEI *s,
const HEVCParamSets *ps, int type, int size)
{
@@ -525,6 +542,8 @@ static int decode_nal_sei_prefix(GetBitContext *gb, void
*logctx, HEVCSEI *s,
return decode_nal_sei_timecode(>timecode, gb);
case SEI_TYPE_FILM_GRAIN_CHARACTERISTICS:
return
decode_film_grain_characteristics(>film_grain_characteristics, gb);
+case SEI_TYPE_AMBIENT_VIEWING_ENVIRONMENT:
+return decode_ambient_viewing_env(>ambient_viewing_env, gb, size);
default:
av_log(logctx, AV_LOG_DEBUG, "Skipped PREFIX SEI %d\n", type);
skip_bits_long(gb, 8 * size);
diff --git a/libavcodec/hevc_sei.h b/libavcodec/hevc_sei.h
index f198402..c7623f5 100644
--- a/libavcodec/hevc_sei.h
+++ b/libavcodec/hevc_sei.h
@@ -134,6 +134,13 @@ typedef struct HEVCSEIFilmGrainCharacteristics {
int persistence_flag;
} HEVCSEIFilmGrainCharacteristics;
+typedef struct HEVCSEIAmbientViewingEnvironment {
+int present;
+uint32_t ambient_illuminance;
+uint16_t ambient_light_x;
+uint16_t ambient_light_y;
+} HEVCSEIAmbientViewingEnvironment;
+
typedef struct HEVCSEI {
HEVCSEIPictureHash picture_hash;
HEVCSEIFramePacking frame_packing;
@@ -149,6 +156,7 @@ typedef struct HEVCSEI {
HEVCSEIAlternativeTransfer alternative_transfer;
HEVCSEITimeCode timecode;
HEVCSEIFilmGrainCharacteristics film_grain_characteristics;
+HEVCSEIAmbientViewingEnvironment ambient_viewing_env;
} HEVCSEI;
struct HEVCParamSets;
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index 09c07ac..21ed579 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -2998,6 +2998,15 @@ static int set_side_data(HEVCContext *s)
}
}
+if (s->sei.ambient_viewing_env.present > 0) {
+AVAmbientViewingEnv *metadata =
av_ambient_viewing_env_create_side_data(out);
+if (!metadata)
+return AVERROR(ENOMEM);
+metadata->ambient_illuminance =
s->sei.ambient_viewing_env.ambient_illuminance;
+metadata->ambient_light_x = s->sei.ambient_viewing_env.ambient_light_x;
+metadata->ambient_light_y = s->sei.ambient_viewing_env.ambient_light_y;
+}
+
return 0;
}
@@ -3800,6 +3809,7 @@ static int hevc_update_thread_context(AVCodecContext *dst,
s->sei.mastering_display= s0->sei.mastering_display;
s->sei.content_light= s0->sei.content_light;
s->sei.alternative_transfer = s0->sei.alternative_transfer;
+s->sei.ambient_viewing_env = s0->sei.ambient_viewing_env;
ret = export_stream_params_from_sei(s);
if (ret < 0)
diff --git a/tests/ref/fate/hevc-dv-rpu b/tests/ref/fate/hevc-dv-rpu
index 1980ab1..6879f71 100644
--- a/tests/ref/fate/hevc-dv-rpu
+++ b/tests/ref/fate/hevc-dv-rpu
@@ -117,6 +117,9 @@ source_min_pq=0
source_max_pq=3079
source_diagonal=42
[/SIDE_DATA]
+[SIDE_DATA]
+side_data_type=Ambient Viewing Environment
+[/SIDE_DATA]
[/FRAME]
[FRAME]
[SIDE_DATA]
@@ -234,4 +237,7 @@ source_min_pq=0
source_max_pq=3079
source_diagonal=42
[/SIDE_DATA]
+[SIDE_DATA]
+side_data_type=Ambient Viewing Environment
+[/SIDE_DATA]
[/FRAME]
--
1.8.3.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 1/5] avutil: add ambient viewing environment metadata side data
From: Limin Wang
Signed-off-by: Limin Wang
---
libavutil/frame.c | 1 +
libavutil/frame.h | 6 +
libavutil/mastering_display_metadata.c | 23 +
libavutil/mastering_display_metadata.h | 45 ++
libavutil/version.h| 2 +-
5 files changed, 76 insertions(+), 1 deletion(-)
diff --git a/libavutil/frame.c b/libavutil/frame.c
index fbb869f..8882da2 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -815,6 +815,7 @@ const char *av_frame_side_data_name(enum
AVFrameSideDataType type)
case AV_FRAME_DATA_DETECTION_BBOXES:return "Bounding boxes for
object detection and classification";
case AV_FRAME_DATA_DOVI_RPU_BUFFER: return "Dolby Vision RPU
Data";
case AV_FRAME_DATA_DOVI_METADATA: return "Dolby Vision
Metadata";
+case AV_FRAME_DATA_AMBIENT_VIEWING_ENV: return "Ambient Viewing
Environment";
}
return NULL;
}
diff --git a/libavutil/frame.h b/libavutil/frame.h
index 33fac20..92413c9 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -209,6 +209,12 @@ enum AVFrameSideDataType {
* volume transform - CUVA 005.1-2021.
*/
AV_FRAME_DATA_DYNAMIC_HDR_VIVID,
+
+/**
+ * ambient viewing environment for a video frame, as described by
+ * the AVAmbientViewingEnv
+ */
+AV_FRAME_DATA_AMBIENT_VIEWING_ENV,
};
enum AVActiveFormatDescription {
diff --git a/libavutil/mastering_display_metadata.c
b/libavutil/mastering_display_metadata.c
index 6069347..f094eab 100644
--- a/libavutil/mastering_display_metadata.c
+++ b/libavutil/mastering_display_metadata.c
@@ -64,3 +64,26 @@ AVContentLightMetadata
*av_content_light_metadata_create_side_data(AVFrame *fram
return (AVContentLightMetadata *)side_data->data;
}
+
+AVAmbientViewingEnv *av_ambient_viewing_env_alloc(size_t *size)
+{
+AVAmbientViewingEnv *metadata = av_mallocz(sizeof(*metadata));
+
+if (size)
+*size = sizeof(*metadata);
+
+return metadata;
+}
+
+AVAmbientViewingEnv *av_ambient_viewing_env_create_side_data(AVFrame *frame)
+{
+AVFrameSideData *side_data = av_frame_new_side_data(frame,
+AV_FRAME_DATA_AMBIENT_VIEWING_ENV,
+sizeof(AVAmbientViewingEnv));
+if (!side_data)
+return NULL;
+
+memset(side_data->data, 0, sizeof(AVAmbientViewingEnv));
+
+return (AVAmbientViewingEnv *)side_data->data;
+}
diff --git a/libavutil/mastering_display_metadata.h
b/libavutil/mastering_display_metadata.h
index c23b07c..c1ba659 100644
--- a/libavutil/mastering_display_metadata.h
+++ b/libavutil/mastering_display_metadata.h
@@ -125,4 +125,49 @@ AVContentLightMetadata
*av_content_light_metadata_alloc(size_t *size);
*/
AVContentLightMetadata *av_content_light_metadata_create_side_data(AVFrame
*frame);
+/**
+ * The characteristics of the nominal ambient viewing environment for
+ * the display of the associated video content.
+ * To be used as payload of a AVFrameSideData the appropriate type.
+ *
+ * @note The struct should be allocated with av_ambient_viewing_env_alloc()
+ * and its size is not a part of the public ABI.
+ */
+typedef struct AVAmbientViewingEnv {
+/**
+ * specifies the environmental illuminance of the ambient viewing
+ * environment in units of 0.0001 lux.
+ * ambient_illuminance shall not be equal to 0.
+ */
+uint32_t ambient_illuminance;
+/**
+ * specify the normalized x and y chromaticity coordinates, respectively,
+ * of the environmental ambient light in the nominal viewing environment,
+ * according to the CIE 1931 definition of x and y as specified in ISO
+ * 11664-1 (see also ISO 11664-3 and CIE 15), in normalized increments of
+ * 0.2. The values of ambient_light_x and ambient_light_y shall be in
+ * the range of 0 to 5
+ */
+uint16_t ambient_light_x;
+uint16_t ambient_light_y;
+} AVAmbientViewingEnv;
+
+/**
+ * Allocate an AVAmbientViewingEnv structure and set its fields to
+ * default values. The resulting struct can be freed using av_freep().
+ *
+ * @return An AVAmbientViewingEnv filled with default values or NULL
+ * on failure.
+ */
+AVAmbientViewingEnv *av_ambient_viewing_env_alloc(size_t *size);
+
+/**
+ * Allocate a complete AVAmbientViewingEnv and add it to the frame.
+ *
+ * @param frame The frame which side data is added to.
+ *
+ * @return The AVAmbientViewingEnv structure to be filled by caller.
+ */
+AVAmbientViewingEnv *av_ambient_viewing_env_create_side_data(AVFrame *frame);
+
#endif /* AVUTIL_MASTERING_DISPLAY_METADATA_H */
diff --git a/libavutil/version.h b/libavutil/version.h
index 6735c20..998202f 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -79,7 +79,7 @@
*/
#define LIBAVUTIL_VERSION_MAJOR 57
-#define LIBAVUTIL_VERSION_MINOR 24
+#define LIBAVUTIL_VERSION_MINOR 25
#define LIBAVUTIL_VERSION_MICRO 101
#define
[FFmpeg-devel] [PATCH] lavc/flacdec: Increase residual limit from INT_MAX to UINT_MAX
---
libavcodec/flacdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/flacdec.c b/libavcodec/flacdec.c
index dd6026f9de..cb32d7cae8 100644
--- a/libavcodec/flacdec.c
+++ b/libavcodec/flacdec.c
@@ -260,7 +260,7 @@ static int decode_residuals(FLACContext *s, int32_t
*decoded, int pred_order)
for (; i < samples; i++)
*decoded++ = get_sbits_long(, tmp);
} else {
-int real_limit = tmp ? (INT_MAX >> tmp) + 2 : INT_MAX;
+int real_limit = (tmp > 1) ? (INT_MAX >> (tmp - 1)) + 2 : INT_MAX;
for (; i < samples; i++) {
int v = get_sr_golomb_flac(, tmp, real_limit, 1);
if (v == 0x8000){
--
2.30.2
___
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/7] avformat/mov_chan: rename mov_get_channel_label() to better reflect its purpose
On 3/28/2022 8:24 PM, James Almer wrote:
This function turns a mov channel label into a lavf native bitmask.
Signed-off-by: James Almer
---
libavformat/mov_chan.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/mov_chan.c b/libavformat/mov_chan.c
index f52239d347..4607540297 100644
--- a/libavformat/mov_chan.c
+++ b/libavformat/mov_chan.c
@@ -485,7 +485,7 @@ static uint64_t mov_get_channel_layout(uint32_t tag,
uint32_t bitmap)
return layout_map[i].layout;
}
-static uint32_t mov_get_channel_label(uint32_t label)
+static uint32_t mov_get_channel_mask(uint32_t label)
{
if (label == 0)
return 0;
@@ -590,7 +590,7 @@ int ff_mov_read_chan(AVFormatContext *s, AVIOContext *pb,
AVStream *st,
avio_rl32(pb); // mCoordinates[2]
size -= 20;
if (layout_tag == 0) {
-uint32_t mask_incr = mov_get_channel_label(label);
+uint32_t mask_incr = mov_get_channel_mask(label);
if (mask_incr == 0) {
label_mask = 0;
break;
Will apply set.
___
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/libvpxenc: return quantizer parameter for an encoded frame
---
libavcodec/libvpxenc.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index dff1d06b0e..0705863450 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -1250,6 +1250,8 @@ static int storeframe(AVCodecContext *avctx, struct
FrameListData *cx_frame,
int ret = ff_get_encode_buffer(avctx, pkt, cx_frame->sz, 0);
uint8_t *side_data;
int pict_type;
+int quality;
+VPxContext *ctx = avctx->priv_data;
if (ret < 0)
return ret;
@@ -1264,7 +1266,12 @@ static int storeframe(AVCodecContext *avctx, struct
FrameListData *cx_frame,
pict_type = AV_PICTURE_TYPE_P;
}
-ff_side_data_set_encoder_stats(pkt, 0, cx_frame->sse + 1,
+ret = vpx_codec_control(>encoder, VP8E_GET_LAST_QUANTIZER_64,
);
+if (ret != VPX_CODEC_OK) {
+quality = 0;
+}
+
+ff_side_data_set_encoder_stats(pkt, quality * FF_QP2LAMBDA, cx_frame->sse
+ 1,
cx_frame->have_sse ? 3 : 0, pict_type);
if (cx_frame->have_sse) {
--
2.35.1.1094.g7c7d902a7c-goog
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v7 05/10] qsv: build audio related code when MFX_VERSION < 2.0
Quoting Xiang, Haihao (2022-03-11 09:16:25) > From: Haihao Xiang > > Audio isn't supported for MFX_VERSION >= 2.0[1][2]. This is in > preparation for oneVPL support > > [1]: > https://spec.oneapi.io/versions/latest/elements/oneVPL/source/VPL_intel_media_sdk.html#msdk-full-name-feature-removals > [2]: https://github.com/oneapi-src/oneVPL > --- > libavcodec/qsv.c | 5 + > libavfilter/qsvvpp.c | 6 ++ > libavfilter/qsvvpp.h | 2 ++ > 3 files changed, 13 insertions(+) Why not just remove this completely? None of our QSV code does anything with audio. -- 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 v8 2/2] avcodec/mjpegenc: support writing ICC profiles
From: Niklas Haas
This is mostly straightforward. The major complication is that, as a
result of the 16-bit chunk size limitation, ICC profiles may need to be
split up into multiple chunks.
We also need to make sure to allocate enough extra space in the packet
to fit the ICC profile, so modify both mpegvideo_enc.c and ljpegenc.c to
take into account this extra overhead, failing cleanly if necessary.
Also add a FATE transcode test to ensure that the ICC profile gets
written (and read) correctly. Note that this ICC profile is smaller than
64 kB, so this doesn't test the APP2 chunk re-arranging code at all.
Signed-off-by: Niklas Haas
---
libavcodec/ljpegenc.c| 6 ++--
libavcodec/mjpegenc.c| 3 +-
libavcodec/mjpegenc_common.c | 68 ++--
libavcodec/mjpegenc_common.h | 4 ++-
libavcodec/mpegvideo_enc.c | 4 ++-
tests/fate/image.mak | 6 +++-
tests/ref/fate/jpg-icc | 42 ++
7 files changed, 124 insertions(+), 9 deletions(-)
create mode 100644 tests/ref/fate/jpg-icc
diff --git a/libavcodec/ljpegenc.c b/libavcodec/ljpegenc.c
index 1af4475b75..522898eb73 100644
--- a/libavcodec/ljpegenc.c
+++ b/libavcodec/ljpegenc.c
@@ -220,7 +220,7 @@ static int ljpeg_encode_frame(AVCodecContext *avctx,
AVPacket *pkt,
const int height = avctx->height;
const int mb_width = (width + s->hsample[0] - 1) / s->hsample[0];
const int mb_height = (height + s->vsample[0] - 1) / s->vsample[0];
-int max_pkt_size = AV_INPUT_BUFFER_MIN_SIZE;
+size_t max_pkt_size = AV_INPUT_BUFFER_MIN_SIZE;
int ret, header_bits;
if(avctx->pix_fmt == AV_PIX_FMT_BGR0
@@ -233,12 +233,14 @@ static int ljpeg_encode_frame(AVCodecContext *avctx,
AVPacket *pkt,
* s->hsample[0] * s->vsample[0];
}
+if ((ret = ff_mjpeg_add_icc_profile_size(avctx, pict, _pkt_size)) < 0)
+return ret;
if ((ret = ff_alloc_packet(avctx, pkt, max_pkt_size)) < 0)
return ret;
init_put_bits(, pkt->data, pkt->size);
-ff_mjpeg_encode_picture_header(avctx, , NULL, >scantable,
+ff_mjpeg_encode_picture_header(avctx, , pict, NULL, >scantable,
s->pred, s->matrix, s->matrix, 0);
header_bits = put_bits_count();
diff --git a/libavcodec/mjpegenc.c b/libavcodec/mjpegenc.c
index 6ea113afb2..54ded08282 100644
--- a/libavcodec/mjpegenc.c
+++ b/libavcodec/mjpegenc.c
@@ -80,7 +80,7 @@ static av_cold void init_uni_ac_vlc(const uint8_t
huff_size_ac[256],
static void mjpeg_encode_picture_header(MpegEncContext *s)
{
-ff_mjpeg_encode_picture_header(s->avctx, >pb, s->mjpeg_ctx,
+ff_mjpeg_encode_picture_header(s->avctx, >pb, s->picture->f,
s->mjpeg_ctx,
>intra_scantable, 0,
s->intra_matrix, s->chroma_intra_matrix,
s->slice_context_count > 1);
@@ -131,6 +131,7 @@ static void mjpeg_encode_picture_frame(MpegEncContext *s)
}
bytes_needed = (total_bits + 7) / 8;
+ff_mjpeg_add_icc_profile_size(s->avctx, s->picture->f, _needed);
ff_mpv_reallocate_putbitbuffer(s, bytes_needed, bytes_needed);
for (int i = 0; i < m->huff_ncode; i++) {
diff --git a/libavcodec/mjpegenc_common.c b/libavcodec/mjpegenc_common.c
index 4143a372bb..98c464fc62 100644
--- a/libavcodec/mjpegenc_common.c
+++ b/libavcodec/mjpegenc_common.c
@@ -131,8 +131,41 @@ static void jpeg_table_header(AVCodecContext *avctx,
PutBitContext *p,
AV_WB16(ptr, size);
}
-static void jpeg_put_comments(AVCodecContext *avctx, PutBitContext *p)
+enum {
+ICC_HDR_SIZE= 16, /* ICC_PROFILE\0 tag + 4 bytes */
+ICC_CHUNK_SIZE = UINT16_MAX - ICC_HDR_SIZE,
+ICC_MAX_CHUNKS = UINT8_MAX,
+};
+
+int ff_mjpeg_add_icc_profile_size(AVCodecContext *avctx, const AVFrame *frame,
+ size_t *max_pkt_size)
{
+const AVFrameSideData *sd;
+size_t new_pkt_size;
+int nb_chunks;
+sd = av_frame_get_side_data(frame, AV_FRAME_DATA_ICC_PROFILE);
+if (!sd || !sd->size)
+return 0;
+
+if (sd->size > ICC_MAX_CHUNKS * ICC_CHUNK_SIZE) {
+av_log(avctx, AV_LOG_ERROR, "Cannot store %"SIZE_SPECIFIER" byte ICC "
+ "profile: too large for JPEG\n",
+ sd->size);
+return AVERROR_INVALIDDATA;
+}
+
+nb_chunks = (sd->size + ICC_CHUNK_SIZE - 1) / ICC_CHUNK_SIZE;
+new_pkt_size = *max_pkt_size + nb_chunks * (UINT16_MAX + 2 /* APP2 marker
*/);
+if (new_pkt_size < *max_pkt_size) /* overflow */
+return AVERROR_INVALIDDATA;
+*max_pkt_size = new_pkt_size;
+return 0;
+}
+
+static void jpeg_put_comments(AVCodecContext *avctx, PutBitContext *p,
+ const AVFrame *frame)
+{
+const AVFrameSideData *sd = NULL;
int size;
uint8_t *ptr;
@@ -162,6 +195,35 @@ static void jpeg_put_comments(AVCodecContext *avctx,
PutBitContext *p)
[FFmpeg-devel] [PATCH v8 1/2] avcodec/pngenc: support writing iCCP chunks
From: Niklas Haas
We re-use the PNGEncContext.zstream for deflate-related operations.
Other than that, the code is pretty straightforward. Special care needs
to be taken to avoid writing more than 79 characters of the profile
description (the maximum supported).
To write the (dynamically sized) deflate-encoded data, we allocate extra
space in the packet and use that directly as a scratch buffer. Modify
png_write_chunk slightly to allow pre-writing the chunk contents like
this.
Also add a FATE transcode test to ensure that the ICC profile gets
encoded correctly.
Signed-off-by: Niklas Haas
---
libavcodec/pngenc.c| 84 +-
tests/fate/image.mak | 10 -
tests/ref/fate/png-icc | 43 +
3 files changed, 133 insertions(+), 4 deletions(-)
create mode 100644 tests/ref/fate/png-icc
diff --git a/libavcodec/pngenc.c b/libavcodec/pngenc.c
index f67f90cd14..47a5ede888 100644
--- a/libavcodec/pngenc.c
+++ b/libavcodec/pngenc.c
@@ -236,7 +236,8 @@ static void png_write_chunk(uint8_t **f, uint32_t tag,
bytestream_put_be32(f, av_bswap32(tag));
if (length > 0) {
crc = av_crc(crc_table, crc, buf, length);
-memcpy(*f, buf, length);
+if (*f != buf)
+memcpy(*f, buf, length);
*f += length;
}
bytestream_put_be32(f, ~crc);
@@ -345,10 +346,53 @@ static int png_get_gama(enum
AVColorTransferCharacteristic trc, uint8_t *buf)
return 1;
}
+static int png_write_iccp(PNGEncContext *s, const AVFrameSideData *sd)
+{
+z_stream *const zstream = >zstream.zstream;
+const AVDictionaryEntry *entry;
+const char *name;
+uint8_t *start, *buf;
+int ret;
+
+if (!sd || !sd->size)
+return 0;
+zstream->next_in = sd->data;
+zstream->avail_in = sd->size;
+
+/* write the chunk contents first */
+start = s->bytestream + 8; /* make room for iCCP tag + length */
+buf = start;
+
+/* profile description */
+entry = av_dict_get(sd->metadata, "name", NULL, 0);
+name = (entry && entry->value[0]) ? entry->value : "icc";
+for (int i = 0;; i++) {
+char c = (i == 79) ? 0 : name[i];
+bytestream_put_byte(, c);
+if (!c)
+break;
+}
+
+/* compression method and profile data */
+bytestream_put_byte(, 0);
+zstream->next_out = buf;
+zstream->avail_out = s->bytestream_end - buf;
+ret = deflate(zstream, Z_FINISH);
+deflateReset(zstream);
+if (ret != Z_STREAM_END)
+return AVERROR_EXTERNAL;
+
+/* rewind to the start and write the chunk header/crc */
+png_write_chunk(>bytestream, MKTAG('i', 'C', 'C', 'P'), start,
+zstream->next_out - start);
+return 0;
+}
+
static int encode_headers(AVCodecContext *avctx, const AVFrame *pict)
{
AVFrameSideData *side_data;
PNGEncContext *s = avctx->priv_data;
+int ret;
/* write png header */
AV_WB32(s->buf, avctx->width);
@@ -401,7 +445,11 @@ static int encode_headers(AVCodecContext *avctx, const
AVFrame *pict)
if (png_get_gama(pict->color_trc, s->buf))
png_write_chunk(>bytestream, MKTAG('g', 'A', 'M', 'A'), s->buf, 4);
-/* put the palette if needed */
+side_data = av_frame_get_side_data(pict, AV_FRAME_DATA_ICC_PROFILE);
+if ((ret = png_write_iccp(s, side_data)))
+return ret;
+
+/* put the palette if needed, must be after colorspace information */
if (s->color_type == PNG_COLOR_TYPE_PALETTE) {
int has_alpha, alpha, i;
unsigned int v;
@@ -525,6 +573,34 @@ the_end:
return ret;
}
+static int add_icc_profile_size(AVCodecContext *avctx, const AVFrame *pict,
+uint64_t *max_packet_size)
+{
+PNGEncContext *s = avctx->priv_data;
+const AVFrameSideData *sd;
+const int hdr_size = 128;
+uint64_t new_pkt_size;
+uLong bound;
+
+if (!pict)
+return 0;
+sd = av_frame_get_side_data(pict, AV_FRAME_DATA_ICC_PROFILE);
+if (!sd || !sd->size)
+return 0;
+if (sd->size != (uLong) sd->size)
+return AVERROR_INVALIDDATA;
+
+bound = deflateBound(>zstream.zstream, sd->size);
+if (bound > INT32_MAX - hdr_size)
+return AVERROR_INVALIDDATA;
+
+new_pkt_size = *max_packet_size + bound + hdr_size;
+if (new_pkt_size < *max_packet_size)
+return AVERROR_INVALIDDATA;
+*max_packet_size = new_pkt_size;
+return 0;
+}
+
static int encode_png(AVCodecContext *avctx, AVPacket *pkt,
const AVFrame *pict, int *got_packet)
{
@@ -541,6 +617,8 @@ static int encode_png(AVCodecContext *avctx, AVPacket *pkt,
enc_row_size +
12 * (((int64_t)enc_row_size + IOBUF_SIZE - 1) / IOBUF_SIZE) //
IDAT * ceil(enc_row_size / IOBUF_SIZE)
);
+if ((ret = add_icc_profile_size(avctx, pict, _packet_size)))
+return ret;
ret = ff_alloc_packet(avctx, pkt, max_packet_size);
if (ret < 0)
Re: [FFmpeg-devel] [PATCH v7 1/2] avcodec/pngenc: support writing iCCP chunks
On Fri, 01 Apr 2022 15:31:16 +0200 Andreas Rheinhardt wrote: > Passing the PNGEncContext would be more natural. Changed. > Since db57a5370bd37105d389a45b04bf4970802407ec the callers' > max_packet_size are not size_t any more, but always 64bit (so that > there's no truncation in case size_t is 32bit). Changed. > ULONG_MAX is the maximum of unsigned long, yet deflateBound uses uLong. > The latter is a currently typedef for unsigned long, but do we want to > rely on that? The ordinary way to check for whethe a value can be > represented in a type is by "if (sd->size != (uLong)sd->size)" Changed. I didn't know about this trick, thanks. > AV_LOG_WARNING makes no sense given that you error out afterwards. > (And anyway: Is a log-message really needed for something that will > never happen in reality?) I think you're right. For JPEG it makes sense to keep around an error printout, because the JPEG profile limit is quite small in comparison (16 MB - the largest ICC profiles I have encountered in the wild are on the order of megabytes as well). But PNG supports up to 4 GB ICC profiles, which strains all conceivable credibility. Somebody would have to be deliberately trying to hit this limitation. Removed both error printouts (including the one about zlib misbehaving, equally unlikely). ___ 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 v12 2/4] avcodec/libjxl: add Jpeg XL decoding via libjxl
Quoting Leo Izen (2022-04-02 22:12:08)
> +case JXL_DEC_COLOR_ENCODING:
> +av_log(avctx, AV_LOG_DEBUG, "COLOR_ENCODING event emitted\n");
> +jret = JxlDecoderGetICCProfileSize(ctx->decoder,
> >jxl_pixfmt, JXL_COLOR_PROFILE_TARGET_ORIGINAL, >iccp_len);
Does iccp_len need to be a context variable? Seems to me it's only used
in this block.
> +if (jret == JXL_DEC_SUCCESS && ctx->iccp_len > 0) {
> +av_buffer_unref(>iccp);
> +av_assert2(!ctx->iccp);
Useless assert, you can rely on basic functions to do what they should.
> +ctx->iccp = av_buffer_alloc(ctx->iccp_len);
> +if (!ctx->iccp)
> +return AVERROR(ENOMEM);
> +jret = JxlDecoderGetColorAsICCProfile(ctx->decoder,
> >jxl_pixfmt, JXL_COLOR_PROFILE_TARGET_ORIGINAL, ctx->iccp->data,
> ctx->iccp_len);
> +if (jret != JXL_DEC_SUCCESS)
> +av_freep(>iccp);
av_buffer_unref?
> +}
> +continue;
> +case JXL_DEC_FRAME:
> +case JXL_DEC_NEED_IMAGE_OUT_BUFFER:
> +/*
> + * We don't do this at basic info time
> + * because it will happen again when we
> + * rewind anyway
> + */
> +av_log(avctx, AV_LOG_DEBUG, "%s event emitted\n", jret ==
> JXL_DEC_FRAME ? "FRAME" : "NEED_IMAGE_OUT_BUFFER");
> +ret = ff_get_buffer(avctx, frame, 0);
Is it absolutely guaranteed that this will always happen before
JXL_DEC_FULL_IMAGE in the same libjxl_decode_frame() invocation?
Can it happen that you get JXL_DEC_NEED_IMAGE_OUT_BUFFER/JXL_DEC_FRAME,
then JXL_DEC_NEED_MORE_INPUT, which causes you to return, then
JXL_DEC_FULL_IMAGE on the next libjxl_decode_frame() call?
> +case JXL_DEC_SUCCESS:
> +av_log(avctx, AV_LOG_DEBUG, "SUCCESS event emitted\n");
> +/*
> + * The file has finished decoding
> + * reset the decoder to let us
> + * reuse it again for the next image
> + */
> +JxlDecoderReset(ctx->decoder);
> +libjxl_init_jxl_decoder(avctx);
> +buf = avpkt->data;
> +remaining = avpkt->size;
Why reset buf? The same data is not going to be decoded again, is it?
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/libvpxenc: return quantizer parameter for an encoded frame
Quoting Danil Chapovalov (2022-03-24 18:25:24)
> ---
> libavcodec/libvpxenc.c | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
> index dff1d06b0e..5db31db5dc 100644
> --- a/libavcodec/libvpxenc.c
> +++ b/libavcodec/libvpxenc.c
> @@ -1250,6 +1250,7 @@ static int storeframe(AVCodecContext *avctx, struct
> FrameListData *cx_frame,
> int ret = ff_get_encode_buffer(avctx, pkt, cx_frame->sz, 0);
> uint8_t *side_data;
> int pict_type;
> +int quality;
>
> if (ret < 0)
> return ret;
> @@ -1264,7 +1265,13 @@ static int storeframe(AVCodecContext *avctx, struct
> FrameListData *cx_frame,
> pict_type = AV_PICTURE_TYPE_P;
> }
>
> -ff_side_data_set_encoder_stats(pkt, 0, cx_frame->sse + 1,
> +ret = vpx_codec_control(&((VPxContext *)avctx->priv_data)->encoder,
The cast is really ugly, just add a local variable for priv_data.
> +VP8E_GET_LAST_QUANTIZER_64, );
> +if (ret != VPX_CODEC_OK) {
> +quality = 0;
> +}
> +
> +ff_side_data_set_encoder_stats(pkt, quality, cx_frame->sse + 1,
other encoders multiply the quantizer by FF_QP2LAMBDA
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] avformat/matroskadec: avoid integer overflows in SAR computation
Quoting Michael Niedermayer (2022-04-01 12:46:08)
> This ignores >64bit
> Alternatively we could support that if it occurs in reality
>
> Fixes: negation of -9223372036854775808
> Fixes: integer overflows
> Fixes:
> 46072/clusterfuzz-testcase-minimized-ffmpeg_dem_MATROSKA_fuzzer-5029840966778880
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/matroskadec.c | 13 -
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
> index d97fc33d44..069fba6cf7 100644
> --- a/libavformat/matroskadec.c
> +++ b/libavformat/matroskadec.c
> @@ -2886,11 +2886,14 @@ static int matroska_parse_tracks(AVFormatContext *s)
> mkv_stereo_mode_display_mul(track->video.stereo_mode,
> _width_mul, _height_mul);
>
> if (track->video.display_unit <
> MATROSKA_VIDEO_DISPLAYUNIT_UNKNOWN) {
> -av_reduce(>sample_aspect_ratio.num,
> - >sample_aspect_ratio.den,
> - st->codecpar->height * track->video.display_width
> * display_width_mul,
> - st->codecpar->width * track->video.display_height
> * display_height_mul,
> - INT_MAX);
> +if (track->video.display_width &&
> track->video.display_height &&
> +st->codecpar->height * (int64_t)display_width_mul <
> INT64_MAX / track->video.display_width &&
> +st->codecpar->width * (int64_t)display_height_mul <
> INT64_MAX / track->video.display_height)
Why not move display_{width,height}_mul to the other side of the
comparison and avoid wordsize assumptions? This is header parsing, so
division performance impact should be negligible.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/3] hwcontext_vulkan: add queue and frame locking functions
Quoting Lynne (2022-04-03 16:52:24)
> This allows for multiple threads to access the same frame. This is
> unfortunately necessary, as in Vulkan, queues are considered to be
> up to the user to synchronize, while frames often have their layout
> changed upon reading.
>
> Patch attached.
>
>
> From d8bd429859f9dc90325dbd0a7355b21ad5a80b6f Mon Sep 17 00:00:00 2001
> From: Lynne
> Date: Sun, 3 Apr 2022 16:44:58 +0200
> Subject: [PATCH 2/3] hwcontext_vulkan: add queue and frame locking functions
>
> This allows for multiple threads to access the same frame. This is
> unfortunately necessary, as in Vulkan, queues are considered to be
> up to the user to synchronize, while frames often have their layout
> changed upon reading.
> ---
> libavutil/hwcontext_vulkan.c | 180 ++-
> libavutil/hwcontext_vulkan.h | 28 ++
> 2 files changed, 164 insertions(+), 44 deletions(-)
>
> diff --git a/libavutil/hwcontext_vulkan.c b/libavutil/hwcontext_vulkan.c
> index 1176858545..5bd0cab7ef 100644
> --- a/libavutil/hwcontext_vulkan.c
> +++ b/libavutil/hwcontext_vulkan.c
> @@ -27,6 +27,7 @@
> #include
> #endif
>
> +#include
Either make vulkan depend on threads or make this all conditional somehow.
> @@ -4129,7 +4209,19 @@ static int vulkan_frames_derive_to(AVHWFramesContext
> *dst_fc,
>
> AVVkFrame *av_vk_frame_alloc(void)
> {
> -return av_mallocz(sizeof(AVVkFrame));
> +AVVkFrame *f = av_mallocz(sizeof(AVVkFrame));
> +if (!f)
> +return NULL;
> +
> +f->internal = av_mallocz(sizeof(*f->internal));
Doxy says AVVkFrame can be freed with av_free.
> +if (!f->internal) {
> +av_free(f);
> +return NULL;
> +}
> +
> +pthread_mutex_init(>internal->lock, NULL);
> +
> +return f;
> }
>
> const HWContextType ff_hwcontext_type_vulkan = {
> diff --git a/libavutil/hwcontext_vulkan.h b/libavutil/hwcontext_vulkan.h
> index ce8a835c6f..5864ae1264 100644
> --- a/libavutil/hwcontext_vulkan.h
> +++ b/libavutil/hwcontext_vulkan.h
> @@ -135,6 +135,19 @@ typedef struct AVVulkanDeviceContext {
> */
> int queue_family_decode_index;
> int nb_decode_queues;
> +
> +/**
> + * Locks a queue, preventing other threads from submitting any command
> + * buffers to this queue.
> + * If set to NULL, will be set to lavu-internal functions that utilize a
> + * mutex.
I'd expect some prescription for who calls this and when. Like
"Any users accessing any queues associated with this device MUST call
this callback before manipulating the queue and unlock_queue() after
they are done."
Same for lock_frame()
> + */
> +void (*lock_queue)(AVHWDeviceContext *ctx, int queue_family, int index);
any reason those are signed?
> +
> +/**
> + * Similar to lock_queue(), unlocks a queue. Must only be called after
> it.
s/similar/complementary/
> + */
> +void (*unlock_queue)(AVHWDeviceContext *ctx, int queue_family, int
> index);
> } AVVulkanDeviceContext;
>
> /**
> @@ -195,6 +208,21 @@ typedef struct AVVulkanFramesContext {
> * av_hwframe_ctx_init().
> */
> AVVkFrameFlags flags;
> +
> +/**
> + * Locks a frame, preventing other threads from changing frame
> properties.
> + * If set to NULL, will be set to lavu-internal functions that utilize a
> + * mutex.
> + * Users SHOULD only ever lock just before command submission in order
> + * to get accurate frame properties, and unlock immediately after command
> + * submission without waiting for it to finish.
> + */
> +void (*lock_frame)(AVHWFramesContext *fc, AVFrame *f);
> +
> +/**
> + * Similar to lock_frame(), unlocks a frame. Must only be called after
> it.
> + */
> +void (*unlock_frame)(AVHWFramesContext *fc, AVFrame *f);
> } AVVulkanFramesContext;
>
> /*
> --
> 2.35.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".
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 1/4] avutil: add ambient viewing environment metadata side data
On Tue, Apr 05, 2022 at 11:13:12AM +0200, Anton Khirnov wrote:
> Quoting lance.lmw...@gmail.com (2022-03-28 14:41:08)
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavutil/frame.c | 1 +
> > libavutil/frame.h | 6 +
> > libavutil/mastering_display_metadata.c | 23 +
> > libavutil/mastering_display_metadata.h | 45
> > ++
> > 4 files changed, 75 insertions(+)
> >
> > diff --git a/libavutil/frame.c b/libavutil/frame.c
> > index fbb869f..8882da2 100644
> > --- a/libavutil/frame.c
> > +++ b/libavutil/frame.c
> > @@ -815,6 +815,7 @@ const char *av_frame_side_data_name(enum
> > AVFrameSideDataType type)
> > case AV_FRAME_DATA_DETECTION_BBOXES:return "Bounding boxes
> > for object detection and classification";
> > case AV_FRAME_DATA_DOVI_RPU_BUFFER: return "Dolby Vision
> > RPU Data";
> > case AV_FRAME_DATA_DOVI_METADATA: return "Dolby Vision
> > Metadata";
> > +case AV_FRAME_DATA_AMBIENT_VIEWING_ENV: return "Ambient
> > Viewing Environment";
> > }
> > return NULL;
> > }
> > diff --git a/libavutil/frame.h b/libavutil/frame.h
> > index 33fac20..f7b1d4e 100644
> > --- a/libavutil/frame.h
> > +++ b/libavutil/frame.h
> > @@ -209,6 +209,12 @@ enum AVFrameSideDataType {
> > * volume transform - CUVA 005.1-2021.
> > */
> > AV_FRAME_DATA_DYNAMIC_HDR_VIVID,
> > +
> > +/**
> > + * ambient viewing environment for a video frame, as described by
> > + * the AVAmbientViewingEnvMetadata.
> > + */
> > +AV_FRAME_DATA_AMBIENT_VIEWING_ENV,
> > };
> >
> > enum AVActiveFormatDescription {
> > diff --git a/libavutil/mastering_display_metadata.c
> > b/libavutil/mastering_display_metadata.c
> > index 6069347..ba1c80f 100644
> > --- a/libavutil/mastering_display_metadata.c
> > +++ b/libavutil/mastering_display_metadata.c
> > @@ -64,3 +64,26 @@ AVContentLightMetadata
> > *av_content_light_metadata_create_side_data(AVFrame *fram
> >
> > return (AVContentLightMetadata *)side_data->data;
> > }
> > +
> > +AVAmbientViewingEnvMetadata *av_ambient_viewing_env_metadata_alloc(size_t
> > *size)
> > +{
> > +AVAmbientViewingEnvMetadata *metadata = av_mallocz(sizeof(*metadata));
> > +
> > +if (size)
> > +*size = sizeof(*metadata);
> > +
> > +return metadata;
> > +}
> > +
> > +AVAmbientViewingEnvMetadata
> > *av_ambient_viewing_env_metadata_create_side_data(AVFrame *frame)
> > +{
> > +AVFrameSideData *side_data = av_frame_new_side_data(frame,
> > +AV_FRAME_DATA_AMBIENT_VIEWING_ENV,
> > +sizeof(AVAmbientViewingEnvMetadata));
> > +if (!side_data)
> > +return NULL;
> > +
> > +memset(side_data->data, 0, sizeof(AVAmbientViewingEnvMetadata));
> > +
> > +return (AVAmbientViewingEnvMetadata *)side_data->data;
> > +}
> > diff --git a/libavutil/mastering_display_metadata.h
> > b/libavutil/mastering_display_metadata.h
> > index c23b07c..d7598c1 100644
> > --- a/libavutil/mastering_display_metadata.h
> > +++ b/libavutil/mastering_display_metadata.h
> > @@ -125,4 +125,49 @@ AVContentLightMetadata
> > *av_content_light_metadata_alloc(size_t *size);
> > */
> > AVContentLightMetadata *av_content_light_metadata_create_side_data(AVFrame
> > *frame);
>
> The names are horribly long. I would suggest dropping 'metadata' from
> the struct and function names, they'd be shorter and no information is
> really lost.
I'm OK with the suggestion, will update the patch, thanks.
>
> --
> Anton Khirnov
--
Thanks,
Limin Wang
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 1/4] avutil: add ambient viewing environment metadata side data
Quoting lance.lmw...@gmail.com (2022-03-28 14:41:08)
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavutil/frame.c | 1 +
> libavutil/frame.h | 6 +
> libavutil/mastering_display_metadata.c | 23 +
> libavutil/mastering_display_metadata.h | 45
> ++
> 4 files changed, 75 insertions(+)
>
> diff --git a/libavutil/frame.c b/libavutil/frame.c
> index fbb869f..8882da2 100644
> --- a/libavutil/frame.c
> +++ b/libavutil/frame.c
> @@ -815,6 +815,7 @@ const char *av_frame_side_data_name(enum
> AVFrameSideDataType type)
> case AV_FRAME_DATA_DETECTION_BBOXES:return "Bounding boxes
> for object detection and classification";
> case AV_FRAME_DATA_DOVI_RPU_BUFFER: return "Dolby Vision RPU
> Data";
> case AV_FRAME_DATA_DOVI_METADATA: return "Dolby Vision
> Metadata";
> +case AV_FRAME_DATA_AMBIENT_VIEWING_ENV: return "Ambient Viewing
> Environment";
> }
> return NULL;
> }
> diff --git a/libavutil/frame.h b/libavutil/frame.h
> index 33fac20..f7b1d4e 100644
> --- a/libavutil/frame.h
> +++ b/libavutil/frame.h
> @@ -209,6 +209,12 @@ enum AVFrameSideDataType {
> * volume transform - CUVA 005.1-2021.
> */
> AV_FRAME_DATA_DYNAMIC_HDR_VIVID,
> +
> +/**
> + * ambient viewing environment for a video frame, as described by
> + * the AVAmbientViewingEnvMetadata.
> + */
> +AV_FRAME_DATA_AMBIENT_VIEWING_ENV,
> };
>
> enum AVActiveFormatDescription {
> diff --git a/libavutil/mastering_display_metadata.c
> b/libavutil/mastering_display_metadata.c
> index 6069347..ba1c80f 100644
> --- a/libavutil/mastering_display_metadata.c
> +++ b/libavutil/mastering_display_metadata.c
> @@ -64,3 +64,26 @@ AVContentLightMetadata
> *av_content_light_metadata_create_side_data(AVFrame *fram
>
> return (AVContentLightMetadata *)side_data->data;
> }
> +
> +AVAmbientViewingEnvMetadata *av_ambient_viewing_env_metadata_alloc(size_t
> *size)
> +{
> +AVAmbientViewingEnvMetadata *metadata = av_mallocz(sizeof(*metadata));
> +
> +if (size)
> +*size = sizeof(*metadata);
> +
> +return metadata;
> +}
> +
> +AVAmbientViewingEnvMetadata
> *av_ambient_viewing_env_metadata_create_side_data(AVFrame *frame)
> +{
> +AVFrameSideData *side_data = av_frame_new_side_data(frame,
> +AV_FRAME_DATA_AMBIENT_VIEWING_ENV,
> +sizeof(AVAmbientViewingEnvMetadata));
> +if (!side_data)
> +return NULL;
> +
> +memset(side_data->data, 0, sizeof(AVAmbientViewingEnvMetadata));
> +
> +return (AVAmbientViewingEnvMetadata *)side_data->data;
> +}
> diff --git a/libavutil/mastering_display_metadata.h
> b/libavutil/mastering_display_metadata.h
> index c23b07c..d7598c1 100644
> --- a/libavutil/mastering_display_metadata.h
> +++ b/libavutil/mastering_display_metadata.h
> @@ -125,4 +125,49 @@ AVContentLightMetadata
> *av_content_light_metadata_alloc(size_t *size);
> */
> AVContentLightMetadata *av_content_light_metadata_create_side_data(AVFrame
> *frame);
The names are horribly long. I would suggest dropping 'metadata' from
the struct and function names, they'd be shorter and no information is
really lost.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavcodec/hevcdec: detect non-conformant missing refs
Quoting Xiaolei Yu (2022-04-05 08:49:24)
>
> For cases which prefer rejecting broken bitstreams.
> ---
> libavcodec/hevc_refs.c | 15 ---
> 1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/hevc_refs.c b/libavcodec/hevc_refs.c
> index fe18ca2b1d..7ea70e301b 100644
> --- a/libavcodec/hevc_refs.c
> +++ b/libavcodec/hevc_refs.c
> @@ -426,7 +426,7 @@ static HEVCFrame *generate_missing_ref(HEVCContext *s,
> int poc)
>
> /* add a reference with the given poc to the list and mark it as used in DPB
> */
> static int add_candidate_ref(HEVCContext *s, RefPicList *list,
> - int poc, int ref_flag, uint8_t use_msb)
> + int poc, int ref_flag, uint8_t use_msb, int
> maybe_missing)
allow_missing would be clearer IMO
> {
> HEVCFrame *ref = find_ref_idx(s, poc, use_msb);
>
> @@ -434,6 +434,9 @@ static int add_candidate_ref(HEVCContext *s, RefPicList
> *list,
> return AVERROR_INVALIDDATA;
>
> if (!ref) {
> +if ((s->avctx->err_recognition & AV_EF_COMPLIANT) && !maybe_missing)
a log message would be nice, so one can easily tell where exactly the
error comes from
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded architecture
The code can also be obtained from branch ffmpeg_mt/mux in my tree git://git.khirnov.net/libav -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] lavfi: Add blurriness filter
Hi,
v3 updated to current HEAD.
Named blurdetect filter now.
Minor fixes on allocation and removed -f option.
Please make this per plane filtering, with default to measure only first
plane.
done in v4.
(Will add Changelog, version.h and fate test once the filter itself looks ok)
Thanks,
ThiloFrom 6411603fe86d4fb6a781aec2ff48e48be12d269e Mon Sep 17 00:00:00 2001
From: Thilo Borgmann
Date: Tue, 5 Apr 2022 10:54:19 +0200
Subject: [PATCH v4 2/2] lavfi: Add blurdetect filter
---
doc/filters.texi| 52 +
libavfilter/Makefile| 1 +
libavfilter/allfilters.c| 1 +
libavfilter/vf_blurdetect.c | 394
4 files changed, 448 insertions(+)
create mode 100644 libavfilter/vf_blurdetect.c
diff --git a/doc/filters.texi b/doc/filters.texi
index 636c80dbff..c6d4537804 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -7990,6 +7990,58 @@ tblend=all_mode=grainextract
@subsection Commands
This filter supports same @ref{commands} as options.
+@anchor{blurdetect}
+@section blurdetect
+
+Determines blurriness of frames without altering the input frames.
+
+Based on Marziliano, Pina, et al. "A no-reference perceptual blur metric."
+Allows for a block-based abbreviation.
+
+The filter accepts the following options:
+
+@table @option
+@item low
+@item high
+Set low and high threshold values used by the Canny thresholding
+algorithm.
+
+The high threshold selects the "strong" edge pixels, which are then
+connected through 8-connectivity with the "weak" edge pixels selected
+by the low threshold.
+
+@var{low} and @var{high} threshold values must be chosen in the range
+[0,1], and @var{low} should be lesser or equal to @var{high}.
+
+Default value for @var{low} is @code{20/255}, and default value for @var{high}
+is @code{50/255}.
+
+@item radius
+Define the radius to search around an edge pixel for local maxima.
+
+@item block_pct
+Determine blurriness only for the most significant blocks, given in percentage.
+
+@item block_width
+Determine blurriness for blocks of width @var{block_width}. If set to any
value smaller 1, no blocks are used and the whole image is processed as one no
matter of @var{block_height}.
+
+@item block_height
+Determine blurriness for blocks of height @var{block_height}. If set to any
value smaller 1, no blocks are used and the whole image is processed as one no
matter of @var{block_width}.
+
+@item planes
+Set planes to filter. Default is first only.
+@end table
+
+@subsection Examples
+
+@itemize
+@item
+Determine blur for 80% of most significant 32x32 blocks:
+@example
+blurdetect=block_width=32:block_height=32:block_pct=80
+@end example
+@end itemize
+
@section bm3d
Denoise frames using Block-Matching 3D algorithm.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 006e59b2bd..6332a6f799 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -195,6 +195,7 @@ OBJS-$(CONFIG_BLACKDETECT_FILTER)+=
vf_blackdetect.o
OBJS-$(CONFIG_BLACKFRAME_FILTER) += vf_blackframe.o
OBJS-$(CONFIG_BLEND_FILTER) += vf_blend.o framesync.o
OBJS-$(CONFIG_BLEND_VULKAN_FILTER) += vf_blend_vulkan.o framesync.o
vulkan.o vulkan_filter.o
+OBJS-$(CONFIG_BLURDETECT_FILTER) += vf_blurdetect.o edge_common.o
OBJS-$(CONFIG_BM3D_FILTER) += vf_bm3d.o framesync.o
OBJS-$(CONFIG_BOXBLUR_FILTER)+= vf_boxblur.o boxblur.o
OBJS-$(CONFIG_BOXBLUR_OPENCL_FILTER) += vf_avgblur_opencl.o opencl.o \
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 9fbaaacf47..2667d153ad 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -183,6 +183,7 @@ extern const AVFilter ff_vf_blackdetect;
extern const AVFilter ff_vf_blackframe;
extern const AVFilter ff_vf_blend;
extern const AVFilter ff_vf_blend_vulkan;
+extern const AVFilter ff_vf_blurdetect;
extern const AVFilter ff_vf_bm3d;
extern const AVFilter ff_vf_boxblur;
extern const AVFilter ff_vf_boxblur_opencl;
diff --git a/libavfilter/vf_blurdetect.c b/libavfilter/vf_blurdetect.c
new file mode 100644
index 00..71e46fa962
--- /dev/null
+++ b/libavfilter/vf_blurdetect.c
@@ -0,0 +1,394 @@
+/*
+ * Copyright (c) 2021 Thilo Borgmann
+ *
+ * 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
[FFmpeg-devel] [PATCH] libavcodec/hevcdec: detect non-conformant missing refs
For cases which prefer rejecting broken bitstreams.
---
libavcodec/hevc_refs.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/libavcodec/hevc_refs.c b/libavcodec/hevc_refs.c
index fe18ca2b1d..7ea70e301b 100644
--- a/libavcodec/hevc_refs.c
+++ b/libavcodec/hevc_refs.c
@@ -426,7 +426,7 @@ static HEVCFrame *generate_missing_ref(HEVCContext *s, int
poc)
/* add a reference with the given poc to the list and mark it as used in DPB */
static int add_candidate_ref(HEVCContext *s, RefPicList *list,
- int poc, int ref_flag, uint8_t use_msb)
+ int poc, int ref_flag, uint8_t use_msb, int
maybe_missing)
{
HEVCFrame *ref = find_ref_idx(s, poc, use_msb);
@@ -434,6 +434,9 @@ static int add_candidate_ref(HEVCContext *s, RefPicList
*list,
return AVERROR_INVALIDDATA;
if (!ref) {
+if ((s->avctx->err_recognition & AV_EF_COMPLIANT) && !maybe_missing)
+return AVERROR_INVALIDDATA;
+
ref = generate_missing_ref(s, poc);
if (!ref)
return AVERROR(ENOMEM);
@@ -476,6 +479,7 @@ int ff_hevc_frame_rps(HEVCContext *s)
for (i = 0; i < short_rps->num_delta_pocs; i++) {
int poc = s->poc + short_rps->delta_poc[i];
int list;
+int maybe_missing;
if (!short_rps->used[i])
list = ST_FOLL;
@@ -484,7 +488,10 @@ int ff_hevc_frame_rps(HEVCContext *s)
else
list = ST_CURR_AFT;
-ret = add_candidate_ref(s, [list], poc, HEVC_FRAME_FLAG_SHORT_REF,
1);
+maybe_missing = list != ST_CURR_BEF && list != ST_CURR_AFT;
+
+ret = add_candidate_ref(s, [list], poc, HEVC_FRAME_FLAG_SHORT_REF,
1,
+maybe_missing);
if (ret < 0)
goto fail;
}
@@ -493,8 +500,10 @@ int ff_hevc_frame_rps(HEVCContext *s)
for (i = 0; i < long_rps->nb_refs; i++) {
int poc = long_rps->poc[i];
int list = long_rps->used[i] ? LT_CURR : LT_FOLL;
+int maybe_missing = list != LT_CURR;
-ret = add_candidate_ref(s, [list], poc, HEVC_FRAME_FLAG_LONG_REF,
long_rps->poc_msb_present[i]);
+ret = add_candidate_ref(s, [list], poc, HEVC_FRAME_FLAG_LONG_REF,
long_rps->poc_msb_present[i],
+maybe_missing);
if (ret < 0)
goto fail;
}
--
2.35.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 1/4] avutil: add ambient viewing environment metadata side data
On Mon, Mar 28, 2022 at 08:41:08PM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavutil/frame.c | 1 +
> libavutil/frame.h | 6 +
> libavutil/mastering_display_metadata.c | 23 +
> libavutil/mastering_display_metadata.h | 45
> ++
> 4 files changed, 75 insertions(+)
>
> diff --git a/libavutil/frame.c b/libavutil/frame.c
> index fbb869f..8882da2 100644
> --- a/libavutil/frame.c
> +++ b/libavutil/frame.c
> @@ -815,6 +815,7 @@ const char *av_frame_side_data_name(enum
> AVFrameSideDataType type)
> case AV_FRAME_DATA_DETECTION_BBOXES:return "Bounding boxes
> for object detection and classification";
> case AV_FRAME_DATA_DOVI_RPU_BUFFER: return "Dolby Vision RPU
> Data";
> case AV_FRAME_DATA_DOVI_METADATA: return "Dolby Vision
> Metadata";
> +case AV_FRAME_DATA_AMBIENT_VIEWING_ENV: return "Ambient Viewing
> Environment";
> }
> return NULL;
> }
> diff --git a/libavutil/frame.h b/libavutil/frame.h
> index 33fac20..f7b1d4e 100644
> --- a/libavutil/frame.h
> +++ b/libavutil/frame.h
> @@ -209,6 +209,12 @@ enum AVFrameSideDataType {
> * volume transform - CUVA 005.1-2021.
> */
> AV_FRAME_DATA_DYNAMIC_HDR_VIVID,
> +
> +/**
> + * ambient viewing environment for a video frame, as described by
> + * the AVAmbientViewingEnvMetadata.
> + */
> +AV_FRAME_DATA_AMBIENT_VIEWING_ENV,
> };
>
> enum AVActiveFormatDescription {
> diff --git a/libavutil/mastering_display_metadata.c
> b/libavutil/mastering_display_metadata.c
> index 6069347..ba1c80f 100644
> --- a/libavutil/mastering_display_metadata.c
> +++ b/libavutil/mastering_display_metadata.c
> @@ -64,3 +64,26 @@ AVContentLightMetadata
> *av_content_light_metadata_create_side_data(AVFrame *fram
>
> return (AVContentLightMetadata *)side_data->data;
> }
> +
> +AVAmbientViewingEnvMetadata *av_ambient_viewing_env_metadata_alloc(size_t
> *size)
> +{
> +AVAmbientViewingEnvMetadata *metadata = av_mallocz(sizeof(*metadata));
> +
> +if (size)
> +*size = sizeof(*metadata);
> +
> +return metadata;
> +}
> +
> +AVAmbientViewingEnvMetadata
> *av_ambient_viewing_env_metadata_create_side_data(AVFrame *frame)
> +{
> +AVFrameSideData *side_data = av_frame_new_side_data(frame,
> +AV_FRAME_DATA_AMBIENT_VIEWING_ENV,
> +sizeof(AVAmbientViewingEnvMetadata));
> +if (!side_data)
> +return NULL;
> +
> +memset(side_data->data, 0, sizeof(AVAmbientViewingEnvMetadata));
> +
> +return (AVAmbientViewingEnvMetadata *)side_data->data;
> +}
> diff --git a/libavutil/mastering_display_metadata.h
> b/libavutil/mastering_display_metadata.h
> index c23b07c..d7598c1 100644
> --- a/libavutil/mastering_display_metadata.h
> +++ b/libavutil/mastering_display_metadata.h
> @@ -125,4 +125,49 @@ AVContentLightMetadata
> *av_content_light_metadata_alloc(size_t *size);
> */
> AVContentLightMetadata *av_content_light_metadata_create_side_data(AVFrame
> *frame);
>
> +/**
> + * The characteristics of the nominal ambient viewing environment for
> + * the display of the associated video content.
> + * To be used as payload of a AVFrameSideData the appropriate type.
> + *
> + * @note The struct should be allocated with
> av_ambient_viewing_env_metadata_alloc()
> + * and its size is not a part of the public ABI.
> + */
> +typedef struct AVAmbientViewingEnvMetadata {
> +/**
> + * specifies the environmental illuminance of the ambient viewing
> + * environment in units of 0.0001 lux.
> + * ambient_illuminance shall not be equal to 0.
> + */
> +uint32_t ambient_illuminance;
> +/**
> + * specify the normalized x and y chromaticity coordinates, respectively,
> + * of the environmental ambient light in the nominal viewing environment,
> + * according to the CIE 1931 definition of x and y as specified in ISO
> + * 11664-1 (see also ISO 11664-3 and CIE 15), in normalized increments of
> + * 0.2. The values of ambient_light_x and ambient_light_y shall be in
> + * the range of 0 to 5
> + */
> +uint16_t ambient_light_x;
> +uint16_t ambient_light_y;
> +} AVAmbientViewingEnvMetadata;
> +
> +/**
> + * Allocate an AVAmbientViewingEnvMetadata structure and set its fields to
> + * default values. The resulting struct can be freed using av_freep().
> + *
> + * @return An AVAmbientViewingEnvMetadata filled with default values or NULL
> + * on failure.
> + */
> +AVAmbientViewingEnvMetadata *av_ambient_viewing_env_metadata_alloc(size_t
> *size);
> +
> +/**
> + * Allocate a complete AVAmbientViewingEnvMetadata and add it to the frame.
> + *
> + * @param frame The frame which side data is added to.
> + *
> + * @return The AVAmbientViewingEnvMetadata structure to be filled by caller.
> + */
>
