[FFmpeg-devel] [PATCH 1/3] avformat/rmdec: support RMHD file format
---
libavformat/rmdec.c | 42 +-
1 file changed, 29 insertions(+), 13 deletions(-)
diff --git a/libavformat/rmdec.c b/libavformat/rmdec.c
index 0f1534b582..8e2ef7cc41 100644
--- a/libavformat/rmdec.c
+++ b/libavformat/rmdec.c
@@ -428,7 +428,8 @@ skip:
static int rm_read_index(AVFormatContext *s)
{
AVIOContext *pb = s->pb;
-unsigned int size, n_pkts, str_id, next_off, n, pos, pts;
+unsigned int size, ver, n_pkts, str_id, next_off, n, pts;
+uint64_t pos;
AVStream *st;
do {
@@ -437,10 +438,14 @@ static int rm_read_index(AVFormatContext *s)
size = avio_rb32(pb);
if (size < 20)
return -1;
-avio_skip(pb, 2);
+ver = avio_rb16(pb);
+if (ver != 0 && ver != 2)
+return AVERROR_INVALIDDATA;
n_pkts = avio_rb32(pb);
str_id = avio_rb16(pb);
next_off = avio_rb32(pb);
+if (ver == 2)
+avio_skip(pb, 4);
for (n = 0; n < s->nb_streams; n++)
if (s->streams[n]->id == str_id) {
st = s->streams[n];
@@ -465,7 +470,7 @@ static int rm_read_index(AVFormatContext *s)
return AVERROR_INVALIDDATA;
avio_skip(pb, 2);
pts = avio_rb32(pb);
-pos = avio_rb32(pb);
+pos = (ver == 0) ? avio_rb32(pb) : avio_rb64(pb);
avio_skip(pb, 4); /* packet no. */
av_add_index_entry(st, pos, pts, 0, 0, AVINDEX_KEYFRAME);
@@ -546,8 +551,10 @@ static int rm_read_header(AVFormatContext *s)
AVIOContext *pb = s->pb;
unsigned int tag;
int tag_size;
+int ver;
unsigned int start_time, duration;
-unsigned int data_off = 0, indx_off = 0;
+unsigned int data_off = 0;
+uint64_t indx_off = 0;
char buf[128], mime[128];
int flags = 0;
int ret;
@@ -558,7 +565,7 @@ static int rm_read_header(AVFormatContext *s)
if (tag == MKTAG('.', 'r', 'a', 0xfd)) {
/* very old .ra format */
return rm_read_header_old(s);
-} else if (tag != MKTAG('.', 'R', 'M', 'F')) {
+} else if (tag != MKTAG('.', 'R', 'M', 'F') && tag != MKTAG('.', 'R', 'M',
'P')) {
return AVERROR(EIO);
}
@@ -572,10 +579,11 @@ static int rm_read_header(AVFormatContext *s)
return AVERROR_INVALIDDATA;
tag = avio_rl32(pb);
tag_size = avio_rb32(pb);
-avio_rb16(pb);
+ver = avio_rb16(pb);
av_log(s, AV_LOG_TRACE, "tag=%s size=%d\n",
av_fourcc2str(tag), tag_size);
-if (tag_size < 10 && tag != MKTAG('D', 'A', 'T', 'A'))
+if ((tag_size < 10 && tag != MKTAG('D', 'A', 'T', 'A')) ||
+(ver != 0 && ver != 2))
return AVERROR_INVALIDDATA;
switch(tag) {
case MKTAG('P', 'R', 'O', 'P'):
@@ -588,7 +596,7 @@ static int rm_read_header(AVFormatContext *s)
duration = avio_rb32(pb); /* duration */
s->duration = av_rescale(duration, AV_TIME_BASE, 1000);
avio_rb32(pb); /* preroll */
-indx_off = avio_rb32(pb); /* index offset */
+indx_off = (ver == 0) ? avio_rb32(pb) : avio_rb64(pb); /* index
offset */
data_off = avio_rb32(pb); /* data offset */
avio_rb16(pb); /* nb streams */
flags = avio_rb16(pb); /* flags */
@@ -650,15 +658,17 @@ static int rm_read_header(AVFormatContext *s)
rm->nb_packets = avio_rb32(pb); /* number of packets */
if (!rm->nb_packets && (flags & 4))
rm->nb_packets = 3600 * 25;
+if (ver == 2)
+avio_skip(pb, 12);
avio_rb32(pb); /* next data header */
if (!data_off)
-data_off = avio_tell(pb) - 18;
+data_off = avio_tell(pb) - (ver == 0 ? 18 : 30);
if (indx_off && (pb->seekable & AVIO_SEEKABLE_NORMAL) &&
!(s->flags & AVFMT_FLAG_IGNIDX) &&
avio_seek(pb, indx_off, SEEK_SET) >= 0) {
rm_read_index(s);
-avio_seek(pb, data_off + 18, SEEK_SET);
+avio_seek(pb, data_off + (ver == 0 ? 18 : 30), SEEK_SET);
}
return 0;
@@ -706,9 +716,15 @@ static int rm_sync(AVFormatContext *s, int64_t *timestamp,
int *flags, int *stre
int n_pkts;
int64_t expected_len;
len = avio_rb32(pb);
-avio_skip(pb, 2);
+int ver = avio_rb16(pb);
+if (ver != 0 && ver != 2)
+return AVERROR_INVALIDDATA;
n_pkts = avio_rb32(pb);
-expected_len = 20 + n_pkts * 14LL;
+
+if (ver == 0)
+expected_len = 20 + n_pkts * 14LL;
+else if (ver == 2)
+expected_len = 24 + n_pkts * 18LL;
if (len == 20 && expected_len <= INT_MAX)
/* some files don't add index entries to chunk size... */
@@ -1078,7 +1094,7 @@ static int rm_probe(const AVProbeData *p)
{
/* check file header
[FFmpeg-devel] [PATCH 3/3] fate: rv60 test cases
--- samples: https://pross.sdf.org/sandpit/test72x72.rmhd (32 KiB) https://pross.sdf.org/sandpit/test512x512.rmhd (64 KiB) tests/fate/video.mak| 8 tests/ref/fate/rv60-512x512 | 9 + tests/ref/fate/rv60-72x72 | 40 + 3 files changed, 57 insertions(+) create mode 100644 tests/ref/fate/rv60-512x512 create mode 100644 tests/ref/fate/rv60-72x72 diff --git a/tests/fate/video.mak b/tests/fate/video.mak index 4e7a77537f..62e6ff1d6b 100644 --- a/tests/fate/video.mak +++ b/tests/fate/video.mak @@ -376,6 +376,14 @@ fate-smvjpeg: CMD = framecrc -idct simple -flags +bitexact -i $(TARGET_SAMPLES)/ FATE_VIDEO-$(call FRAMECRC, AVI, VQC) += fate-vqc fate-vqc: CMD = framecrc -i $(TARGET_SAMPLES)/vqc/samp1.avi +FATE_VIDEO-$(call FRAMECRC, RM, RV60) += fate-rv60-512x512 +fate-rv60-512x512: CMD = framecrc -i $(TARGET_SAMPLES)/rv60/test512x512.rmhd -an + +FATE_VIDEO-$(call FRAMECRC, RM, RV60) += fate-rv60-72x72 +fate-rv60-72x72: CMD = framecrc -i $(TARGET_SAMPLES)/rv60/test72x72.rmhd -an + +fate-rv60: fate-rv60-72x72 fate-rv60-512x512 + FATE_VIDEO += $(FATE_VIDEO-yes) FATE_SAMPLES_FFMPEG += $(FATE_VIDEO) diff --git a/tests/ref/fate/rv60-512x512 b/tests/ref/fate/rv60-512x512 new file mode 100644 index 00..ac2a48f996 --- /dev/null +++ b/tests/ref/fate/rv60-512x512 @@ -0,0 +1,9 @@ +#tb 0: 1/25 +#media_type 0: video +#codec_id 0: rawvideo +#dimensions 0: 512x512 +#sar 0: 0/1 +0, 0, 0,1, 393216, 0x559b76dc +0, 1, 1,1, 393216, 0x419ee67f +0, 2, 2,1, 393216, 0xda985622 +0, 3, 3,1, 393216, 0x25957f66 diff --git a/tests/ref/fate/rv60-72x72 b/tests/ref/fate/rv60-72x72 new file mode 100644 index 00..2f01c2d1f2 --- /dev/null +++ b/tests/ref/fate/rv60-72x72 @@ -0,0 +1,40 @@ +#tb 0: 1/25 +#media_type 0: video +#codec_id 0: rawvideo +#dimensions 0: 72x72 +#sar 0: 0/1 +0, 0, 0,1, 7776, 0x7cef305a +0, 1, 1,1, 7776, 0xe85633d8 +0, 2, 2,1, 7776, 0x38b13204 +0, 3, 3,1, 7776, 0x62c22ba8 +0, 4, 4,1, 7776, 0x38b42d19 +0, 5, 5,1, 7776, 0x80ed2acc +0, 6, 6,1, 7776, 0xbe1f28b7 +0, 7, 7,1, 7776, 0xfa7726d3 +0, 8, 8,1, 7776, 0x473123c3 +0, 9, 9,1, 7776, 0x79072354 +0, 10, 10,1, 7776, 0x1c141c43 +0, 11, 11,1, 7776, 0x50ec1c56 +0, 12, 12,1, 7776, 0x6ccc17bf +0, 13, 13,1, 7776, 0x68101a13 +0, 14, 14,1, 7776, 0x63a21e20 +0, 15, 15,1, 7776, 0xab352043 +0, 16, 16,1, 7776, 0xb81323d6 +0, 17, 17,1, 7776, 0xd08b2931 +0, 18, 18,1, 7776, 0x3ce82ac8 +0, 19, 19,1, 7776, 0x62382cd6 +0, 20, 20,1, 7776, 0x72252ff0 +0, 21, 21,1, 7776, 0x15043309 +0, 22, 22,1, 7776, 0xa6b93378 +0, 23, 23,1, 7776, 0x032c35bf +0, 24, 24,1, 7776, 0xaf5e36ab +0, 25, 25,1, 7776, 0x2c682ef1 +0, 26, 26,1, 7776, 0x07f6319e +0, 27, 27,1, 7776, 0x028e3257 +0, 28, 28,1, 7776, 0x92cb3763 +0, 29, 29,1, 7776, 0x7d7536d1 +0, 30, 30,1, 7776, 0xe8743875 +0, 31, 31,1, 7776, 0x06763a63 +0, 32, 32,1, 7776, 0xe1973be5 +0, 33, 33,1, 7776, 0x26283bde +0, 36, 36,1, 7776, 0xbcda3aca -- 2.42.0 -- Peter (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B) 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] avcodec/amfenc: Fix for windows imprecise sleep
On Tue, Oct 17, 2023 at 9:45 PM Kacper Michajlow wrote:
> On Tue, 17 Oct 2023 at 19:34, Evgeny Pavlov wrote:
> >
> > The reason for using av_usleep() here is that AMF API doesn’t provide an
> > API for explicit wait. There are two modes to get output from encoder:
> >
> > 1. Polling with some sleep to avoid CPU thrashing – currently used in
> FFmpeg
> >
> > 2. Set timeout parameter on AMF encoder and QueryOutput call will block
> > till output is available or the timeout happens.
> >
> > #2 is the preferable way but it is designed more to be used with a
> separate
> > polling thread. With a single-thread approach in FFmpeg, the use of
> timeout
> > can block input submission making things slower. This is even more
> > pronounced when B-frames are enabled and several inputs are needed to
> produce
> > the first output.
> >
> > The condition of this sleep is in special events (primarily when amf
> input
> > queue is full), not the core loop part. During the experiments the cpu
> > increasing is about 2-4% or so, not a burst.
> >
> > For low resolution encoding, these changes bring significant performance
> > improvement (about 15%). It will not bring improvement for high
> resolution
> > such as 4K.
> >
> >
> > Thanks,
> >
> > Evgeny
> >
> > вт, 17 окт. 2023 г. в 03:26, Zhao Zhili :
> >
> > >
> > > > 在 2023年10月17日，上午5:24，Mark Thompson 写道：
> > > >
> > > > On 16/10/2023 10:13, Evgeny Pavlov wrote:
> > > >> This commit reduces the sleep time on Windows to improve AMF
> encoding
> > > >> performance on low resolution input videos.
> > > >> This fix is for Windows only, because sleep() function isn't
> > > >> very accurate on Windows OS.
> > > >> Fix for issue #10622
> > > >> Signed-off-by: Evgeny Pavlov
> > > >> ---
> > > >> libavcodec/amfenc.c | 4
> > > >> 1 file changed, 4 insertions(+)
> > > >> diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c
> > > >> index 061859f85c..0c95465d6e 100644
> > > >> --- a/libavcodec/amfenc.c
> > > >> +++ b/libavcodec/amfenc.c
> > > >> @@ -770,7 +770,11 @@ int ff_amf_receive_packet(AVCodecContext
> *avctx,
> > > AVPacket *avpkt)
> > > >> if (query_output_data_flag == 0) {
> > > >> if (res_resubmit == AMF_INPUT_FULL ||
> ctx->delayed_drain
> > > || (ctx->eof && res_query != AMF_EOF) || (ctx->hwsurfaces_in_queue >=
> > > ctx->hwsurfaces_in_queue_max)) {
> > > >> block_and_wait = 1;
> > > >> +#ifdef _WIN32
> > > >> +av_usleep(0); //Sleep() is not precise on Windows
> OS.
> > > >> +#else
> > > >> av_usleep(1000);
> > > >> +#endif
> > > >> }
> > > >> }
> > > >> } while (block_and_wait);
> > > >
> > > > Wasting lots of power by spinning on a CPU core does not seem like a
> > > good answer to this problem. (I mean, presumably that is why Windows
> isn't
> > > honouring your request for a short sleep, because it wants timers to
> have
> > > larger gaps to avoid wasting power.)
> > >
> > > If av_usleep is implemented via Sleep like current case, sleep 0 means
> > > yield current thread, so it’s not busy wait in normal case (but it can
> be
> > > busy wait).
> > >
> > > av_usleep(500) may looks better and do the same job by depending
> 500/1000
> > > = 0.
> > >
> > > I agree use sleep without real async is like a bug.
> > >
> > > >
> > > > Why is there a sleep here at all, anyway? An API for hardware
> encoding
> > > should be providing a way for the caller to wait for an outstanding
> > > operation to complete.
> > > >
> > > > Thanks,
> > > >
> > > > - 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 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".
>
> Please don't top-post. I'll bottom-post now and no one will know how
> to read this email.
>
> If you need more precise sleep on Windows, your application should use
> timeBeginPeriod/timeEndPeriod API, see
>
> https://learn.microsoft.com/en-us/windows/win32/api/timeapi/nf-timeapi-timebeginperiod
>
> This sleep shouldn't be there to begin with and removing it only for
> Windows, seems like a hacky workaround.
>
> Sleep on Windows is accurate, when you request a timer resolution
> appropriate for your application. You probably don't do that, and have
> unexpectedly long sleeps, but it is not because they are "
[FFmpeg-devel] Opportunity to contribute to Media Localization Company (live streaming)
Hey there, I'm here to share that there is an opportunity to join a media localization startup, that requires help with setting live streamings. That means you can be a frontman in the creation of a worldwide product. Mainly used: Java / AWS Media Live / Media Package / FFmpeg HLS / SRT / webRTC (C++ is also could be an option) Contact me if you want to hear more I wish you all the best Nick (: ___ 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] aarch64: Stop using asm/hwcap.h for the HWCAP_* detection
Including sys/auxv.h should be enough (it pulls in bits/hwcap.h, which provides the same defines). --- configure | 2 -- libavutil/aarch64/cpu.c | 3 +-- 2 files changed, 1 insertion(+), 4 deletions(-) diff --git a/configure b/configure index bc0c0bd4e4..4ab20c54ec 100755 --- a/configure +++ b/configure @@ -2202,7 +2202,6 @@ HAVE_LIST_PUB=" HEADERS_LIST=" arpa_inet_h -asm_hwcap_h asm_types_h cdio_paranoia_h cdio_paranoia_paranoia_h @@ -6453,7 +6452,6 @@ check_headers io.h enabled libdrm && check_headers linux/dma-buf.h -check_headers asm/hwcap.h check_headers linux/perf_event.h check_headers libcrystalhd/libcrystalhd_if.h check_headers malloc.h diff --git a/libavutil/aarch64/cpu.c b/libavutil/aarch64/cpu.c index 2803b31443..bd780e8591 100644 --- a/libavutil/aarch64/cpu.c +++ b/libavutil/aarch64/cpu.c @@ -20,9 +20,8 @@ #include "libavutil/cpu_internal.h" #include "config.h" -#if (defined(__linux__) || defined(__ANDROID__)) && HAVE_GETAUXVAL && HAVE_ASM_HWCAP_H +#if (defined(__linux__) || defined(__ANDROID__)) && HAVE_GETAUXVAL #include -#include #include #define get_cpu_feature_reg(reg, val) \ -- 2.34.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/2] aarch64: Only enable extensions in the intended files/regions
This eases actual development of the assembly functions, by only allowing extension instructions within the sections that explicitly enable them, instead of having all extensions enabled everywhere. --- libavcodec/aarch64/hevcdsp_epel_neon.S | 3 ++- libavcodec/aarch64/hevcdsp_qpel_neon.S | 2 ++ libavutil/aarch64/asm.S| 16 ++-- 3 files changed, 18 insertions(+), 3 deletions(-) diff --git a/libavcodec/aarch64/hevcdsp_epel_neon.S b/libavcodec/aarch64/hevcdsp_epel_neon.S index edaf39ed92..e398e6ac9d 100644 --- a/libavcodec/aarch64/hevcdsp_epel_neon.S +++ b/libavcodec/aarch64/hevcdsp_epel_neon.S @@ -339,6 +339,7 @@ function ff_hevc_put_hevc_epel_uni_v64_8_neon, export=1 endfunc #if HAVE_I8MM +ENABLE_I8MM .macro EPEL_H_HEADER movrel x5, epel_filters @@ -1963,7 +1964,7 @@ function ff_hevc_put_hevc_epel_uni_w_hv64_8_neon_i8mm, export=1 ret endfunc - +DISABLE_I8MM #endif diff --git a/libavcodec/aarch64/hevcdsp_qpel_neon.S b/libavcodec/aarch64/hevcdsp_qpel_neon.S index 1212eae63d..e131b92a98 100644 --- a/libavcodec/aarch64/hevcdsp_qpel_neon.S +++ b/libavcodec/aarch64/hevcdsp_qpel_neon.S @@ -1558,6 +1558,7 @@ function ff_hevc_put_hevc_qpel_uni_w_v64_8_neon, export=1 endfunc #if HAVE_I8MM +ENABLE_I8MM .macro calc_all2 calc v30, v31, v16, v18, v20, v22, v24, v26, v28, v30, v17, v19, v21, v23, v25, v27, v29, v31 @@ -3395,4 +3396,5 @@ function ff_hevc_put_hevc_qpel_uni_w_hv64_8_neon_i8mm, export=1 ret endfunc +DISABLE_I8MM #endif // HAVE_I8MM diff --git a/libavutil/aarch64/asm.S b/libavutil/aarch64/asm.S index 8589cf74fc..1840f9fb01 100644 --- a/libavutil/aarch64/asm.S +++ b/libavutil/aarch64/asm.S @@ -41,12 +41,24 @@ #endif #if HAVE_AS_ARCHEXT_DOTPROD_DIRECTIVE -.arch_extension dotprod +#define ENABLE_DOTPROD .arch_extension dotprod +#define DISABLE_DOTPROD .arch_extension nodotprod +#else +#define ENABLE_DOTPROD +#define DISABLE_DOTPROD #endif + #if HAVE_AS_ARCHEXT_I8MM_DIRECTIVE -.arch_extension i8mm +#define ENABLE_I8MM .arch_extension i8mm +#define DISABLE_I8MM .arch_extension noi8mm +#else +#define ENABLE_I8MM +#define DISABLE_I8MM #endif +DISABLE_DOTPROD +DISABLE_I8MM + /* Support macros for * - Armv8.3-A Pointer Authentication and -- 2.34.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/hevc_ps: Dont leave invalid cpb_cnt_minus1 in the context
Michael Niedermayer:
> Fixes: index 32 out of bounds for type 'uint32_t [32]'
> Fixes:
> 63003/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-4685160840560640
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/hevc_ps.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
> index a6b64b92e3..f4365ef5b5 100644
> --- a/libavcodec/hevc_ps.c
> +++ b/libavcodec/hevc_ps.c
> @@ -421,6 +421,7 @@ static int decode_hrd(GetBitContext *gb, int
> common_inf_present,
> if (hdr->cpb_cnt_minus1[i] > 31) {
> av_log(NULL, AV_LOG_ERROR, "nb_cpb %d invalid\n",
> hdr->cpb_cnt_minus1[i]);
> +hdr->cpb_cnt_minus1[i] = 0;
> return AVERROR_INVALIDDATA;
> }
> }
There is a second issue here: There can be truncation during the
previous assignment, because cpb_cnt_minus1 is uint8_t. So this should
be fixed by properly checking the value and only putting it in the
parameter set after it has been validated (which also avoids having to
reset it).
- 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 v28 1/2] avcodec/evc_encoder: Provided support for EVC encoder
On Tue, Sep 19, 2023 at 7:34 AM Dawid Kozinski wrote:
>
> - Added EVC encoder wrapper
> - Changes in project configuration file and libavcodec Makefile
> - Added documentation for xeve wrapper
>
Can you make this work with just the baseline library too? For Fedora
and EPEL, we can only ship the xev{e,d} baseline libraries.
--
真実はいつも一つ！/ Always, there's only one truth!
___
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 v28 2/2] avcodec/evc_decoder: Provided support for EVC decoder
On Tue, Sep 19, 2023 at 7:35 AM Dawid Kozinski wrote:
>
> - Added EVC decoder wrapper
> - Changes in project configuration file and libavcodec Makefile
> - Added documentation for xevd wrapper
>
Can you make this work with just the baseline library too? For Fedora
and EPEL, we can only ship the xev{e,d} baseline libraries.
--
真実はいつも一つ！/ Always, there's only one truth!
___
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] Add init_program_date_time so start time can be specified
On 18 Oct 2023, at 3:14, David Johansen wrote:
> On Tue, Oct 17, 2023 at 7:09 PM wrote:
>
>>
>>
>> On 17 Oct 2023, at 17:51, Dave Johansen wrote:
>>
>>> ---
>>> doc/muxers.texi | 3 +++
>>> libavformat/hlsenc.c | 7 ++-
>>> 2 files changed, 9 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/doc/muxers.texi b/doc/muxers.texi
>>> index f6071484ff..87c19a5cb9 100644
>>> --- a/doc/muxers.texi
>>> +++ b/doc/muxers.texi
>>> @@ -1086,6 +1086,9 @@ seeking. This flag should be used with the
>> @code{hls_time} option.
>>> @item program_date_time
>>> Generate @code{EXT-X-PROGRAM-DATE-TIME} tags.
>>>
>>> +@item init_program_date_time
>>> +Time to start program date time at.
>>> +
>>> @item second_level_segment_index
>>> Makes it possible to use segment indexes as %%d in hls_segment_filename
>> expression
>>> besides date/time values when strftime is on.
>>> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>>> index 4ef84c05c1..474322cc21 100644
>>> --- a/libavformat/hlsenc.c
>>> +++ b/libavformat/hlsenc.c
>>> @@ -28,6 +28,8 @@
>>> #include
>>> #endif
>>>
>>> +#include "float.h"
>>> +
>>> #include "libavutil/avassert.h"
>>> #include "libavutil/mathematics.h"
>>> #include "libavutil/avstring.h"
>>> @@ -212,6 +214,8 @@ typedef struct HLSContext {
>>> int64_t recording_time;
>>> int64_t max_seg_size; // every segment file max size
>>>
>>> +double init_program_date_time;
>>> +
>>> char *baseurl;
>>> char *vtt_format_options_str;
>>> char *subtitle_filename;
>>> @@ -2867,7 +2871,7 @@ static int hls_init(AVFormatContext *s)
>>> char *p = NULL;
>>> int http_base_proto = ff_is_http_proto(s->url);
>>> int fmp4_init_filename_len = strlen(hls->fmp4_init_filename) + 1;
>>> -double initial_program_date_time = av_gettime() / 100.0;
>>> +double initial_program_date_time = hls->init_program_date_time ?
>> hls->init_program_date_time : av_gettime() / 100.0;
>>>
>>> if (hls->use_localtime) {
>>> pattern = get_default_pattern_localtime_fmt(s);
>>> @@ -3141,6 +3145,7 @@ static const AVOption options[] = {
>>> {"split_by_time", "split the hls segment by time which user set by
>> hls_time", 0, AV_OPT_TYPE_CONST, {.i64 = HLS_SPLIT_BY_TIME }, 0, UINT_MAX,
>> E, "flags"},
>>> {"append_list", "append the new segments into old hls segment
>> list", 0, AV_OPT_TYPE_CONST, {.i64 = HLS_APPEND_LIST }, 0, UINT_MAX, E,
>> "flags"},
>>> {"program_date_time", "add EXT-X-PROGRAM-DATE-TIME", 0,
>> AV_OPT_TYPE_CONST, {.i64 = HLS_PROGRAM_DATE_TIME }, 0, UINT_MAX, E,
>> "flags"},
>>> +{"init_program_date_time", "Time to start program date time at",
>> OFFSET(init_program_date_time), AV_OPT_TYPE_DOUBLE, {.dbl = 0 }, 0,
>> DBL_MAX, E},
>>
>> This should probably not be mixed into the flags options list.
>>
>> It seems odd to have the user provide a double here instead of a ISO 8601
>> datetime, which is what the spec requires / ends up in the playlist.
>> If you do not want to handle the datetime string parsing, at least it
>> would be good to give a hint what exactly the double value is expected to
>> be here.
>>
>> However usability-wise I would prefer to accept a proper date/time here…
>>
>
> Is there an example of how to accept a string as the option and then do the
> parsing that I could base the code on?
For the option itself, just change the type (of course adjust the struct
variable as well):
{"init_program_date_time", "Time to start program date time at",
OFFSET(init_program_date_time), AV_OPT_TYPE_STRING, .flags = E},
And for parsing maybe have a look at libavformat/dashdec.c around line 191
which does
rudimentary ISO-8601 parsing.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/3] avcodec/rv60: RealVideo 6.0 decoder
Quoting Peter Ross (2023-10-18 10:03:54)
> +static int rv60_decode_frame(AVCodecContext *avctx, AVFrame * frame,
> + int * got_frame, AVPacket * avpkt)
> +{
> +RV60Context *s = avctx->priv_data;
> +GetBitContext gb;
> +int ret, header_size, width, height, ofs;
> +
> +if (avpkt->size == 0) {
> +if (s->last_frame[NEXT_PIC]->data[0] && !s->got_last_frame_output) {
> +if ((ret = av_frame_ref(frame, s->last_frame[NEXT_PIC])) < 0)
> +return ret;
> +s->got_last_frame_output = 1;
> +*got_frame = 1;
> +}
I think you can simplify this into:
if (s->last_frame[NEXT_PIC]->data[0]) {
av_frame_move_ref(frame, s->last_frame[NEXT_PIC]);
*got_frame = 1;
}
> +return 0;
> +}
> +
> +if (avpkt->size < 9)
> +return AVERROR_INVALIDDATA;
> +
> +header_size = avpkt->data[0] * 8 + 9;
> +if (avpkt->size < header_size)
> +return AVERROR_INVALIDDATA;
> +
> +init_get_bits8(&gb, avpkt->data + header_size, avpkt->size -
> header_size);
> +
> +if ((ret = read_frame_header(s, &gb, &width, &height)) < 0)
> +return ret;
> +
> +if (avctx->skip_frame >= AVDISCARD_NONREF && s->pict_type ==
> AV_PICTURE_TYPE_B ||
> +avctx->skip_frame >= AVDISCARD_NONKEY && s->pict_type !=
> AV_PICTURE_TYPE_I ||
> +avctx->skip_frame >= AVDISCARD_ALL)
> +return avpkt->size;
> +
> +if (s->pict_type != AV_PICTURE_TYPE_B)
> +FFSWAP(AVFrame *, s->last_frame[NEXT_PIC], s->last_frame[LAST_PIC]);
> +
> +if ((s->pict_type == AV_PICTURE_TYPE_P &&
> !s->last_frame[LAST_PIC]->data[0]) ||
> +(s->pict_type == AV_PICTURE_TYPE_B &&
> (!s->last_frame[LAST_PIC]->data[0] || !s->last_frame[NEXT_PIC]->data[0]))) {
> +av_log(s->avctx, AV_LOG_ERROR, "missing reference frame\n");
> +return AVERROR_INVALIDDATA;
> +}
> +
> +av_frame_unref(s->last_frame[CUR_PIC]);
> +
> +s->last_frame[CUR_PIC]->pict_type = s->pict_type;
> +if (s->pict_type == AV_PICTURE_TYPE_I)
> +s->last_frame[CUR_PIC]->flags |= AV_FRAME_FLAG_KEY;
> +
> +if ((ret = update_dimensions_clear_info(s, width, height)) < 0)
> +return ret;
> +
> +if ((ret = ff_reget_buffer(avctx, s->last_frame[CUR_PIC], 0)) < 0)
You just unreffed the frame above, what is the point of using
reget_buffer()?
> +return ret;
> +
> +if ((ret = read_slice_sizes(s, &gb)) < 0)
> +return ret;
> +
> +ofs = get_bits_count(&gb) / 8;
> +
> +for (int i = 0; i < s->cu_height; i++) {
> +s->slice[i].data = avpkt->data + header_size + ofs;
> +s->slice[i].data_size = FFMIN(s->slice[i].size, avpkt->size -
> header_size - ofs);
> +ofs += s->slice[i].size;
> +}
> +
> +if (ffcodec(avctx->codec)->update_thread_context)
> +ff_thread_finish_setup(avctx);
> +
> +ret = ff_slice_thread_allocz_entries(s->avctx, s->cu_height);
> +if (ret < 0)
> +return ret;
> +
> +s->avctx->execute2(s->avctx, decode_slice, s->last_frame[CUR_PIC], NULL,
> s->cu_height);
> +
> +frame->pkt_dts = avpkt->dts;
The generic code should be doing this already.
> +
> +ret = 0;
> +if (s->pict_type == AV_PICTURE_TYPE_B)
> +ret = av_frame_ref(frame, s->last_frame[CUR_PIC]);
You could change this into av_frame_move_ref() and drop the unref below.
> +else if (s->last_frame[LAST_PIC]->data[0])
> +ret = av_frame_ref(frame, s->last_frame[LAST_PIC]);
> +if (ret < 0)
> +return ret;
> +
> +if (s->last_frame[LAST_PIC]->data[0])
> +*got_frame = 1;
> +
> +if (s->pict_type != AV_PICTURE_TYPE_B)
> +FFSWAP(AVFrame *, s->last_frame[CUR_PIC], s->last_frame[NEXT_PIC]);
> +else
> +av_frame_unref(s->last_frame[CUR_PIC]);
> +
> +if (s->pict_type != AV_PICTURE_TYPE_B) {
> +s->ref_pts[0] = s->ref_pts[1];
> +s->ref_pts[1] = avpkt->pts;
> +
> +s->ref_ts[0] = s->ref_ts[1];
> +s->ref_ts[1] = s->ts;
> +
> +if (s->ref_pts[1] > s->ref_pts[0] && s->ref_ts[1] > s->ref_ts[0])
> +s->ts_scale = (s->ref_pts[1] - s->ref_pts[0]) / (s->ref_ts[1] -
> s->ref_ts[0]);
> +} else {
> +frame->pts = s->ref_pts[0] + (s->ts - s->ref_ts[0]) * s->ts_scale;
This looks immensely evil. Isn't ff_get_buffer() already setting the
timestamps correctly?
--
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] SWS cleanup / SPI Funding Suggestion
Le keskiviikkona 18. lokakuuta 2023, 0.57.45 EEST Michael Niedermayer a écrit : > On Tue, Oct 17, 2023 at 09:50:41PM +0300, Rémi Denis-Courmont wrote: > > Le perjantaina 13. lokakuuta 2023, 22.19.34 EEST Michael Niedermayer a écrit : > > > But some goals would probably be to make sws > > > * pleasent to work with > > > * similar speed or faster > > > * proper multithreading > > > * proper full colorspace convertion not ignoring gamma, primaries, ... > > > * clean / understandable modular design (maybe everything can be a > > > "Filter" > > > inside sws that get build into a chain) > > > > It sounds very nice. But it also sounds very fuzzy and subjective. Unless > > you can put this in more objective terms such as would be expected of a > > statement of work, all the while not compromising the intent of the > > sponsorship, I would advise against using foundation funds. > > What i had in mind was that the developer who wants to work on this would > provide a offer that is more clearly defined. That does not seem like a good idea, due to obvious moral hazards. > > In my opinion, not "paying properly" is morally wrong, and sets a very bad > > example that it is acceptable not to pay developers properly. > > It can be "proper" depending on where the developer is from, what she > exactly will do and how much time she will need. Also the developer may > have other sources of payment for this work or may benefit from a better > swscale directly or want to work on this volunteerly and just needs a > little extra push. You have to keep in mind that this working model is already intrinsically rather precarious (for the developer). It only gets worse if you make it underpaid and/or reliant on additional third party grants or motivation. Also if there are vested interest in getting the work done anyway, then it really should be funded by those vested interests: again, the foundation does not look like it can afford to spend much of anything in sponsored development at this time. > But IMO the really important part is a different one. Not how much money we > have in SPI from donations today. But how much we could have if we USE the > money. As long as the additional income does not become a legal liability, by all means, spend on stuff with good Return On Investment. But while I can see the appeal of revamping swscale on a technical level as a professional software engineer myself, I am very Very VERY skeptic that it would have much if any ROI in terms of donations to FFmpeg. > Why would someone donate to FFmpeg? People will donate if they are willing, able and aware. Unfortunately, since FFmpeg is predominantly a library and almost exclusive back-end software, people do not know that they can even donate, even the few that are able and willing to do so. > we have enough money for hw & travel. Sure, but that is most certainly not at the top of the list of reasons for the dearth of donations. > If we use it to improve FFmpeg suddenly there is a reason to donate and also > theres a reason for us to ask for donations. FFmpeg is nothing short of amazing as it is. Improving swscale is definitely not going to make a significant difference in that respect. > Only when we use the money and actively seek donations can we know what > amount of money would be available. If you want to actively seek donations, you need to make people aware that you want donations. In other words, you need to do marketingpublic relations. Improving swscale is NOT that. That's R&D, and it's only of immediate interest and notice to technically versed people. > Also not using the money ever is almost certainly not what the people > donating wanted. This is true. A lot of people seem to think that open-source developers are permanently teenagers working in their parents' basements, and that donations are luxurious pocket money, when it really is small change. But that does not change the fact that you simply don't have the right scale of revenue to sponsor development. > And many different developers did over the last years indicate the need for > more solid financial sustainability. Spending what little money the foundation has on a highly technical and low external visibility development project is *not* sustainable by any reasonable common acceptance of the word. When white collars utter "open-source sustainability", they mean is sustained and sustainable funding from commercial users of open-source, on a scale that is able to support ongoing development and maintenance activities. A one-shot swscale improvement project is anything but. > both SPI and FFlabs can be a parts in this. Rejecting SPI seems not wise. > Having multiple sources of funding seems a good thing. I am not rejecting SPI by principles. Certainly MediaWiki and Mozilla have at times shown that it is possible for foundation to pay their own developpers. I am rejecting SPI/FFmpeg because the revenues simply are not sufficient at t
[FFmpeg-devel] [PATCH v2 1/2] fftools/ffplay: add vulkan renderer via libplacebo
From: Zhao Zhili
---
configure | 2 +-
fftools/Makefile | 2 +
fftools/ffplay.c | 46 ++-
fftools/ffplay_renderer.c | 265 ++
fftools/ffplay_renderer.h | 38 ++
5 files changed, 347 insertions(+), 6 deletions(-)
create mode 100644 fftools/ffplay_renderer.c
create mode 100644 fftools/ffplay_renderer.h
diff --git a/configure b/configure
index 953104150f..a3b3726e2c 100755
--- a/configure
+++ b/configure
@@ -3904,7 +3904,7 @@ ffmpeg_select="aformat_filter anull_filter atrim_filter
format_filter
ffmpeg_suggest="ole32 psapi shell32"
ffplay_deps="avcodec avformat avfilter swscale swresample sdl2"
ffplay_select="crop_filter transpose_filter hflip_filter vflip_filter
rotate_filter"
-ffplay_suggest="shell32"
+ffplay_suggest="shell32 libplacebo vulkan"
ffprobe_deps="avcodec avformat"
ffprobe_suggest="shell32"
diff --git a/fftools/Makefile b/fftools/Makefile
index 56820e6bc8..3c763e3db9 100644
--- a/fftools/Makefile
+++ b/fftools/Makefile
@@ -22,6 +22,8 @@ OBJS-ffmpeg += \
fftools/sync_queue.o\
fftools/thread_queue.o \
+OBJS-ffplay += fftools/ffplay_renderer.o
+
define DOFFTOOL
OBJS-$(1) += fftools/cmdutils.o fftools/opt_common.o fftools/$(1).o
$(OBJS-$(1)-yes)
ifdef HAVE_GNU_WINDRES
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index d8c69e10bc..305d72d8b8 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -58,6 +58,7 @@
#include
#include "cmdutils.h"
+#include "ffplay_renderer.h"
#include "opt_common.h"
const char program_name[] = "ffplay";
@@ -350,6 +351,7 @@ static char *afilters = NULL;
static int autorotate = 1;
static int find_stream_info = 1;
static int filter_nbthreads = 0;
+static int enable_vulkan = 0;
/* current context */
static int is_full_screen;
@@ -362,6 +364,8 @@ static SDL_Renderer *renderer;
static SDL_RendererInfo renderer_info = {0};
static SDL_AudioDeviceID audio_dev;
+static VkRenderer *vk_renderer;
+
static const struct TextureFormatEntry {
enum AVPixelFormat format;
int texture_fmt;
@@ -954,6 +958,11 @@ static void video_image_display(VideoState *is)
SDL_Rect rect;
vp = frame_queue_peek_last(&is->pictq);
+if (vk_renderer) {
+vk_renderer_display(vk_renderer, vp->frame);
+return;
+}
+
if (is->subtitle_st) {
if (frame_queue_nb_remaining(&is->subpq) > 0) {
sp = frame_queue_peek(&is->subpq);
@@ -1289,6 +1298,8 @@ static void do_exit(VideoState *is)
}
if (renderer)
SDL_DestroyRenderer(renderer);
+if (vk_renderer)
+vk_renderer_destroy(vk_renderer);
if (window)
SDL_DestroyWindow(window);
uninit_opts();
@@ -3447,6 +3458,8 @@ static void event_loop(VideoState *cur_stream)
SDL_DestroyTexture(cur_stream->vis_texture);
cur_stream->vis_texture = NULL;
}
+if (vk_renderer)
+vk_renderer_resize(vk_renderer, screen_width,
screen_height);
case SDL_WINDOWEVENT_EXPOSED:
cur_stream->force_refresh = 1;
}
@@ -3611,6 +3624,7 @@ static const OptionDef options[] = {
{ "find_stream_info", OPT_BOOL | OPT_INPUT | OPT_EXPERT, {
&find_stream_info },
"read and decode the streams to fill missing information with
heuristics" },
{ "filter_threads", HAS_ARG | OPT_INT | OPT_EXPERT, { &filter_nbthreads },
"number of filter threads per graph" },
+{ "enable_vulkan", OPT_BOOL, { &enable_vulkan }, "enable vulkan render" },
{ NULL, },
};
@@ -3725,9 +3739,31 @@ int main(int argc, char **argv)
#ifdef SDL_HINT_VIDEO_X11_NET_WM_BYPASS_COMPOSITOR
SDL_SetHint(SDL_HINT_VIDEO_X11_NET_WM_BYPASS_COMPOSITOR, "0");
#endif
+if (enable_vulkan) {
+vk_renderer = vk_get_renderer();
+if (vk_renderer) {
+#if SDL_VERSION_ATLEAST(2, 0, 6)
+flags |= SDL_WINDOW_VULKAN;
+#endif
+} else {
+av_log(NULL, AV_LOG_WARNING, "Doesn't support vulkan renderer,
fallback to SDL renderer\n");
+enable_vulkan = 0;
+}
+}
window = SDL_CreateWindow(program_name, SDL_WINDOWPOS_UNDEFINED,
SDL_WINDOWPOS_UNDEFINED, default_width, default_height, flags);
SDL_SetHint(SDL_HINT_RENDER_SCALE_QUALITY, "linear");
-if (window) {
+if (!window) {
+av_log(NULL, AV_LOG_FATAL, "Failed to create window: %s",
SDL_GetError());
+do_exit(NULL);
+}
+
+if (vk_renderer) {
+ret = vk_renderer_create(vk_renderer, window);
+if (ret < 0) {
+av_log(NULL, AV_LOG_FATAL, "Failed to create vulkan renderer,
%s\n", av_err2str(ret));
+do_exit(NULL);
+}
+} else {
renderer = SDL_CreateRenderer(window, -1, SDL_RENDERER_ACCELERATED
| SDL_RENDER
[FFmpeg-devel] [PATCH v2 2/2] fftools/ffplay: add hwaccel decoding support
From: Zhao Zhili
---
fftools/ffplay.c | 30 ++
fftools/ffplay_renderer.c | 117 ++
2 files changed, 147 insertions(+)
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index 305d72d8b8..0f9584b57e 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -352,6 +352,7 @@ static int autorotate = 1;
static int find_stream_info = 1;
static int filter_nbthreads = 0;
static int enable_vulkan = 0;
+static const char *hwaccel = NULL;
/* current context */
static int is_full_screen;
@@ -2557,6 +2558,24 @@ static int audio_open(void *opaque, AVChannelLayout
*wanted_channel_layout, int
return spec.size;
}
+static int create_hwaccel(AVBufferRef **device_ctx)
+{
+enum AVHWDeviceType type;
+int ret;
+
+*device_ctx = NULL;
+
+if (!hwaccel)
+return 0;
+
+type = av_hwdevice_find_type_by_name(hwaccel);
+if (type == AV_HWDEVICE_TYPE_NONE)
+return AVERROR(ENOTSUP);
+
+ret = av_hwdevice_ctx_create(device_ctx, type, NULL, NULL, 0);
+return ret;
+}
+
/* open a given stream. Return 0 if OK */
static int stream_component_open(VideoState *is, int stream_index)
{
@@ -2624,6 +2643,12 @@ static int stream_component_open(VideoState *is, int
stream_index)
av_dict_set(&opts, "flags", "+copy_opaque", AV_DICT_MULTIKEY);
+if (avctx->codec_type == AVMEDIA_TYPE_VIDEO) {
+ret = create_hwaccel(&avctx->hw_device_ctx);
+if (ret < 0)
+goto fail;
+}
+
if ((ret = avcodec_open2(avctx, codec, &opts)) < 0) {
goto fail;
}
@@ -3625,6 +3650,7 @@ static const OptionDef options[] = {
"read and decode the streams to fill missing information with
heuristics" },
{ "filter_threads", HAS_ARG | OPT_INT | OPT_EXPERT, { &filter_nbthreads },
"number of filter threads per graph" },
{ "enable_vulkan", OPT_BOOL, { &enable_vulkan }, "enable vulkan render" },
+{ "hwaccel", HAS_ARG | OPT_STRING | OPT_EXPERT, { &hwaccel }, "use HW
accelerated decoding" },
{ NULL, },
};
@@ -3739,6 +3765,10 @@ int main(int argc, char **argv)
#ifdef SDL_HINT_VIDEO_X11_NET_WM_BYPASS_COMPOSITOR
SDL_SetHint(SDL_HINT_VIDEO_X11_NET_WM_BYPASS_COMPOSITOR, "0");
#endif
+if (hwaccel && !enable_vulkan) {
+av_log(NULL, AV_LOG_INFO, "Enable vulkan renderer to support
hwaccel %s\n", hwaccel);
+enable_vulkan = 1;
+}
if (enable_vulkan) {
vk_renderer = vk_get_renderer();
if (vk_renderer) {
diff --git a/fftools/ffplay_renderer.c b/fftools/ffplay_renderer.c
index 796a964a7b..bf6ad7fbaf 100644
--- a/fftools/ffplay_renderer.c
+++ b/fftools/ffplay_renderer.c
@@ -50,6 +50,12 @@ typedef struct RendererContext {
pl_tex tex[4];
pl_log vk_log;
+
+AVBufferRef *hw_device;
+AVBufferRef *hw_frame;
+int hw_failed;
+
+AVFrame *vk_frame;
} RendererContext;
static void vk_log_cb(void *log_priv, enum pl_log_level level, const char
*msg) {
@@ -133,6 +139,13 @@ static int create(VkRenderer *renderer, SDL_Window *window)
ret = AVERROR_EXTERNAL;
goto out;
}
+
+ctx->vk_frame = av_frame_alloc();
+if (!ctx->vk_frame) {
+ret = AVERROR(ENOMEM);
+goto out;
+}
+
ret = 0;
out:
@@ -140,6 +153,102 @@ out:
return ret;
}
+static int create_hw(VkRenderer *renderer, AVFrame *frame)
+{
+RendererContext *ctx = (RendererContext *)renderer;
+AVHWFramesContext *src_hw_frame = (AVHWFramesContext
*)frame->hw_frames_ctx->data;
+AVBufferRef *src_dev = src_hw_frame->device_ref;
+int ret;
+
+if (ctx->hw_failed)
+return ctx->hw_failed;
+
+if (!ctx->hw_device) {
+ret = av_hwdevice_ctx_create_derived(&ctx->hw_device,
AV_HWDEVICE_TYPE_VULKAN, src_dev, 0);
+if (ret < 0) {
+av_log(renderer, AV_LOG_ERROR, "Derive hwaccel failed, %s\n",
av_err2str(ret));
+ctx->hw_failed = ret;
+return ret;
+}
+}
+
+if (!ctx->hw_frame) {
+AVHWFramesContext *hw_frame;
+
+ctx->hw_frame = av_hwframe_ctx_alloc(ctx->hw_device);
+if (!ctx->hw_frame) {
+ctx->hw_failed = AVERROR(ENOMEM);
+return AVERROR(ENOMEM);
+}
+
+hw_frame = (AVHWFramesContext *)ctx->hw_frame->data;
+hw_frame->format = AV_PIX_FMT_VULKAN;
+hw_frame->sw_format = src_hw_frame->sw_format;
+hw_frame->width = frame->width;
+hw_frame->height = frame->height;
+
+ret = av_hwframe_ctx_init(ctx->hw_frame);
+if (ret < 0) {
+av_log(renderer, AV_LOG_ERROR, "Create hwframe context failed,
%s\n", av_err2str(ret));
+ctx->hw_failed = ret;
+return ret;
+}
+}
+
+return 0;
+}
+
+static int transfer_frame(VkRenderer *renderer, AVFrame *frame)
+{
+RendererContext *ctx = (RendererContext *)renderer;
+int ret;
+
+if (!frame->hw_frames_ctx)
+return 0;
+
+i
Re: [FFmpeg-devel] [PATCH v2 2/2] fftools/ffplay: add hwaccel decoding support
On 2023/10/19 00:55, Zhao Zhili wrote: From: Zhao Zhili --- fftools/ffplay.c | 30 ++ fftools/ffplay_renderer.c | 117 ++ 2 files changed, 147 insertions(+) With this patchset, I got a heap-use-after-free crash in vulkan decoder after seek. See ticket 10628 for ASAN information. https://trac.ffmpeg.org/ticket/10628 ___ 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] libavutil/ppc/cpu.c: check that AT_HWCAP2 is defined
On Sat, Oct 14, 2023, 23:27 Sean McGovern wrote:
> It was not introduced until glibc 2.18.
> ---
> This should fix the ppc32 FATE node.
> ---
> libavutil/ppc/cpu.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/libavutil/ppc/cpu.c b/libavutil/ppc/cpu.c
> index 96b491c716..bc8bb5f47c 100644
> --- a/libavutil/ppc/cpu.c
> +++ b/libavutil/ppc/cpu.c
> @@ -95,12 +95,15 @@ int ff_get_cpu_flags_ppc(void)
> #endif
> if (ret & AV_CPU_FLAG_VSX)
> av_assert0(ret & AV_CPU_FLAG_ALTIVEC);
> -} else if (buf[i] == AT_HWCAP2) {
> +}
> +#ifdef AT_HWCAP2 /* not introduced until glibc 2.18 */
> +else if (buf[i] == AT_HWCAP2) {
> #ifdef PPC_FEATURE2_ARCH_2_07
> if (buf[i + 1] & PPC_FEATURE2_ARCH_2_07)
> ret |= AV_CPU_FLAG_POWER8;
> #endif
> }
> +#endif /* AT_HWCAP2 */
> }
> }
>
> --
> 2.39.2
>
Ping review.
Alternatively, can the ppc32 FATE nodes be upgraded to a distribution
release with glibc 2.18 or higher?
Can I assist with that somehow?
Thanks,
Sean McGovern
___
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] trac spam
please delete: comment 14 in ticket 2104 comment 6 in ticket 2776 user "bristleback" Thanks, Michael ___ 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] avformat/mxfdec: Check klv offset
ons 2023-10-18 klockan 02:49 +0200 skrev Michael Niedermayer:
> Fixes: Assertion klv_offset >= mxf->run_in failed at
> libavformat/mxfdec.c:736
> Fixes: 62936/clusterfuzz-testcase-minimized-ffmpeg_dem_MXF_fuzzer-
> 5778404366221312.fuzz
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/mxfdec.c | 13 -
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> index 68939091e6..f2ec508b72 100644
> --- a/libavformat/mxfdec.c
> +++ b/libavformat/mxfdec.c
> @@ -458,12 +458,15 @@ static int mxf_read_sync(AVIOContext *pb, const
> uint8_t *key, unsigned size)
> return i == size;
> }
>
> -static int klv_read_packet(KLVPacket *klv, AVIOContext *pb)
> +static int klv_read_packet(MXFContext *mxf, KLVPacket *klv,
> AVIOContext *pb)
> {
> int64_t length, pos;
> if (!mxf_read_sync(pb, mxf_klv_key, 4))
> return AVERROR_INVALIDDATA;
> klv->offset = avio_tell(pb) - 4;
> + if (klv->offset < mxf->run_in)
One stray space in there which of course can be fixed when pushing
Looks OK
/Tomas
___
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] Add a 7.1.4 channel layout
Signed-off-by: Will Wolcott
---
doc/utils.texi| 2 ++
libavutil/channel_layout.c| 1 +
libavutil/channel_layout.h| 2 ++
libavutil/version.h | 2 +-
tests/ref/fate/channel_layout | 1 +
5 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/doc/utils.texi b/doc/utils.texi
index 8e8bfa76d4..c67ae6f6c6 100644
--- a/doc/utils.texi
+++ b/doc/utils.texi
@@ -715,6 +715,8 @@ FL+FR+FC+LFE+BL+BR+FLC+FRC
FL+FR+FC+LFE+FLC+FRC+SL+SR
@item 7.1(top)
FL+FR+FC+LFE+BL+BR+TFL+TFR
+@item 7.1.4
+FL+FR+FC+LFE+BL+BR+SL+SR+TFL+TFR+TBL+TBR
@item octagonal
FL+FR+FC+BL+BR+BC+SL+SR
@item cube
diff --git a/libavutil/channel_layout.c b/libavutil/channel_layout.c
index 9b581ae6b3..a2c4eff5f4 100644
--- a/libavutil/channel_layout.c
+++ b/libavutil/channel_layout.c
@@ -201,6 +201,7 @@ static const struct channel_layout_name
channel_layout_map[] = {
{ "7.1(wide)", AV_CHANNEL_LAYOUT_7POINT1_WIDE_BACK },
{ "7.1(wide-side)", AV_CHANNEL_LAYOUT_7POINT1_WIDE},
{ "7.1(top)", AV_CHANNEL_LAYOUT_7POINT1_TOP_BACK},
+{ "7.1.4", AV_CHANNEL_LAYOUT_7POINT1POINT4 },
{ "octagonal", AV_CHANNEL_LAYOUT_OCTAGONAL },
{ "cube", AV_CHANNEL_LAYOUT_CUBE},
{ "hexadecagonal", AV_CHANNEL_LAYOUT_HEXADECAGONAL },
diff --git a/libavutil/channel_layout.h b/libavutil/channel_layout.h
index ac2ddfa022..ddeff8c644 100644
--- a/libavutil/channel_layout.h
+++ b/libavutil/channel_layout.h
@@ -233,6 +233,7 @@ enum AVChannelOrder {
#define AV_CH_LAYOUT_7POINT1_WIDE
(AV_CH_LAYOUT_5POINT1|AV_CH_FRONT_LEFT_OF_CENTER|AV_CH_FRONT_RIGHT_OF_CENTER)
#define AV_CH_LAYOUT_7POINT1_WIDE_BACK
(AV_CH_LAYOUT_5POINT1_BACK|AV_CH_FRONT_LEFT_OF_CENTER|AV_CH_FRONT_RIGHT_OF_CENTER)
#define AV_CH_LAYOUT_7POINT1_TOP_BACK
(AV_CH_LAYOUT_5POINT1_BACK|AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT)
+#define AV_CH_LAYOUT_7POINT1POINT4
(AV_CH_LAYOUT_7POINT1|AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT|AV_CH_TOP_BACK_LEFT|AV_CH_TOP_BACK_RIGHT)
#define AV_CH_LAYOUT_OCTAGONAL
(AV_CH_LAYOUT_5POINT0|AV_CH_BACK_LEFT|AV_CH_BACK_CENTER|AV_CH_BACK_RIGHT)
#define AV_CH_LAYOUT_CUBE
(AV_CH_LAYOUT_QUAD|AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT|AV_CH_TOP_BACK_LEFT|AV_CH_TOP_BACK_RIGHT)
#define AV_CH_LAYOUT_HEXADECAGONAL
(AV_CH_LAYOUT_OCTAGONAL|AV_CH_WIDE_LEFT|AV_CH_WIDE_RIGHT|AV_CH_TOP_BACK_LEFT|AV_CH_TOP_BACK_RIGHT|AV_CH_TOP_BACK_CENTER|AV_CH_TOP_FRONT_CENTER|AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT)
@@ -399,6 +400,7 @@ typedef struct AVChannelLayout {
#define AV_CHANNEL_LAYOUT_7POINT1_WIDE AV_CHANNEL_LAYOUT_MASK(8,
AV_CH_LAYOUT_7POINT1_WIDE)
#define AV_CHANNEL_LAYOUT_7POINT1_WIDE_BACK AV_CHANNEL_LAYOUT_MASK(8,
AV_CH_LAYOUT_7POINT1_WIDE_BACK)
#define AV_CHANNEL_LAYOUT_7POINT1_TOP_BACK AV_CHANNEL_LAYOUT_MASK(8,
AV_CH_LAYOUT_7POINT1_TOP_BACK)
+#define AV_CHANNEL_LAYOUT_7POINT1POINT4 AV_CHANNEL_LAYOUT_MASK(12,
AV_CH_LAYOUT_7POINT1POINT4)
#define AV_CHANNEL_LAYOUT_OCTAGONAL AV_CHANNEL_LAYOUT_MASK(8,
AV_CH_LAYOUT_OCTAGONAL)
#define AV_CHANNEL_LAYOUT_CUBE AV_CHANNEL_LAYOUT_MASK(8,
AV_CH_LAYOUT_CUBE)
#define AV_CHANNEL_LAYOUT_HEXADECAGONAL AV_CHANNEL_LAYOUT_MASK(16,
AV_CH_LAYOUT_HEXADECAGONAL)
diff --git a/libavutil/version.h b/libavutil/version.h
index 4c0c545d40..279e54c394 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -79,7 +79,7 @@
*/
#define LIBAVUTIL_VERSION_MAJOR 58
-#define LIBAVUTIL_VERSION_MINOR 27
+#define LIBAVUTIL_VERSION_MINOR 28
#define LIBAVUTIL_VERSION_MICRO 100
#define LIBAVUTIL_VERSION_INT AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
diff --git a/tests/ref/fate/channel_layout b/tests/ref/fate/channel_layout
index b93f96dbb3..d49f8906d0 100644
--- a/tests/ref/fate/channel_layout
+++ b/tests/ref/fate/channel_layout
@@ -25,6 +25,7 @@ hexagonal FL+FR+FC+BL+BR+BC
7.1(wide) FL+FR+FC+LFE+BL+BR+FLC+FRC
7.1(wide-side) FL+FR+FC+LFE+FLC+FRC+SL+SR
7.1(top) FL+FR+FC+LFE+BL+BR+TFL+TFR
+7.1.4 FL+FR+FC+LFE+BL+BR+SL+SR+TFL+TFR+TBL+TBR
octagonal FL+FR+FC+BL+BR+BC+SL+SR
cube FL+FR+BL+BR+TFL+TFR+TBL+TBR
hexadecagonal FL+FR+FC+BL+BR+BC+SL+SR+TFL+TFC+TFR+TBL+TBC+TBR+WL+WR
--
2.39.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] Should setting disposition forced on a subtitle stream actually force it?
We are not currently able to force mov_text subtitles by setting -disposition:s:0 +forced or equivalent. Should this setting actually result in forced subtitles or is this a misapprehension of the meaning of this setting? Thanks ___ 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] amfenc: Use a blocking call instead of sleeping and polling
---
On 17/10/2023 18:11, Evgeny Pavlov wrote:
The reason for using av_usleep() here is that AMF API doesn’t provide an
API for explicit wait. There are two modes to get output from encoder:
1. Polling with some sleep to avoid CPU thrashing – currently used in FFmpeg
2. Set timeout parameter on AMF encoder and QueryOutput call will block
till output is available or the timeout happens.
#2 is the preferable way but it is designed more to be used with a separate
polling thread. With a single-thread approach in FFmpeg, the use of timeout
can block input submission making things slower. This is even more
pronounced when B-frames are enabled and several inputs are needed to produce
the first output.
This approach seems like it should work here? Run non-blocking until the queue
is full, then switch to blocking when you need to wait for some output.
I tried the patch enclosing (H.264 only, different proprties needed for other
codecs), but it doesn't seem to work - the test assert always hits immediately
and timing shows that QueryOutput didn't block even though the timeout should
be set? I'm probably doing something incorrect, maybe you would know how to
fix it.
The condition of this sleep is in special events (primarily when amf input
queue is full), not the core loop part. During the experiments the cpu
increasing is about 2-4% or so, not a burst.
What cases are you experimenting with?
The most problematic case I can think of is multiple encodes running
simultaneously sharing the same instance so that each one has to wait for
others to complete and therefore all queues fill up.
The busy wait will end up being the only place where it can block (since
everything else runs asynchronously), so you will peg one CPU at close to 100%
per encode running.
Thanks,
- Mark
libavcodec/amfenc.c | 22 +++---
libavcodec/amfenc.h | 1 +
2 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c
index 061859f85c..db7ddbb083 100644
--- a/libavcodec/amfenc.c
+++ b/libavcodec/amfenc.c
@@ -713,13 +713,22 @@ int ff_amf_receive_packet(AVCodecContext *avctx, AVPacket
*avpkt)
}
}
-
+block_and_wait = 0;
do {
-block_and_wait = 0;
// poll data
if (!avpkt->data && !avpkt->buf) {
+int64_t timeout = block_and_wait ? 100 : 0;
+if (timeout != ctx->output_query_timeout) {
+av_log(avctx, AV_LOG_INFO, "Set output query timeout to
%"PRId64"\n", timeout);
+AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_QUERY_TIMEOUT, timeout);
+AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_UNKNOWN, "Failed to
set output query timeout\n");
+ctx->output_query_timeout = timeout;
+}
+
res_query = ctx->encoder->pVtbl->QueryOutput(ctx->encoder, &data);
if (data) {
+av_log(avctx, AV_LOG_INFO, "QueryOutput returned with data\n");
+
// copy data to packet
AMFBuffer *buffer;
AMFGuid guid = IID_AMFBuffer();
@@ -740,7 +749,13 @@ int ff_amf_receive_packet(AVCodecContext *avctx, AVPacket
*avpkt)
data->pVtbl->Release(data);
AMF_RETURN_IF_FALSE(ctx, ret >= 0, ret, "amf_copy_buffer() failed
with error %d\n", ret);
+} else {
+av_log(avctx, AV_LOG_INFO, "QueryOutput returned with nothing
(%d)\n", res_query);
+// For testing, shouldn't hit this unless machine is otherwise
very loaded.
+av_assert0(!block_and_wait);
}
+
+block_and_wait = 0;
}
res_resubmit = AMF_OK;
if (ctx->delayed_surface != NULL) { // try to resubmit frame
@@ -769,8 +784,9 @@ int ff_amf_receive_packet(AVCodecContext *avctx, AVPacket
*avpkt)
if (query_output_data_flag == 0) {
if (res_resubmit == AMF_INPUT_FULL || ctx->delayed_drain || (ctx->eof &&
res_query != AMF_EOF) || (ctx->hwsurfaces_in_queue >= ctx->hwsurfaces_in_queue_max)) {
+av_log(avctx, AV_LOG_INFO, "Need to wait for output\n");
block_and_wait = 1;
-av_usleep(1000);
+//av_usleep(1000);
}
}
} while (block_and_wait);
diff --git a/libavcodec/amfenc.h b/libavcodec/amfenc.h
index 2dbd378ef8..64c77115b6 100644
--- a/libavcodec/amfenc.h
+++ b/libavcodec/amfenc.h
@@ -72,6 +72,7 @@ typedef struct AmfContext {
int delayed_drain;
AMFSurface *delayed_surface;
AVFrame*delayed_frame;
+int64_t output_query_timeout;
// shift dts back by max_b_frames in timing
AVFifo *timestamp_list;
--
2.39.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, o
Re: [FFmpeg-devel] [PATCH avcodec/amfenc: 10 bit support, v4, 1/3] avcodec/amfenc: Fixes the color information in the output.
On 17/10/2023 19:00, Evgeny Pavlov wrote:
On Mon, Oct 16, 2023 at 11:41 PM Mark Thompson wrote:
...
@@ -785,6 +787,41 @@ int ff_amf_receive_packet(AVCodecContext *avctx,
AVPacket *avpkt)
return ret;
}
+int ff_amf_get_color_profile(AVCodecContext *avctx)
+{
+amf_int64 color_profile = AMF_VIDEO_CONVERTER_COLOR_PROFILE_UNKNOWN;
Can you explain what this CONVERTER_COLOR_PROFILE option is actually doing?
You've passed the primaries and transfer function to AMF options later on,
but this seems to then only consider a subset of possible matrices rather
than just passing that through as well to write into the VUI metadata. Why?
(If this isn't supported by AMF then a more correct solution might be to
insert a metadata BSF to edit the correct values into the output stream
after it has been encoded.)
When RGB surface is submitted, AMF encoder not only writes VUI header but
also does color conversion. In this case CONVERTER_COLOR_PROFILE defines
color conversion matrix. This conversion may happen with shaders or inside
VCN if it is capable to do so.
These are input parameters for conversion – if conversion is involved:
AMF_VIDEO_ENCODER_INPUT_COLOR_PROFILE – for color conversion: limited
number of color spaces is supported.
AMF_VIDEO_ENCODER_INPUT_TRANSFER_CHARACTERISTIC
AMF_VIDEO_ENCODER_INPUT_COLOR_PRIMARIES
AMF_VIDEO_ENCODER_INPUT_HDR_METADATA
These are output parameters for conversion and data for VUI:
AMF_VIDEO_ENCODER_OUTPUT_COLOR_PROFILE – for VUI only, used if color
conversion is done outside of AMF
AMF_VIDEO_ENCODER_OUTPUT_TRANSFER_CHARACTERISTIC
AMF_VIDEO_ENCODER_OUTPUT_COLOR_PRIMARIES
AMF_VIDEO_ENCODER_OUTPUT_HDR_METADATA
It would be possible to add unsupported color matrices via editing VUI in
the output stream but it is better to do it via a separate patch as
supported covers most common use cases.
How does the setup you have here support the most common case, where that the
user has the input in the right format and just wants the colour properties
that they have set (primaries/transfer/matrix/range/chroma location) to be
written directly into the encoded stream?
(In most encoders this is the only case, since ad-hoc conversion of the input
like this is generally considered out-of-scope and done separately.)
+if (avctx->color_range == AVCOL_RANGE_JPEG) {
+/// Color Space for Full (JPEG) Range
+switch (avctx->colorspace) {
+case AVCOL_SPC_SMPTE170M:
+color_profile = AMF_VIDEO_CONVERTER_COLOR_PROFILE_FULL_601;
+break;
+case AVCOL_SPC_BT709:
+color_profile = AMF_VIDEO_CONVERTER_COLOR_PROFILE_FULL_709;
+break;
+case AVCOL_SPC_BT2020_NCL:
+case AVCOL_SPC_BT2020_CL:
+color_profile = AMF_VIDEO_CONVERTER_COLOR_PROFILE_FULL_2020;
+break;
+}
+} else {
+/// Color Space for Limited (MPEG) range
+switch (avctx->colorspace) {
+case AVCOL_SPC_SMPTE170M:
+color_profile = AMF_VIDEO_CONVERTER_COLOR_PROFILE_601;
+break;
+case AVCOL_SPC_BT709:
+color_profile = AMF_VIDEO_CONVERTER_COLOR_PROFILE_709;
+break;
+case AVCOL_SPC_BT2020_NCL:
+case AVCOL_SPC_BT2020_CL:
+color_profile = AMF_VIDEO_CONVERTER_COLOR_PROFILE_2020;
+break;
+}
+}
+return color_profile;
+}
+
const AVCodecHWConfigInternal *const ff_amfenc_hw_configs[] = {
#if CONFIG_D3D11VA
HW_CONFIG_ENCODER_FRAMES(D3D11, D3D11VA),
...
+pix_fmt = avctx->hw_frames_ctx ?
((AVHWFramesContext*)avctx->hw_frames_ctx->data)->sw_format
+: avctx->pix_fmt;
+if (pix_fmt == AV_PIX_FMT_P010) {
+color_depth = AMF_COLOR_BIT_DEPTH_10;
+}
+AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_HEVC_COLOR_BIT_DEPTH, color_depth);
Is this the input bit depth or the codec bit depth? (Can they be
different?)
According to AMF documentation, this property "sets the number of bits in
each pixel’s color component in the encoder’s compressed output bitstream".
We should set up correct bit depth for encoder if we have 10-bit input
Doesn't that mean it should be set based on the profile rather than the input
bit depth?
(Or, if only the input bit depth is supported then you probably want to
validate above that the profile and input bit depth actually match.)
+/// Color Transfer Characteristics (AMF matches ISO/IEC)
+AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_HEVC_OUTPUT_TRANSFER_CHARACTERISTIC,
(amf_int64)avctx->color_trc);
+/// Color Primaries (AMF matches ISO/IEC)
+AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_HEVC_OUTPUT_COLOR_PRIMARIES,
(amf_int64)avctx->color_primaries);
+
Thanks,
- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubs
Re: [FFmpeg-devel] [PATCH] ffprobe: fix XML rendering, review XML layout
On date Tuesday 2023-10-17 11:56:35 +0200, Stefano Sabatini wrote: > On date Sunday 2023-10-15 19:15:16 +0200, Michael Niedermayer wrote: > > On Sat, Oct 14, 2023 at 09:50:24PM +0200, Stefano Sabatini wrote: > > > On date Saturday 2023-10-14 19:24:28 +0200, Stefano Sabatini wrote: > > > > Fix rendering of int values within a side data element, which was > > > > broken since commit d2d3a83ad93, where the side data element was > > > > correctly marked as a variable fields element. Logic to render a > > > > string variable was implemented already, but it was not implemented > > > > for the int fields path, which was enabled by that commit. > > > [...] > > > > > > V2 with schema fixes. > > > > > > I'd like to include the fixed version with 6.1 (will probably push in > > > a few days if I see no comments). > > > > > Changelog |2 + > > > doc/ffprobe.xsd| 31 +--- > > > fftools/ffprobe.c | 49 > > > + > > > tests/ref/fate/ffprobe_xml | 26 +++ > > > > This needs to update fate references > > Yes, thanks for noticing. Tested against complete FATE, updated. Will push tomorrow or later if I see no more comments. ___ 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] ffprobe: add -output_format as an alias of -of
On date Sunday 2023-10-15 11:29:10 +0200, Stefano Sabatini wrote: > Currently we have -of and -print_format, which is a bit confusing. Add > -output_format as an alias of -of to match the short name. > --- > Changelog | 1 + > doc/ffprobe.texi | 6 +++--- > fftools/ffprobe.c | 17 + > 3 files changed, 13 insertions(+), 11 deletions(-) > > diff --git a/Changelog b/Changelog > index 259180e190..cceee46215 100644 > --- a/Changelog > +++ b/Changelog > @@ -37,6 +37,7 @@ version : > - VAAPI AV1 encoder > - ffprobe XML output schema changed to account for multiple >variable-fields elements within the same parent element > +- ffprobe -output_format option added as an alias of -of Will push tomorrow or later if I see no comments. ___ 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] doc: add spi.txt
On date Tuesday 2023-10-17 14:41:00 +0200, epira...@gmail.com wrote: > > > On 17 Oct 2023, at 9:29, Stefano Sabatini wrote: > > > On date Monday 2023-10-16 06:34:45 +0200, Lynne wrote: > >> Oct 16, 2023, 00:50 by mich...@niedermayer.cc: > >> > >>> This explains how to request refunds and what can be funded by SPI > >>> > >>> Co-Author: Stefano Sabatini > >>> --- > >>> doc/spi.txt | 73 + > >>> 1 file changed, 73 insertions(+) > >>> create mode 100644 doc/spi.txt > >>> > >>> diff --git a/doc/spi.txt b/doc/spi.txt > >>> new file mode 100644 > >>> index 00..ff4af8f42b > >>> > >> > >> Again, I think this belongs on the website, not in our codebase. > > > > Given that this is a sort of internal memo, and that is targeted at > > developers rather than final users, I see no value into exposing this > > in the website (and we have similar documents - e.g. community.texi - > > already in doc). > > > > OTOH given that this clarifies how donations are spent, there is also > > a value into making this more transparent to users/donors, but I don't > > see this as blocking (we can publish it here and then move it to the > > website once the process has been consolidated). > > IMO this would be much more discoverable on the website, it would > never occur to me to look for such information in the FFmpeg source > tree doc folder. I'm fine with either, I'll let Michael decide the final target repository. ___ 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] SWS cleanup / SPI Funding Suggestion
On date Tuesday 2023-10-17 16:58:41 +, ffmpeg-devel Mailing List wrote:
>
>
> > On Oct 17, 2023, at 7:36 AM, Michael Niedermayer
> > wrote:
> >
> > On Sat, Oct 14, 2023 at 07:53:04PM +0200, Stefano Sabatini wrote:
> >>
> >> It would be useful at this point to define the process to accept the
> >> proposal and potential candidates. We have a technical committee which
> >> might take the lead on that and probably have the last word on it,
> >> since "approved by the community" is a bit vague and there is the risk
> >> that there will be never an approval "from the community" because of
> >> diverging views, or that we get stuck at the design level.
> >
> > I think there are several shades of this
> >
> > The community might simply have a consensus that X should be funded.
> > We achieved this both for traval and hw in all or nearly all cases.
> > And quite plausibly we will achieve this too for other cases
> >
> > Hypothetically the community might have a consensus some work should
> > be funded but not agree on technical details.
> > Here honestly i think the developer doing the work should be the main
> > decission maker. She is the one doing the work, knowing the code best.
> > And most likely its one of the FFmpeg team doing the work.
>
> I think this makes sense for cases where there is easily reachable
> consensus. What happens when we can't easily reach consensus? For
> example it doesn't seem like we have consensus on funding
> improvements to swscale (compared to integrating a 3rd party
> library). Does that mean that work cannot get funded through SPI?
>
> This is where I think using the TC to make a decision where the
> community at large cannot reach consensus might be useful. It
> doesn't need to decide the fine technical points of how the work is
> done, but it can provide a useful mechanism to disagree and commit
> about whether the work should be done at all and provide the broad
> strokes (like improve swscale vs write a brand new library vs
> integrate some third party one).
+1
And we should try to prevent both later complaints ("it was decided
against my will") or block development because a single or a minority
of developers is against it.
OTOH voting/decision making should only be seeked out in case there is
some disagreement which cannot be resolved during the preliminary
discussion on list/chat, or in case there is more than one candidate
for the task.
I cannot comment about what exact party should be called out (TC vs
GA).
___
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] SWS cleanup / SPI Funding Suggestion
On date Wednesday 2023-10-18 19:30:11 +0300, Rémi Denis-Courmont wrote: > Le keskiviikkona 18. lokakuuta 2023, 0.57.45 EEST Michael Niedermayer a écrit > : > > On Tue, Oct 17, 2023 at 09:50:41PM +0300, Rémi Denis-Courmont wrote: [...] > > > What happens if more than one credible developer wants to take up the > > > project? > > > > Then 15k$ was too much > > So that's lowest bidder paradigm. Then you have to have a SoW first. See > above. This is similar to some of the issues with the GSOC program, the same amount of money can mean something very different depending on the contributors country/cost of life. So it is not really possible to make a fixed price which is fair to everyone. Possibly it should be computed depending on the country of the candidate developer depending on some economic parameter. > (...) > > Whats the worst that can happen ? > > The project fails because the terms were too vaguely defined. The GA become > even more reluctant to spend what little money FFmpeg has. Developers are > turned off from applying for sponsorship from FFmpeg. The contracted > developer > rage-quits. I can see this happening, but we cannot really predict without trying - and we can learn from failure. Another option would be to have something similar to bounties (e.g. 100$ for each bug fixed - at least this might get low-hanging fruits go away easily). Or with some more organization we migth have the equivalent of FFSOC - although this would be much more complicated to setup (since you have to check with the student status and get the economical part straight, deal with drops-out and so on). ___ 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] doc: add spi.txt
On date Wednesday 2023-10-18 23:46:48 +0200, Stefano Sabatini wrote: > On date Tuesday 2023-10-17 14:41:00 +0200, epira...@gmail.com wrote: [...] > > IMO this would be much more discoverable on the website, it would > > never occur to me to look for such information in the FFmpeg source > > tree doc folder. > > I'm fine with either, I'll let Michael decide the final target repository. OTOH more visibility for something which is not yet very well defined is not necessarily good, I'd move that to the website only when/iff the process is more consolidated. ___ 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] Add a 7.1.4 channel layout
On 10/18/2023 4:19 PM, Will Wolcott via ffmpeg-devel wrote:
Signed-off-by: Will Wolcott
---
doc/utils.texi| 2 ++
libavutil/channel_layout.c| 1 +
libavutil/channel_layout.h| 2 ++
libavutil/version.h | 2 +-
tests/ref/fate/channel_layout | 1 +
5 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/doc/utils.texi b/doc/utils.texi
index 8e8bfa76d4..c67ae6f6c6 100644
--- a/doc/utils.texi
+++ b/doc/utils.texi
@@ -715,6 +715,8 @@ FL+FR+FC+LFE+BL+BR+FLC+FRC
FL+FR+FC+LFE+FLC+FRC+SL+SR
@item 7.1(top)
FL+FR+FC+LFE+BL+BR+TFL+TFR
+@item 7.1.4
+FL+FR+FC+LFE+BL+BR+SL+SR+TFL+TFR+TBL+TBR
@item octagonal
FL+FR+FC+BL+BR+BC+SL+SR
@item cube
diff --git a/libavutil/channel_layout.c b/libavutil/channel_layout.c
index 9b581ae6b3..a2c4eff5f4 100644
--- a/libavutil/channel_layout.c
+++ b/libavutil/channel_layout.c
@@ -201,6 +201,7 @@ static const struct channel_layout_name
channel_layout_map[] = {
{ "7.1(wide)", AV_CHANNEL_LAYOUT_7POINT1_WIDE_BACK },
{ "7.1(wide-side)", AV_CHANNEL_LAYOUT_7POINT1_WIDE},
{ "7.1(top)", AV_CHANNEL_LAYOUT_7POINT1_TOP_BACK},
+{ "7.1.4", AV_CHANNEL_LAYOUT_7POINT1POINT4 },
Fyi, your client mangled the patch. It can't be applied as is.
This is introducing a new naming scheme, I assume to represent
"Loudspeaker configuration for Sound System J" from ITU-R BS.2051-3,
right? Until now we have used the definition in ITU-R BS.1196-8 for
other layouts like 7.1(top) and 22.2, so it would be a good idea to try
and come up with a common ground about how to name things from now on
(Changes to existing layouts are possible, if anything by using alias
defines).
{ "octagonal", AV_CHANNEL_LAYOUT_OCTAGONAL },
{ "cube", AV_CHANNEL_LAYOUT_CUBE},
{ "hexadecagonal", AV_CHANNEL_LAYOUT_HEXADECAGONAL },
diff --git a/libavutil/channel_layout.h b/libavutil/channel_layout.h
index ac2ddfa022..ddeff8c644 100644
--- a/libavutil/channel_layout.h
+++ b/libavutil/channel_layout.h
@@ -233,6 +233,7 @@ enum AVChannelOrder {
#define AV_CH_LAYOUT_7POINT1_WIDE
(AV_CH_LAYOUT_5POINT1|AV_CH_FRONT_LEFT_OF_CENTER|AV_CH_FRONT_RIGHT_OF_CENTER)
#define AV_CH_LAYOUT_7POINT1_WIDE_BACK
(AV_CH_LAYOUT_5POINT1_BACK|AV_CH_FRONT_LEFT_OF_CENTER|AV_CH_FRONT_RIGHT_OF_CENTER)
#define AV_CH_LAYOUT_7POINT1_TOP_BACK
(AV_CH_LAYOUT_5POINT1_BACK|AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT)
+#define AV_CH_LAYOUT_7POINT1POINT4
(AV_CH_LAYOUT_7POINT1|AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT|AV_CH_TOP_BACK_LEFT|AV_CH_TOP_BACK_RIGHT)
#define AV_CH_LAYOUT_OCTAGONAL
(AV_CH_LAYOUT_5POINT0|AV_CH_BACK_LEFT|AV_CH_BACK_CENTER|AV_CH_BACK_RIGHT)
#define AV_CH_LAYOUT_CUBE
(AV_CH_LAYOUT_QUAD|AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT|AV_CH_TOP_BACK_LEFT|AV_CH_TOP_BACK_RIGHT)
#define AV_CH_LAYOUT_HEXADECAGONAL
(AV_CH_LAYOUT_OCTAGONAL|AV_CH_WIDE_LEFT|AV_CH_WIDE_RIGHT|AV_CH_TOP_BACK_LEFT|AV_CH_TOP_BACK_RIGHT|AV_CH_TOP_BACK_CENTER|AV_CH_TOP_FRONT_CENTER|AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT)
@@ -399,6 +400,7 @@ typedef struct AVChannelLayout {
#define AV_CHANNEL_LAYOUT_7POINT1_WIDE AV_CHANNEL_LAYOUT_MASK(8,
AV_CH_LAYOUT_7POINT1_WIDE)
#define AV_CHANNEL_LAYOUT_7POINT1_WIDE_BACK AV_CHANNEL_LAYOUT_MASK(8,
AV_CH_LAYOUT_7POINT1_WIDE_BACK)
#define AV_CHANNEL_LAYOUT_7POINT1_TOP_BACK AV_CHANNEL_LAYOUT_MASK(8,
AV_CH_LAYOUT_7POINT1_TOP_BACK)
+#define AV_CHANNEL_LAYOUT_7POINT1POINT4 AV_CHANNEL_LAYOUT_MASK(12,
AV_CH_LAYOUT_7POINT1POINT4)
#define AV_CHANNEL_LAYOUT_OCTAGONAL AV_CHANNEL_LAYOUT_MASK(8,
AV_CH_LAYOUT_OCTAGONAL)
#define AV_CHANNEL_LAYOUT_CUBE AV_CHANNEL_LAYOUT_MASK(8,
AV_CH_LAYOUT_CUBE)
#define AV_CHANNEL_LAYOUT_HEXADECAGONAL AV_CHANNEL_LAYOUT_MASK(16,
AV_CH_LAYOUT_HEXADECAGONAL)
diff --git a/libavutil/version.h b/libavutil/version.h
index 4c0c545d40..279e54c394 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -79,7 +79,7 @@
*/
#define LIBAVUTIL_VERSION_MAJOR 58
-#define LIBAVUTIL_VERSION_MINOR 27
+#define LIBAVUTIL_VERSION_MINOR 28
#define LIBAVUTIL_VERSION_MICRO 100
#define LIBAVUTIL_VERSION_INT AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
diff --git a/tests/ref/fate/channel_layout b/tests/ref/fate/channel_layout
index b93f96dbb3..d49f8906d0 100644
--- a/tests/ref/fate/channel_layout
+++ b/tests/ref/fate/channel_layout
@@ -25,6 +25,7 @@ hexagonal FL+FR+FC+BL+BR+BC
7.1(wide) FL+FR+FC+LFE+BL+BR+FLC+FRC
7.1(wide-side) FL+FR+FC+LFE+FLC+FRC+SL+SR
7.1(top) FL+FR+FC+LFE+BL+BR+TFL+TFR
+7.1.4 FL+FR+FC+LFE+BL+BR+SL+SR+TFL+TFR+TBL+TBR
octagonal FL+FR+FC+BL+BR+BC+SL+SR
cube FL+FR+BL+BR+TFL+TFR+TBL+TBR
hexadecagonal FL+FR+FC+BL+BR+BC+SL+SR+TFL+TFC+TFR+TBL+TBC+TBR+WL+WR
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link
Re: [FFmpeg-devel] [PATCH v2] doc: add spi.txt
Oct 19, 2023, 00:15 by stefa...@gmail.com: > On date Wednesday 2023-10-18 23:46:48 +0200, Stefano Sabatini wrote: > >> On date Tuesday 2023-10-17 14:41:00 +0200, epira...@gmail.com wrote: >> > [...] > >> > IMO this would be much more discoverable on the website, it would >> > never occur to me to look for such information in the FFmpeg source >> > tree doc folder. >> >> I'm fine with either, I'll let Michael decide the final target repository. >> > > OTOH more visibility for something which is not yet very well defined > is not necessarily good, I'd move that to the website only when/iff > the process is more consolidated. > I think since it's not related to code, it should go on the website, if only to keep the repo clean. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 2/2] fftools/ffplay: add hwaccel decoding support
Oct 18, 2023, 19:05 by quinkbl...@foxmail.com: > > On 2023/10/19 00:55, Zhao Zhili wrote: > >> From: Zhao Zhili >> >> --- >> fftools/ffplay.c | 30 ++ >> fftools/ffplay_renderer.c | 117 ++ >> 2 files changed, 147 insertions(+) >> > > With this patchset, I got a heap-use-after-free crash in vulkan decoder after > seek. See ticket 10628 for ASAN information. > > https://trac.ffmpeg.org/ticket/10628 > Why are you reporting an issue for a patch that hasn't even been merged yet? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 2/2] fftools/ffplay: add hwaccel decoding support
> 在 2023年10月19日，上午9:31，Lynne 写道： > > Oct 18, 2023, 19:05 by quinkbl...@foxmail.com: > >> >>> On 2023/10/19 00:55, Zhao Zhili wrote: >>> >>> From: Zhao Zhili >>> >>> --- >>> fftools/ffplay.c | 30 ++ >>> fftools/ffplay_renderer.c | 117 ++ >>> 2 files changed, 147 insertions(+) >>> >> >> With this patchset, I got a heap-use-after-free crash in vulkan decoder >> after seek. See ticket 10628 for ASAN information. >> >> https://trac.ffmpeg.org/ticket/10628 >> > > Why are you reporting an issue for a patch that hasn't > even been merged yet? The issue isn’t created by this patch, but triggered by this patch. If user call libavcodec in the same way as ffplay, they can get the same result, but harder for us to reproduce. I think this is one of the reasons to let ffplay test our hardware decoders. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/2] lavc/internal: add skip_samples2 field
The issue is that avci->skip_samples will be overridden by any side-data.
When operating on raw files (adts, for example), the decoder is free
to decide the amount of samples to skip. Usually, this is the algorithmic
delay of the decoder.
When operating on more complete containers, like ISOBMFF, the amount of
samples to be skipped is recorded and signalled by the encoder.
However, it turns out many encoders have an arbitrary choice of padding
to insert at the start. Normally, they would signal the amount into
the container. But with ISOBMFF, there isn't just a single option -
the format has been extended multiple times, and has multiple ways
to signal padding. In the case of fdkaac-encoded samples, the STTS
is used, rather than the CTTS, which ends up with us leaving the padding
in.
But it's not just containers, as it turns out, most AAC encoders use
an arbitrary amount of padding at the start that may, or may not be
trimmed (usually, it won't be).
Furthermore, AAC has specific amount of algorithmic delay for SBR
operation. This delay is not accounter for anywhere. While it's an
option to skip the samples in the decoder, doing this in decode.c,
along with the rest of the skip adjustments, is a neater way, and
can be extended to other codecs.
Patch attached.
>From 9986c7f0c71d944101f1c7fe7b1395ee21e34a8e Mon Sep 17 00:00:00 2001
From: Lynne
Date: Thu, 19 Oct 2023 04:28:03 +0200
Subject: [PATCH 1/2] lavc/internal: add skip_samples2 field
The issue is that avci->skip_samples will be overridden by any side-data.
When operating on raw files (adts, for example), the decoder is free
to decide the amount of samples to skip. Usually, this is the algorithmic
delay of the decoder.
When operating on more complete containers, like ISOBMFF, the amount of
samples to be skipped is recorded and signalled by the encoder.
However, it turns out many encoders have an arbitrary choice of padding
to insert at the start. Normally, they would signal the amount into
the container. But with ISOBMFF, there isn't just a single option -
the format has been extended multiple times, and has multiple ways
to signal padding. In the case of fdkaac-encoded samples, the STTS
is used, rather than the CTTS, which ends up with us leaving the padding
in.
But it's not just containers, as it turns out, most AAC encoders use
an arbitrary amount of padding at the start that may, or may not be
trimmed (usually, it won't be).
Furthermore, AAC has specific amount of algorithmic delay for SBR
operation. This delay is not accounter for anywhere. While it's an
option to skip the samples in the decoder, doing this in decode.c,
along with the rest of the skip adjustments, is a neater way, and
can be extended to other codecs.
---
libavcodec/decode.c | 2 ++
libavcodec/internal.h | 9 +
2 files changed, 11 insertions(+)
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index ad39021354..32944a6b6a 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -338,6 +338,8 @@ static int discard_samples(AVCodecContext *avctx, AVFrame *frame, int64_t *disca
return AVERROR(EAGAIN);
}
+avci->skip_samples += avci->skip_samples2;
+
if (avci->skip_samples > 0) {
if (frame->nb_samples <= avci->skip_samples){
*discarded_samples += frame->nb_samples;
diff --git a/libavcodec/internal.h b/libavcodec/internal.h
index eb9e0d707c..3d8d4d9a4d 100644
--- a/libavcodec/internal.h
+++ b/libavcodec/internal.h
@@ -115,9 +115,18 @@ typedef struct AVCodecInternal {
/**
* Number of audio samples to skip at the start of the next decoded frame
+ *
+ * Note: This will be overridden by any side data.
*/
int skip_samples;
+/**
+ * Additional samples to skip ad the start of the next decoded frame.
+ *
+ * These will be added to any skip amount after taking side data into account.
+ */
+int skip_samples2;
+
/**
* hwaccel-specific private data
*/
--
2.42.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 2/2] aacdec: padding skip improvements
Change from the previous version: by default, the current behaviour
of the decoder is preserved. Samples to skip are zero by default.
We can improve this later.
For some reason, this was never set, which meant all **raw** AAC in ADTS
streams, except faac, had extra samples at the start.
Despite this being a standard MDCT-based codec with a frame size of 1024,
hence a delay of 1024 samples at the start, all major encoders, excluding
faac and ffmpeg, use different amounts of padding.
Patch attached.
>From 691fdb2952707fffd6975ca7a555e198236e9168 Mon Sep 17 00:00:00 2001
From: Lynne
Date: Tue, 3 Oct 2023 05:57:50 +0200
Subject: [PATCH] aacdec: padding skip improvements
For some reason, this was never set, which meant all **raw** AAC in ADTS
streams, except faac, had extra samples at the start.
Despite this being a standard MDCT-based codec with a frame size of 1024,
hence a delay of 1024 samples at the start, all major encoders, excluding
faac and FFmpeg, use 2048 samples of padding.
---
libavcodec/aac.h | 1 +
libavcodec/aacdec_template.c | 20 +++-
2 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/libavcodec/aac.h b/libavcodec/aac.h
index 285d3b7482..79bbb3cce5 100644
--- a/libavcodec/aac.h
+++ b/libavcodec/aac.h
@@ -298,6 +298,7 @@ struct AACContext {
AVCodecContext *avctx;
AVFrame *frame;
+int override_padding;
int is_saved; ///< Set if elements have stored overlap from previous frame.
DynamicRangeControl che_drc;
diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index 954399f86b..a5b46b09e3 100644
--- a/libavcodec/aacdec_template.c
+++ b/libavcodec/aacdec_template.c
@@ -1273,6 +1273,9 @@ static av_cold int aac_decode_init(AVCodecContext *avctx)
if (ret < 0)
return ret;
+/* Usually overridden by side data */
+avctx->internal->skip_samples = ac->override_padding;
+
return 0;
}
@@ -2417,14 +2420,16 @@ static int decode_dynamic_range(DynamicRangeControl *che_drc,
return n;
}
-static int decode_fill(AACContext *ac, GetBitContext *gb, int len) {
-uint8_t buf[256];
-int i, major, minor;
+static int decode_fill(AACContext *ac, GetBitContext *gb, int len)
+{
+uint8_t buf[256] = { 0 };
+int i, major, minor, micro;
if (len < 13+7*8)
goto unknown;
-get_bits(gb, 13); len -= 13;
+get_bits(gb, 13);
+len -= 13;
for(i=0; i+1=8; i++, len-=8)
buf[i] = get_bits(gb, 8);
@@ -2434,7 +2439,9 @@ static int decode_fill(AACContext *ac, GetBitContext *gb, int len) {
av_log(ac->avctx, AV_LOG_DEBUG, "FILL:%s\n", buf);
if (sscanf(buf, "libfaac %d.%d", &major, &minor) == 2){
-ac->avctx->internal->skip_samples = 1024;
+ac->avctx->internal->skip_samples -= 1024;
+} else if ((sscanf(buf, "avc %d.%d.%d", &major, &minor, µ) == 3)) {
+ac->avctx->internal->skip_samples -= 1024;
}
unknown:
@@ -3471,6 +3478,9 @@ static const AVOption options[] = {
{ "coded","order in which the channels are coded in the bitstream",
0, AV_OPT_TYPE_CONST, { .i64 = CHANNEL_ORDER_CODED }, .flags = AACDEC_FLAGS, "channel_order" },
+{ "padding", "Override the padding at the start of a stream.\n",
+offsetof(AACContext, override_padding), AV_OPT_TYPE_INT, { .i64 = 1024 }, 1024, 8192, AACDEC_FLAGS },
+
{NULL},
};
--
2.42.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 2/2] aacdec: padding skip improvements
Correct patch attached.
>From 91ff271acffdb00bb8a7ace0ae1e811770104fc2 Mon Sep 17 00:00:00 2001
From: Lynne
Date: Thu, 19 Oct 2023 04:36:12 +0200
Subject: [PATCH 2/2] aacdec: padding skip improvements
For some reason, this was never set, which meant all **raw** AAC in ADTS
streams, except faac, had extra samples at the start.
Despite this being a standard MDCT-based codec with a frame size of 1024,
hence a delay of 1024 samples at the start, all major encoders, excluding
faac and ffmpeg, use different amounts of padding.
---
libavcodec/aac.h | 1 +
libavcodec/aacdec_template.c | 20 +++-
2 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/libavcodec/aac.h b/libavcodec/aac.h
index 285d3b7482..79bbb3cce5 100644
--- a/libavcodec/aac.h
+++ b/libavcodec/aac.h
@@ -298,6 +298,7 @@ struct AACContext {
AVCodecContext *avctx;
AVFrame *frame;
+int override_padding;
int is_saved; ///< Set if elements have stored overlap from previous frame.
DynamicRangeControl che_drc;
diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index 954399f86b..d5855a4f98 100644
--- a/libavcodec/aacdec_template.c
+++ b/libavcodec/aacdec_template.c
@@ -1273,6 +1273,9 @@ static av_cold int aac_decode_init(AVCodecContext *avctx)
if (ret < 0)
return ret;
+/* Usually overridden by side data */
+avctx->internal->skip_samples2 = ac->override_padding;
+
return 0;
}
@@ -2417,14 +2420,16 @@ static int decode_dynamic_range(DynamicRangeControl *che_drc,
return n;
}
-static int decode_fill(AACContext *ac, GetBitContext *gb, int len) {
-uint8_t buf[256];
+static int decode_fill(AACContext *ac, GetBitContext *gb, int len)
+{
+uint8_t buf[256] = { 0 };
int i, major, minor;
if (len < 13+7*8)
goto unknown;
-get_bits(gb, 13); len -= 13;
+get_bits(gb, 13);
+len -= 13;
for(i=0; i+1=8; i++, len-=8)
buf[i] = get_bits(gb, 8);
@@ -2433,8 +2438,10 @@ static int decode_fill(AACContext *ac, GetBitContext *gb, int len) {
if (ac->avctx->debug & FF_DEBUG_PICT_INFO)
av_log(ac->avctx, AV_LOG_DEBUG, "FILL:%s\n", buf);
-if (sscanf(buf, "libfaac %d.%d", &major, &minor) == 2){
-ac->avctx->internal->skip_samples = 1024;
+if (!ac->override_padding) {
+if (sscanf(buf, "libfaac %d.%d", &major, &minor) == 2){
+ac->avctx->internal->skip_samples = 1024;
+}
}
unknown:
@@ -3471,6 +3478,9 @@ static const AVOption options[] = {
{ "coded","order in which the channels are coded in the bitstream",
0, AV_OPT_TYPE_CONST, { .i64 = CHANNEL_ORDER_CODED }, .flags = AACDEC_FLAGS, "channel_order" },
+{ "padding", "Override the padding at the start of a stream.\n",
+offsetof(AACContext, override_padding), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 8192, AACDEC_FLAGS },
+
{NULL},
};
--
2.42.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 v2 2/2] fftools/ffplay: add hwaccel decoding support
Oct 18, 2023, 18:55 by quinkbl...@foxmail.com: > From: Zhao Zhili > > --- > fftools/ffplay.c | 30 ++ > fftools/ffplay_renderer.c | 117 ++ > 2 files changed, 147 insertions(+) > This patch doesn't look correct, libplacebo and lavc have to share the same Vulkan device. Either create a hwcontext vulkan device and import it into libplacebo, which you would then use for decoding, or use libplacebo's context and initialize a lavu hwcontext from 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 v2 2/2] fftools/ffplay: add hwaccel decoding support
> On Oct 19, 2023, at 11:31, Lynne wrote: > > Oct 18, 2023, 18:55 by quinkbl...@foxmail.com: > >> From: Zhao Zhili >> >> --- >> fftools/ffplay.c | 30 ++ >> fftools/ffplay_renderer.c | 117 ++ >> 2 files changed, 147 insertions(+) >> > > This patch doesn't look correct, libplacebo and lavc have to > share the same Vulkan device. > Either create a hwcontext vulkan device and import it into libplacebo, > which you would then use for decoding, or use libplacebo's context and > initialize a lavu hwcontext from it. OK. Will fixed in next version. > ___ > 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".
