Re: [FFmpeg-devel] FFV1 slicecrc: "hashxx" instead of "CRC" for speed?
Thanks for all your replies! Now I can refer to this, when being asked "Why CRC and not ...?" :) Kind regards, Peter ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 5/5] fftools/ffmpeg: make demuxing with one file always blocking
--- fftools/ffmpeg_demux.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/fftools/ffmpeg_demux.c b/fftools/ffmpeg_demux.c index 8ea5318148..b32bac217d 100644 --- a/fftools/ffmpeg_demux.c +++ b/fftools/ffmpeg_demux.c @@ -363,8 +363,9 @@ static int thread_start(Demuxer *d) if (d->thread_queue_size <= 0) d->thread_queue_size = (nb_input_files > 1 ? 8 : 1); -if (f->ctx->pb ? !f->ctx->pb->seekable : -strcmp(f->ctx->iformat->name, "lavfi")) +if (nb_input_files > 1 && +(f->ctx->pb ? !f->ctx->pb->seekable : + strcmp(f->ctx->iformat->name, "lavfi"))) d->non_blocking = 1; ret = av_thread_message_queue_alloc(&d->in_thread_queue, d->thread_queue_size, sizeof(DemuxMsg)); -- 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 1/5] lavf/rtpdec_asf: set AVFMT_FLAG_NONBLOCK
Makes sure EAGAIN from the internal ASF demuxer is propagated to the RTP
demuxer. Will be important in following commits.
---
libavformat/rtpdec_asf.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/rtpdec_asf.c b/libavformat/rtpdec_asf.c
index 72ead6975a..7824082d22 100644
--- a/libavformat/rtpdec_asf.c
+++ b/libavformat/rtpdec_asf.c
@@ -128,6 +128,7 @@ int ff_wms_parse_sdp_a_line(AVFormatContext *s, const char
*p)
return AVERROR(ENOMEM);
}
rt->asf_ctx->pb = &pb.pub;
+rt->asf_ctx->flags |= AVFMT_FLAG_NONBLOCK;
av_dict_set(&opts, "no_resync_search", "1", 0);
if ((ret = ff_copy_whiteblacklists(rt->asf_ctx, s)) < 0) {
--
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 4/5] fftools/ffmpeg_demux: do not set AVFMT_FLAG_NONBLOCK
This is pointless now that demuxing always runs in a separate thread.
Remove special handling for AVERROR(EAGAIN), which should never be
returned now.
---
fftools/ffmpeg_demux.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/fftools/ffmpeg_demux.c b/fftools/ffmpeg_demux.c
index ee867cc15c..8ea5318148 100644
--- a/fftools/ffmpeg_demux.c
+++ b/fftools/ffmpeg_demux.c
@@ -254,11 +254,6 @@ static void *input_thread(void *arg)
DemuxMsg msg = { NULL };
ret = av_read_frame(f->ctx, pkt);
-
-if (ret == AVERROR(EAGAIN)) {
-av_usleep(1);
-continue;
-}
if (ret < 0) {
if (d->loop) {
/* signal looping to the consumer thread */
@@ -917,7 +912,6 @@ int ifile_open(OptionsContext *o, const char *filename)
ic->subtitle_codec_id = subtitle_codec_name ? ic->subtitle_codec->id :
AV_CODEC_ID_NONE;
ic->data_codec_id = data_codec_name ? ic->data_codec->id :
AV_CODEC_ID_NONE;
-ic->flags |= AVFMT_FLAG_NONBLOCK;
if (o->bitexact)
ic->flags |= AVFMT_FLAG_BITEXACT;
ic->interrupt_callback = int_cb;
--
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 3/5] lavf: replace FFERROR_REDO with AVERROR(EAGAIN)
There is no meaningful distinction between them, both mean "the demuxer
did some work, but did not produce a packet - should be called again".
---
libavformat/demux.c | 12
libavformat/demux.h | 6 --
libavformat/flvdec.c | 14 +++---
libavformat/lxfdec.c | 2 +-
libavformat/mlvdec.c | 2 +-
libavformat/mpeg.c| 2 +-
libavformat/smacker.c | 2 +-
7 files changed, 15 insertions(+), 25 deletions(-)
diff --git a/libavformat/demux.c b/libavformat/demux.c
index 5cd9522367..8c81a58274 100644
--- a/libavformat/demux.c
+++ b/libavformat/demux.c
@@ -572,14 +572,10 @@ FF_ENABLE_DEPRECATION_WARNINGS
if (err < 0) {
av_packet_unref(pkt);
-/* Some demuxers return FFERROR_REDO when they consume
- data and discard it (ignored streams, junk, extradata).
- We must re-call the demuxer to get the real packet.
-
- Treat EAGAIN the same as FFERROR_REDO, unless the user
- requested non-blocking behavior. */
-if (err == FFERROR_REDO ||
-(err == AVERROR(EAGAIN) && !(s->flags & AVFMT_FLAG_NONBLOCK)))
+/* Some demuxers return AVERROR(EAGAIN) when they consume
+ data and discard it (ignored streams, junk, extradata). Call the
+ demuxer again unless the user requested non-blocking behavior.
*/
+if (err == AVERROR(EAGAIN) && !(s->flags & AVFMT_FLAG_NONBLOCK))
continue;
if (!pktl || err == AVERROR(EAGAIN))
return err;
diff --git a/libavformat/demux.h b/libavformat/demux.h
index 1f57e062f6..a008c3dba1 100644
--- a/libavformat/demux.h
+++ b/libavformat/demux.h
@@ -55,12 +55,6 @@ typedef struct FFStreamInfo {
int fps_last_dts_idx;
} FFStreamInfo;
-/**
- * Returned by demuxers to indicate that data was consumed but discarded
- * (ignored streams or junk data). The framework will re-call the demuxer.
- */
-#define FFERROR_REDO FFERRTAG('R','E','D','O')
-
#define RELATIVE_TS_BASE (INT64_MAX - (1LL << 48))
static av_always_inline int is_relative(int64_t ts)
diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index d83edff727..d320a431db 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -1058,7 +1058,7 @@ retry:
}
if (size == 0) {
-ret = FFERROR_REDO;
+ret = AVERROR(EAGAIN);
goto leave;
}
@@ -1110,13 +1110,13 @@ skip:
av_log(s, AV_LOG_ERROR, "Unable to seek to the next packet\n");
return AVERROR_INVALIDDATA;
}
-ret = FFERROR_REDO;
+ret = AVERROR(EAGAIN);
goto leave;
}
/* skip empty data packets */
if (!size) {
-ret = FFERROR_REDO;
+ret = AVERROR(EAGAIN);
goto leave;
}
@@ -1160,7 +1160,7 @@ skip:
(st->discard >= AVDISCARD_BIDIR && ((flags & FLV_VIDEO_FRAMETYPE_MASK)
== FLV_FRAME_DISP_INTER && stream_type == FLV_STREAM_TYPE_VIDEO)) ||
st->discard >= AVDISCARD_ALL) {
avio_seek(s->pb, next, SEEK_SET);
-ret = FFERROR_REDO;
+ret = AVERROR(EAGAIN);
goto leave;
}
@@ -1273,7 +1273,7 @@ retry_duration:
if (st->codecpar->extradata) {
if ((ret = flv_queue_extradata(flv, s->pb, stream_type, size))
< 0)
return ret;
-ret = FFERROR_REDO;
+ret = AVERROR(EAGAIN);
goto leave;
}
if ((ret = flv_get_extradata(s, st, size)) < 0)
@@ -1284,14 +1284,14 @@ retry_duration:
if (st->codecpar->codec_id == AV_CODEC_ID_AAC && t &&
!strcmp(t->value, "Omnia A/XE"))
st->codecpar->extradata_size = 2;
-ret = FFERROR_REDO;
+ret = AVERROR(EAGAIN);
goto leave;
}
}
/* skip empty data packets */
if (!size) {
-ret = FFERROR_REDO;
+ret = AVERROR(EAGAIN);
goto leave;
}
diff --git a/libavformat/lxfdec.c b/libavformat/lxfdec.c
index 8003ae98b7..bd28dfe270 100644
--- a/libavformat/lxfdec.c
+++ b/libavformat/lxfdec.c
@@ -307,7 +307,7 @@ static int lxf_read_packet(AVFormatContext *s, AVPacket
*pkt)
if (stream > 1) {
av_log(s, AV_LOG_WARNING,
"got packet with illegal stream index %"PRIu32"\n", stream);
-return FFERROR_REDO;
+return AVERROR(EAGAIN);
}
if (stream == 1 && s->nb_streams < 2) {
diff --git a/libavformat/mlvdec.c b/libavformat/mlvdec.c
index db3b77bb9b..d510787fcd 100644
--- a/libavformat/mlvdec.c
+++ b/libavformat/mlvdec.c
@@ -422,7 +422,7 @@ static int read_packet(AVFormatContext *avctx, AVPacket
*pkt)
pb = mlv->pb[sti->index_entries[index].size];
if (!pb) {
-ret = FFERROR_REDO;
+ret = AVERROR(EAGAIN);
goto next_packet;
}
avio_seek(pb, sti->index_entries[index].pos, SEEK_SET);
diff --git a/libavformat/mpeg.c b/libavformat/mpeg
[FFmpeg-devel] [PATCH 2/5] lavf/demux: treat EAGAIN as REDO unless AVFMT_FLAG_NONBLOCK is set
Lavf only supports a very limited approximation of non-blocking behavior, so we should not return random EAGAINs to callers unless they specifically requested it. --- libavformat/demux.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/libavformat/demux.c b/libavformat/demux.c index 2dfd82a63c..5cd9522367 100644 --- a/libavformat/demux.c +++ b/libavformat/demux.c @@ -574,8 +574,12 @@ FF_ENABLE_DEPRECATION_WARNINGS /* Some demuxers return FFERROR_REDO when they consume data and discard it (ignored streams, junk, extradata). - We must re-call the demuxer to get the real packet. */ -if (err == FFERROR_REDO) + We must re-call the demuxer to get the real packet. + + Treat EAGAIN the same as FFERROR_REDO, unless the user + requested non-blocking behavior. */ +if (err == FFERROR_REDO || +(err == AVERROR(EAGAIN) && !(s->flags & AVFMT_FLAG_NONBLOCK))) continue; if (!pktl || err == AVERROR(EAGAIN)) return err; -- 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] libx265: support ATSC A/53 captions
On 08.11.2022 07:49, Eran Kornblau wrote: Trying again… From: Eran Kornblau Sent: Monday, 17 October 2022 19:29 To: FFmpeg development discussions and patches mailto:ffmpeg-devel@ffmpeg.org>> Subject: [PATCH] libx265: support ATSC A/53 captions Hi, The attached patch adds rendering of ATSC A/53 captions as HEVC SEI messages. The option name/implementation is aligned with the corresponding libx264 feature. What frees the sei data on success? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v4 1/2] lavc: add HWACCEL_CAP_RESET_WITHOUT_UNINIT capacity for hwaccel
The capacity can avoid hwaccel being uninited when do the reset. It
provides the method for hwaccel if it still want to use the previous
initialized configuration after reset. And the configuration can be
updated in AVHWAccel.init() if needed.
For example, when use vaapi vp9 decode dynamic resolution clips, need
to avoid changing vaContext in avctx->internal->hwaccel_priv_data if
current frame resolution change and it reference a pervious frame with
different resolution. Otherwise reference frame's information bound
in vaContext will be lost, then corrupt current frame.
Signed-off-by: Fei Wang
---
libavcodec/decode.c | 10 ++
libavcodec/hwconfig.h | 7 +++
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 6be2d3d6ed..cfada048e8 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1109,7 +1109,7 @@ static int hwaccel_init(AVCodecContext *avctx,
return AVERROR_PATCHWELCOME;
}
-if (hwaccel->priv_data_size) {
+if (hwaccel->priv_data_size && !avctx->internal->hwaccel_priv_data) {
avctx->internal->hwaccel_priv_data =
av_mallocz(hwaccel->priv_data_size);
if (!avctx->internal->hwaccel_priv_data)
@@ -1134,10 +1134,12 @@ static int hwaccel_init(AVCodecContext *avctx,
static void hwaccel_uninit(AVCodecContext *avctx)
{
-if (avctx->hwaccel && avctx->hwaccel->uninit)
-avctx->hwaccel->uninit(avctx);
+if (avctx->hwaccel && !(avctx->hwaccel->caps_internal &
HWACCEL_CAP_RESET_WITHOUT_UNINIT)) {
+if (avctx->hwaccel->uninit)
+avctx->hwaccel->uninit(avctx);
-av_freep(&avctx->internal->hwaccel_priv_data);
+av_freep(&avctx->internal->hwaccel_priv_data);
+}
avctx->hwaccel = NULL;
diff --git a/libavcodec/hwconfig.h b/libavcodec/hwconfig.h
index 721424912c..5fb4e06d5f 100644
--- a/libavcodec/hwconfig.h
+++ b/libavcodec/hwconfig.h
@@ -25,6 +25,13 @@
#define HWACCEL_CAP_ASYNC_SAFE (1 << 0)
+/**
+ * The hwaccel supports reset without calling back AVHWAccel.uninit()
+ * and realloc avctx->internal->hwaccel_priv_data.
+ *
+ * New configuration can set up through AVHWAccel.init().
+ */
+#define HWACCEL_CAP_RESET_WITHOUT_UNINIT (1 << 1)
typedef struct AVCodecHWConfigInternal {
/**
--
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".
[FFmpeg-devel] [PATCH v4 2/2] lavc/vaapi_decode: add support for HWACCEL_CAP_RESET_WITHOUT_UNINIT
This can fix vp9 decode image corruption when the frame size is change,
but the pervious frames still be referenced.
Surfaces don't need to be bound to vaContext only after VAAPI 1.0.0:
https://github.com/intel/libva/commit/492b692005ccd0d8da190209d5b3ae7b7825f4b8
Signed-off-by: Fei Wang
---
libavcodec/vaapi_decode.c | 41 ++-
libavcodec/vaapi_vp9.c| 4
2 files changed, 27 insertions(+), 18 deletions(-)
diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
index 134f10eca5..618f3c3e0a 100644
--- a/libavcodec/vaapi_decode.c
+++ b/libavcodec/vaapi_decode.c
@@ -658,8 +658,10 @@ int ff_vaapi_decode_init(AVCodecContext *avctx)
VAStatus vas;
int err;
-ctx->va_config = VA_INVALID_ID;
-ctx->va_context = VA_INVALID_ID;
+if (!ctx->va_config && !ctx->va_context) {
+ctx->va_config = VA_INVALID_ID;
+ctx->va_context = VA_INVALID_ID;
+}
err = ff_decode_get_hw_frames_ctx(avctx, AV_HWDEVICE_TYPE_VAAPI);
if (err < 0)
@@ -670,24 +672,27 @@ int ff_vaapi_decode_init(AVCodecContext *avctx)
ctx->device = ctx->frames->device_ctx;
ctx->hwctx = ctx->device->hwctx;
-err = vaapi_decode_make_config(avctx, ctx->frames->device_ref,
- &ctx->va_config, NULL);
-if (err)
-goto fail;
-
-vas = vaCreateContext(ctx->hwctx->display, ctx->va_config,
- avctx->coded_width, avctx->coded_height,
- VA_PROGRESSIVE,
- ctx->hwfc->surface_ids,
- ctx->hwfc->nb_surfaces,
- &ctx->va_context);
-if (vas != VA_STATUS_SUCCESS) {
-av_log(avctx, AV_LOG_ERROR, "Failed to create decode "
- "context: %d (%s).\n", vas, vaErrorStr(vas));
-err = AVERROR(EIO);
-goto fail;
+if (ctx->va_config == VA_INVALID_ID) {
+err = vaapi_decode_make_config(avctx, ctx->frames->device_ref,
+ &ctx->va_config, NULL);
+if (err)
+goto fail;
}
+if (ctx->va_context == VA_INVALID_ID) {
+vas = vaCreateContext(ctx->hwctx->display, ctx->va_config,
+ avctx->coded_width, avctx->coded_height,
+ VA_PROGRESSIVE,
+ ctx->hwfc->surface_ids,
+ ctx->hwfc->nb_surfaces,
+ &ctx->va_context);
+if (vas != VA_STATUS_SUCCESS) {
+av_log(avctx, AV_LOG_ERROR, "Failed to create decode "
+ "context: %d (%s).\n", vas, vaErrorStr(vas));
+err = AVERROR(EIO);
+goto fail;
+}
+}
av_log(avctx, AV_LOG_DEBUG, "Decode context initialised: "
"%#x/%#x.\n", ctx->va_config, ctx->va_context);
diff --git a/libavcodec/vaapi_vp9.c b/libavcodec/vaapi_vp9.c
index 776382f683..245b7a1b3a 100644
--- a/libavcodec/vaapi_vp9.c
+++ b/libavcodec/vaapi_vp9.c
@@ -181,5 +181,9 @@ const AVHWAccel ff_vp9_vaapi_hwaccel = {
.uninit = ff_vaapi_decode_uninit,
.frame_params = ff_vaapi_common_frame_params,
.priv_data_size = sizeof(VAAPIDecodeContext),
+#if VA_CHECK_VERSION(1, 0, 0)
+.caps_internal= HWACCEL_CAP_ASYNC_SAFE |
HWACCEL_CAP_RESET_WITHOUT_UNINIT,
+#else
.caps_internal= HWACCEL_CAP_ASYNC_SAFE,
+#endif
};
--
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 v3 2/3] lavc/decode: Add internal surface re-allocate method for hwaccel
On Mon, 2022-09-19 at 14:08 +0800, Fei Wang wrote: > On Wed, 2022-09-07 at 22:56 +0100, Mark Thompson wrote: > > On 23/08/2022 09:19, Fei Wang wrote: > > > From: Linjie Fu > > > > > > Add HWACCEL_CAP_INTERNAL_ALLOC flag to indicate hwaccels are able > > > to > > > re-allocate surface internally through > > > ff_decode_get_hw_frames_ctx. > > > So that hwaccels don't need to reinitialize all hw related > > > configs > > > when decode resolution change, just need to re-allocate new > > > surface > > > by using new resolution. > > > > > > Signed-off-by: Linjie Fu > > > Signed-off-by: Fei Wang > > > --- > > > libavcodec/decode.c | 36 > > > libavcodec/hwconfig.h | 1 + > > > 2 files changed, 37 insertions(+) > > > > You can't just not call the user get_format callback and allocate > > your own surfaces - this breaks direct rendering and other cases > > where the user wanted to manage the surfaces. > > > > This is also missing any check that the hardware decoder supports > > the > > stream post-transition - if the decoder does not support the new > > size > > (or any other property of the new stream) then this will try to > > blindly decode it anyway and fail, where previously it would have > > correctly fallen back to software decoding. > > > > > > None of these patches say what the aim is, but from reading them > > and > > seeing that VP9 is the intended target then I am guessing that this > > is intended to support the case where the stream resizes while > > still > > using previous reference frames - is that right? > > Yes, this fixed some vp9 resize streams which reference frames has > different resolution. > > > If my guess is correct, I think you should (a) mention that fact in > > the patches, and (b) target the support at specifically that case, > > and not try to mess with any other reinit cases. > > > > Something like: if you know you are in that case (the decoder > > itself > > has this information and could pass it to ff_get_format somehow) > > and > > the context supports it (I am still unclear how this support can be > > determined - the libva documentation is very clear that a context > > is > > tied to a particular height/width), then remember the context > > across > > the user get_format call and if things match up then re-use it. > > Thanks, the logic looks good. I will check it later to see if any > blocks on the detail implementation. Current decode logis is hwaccel->uninit, get_format, hwaccel->init. While the avctx->internal->hwaccel_priv_data is freed in uninit and re-alloc in init, so it can't store and re-use vaContext in get_format. I have modified the other version of V4, which can keep current decode logic as much as possible and still put alloc surfaces in hwaccel.init() after call back get_foramt. Thanks Fei > > Thanks > Fei > > If for some reason you are in that case but it can't work (e.g. > > because the new size isn't supported by the hardware), then you > > need > > a better error message - the stream is actually broken because most > > frames are not decodable until you reach another recovery point > > (since the reference frames are in hardware surfaces so the > > software > > decoder can't use them). > > > > - Mark > > ___ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > To unsubscribe, visit link above, or email > > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ 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 14/20] fftools/ffmpeg_mux_init: drop a duplicated block in copy_metadata()
Quoting Michael Niedermayer (2022-10-18 23:51:22)
> On Tue, Oct 18, 2022 at 02:36:55PM +0200, Anton Khirnov wrote:
> > It does the same thing as the block right below it.
> > ---
> > fftools/ffmpeg_mux_init.c | 10 --
> > 1 file changed, 10 deletions(-)
>
> This seems to make a difference for
> ffmpeg -i meta.flac -map_metadata:s -1 -vcodec mpeg4 -t 0.1 -y /tmp/tmp3x.mkv
>
> The metadata in meta.flac is a bit odd though
>
> Input #0, flac, from '/home/michael/videos/meta.flac':
> Metadata:
> al : Hyper fast Audio and Video encoder
> : usage: ffmpeg [options] [[infile options] -i infile]...
> {[outfile options] outfile}...
> :
> : Main options:
>
> : -param1 E.V.. scaler param 1
> x : öäü?ß^x²€
Is this before or after?
If I'm reading the code correctly, no metadata should be copied after my
patch, which IMO is more consistent with the docs.
--
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 3/5] lavf: replace FFERROR_REDO with AVERROR(EAGAIN)
Anton Khirnov (12022-11-08): > There is no meaningful distinction between them, both mean "the demuxer > did some work, but did not produce a packet - should be called again". NAK, there a difference in semantics: AVEROR(EAGAIN) is for when data is not available for external reasons, typically network blocking, AVERROR_REDO is for when data is available and the demuxer will read it as soon as it is restarted, just to avoid having a loop in the demuxer. -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/2] avfilter/vf_libplacebo: support all supported pixfmts
From: Niklas Haas
This is done only to the inputs, not the outputs, because we always
output vulkan hwframes.
Doing so also requires keeping track of backing textures for non-hwdec
formats, but is otherwise a mostly straightforward change to the format
query function. Special care needs to be taken to avoid crashing on
older libplacebo due to AV_PIX_FMT_RGBF32LE et al.
---
libavfilter/vf_libplacebo.c | 41 -
1 file changed, 36 insertions(+), 5 deletions(-)
diff --git a/libavfilter/vf_libplacebo.c b/libavfilter/vf_libplacebo.c
index cb6b021816..fa9a7675d1 100644
--- a/libavfilter/vf_libplacebo.c
+++ b/libavfilter/vf_libplacebo.c
@@ -62,6 +62,7 @@ typedef struct LibplaceboContext {
pl_vulkan vulkan;
pl_gpu gpu;
pl_renderer renderer;
+pl_tex tex[4];
/* settings */
char *out_format_string;
@@ -302,6 +303,8 @@ static void libplacebo_uninit(AVFilterContext *avctx)
{
LibplaceboContext *s = avctx->priv;
+for (int i = 0; i < FF_ARRAY_ELEMS(s->tex); i++)
+pl_tex_destroy(s->gpu, &s->tex[i]);
for (int i = 0; i < s->num_hooks; i++)
pl_mpv_user_shader_destroy(&s->hooks[i]);
pl_renderer_destroy(&s->renderer);
@@ -321,6 +324,7 @@ static int process_frames(AVFilterContext *avctx, AVFrame
*out, AVFrame *in)
struct pl_frame image, target;
ok = pl_map_avframe_ex(s->gpu, &image, pl_avframe_params(
.frame= in,
+.tex = s->tex,
.map_dovi = s->apply_dovi,
));
@@ -510,22 +514,49 @@ fail:
static int libplacebo_query_format(AVFilterContext *ctx)
{
int err = 0;
-static const enum AVPixelFormat pix_fmts[] = {
+LibplaceboContext *s = ctx->priv;
+const AVPixFmtDescriptor *desc = NULL;
+AVFilterFormats *in_fmts = NULL;
+static const enum AVPixelFormat out_fmts[] = {
AV_PIX_FMT_VULKAN, AV_PIX_FMT_NONE,
};
RET(init_vulkan(ctx));
-RET(ff_formats_ref(ff_make_format_list(pix_fmts),
- &ctx->inputs[0]->outcfg.formats));
-RET(ff_formats_ref(ff_make_format_list(pix_fmts),
+while ((desc = av_pix_fmt_desc_next(desc))) {
+
+#if PL_API_VER < 232
+// Older libplacebo can't handle >64-bit pixel formats, so safe-guard
+// this to prevent triggering an assertion
+if (av_get_bits_per_pixel(desc) > 64)
+continue;
+#endif
+
+enum AVPixelFormat pixfmt = av_pix_fmt_desc_get_id(desc);
+if (pl_test_pixfmt(s->gpu, pixfmt)) {
+if ((err = ff_add_format(&in_fmts, pixfmt)) < 0)
+return err;
+}
+}
+
+RET(ff_formats_ref(in_fmts, &ctx->inputs[0]->outcfg.formats));
+RET(ff_formats_ref(ff_make_format_list(out_fmts),
&ctx->outputs[0]->incfg.formats));
+
return 0;
fail:
return err;
}
+static int libplacebo_config_input(AVFilterLink *inlink)
+{
+if (inlink->format == AV_PIX_FMT_VULKAN)
+return ff_vk_filter_config_input(inlink);
+
+return 0;
+}
+
static int libplacebo_config_output(AVFilterLink *outlink)
{
int err;
@@ -755,7 +786,7 @@ static const AVFilterPad libplacebo_inputs[] = {
.name = "default",
.type = AVMEDIA_TYPE_VIDEO,
.filter_frame = &filter_frame,
-.config_props = &ff_vk_filter_config_input,
+.config_props = &libplacebo_config_input,
},
};
--
2.38.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/2] avfilter/vf_libplacebo: init vulkan device in query_format
From: Niklas Haas
Instead of doing it ad-hoc in `filter_frame`. This is not a huge change
on its own, but paves the way for adding support for more formats in the
future, in particular formats other than AV_PIX_FMT_VULKAN.
---
libavfilter/vf_libplacebo.c | 35 ---
1 file changed, 28 insertions(+), 7 deletions(-)
diff --git a/libavfilter/vf_libplacebo.c b/libavfilter/vf_libplacebo.c
index cfee1117e8..cb6b021816 100644
--- a/libavfilter/vf_libplacebo.c
+++ b/libavfilter/vf_libplacebo.c
@@ -56,7 +56,6 @@ static const struct pl_tone_map_function * const
tonemapping_funcs[TONE_MAP_COUN
typedef struct LibplaceboContext {
/* lavfi vulkan*/
FFVulkanContext vkctx;
-int initialized;
/* libplacebo */
pl_log log;
@@ -237,10 +236,17 @@ static int init_vulkan(AVFilterContext *avctx)
{
int err = 0;
LibplaceboContext *s = avctx->priv;
-const AVVulkanDeviceContext *hwctx = s->vkctx.hwctx;
+const AVVulkanDeviceContext *hwctx;
uint8_t *buf = NULL;
size_t buf_len;
+if (!avctx->hw_device_ctx) {
+av_log(s, AV_LOG_ERROR, "Missing vulkan hwdevice for
vf_libplacebo.\n");
+return AVERROR(EINVAL);
+}
+
+hwctx = ((AVHWDeviceContext*) avctx->hw_device_ctx->data)->hwctx;
+
/* Import libavfilter vulkan context into libplacebo */
s->vulkan = pl_vulkan_import(s->log, pl_vulkan_import_params(
.instance = hwctx->inst,
@@ -289,7 +295,6 @@ static int init_vulkan(AVFilterContext *avctx)
fail:
if (buf)
av_file_unmap(buf, buf_len);
-s->initialized = 1;
return err;
}
@@ -303,7 +308,6 @@ static void libplacebo_uninit(AVFilterContext *avctx)
pl_vulkan_destroy(&s->vulkan);
pl_log_destroy(&s->log);
ff_vk_uninit(&s->vkctx);
-s->initialized = 0;
s->gpu = NULL;
}
@@ -452,8 +456,6 @@ static int filter_frame(AVFilterLink *link, AVFrame *in)
}
pl_log_level_update(s->log, get_log_level());
-if (!s->initialized)
-RET(init_vulkan(ctx));
RET(av_frame_copy_props(out, in));
out->width = outlink->w;
@@ -505,6 +507,25 @@ fail:
return err;
}
+static int libplacebo_query_format(AVFilterContext *ctx)
+{
+int err = 0;
+static const enum AVPixelFormat pix_fmts[] = {
+AV_PIX_FMT_VULKAN, AV_PIX_FMT_NONE,
+};
+
+RET(init_vulkan(ctx));
+
+RET(ff_formats_ref(ff_make_format_list(pix_fmts),
+ &ctx->inputs[0]->outcfg.formats));
+RET(ff_formats_ref(ff_make_format_list(pix_fmts),
+ &ctx->outputs[0]->incfg.formats));
+return 0;
+
+fail:
+return err;
+}
+
static int libplacebo_config_output(AVFilterLink *outlink)
{
int err;
@@ -755,7 +776,7 @@ const AVFilter ff_vf_libplacebo = {
.process_command = &ff_filter_process_command,
FILTER_INPUTS(libplacebo_inputs),
FILTER_OUTPUTS(libplacebo_outputs),
-FILTER_SINGLE_PIXFMT(AV_PIX_FMT_VULKAN),
+FILTER_QUERY_FUNC(libplacebo_query_format),
.priv_class = &libplacebo_class,
.flags_internal = FF_FILTER_FLAG_HWFRAME_AWARE,
};
--
2.38.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] Makefile: Build complete doc with Doxygen
On 24 Sep 2022, at 23:09, Marvin Scholz wrote: > Add DISABLEDINSTHEADERS, a variable containing the headers of disabled > libraries. This is needed so that Doxygen does not generate incomplete > documentation when a component is disabled, which is quite unexpected > behaviour and results in warnings due to, among other things, broken > references. > --- > Makefile | 10 ++ > doc/Makefile | 2 +- > 2 files changed, 11 insertions(+), 1 deletion(-) > > diff --git a/Makefile b/Makefile > index 61f79e27ae..26714950b7 100644 > --- a/Makefile > +++ b/Makefile > @@ -110,7 +110,17 @@ include $(SRC_PATH)/$(1)/Makefile > include $(SRC_PATH)/ffbuild/library.mak > endef > > +define DODISABLEDSUBDIR > +$(foreach V,$(SUBDIR_VARS),$(eval $(call RESET,$(V > +SUBDIR := $(1)/ > +include $(SRC_PATH)/$(1)/Makefile > +DISABLEDINSTHEADERS := $$(DISABLEDINSTHEADERS) $$(HEADERS:%=$$(SUBDIR)%) > +endef > + > +DISABLEDFFLIBS := $(filter-out $(FFLIBS),$(ALLFFLIBS)) > + > $(foreach D,$(FFLIBS),$(eval $(call DOSUBDIR,lib$(D > +$(foreach D,$(DISABLEDFFLIBS),$(eval $(call DODISABLEDSUBDIR,lib$(D > > include $(SRC_PATH)/fftools/Makefile > include $(SRC_PATH)/doc/Makefile > diff --git a/doc/Makefile b/doc/Makefile > index 25774c7bad..d71a02e408 100644 > --- a/doc/Makefile > +++ b/doc/Makefile > @@ -100,7 +100,7 @@ doc/%.3: doc/%.pod $(GENTEXI) > > $(DOCS) doc/doxy/html: | doc/ > > -DOXY_INPUT = $(INSTHEADERS) > +DOXY_INPUT = $(INSTHEADERS) $(DISABLEDINSTHEADERS) > DOXY_INPUT_DEPS = $(addprefix $(SRC_PATH)/, $(DOXY_INPUT)) ffbuild/config.mak > > doc/doxy/html: TAG = DOXY > -- > 2.37.0 (Apple Git-136) Another ping for review, please. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/5] lavf: replace FFERROR_REDO with AVERROR(EAGAIN)
Quoting Nicolas George (2022-11-08 13:54:53) > Anton Khirnov (12022-11-08): > > There is no meaningful distinction between them, both mean "the demuxer > > did some work, but did not produce a packet - should be called again". > > NAK, there a difference in semantics: AVEROR(EAGAIN) is for when data is > not available for external reasons, typically network blocking, This is false - there are zero demuxers returning EAGAIN due to network blocking. Furthermore, lavf architecture fundamentally does not allow generic non-blocking operations, so the most any demuxer can do is return at a few specific points. And since demuxers are supposed to be independent of the underlying IO protocol, they fundamentally cannot know anything about network state. So there really is no meaningful difference between REDO and EAGAIN. Both are just an opportunity for the caller to do something else before trying again. If we believe giving the caller this option is valuable, then it's valuable in both these cases and it makes no sense to distinguish between them. -- 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 3/5] lavf: replace FFERROR_REDO with AVERROR(EAGAIN)
Anton Khirnov (12022-11-08): > This is false - there are zero demuxers returning EAGAIN due to network > blocking. There are devices who return EAGAIN due to device blocking. > So there really is no meaningful difference between REDO and EAGAIN. There is a difference: REDO is internal, EAGAIN is public. -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libx265: support ATSC A/53 captions
> > -Original Message- > From: ffmpeg-devel On Behalf Of Timo > Rothenpieler > Sent: Tuesday, 8 November 2022 13:33 > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH] libx265: support ATSC A/53 captions > > > > > The attached patch adds rendering of ATSC A/53 captions as HEVC SEI > > messages. > > The option name/implementation is aligned with the corresponding libx264 > > feature. > > What frees the sei data on success? > Thanks Timo, good point! I missed the fact that libx264 gets a callback for freeing the SEI payloads (sei_free). It seems libx265 does not have this option, so I added some 'for' loop to free the payloads after the call to encoder_encode. In addition: 1. I added av_memdup on the 'user-data-unregistered' side data so that it won't be freed twice. 2. I added a 'free_picture' function for freeing the x265_picture in case of error. (both changes are aligned with the implementation in libx264.c) Updated patch attached. While checking the point you raised, I ran some libx265 transcode with valgrind, and it reported errors unrelated to this patch. Attaching the full output, in case anyone wants to have a look. Thanks! Eran 0001-libx265-support-ATSC-A-53-captions.patch Description: 0001-libx265-support-ATSC-A-53-captions.patch $ valgrind -v --tool=memcheck --leak-check=yes --num-callers=128 ffmpeg -i /opt/kaltura/live/s32-merged.mp4 -t 0.5 -c:v libx265 -force_key_frames 'expr:gte(t,n_forced*2)' -x265-params min-keyint=1:keyint=60:vbv-maxrate=8400:vbv-bufsize=24000:pools=4:aq-mode=3:bframes=4:ref=2:limit-refs=3:rc-lookahead=15:subme=2:open-gop=0 -crf 26 -preset fast -c:a aac -b:a 128k -y /tmp/jap-h265.ts ==12400== Memcheck, a memory error detector ==12400== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==12400== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info ==12400== Command: ffmpeg -i /opt/kaltura/live/s32-merged.mp4 -t 0.5 -c:v libx265 -force_key_frames expr:gte(t,n_forced*2) -x265-params min-keyint=1:keyint=60:vbv-maxrate=8400:vbv-bufsize=24000:pools=4:aq-mode=3:bframes=4:ref=2:limit-refs=3:rc-lookahead=15:subme=2:open-gop=0 -crf 26 -preset fast -c:a aac -b:a 128k -y /tmp/jap-h265.ts ==12400== --12400-- Valgrind options: --12400---v --12400----tool=memcheck --12400----leak-check=yes --12400----num-callers=128 --12400-- Contents of /proc/version: --12400-- Linux version 3.13.0-49-generic (buildd@akateko) (gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) ) #83-Ubuntu SMP Fri Apr 10 20:11:33 UTC 2015 --12400-- Arch and hwcaps: AMD64, LittleEndian, amd64-cx16-lzcnt-rdtscp-sse3-avx-avx2-bmi --12400-- Page sizes: currently 4096, max supported 4096 --12400-- Valgrind library directory: /usr/lib/valgrind --12400-- Reading syms from /usr/local/bin/ffmpeg --12400-- Reading syms from /lib/x86_64-linux-gnu/ld-2.19.so --12400-- Considering /lib/x86_64-linux-gnu/ld-2.19.so .. --12400-- .. CRC mismatch (computed aedc220e wanted 13895c11) --12400-- Considering /usr/lib/debug/lib/x86_64-linux-gnu/ld-2.19.so .. --12400-- .. CRC is valid --12400-- Reading syms from /usr/lib/valgrind/memcheck-amd64-linux --12400-- Considering /usr/lib/valgrind/memcheck-amd64-linux .. --12400-- .. CRC mismatch (computed fed8e6c5 wanted e6be554a) --12400--object doesn't have a symbol table --12400--object doesn't have a dynamic symbol table --12400-- Scheduler: using generic scheduler lock implementation. --12400-- Reading suppressions file: /usr/lib/valgrind/default.supp ==12400== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-12400-by-root-on-??? ==12400== embedded gdbserver: writing to /tmp/vgdb-pipe-to-vgdb-from-12400-by-root-on-??? ==12400== embedded gdbserver: shared mem /tmp/vgdb-pipe-shared-mem-vgdb-12400-by-root-on-??? ==12400== ==12400== TO CONTROL THIS PROCESS USING vgdb (which you probably ==12400== don't want to do, unless you know exactly what you're doing, ==12400== or are doing some strange experiment): ==12400== /usr/lib/valgrind/../../bin/vgdb --pid=12400 ...command... ==12400== ==12400== TO DEBUG THIS PROCESS USING GDB: start GDB like this ==12400== /path/to/gdb ffmpeg ==12400== and then give GDB the following command ==12400== target remote | /usr/lib/valgrind/../../bin/vgdb --pid=12400 ==12400== --pid is optional if only one valgrind process is running ==12400== --12400-- REDIR: 0x4019d70 (ld-linux-x86-64.so.2:strlen) redirected to 0x380764b1 (???) --12400-- Reading syms from /usr/lib/valgrind/vgpreload_core-amd64-linux.so --12400-- Considering /usr/lib/valgrind/vgpreload_core-amd64-linux.so .. --12400-- .. CRC mismatch (computed 4bcdfe99 wanted 3143e841) --12400--object doesn't have a symbol table --12400-- Reading syms from /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so --12400-- Considering /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so .. --12400-- .. CRC mismatch (computed 3df18bf1 wanted 14fefe1c) --12400--object doesn't have
Re: [FFmpeg-devel] [PATCH] libx265: support ATSC A/53 captions
On 08.11.2022 15:25, Eran Kornblau wrote: -Original Message- From: ffmpeg-devel On Behalf Of Timo Rothenpieler Sent: Tuesday, 8 November 2022 13:33 To: ffmpeg-devel@ffmpeg.org Subject: Re: [FFmpeg-devel] [PATCH] libx265: support ATSC A/53 captions The attached patch adds rendering of ATSC A/53 captions as HEVC SEI messages. The option name/implementation is aligned with the corresponding libx264 feature. What frees the sei data on success? Thanks Timo, good point! I missed the fact that libx264 gets a callback for freeing the SEI payloads (sei_free). It seems libx265 does not have this option, so I added some 'for' loop to free the payloads after the call to encoder_encode. In addition: 1. I added av_memdup on the 'user-data-unregistered' side data so that it won't be freed twice. 2. I added a 'free_picture' function for freeing the x265_picture in case of error. (both changes are aligned with the implementation in libx264.c) Updated patch attached. One nit: splitting the first line of free_picture() in two isn't really neccesary and makes the function a bit uglier. One small problem: libx265 now needs to select atsc_a53 in configure, analog to how libx264 and all the others do. Otherwise the file containing the a53 code might not get compiled. LGTM otherwise While checking the point you raised, I ran some libx265 transcode with valgrind, and it reported errors unrelated to this patch. Attaching the full output, in case anyone wants to have a look. x265 has a bunch of issues related to SEI data. See for example https://trac.ffmpeg.org/ticket/9666#comment:1 i.e. if the number of per-frame sei data ever increases past its initial count, it'll just straight up explode. ___ 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] libx265: support ATSC A/53 captions
> > On 08.11.2022 15:25, Eran Kornblau wrote: > >> > >> -Original Message- > >> From: ffmpeg-devel On Behalf Of > >> Timo Rothenpieler > >> Sent: Tuesday, 8 November 2022 13:33 > >> To: ffmpeg-devel@ffmpeg.org > >> Subject: Re: [FFmpeg-devel] [PATCH] libx265: support ATSC A/53 > >> captions > >> > >>> > >>> The attached patch adds rendering of ATSC A/53 captions as HEVC SEI > >>> messages. > >>> The option name/implementation is aligned with the corresponding libx264 > >>> feature. > >> > >> What frees the sei data on success? > >> > > Thanks Timo, good point! > > > > I missed the fact that libx264 gets a callback for freeing the SEI payloads > > (sei_free). > > It seems libx265 does not have this option, so I added some 'for' loop to > > free the payloads after the call to encoder_encode. > > > > In addition: > > 1. I added av_memdup on the 'user-data-unregistered' side data so that it > > won't be freed twice. > > 2. I added a 'free_picture' function for freeing the x265_picture in case > > of error. > > (both changes are aligned with the implementation in libx264.c) > > > > Updated patch attached. > > One nit: splitting the first line of free_picture() in two isn't really > neccesary and makes the function a bit uglier. > Fixed > One small problem: libx265 now needs to select atsc_a53 in configure, analog > to how libx264 and all the others do. > Otherwise the file containing the a53 code might not get compiled. > Fixed > LGTM otherwise > Thanks! Eran > > While checking the point you raised, I ran some libx265 transcode with > > valgrind, and it reported errors unrelated to this patch. > > Attaching the full output, in case anyone wants to have a look. > > x265 has a bunch of issues related to SEI data. > See for example > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ffmpeg.org%2Fticket%2F9666%23comment%3A1&data=05%7C01%7C%7C5cd31da5382f4946e0c508dac198454d%7C0c503748de3f4e2597e26819d53a42b6%7C1%7C0%7C638035156992542567%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=9AdmTE%2B4dzHED8KLN0ps2GvvynacXfrWjhVJk4SBWJo%3D&reserved=0 > > i.e. if the number of per-frame sei data ever increases past its initial > count, it'll just straight up explode. > ___ 0001-libx265-support-ATSC-A-53-captions.patch Description: 0001-libx265-support-ATSC-A-53-captions.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 1/7] postproc/postprocess: Remove obsolete MMX(EXT)/3Dnow functions
Andreas Rheinhardt: > postprocess.c currently has C, MMX, MMXEXT, 3DNow as well as > SSE2 versions of its internal functions. But given that only > ancient 32-bit x86 CPUs don't support SSE2, the MMX, MMXEXT > and 3DNow versions are obsolete and are therefore removed by > this commit. This saves about 56KB here. > > (The SSE2 version in particular is not really complete, > so that it often falls back to MMXEXT (which means that > there were some identical (apart from the name) MMXEXT > and SSE2 functions; this duplication no longer exists > with this commit.) > > Signed-off-by: Andreas Rheinhardt > --- > The PP_CPU_CAPS_MMX(2)/3DNOW could now be deprecated. > > libpostproc/postprocess.c | 69 ++-- > libpostproc/postprocess_template.c | 521 ++--- > 2 files changed, 57 insertions(+), 533 deletions(-) > > diff --git a/libpostproc/postprocess.c b/libpostproc/postprocess.c > index 383c691cb4..0586e458b4 100644 > --- a/libpostproc/postprocess.c > +++ b/libpostproc/postprocess.c > @@ -26,28 +26,27 @@ > */ > > /* > -C MMX MMX23DNow AltiVec > -isVertDCEc Ec Ec > -isVertMinMaxOk Ec Ec Ec > -doVertLowPass E e e Ec > -doVertDefFilter Ec Ec e e Ec > -isHorizDC Ec Ec Ec > -isHorizMinMaxOk a E Ec > -doHorizLowPass E e e Ec > -doHorizDefFilterEc Ec e e Ec > -do_a_deblockEc E Ec E > -deRing E e e* Ecp > -Vertical RKAlgo1E a a > -Horizontal RKAlgo1 a a > -Vertical X1#a E E > -Horizontal X1# a E E > -LinIpolDeinterlace e E E* > -CubicIpolDeinterlacea e e* > -LinBlendDeinterlace e E E* > +C MMX MMX2AltiVec > +isVertDCEc Ec Ec > +isVertMinMaxOk Ec Ec Ec > +doVertLowPass E e Ec > +doVertDefFilter Ec Ec e Ec > +isHorizDC Ec Ec Ec > +isHorizMinMaxOk a E Ec > +doHorizLowPass E e Ec > +doHorizDefFilterEc Ec e Ec > +do_a_deblockEc E Ec > +deRing E e Ecp > +Vertical RKAlgo1E a > +Horizontal RKAlgo1 a > +Vertical X1#a E > +Horizontal X1# a E > +LinIpolDeinterlace e E > +CubicIpolDeinterlacea e > +LinBlendDeinterlace e E > MedianDeinterlace# E Ec Ec > -TempDeNoiser# E e e Ec > +TempDeNoiser# E e Ec > > -* I do not have a 3DNow! CPU -> it is untested, but no one said it does not > work so it seems to work > # more or less selfinvented filters so the exactness is not too meaningful > E = Exact implementation > e = almost exact implementation (slightly different rounding,...) > @@ -83,7 +82,6 @@ try to unroll inner for(x=0 ... loop to avoid these damn > if(x ... checks > #include > #include > //#undef HAVE_MMXEXT_INLINE > -//#define HAVE_AMD3DNOW_INLINE > //#undef HAVE_MMX_INLINE > //#undef ARCH_X86 > //#define DEBUG_BRIGHTNESS > @@ -494,7 +492,7 @@ static av_always_inline void do_a_deblock_C(uint8_t *src, > int step, > } > } > > -//Note: we have C, MMX, MMX2, 3DNOW version there is no 3DNOW+MMX2 one > +//Note: we have C and SSE2 version (which uses MMX(EXT) when advantageous) > //Plain C versions > //we always compile C for testing which needs bitexactness > #define TEMPLATE_PP_C 1 > @@ -508,27 +506,12 @@ static av_always_inline void do_a_deblock_C(uint8_t > *src, int step, > > #if ARCH_X86 && HAVE_INLINE_ASM > #if CONFIG_RUNTIME_CPUDETECT > -#define TEMPLATE_PP_MMX 1 > -#include "postprocess_template.c" > -#define TEMPLATE_PP_MMXEXT 1 > -#include "postprocess_template.c" > -#define TEMPLATE_PP_3DNOW 1 > -#include "postprocess_template.c" > #define TEMPLATE_PP_SSE2 1 > #include "postprocess_template.c" > #else > #if HAVE_SSE2_INLINE > #define TEMPLATE_PP_SSE2 1 > #include "postprocess_template.c" > -#elif HAVE_MMXEXT_INLINE > -#define TEMPLATE_PP_MMXEXT 1 > -#include "postprocess_template.c" > -#elif HAVE_AMD3DNOW_INLINE > -#define TEMPLATE_PP_3DNOW 1 > -#include "postproce
Re: [FFmpeg-devel] [PATCH 1/7] postproc/postprocess: Remove obsolete MMX(EXT)/3Dnow functions
On 11/8/22, Andreas Rheinhardt wrote: > Andreas Rheinhardt: >> postprocess.c currently has C, MMX, MMXEXT, 3DNow as well as >> SSE2 versions of its internal functions. But given that only >> ancient 32-bit x86 CPUs don't support SSE2, the MMX, MMXEXT >> and 3DNow versions are obsolete and are therefore removed by >> this commit. This saves about 56KB here. >> >> (The SSE2 version in particular is not really complete, >> so that it often falls back to MMXEXT (which means that >> there were some identical (apart from the name) MMXEXT >> and SSE2 functions; this duplication no longer exists >> with this commit.) >> >> Signed-off-by: Andreas Rheinhardt >> --- >> The PP_CPU_CAPS_MMX(2)/3DNOW could now be deprecated. >> >> libpostproc/postprocess.c | 69 ++-- >> libpostproc/postprocess_template.c | 521 ++--- >> 2 files changed, 57 insertions(+), 533 deletions(-) >> >> diff --git a/libpostproc/postprocess.c b/libpostproc/postprocess.c >> index 383c691cb4..0586e458b4 100644 >> --- a/libpostproc/postprocess.c >> +++ b/libpostproc/postprocess.c >> @@ -26,28 +26,27 @@ >> */ >> >> /* >> -C MMX MMX23DNow AltiVec >> -isVertDCEc Ec Ec >> -isVertMinMaxOk Ec Ec Ec >> -doVertLowPass E e e Ec >> -doVertDefFilter Ec Ec e e Ec >> -isHorizDC Ec Ec Ec >> -isHorizMinMaxOk a E Ec >> -doHorizLowPass E e e Ec >> -doHorizDefFilterEc Ec e e Ec >> -do_a_deblockEc E Ec E >> -deRing E e e* Ecp >> -Vertical RKAlgo1E a a >> -Horizontal RKAlgo1 a a >> -Vertical X1#a E E >> -Horizontal X1# a E E >> -LinIpolDeinterlace e E E* >> -CubicIpolDeinterlacea e e* >> -LinBlendDeinterlace e E E* >> +C MMX MMX2AltiVec >> +isVertDCEc Ec Ec >> +isVertMinMaxOk Ec Ec Ec >> +doVertLowPass E e Ec >> +doVertDefFilter Ec Ec e Ec >> +isHorizDC Ec Ec Ec >> +isHorizMinMaxOk a E Ec >> +doHorizLowPass E e Ec >> +doHorizDefFilterEc Ec e Ec >> +do_a_deblockEc E Ec >> +deRing E e Ecp >> +Vertical RKAlgo1E a >> +Horizontal RKAlgo1 a >> +Vertical X1#a E >> +Horizontal X1# a E >> +LinIpolDeinterlace e E >> +CubicIpolDeinterlacea e >> +LinBlendDeinterlace e E >> MedianDeinterlace# E Ec Ec >> -TempDeNoiser# E e e Ec >> +TempDeNoiser# E e Ec >> >> -* I do not have a 3DNow! CPU -> it is untested, but no one said it does >> not work so it seems to work >> # more or less selfinvented filters so the exactness is not too >> meaningful >> E = Exact implementation >> e = almost exact implementation (slightly different rounding,...) >> @@ -83,7 +82,6 @@ try to unroll inner for(x=0 ... loop to avoid these damn >> if(x ... checks >> #include >> #include >> //#undef HAVE_MMXEXT_INLINE >> -//#define HAVE_AMD3DNOW_INLINE >> //#undef HAVE_MMX_INLINE >> //#undef ARCH_X86 >> //#define DEBUG_BRIGHTNESS >> @@ -494,7 +492,7 @@ static av_always_inline void do_a_deblock_C(uint8_t >> *src, int step, >> } >> } >> >> -//Note: we have C, MMX, MMX2, 3DNOW version there is no 3DNOW+MMX2 one >> +//Note: we have C and SSE2 version (which uses MMX(EXT) when >> advantageous) >> //Plain C versions >> //we always compile C for testing which needs bitexactness >> #define TEMPLATE_PP_C 1 >> @@ -508,27 +506,12 @@ static av_always_inline void do_a_deblock_C(uint8_t >> *src, int step, >> >> #if ARCH_X86 && HAVE_INLINE_ASM >> #if CONFIG_RUNTIME_CPUDETECT >> -#define TEMPLATE_PP_MMX 1 >> -#include "postprocess_template.c" >> -#define TEMPLATE_PP_MMXEXT 1 >> -#include "postprocess_template.c" >> -#define TEMPLATE_PP_3DNOW 1 >> -#include "postprocess_template.c" >> #define TEMPLATE_PP_SSE2 1 >> #include "postprocess_template.c" >> #else >> #if HAVE_SSE2_INLINE >> #define TEMPLATE_PP_SSE2 1 >> #include "postprocess_template.c" >> -#elif HAVE_MMXEXT_INLINE >> -#define TEMPLATE_PP_MMXEXT 1 >> -#inclu
Re: [FFmpeg-devel] [PATCH 3/5] lavf: replace FFERROR_REDO with AVERROR(EAGAIN)
Quoting Nicolas George (2022-11-08 15:15:39) > Anton Khirnov (12022-11-08): > > This is false - there are zero demuxers returning EAGAIN due to network > > blocking. > > There are devices who return EAGAIN due to device blocking. Sure, and that's about it. And as I said before - there is no way to tell when a device will be ready, so this is of very limited usefulness. > > So there really is no meaningful difference between REDO and EAGAIN. > > There is a difference: REDO is internal, EAGAIN is public. That is not a meaningful difference. A meaningful difference would be one that has actionable consequences. -- 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] avutil/tx: use llrintf() to convert a float into a 64 bit integer
Should fix fate failures on Windowx x86 targets, where long is 32 bits. Signed-off-by: James Almer --- libavutil/tx_priv.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavutil/tx_priv.h b/libavutil/tx_priv.h index 3195cb51b2..fb61119009 100644 --- a/libavutil/tx_priv.h +++ b/libavutil/tx_priv.h @@ -124,7 +124,7 @@ typedef void TXComplex; } while (0) #define UNSCALE(x) ((double)(x)/2147483648.0) -#define RESCALE(x) (av_clip64(lrintf((x) * 2147483648.0), INT32_MIN, INT32_MAX)) +#define RESCALE(x) (av_clip64(llrintf((x) * 2147483648.0), INT32_MIN, INT32_MAX)) #define FOLD(x, y) ((int32_t)((x) + (unsigned)(y) + 32) >> 6) -- 2.38.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avutil/tx: use llrintf() to convert a float into a 64 bit integer
On Tue, 8 Nov 2022, James Almer wrote: Should fix fate failures on Windowx x86 targets, where long is 32 bits. Signed-off-by: James Almer --- libavutil/tx_priv.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavutil/tx_priv.h b/libavutil/tx_priv.h index 3195cb51b2..fb61119009 100644 --- a/libavutil/tx_priv.h +++ b/libavutil/tx_priv.h @@ -124,7 +124,7 @@ typedef void TXComplex; } while (0) #define UNSCALE(x) ((double)(x)/2147483648.0) -#define RESCALE(x) (av_clip64(lrintf((x) * 2147483648.0), INT32_MIN, INT32_MAX)) +#define RESCALE(x) (av_clip64(llrintf((x) * 2147483648.0), INT32_MIN, INT32_MAX)) LGTM, thanks! This does seem to fix the test failures in my configs. // Martin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat: fix use of undeclared identifier error when compiling Chromium
From: gz83 Cross-compiling Chromium on Ubuntu 22.04 will encounter errors related to avformat, because Chromium regularly synchronizes upstream changes, so now submit code directly to upstream --- libavformat/flac_picture.c | 3 ++- libavformat/matroskadec.c | 10 +- libavformat/mov.c | 11 ++- libavformat/oggdec.c | 1 + libavformat/riff.c | 1 + 5 files changed, 15 insertions(+), 11 deletions(-) diff --git a/libavformat/flac_picture.c b/libavformat/flac_picture.c index b33fee75b4..36d190fdc7 100644 --- a/libavformat/flac_picture.c +++ b/libavformat/flac_picture.c @@ -19,9 +19,10 @@ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA */ -#include "libavutil/intreadwrite.h" #include "libavcodec/bytestream.h" +#include "libavcodec/defs.h" #include "libavcodec/png.h" +#include "libavutil/intreadwrite.h" #include "avformat.h" #include "demux.h" #include "flac_picture.h" diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c index d582f566a2..f7bb962941 100644 --- a/libavformat/matroskadec.c +++ b/libavformat/matroskadec.c @@ -34,6 +34,11 @@ #include #include +#include "libavcodec/bytestream.h" +#include "libavcodec/defs.h" +#include "libavcodec/flac.h" +#include "libavcodec/mpeg4audio.h" +#include "libavcodec/packet_internal.h" #include "libavutil/avstring.h" #include "libavutil/base64.h" #include "libavutil/bprint.h" @@ -50,11 +55,6 @@ #include "libavutil/time_internal.h" #include "libavutil/spherical.h" -#include "libavcodec/bytestream.h" -#include "libavcodec/flac.h" -#include "libavcodec/mpeg4audio.h" -#include "libavcodec/packet_internal.h" - #include "avformat.h" #include "avio_internal.h" #include "demux.h" diff --git a/libavformat/mov.c b/libavformat/mov.c index 1f436e21d6..39d2c71edb 100644 --- a/libavformat/mov.c +++ b/libavformat/mov.c @@ -29,6 +29,12 @@ #include #include +#include "libavcodec/ac3tab.h" +#include "libavcodec/defs.h" +#include "libavcodec/flac.h" +#include "libavcodec/hevc.h" +#include "libavcodec/mpegaudiodecheader.h" +#include "libavcodec/mlp_parse.h" #include "libavutil/attributes.h" #include "libavutil/bprint.h" #include "libavutil/channel_layout.h" @@ -49,11 +55,6 @@ #include "libavutil/stereo3d.h" #include "libavutil/timecode.h" #include "libavutil/uuid.h" -#include "libavcodec/ac3tab.h" -#include "libavcodec/flac.h" -#include "libavcodec/hevc.h" -#include "libavcodec/mpegaudiodecheader.h" -#include "libavcodec/mlp_parse.h" #include "avformat.h" #include "internal.h" #include "avio_internal.h" diff --git a/libavformat/oggdec.c b/libavformat/oggdec.c index 3b19e0bd89..c4321a9436 100644 --- a/libavformat/oggdec.c +++ b/libavformat/oggdec.c @@ -29,6 +29,7 @@ */ #include +#include "libavcodec/defs.h" #include "libavutil/avassert.h" #include "libavutil/intreadwrite.h" #include "avio_internal.h" diff --git a/libavformat/riff.c b/libavformat/riff.c index 7319406b39..b1cac3171b 100644 --- a/libavformat/riff.c +++ b/libavformat/riff.c @@ -22,6 +22,7 @@ #include #include "config.h" #include "config_components.h" +#include "libavcodec/codec_id.h" #include "libavutil/macros.h" #include "avformat.h" #include "internal.h" -- 2.38.1.windows.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] Rework color quantization in palette{gen,use}
On Sun, Nov 06, 2022 at 07:46:38PM +, Soft Works wrote:
>
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Clément Bœsch
> > Sent: Saturday, November 5, 2022 4:26 PM
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: [FFmpeg-devel] Rework color quantization in palette{gen,use}
> >
> > Hi,
> >
> > This patchset essentially fixes a few core problems in these filters
> > and
> > switches to a perceptual model.
> >
> > I've generated a report for each key commit on this (temporary) page:
> > http://big.pkh.me/pal/ (warning: heavy page, ~500M; I did try to add
> > some lazy
> > loading of the images but I'm not sure it's actually working as
> > expected).
>
> Comparing the results for the known and simple "rainbow O" example reveals
> that the proposed implementation seems to be even inferior to the current
> code and even farther away from what is possible to achieve:
>
> https://gist.github.com/softworkz/e310e3c84a338f98977d70b09e3e3f4f
The pngquant file on this page has 373 unique colors, and the transparency
is fake (the checkerboard is opaque white & grey). I think there is a
mistake here.
WRT the regression after the patch, I confirm that there is a problem
related to the dithering. If you try with dither=none or even
dither=bayer, you'll observe that the colors are much better. I will
update the results page at some point to include that file.
Now indeed the sierra dithering (and probably the other of the same type)
are somehow spreading way too strongly, it's unclear to me yet but that
might be a bug I introduced. I'll investigate, thanks.
Regards,
--
Clément B.
___
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 12/15] avfilter/palettegen: base split decision on a perceptual model
On Sat, Nov 05, 2022 at 08:07:42PM +0100, Andreas Rheinhardt wrote: [...] > You are adding floating point to places where there was no floating > point before (some other patches of this patchset do the same). Is this > still bitexact across all supported arches? > https://patchwork.ffmpeg.org/project/ffmpeg/patch/20221105152617.1809282-1...@pkh.me/ > makes me believe that the answer is no. Oof I completely forgot about that, you're right. I'm working on a bitexact version right now, we should be ready soon™. It may also address partially the performance issue. Thanks for pointing this out! Regards, -- Clément B. ___ 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] Rework color quantization in palette{gen,use}
On Sun, Nov 06, 2022 at 06:30:22PM +0100, Michael Niedermayer wrote: > On Sun, Nov 06, 2022 at 06:09:41PM +0100, Michael Niedermayer wrote: > > On Sat, Nov 05, 2022 at 04:26:02PM +0100, Clément Bœsch wrote: > > > Hi, > > > > > > This patchset essentially fixes a few core problems in these filters and > > > switches to a perceptual model. > > > > > > I've generated a report for each key commit on this (temporary) page: > > > http://big.pkh.me/pal/ (warning: heavy page, ~500M; I did try to add some > > > lazy > > > loading of the images but I'm not sure it's actually working as expected). > > > > i just looked at file00 and 16 and 64 colors with dither for it and they > > look > > different, some areas look better before and some better afterwards > > looked at more of the 16 color cases with dither > (16 colors as i asumed fewer would magnify any issues ) > file 01, IMHO current looks better than last (variance per axis) > file 02, IMHO current looks better than last (variance per axis) > file 03, IMHO VPA looks better but both really are quite off in terms of > color, > thats not the color of the original image. > file 04, VPA is not good thats not the correct color > > It seems th last (variance per axis) is more pale and looses color > You're right, the variance per axis change is not always very good, I might dismissed it entirely. It also makes me question the use of the variance entirely when splitting the boxes. I need to investigate if choosing the box with a simpler heuristic (something naive like picking the box with the highest volume) is not actually improving things. I'll investigate and share the results. Thanks for looking deeply into that! > > Have you done any double blind comparission ? Nope, I probably should, but I'm not sure I have the energy to setup such a thing yet. Regards, -- Clément B. ___ 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] Rework color quantization in palette{gen,use}
On Sun, Nov 06, 2022 at 08:19:24AM -0500, Ronald S. Bultje wrote: > Hi, > > On Sat, Nov 5, 2022 at 2:54 PM Clément Bœsch wrote: > > > On Sat, Nov 05, 2022 at 04:44:39PM +0100, Paul B Mahol wrote: > > [...] > > > > Finally, I do believe a lot of other color filters could at least > > benefit > > > > from > > > > fixing their gamma handling (I know I'm guilty of this in various other > > > > filters). > > > > > > gamma handling depends not on pixel format but on metadata present in > > frame. > > > > Right, as suggested by Ronald on IRC, maybe it would have been appropriate > > to use the vf colorspace code to honor the transfer functions. > > > > That being said, this involves quite a substantial refactoring. Is this > > considered blocking? > > > > Not for me. I'd like a big fat FIXME and I (or you, or anyone) can look > into this at some point in the future. > I will likely add a warning, or even error out if the input is not sRGB to limit the damage. -- Clément B. ___ 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] Rework color quantization in palette{gen,use}
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Clément Bœsch
> Sent: Tuesday, November 8, 2022 10:08 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Rework color quantization in
> palette{gen,use}
>
> On Sun, Nov 06, 2022 at 07:46:38PM +, Soft Works wrote:
> >
> >
> > > -Original Message-
> > > From: ffmpeg-devel On Behalf Of
> > > Clément Bœsch
> > > Sent: Saturday, November 5, 2022 4:26 PM
> > > To: ffmpeg-devel@ffmpeg.org
> > > Subject: [FFmpeg-devel] Rework color quantization in
> palette{gen,use}
> > >
> > > Hi,
> > >
> > > This patchset essentially fixes a few core problems in these
> filters
> > > and
> > > switches to a perceptual model.
> > >
> > > I've generated a report for each key commit on this (temporary)
> page:
> > > http://big.pkh.me/pal/ (warning: heavy page, ~500M; I did try to
> add
> > > some lazy
> > > loading of the images but I'm not sure it's actually working as
> > > expected).
> >
> > Comparing the results for the known and simple "rainbow O" example
> reveals
> > that the proposed implementation seems to be even inferior to the
> current
> > code and even farther away from what is possible to achieve:
> >
> > https://gist.github.com/softworkz/e310e3c84a338f98977d70b09e3e3f4f
>
> The pngquant file on this page has 373 unique colors, and the
> transparency
> is fake (the checkerboard is opaque white & grey). I think there is a
> mistake here.
Hi Clement,
I'm sorry about the confusion. The files in both Gists were created
in the same way: Opened the result image in PhotoShop, set the view
size to 400% and then created a screenshot and pasted into the Gist.
The reason I did it that way was that GitHub seemed to do its own
image "optimization" and I wanted to rule out any such effects and
just let others see what I see.
I couldn't find the original result from pngquant, but I have attached
the result from the elbg filter which is almost of the same quality.
For completeness, I'm also including the recent comparison, but it
seems you're already on track in this regard.
> WRT the regression after the patch, I confirm that there is a problem
> related to the dithering. If you try with dither=none or even
> dither=bayer, you'll observe that the colors are much better. I will
> update the results page at some point to include that file.
That would be great. Maybe you could also find another "simple" example
like with large-scale gradients rather than being so strongly colored
like the others?
Then I'd have a question about your file07 example. Is this the
original file or did I mix something up?
http://big.pkh.me/pal/output/0-current/file07/cfg00/0-ref.png
I'm wondering because the image is full or weird artifacts at the
edges of the green (and other) leafes.
> Now indeed the sierra dithering (and probably the other of the same
> type)
> are somehow spreading way too strongly, it's unclear to me yet but
> that
> might be a bug I introduced. I'll investigate, thanks.
Yup, okay, thanks.
PS: I'd be curious what you think about the elbg image...
Thanks,
softworkz
<>
<>
___
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: fix use of undeclared identifier error when compiling Chromium
> On Nov 9, 2022, at 03:48, uiopt...@gmail.com wrote: > > From: gz83 > > Cross-compiling Chromium on Ubuntu 22.04 will encounter errors related > to avformat, because Chromium regularly synchronizes upstream changes, > so now submit code directly to upstream > --- > libavformat/flac_picture.c | 3 ++- > libavformat/matroskadec.c | 10 +- > libavformat/mov.c | 11 ++- > libavformat/oggdec.c | 1 + > libavformat/riff.c | 1 + > 5 files changed, 15 insertions(+), 11 deletions(-) > > diff --git a/libavformat/flac_picture.c b/libavformat/flac_picture.c > index b33fee75b4..36d190fdc7 100644 > --- a/libavformat/flac_picture.c > +++ b/libavformat/flac_picture.c > @@ -19,9 +19,10 @@ > * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 > USA > */ > > -#include "libavutil/intreadwrite.h" > #include "libavcodec/bytestream.h" > +#include "libavcodec/defs.h" > #include "libavcodec/png.h" > +#include "libavutil/intreadwrite.h" > #include "avformat.h" > #include "demux.h" > #include "flac_picture.h" > diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c > index d582f566a2..f7bb962941 100644 > --- a/libavformat/matroskadec.c > +++ b/libavformat/matroskadec.c > @@ -34,6 +34,11 @@ > #include > #include > > +#include "libavcodec/bytestream.h" > +#include "libavcodec/defs.h" > +#include "libavcodec/flac.h" > +#include "libavcodec/mpeg4audio.h" > +#include "libavcodec/packet_internal.h" > #include "libavutil/avstring.h" > #include "libavutil/base64.h" > #include "libavutil/bprint.h" > @@ -50,11 +55,6 @@ > #include "libavutil/time_internal.h" > #include "libavutil/spherical.h" > > -#include "libavcodec/bytestream.h" > -#include "libavcodec/flac.h" > -#include "libavcodec/mpeg4audio.h" > -#include "libavcodec/packet_internal.h" > - > #include "avformat.h" > #include "avio_internal.h" > #include "demux.h" > diff --git a/libavformat/mov.c b/libavformat/mov.c > index 1f436e21d6..39d2c71edb 100644 > --- a/libavformat/mov.c > +++ b/libavformat/mov.c > @@ -29,6 +29,12 @@ > #include > #include > > +#include "libavcodec/ac3tab.h" > +#include "libavcodec/defs.h" > +#include "libavcodec/flac.h" > +#include "libavcodec/hevc.h" > +#include "libavcodec/mpegaudiodecheader.h" > +#include "libavcodec/mlp_parse.h" > #include "libavutil/attributes.h" > #include "libavutil/bprint.h" > #include "libavutil/channel_layout.h" > @@ -49,11 +55,6 @@ > #include "libavutil/stereo3d.h" > #include "libavutil/timecode.h" > #include "libavutil/uuid.h" > -#include "libavcodec/ac3tab.h" > -#include "libavcodec/flac.h" > -#include "libavcodec/hevc.h" > -#include "libavcodec/mpegaudiodecheader.h" > -#include "libavcodec/mlp_parse.h" > #include "avformat.h" > #include "internal.h" > #include "avio_internal.h" > diff --git a/libavformat/oggdec.c b/libavformat/oggdec.c > index 3b19e0bd89..c4321a9436 100644 > --- a/libavformat/oggdec.c > +++ b/libavformat/oggdec.c > @@ -29,6 +29,7 @@ > */ > > #include > +#include "libavcodec/defs.h" > #include "libavutil/avassert.h" > #include "libavutil/intreadwrite.h" > #include "avio_internal.h" > diff --git a/libavformat/riff.c b/libavformat/riff.c > index 7319406b39..b1cac3171b 100644 > --- a/libavformat/riff.c > +++ b/libavformat/riff.c > @@ -22,6 +22,7 @@ > #include > #include "config.h" > #include "config_components.h" > +#include "libavcodec/codec_id.h" > #include "libavutil/macros.h" > #include "avformat.h" > #include "internal.h" > -- > 2.38.1.windows.1 > Please explain why the patch is needed. If chromium rewrite the build system of FFmpeg, I don’t think FFmpeg should support it. ___ 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: fix use of undeclared identifier error when compiling Chromium
I encountered an error in the files included in this patch when compiling Chromium. When I followed this patch to modify the ffmpeg file in the Chromium source code, the compilation no longer reported errors. Chromium regularly merges the latest revisions of ffmpeg through Cherry-Pick. I also submitted this patch to Chromium before submitting it to ffmpeg, but Chromium asked me to submit it to ffmpeg first "zhilizhao(赵志立)" 於 2022年11月9日 週三 10:23 寫道： > > > > On Nov 9, 2022, at 03:48, uiopt...@gmail.com wrote: > > > > From: gz83 > > > > Cross-compiling Chromium on Ubuntu 22.04 will encounter errors related > > to avformat, because Chromium regularly synchronizes upstream changes, > > so now submit code directly to upstream > > --- > > libavformat/flac_picture.c | 3 ++- > > libavformat/matroskadec.c | 10 +- > > libavformat/mov.c | 11 ++- > > libavformat/oggdec.c | 1 + > > libavformat/riff.c | 1 + > > 5 files changed, 15 insertions(+), 11 deletions(-) > > > > diff --git a/libavformat/flac_picture.c b/libavformat/flac_picture.c > > index b33fee75b4..36d190fdc7 100644 > > --- a/libavformat/flac_picture.c > > +++ b/libavformat/flac_picture.c > > @@ -19,9 +19,10 @@ > > * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA > 02110-1301 USA > > */ > > > > -#include "libavutil/intreadwrite.h" > > #include "libavcodec/bytestream.h" > > +#include "libavcodec/defs.h" > > #include "libavcodec/png.h" > > +#include "libavutil/intreadwrite.h" > > #include "avformat.h" > > #include "demux.h" > > #include "flac_picture.h" > > diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c > > index d582f566a2..f7bb962941 100644 > > --- a/libavformat/matroskadec.c > > +++ b/libavformat/matroskadec.c > > @@ -34,6 +34,11 @@ > > #include > > #include > > > > +#include "libavcodec/bytestream.h" > > +#include "libavcodec/defs.h" > > +#include "libavcodec/flac.h" > > +#include "libavcodec/mpeg4audio.h" > > +#include "libavcodec/packet_internal.h" > > #include "libavutil/avstring.h" > > #include "libavutil/base64.h" > > #include "libavutil/bprint.h" > > @@ -50,11 +55,6 @@ > > #include "libavutil/time_internal.h" > > #include "libavutil/spherical.h" > > > > -#include "libavcodec/bytestream.h" > > -#include "libavcodec/flac.h" > > -#include "libavcodec/mpeg4audio.h" > > -#include "libavcodec/packet_internal.h" > > - > > #include "avformat.h" > > #include "avio_internal.h" > > #include "demux.h" > > diff --git a/libavformat/mov.c b/libavformat/mov.c > > index 1f436e21d6..39d2c71edb 100644 > > --- a/libavformat/mov.c > > +++ b/libavformat/mov.c > > @@ -29,6 +29,12 @@ > > #include > > #include > > > > +#include "libavcodec/ac3tab.h" > > +#include "libavcodec/defs.h" > > +#include "libavcodec/flac.h" > > +#include "libavcodec/hevc.h" > > +#include "libavcodec/mpegaudiodecheader.h" > > +#include "libavcodec/mlp_parse.h" > > #include "libavutil/attributes.h" > > #include "libavutil/bprint.h" > > #include "libavutil/channel_layout.h" > > @@ -49,11 +55,6 @@ > > #include "libavutil/stereo3d.h" > > #include "libavutil/timecode.h" > > #include "libavutil/uuid.h" > > -#include "libavcodec/ac3tab.h" > > -#include "libavcodec/flac.h" > > -#include "libavcodec/hevc.h" > > -#include "libavcodec/mpegaudiodecheader.h" > > -#include "libavcodec/mlp_parse.h" > > #include "avformat.h" > > #include "internal.h" > > #include "avio_internal.h" > > diff --git a/libavformat/oggdec.c b/libavformat/oggdec.c > > index 3b19e0bd89..c4321a9436 100644 > > --- a/libavformat/oggdec.c > > +++ b/libavformat/oggdec.c > > @@ -29,6 +29,7 @@ > > */ > > > > #include > > +#include "libavcodec/defs.h" > > #include "libavutil/avassert.h" > > #include "libavutil/intreadwrite.h" > > #include "avio_internal.h" > > diff --git a/libavformat/riff.c b/libavformat/riff.c > > index 7319406b39..b1cac3171b 100644 > > --- a/libavformat/riff.c > > +++ b/libavformat/riff.c > > @@ -22,6 +22,7 @@ > > #include > > #include "config.h" > > #include "config_components.h" > > +#include "libavcodec/codec_id.h" > > #include "libavutil/macros.h" > > #include "avformat.h" > > #include "internal.h" > > -- > > 2.38.1.windows.1 > > > > Please explain why the patch is needed. If chromium rewrite the build > system > of FFmpeg, I don’t think FFmpeg should support it. > ___ > 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] avformat: fix use of undeclared identifier error when compiling Chromium
> On Nov 9, 2022, at 10:41, 揚帆起航 wrote: > > I encountered an error in the files included in this patch when compiling > Chromium. When I followed this patch to modify the ffmpeg file in the > Chromium source code, the compilation no longer reported errors. > > Chromium regularly merges the latest revisions of ffmpeg through > Cherry-Pick. I also submitted this patch to Chromium before submitting it > to ffmpeg, but Chromium asked me to submit it to ffmpeg first We can’t reproduce the issue, so more details of each ‘undeclared identifier error’ should be given. For example, why >>> +#include "libavcodec/defs.h” is needed in flac_picture.c since it’s already included by avformat.h? > > "zhilizhao(赵志立)" 於 2022年11月9日 週三 10:23 寫道： > >> >> >>> On Nov 9, 2022, at 03:48, uiopt...@gmail.com wrote: >>> >>> From: gz83 >>> >>> Cross-compiling Chromium on Ubuntu 22.04 will encounter errors related >>> to avformat, because Chromium regularly synchronizes upstream changes, >>> so now submit code directly to upstream >>> --- >>> libavformat/flac_picture.c | 3 ++- >>> libavformat/matroskadec.c | 10 +- >>> libavformat/mov.c | 11 ++- >>> libavformat/oggdec.c | 1 + >>> libavformat/riff.c | 1 + >>> 5 files changed, 15 insertions(+), 11 deletions(-) >>> >>> diff --git a/libavformat/flac_picture.c b/libavformat/flac_picture.c >>> index b33fee75b4..36d190fdc7 100644 >>> --- a/libavformat/flac_picture.c >>> +++ b/libavformat/flac_picture.c >>> @@ -19,9 +19,10 @@ >>> * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA >> 02110-1301 USA >>> */ >>> >>> -#include "libavutil/intreadwrite.h" >>> #include "libavcodec/bytestream.h" >>> +#include "libavcodec/defs.h" >>> #include "libavcodec/png.h" >>> +#include "libavutil/intreadwrite.h" >>> #include "avformat.h" >>> #include "demux.h" >>> #include "flac_picture.h" >>> diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c >>> index d582f566a2..f7bb962941 100644 >>> --- a/libavformat/matroskadec.c >>> +++ b/libavformat/matroskadec.c >>> @@ -34,6 +34,11 @@ >>> #include >>> #include >>> >>> +#include "libavcodec/bytestream.h" >>> +#include "libavcodec/defs.h" >>> +#include "libavcodec/flac.h" >>> +#include "libavcodec/mpeg4audio.h" >>> +#include "libavcodec/packet_internal.h" >>> #include "libavutil/avstring.h" >>> #include "libavutil/base64.h" >>> #include "libavutil/bprint.h" >>> @@ -50,11 +55,6 @@ >>> #include "libavutil/time_internal.h" >>> #include "libavutil/spherical.h" >>> >>> -#include "libavcodec/bytestream.h" >>> -#include "libavcodec/flac.h" >>> -#include "libavcodec/mpeg4audio.h" >>> -#include "libavcodec/packet_internal.h" >>> - >>> #include "avformat.h" >>> #include "avio_internal.h" >>> #include "demux.h" >>> diff --git a/libavformat/mov.c b/libavformat/mov.c >>> index 1f436e21d6..39d2c71edb 100644 >>> --- a/libavformat/mov.c >>> +++ b/libavformat/mov.c >>> @@ -29,6 +29,12 @@ >>> #include >>> #include >>> >>> +#include "libavcodec/ac3tab.h" >>> +#include "libavcodec/defs.h" >>> +#include "libavcodec/flac.h" >>> +#include "libavcodec/hevc.h" >>> +#include "libavcodec/mpegaudiodecheader.h" >>> +#include "libavcodec/mlp_parse.h" >>> #include "libavutil/attributes.h" >>> #include "libavutil/bprint.h" >>> #include "libavutil/channel_layout.h" >>> @@ -49,11 +55,6 @@ >>> #include "libavutil/stereo3d.h" >>> #include "libavutil/timecode.h" >>> #include "libavutil/uuid.h" >>> -#include "libavcodec/ac3tab.h" >>> -#include "libavcodec/flac.h" >>> -#include "libavcodec/hevc.h" >>> -#include "libavcodec/mpegaudiodecheader.h" >>> -#include "libavcodec/mlp_parse.h" >>> #include "avformat.h" >>> #include "internal.h" >>> #include "avio_internal.h" >>> diff --git a/libavformat/oggdec.c b/libavformat/oggdec.c >>> index 3b19e0bd89..c4321a9436 100644 >>> --- a/libavformat/oggdec.c >>> +++ b/libavformat/oggdec.c >>> @@ -29,6 +29,7 @@ >>> */ >>> >>> #include >>> +#include "libavcodec/defs.h" >>> #include "libavutil/avassert.h" >>> #include "libavutil/intreadwrite.h" >>> #include "avio_internal.h" >>> diff --git a/libavformat/riff.c b/libavformat/riff.c >>> index 7319406b39..b1cac3171b 100644 >>> --- a/libavformat/riff.c >>> +++ b/libavformat/riff.c >>> @@ -22,6 +22,7 @@ >>> #include >>> #include "config.h" >>> #include "config_components.h" >>> +#include "libavcodec/codec_id.h" >>> #include "libavutil/macros.h" >>> #include "avformat.h" >>> #include "internal.h" >>> -- >>> 2.38.1.windows.1 >>> >> >> Please explain why the patch is needed. If chromium rewrite the build >> system >> of FFmpeg, I don’t think FFmpeg should support it. >> ___ >> 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.or
