Re: [FFmpeg-devel] [PATCH 2/3] lavc/libxavs2: use upper layer qp parameters first
> 在 2019年1月22日，下午2:38，hwrenx 写道：
>
> Signed-off-by: hwrenx
> ---
> libavcodec/libxavs2.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/libxavs2.c b/libavcodec/libxavs2.c
> index 2d29427..0ad9ca9 100644
> --- a/libavcodec/libxavs2.c
> +++ b/libavcodec/libxavs2.c
> @@ -109,8 +109,9 @@ static av_cold int xavs2_init(AVCodecContext *avctx)
> xavs2_opt_set2("RateControl", "%d", 1);
> xavs2_opt_set2("TargetBitRate", "%"PRId64"", avctx->bit_rate);
> xavs2_opt_set2("InitialQP", "%d", cae->initial_qp);
> -xavs2_opt_set2("MaxQP", "%d", cae->max_qp);
> -xavs2_opt_set2("MinQP", "%d", cae->min_qp);
> +xavs2_opt_set2("MaxQP", "%d", avctx->qmax >= 0 ? avctx->qmax
> : cae->max_qp);
> +xavs2_opt_set2("MinQP", "%d", avctx->qmin >= 0 ? avctx->qmin
> : cae->min_qp);
> +
empty line
> } else {
> xavs2_opt_set2("InitialQP", "%d", cae->qp);
> }
> --
> 2.7.4
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] lavc/libdavs2: fix parameter setting error
> 在 2019年1月22日，下午2:38，hwrenx 写道：
>
> Signed-off-by: hwrenx
> ---
> libavcodec/libdavs2.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/libdavs2.c b/libavcodec/libdavs2.c
> index cf75656..f8f1b05 100644
> --- a/libavcodec/libdavs2.c
> +++ b/libavcodec/libdavs2.c
> @@ -45,10 +45,11 @@ static av_cold int davs2_init(AVCodecContext *avctx)
>/* init the decoder */
>cad->param.threads = avctx->thread_count;
>cad->param.info_level = 0;
> -cad->decoder= davs2_decoder_open(&cad->param);
>cad->param.disable_avx = !(cpu_flags & AV_CPU_FLAG_AVX &&
>cpu_flags & AV_CPU_FLAG_AVX2);
>
> +cad->decoder= davs2_decoder_open(&cad->param);
> +
empty line
>if (!cad->decoder) {
>av_log(avctx, AV_LOG_ERROR, "decoder created error.");
>return AVERROR_EXTERNAL;
> --
> 2.7.4
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec: add ARBC decoder
Thanks Kostya for great help in reversing binary.
Signed-off-by: Paul B Mahol
---
libavcodec/Makefile | 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/arbc.c | 203
libavcodec/avcodec.h| 1 +
libavcodec/codec_desc.c | 7 ++
libavformat/riff.c | 1 +
6 files changed, 214 insertions(+)
create mode 100644 libavcodec/arbc.c
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index bf746c143d..8e240aecf0 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -198,6 +198,7 @@ OBJS-$(CONFIG_APTX_HD_DECODER) += aptx.o
OBJS-$(CONFIG_APTX_HD_ENCODER) += aptx.o
OBJS-$(CONFIG_APNG_DECODER)+= png.o pngdec.o pngdsp.o
OBJS-$(CONFIG_APNG_ENCODER)+= png.o pngenc.o
+OBJS-$(CONFIG_ARBC_DECODER)+= arbc.o
OBJS-$(CONFIG_SSA_DECODER) += assdec.o ass.o
OBJS-$(CONFIG_SSA_ENCODER) += assenc.o ass.o
OBJS-$(CONFIG_ASS_DECODER) += assdec.o ass.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index fe0376e27e..5cbb09a5a4 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -41,6 +41,7 @@ extern AVCodec ff_anm_decoder;
extern AVCodec ff_ansi_decoder;
extern AVCodec ff_apng_encoder;
extern AVCodec ff_apng_decoder;
+extern AVCodec ff_arbc_decoder;
extern AVCodec ff_asv1_encoder;
extern AVCodec ff_asv1_decoder;
extern AVCodec ff_asv2_encoder;
diff --git a/libavcodec/arbc.c b/libavcodec/arbc.c
new file mode 100644
index 00..59a1d7bf0a
--- /dev/null
+++ b/libavcodec/arbc.c
@@ -0,0 +1,203 @@
+/*
+ * Gryphon's Anim Compressor decoder
+ * Copyright (c) 2018 Paul B Mahol
+ *
+ * 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
+#include
+
+#include "libavutil/imgutils.h"
+#include "libavutil/internal.h"
+#include "libavutil/intreadwrite.h"
+#include "libavutil/mem.h"
+
+#include "avcodec.h"
+#include "bytestream.h"
+#include "internal.h"
+
+typedef struct ARBCContext {
+GetByteContext gb;
+
+AVFrame *prev_frame;
+} ARBCContext;
+
+static void fill_tile4(AVCodecContext *avctx, uint8_t *color, AVFrame *frame)
+{
+ARBCContext *s = avctx->priv_data;
+GetByteContext *gb = &s->gb;
+int nb_tiles = bytestream2_get_le16(gb);
+int h = avctx->height - 1;
+
+for (int i = 0; i < nb_tiles; i++) {
+int y = bytestream2_get_byte(gb);
+int x = bytestream2_get_byte(gb);
+uint16_t mask = bytestream2_get_le16(gb);
+int start_y = y * 4, start_x = x * 4;
+int end_y = start_y + 4, end_x = start_x + 4;
+
+for (int j = start_y; j < end_y; j++) {
+for (int k = start_x; k < end_x; k++) {
+if (mask & 0x8000) {
+if (j >= avctx->height || k >= avctx->width)
+continue;
+frame->data[0][frame->linesize[0] * (h - j) + 3 * k + 0] =
color[0];
+frame->data[0][frame->linesize[0] * (h - j) + 3 * k + 1] =
color[1];
+frame->data[0][frame->linesize[0] * (h - j) + 3 * k + 2] =
color[2];
+}
+mask = mask << 1;
+}
+}
+}
+}
+
+static void fill_tileX(AVCodecContext *avctx, int tile_width, int tile_height,
+ uint8_t *color, AVFrame *frame)
+{
+ARBCContext *s = avctx->priv_data;
+GetByteContext *gb = &s->gb;
+const int step_h = tile_height / 4;
+const int step_w = tile_width / 4;
+int nb_tiles = bytestream2_get_le16(gb);
+int h = avctx->height - 1;
+
+for (int i = 0; i < nb_tiles; i++) {
+int y = bytestream2_get_byte(gb);
+int x = bytestream2_get_byte(gb);
+uint16_t mask = bytestream2_get_le16(gb);
+int start_y = y * tile_height, start_x = x * tile_width;
+int end_y = start_y + tile_height, end_x = start_x + tile_width;
+
+for (int j = start_y; j < end_y; j += step_h) {
+for (int k = start_x; k < end_x; k += step_w) {
+if (mask & 0x8000U) {
+for (int m = 0; m < step_h; m++) {
+for (int n = 0; n < step_w; n++) {
+if (j + m >= avctx->height || k + n >=
avctx->width)
+
Re: [FFmpeg-devel] [PATCH]lavf/cafdec: Do not fail hard for files ending with junk
2019-01-15 13:17 GMT+01:00, Paul B Mahol : > On 1/15/19, Carl Eugen Hoyos wrote: >> 2019-01-15 12:53 GMT+01:00, Paul B Mahol : >>> On 1/15/19, Carl Eugen Hoyos wrote: 2019-01-15 10:23 GMT+01:00, Paul B Mahol : > On 1/15/19, Carl Eugen Hoyos wrote: >> A user provided a real-life caf file ending with junk after the data >> chunk, QuickTime reads such files. >> >> Please comment, Carl Eugen >> > > NACK, there is data after junk bytes, which would get simply > discarded with your patch. Please elaborate: I don't think any data gets discarded because of this patch. >>> >>> I told you already, hex edit size of data chunk to very big number and >>> play file again. >> >> Of course. >> >> But how does this change the output compared to my patch? >> > > It does change, full length of audio is: > > MD5=5128bc2cd0e7b0560f15dd4c0546d1a0rate= 0.0kbits/s speed= 777x > size= 0kB time=00:09:18.16 bitrate= 0.0kbits/s speed= 769x Sorry for the delay: QuickTime Player only plays the file for ~6:20. Playing the file longer would be an issue since atoms after the data atom are allowed. And most important: This is unrelated, my patch is about playing a file that is supposed to be played but currently doesn't work. If there is something else to be improved, it should be a separate patch. Please comment, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/cafdec: Do not fail hard for files ending with junk
On 1/22/19, Carl Eugen Hoyos wrote: > 2019-01-15 13:17 GMT+01:00, Paul B Mahol : >> On 1/15/19, Carl Eugen Hoyos wrote: >>> 2019-01-15 12:53 GMT+01:00, Paul B Mahol : On 1/15/19, Carl Eugen Hoyos wrote: > 2019-01-15 10:23 GMT+01:00, Paul B Mahol : >> On 1/15/19, Carl Eugen Hoyos wrote: > >>> A user provided a real-life caf file ending with junk after the data >>> chunk, QuickTime reads such files. >>> >>> Please comment, Carl Eugen >>> >> >> NACK, there is data after junk bytes, which would get simply >> discarded with your patch. > > Please elaborate: I don't think any data gets discarded because > of this patch. I told you already, hex edit size of data chunk to very big number and play file again. >>> >>> Of course. >>> >>> But how does this change the output compared to my patch? >>> >> >> It does change, full length of audio is: >> >> MD5=5128bc2cd0e7b0560f15dd4c0546d1a0rate= 0.0kbits/s speed= 777x >> size= 0kB time=00:09:18.16 bitrate= 0.0kbits/s speed= 769x > > Sorry for the delay: > QuickTime Player only plays the file for ~6:20. > Playing the file longer would be an issue since atoms after the > data atom are allowed. > And most important: This is unrelated, my patch is about playing > a file that is supposed to be played but currently doesn't work. > If there is something else to be improved, it should be a separate > patch. > > Please comment, Carl Eugen You can not claim it fixes playback. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/cafdec: Do not fail hard for files ending with junk
On 1/22/19, Paul B Mahol wrote: > On 1/22/19, Carl Eugen Hoyos wrote: >> 2019-01-15 13:17 GMT+01:00, Paul B Mahol : >>> On 1/15/19, Carl Eugen Hoyos wrote: 2019-01-15 12:53 GMT+01:00, Paul B Mahol : > On 1/15/19, Carl Eugen Hoyos wrote: >> 2019-01-15 10:23 GMT+01:00, Paul B Mahol : >>> On 1/15/19, Carl Eugen Hoyos wrote: >> A user provided a real-life caf file ending with junk after the data chunk, QuickTime reads such files. Please comment, Carl Eugen >>> >>> NACK, there is data after junk bytes, which would get simply >>> discarded with your patch. >> >> Please elaborate: I don't think any data gets discarded because >> of this patch. > > I told you already, hex edit size of data chunk to very big number and > play file again. Of course. But how does this change the output compared to my patch? >>> >>> It does change, full length of audio is: >>> >>> MD5=5128bc2cd0e7b0560f15dd4c0546d1a0rate= 0.0kbits/s speed= 777x >>> size= 0kB time=00:09:18.16 bitrate= 0.0kbits/s speed= 769x >> >> Sorry for the delay: >> QuickTime Player only plays the file for ~6:20. >> Playing the file longer would be an issue since atoms after the >> data atom are allowed. >> And most important: This is unrelated, my patch is about playing >> a file that is supposed to be played but currently doesn't work. >> If there is something else to be improved, it should be a separate >> patch. >> >> Please comment, Carl Eugen > > You can not claim it fixes playback. Also you can not claim there is junk. There is real sound there. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/cafdec: Do not fail hard for files ending with junk
2019-01-22 11:28 GMT+01:00, Paul B Mahol : > On 1/22/19, Paul B Mahol wrote: >> On 1/22/19, Carl Eugen Hoyos wrote: >>> 2019-01-15 13:17 GMT+01:00, Paul B Mahol : On 1/15/19, Carl Eugen Hoyos wrote: > 2019-01-15 12:53 GMT+01:00, Paul B Mahol : >> On 1/15/19, Carl Eugen Hoyos wrote: >>> 2019-01-15 10:23 GMT+01:00, Paul B Mahol : On 1/15/19, Carl Eugen Hoyos wrote: >>> > A user provided a real-life caf file ending with junk after the > data > chunk, QuickTime reads such files. > > Please comment, Carl Eugen > NACK, there is data after junk bytes, which would get simply discarded with your patch. >>> >>> Please elaborate: I don't think any data gets discarded because >>> of this patch. >> >> I told you already, hex edit size of data chunk to very big number and >> play file again. > > Of course. > > But how does this change the output compared to my patch? > It does change, full length of audio is: MD5=5128bc2cd0e7b0560f15dd4c0546d1a0rate= 0.0kbits/s speed= 777x size= 0kB time=00:09:18.16 bitrate= 0.0kbits/s speed= 769x >>> >>> Sorry for the delay: >>> QuickTime Player only plays the file for ~6:20. >>> Playing the file longer would be an issue since atoms after the >>> data atom are allowed. >>> And most important: This is unrelated, my patch is about playing >>> a file that is supposed to be played but currently doesn't work. >>> If there is something else to be improved, it should be a separate >>> patch. >>> >>> Please comment, Carl Eugen >> >> You can not claim it fixes playback. It does here: The file does not play without my patch, it plays (for the right duration) with my patch. > Also you can not claim there is junk. There is real sound there. So you want me to change the commit message, is that correct? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/cafdec: Do not fail hard for files ending with junk
On 1/22/19, Carl Eugen Hoyos wrote: > 2019-01-22 11:28 GMT+01:00, Paul B Mahol : >> On 1/22/19, Paul B Mahol wrote: >>> On 1/22/19, Carl Eugen Hoyos wrote: 2019-01-15 13:17 GMT+01:00, Paul B Mahol : > On 1/15/19, Carl Eugen Hoyos wrote: >> 2019-01-15 12:53 GMT+01:00, Paul B Mahol : >>> On 1/15/19, Carl Eugen Hoyos wrote: 2019-01-15 10:23 GMT+01:00, Paul B Mahol : > On 1/15/19, Carl Eugen Hoyos wrote: >> A user provided a real-life caf file ending with junk after the >> data >> chunk, QuickTime reads such files. >> >> Please comment, Carl Eugen >> > > NACK, there is data after junk bytes, which would get simply > discarded with your patch. Please elaborate: I don't think any data gets discarded because of this patch. >>> >>> I told you already, hex edit size of data chunk to very big number >>> and >>> play file again. >> >> Of course. >> >> But how does this change the output compared to my patch? >> > > It does change, full length of audio is: > > MD5=5128bc2cd0e7b0560f15dd4c0546d1a0rate= 0.0kbits/s speed= 777x > size= 0kB time=00:09:18.16 bitrate= 0.0kbits/s speed= 769x Sorry for the delay: QuickTime Player only plays the file for ~6:20. Playing the file longer would be an issue since atoms after the data atom are allowed. And most important: This is unrelated, my patch is about playing a file that is supposed to be played but currently doesn't work. If there is something else to be improved, it should be a separate patch. Please comment, Carl Eugen >>> >>> You can not claim it fixes playback. > > It does here: The file does not play without my patch, it plays > (for the right duration) with my patch. > Duration is not right at all. >> Also you can not claim there is junk. There is real sound there. > > So you want me to change the commit message, is that > correct? I mentioned just one issue of many. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/cafdec: Do not fail hard for files ending with junk
2019-01-22 11:38 GMT+01:00, Paul B Mahol : > On 1/22/19, Carl Eugen Hoyos wrote: >> 2019-01-22 11:28 GMT+01:00, Paul B Mahol : >>> On 1/22/19, Paul B Mahol wrote: On 1/22/19, Carl Eugen Hoyos wrote: > 2019-01-15 13:17 GMT+01:00, Paul B Mahol : >> On 1/15/19, Carl Eugen Hoyos wrote: >>> 2019-01-15 12:53 GMT+01:00, Paul B Mahol : On 1/15/19, Carl Eugen Hoyos wrote: > 2019-01-15 10:23 GMT+01:00, Paul B Mahol : >> On 1/15/19, Carl Eugen Hoyos wrote: > >>> A user provided a real-life caf file ending with junk after the >>> data >>> chunk, QuickTime reads such files. >>> >>> Please comment, Carl Eugen >>> >> >> NACK, there is data after junk bytes, which would get simply >> discarded with your patch. > > Please elaborate: I don't think any data gets discarded because > of this patch. I told you already, hex edit size of data chunk to very big number and play file again. >>> >>> Of course. >>> >>> But how does this change the output compared to my patch? >>> >> >> It does change, full length of audio is: >> >> MD5=5128bc2cd0e7b0560f15dd4c0546d1a0rate= 0.0kbits/s speed= 777x >> size= 0kB time=00:09:18.16 bitrate= 0.0kbits/s speed= 769x > > Sorry for the delay: > QuickTime Player only plays the file for ~6:20. > Playing the file longer would be an issue since atoms after the > data atom are allowed. > And most important: This is unrelated, my patch is about playing > a file that is supposed to be played but currently doesn't work. > If there is something else to be improved, it should be a separate > patch. > > Please comment, Carl Eugen You can not claim it fixes playback. >> >> It does here: The file does not play without my patch, it plays >> (for the right duration) with my patch. > > Duration is not right at all. Does QuickTime play the file longer for you than FFmpeg with my patch? Or do I misunderstand you? >>> Also you can not claim there is junk. There is real sound there. >> >> So you want me to change the commit message, is that >> correct? > > I mentioned just one issue of many. That is unfortunately not helpful: Please explain what is wrong with the patch. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/cafdec: Do not fail hard for files ending with junk
On 1/22/19, Carl Eugen Hoyos wrote: > 2019-01-22 11:38 GMT+01:00, Paul B Mahol : >> On 1/22/19, Carl Eugen Hoyos wrote: >>> 2019-01-22 11:28 GMT+01:00, Paul B Mahol : On 1/22/19, Paul B Mahol wrote: > On 1/22/19, Carl Eugen Hoyos wrote: >> 2019-01-15 13:17 GMT+01:00, Paul B Mahol : >>> On 1/15/19, Carl Eugen Hoyos wrote: 2019-01-15 12:53 GMT+01:00, Paul B Mahol : > On 1/15/19, Carl Eugen Hoyos wrote: >> 2019-01-15 10:23 GMT+01:00, Paul B Mahol : >>> On 1/15/19, Carl Eugen Hoyos wrote: >> A user provided a real-life caf file ending with junk after the data chunk, QuickTime reads such files. Please comment, Carl Eugen >>> >>> NACK, there is data after junk bytes, which would get simply >>> discarded with your patch. >> >> Please elaborate: I don't think any data gets discarded because >> of this patch. > > I told you already, hex edit size of data chunk to very big number > and > play file again. Of course. But how does this change the output compared to my patch? >>> >>> It does change, full length of audio is: >>> >>> MD5=5128bc2cd0e7b0560f15dd4c0546d1a0rate= 0.0kbits/s speed= 777x >>> size= 0kB time=00:09:18.16 bitrate= 0.0kbits/s speed= 769x >> >> Sorry for the delay: >> QuickTime Player only plays the file for ~6:20. >> Playing the file longer would be an issue since atoms after the >> data atom are allowed. >> And most important: This is unrelated, my patch is about playing >> a file that is supposed to be played but currently doesn't work. >> If there is something else to be improved, it should be a separate >> patch. >> >> Please comment, Carl Eugen > > You can not claim it fixes playback. >>> >>> It does here: The file does not play without my patch, it plays >>> (for the right duration) with my patch. >> >> Duration is not right at all. > > Does QuickTime play the file longer for you than FFmpeg > with my patch? > Or do I misunderstand you? Correct duration is one I showed it here. > Also you can not claim there is junk. There is real sound there. >>> >>> So you want me to change the commit message, is that >>> correct? >> >> I mentioned just one issue of many. > > That is unfortunately not helpful: Please explain what is > wrong with the patch. I already said what is wrong in my previous mails, why should I repeat myself all over again? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil: Rename RSHIFT macro to ROUNDED_RSHIFT
2019-01-21 21:47 GMT+01:00, James Almer :
> On 1/21/2019 4:09 PM, FeRD (Frank Dana) wrote:
>> The RSHIFT macro in libavutil/common.h does not actually perform
>> a bitwise right-shift, but rather a rounded version of the same
>> operation, as is noted by a comment above the macro. The rounded
>> divsion macro on the very next line is named ROUNDED_DIV, which
>> seems far more clear.
>>
>> This patch renames RSHIFT to ROUNDED_RSHIFT, then updates all
>> uses of the macro to use the new name. (These are all located
>> in three codec files under libavcodec/.)
>>
>> Signed-off-by: FeRD (Frank Dana)
>> ---
>> libavcodec/mpeg4videodec.c | 4 ++--
>> libavcodec/vp3.c | 16
>> libavcodec/vp56.c | 4 ++--
>> libavutil/common.h | 2 +-
>> 4 files changed, 13 insertions(+), 13 deletions(-)
>>
>> diff --git a/libavcodec/mpeg4videodec.c b/libavcodec/mpeg4videodec.c
>> index f44ee76bd4..5d63ba12ba 100644
>> --- a/libavcodec/mpeg4videodec.c
>> +++ b/libavcodec/mpeg4videodec.c
>> @@ -601,7 +601,7 @@ static inline int get_amv(Mpeg4DecContext *ctx, int n)
>> if (ctx->divx_version == 500 && ctx->divx_build == 413 && a >=
>> s->quarter_sample)
>> sum = s->sprite_offset[0][n] / (1 << (a -
>> s->quarter_sample));
>> else
>> -sum = RSHIFT(s->sprite_offset[0][n] * (1 <<
>> s->quarter_sample), a);
>> +sum = ROUNDED_RSHIFT(s->sprite_offset[0][n] * (1 <<
>> s->quarter_sample), a);
>> } else {
>> dx= s->sprite_delta[n][0];
>> dy= s->sprite_delta[n][1];
>> @@ -623,7 +623,7 @@ static inline int get_amv(Mpeg4DecContext *ctx, int n)
>> v += dx;
>> }
>> }
>> -sum = RSHIFT(sum, a + 8 - s->quarter_sample);
>> +sum = ROUNDED_RSHIFT(sum, a + 8 - s->quarter_sample);
>> }
>>
>> if (sum < -len)
>> diff --git a/libavcodec/vp3.c b/libavcodec/vp3.c
>> index a5d8c2ed0b..13b3d6e22a 100644
>> --- a/libavcodec/vp3.c
>> +++ b/libavcodec/vp3.c
>> @@ -861,10 +861,10 @@ static int unpack_vectors(Vp3DecodeContext *s,
>> GetBitContext *gb)
>>
>> if (s->chroma_y_shift) {
>> if (s->macroblock_coding[current_macroblock] ==
>> MODE_INTER_FOURMV) {
>> -motion_x[0] = RSHIFT(motion_x[0] + motion_x[1] +
>> - motion_x[2] + motion_x[3],
>> 2);
>> -motion_y[0] = RSHIFT(motion_y[0] + motion_y[1] +
>> - motion_y[2] + motion_y[3],
>> 2);
>> +motion_x[0] = ROUNDED_RSHIFT(motion_x[0] +
>> motion_x[1] +
>> + motion_x[2] +
>> motion_x[3], 2);
>> +motion_y[0] = ROUNDED_RSHIFT(motion_y[0] +
>> motion_y[1] +
>> + motion_y[2] +
>> motion_y[3], 2);
>> }
>> motion_x[0] = (motion_x[0] >> 1) | (motion_x[0] & 1);
>> motion_y[0] = (motion_y[0] >> 1) | (motion_y[0] & 1);
>> @@ -873,10 +873,10 @@ static int unpack_vectors(Vp3DecodeContext *s,
>> GetBitContext *gb)
>> s->motion_val[1][frag][1] = motion_y[0];
>> } else if (s->chroma_x_shift) {
>> if (s->macroblock_coding[current_macroblock] ==
>> MODE_INTER_FOURMV) {
>> -motion_x[0] = RSHIFT(motion_x[0] + motion_x[1],
>> 1);
>> -motion_y[0] = RSHIFT(motion_y[0] + motion_y[1],
>> 1);
>> -motion_x[1] = RSHIFT(motion_x[2] + motion_x[3],
>> 1);
>> -motion_y[1] = RSHIFT(motion_y[2] + motion_y[3],
>> 1);
>> +motion_x[0] = ROUNDED_RSHIFT(motion_x[0] +
>> motion_x[1], 1);
>> +motion_y[0] = ROUNDED_RSHIFT(motion_y[0] +
>> motion_y[1], 1);
>> +motion_x[1] = ROUNDED_RSHIFT(motion_x[2] +
>> motion_x[3], 1);
>> +motion_y[1] = ROUNDED_RSHIFT(motion_y[2] +
>> motion_y[3], 1);
>> } else {
>> motion_x[1] = motion_x[0];
>> motion_y[1] = motion_y[0];
>> diff --git a/libavcodec/vp56.c b/libavcodec/vp56.c
>> index b69fe6c176..9359b48bc6 100644
>> --- a/libavcodec/vp56.c
>> +++ b/libavcodec/vp56.c
>> @@ -197,8 +197,8 @@ static void vp56_decode_4mv(VP56Context *s, int row,
>> int col)
>>
>> /* chroma vectors are average luma vectors */
>> if (s->avctx->codec->id == AV_CODEC_ID_VP5) {
>> -s->mv[4].x = s->mv[5].x = RSHIFT(mv.x,2);
>> -s->mv[4].y = s->mv[5].y = RSHIFT(mv.y,2);
>> +s->mv[4].x = s->mv[5].x = ROUNDED_RSHIFT(mv.x,2);
>> +s->mv[4].y = s->mv[5].y = ROUNDED_RSHIFT(mv.y,2);
>> } else {
>> s->mv[4] = s->mv[5] = (VP56mv) {mv.x/4, mv.y/4};
>> }
>> diff --git a/libavutil/common.h b/libavutil/common.h
>> i
Re: [FFmpeg-devel] [PATCH]lavf/cafdec: Do not fail hard for files ending with junk
2019-01-22 11:56 GMT+01:00, Paul B Mahol : > On 1/22/19, Carl Eugen Hoyos wrote: >> 2019-01-22 11:38 GMT+01:00, Paul B Mahol : >>> On 1/22/19, Carl Eugen Hoyos wrote: 2019-01-22 11:28 GMT+01:00, Paul B Mahol : > On 1/22/19, Paul B Mahol wrote: >> On 1/22/19, Carl Eugen Hoyos wrote: >>> 2019-01-15 13:17 GMT+01:00, Paul B Mahol : On 1/15/19, Carl Eugen Hoyos wrote: > 2019-01-15 12:53 GMT+01:00, Paul B Mahol : >> On 1/15/19, Carl Eugen Hoyos wrote: >>> 2019-01-15 10:23 GMT+01:00, Paul B Mahol : On 1/15/19, Carl Eugen Hoyos wrote: >>> > A user provided a real-life caf file ending with junk after the > data > chunk, QuickTime reads such files. > > Please comment, Carl Eugen > NACK, there is data after junk bytes, which would get simply discarded with your patch. >>> >>> Please elaborate: I don't think any data gets discarded because >>> of this patch. >> >> I told you already, hex edit size of data chunk to very big number >> and >> play file again. > > Of course. > > But how does this change the output compared to my patch? > It does change, full length of audio is: MD5=5128bc2cd0e7b0560f15dd4c0546d1a0rate= 0.0kbits/s speed= 777x size= 0kB time=00:09:18.16 bitrate= 0.0kbits/s speed= 769x >>> >>> Sorry for the delay: >>> QuickTime Player only plays the file for ~6:20. >>> Playing the file longer would be an issue since atoms after the >>> data atom are allowed. >>> And most important: This is unrelated, my patch is about playing >>> a file that is supposed to be played but currently doesn't work. >>> If there is something else to be improved, it should be a separate >>> patch. >>> >>> Please comment, Carl Eugen >> >> You can not claim it fixes playback. It does here: The file does not play without my patch, it plays (for the right duration) with my patch. >>> >>> Duration is not right at all. >> >> Does QuickTime play the file longer for you than FFmpeg >> with my patch? >> Or do I misunderstand you? > > Correct duration is one I showed it here. No, the correct duration for the given file is ~6:20 as already explained. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil: Rename RSHIFT macro to ROUNDED_RSHIFT
On Tue, Jan 22, 2019 at 11:58 AM Carl Eugen Hoyos wrote:
>
> 2019-01-21 21:47 GMT+01:00, James Almer :
> > On 1/21/2019 4:09 PM, FeRD (Frank Dana) wrote:
> >> The RSHIFT macro in libavutil/common.h does not actually perform
> >> a bitwise right-shift, but rather a rounded version of the same
> >> operation, as is noted by a comment above the macro. The rounded
> >> divsion macro on the very next line is named ROUNDED_DIV, which
> >> seems far more clear.
> >>
> >> This patch renames RSHIFT to ROUNDED_RSHIFT, then updates all
> >> uses of the macro to use the new name. (These are all located
> >> in three codec files under libavcodec/.)
> >>
> >> Signed-off-by: FeRD (Frank Dana)
> >> ---
> >> libavcodec/mpeg4videodec.c | 4 ++--
> >> libavcodec/vp3.c | 16
> >> libavcodec/vp56.c | 4 ++--
> >> libavutil/common.h | 2 +-
> >> 4 files changed, 13 insertions(+), 13 deletions(-)
> >>
> >> diff --git a/libavcodec/mpeg4videodec.c b/libavcodec/mpeg4videodec.c
> >> index f44ee76bd4..5d63ba12ba 100644
> >> --- a/libavcodec/mpeg4videodec.c
> >> +++ b/libavcodec/mpeg4videodec.c
> >> @@ -601,7 +601,7 @@ static inline int get_amv(Mpeg4DecContext *ctx, int n)
> >> if (ctx->divx_version == 500 && ctx->divx_build == 413 && a >=
> >> s->quarter_sample)
> >> sum = s->sprite_offset[0][n] / (1 << (a -
> >> s->quarter_sample));
> >> else
> >> -sum = RSHIFT(s->sprite_offset[0][n] * (1 <<
> >> s->quarter_sample), a);
> >> +sum = ROUNDED_RSHIFT(s->sprite_offset[0][n] * (1 <<
> >> s->quarter_sample), a);
> >> } else {
> >> dx= s->sprite_delta[n][0];
> >> dy= s->sprite_delta[n][1];
> >> @@ -623,7 +623,7 @@ static inline int get_amv(Mpeg4DecContext *ctx, int n)
> >> v += dx;
> >> }
> >> }
> >> -sum = RSHIFT(sum, a + 8 - s->quarter_sample);
> >> +sum = ROUNDED_RSHIFT(sum, a + 8 - s->quarter_sample);
> >> }
> >>
> >> if (sum < -len)
> >> diff --git a/libavcodec/vp3.c b/libavcodec/vp3.c
> >> index a5d8c2ed0b..13b3d6e22a 100644
> >> --- a/libavcodec/vp3.c
> >> +++ b/libavcodec/vp3.c
> >> @@ -861,10 +861,10 @@ static int unpack_vectors(Vp3DecodeContext *s,
> >> GetBitContext *gb)
> >>
> >> if (s->chroma_y_shift) {
> >> if (s->macroblock_coding[current_macroblock] ==
> >> MODE_INTER_FOURMV) {
> >> -motion_x[0] = RSHIFT(motion_x[0] + motion_x[1] +
> >> - motion_x[2] + motion_x[3],
> >> 2);
> >> -motion_y[0] = RSHIFT(motion_y[0] + motion_y[1] +
> >> - motion_y[2] + motion_y[3],
> >> 2);
> >> +motion_x[0] = ROUNDED_RSHIFT(motion_x[0] +
> >> motion_x[1] +
> >> + motion_x[2] +
> >> motion_x[3], 2);
> >> +motion_y[0] = ROUNDED_RSHIFT(motion_y[0] +
> >> motion_y[1] +
> >> + motion_y[2] +
> >> motion_y[3], 2);
> >> }
> >> motion_x[0] = (motion_x[0] >> 1) | (motion_x[0] & 1);
> >> motion_y[0] = (motion_y[0] >> 1) | (motion_y[0] & 1);
> >> @@ -873,10 +873,10 @@ static int unpack_vectors(Vp3DecodeContext *s,
> >> GetBitContext *gb)
> >> s->motion_val[1][frag][1] = motion_y[0];
> >> } else if (s->chroma_x_shift) {
> >> if (s->macroblock_coding[current_macroblock] ==
> >> MODE_INTER_FOURMV) {
> >> -motion_x[0] = RSHIFT(motion_x[0] + motion_x[1],
> >> 1);
> >> -motion_y[0] = RSHIFT(motion_y[0] + motion_y[1],
> >> 1);
> >> -motion_x[1] = RSHIFT(motion_x[2] + motion_x[3],
> >> 1);
> >> -motion_y[1] = RSHIFT(motion_y[2] + motion_y[3],
> >> 1);
> >> +motion_x[0] = ROUNDED_RSHIFT(motion_x[0] +
> >> motion_x[1], 1);
> >> +motion_y[0] = ROUNDED_RSHIFT(motion_y[0] +
> >> motion_y[1], 1);
> >> +motion_x[1] = ROUNDED_RSHIFT(motion_x[2] +
> >> motion_x[3], 1);
> >> +motion_y[1] = ROUNDED_RSHIFT(motion_y[2] +
> >> motion_y[3], 1);
> >> } else {
> >> motion_x[1] = motion_x[0];
> >> motion_y[1] = motion_y[0];
> >> diff --git a/libavcodec/vp56.c b/libavcodec/vp56.c
> >> index b69fe6c176..9359b48bc6 100644
> >> --- a/libavcodec/vp56.c
> >> +++ b/libavcodec/vp56.c
> >> @@ -197,8 +197,8 @@ static void vp56_decode_4mv(VP56Context *s, int row,
> >> int col)
> >>
> >> /* chroma vectors are average luma vectors */
> >> if (s->avctx->codec->id == AV_CODEC_ID_VP5) {
> >> -s->mv[4].x = s->mv[5].x = RSHIFT(mv.x,2);
> >> -s->mv[4].y = s->mv[5].y = RSHIFT(mv.
Re: [FFmpeg-devel] [PATCH]lavf/cafdec: Do not fail hard for files ending with junk
On 1/22/19, Carl Eugen Hoyos wrote: > 2019-01-22 11:56 GMT+01:00, Paul B Mahol : >> On 1/22/19, Carl Eugen Hoyos wrote: >>> 2019-01-22 11:38 GMT+01:00, Paul B Mahol : On 1/22/19, Carl Eugen Hoyos wrote: > 2019-01-22 11:28 GMT+01:00, Paul B Mahol : >> On 1/22/19, Paul B Mahol wrote: >>> On 1/22/19, Carl Eugen Hoyos wrote: 2019-01-15 13:17 GMT+01:00, Paul B Mahol : > On 1/15/19, Carl Eugen Hoyos wrote: >> 2019-01-15 12:53 GMT+01:00, Paul B Mahol : >>> On 1/15/19, Carl Eugen Hoyos wrote: 2019-01-15 10:23 GMT+01:00, Paul B Mahol : > On 1/15/19, Carl Eugen Hoyos wrote: >> A user provided a real-life caf file ending with junk after >> the >> data >> chunk, QuickTime reads such files. >> >> Please comment, Carl Eugen >> > > NACK, there is data after junk bytes, which would get simply > discarded with your patch. Please elaborate: I don't think any data gets discarded because of this patch. >>> >>> I told you already, hex edit size of data chunk to very big >>> number >>> and >>> play file again. >> >> Of course. >> >> But how does this change the output compared to my patch? >> > > It does change, full length of audio is: > > MD5=5128bc2cd0e7b0560f15dd4c0546d1a0rate= 0.0kbits/s speed= 777x > size= 0kB time=00:09:18.16 bitrate= 0.0kbits/s speed= 769x Sorry for the delay: QuickTime Player only plays the file for ~6:20. Playing the file longer would be an issue since atoms after the data atom are allowed. And most important: This is unrelated, my patch is about playing a file that is supposed to be played but currently doesn't work. If there is something else to be improved, it should be a separate patch. Please comment, Carl Eugen >>> >>> You can not claim it fixes playback. > > It does here: The file does not play without my patch, it plays > (for the right duration) with my patch. Duration is not right at all. >>> >>> Does QuickTime play the file longer for you than FFmpeg >>> with my patch? >>> Or do I misunderstand you? >> >> Correct duration is one I showed it here. > > No, the correct duration for the given file is ~6:20 as > already explained. Nope, you are removing actual valid audio samples this way. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/cafdec: Do not fail hard for files ending with junk
2019-01-22 12:04 GMT+01:00, Paul B Mahol : > On 1/22/19, Carl Eugen Hoyos wrote: >> 2019-01-22 11:56 GMT+01:00, Paul B Mahol : >>> On 1/22/19, Carl Eugen Hoyos wrote: 2019-01-22 11:38 GMT+01:00, Paul B Mahol : > On 1/22/19, Carl Eugen Hoyos wrote: >> 2019-01-22 11:28 GMT+01:00, Paul B Mahol : >>> On 1/22/19, Paul B Mahol wrote: On 1/22/19, Carl Eugen Hoyos wrote: > 2019-01-15 13:17 GMT+01:00, Paul B Mahol : >> On 1/15/19, Carl Eugen Hoyos wrote: >>> 2019-01-15 12:53 GMT+01:00, Paul B Mahol : On 1/15/19, Carl Eugen Hoyos wrote: > 2019-01-15 10:23 GMT+01:00, Paul B Mahol : >> On 1/15/19, Carl Eugen Hoyos wrote: > >>> A user provided a real-life caf file ending with junk after >>> the >>> data >>> chunk, QuickTime reads such files. >>> >>> Please comment, Carl Eugen >>> >> >> NACK, there is data after junk bytes, which would get simply >> discarded with your patch. > > Please elaborate: I don't think any data gets discarded because > of this patch. I told you already, hex edit size of data chunk to very big number and play file again. >>> >>> Of course. >>> >>> But how does this change the output compared to my patch? >>> >> >> It does change, full length of audio is: >> >> MD5=5128bc2cd0e7b0560f15dd4c0546d1a0rate= 0.0kbits/s speed= 777x >> size= 0kB time=00:09:18.16 bitrate= 0.0kbits/s speed= 769x > > Sorry for the delay: > QuickTime Player only plays the file for ~6:20. > Playing the file longer would be an issue since atoms after the > data atom are allowed. > And most important: This is unrelated, my patch is about playing > a file that is supposed to be played but currently doesn't work. > If there is something else to be improved, it should be a separate > patch. > > Please comment, Carl Eugen You can not claim it fixes playback. >> >> It does here: The file does not play without my patch, it plays >> (for the right duration) with my patch. > > Duration is not right at all. Does QuickTime play the file longer for you than FFmpeg with my patch? Or do I misunderstand you? >>> >>> Correct duration is one I showed it here. >> >> No, the correct duration for the given file is ~6:20 as >> already explained. > > Nope, you are removing actual valid audio samples this way. But the caf structure claims that the discussed data are not valid audio samples but other caf atoms, since valid files exist that have atoms there, it is correct to skip the atoms if they cannot be detected, that is just how caf works. Is my explanation sufficient for you now? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil: Rename RSHIFT macro to ROUNDED_RSHIFT
2019-01-22 12:03 GMT+01:00, Hendrik Leppkes :
> On Tue, Jan 22, 2019 at 11:58 AM Carl Eugen Hoyos
> wrote:
>>
>> 2019-01-21 21:47 GMT+01:00, James Almer :
>> > On 1/21/2019 4:09 PM, FeRD (Frank Dana) wrote:
>> >> The RSHIFT macro in libavutil/common.h does not actually perform
>> >> a bitwise right-shift, but rather a rounded version of the same
>> >> operation, as is noted by a comment above the macro. The rounded
>> >> divsion macro on the very next line is named ROUNDED_DIV, which
>> >> seems far more clear.
>> >>
>> >> This patch renames RSHIFT to ROUNDED_RSHIFT, then updates all
>> >> uses of the macro to use the new name. (These are all located
>> >> in three codec files under libavcodec/.)
>> >>
>> >> Signed-off-by: FeRD (Frank Dana)
>> >> ---
>> >> libavcodec/mpeg4videodec.c | 4 ++--
>> >> libavcodec/vp3.c | 16
>> >> libavcodec/vp56.c | 4 ++--
>> >> libavutil/common.h | 2 +-
>> >> 4 files changed, 13 insertions(+), 13 deletions(-)
>> >>
>> >> diff --git a/libavcodec/mpeg4videodec.c b/libavcodec/mpeg4videodec.c
>> >> index f44ee76bd4..5d63ba12ba 100644
>> >> --- a/libavcodec/mpeg4videodec.c
>> >> +++ b/libavcodec/mpeg4videodec.c
>> >> @@ -601,7 +601,7 @@ static inline int get_amv(Mpeg4DecContext *ctx, int
>> >> n)
>> >> if (ctx->divx_version == 500 && ctx->divx_build == 413 && a >=
>> >> s->quarter_sample)
>> >> sum = s->sprite_offset[0][n] / (1 << (a -
>> >> s->quarter_sample));
>> >> else
>> >> -sum = RSHIFT(s->sprite_offset[0][n] * (1 <<
>> >> s->quarter_sample), a);
>> >> +sum = ROUNDED_RSHIFT(s->sprite_offset[0][n] * (1 <<
>> >> s->quarter_sample), a);
>> >> } else {
>> >> dx= s->sprite_delta[n][0];
>> >> dy= s->sprite_delta[n][1];
>> >> @@ -623,7 +623,7 @@ static inline int get_amv(Mpeg4DecContext *ctx, int
>> >> n)
>> >> v += dx;
>> >> }
>> >> }
>> >> -sum = RSHIFT(sum, a + 8 - s->quarter_sample);
>> >> +sum = ROUNDED_RSHIFT(sum, a + 8 - s->quarter_sample);
>> >> }
>> >>
>> >> if (sum < -len)
>> >> diff --git a/libavcodec/vp3.c b/libavcodec/vp3.c
>> >> index a5d8c2ed0b..13b3d6e22a 100644
>> >> --- a/libavcodec/vp3.c
>> >> +++ b/libavcodec/vp3.c
>> >> @@ -861,10 +861,10 @@ static int unpack_vectors(Vp3DecodeContext *s,
>> >> GetBitContext *gb)
>> >>
>> >> if (s->chroma_y_shift) {
>> >> if (s->macroblock_coding[current_macroblock] ==
>> >> MODE_INTER_FOURMV) {
>> >> -motion_x[0] = RSHIFT(motion_x[0] + motion_x[1]
>> >> +
>> >> - motion_x[2] +
>> >> motion_x[3],
>> >> 2);
>> >> -motion_y[0] = RSHIFT(motion_y[0] + motion_y[1]
>> >> +
>> >> - motion_y[2] +
>> >> motion_y[3],
>> >> 2);
>> >> +motion_x[0] = ROUNDED_RSHIFT(motion_x[0] +
>> >> motion_x[1] +
>> >> + motion_x[2] +
>> >> motion_x[3], 2);
>> >> +motion_y[0] = ROUNDED_RSHIFT(motion_y[0] +
>> >> motion_y[1] +
>> >> + motion_y[2] +
>> >> motion_y[3], 2);
>> >> }
>> >> motion_x[0] = (motion_x[0] >> 1) | (motion_x[0] &
>> >> 1);
>> >> motion_y[0] = (motion_y[0] >> 1) | (motion_y[0] &
>> >> 1);
>> >> @@ -873,10 +873,10 @@ static int unpack_vectors(Vp3DecodeContext *s,
>> >> GetBitContext *gb)
>> >> s->motion_val[1][frag][1] = motion_y[0];
>> >> } else if (s->chroma_x_shift) {
>> >> if (s->macroblock_coding[current_macroblock] ==
>> >> MODE_INTER_FOURMV) {
>> >> -motion_x[0] = RSHIFT(motion_x[0] +
>> >> motion_x[1],
>> >> 1);
>> >> -motion_y[0] = RSHIFT(motion_y[0] +
>> >> motion_y[1],
>> >> 1);
>> >> -motion_x[1] = RSHIFT(motion_x[2] +
>> >> motion_x[3],
>> >> 1);
>> >> -motion_y[1] = RSHIFT(motion_y[2] +
>> >> motion_y[3],
>> >> 1);
>> >> +motion_x[0] = ROUNDED_RSHIFT(motion_x[0] +
>> >> motion_x[1], 1);
>> >> +motion_y[0] = ROUNDED_RSHIFT(motion_y[0] +
>> >> motion_y[1], 1);
>> >> +motion_x[1] = ROUNDED_RSHIFT(motion_x[2] +
>> >> motion_x[3], 1);
>> >> +motion_y[1] = ROUNDED_RSHIFT(motion_y[2] +
>> >> motion_y[3], 1);
>> >> } else {
>> >> motion_x[1] = motion_x[0];
>> >> motion_y[1] = motion_y[0];
>> >> diff --git a/libavcodec/vp56.c b/libavcodec/vp56.c
>> >> index b69fe6c176..9359b48bc6 100644
>> >> --- a/libavcodec/vp56.c
>> >> +++ b/libavcodec/vp56.c
>> >> @@ -197,8 +197,8 @@ static void vp56_decode_4mv(VP56Context *s, int
>> >> row,
>> >>
Re: [FFmpeg-devel] [PATCH]lavf/cafdec: Do not fail hard for files ending with junk
On 1/22/19, Carl Eugen Hoyos wrote: > 2019-01-22 12:04 GMT+01:00, Paul B Mahol : >> On 1/22/19, Carl Eugen Hoyos wrote: >>> 2019-01-22 11:56 GMT+01:00, Paul B Mahol : On 1/22/19, Carl Eugen Hoyos wrote: > 2019-01-22 11:38 GMT+01:00, Paul B Mahol : >> On 1/22/19, Carl Eugen Hoyos wrote: >>> 2019-01-22 11:28 GMT+01:00, Paul B Mahol : On 1/22/19, Paul B Mahol wrote: > On 1/22/19, Carl Eugen Hoyos wrote: >> 2019-01-15 13:17 GMT+01:00, Paul B Mahol : >>> On 1/15/19, Carl Eugen Hoyos wrote: 2019-01-15 12:53 GMT+01:00, Paul B Mahol : > On 1/15/19, Carl Eugen Hoyos wrote: >> 2019-01-15 10:23 GMT+01:00, Paul B Mahol : >>> On 1/15/19, Carl Eugen Hoyos wrote: >> A user provided a real-life caf file ending with junk after the data chunk, QuickTime reads such files. Please comment, Carl Eugen >>> >>> NACK, there is data after junk bytes, which would get simply >>> discarded with your patch. >> >> Please elaborate: I don't think any data gets discarded >> because >> of this patch. > > I told you already, hex edit size of data chunk to very big > number > and > play file again. Of course. But how does this change the output compared to my patch? >>> >>> It does change, full length of audio is: >>> >>> MD5=5128bc2cd0e7b0560f15dd4c0546d1a0rate= 0.0kbits/s speed= >>> 777x >>> size= 0kB time=00:09:18.16 bitrate= 0.0kbits/s speed= >>> 769x >> >> Sorry for the delay: >> QuickTime Player only plays the file for ~6:20. >> Playing the file longer would be an issue since atoms after the >> data atom are allowed. >> And most important: This is unrelated, my patch is about playing >> a file that is supposed to be played but currently doesn't work. >> If there is something else to be improved, it should be a separate >> patch. >> >> Please comment, Carl Eugen > > You can not claim it fixes playback. >>> >>> It does here: The file does not play without my patch, it plays >>> (for the right duration) with my patch. >> >> Duration is not right at all. > > Does QuickTime play the file longer for you than FFmpeg > with my patch? > Or do I misunderstand you? Correct duration is one I showed it here. >>> >>> No, the correct duration for the given file is ~6:20 as >>> already explained. >> >> Nope, you are removing actual valid audio samples this way. > > But the caf structure claims that the discussed data are > not valid audio samples but other caf atoms, since valid > files exist that have atoms there, it is correct to skip the > atoms if they cannot be detected, that is just how caf > works. I'm not talking about CAF structure. > Is my explanation sufficient for you now? You still claim 2 things in your patch which are lie. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/cafdec: Do not fail hard for files ending with junk
2019-01-22 12:21 GMT+01:00, Paul B Mahol : > On 1/22/19, Carl Eugen Hoyos wrote: >> 2019-01-22 12:04 GMT+01:00, Paul B Mahol : >>> On 1/22/19, Carl Eugen Hoyos wrote: 2019-01-22 11:56 GMT+01:00, Paul B Mahol : > On 1/22/19, Carl Eugen Hoyos wrote: >> 2019-01-22 11:38 GMT+01:00, Paul B Mahol : >>> On 1/22/19, Carl Eugen Hoyos wrote: 2019-01-22 11:28 GMT+01:00, Paul B Mahol : > On 1/22/19, Paul B Mahol wrote: >> On 1/22/19, Carl Eugen Hoyos wrote: >>> 2019-01-15 13:17 GMT+01:00, Paul B Mahol : On 1/15/19, Carl Eugen Hoyos wrote: > 2019-01-15 12:53 GMT+01:00, Paul B Mahol : >> On 1/15/19, Carl Eugen Hoyos wrote: >>> 2019-01-15 10:23 GMT+01:00, Paul B Mahol : On 1/15/19, Carl Eugen Hoyos wrote: >>> > A user provided a real-life caf file ending with junk after > the > data > chunk, QuickTime reads such files. > > Please comment, Carl Eugen > NACK, there is data after junk bytes, which would get simply discarded with your patch. >>> >>> Please elaborate: I don't think any data gets discarded >>> because >>> of this patch. >> >> I told you already, hex edit size of data chunk to very big >> number >> and >> play file again. > > Of course. > > But how does this change the output compared to my patch? > It does change, full length of audio is: MD5=5128bc2cd0e7b0560f15dd4c0546d1a0rate= 0.0kbits/s speed= 777x size= 0kB time=00:09:18.16 bitrate= 0.0kbits/s speed= 769x >>> >>> Sorry for the delay: >>> QuickTime Player only plays the file for ~6:20. >>> Playing the file longer would be an issue since atoms after the >>> data atom are allowed. >>> And most important: This is unrelated, my patch is about playing >>> a file that is supposed to be played but currently doesn't work. >>> If there is something else to be improved, it should be a >>> separate >>> patch. >>> >>> Please comment, Carl Eugen >> >> You can not claim it fixes playback. It does here: The file does not play without my patch, it plays (for the right duration) with my patch. >>> >>> Duration is not right at all. >> >> Does QuickTime play the file longer for you than FFmpeg >> with my patch? >> Or do I misunderstand you? > > Correct duration is one I showed it here. No, the correct duration for the given file is ~6:20 as already explained. >>> >>> Nope, you are removing actual valid audio samples this way. >> >> But the caf structure claims that the discussed data are >> not valid audio samples but other caf atoms, since valid >> files exist that have atoms there, it is correct to skip the >> atoms if they cannot be detected, that is just how caf >> works. > > I'm not talking about CAF structure. But the CAF structure is the relevant talking point for caf files, no? >> Is my explanation sufficient for you now? > > You still claim 2 things in your patch which are lie. So you claim I am a liar? Does that mean we can finally drop the CoC? Please elaborate, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]lavc/g723_1enc: Set the default bitrate to 6300
Hi!
Attached patch makes the G.723_1 encoder easier to use.
Please comment, Carl Eugen
From 28b6114ed8e03dcd6ede45a54642582e3c6cc99b Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Tue, 22 Jan 2019 12:22:23 +0100
Subject: [PATCH] lavc/g723_1enc: Set the default bitrate to 6300.
---
libavcodec/g723_1enc.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/libavcodec/g723_1enc.c b/libavcodec/g723_1enc.c
index fe3fd09..5928405 100644
--- a/libavcodec/g723_1enc.c
+++ b/libavcodec/g723_1enc.c
@@ -1191,6 +1191,11 @@ static int g723_1_encode_frame(AVCodecContext *avctx, AVPacket *avpkt,
return 0;
}
+static const AVCodecDefault defaults[] = {
+{ "b", "6300" },
+{ NULL },
+};
+
AVCodec ff_g723_1_encoder = {
.name = "g723_1",
.long_name = NULL_IF_CONFIG_SMALL("G.723.1"),
@@ -1199,6 +1204,7 @@ AVCodec ff_g723_1_encoder = {
.priv_data_size = sizeof(G723_1_Context),
.init = g723_1_encode_init,
.encode2= g723_1_encode_frame,
+.defaults = defaults,
.sample_fmts= (const enum AVSampleFormat[]) {
AV_SAMPLE_FMT_S16, AV_SAMPLE_FMT_NONE
},
--
1.7.10.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/cafdec: Do not fail hard for files ending with junk
On 1/22/19, Carl Eugen Hoyos wrote: > 2019-01-22 12:21 GMT+01:00, Paul B Mahol : >> On 1/22/19, Carl Eugen Hoyos wrote: >>> 2019-01-22 12:04 GMT+01:00, Paul B Mahol : On 1/22/19, Carl Eugen Hoyos wrote: > 2019-01-22 11:56 GMT+01:00, Paul B Mahol : >> On 1/22/19, Carl Eugen Hoyos wrote: >>> 2019-01-22 11:38 GMT+01:00, Paul B Mahol : On 1/22/19, Carl Eugen Hoyos wrote: > 2019-01-22 11:28 GMT+01:00, Paul B Mahol : >> On 1/22/19, Paul B Mahol wrote: >>> On 1/22/19, Carl Eugen Hoyos wrote: 2019-01-15 13:17 GMT+01:00, Paul B Mahol : > On 1/15/19, Carl Eugen Hoyos wrote: >> 2019-01-15 12:53 GMT+01:00, Paul B Mahol : >>> On 1/15/19, Carl Eugen Hoyos wrote: 2019-01-15 10:23 GMT+01:00, Paul B Mahol : > On 1/15/19, Carl Eugen Hoyos wrote: >> A user provided a real-life caf file ending with junk >> after >> the >> data >> chunk, QuickTime reads such files. >> >> Please comment, Carl Eugen >> > > NACK, there is data after junk bytes, which would get > simply > discarded with your patch. Please elaborate: I don't think any data gets discarded because of this patch. >>> >>> I told you already, hex edit size of data chunk to very big >>> number >>> and >>> play file again. >> >> Of course. >> >> But how does this change the output compared to my patch? >> > > It does change, full length of audio is: > > MD5=5128bc2cd0e7b0560f15dd4c0546d1a0rate= 0.0kbits/s speed= > 777x > size= 0kB time=00:09:18.16 bitrate= 0.0kbits/s speed= > 769x Sorry for the delay: QuickTime Player only plays the file for ~6:20. Playing the file longer would be an issue since atoms after the data atom are allowed. And most important: This is unrelated, my patch is about playing a file that is supposed to be played but currently doesn't work. If there is something else to be improved, it should be a separate patch. Please comment, Carl Eugen >>> >>> You can not claim it fixes playback. > > It does here: The file does not play without my patch, it plays > (for the right duration) with my patch. Duration is not right at all. >>> >>> Does QuickTime play the file longer for you than FFmpeg >>> with my patch? >>> Or do I misunderstand you? >> >> Correct duration is one I showed it here. > > No, the correct duration for the given file is ~6:20 as > already explained. Nope, you are removing actual valid audio samples this way. >>> >>> But the caf structure claims that the discussed data are >>> not valid audio samples but other caf atoms, since valid >>> files exist that have atoms there, it is correct to skip the >>> atoms if they cannot be detected, that is just how caf >>> works. >> >> I'm not talking about CAF structure. > > But the CAF structure is the relevant talking point for caf files, no? > >>> Is my explanation sufficient for you now? >> >> You still claim 2 things in your patch which are lie. > > So you claim I am a liar? Does that mean we can > finally drop the CoC? > > Please elaborate, Carl Eugen You claim that: 1. There is junk data after end of data chunk as set in that file. 2. No useful data is being discarded. Both are not true. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil: Rename RSHIFT macro to ROUNDED_RSHIFT
On Mon, Jan 21, 2019 at 21:32:46 -0500, FeRD wrote: > Well... not *purely* cosmetic. See [1] for an example of one issue. Ruby's > `ruby/config.h` header also defines an `RSHIFT` macro, with different > semantics (it doesn't round), so when building code which includes > both headers the macro ends up being redefined. [...] > [1]: https://github.com/OpenShot/libopenshot/issues/164 While I agree with the assessment that ffmpeg's macro should have been named "FF_RSHIFT", "AV_RSHIFT" or even something more appropriate along your suggestion, you failed to post an upstream patch with ruby to rename their macro to "RUBY_RSHIFT". ;-) Honestly, these arbitrary names (sometimes also public function names) really mess up inclusions. (E.g. mutt moved from M_MACRONAME to MUTT_MACRONAME recently, for the same reasons.) Moritz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: add ARBC decoder
On Tue, Jan 22, 2019 at 10:55:33 +0100, Paul B Mahol wrote: > libavcodec/Makefile | 1 + > libavcodec/allcodecs.c | 1 + > libavcodec/arbc.c | 203 > libavcodec/avcodec.h| 1 + > libavcodec/codec_desc.c | 7 ++ > libavformat/riff.c | 1 + A changelog entry and a doc entry are welcomed. :-) Cheers, Moritz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: add ARBC decoder
On 1/22/2019 6:55 AM, Paul B Mahol wrote:
> Thanks Kostya for great help in reversing binary.
>
> Signed-off-by: Paul B Mahol
> ---
> libavcodec/Makefile | 1 +
> libavcodec/allcodecs.c | 1 +
> libavcodec/arbc.c | 203
> libavcodec/avcodec.h| 1 +
> libavcodec/codec_desc.c | 7 ++
> libavformat/riff.c | 1 +
> 6 files changed, 214 insertions(+)
> create mode 100644 libavcodec/arbc.c
>
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index bf746c143d..8e240aecf0 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -198,6 +198,7 @@ OBJS-$(CONFIG_APTX_HD_DECODER) += aptx.o
> OBJS-$(CONFIG_APTX_HD_ENCODER) += aptx.o
> OBJS-$(CONFIG_APNG_DECODER)+= png.o pngdec.o pngdsp.o
> OBJS-$(CONFIG_APNG_ENCODER)+= png.o pngenc.o
> +OBJS-$(CONFIG_ARBC_DECODER)+= arbc.o
> OBJS-$(CONFIG_SSA_DECODER) += assdec.o ass.o
> OBJS-$(CONFIG_SSA_ENCODER) += assenc.o ass.o
> OBJS-$(CONFIG_ASS_DECODER) += assdec.o ass.o
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> index fe0376e27e..5cbb09a5a4 100644
> --- a/libavcodec/allcodecs.c
> +++ b/libavcodec/allcodecs.c
> @@ -41,6 +41,7 @@ extern AVCodec ff_anm_decoder;
> extern AVCodec ff_ansi_decoder;
> extern AVCodec ff_apng_encoder;
> extern AVCodec ff_apng_decoder;
> +extern AVCodec ff_arbc_decoder;
> extern AVCodec ff_asv1_encoder;
> extern AVCodec ff_asv1_decoder;
> extern AVCodec ff_asv2_encoder;
> diff --git a/libavcodec/arbc.c b/libavcodec/arbc.c
> new file mode 100644
> index 00..59a1d7bf0a
> --- /dev/null
> +++ b/libavcodec/arbc.c
> @@ -0,0 +1,203 @@
> +/*
> + * Gryphon's Anim Compressor decoder
> + * Copyright (c) 2018 Paul B Mahol
> + *
> + * 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
> +#include
> +
> +#include "libavutil/imgutils.h"
> +#include "libavutil/internal.h"
> +#include "libavutil/intreadwrite.h"
> +#include "libavutil/mem.h"
> +
> +#include "avcodec.h"
> +#include "bytestream.h"
> +#include "internal.h"
> +
> +typedef struct ARBCContext {
> +GetByteContext gb;
> +
> +AVFrame *prev_frame;
> +} ARBCContext;
> +
> +static void fill_tile4(AVCodecContext *avctx, uint8_t *color, AVFrame *frame)
> +{
> +ARBCContext *s = avctx->priv_data;
> +GetByteContext *gb = &s->gb;
> +int nb_tiles = bytestream2_get_le16(gb);
> +int h = avctx->height - 1;
> +
> +for (int i = 0; i < nb_tiles; i++) {
> +int y = bytestream2_get_byte(gb);
> +int x = bytestream2_get_byte(gb);
> +uint16_t mask = bytestream2_get_le16(gb);
> +int start_y = y * 4, start_x = x * 4;
> +int end_y = start_y + 4, end_x = start_x + 4;
> +
> +for (int j = start_y; j < end_y; j++) {
> +for (int k = start_x; k < end_x; k++) {
> +if (mask & 0x8000) {
> +if (j >= avctx->height || k >= avctx->width)
> +continue;
> +frame->data[0][frame->linesize[0] * (h - j) + 3 * k + 0]
> = color[0];
> +frame->data[0][frame->linesize[0] * (h - j) + 3 * k + 1]
> = color[1];
> +frame->data[0][frame->linesize[0] * (h - j) + 3 * k + 2]
> = color[2];
> +}
> +mask = mask << 1;
get_bits(). Same below.
> +}
> +}
> +}
> +}
> +
> +static void fill_tileX(AVCodecContext *avctx, int tile_width, int
> tile_height,
> + uint8_t *color, AVFrame *frame)
> +{
> +ARBCContext *s = avctx->priv_data;
> +GetByteContext *gb = &s->gb;
> +const int step_h = tile_height / 4;
> +const int step_w = tile_width / 4;
> +int nb_tiles = bytestream2_get_le16(gb);
> +int h = avctx->height - 1;
> +
> +for (int i = 0; i < nb_tiles; i++) {
> +int y = bytestream2_get_byte(gb);
> +int x = bytestream2_get_byte(gb);
> +uint16_t mask = bytestream2_get_le16(gb);
> +int start_y = y * tile_height, start_x = x * tile_width;
> +int end_y = start_y + tile_height, end_x = start_x + tile_width;
> +
> +for (int j = start_y; j < end_
Re: [FFmpeg-devel] [PATCH] avcodec: add ARBC decoder
On 1/22/19, James Almer wrote:
> On 1/22/2019 6:55 AM, Paul B Mahol wrote:
>> Thanks Kostya for great help in reversing binary.
>>
>> Signed-off-by: Paul B Mahol
>> ---
>> libavcodec/Makefile | 1 +
>> libavcodec/allcodecs.c | 1 +
>> libavcodec/arbc.c | 203
>> libavcodec/avcodec.h| 1 +
>> libavcodec/codec_desc.c | 7 ++
>> libavformat/riff.c | 1 +
>> 6 files changed, 214 insertions(+)
>> create mode 100644 libavcodec/arbc.c
>>
>> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
>> index bf746c143d..8e240aecf0 100644
>> --- a/libavcodec/Makefile
>> +++ b/libavcodec/Makefile
>> @@ -198,6 +198,7 @@ OBJS-$(CONFIG_APTX_HD_DECODER) += aptx.o
>> OBJS-$(CONFIG_APTX_HD_ENCODER) += aptx.o
>> OBJS-$(CONFIG_APNG_DECODER)+= png.o pngdec.o pngdsp.o
>> OBJS-$(CONFIG_APNG_ENCODER)+= png.o pngenc.o
>> +OBJS-$(CONFIG_ARBC_DECODER)+= arbc.o
>> OBJS-$(CONFIG_SSA_DECODER) += assdec.o ass.o
>> OBJS-$(CONFIG_SSA_ENCODER) += assenc.o ass.o
>> OBJS-$(CONFIG_ASS_DECODER) += assdec.o ass.o
>> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
>> index fe0376e27e..5cbb09a5a4 100644
>> --- a/libavcodec/allcodecs.c
>> +++ b/libavcodec/allcodecs.c
>> @@ -41,6 +41,7 @@ extern AVCodec ff_anm_decoder;
>> extern AVCodec ff_ansi_decoder;
>> extern AVCodec ff_apng_encoder;
>> extern AVCodec ff_apng_decoder;
>> +extern AVCodec ff_arbc_decoder;
>> extern AVCodec ff_asv1_encoder;
>> extern AVCodec ff_asv1_decoder;
>> extern AVCodec ff_asv2_encoder;
>> diff --git a/libavcodec/arbc.c b/libavcodec/arbc.c
>> new file mode 100644
>> index 00..59a1d7bf0a
>> --- /dev/null
>> +++ b/libavcodec/arbc.c
>> @@ -0,0 +1,203 @@
>> +/*
>> + * Gryphon's Anim Compressor decoder
>> + * Copyright (c) 2018 Paul B Mahol
>> + *
>> + * 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
>> +#include
>> +
>> +#include "libavutil/imgutils.h"
>> +#include "libavutil/internal.h"
>> +#include "libavutil/intreadwrite.h"
>> +#include "libavutil/mem.h"
>> +
>> +#include "avcodec.h"
>> +#include "bytestream.h"
>> +#include "internal.h"
>> +
>> +typedef struct ARBCContext {
>> +GetByteContext gb;
>> +
>> +AVFrame *prev_frame;
>> +} ARBCContext;
>> +
>> +static void fill_tile4(AVCodecContext *avctx, uint8_t *color, AVFrame
>> *frame)
>> +{
>> +ARBCContext *s = avctx->priv_data;
>> +GetByteContext *gb = &s->gb;
>> +int nb_tiles = bytestream2_get_le16(gb);
>> +int h = avctx->height - 1;
>> +
>> +for (int i = 0; i < nb_tiles; i++) {
>> +int y = bytestream2_get_byte(gb);
>> +int x = bytestream2_get_byte(gb);
>> +uint16_t mask = bytestream2_get_le16(gb);
>> +int start_y = y * 4, start_x = x * 4;
>> +int end_y = start_y + 4, end_x = start_x + 4;
>> +
>> +for (int j = start_y; j < end_y; j++) {
>> +for (int k = start_x; k < end_x; k++) {
>> +if (mask & 0x8000) {
>> +if (j >= avctx->height || k >= avctx->width)
>> +continue;
>> +frame->data[0][frame->linesize[0] * (h - j) + 3 * k +
>> 0] = color[0];
>> +frame->data[0][frame->linesize[0] * (h - j) + 3 * k +
>> 1] = color[1];
>> +frame->data[0][frame->linesize[0] * (h - j) + 3 * k +
>> 2] = color[2];
>> +}
>> +mask = mask << 1;
>
> get_bits(). Same below.
Oh, come one, I had enough of this nonsense.
This is 16 bit number, using fucking get bits is overkill.
Get over it.
>
>> +}
>> +}
>> +}
>> +}
>> +
>> +static void fill_tileX(AVCodecContext *avctx, int tile_width, int
>> tile_height,
>> + uint8_t *color, AVFrame *frame)
>> +{
>> +ARBCContext *s = avctx->priv_data;
>> +GetByteContext *gb = &s->gb;
>> +const int step_h = tile_height / 4;
>> +const int step_w = tile_width / 4;
>> +int nb_tiles = bytestream2_get_le16(gb);
>> +int h = avctx->height - 1;
>> +
>> +for (int i = 0; i < nb_tiles; i++) {
>> +int y = bytestream2_get_byte(gb);
>> +
Re: [FFmpeg-devel] [PATCH] avcodec: add ARBC decoder
On 1/22/2019 10:30 AM, Paul B Mahol wrote:
> On 1/22/19, James Almer wrote:
>> On 1/22/2019 6:55 AM, Paul B Mahol wrote:
>>> Thanks Kostya for great help in reversing binary.
>>>
>>> Signed-off-by: Paul B Mahol
>>> ---
>>> libavcodec/Makefile | 1 +
>>> libavcodec/allcodecs.c | 1 +
>>> libavcodec/arbc.c | 203
>>> libavcodec/avcodec.h| 1 +
>>> libavcodec/codec_desc.c | 7 ++
>>> libavformat/riff.c | 1 +
>>> 6 files changed, 214 insertions(+)
>>> create mode 100644 libavcodec/arbc.c
>>>
>>> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
>>> index bf746c143d..8e240aecf0 100644
>>> --- a/libavcodec/Makefile
>>> +++ b/libavcodec/Makefile
>>> @@ -198,6 +198,7 @@ OBJS-$(CONFIG_APTX_HD_DECODER) += aptx.o
>>> OBJS-$(CONFIG_APTX_HD_ENCODER) += aptx.o
>>> OBJS-$(CONFIG_APNG_DECODER)+= png.o pngdec.o pngdsp.o
>>> OBJS-$(CONFIG_APNG_ENCODER)+= png.o pngenc.o
>>> +OBJS-$(CONFIG_ARBC_DECODER)+= arbc.o
>>> OBJS-$(CONFIG_SSA_DECODER) += assdec.o ass.o
>>> OBJS-$(CONFIG_SSA_ENCODER) += assenc.o ass.o
>>> OBJS-$(CONFIG_ASS_DECODER) += assdec.o ass.o
>>> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
>>> index fe0376e27e..5cbb09a5a4 100644
>>> --- a/libavcodec/allcodecs.c
>>> +++ b/libavcodec/allcodecs.c
>>> @@ -41,6 +41,7 @@ extern AVCodec ff_anm_decoder;
>>> extern AVCodec ff_ansi_decoder;
>>> extern AVCodec ff_apng_encoder;
>>> extern AVCodec ff_apng_decoder;
>>> +extern AVCodec ff_arbc_decoder;
>>> extern AVCodec ff_asv1_encoder;
>>> extern AVCodec ff_asv1_decoder;
>>> extern AVCodec ff_asv2_encoder;
>>> diff --git a/libavcodec/arbc.c b/libavcodec/arbc.c
>>> new file mode 100644
>>> index 00..59a1d7bf0a
>>> --- /dev/null
>>> +++ b/libavcodec/arbc.c
>>> @@ -0,0 +1,203 @@
>>> +/*
>>> + * Gryphon's Anim Compressor decoder
>>> + * Copyright (c) 2018 Paul B Mahol
>>> + *
>>> + * 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
>>> +#include
>>> +
>>> +#include "libavutil/imgutils.h"
>>> +#include "libavutil/internal.h"
>>> +#include "libavutil/intreadwrite.h"
>>> +#include "libavutil/mem.h"
>>> +
>>> +#include "avcodec.h"
>>> +#include "bytestream.h"
>>> +#include "internal.h"
>>> +
>>> +typedef struct ARBCContext {
>>> +GetByteContext gb;
>>> +
>>> +AVFrame *prev_frame;
>>> +} ARBCContext;
>>> +
>>> +static void fill_tile4(AVCodecContext *avctx, uint8_t *color, AVFrame
>>> *frame)
>>> +{
>>> +ARBCContext *s = avctx->priv_data;
>>> +GetByteContext *gb = &s->gb;
>>> +int nb_tiles = bytestream2_get_le16(gb);
>>> +int h = avctx->height - 1;
>>> +
>>> +for (int i = 0; i < nb_tiles; i++) {
>>> +int y = bytestream2_get_byte(gb);
>>> +int x = bytestream2_get_byte(gb);
>>> +uint16_t mask = bytestream2_get_le16(gb);
>>> +int start_y = y * 4, start_x = x * 4;
>>> +int end_y = start_y + 4, end_x = start_x + 4;
>>> +
>>> +for (int j = start_y; j < end_y; j++) {
>>> +for (int k = start_x; k < end_x; k++) {
>>> +if (mask & 0x8000) {
>>> +if (j >= avctx->height || k >= avctx->width)
>>> +continue;
>>> +frame->data[0][frame->linesize[0] * (h - j) + 3 * k +
>>> 0] = color[0];
>>> +frame->data[0][frame->linesize[0] * (h - j) + 3 * k +
>>> 1] = color[1];
>>> +frame->data[0][frame->linesize[0] * (h - j) + 3 * k +
>>> 2] = color[2];
>>> +}
>>> +mask = mask << 1;
>>
>> get_bits(). Same below.
>
> Oh, come one, I had enough of this nonsense.
> This is 16 bit number, using fucking get bits is overkill.
> Get over it.
Don't get pissy about nothing. I asked nothing that deserves that kind
of reaction.
Doing mask & 0x8000 then shifting it left by one at every loop is weird
and one of the reasons why get_bits was written for. But do however you
prefer.
>
>>
>>> +}
>>> +}
>>> +}
>>> +}
>>> +
>>> +static void fill_tileX(AVCodecContext *avctx, int tile_width, int
>>> tile_height,
Re: [FFmpeg-devel] [PATCH] avcodec: add ARBC decoder
On Tue, 22 Jan 2019, at 10:55, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
Overall, this is more readable that the ones in the past. Really cool.
> +for (int j = start_y; j < end_y; j++) {
> +for (int k = start_x; k < end_x; k++) {
> +if (mask & 0x8000) {
Do we know where this value comes from?
--
Jean-Baptiste Kempf - President
+33 672 704 734
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH V2] avcodec/libx265: add support for ROI-based encoding
On 21/01/2019 14:40, Guo, Yejun wrote:
[...]
> +} else {
> +// 8x8 block when qg-size is 8, 16*16 block otherwise
Cosmetic: Comments should be /**/ to match the rest of the file.
> +int mb_size = (ctx->params->rc.qgSize == 8) ? 8 : 16;
> +int mbx = (frame->width + mb_size - 1) / mb_size;
> +int mby = (frame->height + mb_size - 1) / mb_size;
> +int nb_rois;
> +AVRegionOfInterest* roi;
Cosmetic: File style is Type *name;
> +if (roi->qoffset.den == 0) {
> +av_free(qoffsets);
> +av_log(ctx, AV_LOG_ERROR,
> "AVRegionOfInterest.qoffset.den should not be zero.\n");
Nit: s/should/must/
> +for (int y = starty; y < endy; y++) {
> +for (int x = startx; x < endx; x++) {
> +qoffsets[x + y*mbx] = qoffset;
> +}
> +}
Cosmetic: Braces not necessary.
> +
> +if (roi->self_size == 0) {
> +av_free(qoffsets);
> +av_log(ctx, AV_LOG_ERROR, "AVRegionOfInterest.self_size
> should be set to sizeof(AVRegionOfInterest).\n");
> +return AVERROR(EINVAL);
> +}
Check should probably be outside loop.
> static int libx265_encode_frame(AVCodecContext *avctx, AVPacket *pkt,
> const AVFrame *pic, int *got_packet)
> {
> +if (x265pic.quantOffsets)
> +av_freep(&x265pic.quantOffsets);
The NULL check is redundant since av_freep does this check internally.
Sorry for for the bits I should have posted in v1 of the patch. All of my
comments
are very minor, or cosmetic in nature, and, in my opinion, can just be applied
by
whoever pushes it.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: add ARBC decoder
On 1/22/19, James Almer wrote:
> On 1/22/2019 10:30 AM, Paul B Mahol wrote:
>> On 1/22/19, James Almer wrote:
>>> On 1/22/2019 6:55 AM, Paul B Mahol wrote:
Thanks Kostya for great help in reversing binary.
Signed-off-by: Paul B Mahol
---
libavcodec/Makefile | 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/arbc.c | 203
libavcodec/avcodec.h| 1 +
libavcodec/codec_desc.c | 7 ++
libavformat/riff.c | 1 +
6 files changed, 214 insertions(+)
create mode 100644 libavcodec/arbc.c
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index bf746c143d..8e240aecf0 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -198,6 +198,7 @@ OBJS-$(CONFIG_APTX_HD_DECODER) += aptx.o
OBJS-$(CONFIG_APTX_HD_ENCODER) += aptx.o
OBJS-$(CONFIG_APNG_DECODER)+= png.o pngdec.o pngdsp.o
OBJS-$(CONFIG_APNG_ENCODER)+= png.o pngenc.o
+OBJS-$(CONFIG_ARBC_DECODER)+= arbc.o
OBJS-$(CONFIG_SSA_DECODER) += assdec.o ass.o
OBJS-$(CONFIG_SSA_ENCODER) += assenc.o ass.o
OBJS-$(CONFIG_ASS_DECODER) += assdec.o ass.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index fe0376e27e..5cbb09a5a4 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -41,6 +41,7 @@ extern AVCodec ff_anm_decoder;
extern AVCodec ff_ansi_decoder;
extern AVCodec ff_apng_encoder;
extern AVCodec ff_apng_decoder;
+extern AVCodec ff_arbc_decoder;
extern AVCodec ff_asv1_encoder;
extern AVCodec ff_asv1_decoder;
extern AVCodec ff_asv2_encoder;
diff --git a/libavcodec/arbc.c b/libavcodec/arbc.c
new file mode 100644
index 00..59a1d7bf0a
--- /dev/null
+++ b/libavcodec/arbc.c
@@ -0,0 +1,203 @@
+/*
+ * Gryphon's Anim Compressor decoder
+ * Copyright (c) 2018 Paul B Mahol
+ *
+ * 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
+#include
+
+#include "libavutil/imgutils.h"
+#include "libavutil/internal.h"
+#include "libavutil/intreadwrite.h"
+#include "libavutil/mem.h"
+
+#include "avcodec.h"
+#include "bytestream.h"
+#include "internal.h"
+
+typedef struct ARBCContext {
+GetByteContext gb;
+
+AVFrame *prev_frame;
+} ARBCContext;
+
+static void fill_tile4(AVCodecContext *avctx, uint8_t *color, AVFrame
*frame)
+{
+ARBCContext *s = avctx->priv_data;
+GetByteContext *gb = &s->gb;
+int nb_tiles = bytestream2_get_le16(gb);
+int h = avctx->height - 1;
+
+for (int i = 0; i < nb_tiles; i++) {
+int y = bytestream2_get_byte(gb);
+int x = bytestream2_get_byte(gb);
+uint16_t mask = bytestream2_get_le16(gb);
+int start_y = y * 4, start_x = x * 4;
+int end_y = start_y + 4, end_x = start_x + 4;
+
+for (int j = start_y; j < end_y; j++) {
+for (int k = start_x; k < end_x; k++) {
+if (mask & 0x8000) {
+if (j >= avctx->height || k >= avctx->width)
+continue;
+frame->data[0][frame->linesize[0] * (h - j) + 3 * k
+
0] = color[0];
+frame->data[0][frame->linesize[0] * (h - j) + 3 * k
+
1] = color[1];
+frame->data[0][frame->linesize[0] * (h - j) + 3 * k
+
2] = color[2];
+}
+mask = mask << 1;
>>>
>>> get_bits(). Same below.
>>
>> Oh, come one, I had enough of this nonsense.
>> This is 16 bit number, using fucking get bits is overkill.
>> Get over it.
>
> Don't get pissy about nothing. I asked nothing that deserves that kind
> of reaction.
>
> Doing mask & 0x8000 then shifting it left by one at every loop is weird
> and one of the reasons why get_bits was written for. Bu
Re: [FFmpeg-devel] [PATCH] avcodec: add ARBC decoder
On 1/22/19, Jean-Baptiste Kempf wrote:
> On Tue, 22 Jan 2019, at 10:55, Paul B Mahol wrote:
>> Signed-off-by: Paul B Mahol
>
> Overall, this is more readable that the ones in the past. Really cool.
With that terms: "more readable" actually means "less complex"
>
>> +for (int j = start_y; j < end_y; j++) {
>> +for (int k = start_x; k < end_x; k++) {
>> +if (mask & 0x8000) {
>
> Do we know where this value comes from?
>
Can't you see? It is obvious. It reads bits from top to bottom of 16
bit number and than does something - filling blocks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Rename RSHIFT macro to ROUNDED_RSHIFT
On Mon, Jan 21, 2019 at 2:15 PM FeRD wrote: > On Mon, Jan 21, 2019 at 1:55 PM Moritz Barsnick wrote: > > > On Mon, Jan 21, 2019 at 12:38:58 -0500, FeRD (Frank Dana) wrote: > > > > > After applying both patches, 'make fate' succeeds and ffmpeg is still > > > functional. > > > > You're not allowed to break fate (or compilation). So the two pathes > > need to be merged. > > > Aha, thanks. I'll resubmit squashed into a single patch. > maybe it would be a good opportunity to expose the symbol publicly, and prefix it with AV_ instead of FF_, like it was done for AV_CEIL_RSHIFT (21f946840260da150affd9a20cc35b3d56194ba6) -- Vittorio ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Support HDR dynamic metadata (HDR10+) in HEVC decoder.
---
libavcodec/hevc_sei.c | 211 --
libavcodec/hevc_sei.h | 6 ++
libavcodec/hevcdec.c | 22 +
3 files changed, 233 insertions(+), 6 deletions(-)
diff --git a/libavcodec/hevc_sei.c b/libavcodec/hevc_sei.c
index c59bd4321e..6edec9f0db 100644
--- a/libavcodec/hevc_sei.c
+++ b/libavcodec/hevc_sei.c
@@ -25,6 +25,7 @@
#include "golomb.h"
#include "hevc_ps.h"
#include "hevc_sei.h"
+#include "libavutil/hdr_dynamic_metadata.h"
static int decode_nal_sei_decoded_picture_hash(HEVCSEIPictureHash *s,
GetBitContext *gb)
{
@@ -206,10 +207,179 @@ static int
decode_registered_user_data_closed_caption(HEVCSEIA53Caption *s, GetB
return 0;
}
-static int decode_nal_sei_user_data_registered_itu_t_t35(HEVCSEI *s,
GetBitContext *gb,
+static int decode_registered_user_data_dynamic_hdr_plus(AVDynamicHDRPlus *s,
GetBitContext *gb,
+void *logctx, int size)
+{
+const int luminance_den = 1;
+const int peak_luminance_den = 15;
+const int rgb_den = 10;
+const int fraction_pixel_den = 1000;
+const int knee_point_den = 4095;
+const int bezier_anchor_den = 1023;
+const int saturation_weight_den = 8;
+
+int w, i, j;
+
+if (get_bits_left(gb) < size * 8)
+return AVERROR_INVALIDDATA;
+
+if (get_bits_left(gb) < 2)
+return AVERROR_INVALIDDATA;
+s->num_windows = get_bits(gb, 2);
+if (s->num_windows < 1 || s->num_windows > 3) {
+av_log(logctx, AV_LOG_ERROR, "num_windows=%d, must be in [1, 3]\n",
+ s->num_windows);
+return AVERROR_INVALIDDATA;
+}
+
+if (get_bits_left(gb) < ((19 * 8 + 1) * (s->num_windows - 1)))
+return AVERROR_INVALIDDATA;
+for (w = 1; w < s->num_windows; w++) {
+s->params[w].window_upper_left_corner_x.num = get_bits(gb, 16);
+s->params[w].window_upper_left_corner_y.num = get_bits(gb, 16);
+s->params[w].window_lower_right_corner_x.num = get_bits(gb, 16);
+s->params[w].window_lower_right_corner_y.num = get_bits(gb, 16);
+// The corners are set to absolute coordinates here. They should be
+// converted to the relative coordinates (in [0, 1]) in the decoder.
+s->params[w].window_upper_left_corner_x.den = 1;
+s->params[w].window_upper_left_corner_y.den = 1;
+s->params[w].window_lower_right_corner_x.den = 1;
+s->params[w].window_lower_right_corner_y.den = 1;
+
+s->params[w].center_of_ellipse_x = get_bits(gb, 16);
+s->params[w].center_of_ellipse_y = get_bits(gb, 16);
+s->params[w].rotation_angle = get_bits(gb, 8);
+s->params[w].semimajor_axis_internal_ellipse = get_bits(gb, 16);
+s->params[w].semimajor_axis_external_ellipse = get_bits(gb, 16);
+s->params[w].semiminor_axis_external_ellipse = get_bits(gb, 16);
+s->params[w].overlap_process_option = get_bits(gb, 1);
+}
+
+if (get_bits_left(gb) < 28)
+return AVERROR(EINVAL);
+s->targeted_system_display_maximum_luminance.num = get_bits(gb, 27);
+s->targeted_system_display_maximum_luminance.den = luminance_den;
+s->targeted_system_display_actual_peak_luminance_flag = get_bits(gb, 1);
+
+if (s->targeted_system_display_actual_peak_luminance_flag) {
+int rows, cols;
+if (get_bits_left(gb) < 10)
+return AVERROR(EINVAL);
+rows = get_bits(gb, 5);
+cols = get_bits(gb, 5);
+if (((rows < 2) || (rows > 25)) || ((cols < 2) || (cols > 25))) {
+av_log(logctx, AV_LOG_ERROR, "num_rows=%d, num_cols=%d, they must
[2, 25] for targeted_system_display_actual_peak_luminance\n", rows, cols);
+return AVERROR_INVALIDDATA;
+}
+s->num_rows_targeted_system_display_actual_peak_luminance = rows;
+s->num_cols_targeted_system_display_actual_peak_luminance = cols;
+
+if (get_bits_left(gb) < (rows * cols * 4))
+return AVERROR(EINVAL);
+
+for (i = 0; i < rows; i++) {
+for (j = 0; j < cols; j++) {
+s->targeted_system_display_actual_peak_luminance[i][j].num =
get_bits(gb, 4);
+s->targeted_system_display_actual_peak_luminance[i][j].den =
peak_luminance_den;
+}
+}
+}
+for (w = 0; w < s->num_windows; w++) {
+if (get_bits_left(gb) < (3 * 17 + 17 + 4))
+return AVERROR(EINVAL);
+for (i = 0; i < 3; i++) {
+s->params[w].maxscl[i].num = get_bits(gb, 17);
+s->params[w].maxscl[i].den = rgb_den;
+}
+s->params[w].average_maxrgb.num = get_bits(gb, 17);
+s->params[w].average_maxrgb.den = rgb_den;
+s->params[w].num_distribution_maxrgb_percentiles = get_bits(gb, 4);
+
+if (get_bits_left(gb) <
+(s->params[w].num_distribution_maxrgb_percentiles * 24))
+return AVERROR(EINVAL);
+for (i = 0; i < s->params[w].num_distributio
Re: [FFmpeg-devel] Rename RSHIFT macro to ROUNDED_RSHIFT
On 1/22/2019 2:17 PM, Vittorio Giovara wrote: > On Mon, Jan 21, 2019 at 2:15 PM FeRD wrote: > >> On Mon, Jan 21, 2019 at 1:55 PM Moritz Barsnick wrote: >> >>> On Mon, Jan 21, 2019 at 12:38:58 -0500, FeRD (Frank Dana) wrote: >>> After applying both patches, 'make fate' succeeds and ffmpeg is still functional. >>> >>> You're not allowed to break fate (or compilation). So the two pathes >>> need to be merged. >> >> >> Aha, thanks. I'll resubmit squashed into a single patch. >> > > maybe it would be a good opportunity to expose the symbol publicly, and > prefix it with AV_ instead of FF_, like it was done for AV_CEIL_RSHIFT > (21f946840260da150affd9a20cc35b3d56194ba6) That's not a good example seeing FF_CEIL_RSHIFT is still defined for backwards compatibility. The idea here is to remove RSHIFT altogether. I'm not against renaming it to AV_ROUNDED_RSHIFT or similar, but other than an entry in APIChanges we have no way to let library users that RSHIFT will be removed two or so years from now. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Avoids duplicated slashes in the RTSP URL. Signed-off-by: Frederic Pillonel
From: Frederic Pillonel
---
libavformat/rtsp.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index ceb770a3a4..20f63e0e01 100644
--- a/libavformat/rtsp.c
+++ b/libavformat/rtsp.c
@@ -548,9 +548,10 @@ static void sdp_parse_line(AVFormatContext *s,
SDPParseState *s1,
NULL, NULL, 0, p);
if (proto[0] == '\0') {
/* relative control URL */
-if
(rtsp_st->control_url[strlen(rtsp_st->control_url)-1]!='/')
-av_strlcat(rtsp_st->control_url, "/",
- sizeof(rtsp_st->control_url));
+if
(rtsp_st->control_url[strlen(rtsp_st->control_url)-1]!='/' &&
+(sizeof(p) > 0 && p[0]!='/'))
+av_strlcat(rtsp_st->control_url, "/",
+sizeof(rtsp_st->control_url));
av_strlcat(rtsp_st->control_url, p,
sizeof(rtsp_st->control_url));
} else
--
2.20.1.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Icecast protocol implementation doesn't parse "/" as a valid mountpoint
Hi all, Today as I tried to implement transcoding a videofeed to an icecast audio-only stream I have encountered some behavior that, in my opionion, leaves room for improvement. The setup used in this scenario consists of * an Open Broadcaster Studio (OBS) instance sending a video/audio feed * an nginx endpoint to receive and re-stream said feed to various hosts (including localhost) * and lastly an AzuraCast (https://github.com/AzuraCast/AzuraCast)instance which employs Icecast2.4 for audio broadcasting. AzuraCast allows streamer/DJ accounts to live-broadcast to any of its radio-stations by connecting through a Broadcasting software of your choice (noteworthy mentions are BUTT or Mixxx) to a dedicated port (e.g. 8005) and a static[1] mountpoint "/" and providing credentials. [1]static as in there is no easy way for me to change this design consideration) The way in which the icecast protocol is currently implemented in ffmpeg, it will check for characters after the trailing slash and assume this as a valid mountpoint. A trailing slash by itself will always be discarded with the following error: "No mountpoint (path) specified!" see: https://ffmpeg.org/doxygen/2.5/icecast_8c_source.html [lines 157-161] so icecast://source:pass@host:port/ is considered invalid by ffmpeg (I cannot think of a quick and dirty workaround either). To my understanding assigning a lone slash as a mountpoint name isn't considered invalid by the IceCast specification and therefore I suggest that it would be an enhancement to lift this current limitation on the way that mountpoints are parsed in an ffmpeg+icecast instruction. kind regards, c0re signature.asc Description: This is a digitally signed message part ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Rename RSHIFT macro to ROUNDED_RSHIFT
On Tue, 2019-01-22 at 15:35 -0300, James Almer wrote:
> I'm not against renaming it to AV_ROUNDED_RSHIFT or similar, but other
> than an entry in APIChanges we have no way to let library users that
> RSHIFT will be removed two or so years from now.
How about:
static inline void __attribute__ ((deprecated)) RSHIFT_is_deprecated(void) {}
#define RSHIFT(a, b) (RSHIFT_is_deprecated(), AV_ROUNDED_SHIFT(a, b))
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2 4/4] avformat/concatdec: always re-calculate start time and duration
On Mon, 21 Jan 2019, Nicolas George wrote: Marton Balint (12019-01-04): Agreed, and this is how it should work even after the patch. user_duration which is the duration specified in the ffconcat file always have priority because get_best_effort_duration always considers that first. So it does not matter that we assign ConcatFile->duration again and again, because we will just reassing the same value. Given that, I don't think an inconsitent state is possible because seeking is only allowed if the durations are known (if they are all set in the ffconcat file). On the other hand, if generic seeking is not allowed, then start_time will never be invalid because we always recalculate it for the next file when we open it. Does this relax your concern? I think it does. Sorry for forgetting to reply to this. Please go ahead when convenient. Thanks, pushed the remaining parts of the series. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Support HDR dynamic metadata (HDR10+) in HEVC decoder.
On Tue, 22 Jan 2019 at 18:01, Mohammad Izadi wrote:
> ---
> libavcodec/hevc_sei.c | 211 --
> libavcodec/hevc_sei.h | 6 ++
> libavcodec/hevcdec.c | 22 +
> 3 files changed, 233 insertions(+), 6 deletions(-)
>
> diff --git a/libavcodec/hevc_sei.c b/libavcodec/hevc_sei.c
> index c59bd4321e..6edec9f0db 100644
> --- a/libavcodec/hevc_sei.c
> +++ b/libavcodec/hevc_sei.c
> @@ -25,6 +25,7 @@
> #include "golomb.h"
> #include "hevc_ps.h"
> #include "hevc_sei.h"
> +#include "libavutil/hdr_dynamic_metadata.h"
>
> static int decode_nal_sei_decoded_picture_hash(HEVCSEIPictureHash *s,
> GetBitContext *gb)
> {
> @@ -206,10 +207,179 @@ static int
> decode_registered_user_data_closed_caption(HEVCSEIA53Caption *s, GetB
> return 0;
> }
>
> -static int decode_nal_sei_user_data_registered_itu_t_t35(HEVCSEI *s,
> GetBitContext *gb,
> +static int decode_registered_user_data_dynamic_hdr_plus(AVDynamicHDRPlus
> *s, GetBitContext *gb,
> +void *logctx, int
> size)
> +{
> +const int luminance_den = 1;
> +const int peak_luminance_den = 15;
> +const int rgb_den = 10;
> +const int fraction_pixel_den = 1000;
> +const int knee_point_den = 4095;
> +const int bezier_anchor_den = 1023;
> +const int saturation_weight_den = 8;
> +
> +int w, i, j;
> +
> +if (get_bits_left(gb) < size * 8)
> +return AVERROR_INVALIDDATA;
> +
> +if (get_bits_left(gb) < 2)
> +return AVERROR_INVALIDDATA;
> +s->num_windows = get_bits(gb, 2);
> +if (s->num_windows < 1 || s->num_windows > 3) {
> +av_log(logctx, AV_LOG_ERROR, "num_windows=%d, must be in [1,
> 3]\n",
> + s->num_windows);
> +return AVERROR_INVALIDDATA;
> +}
> +
> +if (get_bits_left(gb) < ((19 * 8 + 1) * (s->num_windows - 1)))
> +return AVERROR_INVALIDDATA;
>
Put a newline here?
+for (w = 1; w < s->num_windows; w++) {
> +s->params[w].window_upper_left_corner_x.num = get_bits(gb, 16);
> +s->params[w].window_upper_left_corner_y.num = get_bits(gb, 16);
> +s->params[w].window_lower_right_corner_x.num = get_bits(gb, 16);
> +s->params[w].window_lower_right_corner_y.num = get_bits(gb, 16);
> +// The corners are set to absolute coordinates here. They should
> be
> +// converted to the relative coordinates (in [0, 1]) in the
> decoder.
> +s->params[w].window_upper_left_corner_x.den = 1;
> +s->params[w].window_upper_left_corner_y.den = 1;
> +s->params[w].window_lower_right_corner_x.den = 1;
> +s->params[w].window_lower_right_corner_y.den = 1;
> +
> +s->params[w].center_of_ellipse_x = get_bits(gb, 16);
> +s->params[w].center_of_ellipse_y = get_bits(gb, 16);
> +s->params[w].rotation_angle = get_bits(gb, 8);
> +s->params[w].semimajor_axis_internal_ellipse = get_bits(gb, 16);
> +s->params[w].semimajor_axis_external_ellipse = get_bits(gb, 16);
> +s->params[w].semiminor_axis_external_ellipse = get_bits(gb, 16);
> +s->params[w].overlap_process_option = get_bits(gb, 1);
> +}
> +
> +if (get_bits_left(gb) < 28)
> +return AVERROR(EINVAL);
>
And here.
+s->targeted_system_display_maximum_luminance.num = get_bits(gb, 27);
> +s->targeted_system_display_maximum_luminance.den = luminance_den;
> +s->targeted_system_display_actual_peak_luminance_flag = get_bits(gb,
> 1);
> +
> +if (s->targeted_system_display_actual_peak_luminance_flag) {
> +int rows, cols;
> +if (get_bits_left(gb) < 10)
> +return AVERROR(EINVAL);
> +rows = get_bits(gb, 5);
> +cols = get_bits(gb, 5);
> +if (((rows < 2) || (rows > 25)) || ((cols < 2) || (cols > 25))) {
> +av_log(logctx, AV_LOG_ERROR, "num_rows=%d, num_cols=%d, they
> must [2, 25] for targeted_system_display_actual_peak_luminance\n", rows,
> cols);
> +return AVERROR_INVALIDDATA;
> +}
> +s->num_rows_targeted_system_display_actual_peak_luminance = rows;
> +s->num_cols_targeted_system_display_actual_peak_luminance = cols;
> +
> +if (get_bits_left(gb) < (rows * cols * 4))
> +return AVERROR(EINVAL);
> +
> +for (i = 0; i < rows; i++) {
> +for (j = 0; j < cols; j++) {
> +
> s->targeted_system_display_actual_peak_luminance[i][j].num = get_bits(gb,
> 4);
> +
> s->targeted_system_display_actual_peak_luminance[i][j].den =
> peak_luminance_den;
> +}
> +}
> +}
>
Same.
> +for (w = 0; w < s->num_windows; w++) {
> +if (get_bits_left(gb) < (3 * 17 + 17 + 4))
> +return AVERROR(EINVAL);
> +for (i = 0; i < 3; i++) {
> +s->params[w].maxscl[i].num = get_bits(gb, 17);
> +s->params[w].maxscl[i].den = rgb_den;
> +}
> +s->params[w].average_maxrgb.num = get_bits(gb, 17);
> +s->para
Re: [FFmpeg-devel] [PATCH] img2enc: mention -frames:v in error message
On Tue, Jan 15, 2019, at 10:54 PM, Kieran O Leary wrote: > > Looks good to me. Thanks. Pushed with fixed subject prefix. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Support HDR dynamic metadata (HDR10+) in HEVC decoder.
On 1/22/2019 4:50 PM, Rostislav Pehlivanov wrote:
> On Tue, 22 Jan 2019 at 18:01, Mohammad Izadi wrote:
>> diff --git a/libavcodec/hevc_sei.h b/libavcodec/hevc_sei.h
>> index 2fec00ace0..80c56b10bb 100644
>> --- a/libavcodec/hevc_sei.h
>> +++ b/libavcodec/hevc_sei.h
>> @@ -23,6 +23,7 @@
>>
>> #include
>>
>> +#include "libavutil/buffer.h"
>> #include "get_bits.h"
>>
>> /**
>> @@ -94,6 +95,10 @@ typedef struct HEVCSEIMasteringDisplay {
>> uint32_t min_luminance;
>> } HEVCSEIMasteringDisplay;
>>
>> +typedef struct HEVCSEIDynamicHDRPlus{
>> +AVBufferRef *info;
>> +} HEVCSEIDynamicHDRPlus;
>> +
>> typedef struct HEVCSEIContentLight {
>> int present;
>> uint16_t max_content_light_level;
>> @@ -109,6 +114,7 @@ typedef struct HEVCSEI {
>> HEVCSEIPictureHash picture_hash;
>> HEVCSEIFramePacking frame_packing;
>> HEVCSEIDisplayOrientation display_orientation;
>> +HEVCSEIDynamicHDRPlus dynamic_hdr_plus;
>> HEVCSEIPictureTiming picture_timing;
>> HEVCSEIA53Caption a53_caption;
>> HEVCSEIMasteringDisplay mastering_display;
>> diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
>> index 10bf2563c0..a7ed26b9d9 100644
>> --- a/libavcodec/hevcdec.c
>> +++ b/libavcodec/hevcdec.c
>> @@ -28,6 +28,7 @@
>> #include "libavutil/display.h"
>> #include "libavutil/internal.h"
>> #include "libavutil/mastering_display_metadata.h"
>> +#include "libavutil/hdr_dynamic_metadata.h"
>> #include "libavutil/md5.h"
>> #include "libavutil/opt.h"
>> #include "libavutil/pixdesc.h"
>> @@ -2769,6 +2770,26 @@ static int set_side_data(HEVCContext *s)
>> s->avctx->color_trc = out->color_trc =
>> s->sei.alternative_transfer.preferred_transfer_characteristics;
>> }
>>
>> +if (s->sei.dynamic_hdr_plus.info){
>> +AVDynamicHDRPlus *metadata =
>> (AVDynamicHDRPlus*)s->sei.dynamic_hdr_plus.info->data;
>> +// Convert coordinates to relative coordinate in [0, 1].
>> +metadata->params[0].window_upper_left_corner_x.num = 0;
>> +metadata->params[0].window_upper_left_corner_y.num = 0;
>> +metadata->params[0].window_lower_right_corner_x.num =
>> out->width-1;
>> +metadata->params[0].window_lower_right_corner_y.num =
>> out->height-1;
>> +for (int w = 0; w < metadata->num_windows; w++) {
>> +metadata->params[w].window_upper_left_corner_x.den =
>> out->width-1;
>> +metadata->params[w].window_upper_left_corner_y.den =
>> out->height-1;
>> +metadata->params[w].window_lower_right_corner_x.den =
>> out->width-1;
>> +metadata->params[w].window_lower_right_corner_y.den =
>> out->height-1;
>> +}
>>
>
> Put spaces between all the variables you're subtracting one out of?
He can't edit the AVBufferRef stored in HEVCSEI for each frame as it
becomes non writable past the first reference.
>
>
>
>> +if (!av_frame_new_side_data_from_buf(out,
>> AV_FRAME_DATA_DYNAMIC_HDR_PLUS, s->sei.dynamic_hdr_plus.info)) {
>>
>
> This is wrong, this takes ownership of the buffer, so by the time you apply
> it to the next frame it would have been free'd by the previous frame's
> unref.
> You need to call av_buffer_ref(s->sei.dynamic_hdr_plus.info) and put the
> new reference in av_frame_new_side_data_from_buf().
> You should also check if av_buffer_ref returned NULL in case of OOM.
> In case there's an error I don't think you should unref the s->
> sei.dynamic_hdr_plus.info buffer. It'll be freed during uninit, which the
> user will call if they think its necessary. That way the decoder state
> won't change.
> You should however return whatever av_frame_new_side_data_from_buf()
> returns. Just don't check it.
If this is meant to work through resolution changes, then he'll have to
call av_buffer_make_writable() for the new reference meant to be
attached as side data, either when it differs from the previous frame
(this needs code to keep track of dimension changes), or
unconditionally, in which case the benefit of reusing buffers will be lost.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: add ARBC decoder
On Tue, Jan 22, 2019 at 10:22:29AM -0300, James Almer wrote:
> On 1/22/2019 6:55 AM, Paul B Mahol wrote:
> > Thanks Kostya for great help in reversing binary.
:)
> > +static void fill_tile4(AVCodecContext *avctx, uint8_t *color, AVFrame
> > *frame)
> > +{
> > +ARBCContext *s = avctx->priv_data;
> > +GetByteContext *gb = &s->gb;
> > +int nb_tiles = bytestream2_get_le16(gb);
> > +int h = avctx->height - 1;
> > +
> > +for (int i = 0; i < nb_tiles; i++) {
> > +int y = bytestream2_get_byte(gb);
> > +int x = bytestream2_get_byte(gb);
> > +uint16_t mask = bytestream2_get_le16(gb);
> > +int start_y = y * 4, start_x = x * 4;
> > +int end_y = start_y + 4, end_x = start_x + 4;
> > +
> > +for (int j = start_y; j < end_y; j++) {
> > +for (int k = start_x; k < end_x; k++) {
> > +if (mask & 0x8000) {
> > +if (j >= avctx->height || k >= avctx->width)
> > +continue;
> > +frame->data[0][frame->linesize[0] * (h - j) + 3 * k +
> > 0] = color[0];
> > +frame->data[0][frame->linesize[0] * (h - j) + 3 * k +
> > 1] = color[1];
> > +frame->data[0][frame->linesize[0] * (h - j) + 3 * k +
> > 2] = color[2];
> > +}
> > +mask = mask << 1;
>
> get_bits(). Same below.
i do not agree, for the overkill reason given by paul.
equally, the pixel blit code could be moved to a seperate inlined function.
this is just a code style suggestion from me.
otherwise looks good.
-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Avoids duplicated slashes in the RTSP URL. Signed-off-by: Frederic Pillonel
On Tue, Jan 22, 2019 at 07:18:33PM +, f...@gmx.ch wrote:
> From: Frederic Pillonel
>
> ---
> libavformat/rtsp.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
> index ceb770a3a4..20f63e0e01 100644
> --- a/libavformat/rtsp.c
> +++ b/libavformat/rtsp.c
> @@ -548,9 +548,10 @@ static void sdp_parse_line(AVFormatContext *s,
> SDPParseState *s1,
> NULL, NULL, 0, p);
> if (proto[0] == '\0') {
> /* relative control URL */
> -if
> (rtsp_st->control_url[strlen(rtsp_st->control_url)-1]!='/')
> -av_strlcat(rtsp_st->control_url, "/",
> - sizeof(rtsp_st->control_url));
> +if
> (rtsp_st->control_url[strlen(rtsp_st->control_url)-1]!='/' &&
> +(sizeof(p) > 0 && p[0]!='/'))
what is sizeof(p) > 0 supposed to check for ?
p is a pointer which cannot have a size of 0
also The commit message should start with a prefix specifying the area or
file changed
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Dictatorship: All citizens are under surveillance, all their steps and
actions recorded, for the politicians to enforce control.
Democracy: All politicians are under surveillance, all their steps and
actions recorded, for the citizens to enforce control.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/g723_1enc: Set the default bitrate to 6300
On Tue, Jan 22, 2019 at 12:27:28PM +0100, Carl Eugen Hoyos wrote: > Hi! > > Attached patch makes the G.723_1 encoder easier to use. > > Please comment, Carl Eugen > g723_1enc.c |6 ++ > 1 file changed, 6 insertions(+) > 4c452f9652b0eb03b7c1c36c554663b9132498a0 > 0001-lavc-g723_1enc-Set-the-default-bitrate-to-6300.patch > From 28b6114ed8e03dcd6ede45a54642582e3c6cc99b Mon Sep 17 00:00:00 2001 > From: Carl Eugen Hoyos > Date: Tue, 22 Jan 2019 12:22:23 +0100 > Subject: [PATCH] lavc/g723_1enc: Set the default bitrate to 6300. if noone else has comments, than this should be ok thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Never trust a computer, one day, it may think you are the virus. -- Compn signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: add ARBC decoder
On 1/22/2019 11:54 AM, Paul B Mahol wrote:
> On 1/22/19, James Almer wrote:
>> On 1/22/2019 10:30 AM, Paul B Mahol wrote:
>>> On 1/22/19, James Almer wrote:
On 1/22/2019 6:55 AM, Paul B Mahol wrote:
> Thanks Kostya for great help in reversing binary.
>
> Signed-off-by: Paul B Mahol
> ---
> libavcodec/Makefile | 1 +
> libavcodec/allcodecs.c | 1 +
> libavcodec/arbc.c | 203
> libavcodec/avcodec.h| 1 +
> libavcodec/codec_desc.c | 7 ++
> libavformat/riff.c | 1 +
> 6 files changed, 214 insertions(+)
> create mode 100644 libavcodec/arbc.c
>
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index bf746c143d..8e240aecf0 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -198,6 +198,7 @@ OBJS-$(CONFIG_APTX_HD_DECODER) += aptx.o
> OBJS-$(CONFIG_APTX_HD_ENCODER) += aptx.o
> OBJS-$(CONFIG_APNG_DECODER)+= png.o pngdec.o pngdsp.o
> OBJS-$(CONFIG_APNG_ENCODER)+= png.o pngenc.o
> +OBJS-$(CONFIG_ARBC_DECODER)+= arbc.o
> OBJS-$(CONFIG_SSA_DECODER) += assdec.o ass.o
> OBJS-$(CONFIG_SSA_ENCODER) += assenc.o ass.o
> OBJS-$(CONFIG_ASS_DECODER) += assdec.o ass.o
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> index fe0376e27e..5cbb09a5a4 100644
> --- a/libavcodec/allcodecs.c
> +++ b/libavcodec/allcodecs.c
> @@ -41,6 +41,7 @@ extern AVCodec ff_anm_decoder;
> extern AVCodec ff_ansi_decoder;
> extern AVCodec ff_apng_encoder;
> extern AVCodec ff_apng_decoder;
> +extern AVCodec ff_arbc_decoder;
> extern AVCodec ff_asv1_encoder;
> extern AVCodec ff_asv1_decoder;
> extern AVCodec ff_asv2_encoder;
> diff --git a/libavcodec/arbc.c b/libavcodec/arbc.c
> new file mode 100644
> index 00..59a1d7bf0a
> --- /dev/null
> +++ b/libavcodec/arbc.c
> @@ -0,0 +1,203 @@
> +/*
> + * Gryphon's Anim Compressor decoder
> + * Copyright (c) 2018 Paul B Mahol
> + *
> + * 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
> +#include
> +
> +#include "libavutil/imgutils.h"
> +#include "libavutil/internal.h"
> +#include "libavutil/intreadwrite.h"
> +#include "libavutil/mem.h"
> +
> +#include "avcodec.h"
> +#include "bytestream.h"
> +#include "internal.h"
> +
> +typedef struct ARBCContext {
> +GetByteContext gb;
> +
> +AVFrame *prev_frame;
> +} ARBCContext;
> +
> +static void fill_tile4(AVCodecContext *avctx, uint8_t *color, AVFrame
> *frame)
> +{
> +ARBCContext *s = avctx->priv_data;
> +GetByteContext *gb = &s->gb;
> +int nb_tiles = bytestream2_get_le16(gb);
> +int h = avctx->height - 1;
> +
> +for (int i = 0; i < nb_tiles; i++) {
> +int y = bytestream2_get_byte(gb);
> +int x = bytestream2_get_byte(gb);
> +uint16_t mask = bytestream2_get_le16(gb);
> +int start_y = y * 4, start_x = x * 4;
> +int end_y = start_y + 4, end_x = start_x + 4;
> +
> +for (int j = start_y; j < end_y; j++) {
> +for (int k = start_x; k < end_x; k++) {
> +if (mask & 0x8000) {
> +if (j >= avctx->height || k >= avctx->width)
> +continue;
> +frame->data[0][frame->linesize[0] * (h - j) + 3 * k
> +
> 0] = color[0];
> +frame->data[0][frame->linesize[0] * (h - j) + 3 * k
> +
> 1] = color[1];
> +frame->data[0][frame->linesize[0] * (h - j) + 3 * k
> +
> 2] = color[2];
> +}
> +mask = mask << 1;
get_bits(). Same below.
>>>
>>> Oh, come one, I had enough of this nonsense.
>>> This is 16 bit number, using fucking get bits is overkill.
>>> Get over it.
>>
>> Don't get pissy about nothing. I asked nothing t
Re: [FFmpeg-devel] Icecast protocol implementation doesn't parse "/" as a valid mountpoint
On 22 Jan 2019, at 20:29, c0re wrote: Hi all, Today as I tried to implement transcoding a videofeed to an icecast audio-only stream I have encountered some behavior that, in my opionion, leaves room for improvement. The setup used in this scenario consists of * an Open Broadcaster Studio (OBS) instance sending a video/audio feed * an nginx endpoint to receive and re-stream said feed to various hosts (including localhost) * and lastly an AzuraCast (https://github.com/AzuraCast/AzuraCast)instance which employs Icecast2.4 for audio broadcasting. AzuraCast allows streamer/DJ accounts to live-broadcast to any of its radio-stations by connecting through a Broadcasting software of your choice (noteworthy mentions are BUTT or Mixxx) to a dedicated port (e.g. 8005) and a static[1] mountpoint "/" and providing credentials. This sounds quite weird, it would make a lot more sense to just use the same port and different mountpoints for this. The lack of multiple mountpoints is an old SHOUTcast limitation and Icecast does not suffer from it. [1]static as in there is no easy way for me to change this design consideration) The way in which the icecast protocol is currently implemented in ffmpeg, it will check for characters after the trailing slash and assume this as a valid mountpoint. A trailing slash by itself will always be discarded with the following error: "No mountpoint (path) specified!" see: https://ffmpeg.org/doxygen/2.5/icecast_8c_source.html [lines 157-161] so icecast://source:pass@host:port/ is considered invalid by ffmpeg (I cannot think of a quick and dirty workaround either). Hi, yes indeed Icecast does allow a mountpoint of /, but I would rather not allow that in the FFMpeg Icecast protocol helper, as IMO using / for a mountpoint is not a good idea. Users could accidentally use / as mount- point without this check and would get confused why it does not work out of the box (as by default / is an internal redirect to the status page). I wonder why AzuraCast decides to use / as mountpoint and why it does not even offer you a way to change it. Regards, Marvin Scholz To my understanding assigning a lone slash as a mountpoint name isn't considered invalid by the IceCast specification and therefore I suggest that it would be an enhancement to lift this current limitation on the way that mountpoints are parsed in an ffmpeg+icecast instruction. kind regards, c0re___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: add ARBC decoder
On Tue, Jan 22, 2019 at 10:55:33AM +0100, Paul B Mahol wrote:
> Thanks Kostya for great help in reversing binary.
>
> Signed-off-by: Paul B Mahol
> ---
> libavcodec/Makefile | 1 +
> libavcodec/allcodecs.c | 1 +
> libavcodec/arbc.c | 203
> libavcodec/avcodec.h| 1 +
> libavcodec/codec_desc.c | 7 ++
> libavformat/riff.c | 1 +
> 6 files changed, 214 insertions(+)
> create mode 100644 libavcodec/arbc.c
>
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index bf746c143d..8e240aecf0 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -198,6 +198,7 @@ OBJS-$(CONFIG_APTX_HD_DECODER) += aptx.o
> OBJS-$(CONFIG_APTX_HD_ENCODER) += aptx.o
> OBJS-$(CONFIG_APNG_DECODER)+= png.o pngdec.o pngdsp.o
> OBJS-$(CONFIG_APNG_ENCODER)+= png.o pngenc.o
> +OBJS-$(CONFIG_ARBC_DECODER)+= arbc.o
> OBJS-$(CONFIG_SSA_DECODER) += assdec.o ass.o
> OBJS-$(CONFIG_SSA_ENCODER) += assenc.o ass.o
> OBJS-$(CONFIG_ASS_DECODER) += assdec.o ass.o
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> index fe0376e27e..5cbb09a5a4 100644
> --- a/libavcodec/allcodecs.c
> +++ b/libavcodec/allcodecs.c
> @@ -41,6 +41,7 @@ extern AVCodec ff_anm_decoder;
> extern AVCodec ff_ansi_decoder;
> extern AVCodec ff_apng_encoder;
> extern AVCodec ff_apng_decoder;
> +extern AVCodec ff_arbc_decoder;
> extern AVCodec ff_asv1_encoder;
> extern AVCodec ff_asv1_decoder;
> extern AVCodec ff_asv2_encoder;
> diff --git a/libavcodec/arbc.c b/libavcodec/arbc.c
> new file mode 100644
> index 00..59a1d7bf0a
> --- /dev/null
> +++ b/libavcodec/arbc.c
> @@ -0,0 +1,203 @@
> +/*
> + * Gryphon's Anim Compressor decoder
> + * Copyright (c) 2018 Paul B Mahol
> + *
> + * 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
> +#include
> +
> +#include "libavutil/imgutils.h"
> +#include "libavutil/internal.h"
> +#include "libavutil/intreadwrite.h"
> +#include "libavutil/mem.h"
> +
> +#include "avcodec.h"
> +#include "bytestream.h"
> +#include "internal.h"
> +
> +typedef struct ARBCContext {
> +GetByteContext gb;
> +
> +AVFrame *prev_frame;
> +} ARBCContext;
> +
> +static void fill_tile4(AVCodecContext *avctx, uint8_t *color, AVFrame *frame)
> +{
> +ARBCContext *s = avctx->priv_data;
> +GetByteContext *gb = &s->gb;
> +int nb_tiles = bytestream2_get_le16(gb);
> +int h = avctx->height - 1;
> +
> +for (int i = 0; i < nb_tiles; i++) {
> +int y = bytestream2_get_byte(gb);
> +int x = bytestream2_get_byte(gb);
> +uint16_t mask = bytestream2_get_le16(gb);
> +int start_y = y * 4, start_x = x * 4;
> +int end_y = start_y + 4, end_x = start_x + 4;
> +
> +for (int j = start_y; j < end_y; j++) {
> +for (int k = start_x; k < end_x; k++) {
> +if (mask & 0x8000) {
> +if (j >= avctx->height || k >= avctx->width)
> +continue;
this would treat 1 bits differently than 0 bits when they are outside
teh frame. That is 1 bits would not advance in the bitstream (aka not execute
mask = mask << 1;
this also differs from fill_tileX()
is that intended ?
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- Plato
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Support HDR dynamic metadata (HDR10+) in HEVC decoder.
---
libavcodec/hevc_sei.c | 216 --
libavcodec/hevc_sei.h | 6 ++
libavcodec/hevcdec.c | 21
3 files changed, 237 insertions(+), 6 deletions(-)
diff --git a/libavcodec/hevc_sei.c b/libavcodec/hevc_sei.c
index c59bd4321e..15cd956e85 100644
--- a/libavcodec/hevc_sei.c
+++ b/libavcodec/hevc_sei.c
@@ -25,6 +25,7 @@
#include "golomb.h"
#include "hevc_ps.h"
#include "hevc_sei.h"
+#include "libavutil/hdr_dynamic_metadata.h"
static int decode_nal_sei_decoded_picture_hash(HEVCSEIPictureHash *s,
GetBitContext *gb)
{
@@ -206,10 +207,184 @@ static int
decode_registered_user_data_closed_caption(HEVCSEIA53Caption *s, GetB
return 0;
}
-static int decode_nal_sei_user_data_registered_itu_t_t35(HEVCSEI *s,
GetBitContext *gb,
+static int decode_registered_user_data_dynamic_hdr_plus(AVDynamicHDRPlus *s,
GetBitContext *gb,
+void *logctx, int size)
+{
+const int luminance_den = 1;
+const int peak_luminance_den = 15;
+const int rgb_den = 10;
+const int fraction_pixel_den = 1000;
+const int knee_point_den = 4095;
+const int bezier_anchor_den = 1023;
+const int saturation_weight_den = 8;
+
+int w, i, j;
+
+if (get_bits_left(gb) < size * 8)
+return AVERROR_INVALIDDATA;
+
+if (get_bits_left(gb) < 2)
+return AVERROR_INVALIDDATA;
+s->num_windows = get_bits(gb, 2);
+if (s->num_windows < 1 || s->num_windows > 3) {
+av_log(logctx, AV_LOG_ERROR, "num_windows=%d, must be in [1, 3]\n",
+ s->num_windows);
+return AVERROR_INVALIDDATA;
+}
+
+if (get_bits_left(gb) < ((19 * 8 + 1) * (s->num_windows - 1)))
+return AVERROR_INVALIDDATA;
+
+for (w = 1; w < s->num_windows; w++) {
+s->params[w].window_upper_left_corner_x.num = get_bits(gb, 16);
+s->params[w].window_upper_left_corner_y.num = get_bits(gb, 16);
+s->params[w].window_lower_right_corner_x.num = get_bits(gb, 16);
+s->params[w].window_lower_right_corner_y.num = get_bits(gb, 16);
+// The corners are set to absolute coordinates here. They should be
+// converted to the relative coordinates (in [0, 1]) in the decoder.
+s->params[w].window_upper_left_corner_x.den = 1;
+s->params[w].window_upper_left_corner_y.den = 1;
+s->params[w].window_lower_right_corner_x.den = 1;
+s->params[w].window_lower_right_corner_y.den = 1;
+
+s->params[w].center_of_ellipse_x = get_bits(gb, 16);
+s->params[w].center_of_ellipse_y = get_bits(gb, 16);
+s->params[w].rotation_angle = get_bits(gb, 8);
+s->params[w].semimajor_axis_internal_ellipse = get_bits(gb, 16);
+s->params[w].semimajor_axis_external_ellipse = get_bits(gb, 16);
+s->params[w].semiminor_axis_external_ellipse = get_bits(gb, 16);
+s->params[w].overlap_process_option = get_bits(gb, 1);
+}
+
+if (get_bits_left(gb) < 28)
+return AVERROR(EINVAL);
+
+s->targeted_system_display_maximum_luminance.num = get_bits(gb, 27);
+s->targeted_system_display_maximum_luminance.den = luminance_den;
+s->targeted_system_display_actual_peak_luminance_flag = get_bits(gb, 1);
+
+if (s->targeted_system_display_actual_peak_luminance_flag) {
+int rows, cols;
+if (get_bits_left(gb) < 10)
+return AVERROR(EINVAL);
+rows = get_bits(gb, 5);
+cols = get_bits(gb, 5);
+if (((rows < 2) || (rows > 25)) || ((cols < 2) || (cols > 25))) {
+av_log(logctx, AV_LOG_ERROR, "num_rows=%d, num_cols=%d, they must
[2, 25] for targeted_system_display_actual_peak_luminance\n", rows, cols);
+return AVERROR_INVALIDDATA;
+}
+s->num_rows_targeted_system_display_actual_peak_luminance = rows;
+s->num_cols_targeted_system_display_actual_peak_luminance = cols;
+
+if (get_bits_left(gb) < (rows * cols * 4))
+return AVERROR(EINVAL);
+
+for (i = 0; i < rows; i++) {
+for (j = 0; j < cols; j++) {
+s->targeted_system_display_actual_peak_luminance[i][j].num =
get_bits(gb, 4);
+s->targeted_system_display_actual_peak_luminance[i][j].den =
peak_luminance_den;
+}
+}
+}
+for (w = 0; w < s->num_windows; w++) {
+if (get_bits_left(gb) < (3 * 17 + 17 + 4))
+return AVERROR(EINVAL);
+for (i = 0; i < 3; i++) {
+s->params[w].maxscl[i].num = get_bits(gb, 17);
+s->params[w].maxscl[i].den = rgb_den;
+}
+s->params[w].average_maxrgb.num = get_bits(gb, 17);
+s->params[w].average_maxrgb.den = rgb_den;
+s->params[w].num_distribution_maxrgb_percentiles = get_bits(gb, 4);
+
+if (get_bits_left(gb) <
+(s->params[w].num_distribution_maxrgb_percentiles * 24))
+return AVERROR(EINVAL);
+for (i = 0; i < s->params[w].num_distribu
[FFmpeg-devel] [PATCH] Support HDR dynamic metadata (HDR10+) in HEVC decoder.
---
libavcodec/hevc_sei.c | 216 --
libavcodec/hevc_sei.h | 6 ++
libavcodec/hevcdec.c | 21
3 files changed, 237 insertions(+), 6 deletions(-)
diff --git a/libavcodec/hevc_sei.c b/libavcodec/hevc_sei.c
index c59bd4321e..15cd956e85 100644
--- a/libavcodec/hevc_sei.c
+++ b/libavcodec/hevc_sei.c
@@ -25,6 +25,7 @@
#include "golomb.h"
#include "hevc_ps.h"
#include "hevc_sei.h"
+#include "libavutil/hdr_dynamic_metadata.h"
static int decode_nal_sei_decoded_picture_hash(HEVCSEIPictureHash *s,
GetBitContext *gb)
{
@@ -206,10 +207,184 @@ static int
decode_registered_user_data_closed_caption(HEVCSEIA53Caption *s, GetB
return 0;
}
-static int decode_nal_sei_user_data_registered_itu_t_t35(HEVCSEI *s,
GetBitContext *gb,
+static int decode_registered_user_data_dynamic_hdr_plus(AVDynamicHDRPlus *s,
GetBitContext *gb,
+void *logctx, int size)
+{
+const int luminance_den = 1;
+const int peak_luminance_den = 15;
+const int rgb_den = 10;
+const int fraction_pixel_den = 1000;
+const int knee_point_den = 4095;
+const int bezier_anchor_den = 1023;
+const int saturation_weight_den = 8;
+
+int w, i, j;
+
+if (get_bits_left(gb) < size * 8)
+return AVERROR_INVALIDDATA;
+
+if (get_bits_left(gb) < 2)
+return AVERROR_INVALIDDATA;
+s->num_windows = get_bits(gb, 2);
+if (s->num_windows < 1 || s->num_windows > 3) {
+av_log(logctx, AV_LOG_ERROR, "num_windows=%d, must be in [1, 3]\n",
+ s->num_windows);
+return AVERROR_INVALIDDATA;
+}
+
+if (get_bits_left(gb) < ((19 * 8 + 1) * (s->num_windows - 1)))
+return AVERROR_INVALIDDATA;
+
+for (w = 1; w < s->num_windows; w++) {
+s->params[w].window_upper_left_corner_x.num = get_bits(gb, 16);
+s->params[w].window_upper_left_corner_y.num = get_bits(gb, 16);
+s->params[w].window_lower_right_corner_x.num = get_bits(gb, 16);
+s->params[w].window_lower_right_corner_y.num = get_bits(gb, 16);
+// The corners are set to absolute coordinates here. They should be
+// converted to the relative coordinates (in [0, 1]) in the decoder.
+s->params[w].window_upper_left_corner_x.den = 1;
+s->params[w].window_upper_left_corner_y.den = 1;
+s->params[w].window_lower_right_corner_x.den = 1;
+s->params[w].window_lower_right_corner_y.den = 1;
+
+s->params[w].center_of_ellipse_x = get_bits(gb, 16);
+s->params[w].center_of_ellipse_y = get_bits(gb, 16);
+s->params[w].rotation_angle = get_bits(gb, 8);
+s->params[w].semimajor_axis_internal_ellipse = get_bits(gb, 16);
+s->params[w].semimajor_axis_external_ellipse = get_bits(gb, 16);
+s->params[w].semiminor_axis_external_ellipse = get_bits(gb, 16);
+s->params[w].overlap_process_option = get_bits(gb, 1);
+}
+
+if (get_bits_left(gb) < 28)
+return AVERROR(EINVAL);
+
+s->targeted_system_display_maximum_luminance.num = get_bits(gb, 27);
+s->targeted_system_display_maximum_luminance.den = luminance_den;
+s->targeted_system_display_actual_peak_luminance_flag = get_bits(gb, 1);
+
+if (s->targeted_system_display_actual_peak_luminance_flag) {
+int rows, cols;
+if (get_bits_left(gb) < 10)
+return AVERROR(EINVAL);
+rows = get_bits(gb, 5);
+cols = get_bits(gb, 5);
+if (((rows < 2) || (rows > 25)) || ((cols < 2) || (cols > 25))) {
+av_log(logctx, AV_LOG_ERROR, "num_rows=%d, num_cols=%d, they must
[2, 25] for targeted_system_display_actual_peak_luminance\n", rows, cols);
+return AVERROR_INVALIDDATA;
+}
+s->num_rows_targeted_system_display_actual_peak_luminance = rows;
+s->num_cols_targeted_system_display_actual_peak_luminance = cols;
+
+if (get_bits_left(gb) < (rows * cols * 4))
+return AVERROR(EINVAL);
+
+for (i = 0; i < rows; i++) {
+for (j = 0; j < cols; j++) {
+s->targeted_system_display_actual_peak_luminance[i][j].num =
get_bits(gb, 4);
+s->targeted_system_display_actual_peak_luminance[i][j].den =
peak_luminance_den;
+}
+}
+}
+for (w = 0; w < s->num_windows; w++) {
+if (get_bits_left(gb) < (3 * 17 + 17 + 4))
+return AVERROR(EINVAL);
+for (i = 0; i < 3; i++) {
+s->params[w].maxscl[i].num = get_bits(gb, 17);
+s->params[w].maxscl[i].den = rgb_den;
+}
+s->params[w].average_maxrgb.num = get_bits(gb, 17);
+s->params[w].average_maxrgb.den = rgb_den;
+s->params[w].num_distribution_maxrgb_percentiles = get_bits(gb, 4);
+
+if (get_bits_left(gb) <
+(s->params[w].num_distribution_maxrgb_percentiles * 24))
+return AVERROR(EINVAL);
+for (i = 0; i < s->params[w].num_distribu
[FFmpeg-devel] [PATCH 1/3] avcodec/rasc: Check uncompressed dlta size
We assume that if the compressed size is bigger than if each byte is encoded in
a single raw packet
that the data is invalid.
Fixes: Out of memory
Fixes:
12208/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RASC_fuzzer-5648916473708544
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/rasc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavcodec/rasc.c b/libavcodec/rasc.c
index 1b607ac31e..6e32c1540e 100644
--- a/libavcodec/rasc.c
+++ b/libavcodec/rasc.c
@@ -353,6 +353,8 @@ static int decode_dlta(AVCodecContext *avctx,
compression = bytestream2_get_le32(gb);
if (compression == 1) {
+if (w * h * s->bpp * 3 < uncompressed_size)
+return AVERROR_INVALIDDATA;
ret = decode_zlib(avctx, avpkt, size, uncompressed_size);
if (ret < 0)
return ret;
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/3] avcodec/fic: Check that there is input left in fic_decode_block()
Fixes: Timeout
Fixes:
12450/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FIC_fuzzer-5661984622641152
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/fic.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavcodec/fic.c b/libavcodec/fic.c
index 8833536330..65d102b86b 100644
--- a/libavcodec/fic.c
+++ b/libavcodec/fic.c
@@ -139,6 +139,9 @@ static int fic_decode_block(FICContext *ctx, GetBitContext
*gb,
{
int i, num_coeff;
+if (get_bits_left(gb) < 8)
+return AVERROR_INVALIDDATA;
+
/* Is it a skip block? */
if (get_bits1(gb)) {
*is_p = 1;
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/3] avcodec/rasc: Move ff_get_buffer() after frame checks
If the frame1/2 checks fail this avoids doing the allocation of a new frame Signed-off-by: Michael Niedermayer --- libavcodec/rasc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/libavcodec/rasc.c b/libavcodec/rasc.c index 6e32c1540e..21fc43f325 100644 --- a/libavcodec/rasc.c +++ b/libavcodec/rasc.c @@ -723,12 +723,12 @@ static int decode_frame(AVCodecContext *avctx, return ret; } -if ((ret = ff_get_buffer(avctx, s->frame, 0)) < 0) -return ret; - if (!s->frame2->data[0] || !s->frame1->data[0]) return AVERROR_INVALIDDATA; +if ((ret = ff_get_buffer(avctx, s->frame, 0)) < 0) +return ret; + copy_plane(avctx, s->frame2, s->frame); if (avctx->pix_fmt == AV_PIX_FMT_PAL8) memcpy(s->frame->data[1], s->frame2->data[1], 1024); -- 2.20.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/3] lavu/x86util: make imprecise PMINSD implementation opt-in
This caused rounding errors when values that can't be expressed exactly as 32-bit floats were passed in, which could happen in 16-bit yadif swscale's call is opted in, under the assumption that it never uses values large enough to run into this (i.e. within 2^24) --- libavutil/x86/x86util.asm | 4 ++-- libswscale/x86/scale.asm | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/libavutil/x86/x86util.asm b/libavutil/x86/x86util.asm index d7cd996842..c96afb6ef1 100644 --- a/libavutil/x86/x86util.asm +++ b/libavutil/x86/x86util.asm @@ -799,10 +799,10 @@ pminsw %1, %3 %endmacro -%macro PMINSD 3 ; dst, src, tmp/unused +%macro PMINSD 3-4 ; dst, src, tmp/unused, rounding-allowed %if cpuflag(sse4) pminsd%1, %2 -%elif cpuflag(sse2) +%elif cpuflag(sse2) && (%0 > 3) cvtdq2ps %1, %1 minps %1, %2 cvtps2dq %1, %1 diff --git a/libswscale/x86/scale.asm b/libswscale/x86/scale.asm index 83cabff722..914fd1ada4 100644 --- a/libswscale/x86/scale.asm +++ b/libswscale/x86/scale.asm @@ -364,7 +364,7 @@ cglobal hscale%1to%2_%4, %5, 10, %6, pos0, dst, w, srcmem, filter, fltpos, fltsi movd [dstq+wq*2], m0 %endif ; %3 ==/!= X %else ; %2 == 19 -PMINSDm0, m2, m4 +PMINSDm0, m2, m4, 1 %ifnidn %3, X mova [dstq+wq*(4>>wshr)], m0 %else ; %3 == X -- 2.19.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/3] FATE/filter-video: fix high-bit-depth yadif tests
These previously upconverted the video _after_ applying the filter, so they didn't actually test the high-bit-depth code paths at all, which is why the PMINSD issue in the previous commit wasn't caught. I also added variants with the spatial check enabled and disabled, so both of those paths are tested (as with the 8-bit path). The chroma upconversion to 4:4:4 is deliberate; the upscale results in some non-multiple-of-4 input values in the 10-bit case, and non-multiple-of-256 values in the 16-bit case, so that the tests would catch problems resulting in lossy output in the low bits. --- tests/fate/filter-video.mak | 10 - tests/ref/fate/filter-yadif10 | 60 - tests/ref/fate/filter-yadif10-nospatial | 35 +++ tests/ref/fate/filter-yadif16 | 60 - tests/ref/fate/filter-yadif16-nospatial | 35 +++ 5 files changed, 138 insertions(+), 62 deletions(-) create mode 100644 tests/ref/fate/filter-yadif10-nospatial create mode 100644 tests/ref/fate/filter-yadif16-nospatial diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak index 1042e96e54..a71ad318b1 100644 --- a/tests/fate/filter-video.mak +++ b/tests/fate/filter-video.mak @@ -15,10 +15,16 @@ FATE_YADIF += fate-filter-yadif-mode1 fate-filter-yadif-mode1: CMD = framecrc -flags bitexact -idct simple -i $(TARGET_SAMPLES)/mpeg2/mpeg2_field_encoding.ts -frames:v 59 -vf yadif=1 FATE_YADIF += fate-filter-yadif10 -fate-filter-yadif10: CMD = framecrc -flags bitexact -idct simple -i $(TARGET_SAMPLES)/mpeg2/mpeg2_field_encoding.ts -flags bitexact -pix_fmt yuv420p10le -frames:v 30 -vf yadif=0 +fate-filter-yadif10: CMD = framecrc -flags bitexact -idct simple -i $(TARGET_SAMPLES)/mpeg2/mpeg2_field_encoding.ts -flags bitexact -frames:v 30 -vf format=pix_fmts=yuv444p10,yadif=send_frame + +FATE_YADIF += fate-filter-yadif10-nospatial +fate-filter-yadif10-nospatial: CMD = framecrc -flags bitexact -idct simple -i $(TARGET_SAMPLES)/mpeg2/mpeg2_field_encoding.ts -flags bitexact -frames:v 30 -vf format=pix_fmts=yuv444p10,yadif=send_frame_nospatial FATE_YADIF += fate-filter-yadif16 -fate-filter-yadif16: CMD = framecrc -flags bitexact -idct simple -i $(TARGET_SAMPLES)/mpeg2/mpeg2_field_encoding.ts -flags bitexact -pix_fmt yuv420p16le -frames:v 30 -vf yadif=0 +fate-filter-yadif16: CMD = framecrc -flags bitexact -idct simple -i $(TARGET_SAMPLES)/mpeg2/mpeg2_field_encoding.ts -flags bitexact -frames:v 30 -vf format=pix_fmts=yuv444p16,yadif=send_frame + +FATE_YADIF += fate-filter-yadif16-nospatial +fate-filter-yadif16-nospatial: CMD = framecrc -flags bitexact -idct simple -i $(TARGET_SAMPLES)/mpeg2/mpeg2_field_encoding.ts -flags bitexact -frames:v 30 -vf format=pix_fmts=yuv444p16,yadif=send_frame_nospatial FATE_FILTER_SAMPLES-$(call FILTERDEMDEC, YADIF, MPEGTS, MPEG2VIDEO) += $(FATE_YADIF) diff --git a/tests/ref/fate/filter-yadif10 b/tests/ref/fate/filter-yadif10 index 28e799fc1f..fe59198a28 100644 --- a/tests/ref/fate/filter-yadif10 +++ b/tests/ref/fate/filter-yadif10 @@ -3,33 +3,33 @@ #codec_id 0: rawvideo #dimensions 0: 720x576 #sar 0: 16/15 -0, 9, 9,1, 1244160, 0xe0c2231b -0, 10, 10,1, 1244160, 0xdc7caa43 -0, 11, 11,1, 1244160, 0x52c4dfbf -0, 12, 12,1, 1244160, 0x7c577f07 -0, 13, 13,1, 1244160, 0x5b6ad7ce -0, 14, 14,1, 1244160, 0x6f15ce76 -0, 15, 15,1, 1244160, 0xf120034a -0, 16, 16,1, 1244160, 0x9c65ba64 -0, 17, 17,1, 1244160, 0x883b237e -0, 18, 18,1, 1244160, 0xb8292e0d -0, 19, 19,1, 1244160, 0xbc392721 -0, 20, 20,1, 1244160, 0x7cd82ec9 -0, 21, 21,1, 1244160, 0x167325eb -0, 22, 22,1, 1244160, 0x49bafa73 -0, 23, 23,1, 1244160, 0xe1ff6dbf -0, 24, 24,1, 1244160, 0x85f710b6 -0, 25, 25,1, 1244160, 0xd1fd4cdb -0, 26, 26,1, 1244160, 0xafee03c5 -0, 27, 27,1, 1244160, 0x566be070 -0, 28, 28,1, 1244160, 0xb6abbd01 -0, 29, 29,1, 1244160, 0xa98f38fd -0, 30, 30,1, 1244160, 0x00f4736b -0, 31, 31,1, 1244160, 0x6b0f9dd2 -0, 32, 32,1, 1244160, 0x15810b92 -0, 33, 33,1, 1244160, 0x0b516465 -0, 34, 34,1, 1244160, 0x927d15e6 -0, 35, 35,1, 1244160, 0xd102f2bf -0, 36, 36,1, 1244160, 0xdd8b3b20 -0, 37, 37,1, 1244160, 0x229ac529 -0, 38, 38,1, 1244160, 0xf844e0a2 +0, 9, 9,1, 2488320, 0x1ad5d0
[FFmpeg-devel] [PATCH 3/3] tests/checkasm: add vf_yadif tests
---
libavfilter/vf_yadif.c| 23 ---
libavfilter/yadif.h | 2 +
tests/checkasm/Makefile | 1 +
tests/checkasm/checkasm.c | 3 +
tests/checkasm/checkasm.h | 1 +
tests/checkasm/vf_yadif.c | 137 ++
6 files changed, 158 insertions(+), 9 deletions(-)
create mode 100644 tests/checkasm/vf_yadif.c
diff --git a/libavfilter/vf_yadif.c b/libavfilter/vf_yadif.c
index 3107924932..575b5a421e 100644
--- a/libavfilter/vf_yadif.c
+++ b/libavfilter/vf_yadif.c
@@ -311,6 +311,19 @@ static int query_formats(AVFilterContext *ctx)
return ff_set_common_formats(ctx, fmts_list);
}
+void ff_yadif_init(YADIFContext *s) {
+if (s->csp->comp[0].depth > 8) {
+s->filter_line = filter_line_c_16bit;
+s->filter_edges = filter_edges_16bit;
+} else {
+s->filter_line = filter_line_c;
+s->filter_edges = filter_edges;
+}
+
+if (ARCH_X86)
+ff_yadif_init_x86(s);
+}
+
static int config_props(AVFilterLink *link)
{
AVFilterContext *ctx = link->src;
@@ -332,16 +345,8 @@ static int config_props(AVFilterLink *link)
s->csp = av_pix_fmt_desc_get(link->format);
s->filter = filter;
-if (s->csp->comp[0].depth > 8) {
-s->filter_line = filter_line_c_16bit;
-s->filter_edges = filter_edges_16bit;
-} else {
-s->filter_line = filter_line_c;
-s->filter_edges = filter_edges;
-}
-if (ARCH_X86)
-ff_yadif_init_x86(s);
+ff_yadif_init(s);
return 0;
}
diff --git a/libavfilter/yadif.h b/libavfilter/yadif.h
index c928911b35..aa0ae744f2 100644
--- a/libavfilter/yadif.h
+++ b/libavfilter/yadif.h
@@ -86,6 +86,8 @@ typedef struct YADIFContext {
int current_field; ///< YADIFCurrentField
} YADIFContext;
+void ff_yadif_init(YADIFContext *s);
+
void ff_yadif_init_x86(YADIFContext *yadif);
int ff_yadif_filter_frame(AVFilterLink *link, AVFrame *frame);
diff --git a/tests/checkasm/Makefile b/tests/checkasm/Makefile
index 47b7b06d28..eb1ac06151 100644
--- a/tests/checkasm/Makefile
+++ b/tests/checkasm/Makefile
@@ -37,6 +37,7 @@ AVFILTEROBJS-$(CONFIG_COLORSPACE_FILTER) += vf_colorspace.o
AVFILTEROBJS-$(CONFIG_HFLIP_FILTER) += vf_hflip.o
AVFILTEROBJS-$(CONFIG_THRESHOLD_FILTER) += vf_threshold.o
AVFILTEROBJS-$(CONFIG_NLMEANS_FILTER)+= vf_nlmeans.o
+AVFILTEROBJS-$(CONFIG_YADIF_FILTER) += vf_yadif.o
CHECKASMOBJS-$(CONFIG_AVFILTER) += $(AVFILTEROBJS-yes)
diff --git a/tests/checkasm/checkasm.c b/tests/checkasm/checkasm.c
index c3f5160132..23cdcb27ae 100644
--- a/tests/checkasm/checkasm.c
+++ b/tests/checkasm/checkasm.c
@@ -168,6 +168,9 @@ static const struct {
#if CONFIG_THRESHOLD_FILTER
{ "vf_threshold", checkasm_check_vf_threshold },
#endif
+#if CONFIG_YADIF_FILTER
+{ "vf_yadif", checkasm_check_vf_yadif },
+#endif
#endif
#if CONFIG_SWSCALE
{ "sw_rgb", checkasm_check_sw_rgb },
diff --git a/tests/checkasm/checkasm.h b/tests/checkasm/checkasm.h
index 9e8e879fd3..a5c593e7b9 100644
--- a/tests/checkasm/checkasm.h
+++ b/tests/checkasm/checkasm.h
@@ -72,6 +72,7 @@ void checkasm_check_utvideodsp(void);
void checkasm_check_v210enc(void);
void checkasm_check_vf_hflip(void);
void checkasm_check_vf_threshold(void);
+void checkasm_check_vf_yadif(void);
void checkasm_check_vp8dsp(void);
void checkasm_check_vp9dsp(void);
void checkasm_check_videodsp(void);
diff --git a/tests/checkasm/vf_yadif.c b/tests/checkasm/vf_yadif.c
new file mode 100644
index 00..d011a2771d
--- /dev/null
+++ b/tests/checkasm/vf_yadif.c
@@ -0,0 +1,137 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 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 General Public License for more details.
+ *
+ * You should have received a copy of the GNU 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 "checkasm.h"
+#include "libavfilter/yadif.h"
+#include "libavutil/intreadwrite.h"
+
+#define WIDTH 64
+#define HEIGHT 4
+#define SIZE WIDTH * HEIGHT + 32
+
+#define randomize_buffers(buf, size) \
+do { \
+int j;\
+uint8_t *tmp_buf = (uint8_t*)buf; \
+for (j = 0; j < size; j++)\
+tmp_buf[j] = rnd() & 0xFF;\
+} while (0)
+
+#define randomize_buffers_10(buf, size)\
+do { \
+int j; \
+uint16_t *tmp_buf = (uint1
Re: [FFmpeg-devel] Rename RSHIFT macro to ROUNDED_RSHIFT
On Wed, Jan 23, 2019 at 3:31 AM Uoti Urpala wrote:
>
> On Tue, 2019-01-22 at 15:35 -0300, James Almer wrote:
> > I'm not against renaming it to AV_ROUNDED_RSHIFT or similar, but other
> > than an entry in APIChanges we have no way to let library users that
> > RSHIFT will be removed two or so years from now.
>
> How about:
> static inline void __attribute__ ((deprecated)) RSHIFT_is_deprecated(void) {}
>
> #define RSHIFT(a, b) (RSHIFT_is_deprecated(), AV_ROUNDED_SHIFT(a, b))
>
I like this idear
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH V2] avcodec/libx265: add support for ROI-based encoding
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Derek Buitenhuis
> Sent: Tuesday, January 22, 2019 10:31 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH V2] avcodec/libx265: add support for
> ROI-based encoding
>
> On 21/01/2019 14:40, Guo, Yejun wrote:
>
> [...]
>
> > +} else {
> > +// 8x8 block when qg-size is 8, 16*16 block otherwise
>
> Cosmetic: Comments should be /**/ to match the rest of the file.
ok, and will also change the style of other two comments.
>
> > +int mb_size = (ctx->params->rc.qgSize == 8) ? 8 : 16;
> > +int mbx = (frame->width + mb_size - 1) / mb_size;
> > +int mby = (frame->height + mb_size - 1) / mb_size;
> > +int nb_rois;
> > +AVRegionOfInterest* roi;
>
> Cosmetic: File style is Type *name;
ok, and will also change another place to float *.
>
> > +if (roi->qoffset.den == 0) {
> > +av_free(qoffsets);
> > +av_log(ctx, AV_LOG_ERROR,
> > + "AVRegionOfInterest.qoffset.den should not be zero.\n");
>
> Nit: s/should/must/
ok, will also change the wording later.
> > +for (int y = starty; y < endy; y++) {
> > +for (int x = startx; x < endx; x++) {
> > +qoffsets[x + y*mbx] = qoffset;
> > +}
> > +}
>
> Cosmetic: Braces not necessary.
ok, will remove it to match the rest of code.
>
> > +
> > +if (roi->self_size == 0) {
> > +av_free(qoffsets);
> > +av_log(ctx, AV_LOG_ERROR, "AVRegionOfInterest.self_size
> should be set to sizeof(AVRegionOfInterest).\n");
> > +return AVERROR(EINVAL);
> > +}
>
> Check should probably be outside loop.
The check have to be within the loop, since 'roi' changes with the loop
iteration.
To refine the code, I'll move them near to the check of roi->qoffset.den.
>
>
> > static int libx265_encode_frame(AVCodecContext *avctx, AVPacket *pkt,
> > const AVFrame *pic, int *got_packet)
> > {
>
> > +if (x265pic.quantOffsets)
> > +av_freep(&x265pic.quantOffsets);
>
> The NULL check is redundant since av_freep does this check internally.
thanks, will remove it.
>
> Sorry for for the bits I should have posted in v1 of the patch. All of my
> comments are very minor, or cosmetic in nature, and, in my opinion, can just
> be applied by whoever pushes it.
thanks, no problem, just to make the code better. :)
>
> - Derek
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
