[FFmpeg-devel] [PATCH 1/2] avutil/common: Add FF_PTR_ADD()
Suggested-by: Andreas Rheinhardt
Signed-off-by: Michael Niedermayer
---
libavutil/common.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavutil/common.h b/libavutil/common.h
index aee353d399..c2d47a45b4 100644
--- a/libavutil/common.h
+++ b/libavutil/common.h
@@ -108,6 +108,8 @@
#define FFSWAP(type,a,b) do{type SWAP_tmp= b; b= a; a= SWAP_tmp;}while(0)
#define FF_ARRAY_ELEMS(a) (sizeof(a) / sizeof((a)[0]))
+#define FF_PTR_ADD(ptr, off) ((off) ? (ptr) + (off) : (ptr))
+
/* misc math functions */
#ifdef HAVE_AV_CONFIG_H
--
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".
[FFmpeg-devel] [PATCH 2/2] avfilter/vf_scale: Fix adding 0 to NULL (which is UB) in scale_slice()
Found-by: Jeremy Leconte Signed-off-by: Michael Niedermayer --- libavfilter/vf_scale.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c index 58eee96744..5ad9334d02 100644 --- a/libavfilter/vf_scale.c +++ b/libavfilter/vf_scale.c @@ -635,8 +635,8 @@ static int scale_slice(AVFilterLink *link, AVFrame *out_buf, AVFrame *cur_pic, s int vsub= ((i+1)&2) ? scale->vsub : 0; in_stride[i] = cur_pic->linesize[i] * mul; out_stride[i] = out_buf->linesize[i] * mul; - in[i] = cur_pic->data[i] + ((y>>vsub)+field) * cur_pic->linesize[i]; -out[i] = out_buf->data[i] +field * out_buf->linesize[i]; + in[i] = FF_PTR_ADD(cur_pic->data[i], ((y>>vsub)+field) * cur_pic->linesize[i]); +out[i] = FF_PTR_ADD(out_buf->data[i],field * out_buf->linesize[i]); } if (scale->input_is_pal) in[1] = cur_pic->data[1]; -- 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".
[FFmpeg-devel] [PATCH 1/2] avformat/libsrt: fix setsockopt() typo
--- libavformat/libsrt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c index 233e9096fa..ac865c5658 100644 --- a/libavformat/libsrt.c +++ b/libavformat/libsrt.c @@ -334,7 +334,7 @@ static int libsrt_set_options_pre(URLContext *h, int fd) (s->latency >= 0 && libsrt_setsockopt(h, fd, SRTO_LATENCY, "SRTO_LATENCY", &latency, sizeof(latency)) < 0) || (s->rcvlatency >= 0 && libsrt_setsockopt(h, fd, SRTO_RCVLATENCY, "SRTO_RCVLATENCY", &rcvlatency, sizeof(rcvlatency)) < 0) || (s->peerlatency >= 0 && libsrt_setsockopt(h, fd, SRTO_PEERLATENCY, "SRTO_PEERLATENCY", &peerlatency, sizeof(peerlatency)) < 0) || -(s->tlpktdrop >= 0 && libsrt_setsockopt(h, fd, SRTO_TLPKTDROP, "SRTO_TLPKDROP", &s->tlpktdrop, sizeof(s->tlpktdrop)) < 0) || +(s->tlpktdrop >= 0 && libsrt_setsockopt(h, fd, SRTO_TLPKTDROP, "SRTO_TLPKTDROP", &s->tlpktdrop, sizeof(s->tlpktdrop)) < 0) || (s->nakreport >= 0 && libsrt_setsockopt(h, fd, SRTO_NAKREPORT, "SRTO_NAKREPORT", &s->nakreport, sizeof(s->nakreport)) < 0) || (connect_timeout >= 0 && libsrt_setsockopt(h, fd, SRTO_CONNTIMEO, "SRTO_CONNTIMEO", &connect_timeout, sizeof(connect_timeout)) <0 ) || (s->sndbuf >= 0 && libsrt_setsockopt(h, fd, SRTO_SNDBUF, "SRTO_SNDBUF", &s->sndbuf, sizeof(s->sndbuf)) < 0) || -- 2.30.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] avformat/libsrt: fix help message
SRTO_TLPKTDROP works for receiver and sender both.
---
libavformat/libsrt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c
index ac865c5658..c1e96f700e 100644
--- a/libavformat/libsrt.c
+++ b/libavformat/libsrt.c
@@ -122,7 +122,7 @@ static const AVOption libsrt_options[] = {
{ "tsbpddelay", "deprecated, same effect as latency option",
OFFSET(latency), AV_OPT_TYPE_INT64, { .i64 = -1 },
-1, INT64_MAX, .flags = D|E },
{ "rcvlatency", "receive latency (in microseconds)",
OFFSET(rcvlatency), AV_OPT_TYPE_INT64, { .i64 = -1 },
-1, INT64_MAX, .flags = D|E },
{ "peerlatency","peer latency (in microseconds)",
OFFSET(peerlatency), AV_OPT_TYPE_INT64, { .i64 = -1 },
-1, INT64_MAX, .flags = D|E },
-{ "tlpktdrop", "Enable receiver pkt drop",
OFFSET(tlpktdrop),AV_OPT_TYPE_BOOL, { .i64 = -1 },
-1, 1, .flags = D|E },
+{ "tlpktdrop", "Enable too-late pkt drop",
OFFSET(tlpktdrop),AV_OPT_TYPE_BOOL, { .i64 = -1 },
-1, 1, .flags = D|E },
{ "nakreport", "Enable receiver to send periodic NAK reports",
OFFSET(nakreport),AV_OPT_TYPE_BOOL, { .i64 = -1 },
-1, 1, .flags = D|E },
{ "connect_timeout", "Connect timeout(in milliseconds). Caller default:
3000, rendezvous (x 10)",OFFSET(connect_timeout),
AV_OPT_TYPE_INT64, { .i64 = -1 }, -1, INT64_MAX, .flags = D|E },
{ "mode", "Connection mode (caller, listener, rendezvous)",
OFFSET(mode), AV_OPT_TYPE_INT, { .i64 =
SRT_MODE_CALLER }, SRT_MODE_CALLER, SRT_MODE_RENDEZVOUS, .flags = D|E, "mode" },
--
2.30.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 1/2] avformat/mxfdec: Don't use wrong type of pointer
fre 2021-03-12 klockan 14:07 +0100 skrev Andreas Rheinhardt:
> @@ -2922,20 +2929,19 @@ static int mxf_read_local_tags(MXFContext *mxf,
> KLVPacket *klv, MXFMetadataReadF
> }
> }
> }
> -if (ctx_size && tag == 0x3C0A) {
> -avio_read(pb, ctx->uid, 16);
> +if (meta && tag == 0x3C0A) {
Why not keep this conditional on ctx_size? That way you could get rid
of ctx altogether
> +avio_read(pb, meta->uid, 16);
> } else if ((ret = read_child(ctx, pb, tag, size, uid, -1)) < 0) {
This could be ctx_size ? meta : mxf
> -if (ctx_size)
> -mxf_free_metadataset(&ctx, 1);
> +if (meta)
> +mxf_free_metadataset(&meta, 1);
Please add {} while you're at it
/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".
Re: [FFmpeg-devel] [PATCH] avformat/aviobuf: don't reduce short seek threshold
On Sat, 13 Mar 2021, Andriy Gelman wrote:
From: Andriy Gelman
Commit 8c8e5d5286bf598a89ef9993a2cf6ea409d03a32 added a way to reduce
seek time by waiting for the windowed tcp packets instead of creating a
new socket connection. It implemented this by overwriting
s->short_seek_threshold in the avio_seek(). However,
s->short_seek_threshold could already be set and be higher than the
threshold set by the protocol (i.e. s->short_seek_threshold is set in
ff_configure_buffers_for_index()).
This new feature was only enabled for tls connections in
70d8077b795766e2486e6ec8110f22a97362d6d7. As in Ticket #9148 it reduced
This commit reference is typoed, the last char should be a 6, not a 7.
performance because instead of waiting to refill the AVIOContext buffers
with an existing connections, a new HTTP request was often made instead.
Fixes Ticket #9148.
Signed-off-by: Andriy Gelman
---
libavformat/aviobuf.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
index 78cc60b2ae..518cb11129 100644
--- a/libavformat/aviobuf.c
+++ b/libavformat/aviobuf.c
@@ -283,13 +283,9 @@ int64_t avio_seek(AVIOContext *s, int64_t offset, int
whence)
if (offset < 0)
return AVERROR(EINVAL);
-if (s->short_seek_get) {
-short_seek = s->short_seek_get(s->opaque);
-/* fallback to default short seek */
-if (short_seek <= 0)
-short_seek = s->short_seek_threshold;
-} else
-short_seek = s->short_seek_threshold;
+short_seek = s->short_seek_threshold;
+if (s->short_seek_get)
+short_seek = FFMAX(s->short_seek_get(s->opaque), short_seek);
offset1 = offset - pos; // "offset1" is the relative offset from the beginning
of s->buffer
s->buf_ptr_max = FFMAX(s->buf_ptr_max, s->buf_ptr);
--
2.30.2
LGTM, thanks!
// Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] Fix wrong time_base bug
Set time_base to inv of frame rate is only valid when input video have fixed
frame rate.
Signed-off-by: Donough Liu
---
doc/examples/transcoding.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/examples/transcoding.c b/doc/examples/transcoding.c
index 5aff08c135..49ae32c719 100644
--- a/doc/examples/transcoding.c
+++ b/doc/examples/transcoding.c
@@ -170,7 +170,7 @@ static int open_output_file(const char *filename)
else
enc_ctx->pix_fmt = dec_ctx->pix_fmt;
/* video time_base can be set to whatever is handy and
supported by encoder */
-enc_ctx->time_base = av_inv_q(dec_ctx->framerate);
+enc_ctx->time_base = av_inv_q(av_mul_q(dec_ctx->framerate,
(AVRational){dec_ctx->ticks_per_frame, 1}));
} else {
enc_ctx->sample_rate = dec_ctx->sample_rate;
enc_ctx->channel_layout = dec_ctx->channel_layout;
--
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] doc/encoders: remove text about single bit-depth libx264 support
In the meanwhile libx264 allows to be configured for including both 8/10 bit support within a single library. The new libx264 interface was enabled in 2f96190732d15510ba29471fa45d66841c0c3df1. Signed-off-by: Tobias Rapp --- doc/encoders.texi | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/doc/encoders.texi b/doc/encoders.texi index c9c8785a..a92eb0e 100644 --- a/doc/encoders.texi +++ b/doc/encoders.texi @@ -2305,9 +2305,7 @@ pixel formats as input instead of YUV. @subsection Supported Pixel Formats x264 supports 8- to 10-bit color spaces. The exact bit depth is controlled at -x264's configure time. FFmpeg only supports one bit depth in one particular -build. In other words, it is not possible to build one FFmpeg with multiple -versions of x264 with different bit depths. +x264's configure time. @subsection Options -- 2.7.4 ___ 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: Don't use wrong type of pointer
Tomas Härdin:
> fre 2021-03-12 klockan 14:07 +0100 skrev Andreas Rheinhardt:
>> @@ -2922,20 +2929,19 @@ static int mxf_read_local_tags(MXFContext *mxf,
>> KLVPacket *klv, MXFMetadataReadF
>> }
>> }
>> }
>> -if (ctx_size && tag == 0x3C0A) {
>> -avio_read(pb, ctx->uid, 16);
>> +if (meta && tag == 0x3C0A) {
>
> Why not keep this conditional on ctx_size? That way you could get rid
> of ctx altogether
>
Because I consider it more natural to check for the existence of a
MXFMetadataSet by checking whether a pointer to MXFMetadataSet is NULL
or not. After all, ctx_size could also contain the size of the MXFContext.
>> +avio_read(pb, meta->uid, 16);
>> } else if ((ret = read_child(ctx, pb, tag, size, uid, -1)) < 0) {
>
> This could be ctx_size ? meta : mxf
>
Seems like another check to me.
>> -if (ctx_size)
>> -mxf_free_metadataset(&ctx, 1);
>> +if (meta)
>> +mxf_free_metadataset(&meta, 1);
>
> Please add {} while you're at it
>
Will do.
- 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] fftools/ffmpeg: use the correct size value for wrapped_avframe packets
On 3/15/2021 12:53 AM, Andreas Rheinhardt wrote:
James Almer:
pkt->size on packets wrapping an AVFrame signaled by the wrapped_avframe
codec_id are set to the size of the AVFrame structure and not the actual raw
data contained in it.
ffmpeg.c was using those values to print bogus stats about the resulting output
file.
Before this patch:
frame= 24 fps=0.0 q=-0.0 Lsize=7594kB time=00:00:01.00
bitrate=62209.8kbits/s speed= 27x
video:13kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing
overhead: 60349.488281%
After:
frame= 24 fps=0.0 q=-0.0 Lsize=7594kB time=00:00:01.00
bitrate=62209.8kbits/s speed= 28x
video:7594kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing
overhead: 0.002855%
Signed-off-by: James Almer
---
wrapped_avframe should be redefined to stop using sizeof(AVFrame) altogether.
I'll send a patch with a proposed approach for this.
fftools/ffmpeg.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 2abbc0ff29..6dcf9006db 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -727,7 +727,7 @@ static void write_packet(OutputFile *of, AVPacket *pkt,
OutputStream *ost, int u
{
AVFormatContext *s = of->ctx;
AVStream *st = ost->st;
-int ret;
+int size, ret;
/*
* Audio encoders may split the packets -- #frames in != #packets out.
@@ -842,7 +842,17 @@ static void write_packet(OutputFile *of, AVPacket *pkt,
OutputStream *ost, int u
}
ost->last_mux_dts = pkt->dts;
-ost->data_size += pkt->size;
+if (st->codecpar->codec_id == AV_CODEC_ID_WRAPPED_AVFRAME) {
+AVFrame *frame = (AVFrame *)pkt->data;
+if (!frame)
+exit_program(1);
+size = av_image_get_buffer_size(frame->format, frame->width,
frame->height, 1);
+if (size < 0)
+exit_program(1);
+} else
+size = pkt->size;
+
+ost->data_size += size;
ost->packets_written++;
pkt->stream_index = ost->index;
Is the format of wrapped_avframes actually publically documented
anywhere? Are user applications supposed to look at the data of said
frame or is this just something that allows users to pass AVFrames to
muxers? Given that you sent this patch you probably believe the former,
but is this generally accepted?
No, it's not documented. And no, I don't know if the user is meant to be
allowed to look at it or not, precisely because this pseudo-codec is
undocumented.
Maybe the idea was effectively to just use the encoder and send directly
to muxers, or use a demuxer and send directly to the decoder, in an
opaque way. Given how precarious this is and how a packet flag had to be
added to such modules to signal a not very descriptive "this is from a
trusted source", i wouldn't be surprised if it was an unspoken rule that
nothing outside libav* was meant to manually handle these.
Marton mentioned users might just be looking at the frames, but i don't
know if any project really does. And since packets don't report a
codec_id (only whatever produced them does) but they do report a size,
there's nothing stopping the user from doing so.
So i don't know, would this patch make people think looking at the
wrapped frame is ok? Are they meant to, to begin with?
I can just drop this patch. It's just to stop printing absurd statistics
like 60349.488281% overhead muxing. I'm more interested in making
wrapped_frame less hacky.
___
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: add Actimagine VX video decoder
Florian Nouwt:
> This video format is mainly used in older Nintendo DS games in a .vx
> container. It is the predecessor of the Mobiclip format.
>
> Signed-off-by: Florian Nouwt
> ---
> Changelog |1 +
> configure |1 +
> doc/general_contents.texi |2 +
> libavcodec/Makefile |1 +
> libavcodec/actimagine.c | 1644 +
> libavcodec/allcodecs.c|1 +
> libavcodec/codec_desc.c |7 +
> libavcodec/codec_id.h |1 +
> libavcodec/version.h |2 +-
> libavformat/riff.c|2 +
> 10 files changed, 1661 insertions(+), 1 deletion(-)
> create mode 100644 libavcodec/actimagine.c
>
> diff --git a/Changelog b/Changelog
> index a96e350e09..8807f3dcb3 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -83,6 +83,7 @@ version :
> - msad video filter
> - gophers protocol
> - RIST protocol via librist
> +- Actimagine VX video decoder
>
>
> version 4.3:
> diff --git a/configure b/configure
> index f0ac719d2d..10a07da95f 100755
> --- a/configure
> +++ b/configure
> @@ -2662,6 +2662,7 @@ ac3_fixed_decoder_select="ac3_parser ac3dsp bswapdsp
> mdct"
> ac3_encoder_select="ac3dsp audiodsp mdct me_cmp"
> ac3_fixed_encoder_select="ac3dsp audiodsp mdct me_cmp"
> acelp_kelvin_decoder_select="audiodsp"
> +actimagine_decoder_select="bswapdsp golomb"
> adpcm_g722_decoder_select="g722dsp"
> adpcm_g722_encoder_select="g722dsp"
> aic_decoder_select="golomb idctdsp"
> diff --git a/doc/general_contents.texi b/doc/general_contents.texi
> index 33ece6e884..d4261386fc 100644
> --- a/doc/general_contents.texi
> +++ b/doc/general_contents.texi
> @@ -807,6 +807,8 @@ following image formats are supported:
> @item 8088flex TMV @tab @tab X
> @item A64 multicolor @tab X @tab
> @tab Creates video suitable to be played on a commodore 64 (multicolor
> mode).
> +@item Actimagine VX Video@tab @tab X
> +@tab fourcc: vxs1, VXS1
> @item Amazing Studio PAF Video @tab @tab X
> @item American Laser Games MM @tab@tab X
> @tab Used in games like Mad Dog McCree.
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 81cc16471b..39b3bc968d 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -182,6 +182,7 @@ OBJS-$(CONFIG_AC3_ENCODER) += ac3enc_float.o
> ac3enc.o ac3tab.o \
> OBJS-$(CONFIG_AC3_FIXED_ENCODER) += ac3enc_fixed.o ac3enc.o ac3tab.o
> ac3.o kbdwin.o
> OBJS-$(CONFIG_AC3_MF_ENCODER) += mfenc.o mf_utils.o
> OBJS-$(CONFIG_ACELP_KELVIN_DECODER)+= g729dec.o lsp.o celp_math.o
> celp_filters.o acelp_filters.o acelp_pitch_delay.o acelp_vectors.o
> g729postfilter.o
> +OBJS-$(CONFIG_ACTIMAGINE_DECODER) += actimagine.o
> OBJS-$(CONFIG_AGM_DECODER) += agm.o
> OBJS-$(CONFIG_AIC_DECODER) += aic.o
> OBJS-$(CONFIG_ALAC_DECODER)+= alac.o alac_data.o alacdsp.o
> diff --git a/libavcodec/actimagine.c b/libavcodec/actimagine.c
> new file mode 100644
> index 00..6bb5126b05
> --- /dev/null
> +++ b/libavcodec/actimagine.c
> @@ -0,0 +1,1644 @@
> +/*
> + * Actimagine VX Video decoder
> + * Copyright (c) 2021 Florian Nouwt
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
> USA
> + */
> +
> +#include
> +
> +#include "libavutil/avassert.h"
> +#include "libavutil/thread.h"
> +
> +#include "avcodec.h"
> +#include "bytestream.h"
> +#include "bswapdsp.h"
> +#include "get_bits.h"
> +#include "golomb.h"
> +#include "internal.h"
> +
> +static const uint8_t predict_dc_shift_tab[] = {1, 2, 3, 0, 4};
> +
> +static const uint8_t zigzag4x4_tab[] =
> +{
> +0x00, 0x04, 0x01, 0x02, 0x05, 0x08, 0x0C, 0x09,
> +0x06, 0x03, 0x07, 0x0A, 0x0D, 0x0E, 0x0B, 0x0F
> +};
> +
> +static const uint8_t quant4x4_tab[][8] =
> +{
> +{ 0x0A, 0x0D, 0x0A, 0x0D, 0x0D, 0x10, 0x0D, 0x10 },
> +{ 0x0B, 0x0E, 0x0B, 0x0E, 0x0E, 0x12, 0x0E, 0x12 },
> +{ 0x0D, 0x10, 0x0D, 0x10, 0x10, 0x14, 0x10, 0x14 },
> +{ 0x0E, 0x12, 0x0E, 0x12, 0x12, 0x17, 0x12, 0x17 },
> +{ 0x10, 0x14, 0x10, 0x14, 0x14, 0x19, 0x14, 0x19 },
> +{ 0x12, 0x17, 0x12, 0x17, 0x17, 0x1D, 0x17, 0x1D }
> +};
> +
> +static const uint8_t old_mb_mode_remap_tab[] =
> +{
> + 1, 2,
Re: [FFmpeg-devel] [PATCH] avcodec: add Actimagine VX video decoder
I have uploaded an example video here: https://mega.nz/file/PVwGAbbB#9tL6p3uE-Ej1DP7ngovAPqYghkQckTpW26XlrpAop9w There's both an .avi file which can be read by ffmpeg and a vx file containing the exact same video data, for which I will write a demuxer soon (note that the vx is smaller because it contains compressed audio). I assumed it would be appropriate to have the demuxer as a separate patch after this one was accepted. If I make changes to my patch, do I have to amend the changes to my commit and then regenerate the patch and send it to this thread? This patch and mailing list stuff is kinda new to me. Op ma 15 mrt. 2021 om 14:47 schreef Andreas Rheinhardt : > > Florian Nouwt: > > This video format is mainly used in older Nintendo DS games in a .vx > > container. It is the predecessor of the Mobiclip format. > > > > Signed-off-by: Florian Nouwt > > --- > > Changelog |1 + > > configure |1 + > > doc/general_contents.texi |2 + > > libavcodec/Makefile |1 + > > libavcodec/actimagine.c | 1644 + > > libavcodec/allcodecs.c|1 + > > libavcodec/codec_desc.c |7 + > > libavcodec/codec_id.h |1 + > > libavcodec/version.h |2 +- > > libavformat/riff.c|2 + > > 10 files changed, 1661 insertions(+), 1 deletion(-) > > create mode 100644 libavcodec/actimagine.c > > > > diff --git a/Changelog b/Changelog > > index a96e350e09..8807f3dcb3 100644 > > --- a/Changelog > > +++ b/Changelog > > @@ -83,6 +83,7 @@ version : > > - msad video filter > > - gophers protocol > > - RIST protocol via librist > > +- Actimagine VX video decoder > > > > > > version 4.3: > > diff --git a/configure b/configure > > index f0ac719d2d..10a07da95f 100755 > > --- a/configure > > +++ b/configure > > @@ -2662,6 +2662,7 @@ ac3_fixed_decoder_select="ac3_parser ac3dsp bswapdsp > > mdct" > > ac3_encoder_select="ac3dsp audiodsp mdct me_cmp" > > ac3_fixed_encoder_select="ac3dsp audiodsp mdct me_cmp" > > acelp_kelvin_decoder_select="audiodsp" > > +actimagine_decoder_select="bswapdsp golomb" > > adpcm_g722_decoder_select="g722dsp" > > adpcm_g722_encoder_select="g722dsp" > > aic_decoder_select="golomb idctdsp" > > diff --git a/doc/general_contents.texi b/doc/general_contents.texi > > index 33ece6e884..d4261386fc 100644 > > --- a/doc/general_contents.texi > > +++ b/doc/general_contents.texi > > @@ -807,6 +807,8 @@ following image formats are supported: > > @item 8088flex TMV @tab @tab X > > @item A64 multicolor @tab X @tab > > @tab Creates video suitable to be played on a commodore 64 (multicolor > > mode). > > +@item Actimagine VX Video@tab @tab X > > +@tab fourcc: vxs1, VXS1 > > @item Amazing Studio PAF Video @tab @tab X > > @item American Laser Games MM @tab@tab X > > @tab Used in games like Mad Dog McCree. > > diff --git a/libavcodec/Makefile b/libavcodec/Makefile > > index 81cc16471b..39b3bc968d 100644 > > --- a/libavcodec/Makefile > > +++ b/libavcodec/Makefile > > @@ -182,6 +182,7 @@ OBJS-$(CONFIG_AC3_ENCODER) += > > ac3enc_float.o ac3enc.o ac3tab.o \ > > OBJS-$(CONFIG_AC3_FIXED_ENCODER) += ac3enc_fixed.o ac3enc.o ac3tab.o > > ac3.o kbdwin.o > > OBJS-$(CONFIG_AC3_MF_ENCODER) += mfenc.o mf_utils.o > > OBJS-$(CONFIG_ACELP_KELVIN_DECODER)+= g729dec.o lsp.o celp_math.o > > celp_filters.o acelp_filters.o acelp_pitch_delay.o acelp_vectors.o > > g729postfilter.o > > +OBJS-$(CONFIG_ACTIMAGINE_DECODER) += actimagine.o > > OBJS-$(CONFIG_AGM_DECODER) += agm.o > > OBJS-$(CONFIG_AIC_DECODER) += aic.o > > OBJS-$(CONFIG_ALAC_DECODER)+= alac.o alac_data.o alacdsp.o > > diff --git a/libavcodec/actimagine.c b/libavcodec/actimagine.c > > new file mode 100644 > > index 00..6bb5126b05 > > --- /dev/null > > +++ b/libavcodec/actimagine.c > > @@ -0,0 +1,1644 @@ > > +/* > > + * Actimagine VX Video decoder > > + * Copyright (c) 2021 Florian Nouwt > > + * > > + * This file is part of FFmpeg. > > + * > > + * FFmpeg is free software; you can redistribute it and/or > > + * modify it under the terms of the GNU Lesser General Public > > + * License as published by the Free Software Foundation; either > > + * version 2.1 of the License, or (at your option) any later version. > > + * > > + * FFmpeg is distributed in the hope that it will be useful, > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > > + * Lesser General Public License for more details. > > + * > > + * You should have received a copy of the GNU Lesser General Public > > + * License along with FFmpeg; if not, write to the Free Software > > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA > > 02110-1301 USA > > + */ > > + > > +#include > > + > > +#include "libavutil/avassert.h" > > +#include "libavutil/thr
Re: [FFmpeg-devel] [PATCH] avcodec: add Actimagine VX video decoder
I applied the few changes you suggested. I moved the shared tables to h264_cavlc_data.c. Am I supposed to share the actual vlc tables (such as "static VLC_TYPE coeff_token_vlc_tables[520+332+280+256][2];") which are generated by actimagine_init_static respectively ff_h264_decode_init_vlc as well? Op ma 15 mrt. 2021 om 16:10 schreef Florian Nouwt : > > Signed-off-by: Florian Nouwt > --- > Changelog|1 + > configure|1 + > doc/general_contents.texi|2 + > libavcodec/Makefile |3 +- > libavcodec/actimagine.c | 1523 ++ > libavcodec/allcodecs.c |1 + > libavcodec/codec_desc.c |7 + > libavcodec/codec_id.h|1 + > libavcodec/h264_cavlc.c | 135 +-- > libavcodec/h264_cavlc_data.c | 140 > libavcodec/h264_cavlc_data.h | 33 + > libavcodec/version.h |2 +- > libavformat/riff.c |2 + > 13 files changed, 1723 insertions(+), 128 deletions(-) > create mode 100644 libavcodec/actimagine.c > create mode 100644 libavcodec/h264_cavlc_data.c > create mode 100644 libavcodec/h264_cavlc_data.h > > diff --git a/Changelog b/Changelog > index a96e350e09..8807f3dcb3 100644 > --- a/Changelog > +++ b/Changelog > @@ -83,6 +83,7 @@ version : > - msad video filter > - gophers protocol > - RIST protocol via librist > +- Actimagine VX video decoder > > > version 4.3: > diff --git a/configure b/configure > index f0ac719d2d..10a07da95f 100755 > --- a/configure > +++ b/configure > @@ -2662,6 +2662,7 @@ ac3_fixed_decoder_select="ac3_parser ac3dsp bswapdsp > mdct" > ac3_encoder_select="ac3dsp audiodsp mdct me_cmp" > ac3_fixed_encoder_select="ac3dsp audiodsp mdct me_cmp" > acelp_kelvin_decoder_select="audiodsp" > +actimagine_decoder_select="bswapdsp golomb" > adpcm_g722_decoder_select="g722dsp" > adpcm_g722_encoder_select="g722dsp" > aic_decoder_select="golomb idctdsp" > diff --git a/doc/general_contents.texi b/doc/general_contents.texi > index 33ece6e884..d4261386fc 100644 > --- a/doc/general_contents.texi > +++ b/doc/general_contents.texi > @@ -807,6 +807,8 @@ following image formats are supported: > @item 8088flex TMV @tab @tab X > @item A64 multicolor @tab X @tab > @tab Creates video suitable to be played on a commodore 64 (multicolor > mode). > +@item Actimagine VX Video@tab @tab X > +@tab fourcc: vxs1, VXS1 > @item Amazing Studio PAF Video @tab @tab X > @item American Laser Games MM @tab@tab X > @tab Used in games like Mad Dog McCree. > diff --git a/libavcodec/Makefile b/libavcodec/Makefile > index 81cc16471b..1b90c66925 100644 > --- a/libavcodec/Makefile > +++ b/libavcodec/Makefile > @@ -182,6 +182,7 @@ OBJS-$(CONFIG_AC3_ENCODER) += ac3enc_float.o > ac3enc.o ac3tab.o \ > OBJS-$(CONFIG_AC3_FIXED_ENCODER) += ac3enc_fixed.o ac3enc.o ac3tab.o > ac3.o kbdwin.o > OBJS-$(CONFIG_AC3_MF_ENCODER) += mfenc.o mf_utils.o > OBJS-$(CONFIG_ACELP_KELVIN_DECODER)+= g729dec.o lsp.o celp_math.o > celp_filters.o acelp_filters.o acelp_pitch_delay.o acelp_vectors.o > g729postfilter.o > +OBJS-$(CONFIG_ACTIMAGINE_DECODER) += actimagine.o h264_cavlc_data.o > OBJS-$(CONFIG_AGM_DECODER) += agm.o > OBJS-$(CONFIG_AIC_DECODER) += aic.o > OBJS-$(CONFIG_ALAC_DECODER)+= alac.o alac_data.o alacdsp.o > @@ -367,7 +368,7 @@ OBJS-$(CONFIG_H264_DECODER)+= h264dec.o > h264_cabac.o h264_cavlc.o \ >h264_direct.o h264_loopfilter.o \ >h264_mb.o h264_picture.o \ >h264_refs.o h264_sei.o \ > - h264_slice.o h264data.o > + h264_slice.o h264data.o > h264_cavlc_data.o > OBJS-$(CONFIG_H264_AMF_ENCODER)+= amfenc_h264.o > OBJS-$(CONFIG_H264_CUVID_DECODER) += cuviddec.o > OBJS-$(CONFIG_H264_MEDIACODEC_DECODER) += mediacodecdec.o > diff --git a/libavcodec/actimagine.c b/libavcodec/actimagine.c > new file mode 100644 > index 00..f495426869 > --- /dev/null > +++ b/libavcodec/actimagine.c > @@ -0,0 +1,1523 @@ > +/* > + * Actimagine VX Video decoder > + * Copyright (c) 2021 Florian Nouwt > + * > + * This file is part of FFmpeg. > + * > + * FFmpeg is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Lesser General Public > + * License as published by the Free Software Foundation; either > + * version 2.1 of the License, or (at your option) any later version. > + * > + * FFmpeg is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser
[FFmpeg-devel] [PATCH] avcodec: add Actimagine VX video decoder
Signed-off-by: Florian Nouwt
---
Changelog|1 +
configure|1 +
doc/general_contents.texi|2 +
libavcodec/Makefile |3 +-
libavcodec/actimagine.c | 1523 ++
libavcodec/allcodecs.c |1 +
libavcodec/codec_desc.c |7 +
libavcodec/codec_id.h|1 +
libavcodec/h264_cavlc.c | 135 +--
libavcodec/h264_cavlc_data.c | 140
libavcodec/h264_cavlc_data.h | 33 +
libavcodec/version.h |2 +-
libavformat/riff.c |2 +
13 files changed, 1723 insertions(+), 128 deletions(-)
create mode 100644 libavcodec/actimagine.c
create mode 100644 libavcodec/h264_cavlc_data.c
create mode 100644 libavcodec/h264_cavlc_data.h
diff --git a/Changelog b/Changelog
index a96e350e09..8807f3dcb3 100644
--- a/Changelog
+++ b/Changelog
@@ -83,6 +83,7 @@ version :
- msad video filter
- gophers protocol
- RIST protocol via librist
+- Actimagine VX video decoder
version 4.3:
diff --git a/configure b/configure
index f0ac719d2d..10a07da95f 100755
--- a/configure
+++ b/configure
@@ -2662,6 +2662,7 @@ ac3_fixed_decoder_select="ac3_parser ac3dsp bswapdsp mdct"
ac3_encoder_select="ac3dsp audiodsp mdct me_cmp"
ac3_fixed_encoder_select="ac3dsp audiodsp mdct me_cmp"
acelp_kelvin_decoder_select="audiodsp"
+actimagine_decoder_select="bswapdsp golomb"
adpcm_g722_decoder_select="g722dsp"
adpcm_g722_encoder_select="g722dsp"
aic_decoder_select="golomb idctdsp"
diff --git a/doc/general_contents.texi b/doc/general_contents.texi
index 33ece6e884..d4261386fc 100644
--- a/doc/general_contents.texi
+++ b/doc/general_contents.texi
@@ -807,6 +807,8 @@ following image formats are supported:
@item 8088flex TMV @tab @tab X
@item A64 multicolor @tab X @tab
@tab Creates video suitable to be played on a commodore 64 (multicolor
mode).
+@item Actimagine VX Video@tab @tab X
+@tab fourcc: vxs1, VXS1
@item Amazing Studio PAF Video @tab @tab X
@item American Laser Games MM @tab@tab X
@tab Used in games like Mad Dog McCree.
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 81cc16471b..1b90c66925 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -182,6 +182,7 @@ OBJS-$(CONFIG_AC3_ENCODER) += ac3enc_float.o
ac3enc.o ac3tab.o \
OBJS-$(CONFIG_AC3_FIXED_ENCODER) += ac3enc_fixed.o ac3enc.o ac3tab.o
ac3.o kbdwin.o
OBJS-$(CONFIG_AC3_MF_ENCODER) += mfenc.o mf_utils.o
OBJS-$(CONFIG_ACELP_KELVIN_DECODER)+= g729dec.o lsp.o celp_math.o
celp_filters.o acelp_filters.o acelp_pitch_delay.o acelp_vectors.o
g729postfilter.o
+OBJS-$(CONFIG_ACTIMAGINE_DECODER) += actimagine.o h264_cavlc_data.o
OBJS-$(CONFIG_AGM_DECODER) += agm.o
OBJS-$(CONFIG_AIC_DECODER) += aic.o
OBJS-$(CONFIG_ALAC_DECODER)+= alac.o alac_data.o alacdsp.o
@@ -367,7 +368,7 @@ OBJS-$(CONFIG_H264_DECODER)+= h264dec.o
h264_cabac.o h264_cavlc.o \
h264_direct.o h264_loopfilter.o \
h264_mb.o h264_picture.o \
h264_refs.o h264_sei.o \
- h264_slice.o h264data.o
+ h264_slice.o h264data.o
h264_cavlc_data.o
OBJS-$(CONFIG_H264_AMF_ENCODER)+= amfenc_h264.o
OBJS-$(CONFIG_H264_CUVID_DECODER) += cuviddec.o
OBJS-$(CONFIG_H264_MEDIACODEC_DECODER) += mediacodecdec.o
diff --git a/libavcodec/actimagine.c b/libavcodec/actimagine.c
new file mode 100644
index 00..f495426869
--- /dev/null
+++ b/libavcodec/actimagine.c
@@ -0,0 +1,1523 @@
+/*
+ * Actimagine VX Video decoder
+ * Copyright (c) 2021 Florian Nouwt
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include
+
+#include "libavutil/avassert.h"
+#include "libavutil/thread.h"
+
+#include "avcodec.h"
+#include "bytestream.h"
+#include "bswapdsp.h"
+#include "get_bits.h"
+#include "golomb.h"
+#include "internal.h"
+#include "h264_cavlc_data.h"
+
+static const uint8_t predict_dc_shift_tab[] = {1, 2, 3, 0, 4};
+
+static const uint8_t zigzag4x4_tab[] =
+{
+0x00, 0x04, 0x01, 0x02, 0x05, 0x08,
Re: [FFmpeg-devel] [PATCH 1/2] avformat/mxfdec: Don't use wrong type of pointer
mån 2021-03-15 klockan 14:38 +0100 skrev Andreas Rheinhardt:
> Tomas Härdin:
> > fre 2021-03-12 klockan 14:07 +0100 skrev Andreas Rheinhardt:
> > > @@ -2922,20 +2929,19 @@ static int mxf_read_local_tags(MXFContext *mxf,
> > > KLVPacket *klv, MXFMetadataReadF
> > > }
> > > }
> > > }
> > > -if (ctx_size && tag == 0x3C0A) {
> > > -avio_read(pb, ctx->uid, 16);
> > > +if (meta && tag == 0x3C0A) {
> >
> > Why not keep this conditional on ctx_size? That way you could get rid
> > of ctx altogether
> >
>
> Because I consider it more natural to check for the existence of a
> MXFMetadataSet by checking whether a pointer to MXFMetadataSet is NULL
> or not. After all, ctx_size could also contain the size of the MXFContext.
No, it cannot. Look at mxf_metadata_read_table. ctx_size serves a dual
purpose: whether to pass MXFContext to read(), or to allocate a new
metadata element that is passed to read() instead.
/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".
Re: [FFmpeg-devel] [PATCH] doc/encoders: remove text about single bit-depth libx264 support
On 2021-03-15 18:54, Tobias Rapp wrote: In the meanwhile libx264 allows to be configured for including both 8/10 bit support within a single library. The new libx264 interface was enabled in 2f96190732d15510ba29471fa45d66841c0c3df1. Signed-off-by: Tobias Rapp --- doc/encoders.texi | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/doc/encoders.texi b/doc/encoders.texi index c9c8785a..a92eb0e 100644 --- a/doc/encoders.texi +++ b/doc/encoders.texi @@ -2305,9 +2305,7 @@ pixel formats as input instead of YUV. @subsection Supported Pixel Formats x264 supports 8- to 10-bit color spaces. The exact bit depth is controlled at -x264's configure time. FFmpeg only supports one bit depth in one particular -build. In other words, it is not possible to build one FFmpeg with multiple -versions of x264 with different bit depths. +x264's configure time. @subsection Options LGTM. Gyan ___ 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/mov: Handle when we have an mfra box but have not read the full sidx for a fragment
Use the tfra timestamp if it is available and sidx timestamp is not.
Fixes reading the entire file after seeking in a live-style DASH FMP4
with an MFRA.
This specifically fixes when use_mfra_for is set.
Signed-off-by: Derek Buitenhuis
---
I could also put it behind an additional use_mfra_for option check if that is
what people want.
---
libavformat/mov.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 23b0ead01e..97857789f4 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -1279,6 +1279,10 @@ static int64_t get_frag_time(MOVFragmentIndex
*frag_index,
if (track_id >= 0) {
frag_stream_info = get_frag_stream_info(frag_index, index, track_id);
+if (frag_stream_info->sidx_pts != AV_NOPTS_VALUE)
+return frag_stream_info->sidx_pts;
+if (frag_stream_info->first_tfra_pts != AV_NOPTS_VALUE)
+return frag_stream_info->first_tfra_pts;
return frag_stream_info->sidx_pts;
}
--
2.30.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] avcodec: add Actimagine VX video decoder
Mar 15, 2021, 16:09 by fnou...@gmail.com:
> Signed-off-by: Florian Nouwt
> ---
> Changelog|1 +
> configure|1 +
> doc/general_contents.texi|2 +
> libavcodec/Makefile |3 +-
> libavcodec/actimagine.c | 1523 ++
> libavcodec/allcodecs.c |1 +
> libavcodec/codec_desc.c |7 +
> libavcodec/codec_id.h|1 +
> libavcodec/h264_cavlc.c | 135 +--
> libavcodec/h264_cavlc_data.c | 140
> libavcodec/h264_cavlc_data.h | 33 +
> libavcodec/version.h |2 +-
> libavformat/riff.c |2 +
> 13 files changed, 1723 insertions(+), 128 deletions(-)
> create mode 100644 libavcodec/actimagine.c
> create mode 100644 libavcodec/h264_cavlc_data.c
> create mode 100644 libavcodec/h264_cavlc_data.h
>
> +static void decode_dct(AVCodecContext *avctx, int x, int y, int plane,
> + const int* level)
> +{
> +int a, b, c, d, e, f;
> +int dct[16];
> +int tmp[16];
> +ActimagineContext *s = avctx->priv_data;
> +
> +// dezigzag
> +for (int i = 0; i < 16; i++)
> +dct[zigzag4x4_tab[i]] = level[i];
> +
> +// dequantize
> +for (int i = 0; i < 2; i++) {
> +for (int j = 0; j < 4; j++) {
> +dct[4 * j + i] *= s->qtab[i][j];
> +dct[4 * j + i + 2] *= s->qtab[i][j];
> +}
> +}
> +
> +dct[0] += 32;// rounding
> +
> +for (int i = 0; i < 4; i++) {
> +a = dct[i * 4 + 0];
> +b = dct[i * 4 + 1];
> +c = dct[i * 4 + 2];
> +d = dct[i * 4 + 3];
> +a += c;
> +c = a - c * 2;
> +e = (b >> 1) - d;
> +f = b + (d >> 1);
> +tmp[ 0 + i] = a + f;
> +tmp[ 4 + i] = c + e;
> +tmp[ 8 + i] = c - e;
> +tmp[12 + i] = a - f;
> +}
> +
> +for (int i = 0; i < 4; i++) {
> +a = tmp[i * 4 + 0];
> +b = tmp[i * 4 + 1];
> +c = tmp[i * 4 + 2];
> +d = tmp[i * 4 + 3];
> +a += c;
> +c = a - c * 2;
> +e = (b >> 1) - d;
> +f = b + (d >> 1);
> +PIXEL_CUR(s, plane, x + 0, y + i)
> += av_clip_uint8(PIXEL_CUR(s, plane, x + 0, y + i) + ((a + f) >>
> 6));
> +PIXEL_CUR(s, plane, x + 1, y + i)
> += av_clip_uint8(PIXEL_CUR(s, plane, x + 1, y + i) + ((c + e) >>
> 6));
> +PIXEL_CUR(s, plane, x + 2, y + i)
> += av_clip_uint8(PIXEL_CUR(s, plane, x + 2, y + i) + ((c - e) >>
> 6));
> +PIXEL_CUR(s, plane, x + 3, y + i)
> += av_clip_uint8(PIXEL_CUR(s, plane, x + 3, y + i) + ((a - f) >>
> 6));
> +}
> +}
>
This isn't really a DCT but a WHT approximation of one. We have some
DSP functions with assembly written for this. Some have suggested that
it's similar to H264's. The predictors also look similiar to it.
Could you take a look whether you can reuse them (iwht4_1d in
libavcodec/vp9dsp_template.c), or if not, maybe rename the function
to decode_wht?
___
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: add Actimagine VX video decoder
I'll have a look if functions can be reused. If it's the case, the same
could likely be done to the mobiclip decoder too since that one does a lot
of stuff in a similar way.
The "idct" looks very similar to "ff_h264_idct_add" in h264idct_template.c.
Which would make sense since the codec is largely based on techniques used
in h264. In that function the order seems to be reversed though
(column->row, row->row instead of row->column, row->row) and I wonder if
that can have any impact on the output? (Rounding errors or so)
I think there's a good chance that h264 prediction functions can also be
used. I will check if they are 100% equal.
I have a question about the color space btw. This format uses a yuv
approximation based on bit shifting as I described in the init function.
Currently it is not supported by ffmpeg. Would there be a way to add it or
so? The regular yuv coefficients do look alright, but it is not correct.
Everything is a bit less saturated or so.
Op ma 15 mrt. 2021 18:34 schreef Lynne :
> Mar 15, 2021, 16:09 by fnou...@gmail.com:
>
> > Signed-off-by: Florian Nouwt
> > ---
> > Changelog|1 +
> > configure|1 +
> > doc/general_contents.texi|2 +
> > libavcodec/Makefile |3 +-
> > libavcodec/actimagine.c | 1523 ++
> > libavcodec/allcodecs.c |1 +
> > libavcodec/codec_desc.c |7 +
> > libavcodec/codec_id.h|1 +
> > libavcodec/h264_cavlc.c | 135 +--
> > libavcodec/h264_cavlc_data.c | 140
> > libavcodec/h264_cavlc_data.h | 33 +
> > libavcodec/version.h |2 +-
> > libavformat/riff.c |2 +
> > 13 files changed, 1723 insertions(+), 128 deletions(-)
> > create mode 100644 libavcodec/actimagine.c
> > create mode 100644 libavcodec/h264_cavlc_data.c
> > create mode 100644 libavcodec/h264_cavlc_data.h
> >
> > +static void decode_dct(AVCodecContext *avctx, int x, int y, int plane,
> > + const int* level)
> > +{
> > +int a, b, c, d, e, f;
> > +int dct[16];
> > +int tmp[16];
> > +ActimagineContext *s = avctx->priv_data;
> > +
> > +// dezigzag
> > +for (int i = 0; i < 16; i++)
> > +dct[zigzag4x4_tab[i]] = level[i];
> > +
> > +// dequantize
> > +for (int i = 0; i < 2; i++) {
> > +for (int j = 0; j < 4; j++) {
> > +dct[4 * j + i] *= s->qtab[i][j];
> > +dct[4 * j + i + 2] *= s->qtab[i][j];
> > +}
> > +}
> > +
> > +dct[0] += 32;// rounding
> > +
> > +for (int i = 0; i < 4; i++) {
> > +a = dct[i * 4 + 0];
> > +b = dct[i * 4 + 1];
> > +c = dct[i * 4 + 2];
> > +d = dct[i * 4 + 3];
> > +a += c;
> > +c = a - c * 2;
> > +e = (b >> 1) - d;
> > +f = b + (d >> 1);
> > +tmp[ 0 + i] = a + f;
> > +tmp[ 4 + i] = c + e;
> > +tmp[ 8 + i] = c - e;
> > +tmp[12 + i] = a - f;
> > +}
> > +
> > +for (int i = 0; i < 4; i++) {
> > +a = tmp[i * 4 + 0];
> > +b = tmp[i * 4 + 1];
> > +c = tmp[i * 4 + 2];
> > +d = tmp[i * 4 + 3];
> > +a += c;
> > +c = a - c * 2;
> > +e = (b >> 1) - d;
> > +f = b + (d >> 1);
> > +PIXEL_CUR(s, plane, x + 0, y + i)
> > += av_clip_uint8(PIXEL_CUR(s, plane, x + 0, y + i) + ((a +
> f) >> 6));
> > +PIXEL_CUR(s, plane, x + 1, y + i)
> > += av_clip_uint8(PIXEL_CUR(s, plane, x + 1, y + i) + ((c +
> e) >> 6));
> > +PIXEL_CUR(s, plane, x + 2, y + i)
> > += av_clip_uint8(PIXEL_CUR(s, plane, x + 2, y + i) + ((c -
> e) >> 6));
> > +PIXEL_CUR(s, plane, x + 3, y + i)
> > += av_clip_uint8(PIXEL_CUR(s, plane, x + 3, y + i) + ((a -
> f) >> 6));
> > +}
> > +}
> >
>
> This isn't really a DCT but a WHT approximation of one. We have some
> DSP functions with assembly written for this. Some have suggested that
> it's similar to H264's. The predictors also look similiar to it.
> Could you take a look whether you can reuse them (iwht4_1d in
> libavcodec/vp9dsp_template.c), or if not, maybe rename the function
> to decode_wht?
> ___
> 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] Bash 2.04.0(1)-release in configure script
On 3/15/21 1:20 PM, Hritik Vijay wrote: Hello I trying to work on the prerequisite tasks for GSoC this year. The codebase is huge and I found the following line introduced in c21d6325ab0 on line 50. if test "$BASH_VERSION" = '2.04.0(1)-release'; then echo "This bash version ($BASH_VERSION) is broken on your platform." echo "Upgrade to a later version if available." fi I'm not sure what is special about the bash version 2.04.0(1)-release. I guess the script is trying to check if BASH_VERSION is preset although the try_exec for bash failed. Should the version, in any case, be hard coded like this ? From the terminal Hritik Vijay Sent with [ProtonMail](https://protonmail.com) Secure 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". This is the thread that caused that commit: http://ffmpeg.org/pipermail/ffmpeg-devel/2006-October/017630.html Sounds like someone had an issue with MinGW, and someone just committed that to block it since it's broken (going through the release notes on that version, looks like there were multiple things that it had problems with). ___ 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: add Actimagine VX video decoder
Florian Nouwt: > I applied the few changes you suggested. I moved the shared tables to > h264_cavlc_data.c. Am I supposed to share the actual vlc tables (such > as "static VLC_TYPE coeff_token_vlc_tables[520+332+280+256][2];") > which are generated by actimagine_init_static respectively > ff_h264_decode_init_vlc as well? > Yes, please. > Op ma 15 mrt. 2021 om 16:10 schreef Florian Nouwt : >> >> Signed-off-by: Florian Nouwt >> --- >> Changelog|1 + >> configure|1 + >> doc/general_contents.texi|2 + >> libavcodec/Makefile |3 +- >> libavcodec/actimagine.c | 1523 ++ >> libavcodec/allcodecs.c |1 + >> libavcodec/codec_desc.c |7 + >> libavcodec/codec_id.h|1 + >> libavcodec/h264_cavlc.c | 135 +-- >> libavcodec/h264_cavlc_data.c | 140 >> libavcodec/h264_cavlc_data.h | 33 + >> libavcodec/version.h |2 +- >> libavformat/riff.c |2 + >> 13 files changed, 1723 insertions(+), 128 deletions(-) >> create mode 100644 libavcodec/actimagine.c >> create mode 100644 libavcodec/h264_cavlc_data.c >> create mode 100644 libavcodec/h264_cavlc_data.h >> >> diff --git a/Changelog b/Changelog >> index a96e350e09..8807f3dcb3 100644 >> --- a/Changelog >> +++ b/Changelog >> @@ -83,6 +83,7 @@ version : >> - msad video filter >> - gophers protocol >> - RIST protocol via librist >> +- Actimagine VX video decoder >> >> >> version 4.3: >> diff --git a/configure b/configure >> index f0ac719d2d..10a07da95f 100755 >> --- a/configure >> +++ b/configure >> @@ -2662,6 +2662,7 @@ ac3_fixed_decoder_select="ac3_parser ac3dsp bswapdsp >> mdct" >> ac3_encoder_select="ac3dsp audiodsp mdct me_cmp" >> ac3_fixed_encoder_select="ac3dsp audiodsp mdct me_cmp" >> acelp_kelvin_decoder_select="audiodsp" >> +actimagine_decoder_select="bswapdsp golomb" >> adpcm_g722_decoder_select="g722dsp" >> adpcm_g722_encoder_select="g722dsp" >> aic_decoder_select="golomb idctdsp" >> diff --git a/doc/general_contents.texi b/doc/general_contents.texi >> index 33ece6e884..d4261386fc 100644 >> --- a/doc/general_contents.texi >> +++ b/doc/general_contents.texi >> @@ -807,6 +807,8 @@ following image formats are supported: >> @item 8088flex TMV @tab @tab X >> @item A64 multicolor @tab X @tab >> @tab Creates video suitable to be played on a commodore 64 (multicolor >> mode). >> +@item Actimagine VX Video@tab @tab X >> +@tab fourcc: vxs1, VXS1 >> @item Amazing Studio PAF Video @tab @tab X >> @item American Laser Games MM @tab@tab X >> @tab Used in games like Mad Dog McCree. >> diff --git a/libavcodec/Makefile b/libavcodec/Makefile >> index 81cc16471b..1b90c66925 100644 >> --- a/libavcodec/Makefile >> +++ b/libavcodec/Makefile >> @@ -182,6 +182,7 @@ OBJS-$(CONFIG_AC3_ENCODER) += ac3enc_float.o >> ac3enc.o ac3tab.o \ >> OBJS-$(CONFIG_AC3_FIXED_ENCODER) += ac3enc_fixed.o ac3enc.o ac3tab.o >> ac3.o kbdwin.o >> OBJS-$(CONFIG_AC3_MF_ENCODER) += mfenc.o mf_utils.o >> OBJS-$(CONFIG_ACELP_KELVIN_DECODER)+= g729dec.o lsp.o celp_math.o >> celp_filters.o acelp_filters.o acelp_pitch_delay.o acelp_vectors.o >> g729postfilter.o >> +OBJS-$(CONFIG_ACTIMAGINE_DECODER) += actimagine.o h264_cavlc_data.o >> OBJS-$(CONFIG_AGM_DECODER) += agm.o >> OBJS-$(CONFIG_AIC_DECODER) += aic.o >> OBJS-$(CONFIG_ALAC_DECODER)+= alac.o alac_data.o alacdsp.o >> @@ -367,7 +368,7 @@ OBJS-$(CONFIG_H264_DECODER)+= h264dec.o >> h264_cabac.o h264_cavlc.o \ >>h264_direct.o h264_loopfilter.o \ >>h264_mb.o h264_picture.o \ >>h264_refs.o h264_sei.o \ >> - h264_slice.o h264data.o >> + h264_slice.o h264data.o >> h264_cavlc_data.o >> OBJS-$(CONFIG_H264_AMF_ENCODER)+= amfenc_h264.o >> OBJS-$(CONFIG_H264_CUVID_DECODER) += cuviddec.o >> OBJS-$(CONFIG_H264_MEDIACODEC_DECODER) += mediacodecdec.o >> diff --git a/libavcodec/actimagine.c b/libavcodec/actimagine.c >> new file mode 100644 >> index 00..f495426869 >> --- /dev/null >> +++ b/libavcodec/actimagine.c >> @@ -0,0 +1,1523 @@ >> +/* >> + * Actimagine VX Video decoder >> + * Copyright (c) 2021 Florian Nouwt >> + * >> + * This file is part of FFmpeg. >> + * >> + * FFmpeg is free software; you can redistribute it and/or >> + * modify it under the terms of the GNU Lesser General Public >> + * License as published by the Free Software Foundation; either >> + * version 2.1 of the License, or (at your option) any later version. >> + * >> + * FFmpeg is distributed in the hope that it will be useful, >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of >> + * MERCHANTABILITY or FITNESS FOR
Re: [FFmpeg-devel] [PATCH 1/2] avformat/mxfdec: Don't use wrong type of pointer
Tomas Härdin:
> mån 2021-03-15 klockan 14:38 +0100 skrev Andreas Rheinhardt:
>> Tomas Härdin:
>>> fre 2021-03-12 klockan 14:07 +0100 skrev Andreas Rheinhardt:
@@ -2922,20 +2929,19 @@ static int mxf_read_local_tags(MXFContext *mxf,
KLVPacket *klv, MXFMetadataReadF
}
}
}
-if (ctx_size && tag == 0x3C0A) {
-avio_read(pb, ctx->uid, 16);
+if (meta && tag == 0x3C0A) {
>>>
>>> Why not keep this conditional on ctx_size? That way you could get rid
>>> of ctx altogether
>>>
>>
>> Because I consider it more natural to check for the existence of a
>> MXFMetadataSet by checking whether a pointer to MXFMetadataSet is NULL
>> or not. After all, ctx_size could also contain the size of the MXFContext.
>
> No, it cannot. Look at mxf_metadata_read_table. ctx_size serves a dual
> purpose: whether to pass MXFContext to read(), or to allocate a new
> metadata element that is passed to read() instead.
>
I know that it can't (yes, I looked at that table), but just judging
from its name, ctx_size could also be the size of the MXFContext. And
that's why I think that using a MXFMetadataSet* is more natural.
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/4] avformat/matroskadec: Check for EOF in resync loop
On Tue, Feb 02, 2021 at 06:10:39AM +0100, Andreas Rheinhardt wrote: > Michael Niedermayer: > > Fixes: Timeout (too long -> instantly) > > Fixes: > > 29136/clusterfuzz-testcase-minimized-ffmpeg_dem_WEBM_DASH_MANIFEST_fuzzer-4586141227548672 > > > > Found-by: continuous fuzzing process > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > > Signed-off-by: Michael Niedermayer > > --- > > libavformat/matroskadec.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c > > index 374831baa3..1f28108887 100644 > > --- a/libavformat/matroskadec.c > > +++ b/libavformat/matroskadec.c > > @@ -2895,6 +2895,8 @@ static int matroska_read_header(AVFormatContext *s) > > goto fail; > > pos = avio_tell(matroska->ctx->pb); > > res = ebml_parse(matroska, matroska_segment, matroska); > > +if (res == AVERROR(EIO)) // EOF is translated to EIO, this exists > > the loop on EOF > > +goto fail; > > } > > /* Set data_offset as it might be needed later by seek_frame_generic. > > */ > > if (matroska->current_id == MATROSKA_ID_CLUSTER) > > > > I see two types of files for which this check can be problematic: Those > with an unknown-length segment and truncated files: In both cases a > child element may extend beyond the actually existing data without this > being caught by the check for whether the element extends beyond its > parent (i.e. beyond the end of the segment). > But I don't really see a > better way, so go ahead. ok, will apply thx [...] -- 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: add Actimagine VX video decoder
Mar 15, 2021, 19:37 by fnou...@gmail.com: > I'll have a look if functions can be reused. If it's the case, the same > could likely be done to the mobiclip decoder too since that one does a lot > of stuff in a similar way. > The "idct" looks very similar to "ff_h264_idct_add" in h264idct_template.c. > Which would make sense since the codec is largely based on techniques used > in h264. In that function the order seems to be reversed though > (column->row, row->row instead of row->column, row->row) and I wonder if > that can have any impact on the output? (Rounding errors or so) > I think there's a good chance that h264 prediction functions can also be > used. I will check if they are 100% equal. > The order doesn't matter, and rounding errors shouldn't occur as all your coefficients are left-shifted by 6. > I have a question about the color space btw. This format uses a yuv > approximation based on bit shifting as I described in the init function. > Currently it is not supported by ffmpeg. Would there be a way to add it or > so? The regular yuv coefficients do look alright, but it is not correct. > Everything is a bit less saturated or so. > Are there any docs or code on what the encoder uses? In general we don't do colorspace conversions in decoders, but if it's close enough that some correction can make it fit into bt601 or bt709, I think it would be okay. ___ 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: add Actimagine VX video decoder
Good to know the order doesn't matter. In that case I should be able to use it! I don't have any docs about the format because it's all proprietary, but I did some testing with the official codec for windows and the color conversion I reverse engineered from the decoder used in ds games r = y + (v << 1) g = y - (u >> 1) - v b = y + (u << 1) results in colors that are equal to whatever I throw into the codec and frames that are 1:1 equal to the output of the decoder included in the windows codec. I suppose that I would just have to allocate an extra frame if I wanted to do conversion to normal yuv colors. That frame would then be returned and the original frame would be put in the ref queue. Op ma 15 mrt. 2021 21:07 schreef Lynne : > Mar 15, 2021, 19:37 by fnou...@gmail.com: > > > I'll have a look if functions can be reused. If it's the case, the same > > could likely be done to the mobiclip decoder too since that one does a > lot > > of stuff in a similar way. > > The "idct" looks very similar to "ff_h264_idct_add" in > h264idct_template.c. > > Which would make sense since the codec is largely based on techniques > used > > in h264. In that function the order seems to be reversed though > > (column->row, row->row instead of row->column, row->row) and I wonder if > > that can have any impact on the output? (Rounding errors or so) > > I think there's a good chance that h264 prediction functions can also be > > used. I will check if they are 100% equal. > > > > The order doesn't matter, and rounding errors shouldn't occur as all your > coefficients are left-shifted by 6. > > > > I have a question about the color space btw. This format uses a yuv > > approximation based on bit shifting as I described in the init function. > > Currently it is not supported by ffmpeg. Would there be a way to add it > or > > so? The regular yuv coefficients do look alright, but it is not correct. > > Everything is a bit less saturated or so. > > > > Are there any docs or code on what the encoder uses? In general we don't > do colorspace conversions in decoders, but if it's close enough that some > correction can make it fit into bt601 or bt709, I think it would be okay. > ___ > 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 1/2] avformat/mxfdec: Don't use wrong type of pointer
mån 2021-03-15 klockan 19:48 +0100 skrev Andreas Rheinhardt:
> Tomas Härdin:
> > mån 2021-03-15 klockan 14:38 +0100 skrev Andreas Rheinhardt:
> > > Tomas Härdin:
> > > > fre 2021-03-12 klockan 14:07 +0100 skrev Andreas Rheinhardt:
> > > > > @@ -2922,20 +2929,19 @@ static int mxf_read_local_tags(MXFContext
> > > > > *mxf, KLVPacket *klv, MXFMetadataReadF
> > > > > }
> > > > > }
> > > > > }
> > > > > -if (ctx_size && tag == 0x3C0A) {
> > > > > -avio_read(pb, ctx->uid, 16);
> > > > > +if (meta && tag == 0x3C0A) {
> > > >
> > > > Why not keep this conditional on ctx_size? That way you could get rid
> > > > of ctx altogether
> > > >
> > >
> > > Because I consider it more natural to check for the existence of a
> > > MXFMetadataSet by checking whether a pointer to MXFMetadataSet is NULL
> > > or not. After all, ctx_size could also contain the size of the MXFContext.
> >
> > No, it cannot. Look at mxf_metadata_read_table. ctx_size serves a dual
> > purpose: whether to pass MXFContext to read(), or to allocate a new
> > metadata element that is passed to read() instead.
> >
> I know that it can't (yes, I looked at that table), but just judging
> from its name, ctx_size could also be the size of the MXFContext. And
> that's why I think that using a MXFMetadataSet* is more natural.
Except it isn't sizeof(MXFContext). It's zero. But anyway, this is
bikeshedding on my part since it'll work the same. I have a little
patch that adds some documentation to the function to clarify what
ctx_size does.
/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".
Re: [FFmpeg-devel] [PATCH] avcodec: add Actimagine VX video decoder
Mar 15, 2021, 21:20 by fnou...@gmail.com: > Good to know the order doesn't matter. In that case I should be able to use > it! > > I don't have any docs about the format because it's all proprietary, but I > did some testing with the official codec for windows and the color > conversion I reverse engineered from the decoder used in ds games > r = y + (v << 1) > g = y - (u >> 1) - v > b = y + (u << 1) > results in colors that are equal to whatever I throw into the codec and > frames that are 1:1 equal to the output of the decoder included in the > windows codec. > That's looking really close to YCoCg. In fact it probably is just a variant of YCoCg. You should be able to convert between both with no loss of quality or rounding errors and just mark the output frame as being YUV with a YCoCg colorspace. The wikipedia page on YCoCg has RGB<->YCoCg conversions you can follow. > I suppose that I would just have to allocate an extra frame if I wanted to > do conversion to normal yuv colors. That frame would then be returned and > the original frame would be put in the ref queue. > You could implement an inverse step when you use the reference frames, but for such a codec, where the frame size is going to be comparitively tiny, I think you can just get away quicker with copying and the converting the copied frame, while keeping your ref frames as-is. ___ 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 4/8] avformat/mxfdec: Fix file position addition
On Thu, Feb 04, 2021 at 05:07:31PM -0300, James Almer wrote:
> On 2/4/2021 3:43 PM, Tomas Härdin wrote:
> > mån 2021-02-01 klockan 23:31 +0100 skrev Michael Niedermayer:
> > > Not sure this is the best solution, maybe a more general solution
> > > limiting the avio_tell() output to less than 63bit would be a better
> > > option
> >
> > Probably, since this is likely to happen in more places
iam not sure how to handle this in a more general way.
Simply limiting avio_tell to something seems arbitrary
> >
> > > Fixes: signed integer overflow: 9223372036854775805 + 4 cannot be
> > > represented in type 'long'
> > > Fixes:
> > > 29927/clusterfuzz-testcase-minimized-ffmpeg_dem_MXF_fuzzer-5579985228267520
> > >
> > > Found-by: continuous fuzzing process
> > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > > Signed-off-by: Michael Niedermayer
> > > ---
> > > libavformat/mxfdec.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> > > index afff20402d..97a1b749fe 100644
> > > --- a/libavformat/mxfdec.c
> > > +++ b/libavformat/mxfdec.c
> > > @@ -2861,7 +2861,7 @@ static int mxf_read_local_tags(MXFContext *mxf,
> > > KLVPacket *klv, MXFMetadataReadF
> > > return AVERROR(ENOMEM);
> > > if (ctx_size)
> > > mxf_metadataset_init(ctx, type);
> > > -while (avio_tell(pb) + 4 < klv_end && !avio_feof(pb)) {
> > > +while (avio_tell(pb) + (uint64_t)4 < klv_end && !avio_feof(pb)) {
> >
> > Why not cast avio_tell() instead?
>
> Or use 4ULL
ok
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.
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/8] avcodec/utils: Use more bits for intermediate for AV_CODEC_ID_ADPCM_MS
On Mon, Feb 01, 2021 at 11:31:11PM +0100, Michael Niedermayer wrote: > Fixes: signed integer overflow: 1172577312 * 2 cannot be represented in type > 'int' > Fixes: > 29924/clusterfuzz-testcase-minimized-ffmpeg_dem_BOA_fuzzer-4882912874594304 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/utils.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The day soldiers stop bringing you their problems is the day you have stopped leading them. They have either lost confidence that you can help or concluded you do not care. Either case is a failure of leadership. - Colin Powell 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: add Actimagine VX video decoder
It's actually closer to normal yuv than ycocg. If you look at the coefficients of normal yuv r = y + 1.14v g = y - 0.39u - 0.58v b = y + 2.03u ycocg r = y + co - cg g = y + cg b = y - co - cg the format used in actimagine r = y + 2v g = y - 0.5u - v b = y + 2u You can see it's more like yuv than ycocg. That's also why currently the decoded colors still look "alright". I think it wouldn't be a good idea to use converted ref frames and then convert back as it would likely introduce errors. But like you are saying, this coded is as far as I know, never used for large frame sizes, so it shouldn't really be an issue to have an extra frame and it prevents other problems. Op ma 15 mrt. 2021 21:42 schreef Lynne : > Mar 15, 2021, 21:20 by fnou...@gmail.com: > > > Good to know the order doesn't matter. In that case I should be able to > use > > it! > > > > I don't have any docs about the format because it's all proprietary, but > I > > did some testing with the official codec for windows and the color > > conversion I reverse engineered from the decoder used in ds games > > r = y + (v << 1) > > g = y - (u >> 1) - v > > b = y + (u << 1) > > results in colors that are equal to whatever I throw into the codec and > > frames that are 1:1 equal to the output of the decoder included in the > > windows codec. > > > > That's looking really close to YCoCg. In fact it probably is just a > variant of > YCoCg. You should be able to convert between both with no loss of quality > or rounding errors and just mark the output frame as being YUV with a > YCoCg colorspace. The wikipedia page on YCoCg has RGB<->YCoCg > conversions you can follow. > > > > I suppose that I would just have to allocate an extra frame if I wanted > to > > do conversion to normal yuv colors. That frame would then be returned and > > the original frame would be put in the ref queue. > > > > You could implement an inverse step when you use the reference frames, > but for such a codec, where the frame size is going to be comparitively > tiny, I think you can just get away quicker with copying and the converting > the copied frame, while keeping your ref frames as-is. > ___ > 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/8] avformat/ipmovie: Free packets allocated in header reading
On Mon, Feb 01, 2021 at 11:31:10PM +0100, Michael Niedermayer wrote: > Fixes: memleaks > Fixes: > 29905/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5679700745781248 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavformat/ipmovie.c | 8 ++-- > 1 file changed, 6 insertions(+), 2 deletions(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In fact, the RIAA has been known to suggest that students drop out of college or go to community college in order to be able to afford settlements. -- The RIAA 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: add Actimagine VX video decoder
Mar 15, 2021, 22:02 by fnou...@gmail.com: > It's actually closer to normal yuv than ycocg. If you look at the > coefficients of normal yuv > r = y + 1.14v > g = y - 0.39u - 0.58v > b = y + 2.03u > > ycocg > r = y + co - cg > g = y + cg > b = y - co - cg > > the format used in actimagine > r = y + 2v > g = y - 0.5u - v > b = y + 2u > > You can see it's more like yuv than ycocg. That's also why currently the > decoded colors still look "alright". I think it wouldn't be a good idea to > use converted ref frames and then convert back as it would likely introduce > errors. But like you are saying, this coded is as far as I know, never used > for large frame sizes, so it shouldn't really be an issue to have an extra > frame and it prevents other problems. > Right, I couldn't remember the YUV formula offhand, and the shifts made it look like YCoCg. In that case, you can generate the magic constants to multiply, and then shift the v and u components. For such small numbers you can even do it by hand, for example 1.14/2 = 0.57 = (584 * v) >> 10. You'll want to go as high as you can when you multiply without overflowing, then shift down to decrease rounding error (it always rounds to 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] Bash 2.04.0(1)-release in configure script
Hello I trying to work on the prerequisite tasks for GSoC this year. The codebase is huge and I found the following line introduced in c21d6325ab0 on line 50. if test "$BASH_VERSION" = '2.04.0(1)-release'; then echo "This bash version ($BASH_VERSION) is broken on your platform." echo "Upgrade to a later version if available." fi I'm not sure what is special about the bash version 2.04.0(1)-release. I guess the script is trying to check if BASH_VERSION is preset although the try_exec for bash failed. Should the version, in any case, be hard coded like this ? From the terminal Hritik Vijay Sent with [ProtonMail](https://protonmail.com) Secure 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".
Re: [FFmpeg-devel] [PATCH] avcodec: add Actimagine VX video decoder
Now that I think about it, it might not be possible to an accurate straightforward conversion to regular yuv because of the subsampling. The u and v cannot just linearly be scaled to line up with the required values for regular yuv. That would mean the output would have to be in rgb format. It wouldn't really be an issue, but not the most elegant solution. Wouldn't it be possible to support these alternative coefficients in libswscale or so? I suppose that would still give issues with applications that have their own conversion algorithms. Op ma 15 mrt. 2021 22:20 schreef Lynne : > Mar 15, 2021, 22:02 by fnou...@gmail.com: > > > It's actually closer to normal yuv than ycocg. If you look at the > > coefficients of normal yuv > > r = y + 1.14v > > g = y - 0.39u - 0.58v > > b = y + 2.03u > > > > ycocg > > r = y + co - cg > > g = y + cg > > b = y - co - cg > > > > the format used in actimagine > > r = y + 2v > > g = y - 0.5u - v > > b = y + 2u > > > > You can see it's more like yuv than ycocg. That's also why currently the > > decoded colors still look "alright". I think it wouldn't be a good idea > to > > use converted ref frames and then convert back as it would likely > introduce > > errors. But like you are saying, this coded is as far as I know, never > used > > for large frame sizes, so it shouldn't really be an issue to have an > extra > > frame and it prevents other problems. > > > > Right, I couldn't remember the YUV formula offhand, and the shifts > made it look like YCoCg. > In that case, you can generate the magic constants to multiply, and > then shift the v and u components. For such small numbers you can > even do it by hand, for example 1.14/2 = 0.57 = (584 * v) >> 10. > You'll want to go as high as you can when you multiply without > overflowing, then shift down to decrease rounding error (it always > rounds to 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 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: add Actimagine VX video decoder
Mar 15, 2021, 22:54 by fnou...@gmail.com: > Now that I think about it, it might not be possible to an accurate > straightforward conversion to regular yuv because of the subsampling. The u > and v cannot just linearly be scaled to line up with the required values > for regular yuv. That would mean the output would have to be in rgb format. > It wouldn't really be an issue, but not the most elegant solution. Wouldn't > it be possible to support these alternative coefficients in libswscale or > so? I suppose that would still give issues with applications that have > their own conversion algorithms. > Sure, but none of us really want to dive into libswscale. I don't see how subsampling would be an issue, as long as the same subsampling is used, it should be fine, shouldn't 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] GSOC 2021 project Guided Filter
Hello Steven, I have implemented the code for the Guided filter. Can you guide me with the next steps? And should I submit a patch? *Regards* *Shubham* On Fri, Mar 12, 2021 at 4:36 PM Steven Liu wrote: > > > > 2021年3月12日 下午6:27，Shubham Sahoo 写道： > > > > Hi everyone, > > > > I'm Shubham Sahoo, an undergraduate student in Electronics and Electrical > > Communication Engineering from India. I would like to work on the project > > "Guided Filter" in GSOC 2021. Can anyone please guide me with the next > > steps, the qualification tasks, and the project information? > 1. You could try understand these rules under the link: > https://summerofcode.withgoogle.com/get-started/ > > 2. And understand Guided Filter Calculation: > For example: http://kaiminghe.com/eccv10/ > > 3. And try to implement a filter for that. > > > > > > 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". > > Thanks > > Steven Liu > > > > ___ > 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] avcodec: add Actimagine VX video decoder
On Mon, Mar 15, 2021 at 10:55 PM Florian Nouwt wrote: > > Now that I think about it, it might not be possible to an accurate > straightforward conversion to regular yuv because of the subsampling. The u > and v cannot just linearly be scaled to line up with the required values > for regular yuv. That would mean the output would have to be in rgb format. > It wouldn't really be an issue, but not the most elegant solution. Wouldn't > it be possible to support these alternative coefficients in libswscale or > so? I suppose that would still give issues with applications that have > their own conversion algorithms. > I don't think a single game codec warrants creating an entirely new pixel format for, unless it has a concrete independent definition and is used outside of this codec as well. Otherwise, the conversion logic looks rather straight forward and relatively cheap, and should probably just output RGB (either packed or planar, whichever is easier). It does remind me a bit of YCgCo, but with different formulas unfortunately. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] GSOC 2021 project Guided Filter
> 2021年3月16日 上午5:20，Shubham Sahoo 写道： > > Hello Steven, > > I have implemented the code for the Guided filter. Can you guide me with > the next steps? And should I submit a patch? Next step you should read GSoC rules careful, follow the rhythm of GSoC, And read some documentations: https://ffmpeg.org/contact.html#MailingLists https://ffmpeg.org/developer.html https://ffmpeg.org/git-howto.html Optimizing the Guided Filter performance and get performance data, and compare the data before and after optimization I saw you always top-posting, maybe you have not read documentations yet. > > > > *Regards* > *Shubham* > > > On Fri, Mar 12, 2021 at 4:36 PM Steven Liu wrote: > >> >> >>> 2021年3月12日 下午6:27，Shubham Sahoo 写道： >>> >>> Hi everyone, >>> >>> I'm Shubham Sahoo, an undergraduate student in Electronics and Electrical >>> Communication Engineering from India. I would like to work on the project >>> "Guided Filter" in GSOC 2021. Can anyone please guide me with the next >>> steps, the qualification tasks, and the project information? >> 1. You could try understand these rules under the link: >> https://summerofcode.withgoogle.com/get-started/ >> >> 2. And understand Guided Filter Calculation: >> For example: http://kaiminghe.com/eccv10/ >> >> 3. And try to implement a filter for that. >> >> >>> >>> 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". >> >> Thanks >> >> Steven Liu >> >> >> >> ___ >> 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". Thanks Steven Liu ___ 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/4] avcodec/adpcm_ima_cunning: support stereo
Changes the sample format to S16P, but was only ever mono so it
affects nothing.
Signed-off-by: Zane van Iperen
---
libavcodec/adpcm.c | 11 +++
tests/fate/adpcm.mak | 18 +-
2 files changed, 16 insertions(+), 13 deletions(-)
diff --git a/libavcodec/adpcm.c b/libavcodec/adpcm.c
index eb228cc47a..44f14763fb 100644
--- a/libavcodec/adpcm.c
+++ b/libavcodec/adpcm.c
@@ -111,7 +111,6 @@ static av_cold int adpcm_decode_init(AVCodecContext * avctx)
switch(avctx->codec->id) {
case AV_CODEC_ID_ADPCM_IMA_AMV:
-case AV_CODEC_ID_ADPCM_IMA_CUNNING:
max_channels = 1;
break;
case AV_CODEC_ID_ADPCM_DTK:
@@ -197,6 +196,7 @@ static av_cold int adpcm_decode_init(AVCodecContext * avctx)
switch (avctx->codec->id) {
case AV_CODEC_ID_ADPCM_AICA:
+case AV_CODEC_ID_ADPCM_IMA_CUNNING:
case AV_CODEC_ID_ADPCM_IMA_DAT4:
case AV_CODEC_ID_ADPCM_IMA_QT:
case AV_CODEC_ID_ADPCM_IMA_WAV:
@@ -1377,10 +1377,13 @@ static int adpcm_decode_frame(AVCodecContext *avctx,
void *data,
}
break;
case AV_CODEC_ID_ADPCM_IMA_CUNNING:
+for (channel = 0; channel < avctx->channels; channel++) {
+int16_t *smp = samples_p[channel];
for (n = 0; n < nb_samples / 2; n++) {
int v = bytestream2_get_byteu(&gb);
-*samples++ = adpcm_ima_cunning_expand_nibble(&c->status[0], v &
0x0F);
-*samples++ = adpcm_ima_cunning_expand_nibble(&c->status[0], v >>
4);
+*smp++ = adpcm_ima_cunning_expand_nibble(&c->status[channel], v &
0x0F);
+*smp++ = adpcm_ima_cunning_expand_nibble(&c->status[channel], v >>
4);
+}
}
break;
case AV_CODEC_ID_ADPCM_IMA_OKI:
@@ -2162,7 +2165,7 @@ ADPCM_DECODER(AV_CODEC_ID_ADPCM_EA_XAS,
sample_fmts_s16p, adpcm_ea_xas,
ADPCM_DECODER(AV_CODEC_ID_ADPCM_IMA_AMV, sample_fmts_s16, adpcm_ima_amv,
"ADPCM IMA AMV");
ADPCM_DECODER(AV_CODEC_ID_ADPCM_IMA_APC, sample_fmts_s16, adpcm_ima_apc,
"ADPCM IMA CRYO APC");
ADPCM_DECODER(AV_CODEC_ID_ADPCM_IMA_APM, sample_fmts_s16, adpcm_ima_apm,
"ADPCM IMA Ubisoft APM");
-ADPCM_DECODER(AV_CODEC_ID_ADPCM_IMA_CUNNING, sample_fmts_s16,
adpcm_ima_cunning, "ADPCM IMA Cunning Developments");
+ADPCM_DECODER(AV_CODEC_ID_ADPCM_IMA_CUNNING, sample_fmts_s16p,
adpcm_ima_cunning, "ADPCM IMA Cunning Developments");
ADPCM_DECODER(AV_CODEC_ID_ADPCM_IMA_DAT4,sample_fmts_s16, adpcm_ima_dat4,
"ADPCM IMA Eurocom DAT4");
ADPCM_DECODER(AV_CODEC_ID_ADPCM_IMA_DK3, sample_fmts_s16, adpcm_ima_dk3,
"ADPCM IMA Duck DK3");
ADPCM_DECODER(AV_CODEC_ID_ADPCM_IMA_DK4, sample_fmts_s16, adpcm_ima_dk4,
"ADPCM IMA Duck DK4");
diff --git a/tests/fate/adpcm.mak b/tests/fate/adpcm.mak
index c75a756bc3..84c6996bd4 100644
--- a/tests/fate/adpcm.mak
+++ b/tests/fate/adpcm.mak
@@ -113,31 +113,31 @@ FATE_ADPCM-$(call DEMDEC, ALP, ADPCM_IMA_ALP) +=
fate-adpcm-ima-alp-stereo
fate-adpcm-ima-alp-stereo: CMD = md5 -i $(TARGET_SAMPLES)/alp/theme-cut.tun -f
s16le
FATE_ADPCM-$(call DEMDEC, PP_BNK, ADPCM_IMA_CUNNING) +=
fate-adpcm-ima-cunning-single
-fate-adpcm-ima-cunning-single: CMD = md5 -y -i
$(TARGET_SAMPLES)/pp_bnk/GD-cut.5c -f s16le
+fate-adpcm-ima-cunning-single: CMD = md5 -y -i
$(TARGET_SAMPLES)/pp_bnk/GD-cut.5c -f s16le -af aresample
FATE_ADPCM-$(call DEMDEC, PP_BNK, ADPCM_IMA_CUNNING) +=
fate-adpcm-ima-cunning-track0
-fate-adpcm-ima-cunning-track0: CMD = md5 -y -i
$(TARGET_SAMPLES)/pp_bnk/VIDEOMOD-cut.11c -map 0:a:0 -f s16le
+fate-adpcm-ima-cunning-track0: CMD = md5 -y -i
$(TARGET_SAMPLES)/pp_bnk/VIDEOMOD-cut.11c -map 0:a:0 -f s16le -af aresample
FATE_ADPCM-$(call DEMDEC, PP_BNK, ADPCM_IMA_CUNNING) +=
fate-adpcm-ima-cunning-track1
-fate-adpcm-ima-cunning-track1: CMD = md5 -y -i
$(TARGET_SAMPLES)/pp_bnk/VIDEOMOD-cut.11c -map 0:a:1 -f s16le
+fate-adpcm-ima-cunning-track1: CMD = md5 -y -i
$(TARGET_SAMPLES)/pp_bnk/VIDEOMOD-cut.11c -map 0:a:1 -f s16le -af aresample
FATE_ADPCM-$(call DEMDEC, PP_BNK, ADPCM_IMA_CUNNING) +=
fate-adpcm-ima-cunning-trunc-t1
-fate-adpcm-ima-cunning-trunc-t1: CMD = md5 -y -i
$(TARGET_SAMPLES)/pp_bnk/VIDEOMOD-trunc-t1.11c -map 0:a:0 -f s16le
+fate-adpcm-ima-cunning-trunc-t1: CMD = md5 -y -i
$(TARGET_SAMPLES)/pp_bnk/VIDEOMOD-trunc-t1.11c -map 0:a:0 -f s16le -af aresample
FATE_ADPCM-$(call DEMDEC, PP_BNK, ADPCM_IMA_CUNNING) +=
fate-adpcm-ima-cunning-trunc-t2-track0
-fate-adpcm-ima-cunning-trunc-t2-track0: CMD = md5 -y -i
$(TARGET_SAMPLES)/pp_bnk/VIDEOMOD-trunc-t2.11c -map 0:a:0 -f s16le
+fate-adpcm-ima-cunning-trunc-t2-track0: CMD = md5 -y -i
$(TARGET_SAMPLES)/pp_bnk/VIDEOMOD-trunc-t2.11c -map 0:a:0 -f s16le -af aresample
FATE_ADPCM-$(call DEMDEC, PP_BNK, ADPCM_IMA_CUNNING) +=
fate-adpcm-ima-cunning-trunc-t2-track1
-fate-adpcm-ima-cunning-trunc-t2-track1: CMD = md5 -y -i
$(TARGET_SAMPLES)/pp_bnk/VIDEOMOD-trunc-t2.11c -map 0:a:1 -f s16le
+fate-adpcm-ima-cunning-trunc-t2-track1: CMD = md5 -y -i
$(TAR
[FFmpeg-devel] [PATCH 2/4] avcodec/adpcm_ima_cunning: reindent
Signed-off-by: Zane van Iperen
---
libavcodec/adpcm.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavcodec/adpcm.c b/libavcodec/adpcm.c
index 44f14763fb..5b6d1040af 100644
--- a/libavcodec/adpcm.c
+++ b/libavcodec/adpcm.c
@@ -1379,11 +1379,11 @@ static int adpcm_decode_frame(AVCodecContext *avctx,
void *data,
case AV_CODEC_ID_ADPCM_IMA_CUNNING:
for (channel = 0; channel < avctx->channels; channel++) {
int16_t *smp = samples_p[channel];
-for (n = 0; n < nb_samples / 2; n++) {
-int v = bytestream2_get_byteu(&gb);
-*smp++ = adpcm_ima_cunning_expand_nibble(&c->status[channel], v &
0x0F);
-*smp++ = adpcm_ima_cunning_expand_nibble(&c->status[channel], v >>
4);
-}
+for (n = 0; n < nb_samples / 2; n++) {
+int v = bytestream2_get_byteu(&gb);
+*smp++ = adpcm_ima_cunning_expand_nibble(&c->status[channel],
v & 0x0F);
+*smp++ = adpcm_ima_cunning_expand_nibble(&c->status[channel],
v >> 4);
+}
}
break;
case AV_CODEC_ID_ADPCM_IMA_OKI:
--
2.29.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/4] avformat/pp_bnk: treat music files are stereo
These files are technically a series of planar mono tracks.
If the "music" flag is set, merge the packets from the two
mono tracks, essentially replicating:
[0:a:0][0:a:1]join=inputs=2:channel_layout=stereo[a]
Signed-off-by: Zane van Iperen
---
libavformat/pp_bnk.c | 60
1 file changed, 50 insertions(+), 10 deletions(-)
diff --git a/libavformat/pp_bnk.c b/libavformat/pp_bnk.c
index 8364de1fd9..970ef09923 100644
--- a/libavformat/pp_bnk.c
+++ b/libavformat/pp_bnk.c
@@ -55,6 +55,8 @@ typedef struct PPBnkCtx {
int track_count;
PPBnkCtxTrack *tracks;
uint32_tcurrent_track;
+int is_music;
+AVPacketpkt;
} PPBnkCtx;
enum {
@@ -194,8 +196,12 @@ static int pp_bnk_read_header(AVFormatContext *s)
goto fail;
}
+ctx->is_music = (hdr.flags & PP_BNK_FLAG_MUSIC) &&
+(ctx->track_count == 2) &&
+(ctx->tracks[0].data_size == ctx->tracks[1].data_size);
+
/* Build the streams. */
-for (int i = 0; i < ctx->track_count; i++) {
+for (int i = 0; i < (ctx->is_music ? 1 : ctx->track_count); i++) {
if (!(st = avformat_new_stream(s, NULL))) {
ret = AVERROR(ENOMEM);
goto fail;
@@ -204,14 +210,21 @@ static int pp_bnk_read_header(AVFormatContext *s)
par = st->codecpar;
par->codec_type = AVMEDIA_TYPE_AUDIO;
par->codec_id = AV_CODEC_ID_ADPCM_IMA_CUNNING;
-par->format = AV_SAMPLE_FMT_S16;
-par->channel_layout = AV_CH_LAYOUT_MONO;
-par->channels = 1;
+par->format = AV_SAMPLE_FMT_S16P;
+
+if (ctx->is_music) {
+par->channel_layout = AV_CH_LAYOUT_STEREO;
+par->channels = 2;
+} else {
+par->channel_layout = AV_CH_LAYOUT_MONO;
+par->channels = 1;
+}
+
par->sample_rate= hdr.sample_rate;
par->bits_per_coded_sample = 4;
par->bits_per_raw_sample= 16;
par->block_align= 1;
-par->bit_rate = par->sample_rate *
par->bits_per_coded_sample;
+par->bit_rate = par->sample_rate *
par->bits_per_coded_sample * par->channels;
avpriv_set_pts_info(st, 64, 1, par->sample_rate);
st->start_time = 0;
@@ -253,7 +266,22 @@ static int pp_bnk_read_packet(AVFormatContext *s, AVPacket
*pkt)
size = FFMIN(trk->data_size - trk->bytes_read, PP_BNK_MAX_READ_SIZE);
-if ((ret = av_get_packet(s->pb, pkt, size)) == AVERROR_EOF) {
+if (!ctx->is_music)
+ret = av_new_packet(&ctx->pkt, size);
+else if (ctx->current_track == 0)
+ret = av_new_packet(&ctx->pkt, size * 2);
+else
+ret = 0;
+
+if (ret < 0)
+return ret;
+
+if (ctx->is_music)
+ret = avio_read(s->pb, ctx->pkt.data + size * ctx->current_track,
size);
+else
+ret = avio_read(s->pb, ctx->pkt.data, size);
+
+if (ret == AVERROR_EOF) {
/* If we've hit EOF, don't attempt this track again. */
trk->data_size = trk->bytes_read;
continue;
@@ -261,10 +289,21 @@ static int pp_bnk_read_packet(AVFormatContext *s,
AVPacket *pkt)
return ret;
}
-trk->bytes_read+= ret;
-pkt->flags &= ~AV_PKT_FLAG_CORRUPT;
-pkt->stream_index = ctx->current_track++;
-pkt->duration = ret * 2;
+trk->bytes_read+= ret;
+ctx->pkt.flags &= ~AV_PKT_FLAG_CORRUPT;
+ctx->pkt.stream_index = ctx->current_track++;
+ctx->pkt.duration = ret * 2;
+
+if (ctx->is_music) {
+if (ctx->pkt.stream_index == 0)
+return FFERROR_REDO;
+
+ctx->pkt.stream_index = 0;
+} else {
+ctx->pkt.size = ret;
+}
+
+av_packet_move_ref(pkt, &ctx->pkt);
return 0;
}
@@ -277,6 +316,7 @@ static int pp_bnk_read_close(AVFormatContext *s)
PPBnkCtx *ctx = s->priv_data;
av_freep(&ctx->tracks);
+av_packet_unref(&ctx->pkt);
return 0;
}
--
2.29.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 4/4] fate: add adpcm_ima_cunning stereo test case
Signed-off-by: Zane van Iperen --- tests/fate/adpcm.mak| 3 +++ tests/ref/fate/adpcm-ima-cunning-stereo | 1 + 2 files changed, 4 insertions(+) create mode 100644 tests/ref/fate/adpcm-ima-cunning-stereo diff --git a/tests/fate/adpcm.mak b/tests/fate/adpcm.mak index 84c6996bd4..f858a808c5 100644 --- a/tests/fate/adpcm.mak +++ b/tests/fate/adpcm.mak @@ -139,5 +139,8 @@ fate-adpcm-ima-cunning-trunc-t2a-track1: CMD = md5 -y -i $(TARGET_SAMPLES)/pp_bn FATE_ADPCM-$(call DEMDEC, PP_BNK, ADPCM_IMA_CUNNING) += fate-adpcm-ima-cunning-trunc-h2 fate-adpcm-ima-cunning-trunc-h2: CMD = md5 -y -i $(TARGET_SAMPLES)/pp_bnk/VIDEOMOD-trunc-h2.11c -map 0:a:0 -f s16le -af aresample +FATE_ADPCM-$(call DEMDEC, PP_BNK, ADPCM_IMA_CUNNING) += fate-adpcm-ima-cunning-stereo +fate-adpcm-ima-cunning-stereo: CMD = md5 -y -i $(TARGET_SAMPLES)/pp_bnk/MOGODON2-cut.44c -f s16le -af aresample + FATE_SAMPLES_AVCONV += $(FATE_ADPCM-yes) fate-adpcm: $(FATE_ADPCM-yes) diff --git a/tests/ref/fate/adpcm-ima-cunning-stereo b/tests/ref/fate/adpcm-ima-cunning-stereo new file mode 100644 index 00..7e11c8529d --- /dev/null +++ b/tests/ref/fate/adpcm-ima-cunning-stereo @@ -0,0 +1 @@ +c508235656525c97429153c639dbe8eb -- 2.29.3 ___ 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/4] avformat/pp_bnk: treat music files are stereo
Zane van Iperen:
> These files are technically a series of planar mono tracks.
> If the "music" flag is set, merge the packets from the two
> mono tracks, essentially replicating:
>
> [0:a:0][0:a:1]join=inputs=2:channel_layout=stereo[a]
>
> Signed-off-by: Zane van Iperen
> ---
> libavformat/pp_bnk.c | 60
> 1 file changed, 50 insertions(+), 10 deletions(-)
>
> diff --git a/libavformat/pp_bnk.c b/libavformat/pp_bnk.c
> index 8364de1fd9..970ef09923 100644
> --- a/libavformat/pp_bnk.c
> +++ b/libavformat/pp_bnk.c
> @@ -55,6 +55,8 @@ typedef struct PPBnkCtx {
> int track_count;
> PPBnkCtxTrack *tracks;
> uint32_tcurrent_track;
> +int is_music;
> +AVPacketpkt;
> } PPBnkCtx;
>
> enum {
> @@ -194,8 +196,12 @@ static int pp_bnk_read_header(AVFormatContext *s)
> goto fail;
> }
>
> +ctx->is_music = (hdr.flags & PP_BNK_FLAG_MUSIC) &&
> +(ctx->track_count == 2) &&
> +(ctx->tracks[0].data_size == ctx->tracks[1].data_size);
> +
> /* Build the streams. */
> -for (int i = 0; i < ctx->track_count; i++) {
> +for (int i = 0; i < (ctx->is_music ? 1 : ctx->track_count); i++) {
> if (!(st = avformat_new_stream(s, NULL))) {
> ret = AVERROR(ENOMEM);
> goto fail;
> @@ -204,14 +210,21 @@ static int pp_bnk_read_header(AVFormatContext *s)
> par = st->codecpar;
> par->codec_type = AVMEDIA_TYPE_AUDIO;
> par->codec_id = AV_CODEC_ID_ADPCM_IMA_CUNNING;
> -par->format = AV_SAMPLE_FMT_S16;
> -par->channel_layout = AV_CH_LAYOUT_MONO;
> -par->channels = 1;
> +par->format = AV_SAMPLE_FMT_S16P;
> +
> +if (ctx->is_music) {
> +par->channel_layout = AV_CH_LAYOUT_STEREO;
> +par->channels = 2;
> +} else {
> +par->channel_layout = AV_CH_LAYOUT_MONO;
> +par->channels = 1;
> +}
> +
> par->sample_rate= hdr.sample_rate;
> par->bits_per_coded_sample = 4;
> par->bits_per_raw_sample= 16;
> par->block_align= 1;
> -par->bit_rate = par->sample_rate *
> par->bits_per_coded_sample;
> +par->bit_rate = par->sample_rate *
> par->bits_per_coded_sample * par->channels;
>
> avpriv_set_pts_info(st, 64, 1, par->sample_rate);
> st->start_time = 0;
> @@ -253,7 +266,22 @@ static int pp_bnk_read_packet(AVFormatContext *s,
> AVPacket *pkt)
>
> size = FFMIN(trk->data_size - trk->bytes_read, PP_BNK_MAX_READ_SIZE);
>
> -if ((ret = av_get_packet(s->pb, pkt, size)) == AVERROR_EOF) {
> +if (!ctx->is_music)
> +ret = av_new_packet(&ctx->pkt, size);
> +else if (ctx->current_track == 0)
> +ret = av_new_packet(&ctx->pkt, size * 2);
> +else
> +ret = 0;
> +
> +if (ret < 0)
> +return ret;
> +
> +if (ctx->is_music)
> +ret = avio_read(s->pb, ctx->pkt.data + size *
> ctx->current_track, size);
> +else
> +ret = avio_read(s->pb, ctx->pkt.data, size);
> +
> +if (ret == AVERROR_EOF) {
> /* If we've hit EOF, don't attempt this track again. */
> trk->data_size = trk->bytes_read;
> continue;
> @@ -261,10 +289,21 @@ static int pp_bnk_read_packet(AVFormatContext *s,
> AVPacket *pkt)
> return ret;
> }
>
> -trk->bytes_read+= ret;
> -pkt->flags &= ~AV_PKT_FLAG_CORRUPT;
> -pkt->stream_index = ctx->current_track++;
> -pkt->duration = ret * 2;
> +trk->bytes_read+= ret;
> +ctx->pkt.flags &= ~AV_PKT_FLAG_CORRUPT;
> +ctx->pkt.stream_index = ctx->current_track++;
> +ctx->pkt.duration = ret * 2;
> +
> +if (ctx->is_music) {
> +if (ctx->pkt.stream_index == 0)
> +return FFERROR_REDO;
Wouldn't a simple continue have the same effect? This would allow to
avoid the temporary packet.
> +
> +ctx->pkt.stream_index = 0;
> +} else {
> +ctx->pkt.size = ret;
> +}
> +
> +av_packet_move_ref(pkt, &ctx->pkt);
> return 0;
> }
>
> @@ -277,6 +316,7 @@ static int pp_bnk_read_close(AVFormatContext *s)
> PPBnkCtx *ctx = s->priv_data;
>
> av_freep(&ctx->tracks);
> +av_packet_unref(&ctx->pkt);
>
> return 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 "unsubscri
