Re: [FFmpeg-devel] [PATCH 3/5] [mov] Check if DTS is AV_NOPTS_VALUE in mov_find_next_sample().
On Thu, May 14, 2020 at 03:31:51PM -0700, Dale Curtis wrote: > Signed-off-by: Dale Curtis > --- > libavformat/mov.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The worst form of inequality is to try to make unequal things equal. -- Aristotle 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 2/4] avformat/mpl2dec: Fix integer overflow with duration
On Mon, Jun 08, 2020 at 12:14:49PM +0200, Michael Niedermayer wrote: > Fixes: signed integer overflow: 9223372036854775807 - -1 cannot be > represented in type 'long' > Fixes: > 23167/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-6425051741290496 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavformat/mpl2dec.c | 9 ++--- > 1 file changed, 6 insertions(+), 3 deletions(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The greatest way to live with honor in this world is to be what we pretend to be. -- Socrates 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 1/4] avformat/thp: Check fps
On Mon, Jun 08, 2020 at 12:14:48PM +0200, Michael Niedermayer wrote: > Fixes: division by zero > Fixes: > 23162/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-4856420817436672 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavformat/thp.c | 2 ++ > 1 file changed, 2 insertions(+) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The misfortune of the wise is better than the prosperity of the fool. -- Epicurus 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 3/3] avcodec/loco: Fix signed integer overflow in loco_get_rice()
On Tue, Jun 09, 2020 at 10:55:05PM +0200, Michael Niedermayer wrote: > Fixes: signed integer overflow: 2147483647 + 1 cannot be represented in type > 'int' > Fixes: > 22975/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_LOCO_fuzzer-5658160970072064 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/loco.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Complexity theory is the science of finding the exact solution to an approximation. Benchmarking OTOH is finding an approximation of the exact 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] avfilter/vf_chromakey: The chromakey filter preserves non-opaque alpha transparency.
On 12/06/2020 16:58, Gavin Smith wrote: On 12/06/2020 12:59, Timo Rothenpieler wrote: On 12.06.2020 00:31, Gavin Smith wrote: On 11/06/2020 22:03, Timo Rothenpieler wrote: On 11.06.2020 22:27, Gavin Smith wrote: This is to address trac ticket #8724. The filter did not preserve alpha transparency. Items that were transparent in the input would appear black on the output or pixels that were semi-tranparent would appear opaque. What is the performance impact for inputs without an alpha channel? Firstly, I'm new to this world of filters. Now my patch only applies to chromakey and not chromahold. On that note, is it not the case that the chromakey mandates that all its inputs surfaces contain alpha (as per query_formats function)? Would any AVPixelFormat that does not match query_formats get converted to a format containing alpha transparency? But it still adds new code, and given it's in the very hot path of the filter, it can easily add a performance penalty. Sure. I understand. I'll see what numbers I can get. Having a quick cursory look over the code, I wonder if my code actually might be slightly more performant because it checks the case if a0 != 0. However, this jmp/cmp may negatively impact performance. vf_chromakey wll now have 2 implementations of chromakey depending on whether "use_alpha" is selected. What are your feelings on the best way to approach this? 1. Add an additional function pointer to ChromakeyContext: In do_chromakey_slice(..), call the said func ptr in the loop each iteration? 2. Add a conditional to do_chromakey_slice(...): In the loop iteration, check "use_alpha" variable and execute and jmp to pertinent code? 3. Any other suggestions? Thanks. Generally looks fine to me, but might need hidden behind an option, as to not break existing setups that rely on this filter discarding/ignoring the input alpha channel. Yes. No problem. "preserve_transparency" and default to the equivalent of 'false'? That seems a bit clunky. Maybe something like "use_alpha"? Sure. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/3] avcodec/wmalosslessdec: Check block_align maximum
On Tue, Jun 09, 2020 at 10:55:04PM +0200, Michael Niedermayer wrote: > Fixes: Assertion failure > Fixes: > 22737/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WMALOSSLESS_fuzzer-595839681920 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/wmalosslessdec.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If the United States is serious about tackling the national security threats related to an insecure 5G network, it needs to rethink the extent to which it values corporate profits and government espionage over security.-Bruce Schneier 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/cbs: use av_fast_realloc() in cbs_insert_unit()
On Sat, May 02, 2020 at 01:45:43PM -0300, James Almer wrote: > On 5/2/2020 1:39 PM, Michael Niedermayer wrote: > > On Sat, Apr 11, 2020 at 11:01:41AM -0300, James Almer wrote: > >> Fixes: Timeout > >> Fixes: > >> 20791/clusterfuzz-testcase-minimized-ffmpeg_BSF_AV1_FRAME_SPLIT_fuzzer-5659537719951360 > >> Fixes: > >> 21214/clusterfuzz-testcase-minimized-ffmpeg_BSF_MPEG2_METADATA_fuzzer-5165560875974656 > >> Fixes: > >> 21247/clusterfuzz-testcase-minimized-ffmpeg_BSF_H264_METADATA_fuzzer-5715175257931776 > >> > >> Found-by: continuous fuzzing process > >> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > >> Signed-off-by: James Almer > >> --- > >> This can be ported to av_fast_realloc_array() once that's committed. > >> > >> libavcodec/cbs.c | 37 - > >> libavcodec/cbs.h | 7 +++ > >> 2 files changed, 23 insertions(+), 21 deletions(-) > > > > Not sure we decided on which fix to push, but something > > should be applied > > > > thx > > Mark had some comments and it seemed he preferred your approach in > "avcodec/cbs: Allocate more CodedBitstreamUnit at once in > cbs_insert_unit()", but not sure if he was expecting some changes or > not, so unless av_fast_realloc_array() by Andreas is committed and then > used here, feel free to push your patch instead. will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB There will always be a question for which you do not know the correct answer. 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] codec_desc: mark CFHD as intra-only
On 6/12/2020 7:05 AM, Anton Khirnov wrote: > Quoting James Almer (2020-06-10 14:46:21) >> On 6/10/2020 6:19 AM, Anton Khirnov wrote: >>> Quoting James Almer (2020-06-09 14:45:33) On 6/9/2020 6:06 AM, Anton Khirnov wrote: > I don't think this needs to be visible externally, since it's only > meaningful for internal use. I'm wondering if the presence of > update_thread_context() callback won't be sufficient for this. True, it could be a caps_internal. But take for example the possibility of an external library with a fully featured decoder getting a wrapper, this being a public capability would let the user choose it over the internal one, same as how it can choose a stable decoder over an experimental one, or a software one over an hybrid/hw one. >>> >>> I don't see why this should be a criterium for the user to base any >>> decisions on. It's purely an internal implementation detail that's tied >>> to the way frame threading is currently implemented and can potentially >>> change later. So I don't see why it should be accessible through the >>> API. >> >> An intra only decoder returns I frames only. A fully feature decoder >> would return I and P (and actually get you something other than a key >> frame slideshow). Or at least that's how i understood it. >> Giving the user a way to choose the best decoder for their needs is not >> too crazy. We already do with other implementation specific >> capabilities, as i mentioned above. >> >>> >>> Also, not sure if you saw but I have new patch fixing this problem in >>> another manner. >> >> Yes, i saw. I'm arguing about this other approach because if it's done >> now, it can be done seamlessly (Just revert the change and pretend the >> flag was never deprecated). After 4.3 is effectively tagged, we would >> require to undo the deprecation with another API change, and it will >> look messy. >> >> The flag was meaningless and a duplicate of the codec prop, but now we >> found a way to use it to actually convey information about a decoder, so >> why not do it? > > It still seems to me that this is a solution in search of a problem. If > I understand you correctly, the case you have in mind is a codec where > there is an internal implementation that only supports intra frames > and an external implementation that also supports inter frames. > But that seems incredibly contrived to me. For one thing, I don't know > of any actual situations like this, now or in the past. What do you think prompted the whole issue with the intra-only flag used for cfhd if not the fact the internal decoder is intra only when the codec itself isn't? > For another, why > pick out specifically the ability to decode intra vs inter frames? Because the flag already exists. I wouldn't suggest to introduce it if it didn't. I'm saying it could be easily and seamlessly repurposed. Anyway, no point arguing about something as obscure as this scenario (Of which only one case exists, as stated by Kieran, and it's a matter of merging an old gsoc patch to render it moot), so i'm not going to insist on it. I already approved your alternate solution for the threading issue, for that matter. > There is a huge number of codec features that may be potentially > unsupported by various implementations (see e.g. AAC) and there's no > sane way we can have capability flags for them all. > ___ 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/sccdec: split line with multiple subs
Signed-off-by: Paul B Mahol
---
libavformat/sccdec.c | 35 +--
1 file changed, 33 insertions(+), 2 deletions(-)
diff --git a/libavformat/sccdec.c b/libavformat/sccdec.c
index b9042b39ac..bf0e6c2688 100644
--- a/libavformat/sccdec.c
+++ b/libavformat/sccdec.c
@@ -83,6 +83,7 @@ static int scc_read_header(AVFormatContext *s)
char *saveptr = NULL, *lline;
int hh1, mm1, ss1, fs1, i;
int hh2, mm2, ss2, fs2;
+int po1, po2, ppo1, ppo2;
AVPacket *sub;
if (count == 0) {
@@ -117,21 +118,51 @@ try_again:
lline = (char *)
lline += 12;
+po1 = -1, po2 = -1, ppo1 = -1, ppo2 = -1;
for (i = 0; i < 4095; i += 3) {
char *ptr = av_strtok(lline, " ", );
char c1, c2, c3, c4;
+uint8_t o1, o2;
if (!ptr)
break;
if (av_sscanf(ptr, "%c%c%c%c", , , , ) != 4)
break;
+o1 = convert(c2) | (convert(c1) << 4);
+o2 = convert(c4) | (convert(c3) << 4);
+
+if (o1 == 0x94 && o2 == 0x2f &&
+po1 == 0x94 && po2 == 0x2c &&
+ppo1 == 0x94 && ppo2 == 0x20) {
+int64_t duration;
+
+out[i] = 0;
+duration = i * 11;
+
+sub = ff_subtitles_queue_insert(>q, out, i, 0);
+if (!sub)
+return AVERROR(ENOMEM);
+
+sub->pos = current_pos + i;
+sub->pts = ts_start;
+sub->duration = duration;
+
+ts_start += duration;
+i = 0;
+}
lline = NULL;
out[i+0] = 0xfc;
-out[i+1] = convert(c2) | (convert(c1) << 4);
-out[i+2] = convert(c4) | (convert(c3) << 4);
+out[i+1] = o1;
+out[i+2] = o2;
+
+ppo1 = po1;
+ppo2 = po2;
+po1 = o1;
+po2 = o2;
}
+
out[i] = 0;
sub = ff_subtitles_queue_insert(>q, out, i, 0);
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 1/3] lavu/pix_fmt: add new pixel format x2rgb10
Jun 11, 2020, 17:26 by d...@lynne.ee: > Jun 2, 2020, 08:30 by fei.w.w...@intel.com: > >> >> >>> -Original Message- >>> From: ffmpeg-devel On Behalf Of Wang, >>> Fei W >>> Sent: Friday, May 15, 2020 2:58 PM >>> To: FFmpeg development discussions and patches >>> Subject: Re: [FFmpeg-devel] [PATCH v2 1/3] lavu/pix_fmt: add new pixel >>> format x2rgb10 >>> >>> >>> > -Original Message- >>> > From: ffmpeg-devel On Behalf Of >>> > Lynne >>> > Sent: Wednesday, May 13, 2020 7:19 AM >>> > To: FFmpeg development discussions and patches >> > de...@ffmpeg.org> >>> > Subject: Re: [FFmpeg-devel] [PATCH v2 1/3] lavu/pix_fmt: add new pixel >>> > format x2rgb10 >>> > >>> > May 12, 2020, 23:42 by s...@jkqxz.net: >>> > >>> > > On 12/05/2020 22:42, Lynne wrote: >>> > > >>> > >> Apr 22, 2020, 06:28 by fei.w.w...@intel.com: >>> > >> >>> > -Original Message- >>> > From: Wang, Fei W >>> > Sent: Wednesday, April 22, 2020 1:23 PM >>> > To: ffmpeg-devel@ffmpeg.org >>> > Cc: Wang, Fei W >>> > Subject: [PATCH v2 1/3] lavu/pix_fmt: add new pixel format >>> > x2rgb10 >>> > >>> > The format is packed RGB with each channel 10 bits available and >>> > include 2 bits unused. >>> > >>> > Signed-off-by: Fei Wang >>> > >>> > >> >>> > >> Ping on this patch? I kind of need it to support 10 bit Vulkan >>> > >> sw_formats. >>> > >> I'm happy with the name as-is. >>> > >> >>> > > >>> > > Yes, but we probably need to reach a consensus on whether we are >>> > accepting the addition of these V210-like packed formats first - there >>> > were voices against it last time this was raised. >>> > > >>> > > I am in favour of allowing it because it is a common buffer format >>> > > used in >>> > both graphics and display hardware, and appears in pretty much all >>> > related APIs (OpenGL, OpenCL, Vulkan, KMS, D3D). >>> > > >>> > >>> > Same. With it, we would be able to support kmsgrab from 10bit >>> > displays, which are becoming more and more popular. >>> Glad to know this format can be used for Vulkan 10bit display. Sounds like >>> this >>> format can bring more benefit to ffmpeg. Ping for other comments. >>> >> Hi Kindly ping, is there any other concern of this format? Tks. >> > > Planning to push this tomorrow so I can start working on supporting it in > Vulkan. > Pushed. Thanks for adding swscale support for it as well, it makes debugging easier. ___ 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] avfilter/vf_chromakey: The chromakey filter preserves non-opaque alpha transparency.
On 12/06/2020 12:59, Timo Rothenpieler wrote: On 12.06.2020 00:31, Gavin Smith wrote: On 11/06/2020 22:03, Timo Rothenpieler wrote: On 11.06.2020 22:27, Gavin Smith wrote: This is to address trac ticket #8724. The filter did not preserve alpha transparency. Items that were transparent in the input would appear black on the output or pixels that were semi-tranparent would appear opaque. What is the performance impact for inputs without an alpha channel? Firstly, I'm new to this world of filters. Now my patch only applies to chromakey and not chromahold. On that note, is it not the case that the chromakey mandates that all its inputs surfaces contain alpha (as per query_formats function)? Would any AVPixelFormat that does not match query_formats get converted to a format containing alpha transparency? But it still adds new code, and given it's in the very hot path of the filter, it can easily add a performance penalty. Sure. I understand. I'll see what numbers I can get. Having a quick cursory look over the code, I wonder if my code actually might be slightly more performant because it checks the case if a0 != 0. However, this jmp/cmp may negatively impact performance. Generally looks fine to me, but might need hidden behind an option, as to not break existing setups that rely on this filter discarding/ignoring the input alpha channel. Yes. No problem. "preserve_transparency" and default to the equivalent of 'false'? That seems a bit clunky. Maybe something like "use_alpha"? Sure. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] lavdevice: Add AudioToolbox output device.
Am 08.06.20 um 21:45 schrieb Thilo Borgmann: > $subject, v3. If there are no more comments I'll push this next week. -Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC PATCH] libavcodec/libopenjpeg: pix fmt selection change
On Thu, Jun 11, 2020 at 9:41 PM Michael Bradshaw wrote: > > On Thu, Jun 11, 2020 at 9:42 AM Gautam Ramakrishnan > wrote: > > > Got it. In that case we can safely ignore the patch to fix libopenjpeg. > > However, p1_03.j2k is one of the 2 files to have ppm marker. How could I > > validate a patch to add ppm marker? I need something to cross validate. > > Any suggestions for that? > > > Does the other file with a ppm marker have a sane pixel format? If not the > only the only way I can think of to test this is to hack ffmpeg to remap > the planes in libopenjpegdec.c (e.g., remap them to yuva format). You can > use that for initial validation but it'll have to be reverted when > committing/pushing. > > Long-term I'm not sure how one would regression test this without having a > different file with a sane pixel format. I'm not sure how feasible it is to > hack p1_03.j2k to remove a plane while retaining the ppm marker or perhaps > hacking opj_compress to add a ppm marker to a new test file. > ___ > 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". The other image with a PPM marker has only 3 components. I guess it will be a recognized format. However, it has a marker which is not yet implemented in the native decoder. I guess I'll just implement the other feature and we will be able to test this as well. -- - Gautam | ___ 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: add D2TS, TS2D, TS2T as a common macro in internal.h
From: Limin Wang
Signed-off-by: Limin Wang
---
libavfilter/aeval.c | 2 --
libavfilter/af_volume.c | 4
libavfilter/f_select.c| 3 ---
libavfilter/f_sendcmd.c | 3 ---
libavfilter/internal.h| 4
libavfilter/setpts.c | 4
libavfilter/vf_delogo.c | 1 -
libavfilter/vf_eq.c | 2 --
libavfilter/vf_hue.c | 3 ---
libavfilter/vf_rotate.c | 2 --
libavfilter/vf_scale.c| 2 --
libavfilter/vf_vignette.c | 3 ---
12 files changed, 4 insertions(+), 29 deletions(-)
diff --git a/libavfilter/aeval.c b/libavfilter/aeval.c
index 32cd6de..855dc00 100644
--- a/libavfilter/aeval.c
+++ b/libavfilter/aeval.c
@@ -416,8 +416,6 @@ static int aeval_config_output(AVFilterLink *outlink)
return 0;
}
-#define TS2T(ts, tb) ((ts) == AV_NOPTS_VALUE ? NAN : (double)(ts)*av_q2d(tb))
-
static int filter_frame(AVFilterLink *inlink, AVFrame *in)
{
EvalContext *eval = inlink->dst->priv;
diff --git a/libavfilter/af_volume.c b/libavfilter/af_volume.c
index 213c571..5fc00d8 100644
--- a/libavfilter/af_volume.c
+++ b/libavfilter/af_volume.c
@@ -335,10 +335,6 @@ static int process_command(AVFilterContext *ctx, const
char *cmd, const char *ar
return ret;
}
-#define D2TS(d) (isnan(d) ? AV_NOPTS_VALUE : (int64_t)(d))
-#define TS2D(ts) ((ts) == AV_NOPTS_VALUE ? NAN : (double)(ts))
-#define TS2T(ts, tb) ((ts) == AV_NOPTS_VALUE ? NAN : (double)(ts)*av_q2d(tb))
-
static int filter_frame(AVFilterLink *inlink, AVFrame *buf)
{
AVFilterContext *ctx = inlink->dst;
diff --git a/libavfilter/f_select.c b/libavfilter/f_select.c
index 755e10a..92938c3 100644
--- a/libavfilter/f_select.c
+++ b/libavfilter/f_select.c
@@ -325,9 +325,6 @@ static double get_concatdec_select(AVFrame *frame, int64_t
pts)
return NAN;
}
-#define D2TS(d) (isnan(d) ? AV_NOPTS_VALUE : (int64_t)(d))
-#define TS2D(ts) ((ts) == AV_NOPTS_VALUE ? NAN : (double)(ts))
-
static void select_frame(AVFilterContext *ctx, AVFrame *frame)
{
SelectContext *select = ctx->priv;
diff --git a/libavfilter/f_sendcmd.c b/libavfilter/f_sendcmd.c
index 0ac87e0..6b02669 100644
--- a/libavfilter/f_sendcmd.c
+++ b/libavfilter/f_sendcmd.c
@@ -475,9 +475,6 @@ static av_cold void uninit(AVFilterContext *ctx)
av_freep(>intervals);
}
-#define TS2D(ts) ((ts) == AV_NOPTS_VALUE ? NAN : (double)(ts))
-#define TS2T(ts, tb) ((ts) == AV_NOPTS_VALUE ? NAN : (double)(ts)*av_q2d(tb))
-
static int filter_frame(AVFilterLink *inlink, AVFrame *ref)
{
AVFilterContext *ctx = inlink->dst;
diff --git a/libavfilter/internal.h b/libavfilter/internal.h
index abe7537..6cb601f 100644
--- a/libavfilter/internal.h
+++ b/libavfilter/internal.h
@@ -234,6 +234,10 @@ void ff_avfilter_link_set_out_status(AVFilterLink *link,
int status, int64_t pts
void ff_command_queue_pop(AVFilterContext *filter);
+#define D2TS(d) (isnan(d) ? AV_NOPTS_VALUE : (int64_t)(d))
+#define TS2D(ts) ((ts) == AV_NOPTS_VALUE ? NAN : (double)(ts))
+#define TS2T(ts, tb) ((ts) == AV_NOPTS_VALUE ? NAN : (double)(ts) * av_q2d(tb))
+
/* misc trace functions */
#define FF_TPRINTF_START(ctx, func) ff_tlog(NULL, "%-16s: ", #func)
diff --git a/libavfilter/setpts.c b/libavfilter/setpts.c
index c7c3836..6506653 100644
--- a/libavfilter/setpts.c
+++ b/libavfilter/setpts.c
@@ -142,10 +142,6 @@ static int config_input(AVFilterLink *inlink)
return 0;
}
-#define D2TS(d) (isnan(d) ? AV_NOPTS_VALUE : (int64_t)(d))
-#define TS2D(ts) ((ts) == AV_NOPTS_VALUE ? NAN : (double)(ts))
-#define TS2T(ts, tb) ((ts) == AV_NOPTS_VALUE ? NAN : (double)(ts)*av_q2d(tb))
-
#define BUF_SIZE 64
static inline char *double2int64str(char *buf, double v)
diff --git a/libavfilter/vf_delogo.c b/libavfilter/vf_delogo.c
index e55673d..6069c30 100644
--- a/libavfilter/vf_delogo.c
+++ b/libavfilter/vf_delogo.c
@@ -55,7 +55,6 @@ enum var_name {
VAR_T,
VAR_VARS_NB
};
-#define TS2T(ts, tb) ((ts) == AV_NOPTS_VALUE ? NAN : (double)(ts) * av_q2d(tb))
static int set_expr(AVExpr **pexpr, const char *expr, const char *option, void
*log_ctx)
{
diff --git a/libavfilter/vf_eq.c b/libavfilter/vf_eq.c
index c8c3d5b..114781f 100644
--- a/libavfilter/vf_eq.c
+++ b/libavfilter/vf_eq.c
@@ -249,8 +249,6 @@ static int query_formats(AVFilterContext *ctx)
return ff_set_common_formats(ctx, fmts_list);
}
-#define TS2T(ts, tb) ((ts) == AV_NOPTS_VALUE ? NAN : (double)(ts) * av_q2d(tb))
-
static int filter_frame(AVFilterLink *inlink, AVFrame *in)
{
AVFilterContext *ctx = inlink->dst;
diff --git a/libavfilter/vf_hue.c b/libavfilter/vf_hue.c
index b75ef21..1499c05 100644
--- a/libavfilter/vf_hue.c
+++ b/libavfilter/vf_hue.c
@@ -363,9 +363,6 @@ static void apply_lut10(HueContext *s,
}
}
-#define TS2D(ts) ((ts) == AV_NOPTS_VALUE ? NAN : (double)(ts))
-#define TS2T(ts, tb) ((ts) == AV_NOPTS_VALUE ? NAN : (double)(ts) * av_q2d(tb))
-
static int filter_frame(AVFilterLink *inlink, AVFrame *inpic)
{
HueContext *hue = inlink->dst->priv;
diff --git
[FFmpeg-devel] [PATCH 1/2] avformat/dvenc: return error code of dv_assemble_frame()
From: Limin Wang
Signed-off-by: Limin Wang
---
libavformat/dvenc.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavformat/dvenc.c b/libavformat/dvenc.c
index c71e532..b04d604 100644
--- a/libavformat/dvenc.c
+++ b/libavformat/dvenc.c
@@ -406,9 +406,10 @@ static int dv_write_packet(struct AVFormatContext *s,
AVPacket *pkt)
fsize = dv_assemble_frame(s, s->priv_data, s->streams[pkt->stream_index],
pkt->data, pkt->size, );
-if (fsize > 0) {
-avio_write(s->pb, frame, fsize);
+if (fsize < 0) {
+return fsize;
}
+avio_write(s->pb, frame, fsize);
return 0;
}
--
1.8.3.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/7] avfilter: add ff_inlink_peek_samples and ff_inlink_skip samples
On 6/12/20, Paul B Mahol wrote: > On 6/12/20, Nicolas George wrote: >> Paul B Mahol (12020-06-12): >>> This is needed also by showspectrumpic filter and it needs random number >>> of >>> samples to skip and peek. >> >> I looked at the code for showspectrumpic before making my comment: the >> second part of your statement does not seem accurate. > > How so? Its purely random. Got no answer, will apply. > >> >> -- >> 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] avfilter/vf_chromakey: The chromakey filter preserves non-opaque alpha transparency.
On 12.06.2020 00:31, Gavin Smith wrote: On 11/06/2020 22:03, Timo Rothenpieler wrote: On 11.06.2020 22:27, Gavin Smith wrote: This is to address trac ticket #8724. The filter did not preserve alpha transparency. Items that were transparent in the input would appear black on the output or pixels that were semi-tranparent would appear opaque. What is the performance impact for inputs without an alpha channel? Firstly, I'm new to this world of filters. Now my patch only applies to chromakey and not chromahold. On that note, is it not the case that the chromakey mandates that all its inputs surfaces contain alpha (as per query_formats function)? Would any AVPixelFormat that does not match query_formats get converted to a format containing alpha transparency? But it still adds new code, and given it's in the very hot path of the filter, it can easily add a performance penalty. Generally looks fine to me, but might need hidden behind an option, as to not break existing setups that rely on this filter discarding/ignoring the input alpha channel. Yes. No problem. "preserve_transparency" and default to the equivalent of 'false'? That seems a bit clunky. Maybe something like "use_alpha"? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v3 7/7] avcodec/adpcmenc: cleanup trellis checks
Signed-off-by: Zane van Iperen
---
libavcodec/adpcmenc.c | 35 ++-
1 file changed, 18 insertions(+), 17 deletions(-)
diff --git a/libavcodec/adpcmenc.c b/libavcodec/adpcmenc.c
index d2d90b9176..38cd8add3e 100644
--- a/libavcodec/adpcmenc.c
+++ b/libavcodec/adpcmenc.c
@@ -72,25 +72,26 @@ static av_cold int adpcm_encode_init(AVCodecContext *avctx)
return AVERROR(EINVAL);
}
-if (avctx->trellis && (unsigned)avctx->trellis > 16U) {
-av_log(avctx, AV_LOG_ERROR, "invalid trellis size\n");
-return AVERROR(EINVAL);
-}
+if (avctx->trellis) {
+int frontier, max_paths;
-if (avctx->trellis &&
- (avctx->codec->id == AV_CODEC_ID_ADPCM_IMA_SSI ||
-avctx->codec->id == AV_CODEC_ID_ADPCM_IMA_APM)) {
-/*
- * The current trellis implementation doesn't work for extended
- * runs of samples without periodic resets. Disallow it.
- */
-av_log(avctx, AV_LOG_ERROR, "trellis not supported\n");
-return AVERROR_PATCHWELCOME;
-}
+if ((unsigned)avctx->trellis > 16U) {
+av_log(avctx, AV_LOG_ERROR, "invalid trellis size\n");
+return AVERROR(EINVAL);
+}
-if (avctx->trellis) {
-int frontier = 1 << avctx->trellis;
-int max_paths = frontier * FREEZE_INTERVAL;
+if (avctx->codec->id == AV_CODEC_ID_ADPCM_IMA_SSI ||
+avctx->codec->id == AV_CODEC_ID_ADPCM_IMA_APM) {
+/*
+ * The current trellis implementation doesn't work for extended
+ * runs of samples without periodic resets. Disallow it.
+ */
+av_log(avctx, AV_LOG_ERROR, "trellis not supported\n");
+return AVERROR_PATCHWELCOME;
+}
+
+frontier = 1 << avctx->trellis;
+max_paths = frontier * FREEZE_INTERVAL;
FF_ALLOC_OR_GOTO(avctx, s->paths,
max_paths * sizeof(*s->paths), error);
FF_ALLOC_OR_GOTO(avctx, s->node_buf,
--
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 v3 6/7] fate: add adpcm_ima_apm encoding test
Signed-off-by: Zane van Iperen --- tests/fate/acodec.mak | 2 ++ tests/ref/acodec/adpcm-ima_apm | 4 2 files changed, 6 insertions(+) create mode 100644 tests/ref/acodec/adpcm-ima_apm diff --git a/tests/fate/acodec.mak b/tests/fate/acodec.mak index bb6bfe5ada..197b6ed7c0 100644 --- a/tests/fate/acodec.mak +++ b/tests/fate/acodec.mak @@ -45,6 +45,7 @@ fate-acodec-pcm-u%le: FMT = nut fate-acodec-pcm-f%be: FMT = au FATE_ACODEC_ADPCM-$(call ENCDEC, ADPCM_ADX, ADX) += adx +FATE_ACODEC_ADPCM-$(call ENCDEC, ADPCM_IMA_APM, APM) += ima_apm FATE_ACODEC_ADPCM-$(call ENCDEC, ADPCM_IMA_QT, AIFF) += ima_qt FATE_ACODEC_ADPCM-$(call ENCDEC, ADPCM_IMA_SSI, KVAG) += ima_ssi FATE_ACODEC_ADPCM-$(call ENCDEC, ADPCM_IMA_WAV, WAV) += ima_wav @@ -59,6 +60,7 @@ fate-acodec-adpcm: $(FATE_ACODEC_ADPCM) fate-acodec-adpcm-%: CODEC = adpcm_$(@:fate-acodec-adpcm-%=%) fate-acodec-adpcm-adx: FMT = adx +fate-acodec-adpcm-ima_apm: FMT = apm fate-acodec-adpcm-ima_qt: FMT = aiff fate-acodec-adpcm-ima_ssi: FMT = kvag fate-acodec-adpcm-ima_wav: FMT = wav diff --git a/tests/ref/acodec/adpcm-ima_apm b/tests/ref/acodec/adpcm-ima_apm new file mode 100644 index 00..83bd21f831 --- /dev/null +++ b/tests/ref/acodec/adpcm-ima_apm @@ -0,0 +1,4 @@ +2e795c6c06baabe01ab92864d963e71b *tests/data/fate/acodec-adpcm-ima_apm.apm +264700 tests/data/fate/acodec-adpcm-ima_apm.apm +201607bf7610f062b9a1e6524354c569 *tests/data/fate/acodec-adpcm-ima_apm.out.wav +stddev: 904.76 PSNR: 37.20 MAXDIFF:34029 bytes: 1058400/ 1058400 -- 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 v3 5/7] avformat: add apm muxer
Signed-off-by: Zane van Iperen
---
Changelog| 1 +
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/apm.c| 110 ++-
libavformat/version.h| 2 +-
5 files changed, 112 insertions(+), 3 deletions(-)
diff --git a/Changelog b/Changelog
index 3c82f2ebd6..1f5250bb35 100644
--- a/Changelog
+++ b/Changelog
@@ -78,6 +78,7 @@ version 4.3:
- PFM decoder
- dblur video filter
- Real War KVAG muxer
+- Rayman 2 APM muxer
version 4.2:
diff --git a/libavformat/Makefile b/libavformat/Makefile
index bb09dc6563..a2691cb626 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -94,6 +94,7 @@ OBJS-$(CONFIG_ANM_DEMUXER) += anm.o
OBJS-$(CONFIG_APC_DEMUXER) += apc.o
OBJS-$(CONFIG_APE_DEMUXER) += ape.o apetag.o img2.o
OBJS-$(CONFIG_APM_DEMUXER) += apm.o
+OBJS-$(CONFIG_APM_MUXER) += apm.o rawenc.o
OBJS-$(CONFIG_APNG_DEMUXER) += apngdec.o
OBJS-$(CONFIG_APNG_MUXER)+= apngenc.o
OBJS-$(CONFIG_APTX_DEMUXER) += aptxdec.o rawdec.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index a7c5c9db89..0c8788ef42 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -55,6 +55,7 @@ extern AVInputFormat ff_anm_demuxer;
extern AVInputFormat ff_apc_demuxer;
extern AVInputFormat ff_ape_demuxer;
extern AVInputFormat ff_apm_demuxer;
+extern AVOutputFormat ff_apm_muxer;
extern AVInputFormat ff_apng_demuxer;
extern AVOutputFormat ff_apng_muxer;
extern AVInputFormat ff_aptx_demuxer;
diff --git a/libavformat/apm.c b/libavformat/apm.c
index 57d23200b0..9c9548baab 100644
--- a/libavformat/apm.c
+++ b/libavformat/apm.c
@@ -1,5 +1,5 @@
/*
- * Rayman 2 APM Demuxer
+ * Rayman 2 APM (De)muxer
*
* Copyright (C) 2020 Zane van Iperen (z...@zanevaniperen.com)
*
@@ -21,6 +21,8 @@
*/
#include "avformat.h"
#include "internal.h"
+#include "rawenc.h"
+#include "libavutil/avassert.h"
#include "libavutil/internal.h"
#include "libavutil/intreadwrite.h"
@@ -48,13 +50,14 @@ typedef struct APMExtraData {
uint32_tmagic;
uint32_tfile_size;
uint32_tdata_size;
-uint32_tunk1;
+int32_t unk1;
uint32_tunk2;
APMStatestate;
uint32_tunk3[7];
uint32_tdata;
} APMExtraData;
+#if CONFIG_APM_DEMUXER
static void apm_parse_extradata(APMExtraData *ed, const uint8_t *buf)
{
ed->magic = AV_RL32(buf + 0);
@@ -198,3 +201,106 @@ AVInputFormat ff_apm_demuxer = {
.read_header= apm_read_header,
.read_packet= apm_read_packet
};
+#endif
+
+#if CONFIG_APM_MUXER
+static int apm_write_init(AVFormatContext *s)
+{
+AVCodecParameters *par;
+
+if (s->nb_streams != 1) {
+av_log(s, AV_LOG_ERROR, "APM files have exactly one stream\n");
+return AVERROR(EINVAL);
+}
+
+par = s->streams[0]->codecpar;
+
+if (par->codec_id != AV_CODEC_ID_ADPCM_IMA_APM) {
+av_log(s, AV_LOG_ERROR, "%s codec not supported\n",
+ avcodec_get_name(par->codec_id));
+return AVERROR(EINVAL);
+}
+
+if (par->channels > 2) {
+av_log(s, AV_LOG_ERROR, "APM files only support up to 2 channels\n");
+return AVERROR(EINVAL);
+}
+
+if (par->extradata_size != APM_EXTRADATA_SIZE) {
+av_log(s, AV_LOG_ERROR, "Invalid/missing extradata\n");
+return AVERROR(EINVAL);
+}
+
+if (!(s->pb->seekable & AVIO_SEEKABLE_NORMAL)) {
+av_log(s, AV_LOG_ERROR, "Stream not seekable, unable to write output
file\n");
+return AVERROR(EINVAL);
+}
+
+return 0;
+}
+
+static int apm_write_header(AVFormatContext *s)
+{
+uint8_t buf[APM_FILE_EXTRADATA_SIZE] = { 0 };
+AVCodecParameters *par = s->streams[0]->codecpar;
+
+/*
+ * Bodge a WAVEFORMATEX manually, ff_put_wav_header() can't
+ * be used because of the extra 2 bytes.
+ */
+avio_wl16(s->pb, APM_TAG_CODEC);
+avio_wl16(s->pb, par->channels);
+avio_wl32(s->pb, par->sample_rate);
+avio_wl32(s->pb, par->sample_rate * par->channels * 2);
+avio_wl16(s->pb, par->block_align);
+avio_wl16(s->pb, par->bits_per_coded_sample);
+avio_wl16(s->pb, APM_FILE_EXTRADATA_SIZE);
+
+avio_wl16(s->pb, 0); /* pad */
+
+/*
+ * Build the extradata. Assume the codec's given us correct data.
+ * File and data sizes are fixed later.
+ */
+AV_WL32(buf + 0, APM_TAG_VS12); /* magic */
+AV_WL32(buf + 12, -1); /* unk1, always seems to be -1 */
+memcpy( buf + 20, par->extradata, APM_EXTRADATA_SIZE);
+AV_WL32(buf + 76, APM_TAG_DATA); /* data */
+
+avio_write(s->pb, buf, APM_FILE_EXTRADATA_SIZE);
+return 0;
+}
+
+static int apm_write_trailer(AVFormatContext *s)
+{
+int64_t file_size, data_size;
+
+file_size = avio_tell(s->pb);
+data_size = file_size - (APM_FILE_HEADER_SIZE + 2 +
[FFmpeg-devel] [PATCH v3 1/7] avformat/apm: check codec tag in probe and add constant
Signed-off-by: Zane van Iperen
---
libavformat/apm.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/libavformat/apm.c b/libavformat/apm.c
index 9d2a856cc4..dc59c16562 100644
--- a/libavformat/apm.c
+++ b/libavformat/apm.c
@@ -29,6 +29,7 @@
#define APM_VS12_CHUNK_SIZE 76
#define APM_MAX_READ_SIZE 4096
+#define APM_TAG_CODEC 0x2000
#define APM_TAG_VS12MKTAG('v', 's', '1', '2')
#define APM_TAG_DATAMKTAG('D', 'A', 'T', 'A')
@@ -74,6 +75,9 @@ static void apm_parse_vs12(APMVS12Chunk *vs12, const uint8_t
*buf)
static int apm_probe(const AVProbeData *p)
{
+if (AV_RL16(p->buf) != APM_TAG_CODEC)
+return 0;
+
if (p->buf_size < 100)
return 0;
@@ -103,7 +107,7 @@ static int apm_read_header(AVFormatContext *s)
if (st->codecpar->bits_per_coded_sample != 4)
return AVERROR_INVALIDDATA;
-if (st->codecpar->codec_tag != 0x2000)
+if (st->codecpar->codec_tag != APM_TAG_CODEC)
return AVERROR_INVALIDDATA;
/* ff_get_wav_header() does most of the work, but we need to fix a few
things. */
--
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 v3 2/7] avcodec/adpcm_ima_apm: support new extradata format
Signed-off-by: Zane van Iperen
---
libavcodec/adpcm.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/libavcodec/adpcm.c b/libavcodec/adpcm.c
index 79c5d625d1..4de4a23289 100644
--- a/libavcodec/adpcm.c
+++ b/libavcodec/adpcm.c
@@ -162,11 +162,18 @@ static av_cold int adpcm_decode_init(AVCodecContext *
avctx)
}
break;
case AV_CODEC_ID_ADPCM_IMA_APM:
-if (avctx->extradata && avctx->extradata_size >= 16) {
-c->status[0].predictor = av_clip_intp2(AV_RL32(avctx->extradata +
0), 18);
-c->status[0].step_index = av_clip(AV_RL32(avctx->extradata + 4),
0, 88);
-c->status[1].predictor = av_clip_intp2(AV_RL32(avctx->extradata +
8), 18);
-c->status[1].step_index = av_clip(AV_RL32(avctx->extradata + 12),
0, 88);
+if (avctx->extradata) {
+if (avctx->extradata_size >= 28) {
+c->status[0].predictor =
av_clip_intp2(AV_RL32(avctx->extradata + 16), 18);
+c->status[0].step_index = av_clip(AV_RL32(avctx->extradata +
20), 0, 88);
+c->status[1].predictor =
av_clip_intp2(AV_RL32(avctx->extradata + 4), 18);
+c->status[1].step_index = av_clip(AV_RL32(avctx->extradata +
8), 0, 88);
+} else if (avctx->extradata_size >= 16) {
+c->status[0].predictor =
av_clip_intp2(AV_RL32(avctx->extradata + 0), 18);
+c->status[0].step_index = av_clip(AV_RL32(avctx->extradata +
4), 0, 88);
+c->status[1].predictor =
av_clip_intp2(AV_RL32(avctx->extradata + 8), 18);
+c->status[1].step_index = av_clip(AV_RL32(avctx->extradata +
12), 0, 88);
+}
}
break;
case AV_CODEC_ID_ADPCM_IMA_WS:
--
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 v3 4/7] avformat/apm: use new extradata format
Signed-off-by: Zane van Iperen
---
libavformat/Makefile | 2 +-
libavformat/apm.c| 130 +++
2 files changed, 70 insertions(+), 62 deletions(-)
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 0658fa3710..bb09dc6563 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -93,7 +93,7 @@ OBJS-$(CONFIG_AMRWB_DEMUXER) += amr.o
OBJS-$(CONFIG_ANM_DEMUXER) += anm.o
OBJS-$(CONFIG_APC_DEMUXER) += apc.o
OBJS-$(CONFIG_APE_DEMUXER) += ape.o apetag.o img2.o
-OBJS-$(CONFIG_APM_DEMUXER) += apm.o riffdec.o
+OBJS-$(CONFIG_APM_DEMUXER) += apm.o
OBJS-$(CONFIG_APNG_DEMUXER) += apngdec.o
OBJS-$(CONFIG_APNG_MUXER)+= apngenc.o
OBJS-$(CONFIG_APTX_DEMUXER) += aptxdec.o rawdec.o
diff --git a/libavformat/apm.c b/libavformat/apm.c
index dc59c16562..57d23200b0 100644
--- a/libavformat/apm.c
+++ b/libavformat/apm.c
@@ -21,12 +21,13 @@
*/
#include "avformat.h"
#include "internal.h"
-#include "riff.h"
#include "libavutil/internal.h"
#include "libavutil/intreadwrite.h"
-#define APM_FILE_HEADER_SIZE20
-#define APM_VS12_CHUNK_SIZE 76
+#define APM_FILE_HEADER_SIZE18
+#define APM_FILE_EXTRADATA_SIZE 80
+#define APM_EXTRADATA_SIZE 28
+
#define APM_MAX_READ_SIZE 4096
#define APM_TAG_CODEC 0x2000
@@ -43,34 +44,37 @@ typedef struct APMState {
int32_t saved_l;
} APMState;
-typedef struct APMVS12Chunk {
+typedef struct APMExtraData {
uint32_tmagic;
uint32_tfile_size;
uint32_tdata_size;
uint32_tunk1;
uint32_tunk2;
APMStatestate;
-uint32_tpad[7];
-} APMVS12Chunk;
+uint32_tunk3[7];
+uint32_tdata;
+} APMExtraData;
-static void apm_parse_vs12(APMVS12Chunk *vs12, const uint8_t *buf)
+static void apm_parse_extradata(APMExtraData *ed, const uint8_t *buf)
{
-vs12->magic = AV_RL32(buf + 0);
-vs12->file_size = AV_RL32(buf + 4);
-vs12->data_size = AV_RL32(buf + 8);
-vs12->unk1 = AV_RL32(buf + 12);
-vs12->unk2 = AV_RL32(buf + 16);
-
-vs12->state.has_saved = AV_RL32(buf + 20);
-vs12->state.predictor_r = AV_RL32(buf + 24);
-vs12->state.step_index_r= AV_RL32(buf + 28);
-vs12->state.saved_r = AV_RL32(buf + 32);
-vs12->state.predictor_l = AV_RL32(buf + 36);
-vs12->state.step_index_l= AV_RL32(buf + 40);
-vs12->state.saved_l = AV_RL32(buf + 44);
-
-for (int i = 0; i < FF_ARRAY_ELEMS(vs12->pad); i++)
-vs12->pad[i]= AV_RL32(buf + 48 + (i * 4));
+ed->magic = AV_RL32(buf + 0);
+ed->file_size = AV_RL32(buf + 4);
+ed->data_size = AV_RL32(buf + 8);
+ed->unk1 = AV_RL32(buf + 12);
+ed->unk2 = AV_RL32(buf + 16);
+
+ed->state.has_saved = AV_RL32(buf + 20);
+ed->state.predictor_r = AV_RL32(buf + 24);
+ed->state.step_index_r= AV_RL32(buf + 28);
+ed->state.saved_r = AV_RL32(buf + 32);
+ed->state.predictor_l = AV_RL32(buf + 36);
+ed->state.step_index_l= AV_RL32(buf + 40);
+ed->state.saved_l = AV_RL32(buf + 44);
+
+for (int i = 0; i < FF_ARRAY_ELEMS(ed->unk3); i++)
+ed->unk3[i] = AV_RL32(buf + 48 + (i * 4));
+
+ed->data = AV_RL32(buf + 76);
}
static int apm_probe(const AVProbeData *p)
@@ -94,71 +98,75 @@ static int apm_read_header(AVFormatContext *s)
{
int64_t ret;
AVStream *st;
-APMVS12Chunk vs12;
-uint8_t buf[APM_VS12_CHUNK_SIZE];
+APMExtraData extradata;
+AVCodecParameters *par;
+uint8_t buf[APM_FILE_EXTRADATA_SIZE];
if (!(st = avformat_new_stream(s, NULL)))
return AVERROR(ENOMEM);
-/* The header starts with a WAVEFORMATEX */
-if ((ret = ff_get_wav_header(s, s->pb, st->codecpar, APM_FILE_HEADER_SIZE,
0)) < 0)
-return ret;
-
-if (st->codecpar->bits_per_coded_sample != 4)
+/*
+ * This is 98% a WAVEFORMATEX, but there's something screwy with the
extradata
+ * that ff_get_wav_header() can't (and shouldn't) handle properly.
+ */
+if (avio_rl16(s->pb) != APM_TAG_CODEC)
return AVERROR_INVALIDDATA;
-if (st->codecpar->codec_tag != APM_TAG_CODEC)
+par = st->codecpar;
+par->channels = avio_rl16(s->pb);
+par->sample_rate = avio_rl32(s->pb);
+par->bit_rate = avio_rl32(s->pb) * 8;
+par->block_align = avio_rl16(s->pb);
+par->bits_per_coded_sample = avio_rl16(s->pb);
+
+if (avio_rl16(s->pb) != APM_FILE_EXTRADATA_SIZE)
return AVERROR_INVALIDDATA;
-/* ff_get_wav_header() does most of the work, but we need to fix a few
things. */
-st->codecpar->codec_id =
[FFmpeg-devel] [PATCH v3 3/7] avcodec: add adpcm_ima_apm encoder
Signed-off-by: Zane van Iperen
---
doc/general.texi | 2 +-
libavcodec/Makefile| 1 +
libavcodec/adpcmenc.c | 34 --
libavcodec/allcodecs.c | 1 +
libavcodec/utils.c | 1 +
libavcodec/version.h | 2 +-
6 files changed, 37 insertions(+), 4 deletions(-)
diff --git a/doc/general.texi b/doc/general.texi
index 9b0ee96752..8df7445c36 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -1109,7 +1109,7 @@ following image formats are supported:
@item ADPCM IMA High Voltage Software ALP @tab @tab X
@item ADPCM IMA QuickTime@tab X @tab X
@item ADPCM IMA Simon & Schuster Interactive @tab X @tab X
-@item ADPCM IMA Ubisoft APM @tab @tab X
+@item ADPCM IMA Ubisoft APM @tab X @tab X
@item ADPCM IMA Loki SDL MJPEG @tab @tab X
@item ADPCM IMA WAV @tab X @tab X
@item ADPCM IMA Westwood @tab @tab X
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 5a6ea59715..4ee0bf2d4c 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -853,6 +853,7 @@ OBJS-$(CONFIG_ADPCM_IMA_AMV_DECODER) += adpcm.o
adpcm_data.o
OBJS-$(CONFIG_ADPCM_IMA_ALP_DECODER) += adpcm.o adpcm_data.o
OBJS-$(CONFIG_ADPCM_IMA_APC_DECODER) += adpcm.o adpcm_data.o
OBJS-$(CONFIG_ADPCM_IMA_APM_DECODER) += adpcm.o adpcm_data.o
+OBJS-$(CONFIG_ADPCM_IMA_APM_ENCODER) += adpcmenc.o adpcm_data.o
OBJS-$(CONFIG_ADPCM_IMA_CUNNING_DECODER) += adpcm.o adpcm_data.o
OBJS-$(CONFIG_ADPCM_IMA_DAT4_DECODER) += adpcm.o adpcm_data.o
OBJS-$(CONFIG_ADPCM_IMA_DK3_DECODER) += adpcm.o adpcm_data.o
diff --git a/libavcodec/adpcmenc.c b/libavcodec/adpcmenc.c
index d5fbc0b9a7..d2d90b9176 100644
--- a/libavcodec/adpcmenc.c
+++ b/libavcodec/adpcmenc.c
@@ -77,7 +77,9 @@ static av_cold int adpcm_encode_init(AVCodecContext *avctx)
return AVERROR(EINVAL);
}
-if (avctx->trellis && avctx->codec->id == AV_CODEC_ID_ADPCM_IMA_SSI) {
+if (avctx->trellis &&
+ (avctx->codec->id == AV_CODEC_ID_ADPCM_IMA_SSI ||
+avctx->codec->id == AV_CODEC_ID_ADPCM_IMA_APM)) {
/*
* The current trellis implementation doesn't work for extended
* runs of samples without periodic resets. Disallow it.
@@ -152,6 +154,14 @@ static av_cold int adpcm_encode_init(AVCodecContext *avctx)
avctx->frame_size = BLKSIZE * 2 / avctx->channels;
avctx->block_align = BLKSIZE;
break;
+case AV_CODEC_ID_ADPCM_IMA_APM:
+avctx->frame_size = BLKSIZE * 2 / avctx->channels;
+avctx->block_align = BLKSIZE;
+
+if (!(avctx->extradata = av_mallocz(28 +
AV_INPUT_BUFFER_PADDING_SIZE)))
+goto error;
+avctx->extradata_size = 28;
+break;
default:
ret = AVERROR(EINVAL);
goto error;
@@ -496,7 +506,8 @@ static int adpcm_encode_frame(AVCodecContext *avctx,
AVPacket *avpkt,
if (avctx->codec_id == AV_CODEC_ID_ADPCM_SWF)
pkt_size = (2 + avctx->channels * (22 + 4 * (frame->nb_samples - 1)) +
7) / 8;
-else if (avctx->codec_id == AV_CODEC_ID_ADPCM_IMA_SSI)
+else if (avctx->codec_id == AV_CODEC_ID_ADPCM_IMA_SSI ||
+ avctx->codec_id == AV_CODEC_ID_ADPCM_IMA_APM)
pkt_size = (frame->nb_samples * avctx->channels) / 2;
else
pkt_size = avctx->block_align;
@@ -717,6 +728,24 @@ static int adpcm_encode_frame(AVCodecContext *avctx,
AVPacket *avpkt,
*dst++ = nibble;
}
break;
+case AV_CODEC_ID_ADPCM_IMA_APM:
+{
+PutBitContext pb;
+init_put_bits(, dst, pkt_size);
+
+av_assert0(avctx->trellis == 0);
+
+for (n = frame->nb_samples / 2; n > 0; n--) {
+for (ch = 0; ch < avctx->channels; ch++) {
+put_bits(, 4, adpcm_ima_qt_compress_sample(c->status + ch,
*samples++));
+put_bits(, 4, adpcm_ima_qt_compress_sample(c->status + ch,
samples[st]));
+}
+samples += avctx->channels;
+}
+
+flush_put_bits();
+break;
+}
default:
return AVERROR(EINVAL);
}
@@ -751,6 +780,7 @@ AVCodec ff_ ## name_ ## _encoder = {
\
.caps_internal = FF_CODEC_CAP_INIT_CLEANUP, \
}
+ADPCM_ENCODER(AV_CODEC_ID_ADPCM_IMA_APM, adpcm_ima_apm, sample_fmts,
AV_CODEC_CAP_SMALL_LAST_FRAME, "ADPCM IMA Ubisoft APM");
ADPCM_ENCODER(AV_CODEC_ID_ADPCM_IMA_QT, adpcm_ima_qt, sample_fmts_p, 0,
"ADPCM IMA QuickTime");
ADPCM_ENCODER(AV_CODEC_ID_ADPCM_IMA_SSI, adpcm_ima_ssi, sample_fmts,
AV_CODEC_CAP_SMALL_LAST_FRAME, "ADPCM IMA Simon & Schuster Interactive");
ADPCM_ENCODER(AV_CODEC_ID_ADPCM_IMA_WAV, adpcm_ima_wav, sample_fmts_p, 0,
"ADPCM IMA WAV");
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 80f128cade..f7d560052e 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@
[FFmpeg-devel] [PATCH v3 0/7] adpcm_ima_apm encoder + apm muxer
Add support for encoding adpcm_ima_apm and muxing to apm. If possible, I would like to get this functionality into the 4.3 release. v3: [4][5][6] * Support both extradata formats - fixes FATE failure + preserves compatibility * EINVAL->ERANGE v2: [1][2][3] * fix mixed declarations and code * remove unused variable * fix array initialisation * LOG_WARNING->LOG_ERROR * reorder "name and probe fix" [1] https://ffmpeg.org/pipermail/ffmpeg-devel/2020-June/264310.html [2] https://ffmpeg.org/pipermail/ffmpeg-devel/2020-June/264309.html [3] https://ffmpeg.org/pipermail/ffmpeg-devel/2020-June/264308.html [4] https://ffmpeg.org/pipermail/ffmpeg-devel/2020-June/264328.html [5] https://ffmpeg.org/pipermail/ffmpeg-devel/2020-June/264329.html [6] https://ffmpeg.org/pipermail/ffmpeg-devel/2020-June/264326.html Zane van Iperen (7): avformat/apm: check codec tag in probe and add constant avcodec/adpcm_ima_apm: support new extradata format avcodec: add adpcm_ima_apm encoder avformat/apm: use new extradata format avformat: add apm muxer fate: add adpcm_ima_apm encoding test avcodec/adpcmenc: cleanup trellis checks Changelog | 1 + doc/general.texi | 2 +- libavcodec/Makefile| 1 + libavcodec/adpcm.c | 17 ++- libavcodec/adpcmenc.c | 63 ++--- libavcodec/allcodecs.c | 1 + libavcodec/utils.c | 1 + libavcodec/version.h | 2 +- libavformat/Makefile | 3 +- libavformat/allformats.c | 1 + libavformat/apm.c | 244 - libavformat/version.h | 2 +- tests/fate/acodec.mak | 2 + tests/ref/acodec/adpcm-ima_apm | 4 + 14 files changed, 256 insertions(+), 88 deletions(-) create mode 100644 tests/ref/acodec/adpcm-ima_apm -- 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] codec_desc: mark CFHD as intra-only
> > It still seems to me that this is a solution in search of a problem. If > I understand you correctly, the case you have in mind is a codec where > there is an internal implementation that only supports intra frames > and an external implementation that also supports inter frames. > But that seems incredibly contrived to me. For one thing, I don't know > of any actual situations like this, now or in the past. For another, why > pick out specifically the ability to decode intra vs inter frames? > There is a huge number of codec features that may be potentially > unsupported by various implementations (see e.g. AAC) and there's no > sane way we can have capability flags for them all. > Hi, I have no opinion on the issue at hand but this is currently the case with Cineform. The internal decoder supports the intra features but the open sourced one from them supports intra/inter features. Kieran ___ 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/3] lavc/avcodec: Add caps for the support of variable dimension encoding
Quoting Nicolas George (2020-06-09 11:48:19) > Anton Khirnov (12020-06-08): > > During the last iteration, I asked how is this preferable to just making > > a new encoder instance. Don't think I got a sufficient reply. > > How do we know that we can just put the packets of the new instance > after the packets of the old instance and it will work? The definition of "work" depends on what you do with the data. It is not a given that it will be passed into lavf to be muxed into a file. > > It will work for image codecs, of course. > > It will not work for raw video codecs, since the frame size and > characteristics are global. And yet the patches specifically concern raw video. > > It may work for some codecs. > > It may work if we generate side data to renew the extra data. > > Clearly, making a new encoder instance is not an universal solution. There is no universal solution. My point is that creating a new encoder instance is conceptually simpler and therefore safer than trying to reinitialize all the codec internals. -- 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] codec_desc: mark CFHD as intra-only
Quoting James Almer (2020-06-10 14:46:21) > On 6/10/2020 6:19 AM, Anton Khirnov wrote: > > Quoting James Almer (2020-06-09 14:45:33) > >> On 6/9/2020 6:06 AM, Anton Khirnov wrote: > >>> I don't think this needs to be visible externally, since it's only > >>> meaningful for internal use. I'm wondering if the presence of > >>> update_thread_context() callback won't be sufficient for this. > >> > >> True, it could be a caps_internal. But take for example the possibility > >> of an external library with a fully featured decoder getting a wrapper, > >> this being a public capability would let the user choose it over the > >> internal one, same as how it can choose a stable decoder over an > >> experimental one, or a software one over an hybrid/hw one. > > > > I don't see why this should be a criterium for the user to base any > > decisions on. It's purely an internal implementation detail that's tied > > to the way frame threading is currently implemented and can potentially > > change later. So I don't see why it should be accessible through the > > API. > > An intra only decoder returns I frames only. A fully feature decoder > would return I and P (and actually get you something other than a key > frame slideshow). Or at least that's how i understood it. > Giving the user a way to choose the best decoder for their needs is not > too crazy. We already do with other implementation specific > capabilities, as i mentioned above. > > > > > Also, not sure if you saw but I have new patch fixing this problem in > > another manner. > > Yes, i saw. I'm arguing about this other approach because if it's done > now, it can be done seamlessly (Just revert the change and pretend the > flag was never deprecated). After 4.3 is effectively tagged, we would > require to undo the deprecation with another API change, and it will > look messy. > > The flag was meaningless and a duplicate of the codec prop, but now we > found a way to use it to actually convey information about a decoder, so > why not do it? It still seems to me that this is a solution in search of a problem. If I understand you correctly, the case you have in mind is a codec where there is an internal implementation that only supports intra frames and an external implementation that also supports inter frames. But that seems incredibly contrived to me. For one thing, I don't know of any actual situations like this, now or in the past. For another, why pick out specifically the ability to decode intra vs inter frames? There is a huge number of codec features that may be potentially unsupported by various implementations (see e.g. AAC) and there's no sane way we can have capability flags for them all. -- 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".
