Re: [FFmpeg-devel] [PATCH V2 2/2] libswscale/x86/yuv2rgb: add ssse3 version
On Mon, Dec 02, 2019 at 11:12:42AM +0800, Ting Fu wrote: > Tested using this command: > /ffmpeg -pix_fmt yuv420p -s 1920*1080 -i ArashRawYuv420.yuv \ > -vcodec rawvideo -s 1920*1080 -pix_fmt rgb24 -f null /dev/null > > The fps increase from 389 to 640 on my local machine. > > Signed-off-by: Ting Fu > --- > libswscale/x86/yuv2rgb.c | 8 +- > libswscale/x86/yuv2rgb_template.c | 58 ++- > libswscale/x86/yuv_2_rgb.asm | 162 +++--- > 3 files changed, 209 insertions(+), 19 deletions(-) one of these patches seems to produce new warnings like: libswscale/x86/yuv2rgb_template.c: In function ‘yuv420_rgb15’: libswscale/x86/yuv2rgb_template.c:113:5: warning: passing argument 5 of ‘ff_yuv_420_rgb15_ssse3’ from [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 2 "100% positive feedback" - "All either got their money back or didnt complain" "Best seller ever, very honest" - "Seller refunded buyer after failed scam" signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/3] avformat/movenc: write the major brand also as the first compatible brand
On Mon, Dec 02, 2019 at 01:18:36PM -0300, James Almer wrote: > Signed-off-by: James Almer > --- > This is meant to be squashed with patch 2/3, otherwise it will write duplicate > compatible brands, and a lot of tests will have to be updated twice. I dont think 2 updates are a problem if it keeps the commits more readable [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Observe your enemies, for they first find out your faults. -- Antisthenes signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/3] avformat/movenc: write the major brand also as the first compatible brand
Am Mo., 2. Dez. 2019 um 17:19 Uhr schrieb James Almer : > > Signed-off-by: James Almer > --- > This is meant to be squashed with patch 2/3, otherwise it will write duplicate > compatible brands, and a lot of tests will have to be updated twice. > > I'm sending it like this to make reviewing/reading easier. Could you add a line about why writing the major brand as compatible brand is a good idea? Is this recommended or does it fix a player? Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] libswscale/x86/yuv2rgb: Change inline assembly into nasm code
Am Di., 3. Dez. 2019 um 04:53 Uhr schrieb Fu, Ting : > > > > > -Original Message- > > From: ffmpeg-devel On Behalf Of Carl > > Eugen Hoyos > > Sent: Monday, December 2, 2019 05:49 PM > > To: FFmpeg development discussions and patches > > Subject: Re: [FFmpeg-devel] [PATCH 1/2] libswscale/x86/yuv2rgb: Change > > inline > > assembly into nasm code > > > > Am Mo., 2. Dez. 2019 um 04:17 Uhr schrieb Fu, Ting : > > > > > > > > > > > > > -Original Message- > > > > From: ffmpeg-devel On Behalf Of > > > > Michael Niedermayer > > > > Sent: Friday, November 29, 2019 05:33 AM > > > > To: FFmpeg development discussions and patches > > > > > > > > Subject: Re: [FFmpeg-devel] [PATCH 1/2] libswscale/x86/yuv2rgb: > > > > Change inline assembly into nasm code > > > > > > > > On Thu, Nov 28, 2019 at 02:07:07PM +0800, Ting Fu wrote: > > > > > Signed-off-by: Ting Fu > > > > > --- > > > > > libswscale/x86/Makefile | 1 + > > > > > libswscale/x86/swscale.c | 16 +- > > > > > libswscale/x86/yuv2rgb.c | 81 ++ > > > > > libswscale/x86/yuv2rgb_template.c | 441 > > > > > ++ > > > > > libswscale/x86/yuv_2_rgb.asm | 270 ++ > > > > > 5 files changed, 394 insertions(+), 415 deletions(-) create mode > > > > > 100644 libswscale/x86/yuv_2_rgb.asm > > > > > > > > This changes the output, i presume that is unintentional > > > > > > > > ./ffmpeg -cpuflags 0 -i matrixbench_mpeg2.mpg -t 1 -vf > > > > format=yuv420p,format=rgb565le -an -f framecrc - > > > > > > > > 0, 0, 0,1, 829440, 0x1bd78b86 > > > > 0, 1, 1,1, 829440, 0x85910b33 > > > > ... > > > > vs. > > > > 0, 0, 0,1, 829440, 0x31f4a2bd > > > > 0, 1, 1,1, 829440, 0xf0c66218 > > > > ... > > > > > > > > > > > > > > Hi Michael, > > > > > > This unexpected change is because of the missing verify of current SIMD > > support. > > > So, when cpuflag=0, ffmpeg used mmx code to compute as default. > > > I added if (EXTERNAL_XXX(cpu_flags)) to verify the SIMD in > > libswscale/x86/yuv2rgb.c. > > > > Could the patch be split to make this change easier to understand? > > Hi Carl, > > I didn’t come across any good idea to separate the PATCH. > Since the [PATCH 1/2] is consisted of mmx code for > yuv2rgb24/bgr24/rgb32/bgr32/rgb15/rgb16 and they're all come from former > inline assembly. > Should it be separated into something like > PATCH 1: mmx yuv2rgb24/bgr24 > PATCH 2: mmx yuv2rgb32/bgr32 > PATCH 3: mmx yuv2rgb15/rgb16 > Or adding more comments in nasm file would be more helpful? > > Can you show me if there is any better solution? I cannot be more grateful to > it. I didn't want to imply that I know of a better way, just that your answer to Michael's question made me wonder if adding EXTERNAL_XXX() in a separate patch would fix his concern. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v3] Patch for memory optimization with QuickTime/MP4
Hi,
I recreated the patch from a clean source tree and applied it to a clean source
tree:
$ patch -p1 -i ../ffmpeg.patch
patching file libavformat/isom.h
patching file libavformat/mov.c
Hope it works now.
Cheers,
Jörg
---
libavformat/isom.h | 1 +
libavformat/mov.c | 50 +-
2 files changed, 50 insertions(+), 1 deletion(-)
diff --git a/libavformat/isom.h b/libavformat/isom.h
index 4943b80ccf..9b4753f4d7 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -268,6 +268,7 @@ typedef struct MOVContext {
int advanced_editlist;
int ignore_chapters;
int seek_individually;
+int discard_fragments;
int64_t next_root_atom; ///< offset of the next root atom
int export_all;
int export_xmp;
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 7553a7fdfc..97c02725c5 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -7698,8 +7698,11 @@ static int should_retry(AVIOContext *pb, int error_code)
{
static int mov_switch_root(AVFormatContext *s, int64_t target, int index)
{
-int ret;
+int ret, i;
MOVContext *mov = s->priv_data;
+AVStream *st = NULL;
+MOVStreamContext *sc;
+MOVFragment *frag;
if (index >= 0 && index < mov->frag_index.nb_items)
target = mov->frag_index.item[index].moof_offset;
@@ -7721,6 +7724,44 @@ static int mov_switch_root(AVFormatContext *s, int64_t
target, int index)
mov->found_mdat = 0;
+if (mov->discard_fragments) {
+frag = &mov->fragment;
+
+for (i = 0; i < mov->fc->nb_streams; i++) {
+if (mov->fc->streams[i]->id == frag->track_id) {
+st = mov->fc->streams[i];
+break;
+}
+}
+
+av_assert0(st);
+
+sc = st->priv_data;
+
+switch (st->codecpar->codec_type) {
+case AVMEDIA_TYPE_AUDIO:
+case AVMEDIA_TYPE_SUBTITLE:
+/* Freeing VIDEO tables leads to corrupted video when writing
to eg. MKV */
+av_freep(&st->index_entries);
+st->nb_index_entries = 0;
+st->index_entries_allocated_size = 0;
+
+sc->current_index = 0;
+sc->current_sample = 0;
+
+av_freep(&sc->ctts_data);
+sc->ctts_data = NULL;
+sc->ctts_allocated_size = 0;
+sc->ctts_count = 0;
+break;
+}
+
+av_free(mov->frag_index.item->stream_info);
+av_freep(&mov->frag_index.item);
+mov->frag_index.allocated_size = 0;
+mov->frag_index.nb_items = 0;
+}
+
ret = mov_read_default(mov, s->pb, (MOVAtom){ AV_RL32("root"), INT64_MAX
});
if (ret < 0)
return ret;
@@ -7975,6 +8016,9 @@ static int mov_read_seek(AVFormatContext *s, int
stream_index, int64_t sample_ti
int sample;
int i;
+if (mc->discard_fragments) // Seeking is not possible if fragments are
discarded.
+return AVERROR(ENOTSUP);
+
if (stream_index >= s->nb_streams)
return AVERROR_INVALIDDATA;
@@ -8063,6 +8107,10 @@ static const AVOption mov_options[] = {
{ "decryption_key", "The media decryption key (hex)",
OFFSET(decryption_key), AV_OPT_TYPE_BINARY, .flags = AV_OPT_FLAG_DECODING_PARAM
},
{ "enable_drefs", "Enable external track support.", OFFSET(enable_drefs),
AV_OPT_TYPE_BOOL,
{.i64 = 0}, 0, 1, FLAGS },
+{"discard_fragments",
+"Discards fragments after they have been read to support live
streams.",
+OFFSET(discard_fragments), AV_OPT_TYPE_BOOL, { .i64 = 0 },
+0, 1, FLAGS },
{ NULL },
};
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] Patch for memory optimization with QuickTime/MP4
Am Di., 3. Dez. 2019 um 09:27 Uhr schrieb Jörg Beckmann : > > Hi, > > I recreated the patch from a clean source tree and applied it to a clean > source tree: > > $ patch -p1 -i ../ffmpeg.patch > patching file libavformat/isom.h > patching file libavformat/mov.c > > Hope it works now. > > Cheers, > Jörg It does but all of the above is now part of the commit message, should be removed by whoever commits this. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 1/2] avformat/utils: simplify the code and remove av_strncasecmp
On Mon, Dec 02, 2019 at 12:51:05PM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavformat/utils.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index 8196442dd1..03a3705200 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -4854,11 +4854,10 @@ int ff_mkdir_p(const char *path)
> return -1;
> }
>
> -if (!av_strncasecmp(temp, "/", 1) || !av_strncasecmp(temp, "\\", 1)) {
> +if (*temp == '/' || *temp == '\\')
> pos++;
> -} else if (!av_strncasecmp(temp, "./", 2) || !av_strncasecmp(temp,
> ".\\", 2)) {
> +else if (*temp == '.' && (*(temp+1) == '/' || *(temp+1) == '\\'))
is this really simpler ? (compared to strncmp() for example) ?
it looks more obfuscated
also not sure about the {} removial
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] MAINTAINERS: add myself to libavfilter/dnn
On Sat, Nov 30, 2019 at 12:24:58PM +0800, Guo, Yejun wrote: > Signed-off-by: Guo, Yejun > --- > MAINTAINERS | 2 ++ > 1 file changed, 2 insertions(+) will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws. -- Plato signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavformat/utils: Fix code indentation
On Mon, Dec 02, 2019 at 09:53:47AM +0800, Linjie Fu wrote: > Introduced since 077939626eeaa0c1364065414c18ab9b3a072281. > > Signed-off-by: Linjie Fu > --- > libavformat/utils.c | 22 +++--- > 1 file changed, 11 insertions(+), 11 deletions(-) will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB During times of universal deceit, telling the truth becomes a revolutionary act. -- George Orwell signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/vf_unsharp: Don't dereference NULL
On Sun, Dec 01, 2019 at 11:04:36AM +0100, Paul B Mahol wrote: > LGTM will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have never wished to cater to the crowd; for what I know they do not approve, and what they approve I do not know. -- Epicurus signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/3] avfilter/vf_convolution: add X86 SIMD for filter_column()
comments inline in code At 2019-12-03 15:52:07, xuju...@sjtu.edu.cn wrote: >From: Xu Jun > >+; void filter_column(uint8_t *dst, int height, >+; float rdiv, float bias, const int *const matrix, >+; const uint8_t *c[], int length, int radius, >+; int dstride, int stride); >+ >+%if ARCH_X86_64 >+INIT_XMM sse4 >+%if UNIX64 >+cglobal filter_column, 8, 15, 7, dst, height, matrix, ptr, width, rad, >dstride, stride, i, ci, dst_off, off16, c_off, sum, r >+%else >+cglobal filter_column, 8, 15, 7, dst, height, rdiv, bias, matrix, ptr, width, >rad, dstride, stride, i, ci, dst_off, off16, c_off, sum, r >+%endif no idea, these are difficult to read and understand >+ >+%if WIN64 >+SWAP m0, m2 >+SWAP m1, m3 >+mov r2q, matrixmp >+mov r3q, ptrmp >+mov r4q, widthmp >+mov r5q, radmp >+mov r6q, dstridemp >+mov r7q, stridemp >+DEFINE_ARGS dst, height, matrix, ptr, width, rad, dstride, stride, i, ci, >dst_off, off16, c_off, sum, r >+%endif >+ >+movsxdifnidn widthq, widthd >+movsxdifnidn radq, radd >+movsxdifnidn dstrideq, dstrided >+movsxdifnidn strideq, strided >+sal radq, 1 >+add radq, 1 ;2*radius+1 I don't know how about compare to "LEA x,[y*2+1]" AndI want not discuss in between SAL and SHL >+movsxdifnidn heightq, heightd >+VBROADCASTSS m0, m0 >+VBROADCASTSS m1, m1 >+pxor m6, m6 >+movss m5, [half] >+VBROADCASTSS m5, m5 >+ >+xor dst_offq, dst_offq >+xor c_offq, c_offq >+ >+.loopy: >+xor off16q, off16q >+cmp widthq, mmsize/4 >+jl .loopr >+ >+mov rq, widthq >+and rq, mmsize/4-1 >+sub widthq, rq >+ >+.loop16: ;parallel process 16 elements in a row Processing 4 column per loop, are you means, we want to save lots of unused register? We claim X64, so we have 16 of XMMs >+pxor m4, m4 >+xor iq, iq >+.loopi: >+movss m2, [matrixq + 4*iq] no idea that you working on Float data path, we are lucky, Intel CPU sounds not penalty in here. >+VBROADCASTSS m2, m2 >+mov ciq, [ptrq + iq * gprsize] >+movss m3, [ciq + c_offq] ;c[i][y*stride + off16] >+punpcklbw m3, m6 >+punpcklwd m3, m6 Since you claim SSE4, the instruction PMOVZXBD available, moreover, SSE4 register can be full fill 16 of uint8, but load 4 of them only. >+pmulld m2, m3 >+paddd m4, m2 >+ >+add iq, 1 >+cmp iq, radq When you initial iq to radq and decrement per loop, you can reduce one instruction I know iq is work as index in the loop, but we can found some trick over there. >+jl .loopi >+ >+cvtdq2ps m4, m4 >+mulps m4, m0 ; sum *= rdiv >+addps m4, m1 ; sum += bias >+addps m4, m5 ; sum += 0.5 I don't know how about precision mismatch if we pre-compute (bias+0.5) >+cvttps2dq m4, m4 >+packssdw m4, m4 >+packuswb m4, m4 >+movss [dstq + dst_offq], m4 >+add c_offq, mmsize/4 >+add dst_offq, mmsize/4 >+ >+add off16q, mmsize/4 >+cmp off16q, widthq >+jl .loop16 >+ >+add widthq, rq >+cmp off16q, widthq >+jge .paraend >+ >+.loopr: no idea about this loop, if we can read beyond, we can reuse above SIMD code >+xor sumd, sumd >+xor iq, iq >+.loopr_i: >+mov ciq, [ptrq + iq * gprsize] >+movzx rd, byte [ciq + c_offq] >+imul rd, [matrixq + 4*iq] >+add sumd, rd >+ >+add iq, 1 >+cmp iq, radq >+jl .loopr_i >+ >+pxor m4, m4 >+cvtsi2ss m4, sumd >+mulss m4, m0 ; sum *= rdiv >+addss m4, m1 ; sum += bias >+addss m4, m5 ; sum += 0.5 >+cvttps2dq m4, m4 >+packssdw m4, m4 >+packuswb m4, m4 >+movd sumd, m4 >+mov [dstq + dst_offq], sumb >+add c_offq, 1 >+add dst_offq, 1 >+add off16q, 1 >+cmp off16q, widthq >+jl .loopr >+ >+.paraend: >+sub c_offq, widthq >+sub dst_offq, widthq >+add c_offq, strideq >+add dst_offq, dstrideq >+ >+sub heightq, 1 >+cmp heightq, 0 >+jg .loopy >+ >+.end: >+RET ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/vf_yaepblur: add yaepblur filter
ping:)
leozhang 于2019年11月25日周一 下午5:53写道：
>
> Signed-off-by: leozhang
> ---
> This filter blur the input while preserving edges, with slice threads speed
> up.
> My test speed is about 100fps on 1080p video with 16 threads, on my test
> machine whose cpu is E5-2660 v4 2.0GHz using 16 threads.
> I gauss that i7-9700K 3.6GHz can run faster more.
> The test command is
> ffmpeg -s 1920x1080 -r 30 -i your_test_file.yuv -filter_threads 16 -vf
> yaepblur -f null -
>
> doc/filters.texi | 22 +++
> libavfilter/Makefile | 1 +
> libavfilter/allfilters.c | 1 +
> libavfilter/vf_yaepblur.c | 349
> ++
> 4 files changed, 373 insertions(+)
> create mode 100644 libavfilter/vf_yaepblur.c
>
> diff --git a/doc/filters.texi b/doc/filters.texi
> index c04421b..61e93d5 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -19775,6 +19775,28 @@ Only deinterlace frames marked as interlaced.
> The default value is @code{all}.
> @end table
>
> +@section yaepblur
> +
> +Apply blur filter while preserving edges ("yaepblur" means "yet another edge
> preserving blur filter").
> +The algorithm is described in
> +"J. S. Lee, Digital image enhancement and noise filtering by use of local
> statistics, IEEE Trans. Pattern Anal. Mach. Intell. PAMI-2, 1980."
> +
> +It accepts the following parameters:
> +
> +@table @option
> +@item radius, r
> +Set the window radius. Default value is 3.
> +
> +@item planes, p
> +Set which planes to filter. Default is only the first plane.
> +
> +@item sigma, s
> +Set blur strength. Default value is 128.
> +@end table
> +
> +@subsection Commands
> +This filter supports same @ref{commands} as options.
> +
> @section zoompan
>
> Apply Zoom & Pan effect.
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index 6838d5c..b490a44 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -442,6 +442,7 @@ OBJS-$(CONFIG_XSTACK_FILTER) +=
> vf_stack.o framesync.o
> OBJS-$(CONFIG_YADIF_FILTER) += vf_yadif.o yadif_common.o
> OBJS-$(CONFIG_YADIF_CUDA_FILTER) += vf_yadif_cuda.o
> vf_yadif_cuda.ptx.o \
> yadif_common.o
> +OBJS-$(CONFIG_YAEPBLUR_FILTER) += vf_yaepblur.o
> OBJS-$(CONFIG_ZMQ_FILTER)+= f_zmq.o
> OBJS-$(CONFIG_ZOOMPAN_FILTER)+= vf_zoompan.o
> OBJS-$(CONFIG_ZSCALE_FILTER) += vf_zscale.o
> diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
> index 7c1e19e..8f41186 100644
> --- a/libavfilter/allfilters.c
> +++ b/libavfilter/allfilters.c
> @@ -420,6 +420,7 @@ extern AVFilter ff_vf_xmedian;
> extern AVFilter ff_vf_xstack;
> extern AVFilter ff_vf_yadif;
> extern AVFilter ff_vf_yadif_cuda;
> +extern AVFilter ff_vf_yaepblur;
> extern AVFilter ff_vf_zmq;
> extern AVFilter ff_vf_zoompan;
> extern AVFilter ff_vf_zscale;
> diff --git a/libavfilter/vf_yaepblur.c b/libavfilter/vf_yaepblur.c
> new file mode 100644
> index 000..ef6fbc9
> --- /dev/null
> +++ b/libavfilter/vf_yaepblur.c
> @@ -0,0 +1,349 @@
> +/*
> + * Copyright (C) 2019 Leo Zhang
> +
> + * 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
> + */
> +
> +/**
> + * @file
> + * yaep(yet another edge preserving) blur filter
> + *
> + * This implementation is based on an algorithm described in
> + * "J. S. Lee, Digital image enhancement and noise filtering by use of local
> statistics, IEEE Trans. Pattern
> + * Anal. Mach. Intell. PAMI-2, 1980."
> + */
> +
> +#include "libavutil/opt.h"
> +#include "libavutil/imgutils.h"
> +#include "avfilter.h"
> +#include "internal.h"
> +
> +typedef struct YAEPContext {
> +const AVClass *class;
> +
> +int planes;
> +int radius;
> +int sigma;
> +
> +int nb_planes;
> +int planewidth[4];
> +int planeheight[4];
> +int depth;
> +
> +uint64_t *sat;///< summed area table
> +uint64_t *square_sat; ///< square summed area table
> +int sat_linesize;
> +
> +int (*pre_calculate_row)(AVFilterContext *ctx, void *arg, int jobnr, int
> nb_jobs);
> +int (*filter_slice )(AVFilterContext *ctx, void *arg, int jobnr, int
> nb_jobs);
> +} YAEPContext;
> +
> +stati
Re: [FFmpeg-devel] [PATCHv2 01/10] avformat/mpegtsenc: allow any sensible PID for elementary and PMT PIDs
On Wed, 13 Nov 2019, Marton Balint wrote: This sets the range of the first automatically assigned PMT PID or elementary stream PID parameters to [0x20, 0x1ffa]. You can still assign manually a PID for a stream using AVStream->id in the wider [0x10, 0x1ffe] range as specified by ISO13818-1. But since DVB and ATSC both reserves some PIDs, let's not allow them to be automatically assigned. Also make sure that assigned PID numbers are valid and fix the error message for the previous PID collision checks. Applied patches 1-5 for now. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avformat/hls: Use av_packet_move_ref() for packet ownership transfer
On Tue, Dec 3, 2019 at 11:27 AM Andreas Rheinhardt < andreas.rheinha...@gmail.com> wrote: > Signed-off-by: Andreas Rheinhardt > --- > libavformat/hls.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > I accidentally resent this; please ignore it. - Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/2] avformat/hls: Use av_packet_move_ref() for packet ownership transfer
Signed-off-by: Andreas Rheinhardt --- libavformat/hls.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/libavformat/hls.c b/libavformat/hls.c index 21353bbad7..f60396f246 100644 --- a/libavformat/hls.c +++ b/libavformat/hls.c @@ -2201,9 +2201,8 @@ static int hls_read_packet(AVFormatContext *s, AVPacket *pkt) ist = pls->ctx->streams[pls->pkt.stream_index]; st = pls->main_streams[pls->pkt.stream_index]; -*pkt = pls->pkt; +av_packet_move_ref(pkt, &pls->pkt); pkt->stream_index = st->index; -reset_packet(&c->playlists[minplaylist]->pkt); if (pkt->dts != AV_NOPTS_VALUE) c->cur_timestamp = av_rescale_q(pkt->dts, -- 2.20.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/rmdec: Use av_packet_move_ref() for packet ownership transfer
Signed-off-by: Andreas Rheinhardt
---
libavformat/rmdec.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/libavformat/rmdec.c b/libavformat/rmdec.c
index e612c42e57..2c40b866aa 100644
--- a/libavformat/rmdec.c
+++ b/libavformat/rmdec.c
@@ -836,10 +836,7 @@ static int rm_assemble_video_frame(AVFormatContext *s,
AVIOContext *pb,
if (type == 2 || vst->videobufpos == vst->videobufsize) {
vst->pkt.data[0] = vst->cur_slice-1;
-*pkt= vst->pkt;
-vst->pkt.data= NULL;
-vst->pkt.size= 0;
-vst->pkt.buf = NULL;
+av_packet_move_ref(pkt, &vst->pkt);
if(vst->slices != vst->cur_slice) //FIXME find out how to set slices
correct from the begin
memmove(pkt->data + 1 + 8*vst->cur_slice, pkt->data + 1 +
8*vst->slices,
vst->videobufpos - 1 - 8*vst->slices);
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH V3 1/2] lavf/libsrt: add linger parameter to libsrt
From: Jun Zhao
add linger parameter to libsrt, it's setting the number of seconds
that the socket waits for unsent data when closing.
Reviewed-by: Andriy Gelman
Signed-off-by: Jun Zhao
---
doc/protocols.texi |5 +
libavformat/libsrt.c | 13 +
2 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/doc/protocols.texi b/doc/protocols.texi
index 0e18a49..eab6242 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -1426,6 +1426,11 @@ the overhead transmission (retransmitted and control
packets).
file: Set options as for non-live transmission. See @option{messageapi}
for further explanations
+@item linger=@var{seconds}
+The number of seconds that the socket waits for unsent data when closing.
+Default is -1. -1 means auto (off with 0 seconds in live mode, on with 180
+seconds in file mode).
+
@end table
For more information see: @url{https://github.com/Haivision/srt}.
diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c
index 1c34ec5..0a748a1 100644
--- a/libavformat/libsrt.c
+++ b/libavformat/libsrt.c
@@ -84,6 +84,7 @@ typedef struct SRTContext {
char *smoother;
int messageapi;
SRT_TRANSTYPE transtype;
+int linger;
} SRTContext;
#define D AV_OPT_FLAG_DECODING_PARAM
@@ -128,6 +129,7 @@ static const AVOption libsrt_options[] = {
{ "transtype", "The transmission type for the socket",
OFFSET(transtype),AV_OPT_TYPE_INT, { .i64 =
SRTT_INVALID }, SRTT_LIVE, SRTT_INVALID, .flags = D|E, "transtype" },
{ "live", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = SRTT_LIVE },
INT_MIN, INT_MAX, .flags = D|E, "transtype" },
{ "file", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = SRTT_FILE },
INT_MIN, INT_MAX, .flags = D|E, "transtype" },
+{ "linger", "Number of seconds that the socket waits for unsent
data when closing", OFFSET(linger), AV_OPT_TYPE_INT, { .i64 = -1
}, -1, INT_MAX, .flags = D|E },
{ NULL }
};
@@ -340,6 +342,14 @@ static int libsrt_set_options_pre(URLContext *h, int fd)
((h->flags & AVIO_FLAG_WRITE) && libsrt_setsockopt(h, fd, SRTO_SENDER,
"SRTO_SENDER", &yes, sizeof(yes)) < 0)) {
return AVERROR(EIO);
}
+
+if (s->linger >= 0) {
+struct linger lin;
+lin.l_linger = s->linger;
+lin.l_onoff = lin.l_linger > 0 ? 1 : 0;
+if (libsrt_setsockopt(h, fd, SRTO_LINGER, "SRTO_LINGER", &lin,
sizeof(lin)) < 0)
+return AVERROR(EIO);
+}
return 0;
}
@@ -591,6 +601,9 @@ static int libsrt_open(URLContext *h, const char *uri, int
flags)
goto err;
}
}
+if (av_find_info_tag(buf, sizeof(buf), "linger", p)) {
+s->linger = strtol(buf, NULL, 10);
+}
}
return libsrt_setup(h, uri, flags);
err:
--
1.7.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH V3 0/2] Enable other srt options.
V3: - add more details for linger options. tks Andriy Gelman's comments - fix minor typo in commit message. V2: - correct the commit message. Jun Zhao (2): lavf/libsrt: add linger parameter to libsrt lavf/libsrt: enable other encryption parameters doc/protocols.texi | 21 + libavformat/libsrt.c | 31 +++ 2 files changed, 52 insertions(+), 0 deletions(-) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH V1 2/2] lavfi/avf_showspectrum: Fix the memory leak in error handle path
From: Jun Zhao
Fix the memory leak in error handle path.
Signed-off-by: Jun Zhao
---
libavfilter/avf_showspectrum.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/libavfilter/avf_showspectrum.c b/libavfilter/avf_showspectrum.c
index d5785af..3a3ef7e 100644
--- a/libavfilter/avf_showspectrum.c
+++ b/libavfilter/avf_showspectrum.c
@@ -700,16 +700,15 @@ static int draw_legend(AVFilterContext *ctx, int samples)
drawtext(s->outpicref, 2, outlink->h - 10, "CREATED BY LIBAVFILTER", 0);
drawtext(s->outpicref, outlink->w - 2 - strlen(text) * 10, outlink->h -
10, text, 0);
+av_freep(&text);
if (s->stop) {
-char *text = av_asprintf("Zoom: %d Hz - %d Hz", s->start, s->stop);
+text = av_asprintf("Zoom: %d Hz - %d Hz", s->start, s->stop);
if (!text)
return AVERROR(ENOMEM);
drawtext(s->outpicref, outlink->w - 2 - strlen(text) * 10, 3, text, 0);
av_freep(&text);
}
-av_freep(&text);
-
dst = s->outpicref->data[0] + (s->start_y - 1) * s->outpicref->linesize[0]
+ s->start_x - 1;
for (x = 0; x < s->w + 1; x++)
dst[x] = 200;
--
1.7.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH V3 1/2] lavf/libsrt: add linger parameter to libsrt
On 03-12-2019 04:27 pm, Jun Zhao wrote:
From: Jun Zhao
add linger parameter to libsrt, it's setting the number of seconds
that the socket waits for unsent data when closing.
Reviewed-by: Andriy Gelman
Signed-off-by: Jun Zhao
---
doc/protocols.texi |5 +
libavformat/libsrt.c | 13 +
2 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/doc/protocols.texi b/doc/protocols.texi
index 0e18a49..eab6242 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -1426,6 +1426,11 @@ the overhead transmission (retransmitted and control
packets).
file: Set options as for non-live transmission. See @option{messageapi}
for further explanations
+@item linger=@var{seconds}
+The number of seconds that the socket waits for unsent data when closing.
+Default is -1. -1 means auto (off with 0 seconds in live mode, on with 180
+seconds in file mode).
Add range info.
Gyan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH V3 2/2] lavf/libsrt: enable other encryption parameters
From: Jun Zhao
Enable the SRTO_ENFORCEDENCRYPTION/SRTO_KMREFRESHRATE/
SRTO_KMPREANNOUNCE for srt encryption control.
Signed-off-by: Jun Zhao
---
doc/protocols.texi | 16
libavformat/libsrt.c | 18 ++
2 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/doc/protocols.texi b/doc/protocols.texi
index eab6242..04f6e8b 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -1282,6 +1282,22 @@ only if @option{pbkeylen} is non-zero. It is used on
the receiver only if the received data is encrypted.
The configured passphrase cannot be recovered (write-only).
+@item enforced_encryption=@var{1|0}
+If true, both connection parties must have the same password
+set (including empty, that is, with no encryption). If the
+password doesn't match or only one side is unencrypted,
+the connection is rejected. Default is true.
+
+@item kmrefreshrate=@var{n}
+The number of packets to be transmitted after which the
+encryption key is switched to a new key.
+
+@item kmpreannounce=@var{n}
+The interval between when a new encryption key is sent and
+when switchover occurs. This value also applies to the
+subsequent interval between when switchover occurs and
+when the old encryption key is decommissioned.
+
@item payload_size=@var{bytes}
Sets the maximum declared size of a packet transferred
during the single call to the sending function in Live
diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c
index 0a748a1..06f2c02 100644
--- a/libavformat/libsrt.c
+++ b/libavformat/libsrt.c
@@ -62,6 +62,9 @@ typedef struct SRTContext {
int64_t maxbw;
int pbkeylen;
char *passphrase;
+int enforced_encryption;
+int kmrefreshrate;
+int kmpreannounce;
int mss;
int ffs;
int ipttl;
@@ -102,6 +105,9 @@ static const AVOption libsrt_options[] = {
{ "maxbw", "Maximum bandwidth (bytes per second) that the
connection can use", OFFSET(maxbw),AV_OPT_TYPE_INT64,{ .i64
= -1 }, -1, INT64_MAX, .flags = D|E },
{ "pbkeylen", "Crypto key len in bytes {16,24,32} Default: 16
(128-bit)", OFFSET(pbkeylen), AV_OPT_TYPE_INT, { .i64
= -1 }, -1, 32,.flags = D|E },
{ "passphrase", "Crypto PBKDF2 Passphrase size[0,10..64] 0:disable
crypto", OFFSET(passphrase), AV_OPT_TYPE_STRING, { .str =
NULL }, .flags = D|E },
+{ "enforced_encryption", "Enforces that both connection parties have
the same passphrase set ", OFFSET(enforced_encryption),AV_OPT_TYPE_INT,
{ .i64 = -1 }, -1, 1, .flags = D|E },
+{ "kmrefreshrate", "The number of packets to be transmitted after
which the encryption key is switched to a new key", OFFSET(kmrefreshrate),
AV_OPT_TYPE_INT, { .i64 = -1 }, -1, INT_MAX, .flags = D|E },
+{ "kmpreannounce", "The interval between when a new encryption key
is sent and when switchover occurs", OFFSET(kmpreannounce),
AV_OPT_TYPE_INT, { .i64 = -1 }, -1, INT_MAX, .flags = D|E },
{ "mss","The Maximum Segment Size",
OFFSET(mss), AV_OPT_TYPE_INT, { .i64 = -1 },
-1, 1500, .flags = D|E },
{ "ffs","Flight flag size (window size) (in bytes)",
OFFSET(ffs), AV_OPT_TYPE_INT, { .i64 = -1 },
-1, INT_MAX, .flags = D|E },
{ "ipttl", "IP Time To Live",
OFFSET(ipttl),AV_OPT_TYPE_INT, { .i64 = -1 },
-1, 255, .flags = D|E },
@@ -321,6 +327,9 @@ static int libsrt_set_options_pre(URLContext *h, int fd)
(s->maxbw >= 0 && libsrt_setsockopt(h, fd, SRTO_MAXBW, "SRTO_MAXBW",
&s->maxbw, sizeof(s->maxbw)) < 0) ||
(s->pbkeylen >= 0 && libsrt_setsockopt(h, fd, SRTO_PBKEYLEN,
"SRTO_PBKEYLEN", &s->pbkeylen, sizeof(s->pbkeylen)) < 0) ||
(s->passphrase && libsrt_setsockopt(h, fd, SRTO_PASSPHRASE,
"SRTO_PASSPHRASE", s->passphrase, strlen(s->passphrase)) < 0) ||
+(s->enforced_encryption >= 0 && libsrt_setsockopt(h, fd,
SRTO_ENFORCEDENCRYPTION, "SRTO_ENFORCEDENCRYPTION", &s->enforced_encryption,
sizeof(s->enforced_encryption)) < 0) ||
+(s->kmrefreshrate >= 0 && libsrt_setsockopt(h, fd, SRTO_KMREFRESHRATE,
"SRTO_KMREFRESHRATE", &s->kmrefreshrate, sizeof(s->kmrefreshrate)) < 0) ||
+(s->kmpreannounce >= 0 && libsrt_setsockopt(h, fd, SRTO_KMPREANNOUNCE,
"SRTO_KMPREANNOUNCE", &s->kmpreannounce, sizeof(s->kmpreannounce)) < 0) ||
(s->mss >= 0 && libsrt_setsockopt(h, fd, SRTO_MSS, "SRTO_MMS",
&s->mss, sizeof(s->mss)) < 0) ||
(s->ffs >= 0 && libsrt_setsockopt(h, fd, SRTO_FC, "SRTO_FC", &s->ffs,
sizeof(s->ffs)) < 0) ||
(s->ipttl >= 0 && libsrt_setsockopt(h, fd, SRTO_IPTTL, "SRTO_UPTTL",
&s->ipttl, sizeof(s->ipttl)) < 0) ||
@@ -506,6 +515,15 @@ static int libsrt_open(URLCo
[FFmpeg-devel] [PATCH] avformat/ttaenc: Don't unnecessarily copy packets
When the tta muxer writes the actual packet data at the end of the
muxing process, it repeatedly copies the packets contained in the
linked list of stored packets to an AVPacket located on the stack via
ff_packet_list_get(), writes the data and unrefs the packet.
But when one is willing to traverse and free the linked list oneself,
one can get rid of the copying. This also means that the tta muxer does
not rely on sizeof(AVPacket) any more.
Signed-off-by: Andreas Rheinhardt
---
libavformat/ttaenc.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/libavformat/ttaenc.c b/libavformat/ttaenc.c
index 73c29ae936..84e3937141 100644
--- a/libavformat/ttaenc.c
+++ b/libavformat/ttaenc.c
@@ -122,13 +122,16 @@ static int tta_write_packet(AVFormatContext *s, AVPacket
*pkt)
static void tta_queue_flush(AVFormatContext *s)
{
TTAMuxContext *tta = s->priv_data;
-AVPacket pkt;
-
-while (tta->queue) {
-ff_packet_list_get(&tta->queue, &tta->queue_end, &pkt);
-avio_write(s->pb, pkt.data, pkt.size);
-av_packet_unref(&pkt);
+AVPacketList *entry = tta->queue;
+
+while (entry) {
+AVPacketList *next = entry->next;
+avio_write(s->pb, entry->pkt.data, entry->pkt.size);
+av_packet_unref(&entry->pkt);
+av_free(entry);
+entry = next;
}
+tta->queue = tta->queue_end = NULL;
}
static int tta_write_trailer(AVFormatContext *s)
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/3] avformat/movenc: write the major brand also as the first compatible brand
On 12/3/2019 5:20 AM, Carl Eugen Hoyos wrote: > Am Mo., 2. Dez. 2019 um 17:19 Uhr schrieb James Almer : >> >> Signed-off-by: James Almer >> --- >> This is meant to be squashed with patch 2/3, otherwise it will write >> duplicate >> compatible brands, and a lot of tests will have to be updated twice. >> >> I'm sending it like this to make reviewing/reading easier. > > Could you add a line about why writing the major brand as compatible > brand is a good idea? Is this recommended or does it fix a player? > > Thank you, Carl Eugen The DASH IF validator complains about it when the major isn't listed again as a compatible brand. We're already writing the major a second time in some specific cases. See the checks for mov, psp and 3gp I'm removing at the end of this patch. For mp4 it depended on a magic combination of options. I'm just making it cleaner and more general. There's also ticket 8375 which may or may not be fixed by this. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH V1 1/2] lavf/rtmpproto: Don't unref uninitialized buffers
From: Jun Zhao This happens if ffurl_open_whitelist fails and stream is unset. Signed-off-by: Jun Zhao --- libavformat/rtmpproto.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/libavformat/rtmpproto.c b/libavformat/rtmpproto.c index 5274993..42aacbd 100644 --- a/libavformat/rtmpproto.c +++ b/libavformat/rtmpproto.c @@ -,7 +,7 @@ static int rtmp_calc_swfhash(URLContext *s) RTMPContext *rt = s->priv_data; uint8_t *in_data = NULL, *out_data = NULL, *swfdata; int64_t in_size; -URLContext *stream; +URLContext *stream = NULL; char swfhash[32]; int swfsize; int ret = 0; -- 1.7.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/ttaenc: Don't unnecessarily copy packets
On 12/3/2019 8:34 AM, Andreas Rheinhardt wrote:
> When the tta muxer writes the actual packet data at the end of the
> muxing process, it repeatedly copies the packets contained in the
> linked list of stored packets to an AVPacket located on the stack via
> ff_packet_list_get(), writes the data and unrefs the packet.
>
> But when one is willing to traverse and free the linked list oneself,
> one can get rid of the copying.
Why even add a packet list API if we're just going to reimplement it
manually in a module to save the equivalent of one call to
av_packet_move_ref() of negligible performance?
For that matter, the subject makes it sound you're preventing copying
the packet payload rather than the AVPacket struct.
If at some point this API is made public, AVPacketList may become
opaque. I don't think this micro-optimization is worth the trouble.
> This also means that the tta muxer does
> not rely on sizeof(AVPacket) any more.
This is a good idea, but I'd rather instead alloc the buffer packet at
init() and keep the clean loop calling ff_packet_list_get().
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/ttaenc.c | 15 +--
> 1 file changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/libavformat/ttaenc.c b/libavformat/ttaenc.c
> index 73c29ae936..84e3937141 100644
> --- a/libavformat/ttaenc.c
> +++ b/libavformat/ttaenc.c
> @@ -122,13 +122,16 @@ static int tta_write_packet(AVFormatContext *s,
> AVPacket *pkt)
> static void tta_queue_flush(AVFormatContext *s)
> {
> TTAMuxContext *tta = s->priv_data;
> -AVPacket pkt;
> -
> -while (tta->queue) {
> -ff_packet_list_get(&tta->queue, &tta->queue_end, &pkt);
> -avio_write(s->pb, pkt.data, pkt.size);
> -av_packet_unref(&pkt);
> +AVPacketList *entry = tta->queue;
> +
> +while (entry) {
> +AVPacketList *next = entry->next;
> +avio_write(s->pb, entry->pkt.data, entry->pkt.size);
> +av_packet_unref(&entry->pkt);
> +av_free(entry);
> +entry = next;
> }
> +tta->queue = tta->queue_end = NULL;
> }
>
> static int tta_write_trailer(AVFormatContext *s)
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavf/movenc: Replace dts by pts to calculate duration
On Thu, 28 Nov 2019, manuelyuan wrote: There are many UGC videos with dynamic frame rates, which are represented by PTS jumps. After transcoding with ffmpeg -vsync 0 or -vsync 2, the output video duration becomes longer. Did you post any reproduction case of what, exactly (which field in which box), you think is wrong? Right now, this patch, among other things, breaks the implied last duration of the last packet in a fragment. This can be reproduced by with the lavf-movenc test, like this: $ make libavformat/tests/movenc $ libavformat/tests/movenc -w Then inspect vfr-noduration.mp4 (with a suitable tool, e.g. L-SMASH's boxdumper). Previously, the last packet in each fragment got an inferred/guessed duration (if the duration field of the AVFrame was zero) based on earlier frame intervals, but with your patch it is zero. I'm fairly convinced that most of the changes in your patch shouldn't be made, but to make the discussion proceed you need to _exactly_ specify what you think is wrong, in a way that others can reproduce. // Martin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/ttaenc: Don't unnecessarily copy packets
On Tue, Dec 3, 2019 at 1:20 PM James Almer wrote:
> On 12/3/2019 8:34 AM, Andreas Rheinhardt wrote:
> > When the tta muxer writes the actual packet data at the end of the
> > muxing process, it repeatedly copies the packets contained in the
> > linked list of stored packets to an AVPacket located on the stack via
> > ff_packet_list_get(), writes the data and unrefs the packet.
> >
> > But when one is willing to traverse and free the linked list oneself,
> > one can get rid of the copying.
>
> Why even add a packet list API if we're just going to reimplement it
> manually in a module to save the equivalent of one call to
> av_packet_move_ref() of negligible performance?
>
Ok, patch dropped.
> For that matter, the subject makes it sound you're preventing copying
> the packet payload rather than the AVPacket struct.
>
> If at some point this API is made public, AVPacketList may become
> opaque.
>
> And I thought that the only thing that changes will be that next moves to
the beginning of AVPacketList so that sizeof(AVPacket) can change without
affecting the offset of next. (Removing the dependence on sizeof(AVPacket)
(and not the performance improvement) was actually my motivation, as it is
with my av_packet_move_ref() patches.)
> This also means that the tta muxer does
> > not rely on sizeof(AVPacket) any more.
>
> This is a good idea, but I'd rather instead alloc the buffer packet at
> init() and keep the clean loop calling ff_packet_list_get().
>
> >
> > Signed-off-by: Andreas Rheinhardt
> > ---
> > libavformat/ttaenc.c | 15 +--
> > 1 file changed, 9 insertions(+), 6 deletions(-)
> >
> > diff --git a/libavformat/ttaenc.c b/libavformat/ttaenc.c
> > index 73c29ae936..84e3937141 100644
> > --- a/libavformat/ttaenc.c
> > +++ b/libavformat/ttaenc.c
> > @@ -122,13 +122,16 @@ static int tta_write_packet(AVFormatContext *s,
> AVPacket *pkt)
> > static void tta_queue_flush(AVFormatContext *s)
> > {
> > TTAMuxContext *tta = s->priv_data;
> > -AVPacket pkt;
> > -
> > -while (tta->queue) {
> > -ff_packet_list_get(&tta->queue, &tta->queue_end, &pkt);
> > -avio_write(s->pb, pkt.data, pkt.size);
> > -av_packet_unref(&pkt);
> > +AVPacketList *entry = tta->queue;
> > +
> > +while (entry) {
> > +AVPacketList *next = entry->next;
> > +avio_write(s->pb, entry->pkt.data, entry->pkt.size);
> > +av_packet_unref(&entry->pkt);
> > +av_free(entry);
> > +entry = next;
> > }
> > +tta->queue = tta->queue_end = NULL;
> > }
> >
> > static int tta_write_trailer(AVFormatContext *s)
> >
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avdevice/xcbgrab: Handle reply and error properly
On 2019-11-19 22:59:30 +0900, Kusanagi Kouichi wrote:
> Fix a NULL dereference and leaks.
>
> Signed-off-by: Kusanagi Kouichi
> ---
> libavdevice/xcbgrab.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/libavdevice/xcbgrab.c b/libavdevice/xcbgrab.c
> index b7e689343e..063fecf838 100644
> --- a/libavdevice/xcbgrab.c
> +++ b/libavdevice/xcbgrab.c
> @@ -168,6 +168,7 @@ static int xcbgrab_frame(AVFormatContext *s, AVPacket
> *pkt)
> "sequence:%u resource_id:%u minor_code:%u major_code:%u.\n",
> e->response_type, e->error_code,
> e->sequence, e->resource_id, e->minor_code, e->major_code);
> +free(e);
> return AVERROR(EACCES);
> }
>
> @@ -276,6 +277,7 @@ static int xcbgrab_frame_shm(AVFormatContext *s, AVPacket
> *pkt)
> e->response_type, e->error_code,
> e->sequence, e->resource_id, e->minor_code, e->major_code);
>
> +free(e);
> return AVERROR(EACCES);
> }
>
> @@ -537,6 +539,8 @@ static int create_stream(AVFormatContext *s)
>
> gc = xcb_get_geometry(c->conn, c->screen->root);
> geo = xcb_get_geometry_reply(c->conn, gc, NULL);
> +if (!geo)
> +return AVERROR_EXTERNAL;
>
> if (c->x + c->width > geo->width ||
> c->y + c->height > geo->height) {
> @@ -546,6 +550,7 @@ static int create_stream(AVFormatContext *s)
> c->width, c->height,
> c->x, c->y,
> geo->width, geo->height);
> +free(geo);
> return AVERROR(EINVAL);
> }
>
> --
> 2.24.0
>
ping
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avdevice/xcbgrab: Improve non-shm performance
On 2019-11-19 22:59:56 +0900, Kusanagi Kouichi wrote:
> Use AVBufferPool.
>
> before:
> $ ffmpeg -benchmark -f x11grab -video_size 1920x1200 -r 200 -t 3 -i +0,0 -f
> null -
> ...
> frame= 600 fps=102 q=-0.0 Lsize=N/A time=00:00:03.00 bitrate=N/A speed=0.51x
> video:314kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB
> muxing overhead: unknown
> bench: utime=1.551s stime=3.428s rtime=5.884s
> bench: maxrss=40132kB
>
> after:
> $ ffmpeg -benchmark -f x11grab -video_size 1920x1200 -r 200 -t 3 -i +0,0 -f
> null -
> ...
> frame= 600 fps=138 q=-0.0 Lsize=N/A time=00:00:03.00 bitrate=N/A speed=0.69x
> video:314kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB
> muxing overhead: unknown
> bench: utime=1.231s stime=2.407s rtime=4.349s
> bench: maxrss=40096kB
>
> Signed-off-by: Kusanagi Kouichi
> ---
> libavdevice/xcbgrab.c | 38 +++---
> 1 file changed, 31 insertions(+), 7 deletions(-)
>
> diff --git a/libavdevice/xcbgrab.c b/libavdevice/xcbgrab.c
> index b7e689343e..fde9c534cd 100644
> --- a/libavdevice/xcbgrab.c
> +++ b/libavdevice/xcbgrab.c
> @@ -42,6 +42,7 @@
> #include "libavutil/opt.h"
> #include "libavutil/parseutils.h"
> #include "libavutil/time.h"
> +#include "libavutil/buffer.h"
>
> #include "libavformat/avformat.h"
> #include "libavformat/internal.h"
> @@ -71,6 +72,8 @@ typedef struct XCBGrabContext {
> int region_border;
> int centered;
>
> +AVBufferPool *buf_pool;
> +
> const char *video_size;
> const char *framerate;
>
> @@ -146,6 +149,16 @@ static int xcbgrab_reposition(AVFormatContext *s,
> return 0;
> }
>
> +static AVBufferRef *xcbgrab_allocate_buffer(const int size)
> +{
> +AVPacket pkt;
> +
> +if (av_new_packet(&pkt, size))
> +return NULL;
> +
> +return pkt.buf;
> +}
> +
> static int xcbgrab_frame(AVFormatContext *s, AVPacket *pkt)
> {
> XCBGrabContext *c = s->priv_data;
> @@ -154,7 +167,7 @@ static int xcbgrab_frame(AVFormatContext *s, AVPacket
> *pkt)
> xcb_drawable_t drawable = c->screen->root;
> xcb_generic_error_t *e = NULL;
> uint8_t *data;
> -int length, ret;
> +int length;
>
> iq = xcb_get_image(c->conn, XCB_IMAGE_FORMAT_Z_PIXMAP, drawable,
> c->x, c->y, c->width, c->height, ~0);
> @@ -174,17 +187,21 @@ static int xcbgrab_frame(AVFormatContext *s, AVPacket
> *pkt)
> if (!img)
> return AVERROR(EAGAIN);
>
> +pkt->buf = av_buffer_pool_get(c->buf_pool);
> +if (!pkt->buf) {
> +free(img);
> +return AVERROR(ENOMEM);
> +}
> +
> data = xcb_get_image_data(img);
> length = xcb_get_image_data_length(img);
>
> -ret = av_new_packet(pkt, length);
> -
> -if (!ret)
> -memcpy(pkt->data, data, length);
> -
> +memcpy(pkt->buf->data, data, length);
> free(img);
> +pkt->data = pkt->buf->data;
> +pkt->size = pkt->buf->size;
>
> -return ret;
> +return 0;
> }
>
> static void wait_frame(AVFormatContext *s, AVPacket *pkt)
> @@ -442,6 +459,7 @@ static av_cold int xcbgrab_read_close(AVFormatContext *s)
> #endif
>
> xcb_disconnect(ctx->conn);
> +av_buffer_pool_uninit(&ctx->buf_pool);
>
> return 0;
> }
> @@ -665,6 +683,12 @@ static av_cold int xcbgrab_read_header(AVFormatContext
> *s)
> return ret;
> }
>
> +c->buf_pool = av_buffer_pool_init(c->frame_size,
> xcbgrab_allocate_buffer);
> +if (ret < 0) {
> +xcbgrab_read_close(s);
> +return AVERROR(ENOMEM);
> +}
> +
> #if CONFIG_LIBXCB_SHM
> if ((c->has_shm = check_shm(c->conn)))
> c->segment = xcb_generate_id(c->conn);
> --
> 2.24.0
>
ping
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH V1 1/2] lavf/rtmpproto: Don't unref uninitialized buffers
> 在 2019年12月3日，下午7:00，Jun Zhao 写道： > > From: Jun Zhao > > This happens if ffurl_open_whitelist fails and stream is unset. > > Signed-off-by: Jun Zhao > --- > libavformat/rtmpproto.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/libavformat/rtmpproto.c b/libavformat/rtmpproto.c > index 5274993..42aacbd 100644 > --- a/libavformat/rtmpproto.c > +++ b/libavformat/rtmpproto.c > @@ -,7 +,7 @@ static int rtmp_calc_swfhash(URLContext *s) > RTMPContext *rt = s->priv_data; > uint8_t *in_data = NULL, *out_data = NULL, *swfdata; BTW, swf_data = NULL too. > int64_t in_size; BTW in_size = 0. > -URLContext *stream; > +URLContext *stream = NULL; > char swfhash[32]; > int swfsize; BTW, swfsize = 0. > int ret = 0; > -- > 1.7.1 > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". Steven Thanks ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH V3 1/2] lavf/libsrt: add linger parameter to libsrt
On Tue, Dec 3, 2019 at 7:17 PM Gyan wrote:
>
>
> On 03-12-2019 04:27 pm, Jun Zhao wrote:
> > From: Jun Zhao
> >
> > add linger parameter to libsrt, it's setting the number of seconds
> > that the socket waits for unsent data when closing.
> >
> > Reviewed-by: Andriy Gelman
> > Signed-off-by: Jun Zhao
> > ---
> > doc/protocols.texi |5 +
> > libavformat/libsrt.c | 13 +
> > 2 files changed, 18 insertions(+), 0 deletions(-)
> >
> > diff --git a/doc/protocols.texi b/doc/protocols.texi
> > index 0e18a49..eab6242 100644
> > --- a/doc/protocols.texi
> > +++ b/doc/protocols.texi
> > @@ -1426,6 +1426,11 @@ the overhead transmission (retransmitted and
> control packets).
> > file: Set options as for non-live transmission. See @option{messageapi}
> > for further explanations
> >
> > +@item linger=@var{seconds}
> > +The number of seconds that the socket waits for unsent data when
> closing.
> > +Default is -1. -1 means auto (off with 0 seconds in live mode, on with
> 180
> > +seconds in file mode).
>
> Add range info.
>
> Gyan
>
> Will update the range info as comments, tks
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 1/2] avformat/utils: simplify the code and remove av_strncasecmp
On Tue, Dec 03, 2019 at 09:43:53AM +0100, Michael Niedermayer wrote:
> On Mon, Dec 02, 2019 at 12:51:05PM +0800, lance.lmw...@gmail.com wrote:
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavformat/utils.c | 5 ++---
> > 1 file changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/libavformat/utils.c b/libavformat/utils.c
> > index 8196442dd1..03a3705200 100644
> > --- a/libavformat/utils.c
> > +++ b/libavformat/utils.c
> > @@ -4854,11 +4854,10 @@ int ff_mkdir_p(const char *path)
> > return -1;
> > }
> >
> > -if (!av_strncasecmp(temp, "/", 1) || !av_strncasecmp(temp, "\\", 1)) {
> > +if (*temp == '/' || *temp == '\\')
> > pos++;
>
> > -} else if (!av_strncasecmp(temp, "./", 2) || !av_strncasecmp(temp,
> > ".\\", 2)) {
> > +else if (*temp == '.' && (*(temp+1) == '/' || *(temp+1) == '\\'))
>
> is this really simpler ? (compared to strncmp() for example) ?
> it looks more obfuscated
It's changed for patch#2, for the separator is defined as single
charactor. so it's more simple to compare with character.
>
> also not sure about the {} removial
Yes, it's unrelated cosmetics change, I'll keep it if have chance to update the
patchset.
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> No human being will ever know the Truth, for even if they happen to say it
> by chance, they would not even known they had done so. -- Xenophanes
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 1/3] avfilter/vf_elbg: Fix for the seed type
ping the patchset, thx.
On Fri, Nov 22, 2019 at 09:50:36AM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavfilter/vf_elbg.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/libavfilter/vf_elbg.c b/libavfilter/vf_elbg.c
> index b59da9ec85..5bccb5f58d 100644
> --- a/libavfilter/vf_elbg.c
> +++ b/libavfilter/vf_elbg.c
> @@ -36,7 +36,7 @@
> typedef struct ELBGContext {
> const AVClass *class;
> AVLFG lfg;
> -unsigned int lfg_seed;
> +int64_t lfg_seed;
> int max_steps_nb;
> int *codeword;
> int codeword_length;
> @@ -56,8 +56,8 @@ static const AVOption elbg_options[] = {
> { "l", "set codebook length", OFFSET(codebook_length),
> AV_OPT_TYPE_INT, { .i64 = 256 }, 1, INT_MAX, FLAGS },
> { "nb_steps", "set max number of steps used to compute the mapping",
> OFFSET(max_steps_nb), AV_OPT_TYPE_INT, { .i64 = 1 }, 1, INT_MAX, FLAGS },
> { "n","set max number of steps used to compute the mapping",
> OFFSET(max_steps_nb), AV_OPT_TYPE_INT, { .i64 = 1 }, 1, INT_MAX, FLAGS },
> -{ "seed", "set the random seed", OFFSET(lfg_seed), AV_OPT_TYPE_INT,
> {.i64 = -1}, -1, UINT32_MAX, FLAGS },
> -{ "s","set the random seed", OFFSET(lfg_seed), AV_OPT_TYPE_INT, {
> .i64 = -1 }, -1, UINT32_MAX, FLAGS },
> +{ "seed", "set the random seed", OFFSET(lfg_seed), AV_OPT_TYPE_INT64,
> {.i64 = -1}, -1, UINT32_MAX, FLAGS },
> +{ "s","set the random seed", OFFSET(lfg_seed), AV_OPT_TYPE_INT64, {
> .i64 = -1 }, -1, UINT32_MAX, FLAGS },
> { "pal8", "set the pal8 output", OFFSET(pal8), AV_OPT_TYPE_BOOL, { .i64
> = 0 }, 0, 1, FLAGS },
> { NULL }
> };
> --
> 2.21.0
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v1 1/2] fftools: add global option to dump filter graph to stderr
On Thu, Nov 21, 2019 at 01:32:58PM +0100, Carl Eugen Hoyos wrote:
> Am Do., 21. Nov. 2019 um 12:28 Uhr schrieb Limin Wang
> :
> >
> > On Thu, Nov 21, 2019 at 10:49:28AM +0100, Carl Eugen Hoyos wrote:
> > > Am Mi., 20. Nov. 2019 um 16:03 Uhr schrieb :
> > > >
> > > > From: Limin Wang
> > > >
> > > > It's useful for debugging filter graph purposes, now only lavfi can do
> > > > that.
> > > >
> > > > Signed-off-by: Limin Wang
> > > > ---
> > > > doc/ffmpeg.texi | 4
> > > > fftools/ffmpeg.h| 1 +
> > > > fftools/ffmpeg_filter.c | 7 +++
> > > > fftools/ffmpeg_opt.c| 3 +++
> > > > 4 files changed, 15 insertions(+)
> > > >
> > > > diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
> > > > index 92337d..7e55f67898 100644
> > > > --- a/doc/ffmpeg.texi
> > > > +++ b/doc/ffmpeg.texi
> > > > @@ -668,6 +668,10 @@ Defines how many threads are used to process a
> > > > filter pipeline. Each pipeline
> > > > will produce a thread pool with this many threads available for
> > > > parallel processing.
> > > > The default is the number of available CPUs.
> > > >
> > > > +@item -filter_dumpgraph (@emph{global})
> > > > +Dump filter graph to stderr. It is off by default, the option is
> > > > mostly useful
> > > > +for debugging filter graph purposes
> > > > +
> > > > @item -pre[:@var{stream_specifier}] @var{preset_name}
> > > > (@emph{output,per-stream})
> > > > Specify the preset for matching stream(s).
> > > >
> > > > diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
> > > > index 7b6f802082..b3133e7e99 100644
> > > > --- a/fftools/ffmpeg.h
> > > > +++ b/fftools/ffmpeg.h
> > > > @@ -608,6 +608,7 @@ extern float max_error_rate;
> > > > extern char *videotoolbox_pixfmt;
> > > >
> > > > extern int filter_nbthreads;
> > > > +extern int filter_dumpgraph;
> > > > extern int filter_complex_nbthreads;
> > > > extern int vstats_version;
> > > >
> > > > diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
> > > > index 72838de1e2..35ba3a38db 100644
> > > > --- a/fftools/ffmpeg_filter.c
> > > > +++ b/fftools/ffmpeg_filter.c
> > > > @@ -1109,6 +1109,13 @@ int configure_filtergraph(FilterGraph *fg)
> > > > if ((ret = avfilter_graph_config(fg->graph, NULL)) < 0)
> > > > goto fail;
> > > >
> > > > +if (filter_dumpgraph) {
> > > > +char *dump = avfilter_graph_dump(fg->graph, NULL);
> > > > +fputs(dump, stderr);
> > > > +fflush(stderr);
> > > > +av_free(dump);
> > > > +}
> > > > +
> > > > /* limit the lists of allowed formats to the ones selected, to
> > > > * make sure they stay the same if the filtergraph is reconfigured
> > > > later */
> > > > for (i = 0; i < fg->nb_outputs; i++) {
> > > > diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
> > > > index 71063cc443..44eb890e86 100644
> > > > --- a/fftools/ffmpeg_opt.c
> > > > +++ b/fftools/ffmpeg_opt.c
> > > > @@ -110,6 +110,7 @@ int frame_bits_per_raw_sample = 0;
> > > > float max_error_rate = 2.0/3;
> > > > int filter_nbthreads = 0;
> > > > int filter_complex_nbthreads = 0;
> > > > +int filter_dumpgraph = 0;
> > > > int vstats_version = 2;
> > > >
> > > >
> > > > @@ -3523,6 +3524,8 @@ const OptionDef options[] = {
> > > > "create a complex filtergraph", "graph_description" },
> > > > { "filter_complex_threads", HAS_ARG | OPT_INT, {
> > > > &filter_complex_nbthreads },
> > > > "number of threads for -filter_complex" },
> > > > +{ "filter_dumpgraph", OPT_BOOL, {
> > > > &filter_dumpgraph },
> > > > +"dump filter graph to stderr" },
> > >
> > > dump_filtergraph ?
> >
> > Carl, thanks for the feedback, I'm ok with your recomment name and will
> > update it if no further comments next time.
>
> Consider waiting for others' opinions, I am not a native speaker...
I have updated the patch for the option name, any other comments?
>
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avfilter/vf_showinfo: Fix erroneous results for mean and stdev with pixel bits >8
On Thu, Nov 28, 2019 at 11:51:13PM +0100, Michael Niedermayer wrote: > On Thu, Nov 28, 2019 at 10:34:41PM +0800, lance.lmw...@gmail.com wrote: > > From: Limin Wang > > > > The following is one of the testing results, you can observe the result of > > 16bit isn't correct. > > 1, yuv420p > > ./ffmpeg -f lavfi -i > > color=black:duration=1:r=1:size=1280x720,format=yuv420p,showinfo > > Master: > > mean:[16 128 128] stdev:[0.0 0.0 0.0] > > After applied the patch: > > mean:[16 128 128] stdev:[0.0 0.0 0.0] > > > > > 2, yuv420p10 > > ./ffmpeg -f lavfi -i > > color=black:duration=1:r=1:size=1280x720,format=yuv420p10,showinfo > > Master: > > mean:[32 1 1] stdev:[32.0 1.0 1.0] > > After applied the patch: > > mean:[64 512 512] stdev:[0.0 0.0 0.0] > > with >8bit, both little and big endian formats should be tested Michael, I have updated the patch and test with le and be formats on be and le system. Please review whether the test is complete. > > thx > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User > questions about the command line tools should be sent to the ffmpeg-user ML. > And questions about how to use libav* should be sent to the libav-user ML. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 2/2] avformat/utils: simplify the ff_mkdir_p with SEPARATOR
On Mon, Dec 02, 2019 at 04:25:14PM +0100, Hendrik Leppkes wrote:
> On Mon, Dec 2, 2019 at 3:36 PM Limin Wang wrote:
> >
> > On Mon, Dec 02, 2019 at 09:26:11AM +0100, Hendrik Leppkes wrote:
> > > On Mon, Dec 2, 2019 at 3:16 AM Limin Wang wrote:
> > > >
> > > > On Sun, Dec 01, 2019 at 05:33:16PM +0100, Hendrik Leppkes wrote:
> > > > > On Sun, Dec 1, 2019 at 3:08 PM wrote:
> > > > > >
> > > > > > From: Limin Wang
> > > > > >
> > > > > > Signed-off-by: Limin Wang
> > > > > > ---
> > > > > > libavformat/utils.c | 16 ++--
> > > > > > 1 file changed, 10 insertions(+), 6 deletions(-)
> > > > > >
> > > > > > diff --git a/libavformat/utils.c b/libavformat/utils.c
> > > > > > index 579e6d6..993e6d2 100644
> > > > > > --- a/libavformat/utils.c
> > > > > > +++ b/libavformat/utils.c
> > > > > > @@ -4843,12 +4843,17 @@ void av_url_split(char *proto, int
> > > > > > proto_size,
> > > > > > }
> > > > > > }
> > > > > >
> > > > > > +#if HAVE_DOS_PATHS
> > > > > > +#define SEPARATOR '\\'
> > > > > > +#else
> > > > > > +#define SEPARATOR '/'
> > > > > > +#endif
> > > > > > +
> > > > > > int ff_mkdir_p(const char *path)
> > > > > > {
> > > > > > int ret = 0;
> > > > > > char *temp = av_strdup(path);
> > > > > > char *pos = temp;
> > > > > > -char tmp_ch = '\0';
> > > > > >
> > > > > > if (!path || !temp) {
> > > > > > return -1;
> > > > > > @@ -4856,19 +4861,18 @@ int ff_mkdir_p(const char *path)
> > > > > >
> > > > > > if (*temp == '.')
> > > > > > pos++;
> > > > > > -if (*temp == '/' || *temp == '\\')
> > > > > > +if (*temp == SEPARATOR)
> > > > > > pos++;
> > > > > >
> > > > > > for ( ; *pos != '\0'; ++pos) {
> > > > > > -if (*pos == '/' || *pos == '\\') {
> > > > > > -tmp_ch = *pos;
> > > > > > +if (*pos == SEPARATOR) {
> > > > > > *pos = '\0';
> > > > > > ret = mkdir(temp, 0755);
> > > > > > -*pos = tmp_ch;
> > > > > > +*pos = SEPARATOR;
> > > > > > }
> > > > > > }
> > > > > >
> > > > > > -if ((*(pos - 1) != '/') || (*(pos - 1) != '\\')) {
> > > > > > +if (*(pos - 1) != SEPARATOR) {
> > > > > > ret = mkdir(temp, 0755);
> > > > > > }
> > > > >
> > > > > I think there is some value to be able to specify a path with both
> > > > > kinds of slashes. For example, most of everything else on Windows will
> > > > > accept normal slashes, in addition to the default backslash.
> > > > Hendrik, I haven't got your point yet, can you make it clear so that I
> > > > can change the patch for your case.
> > > >
> > > > For example, on Linux, if the path is:
> > > > ~/Movies/hl\\s/vs%v/manifest.m3u8
> > > >
> > > > The current code will mkdir below path:
> > > > path: /Users
> > > > path: /Users/lmwang
> > > > path: /Users/lmwang/Movies
> > > > path: /Users/lmwang/Movies/hl >>> unexpected
> > > > path: /Users/lmwang/Movies/hl\s
> > > > path: /Users/lmwang/Movies/hl\s/vs0
> > > >
> > > > You can see /Users/lmwang/Movies/hl directory isn't expected directory
> > > > which is created.
> > > >
> > > > After applied the patch, it'll not create it anymore.
> > > >
> > >
> > > But if I'm on Windows and I specify a path with normal slashes (where
> > > SEPARATOR is backslash), I would absolutely expect it to create it
> > > like that. Which it does right now.
> >
> > Now I haven't windows system in hand, so I can't test your condition.
> > For windows, the old code will consider normal slashes(/) as path separator
> > instead of special charactor. Maybe I have misunderstanding for that.
> >
>
> Yes, it does, and it should continue to do so, because everything else
> on Windows does as well. Both slash and backslash are valid path
> seperators.
Sorry, I don't know slash is valid path seperator on windows. I'll try
to cross build a window version to test how to support this case.
>
> - Hendrik
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH V3 2/2] lavf/libsrt: enable other encryption parameters
On Tue, Dec 03, 2019 at 06:57:27PM +0800, Jun Zhao wrote:
> From: Jun Zhao
>
> Enable the SRTO_ENFORCEDENCRYPTION/SRTO_KMREFRESHRATE/
> SRTO_KMPREANNOUNCE for srt encryption control.
>
> Signed-off-by: Jun Zhao
> ---
> doc/protocols.texi | 16
> libavformat/libsrt.c | 18 ++
> 2 files changed, 34 insertions(+), 0 deletions(-)
>
> diff --git a/doc/protocols.texi b/doc/protocols.texi
> index eab6242..04f6e8b 100644
> --- a/doc/protocols.texi
> +++ b/doc/protocols.texi
> @@ -1282,6 +1282,22 @@ only if @option{pbkeylen} is non-zero. It is used on
> the receiver only if the received data is encrypted.
> The configured passphrase cannot be recovered (write-only).
>
> +@item enforced_encryption=@var{1|0}
> +If true, both connection parties must have the same password
> +set (including empty, that is, with no encryption). If the
> +password doesn't match or only one side is unencrypted,
> +the connection is rejected. Default is true.
> +
> +@item kmrefreshrate=@var{n}
> +The number of packets to be transmitted after which the
> +encryption key is switched to a new key.
> +
> +@item kmpreannounce=@var{n}
> +The interval between when a new encryption key is sent and
> +when switchover occurs. This value also applies to the
> +subsequent interval between when switchover occurs and
> +when the old encryption key is decommissioned.
> +
> @item payload_size=@var{bytes}
> Sets the maximum declared size of a packet transferred
> during the single call to the sending function in Live
> diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c
> index 0a748a1..06f2c02 100644
> --- a/libavformat/libsrt.c
> +++ b/libavformat/libsrt.c
> @@ -62,6 +62,9 @@ typedef struct SRTContext {
> int64_t maxbw;
> int pbkeylen;
> char *passphrase;
> +int enforced_encryption;
> +int kmrefreshrate;
> +int kmpreannounce;
> int mss;
> int ffs;
> int ipttl;
> @@ -102,6 +105,9 @@ static const AVOption libsrt_options[] = {
> { "maxbw", "Maximum bandwidth (bytes per second) that the
> connection can use", OFFSET(maxbw),AV_OPT_TYPE_INT64,{
> .i64 = -1 }, -1, INT64_MAX, .flags = D|E },
> { "pbkeylen", "Crypto key len in bytes {16,24,32} Default: 16
> (128-bit)", OFFSET(pbkeylen), AV_OPT_TYPE_INT, {
> .i64 = -1 }, -1, 32,.flags = D|E },
> { "passphrase", "Crypto PBKDF2 Passphrase size[0,10..64] 0:disable
> crypto", OFFSET(passphrase), AV_OPT_TYPE_STRING, { .str =
> NULL }, .flags = D|E },
> +{ "enforced_encryption", "Enforces that both connection parties
> have the same passphrase set ", OFFSET(enforced_encryption),
> AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 1, .flags = D|E },
is this intended to be INT and not AV_OPT_TYPE_BOOL ?
> +{ "kmrefreshrate", "The number of packets to be transmitted
> after which the encryption key is switched to a new key",
> OFFSET(kmrefreshrate), AV_OPT_TYPE_INT, { .i64 = -1 }, -1,
> INT_MAX, .flags = D|E },
> +{ "kmpreannounce", "The interval between when a new encryption
> key is sent and when switchover occurs", OFFSET(kmpreannounce),
> AV_OPT_TYPE_INT, { .i64 = -1 }, -1, INT_MAX, .flags = D|E },
> { "mss","The Maximum Segment Size",
>OFFSET(mss), AV_OPT_TYPE_INT, { .i64 =
> -1 }, -1, 1500, .flags = D|E },
> { "ffs","Flight flag size (window size) (in bytes)",
>OFFSET(ffs), AV_OPT_TYPE_INT, { .i64 =
> -1 }, -1, INT_MAX, .flags = D|E },
> { "ipttl", "IP Time To Live",
>OFFSET(ipttl),AV_OPT_TYPE_INT, { .i64 =
> -1 }, -1, 255, .flags = D|E },
The added options are alot more randomly formated than the surrounding ones
otherwise the patch should be good
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 5/6] tools/target_dec_fuzzer: Support fuzzing error detection
On Sat, Nov 30, 2019 at 12:59:20AM +0100, Michael Niedermayer wrote: > This should increase coverage > > Signed-off-by: Michael Niedermayer > --- > tools/target_dec_fuzzer.c | 6 ++ > 1 file changed, 6 insertions(+) will apply this and the other coverage increasing patch so we get increased coverage [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Take away the freedom of one citizen and you will be jailed, take away the freedom of all citizens and you will be congratulated by your peers in Parliament. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avfilter/buffersrc: deprecate sws_param option
quinkbl...@foxmail.com (12019-12-03): > From: Zhao Zhili > > --- > doc/filters.texi| 4 +--- > libavfilter/buffersrc.c | 14 -- > libavfilter/version.h | 5 - > 3 files changed, 17 insertions(+), 6 deletions(-) LGTM. I will apply in a little time. Thanks. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v3] avformat/matroskaenc: Use random TrackUID
Up until now, the TrackUID of a Matroska track which is supposed to be
random was not random at all: It always coincided with the TrackNumber
which is usually the 1-based index of the corresponding stream in the
array of AVStreams. This has been changed: It is now set via an AVLFG
if AVFMT_FLAG_BITEXACT is not set. Otherwise it is set like it is set
now (the only change happens if an explicit track number has been
chosen via dash_track_number, because the system used in the normal
situation is now used, too). In particular, no FATE tests need to be
updated.
This also fixes a bug in case the dash_track_number option was used:
In this case the TrackUID was set to the track number, but the tags were
written with a TagTrackUID simply based upon the index, so that the tags
didn't apply to the track they ought to apply to.
Signed-off-by: Andreas Rheinhardt
---
I have updated the patchset to rely on the AVLFG to provide sufficiently
many distinct values, as you said. I could add a check and a for if we still
have a collision after (say) 1000 tries in order to avoid the
potentially infinite loop.
libavformat/matroskaenc.c | 52 +--
1 file changed, 44 insertions(+), 8 deletions(-)
diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index 41c3f1a985..b2f28304c8 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -94,6 +94,7 @@ typedef struct mkv_cues {
typedef struct mkv_track {
int write_dts;
int has_cue;
+uint64_tuid;
int sample_rate;
int64_t sample_rate_offset;
int64_t last_timestamp;
@@ -1199,8 +1200,7 @@ static int mkv_write_track(AVFormatContext *s,
MatroskaMuxContext *mkv,
track = start_ebml_master(pb, MATROSKA_ID_TRACKENTRY, 0);
put_ebml_uint (pb, MATROSKA_ID_TRACKNUMBER,
mkv->is_dash ? mkv->dash_track_number : i + 1);
-put_ebml_uint (pb, MATROSKA_ID_TRACKUID,
- mkv->is_dash ? mkv->dash_track_number : i + 1);
+put_ebml_uint (pb, MATROSKA_ID_TRACKUID, mkv->tracks[i].uid);
put_ebml_uint (pb, MATROSKA_ID_TRACKFLAGLACING , 0);// no lacing (yet)
if ((tag = av_dict_get(st->metadata, "title", NULL, 0)))
@@ -1651,7 +1651,8 @@ static int mkv_write_tags(AVFormatContext *s)
if (!mkv_check_tag(st->metadata, MATROSKA_ID_TAGTARGETS_TRACKUID))
continue;
-ret = mkv_write_tag(s, st->metadata, MATROSKA_ID_TAGTARGETS_TRACKUID,
i + 1);
+ret = mkv_write_tag(s, st->metadata, MATROSKA_ID_TAGTARGETS_TRACKUID,
+mkv->tracks[i].uid);
if (ret < 0) return ret;
}
@@ -1659,13 +1660,15 @@ static int mkv_write_tags(AVFormatContext *s)
for (i = 0; i < s->nb_streams; i++) {
AVIOContext *pb;
AVStream *st = s->streams[i];
+mkv_track *track = &mkv->tracks[i];
ebml_master tag_target;
ebml_master tag;
if (st->codecpar->codec_type == AVMEDIA_TYPE_ATTACHMENT)
continue;
-mkv_write_tag_targets(s, MATROSKA_ID_TAGTARGETS_TRACKUID, i + 1,
&tag_target);
+mkv_write_tag_targets(s, MATROSKA_ID_TAGTARGETS_TRACKUID,
+ track->uid, &tag_target);
pb = mkv->tags_bc;
tag = start_ebml_master(pb, MATROSKA_ID_SIMPLETAG, 0);
@@ -1865,10 +1868,6 @@ static int mkv_write_header(AVFormatContext *s)
version = 4;
}
-mkv->tracks = av_mallocz_array(s->nb_streams, sizeof(*mkv->tracks));
-if (!mkv->tracks) {
-return AVERROR(ENOMEM);
-}
ebml_header = start_ebml_master(pb, EBML_ID_HEADER, MAX_EBML_HEADER_SIZE);
put_ebml_uint (pb, EBML_ID_EBMLVERSION , 1);
put_ebml_uint (pb, EBML_ID_EBMLREADVERSION , 1);
@@ -2670,8 +2669,29 @@ static int webm_query_codec(enum AVCodecID codec_id, int
std_compliance)
return 0;
}
+static uint64_t mkv_get_uid(const mkv_track *tracks, int i, AVLFG *c)
+{
+uint64_t uid;
+
+while (1) {
+int k;
+uid = (uint64_t)av_lfg_get(c) << 32;
+uid |= av_lfg_get(c);
+if (!uid)
+continue;
+for (k = 0; k < i; k++) {
+if (tracks[k].uid == uid)
+break;
+}
+if (k == i)
+return uid;
+}
+}
+
static int mkv_init(struct AVFormatContext *s)
{
+MatroskaMuxContext *mkv = s->priv_data;
+AVLFG c;
int i;
if (s->nb_streams > MAX_TRACKS) {
@@ -2700,7 +2720,23 @@ static int mkv_init(struct AVFormatContext *s)
s->internal->avoid_negative_ts_use_pts = 1;
}
+mkv->tracks = av_mallocz_array(s->nb_streams, sizeof(*mkv->tracks));
+if (!mkv->tracks) {
+return AVERROR(ENOMEM);
+}
+
+if (!(s->flags & AVFMT_FLAG_BITEXACT))
+av_lfg_init(&c, av_get_random_seed());
+
for (i = 0; i < s->nb_streams; i++) {
[FFmpeg-devel] Fwd: [OpenMedia] CfP: Open Media devront
Dear FFmpeg developers, please see call for papers for FOSDEM 2020. Kieran -- Forwarded message - From: Christophe Massiot Date: Sun, 13 Oct 2019 at 16:34 Subject: [OpenMedia] CfP: Open Media devront To: FOSDEM , Open Media devroom < open-media-devr...@lists.fosdem.org> Hi all, The Open Media devroom will again be organised at FOSDEM 2020, and we are looking for propositions of talks and panels. FOSDEM is one of the largest (8,000+ hackers!) gatherings of Free and Open Source Software contributors in the world and happens each February in Brussels (Belgium, Europe). This year, the Open Media devroom will take place on: Sunday, February 2nd, 2020 # About the Open Media devroom The Open Media room will focus on all Free & Open Source media projects, including software and hardware, spanning from building audio & video applications, through standards, formats, codecs, video analytics and search to Web video, IPTV, broadcasting and radio practices and much more. If you're interested in video, image or audio technologies, and the breadth of available open source technologies and communities for media - the Open Media room is for you! For more information about the previous year sessions: https://archive.fosdem.org/2019/schedule/track/open_media/ # CFP Guidelines The deadline for submission is: Monday December 2nd, 2019 * To submit your proposal, visit: https://penta.fosdem.org/submission/FOSDEM20 * You will need to create an account (or preferably use your account from previous years) and then go to "create event”, and add the details of your presentation. * IMPORTANT: Please make sure to select ”Open Media devroom” track for your submission. * Your submission must include the following information - The title and subtitle of your talk (please be descriptive). - A short single paragraph detailing what the talk will discuss, and why attendees should attend it. - A longer description if you have more details to share. - Links to related material/websites/blogs etc. - A biography of yourself. - If you have a complicated schedule (plane to catch, other talk…) or need an invitation for a visa, please tell us in the submission notes and we will try to accommodate. * You can submit a session of one of the following formats: - lightning talk (10 minutes incl. questions), - regular talk (25 minutes incl. questions), - workshop (40 minutes or more) * Selected talks will be notified by December 15th 2019. * All sessions will be recorded and be made available under CC-BY licence by FOSDEM at https://video.fosdem.org/ . # Community The official communication channel is the Open Media devroom mailing-list. Join the list at: https://lists.fosdem.org/listinfo/open-media-devroom And please don't hesitate to contact us for more information! Christophe, Ben, Frans and Kieran, On behalf of the Open Media devroom. ___ open-media-devroom mailing list open-media-devr...@lists.fosdem.org https://lists.fosdem.org/listinfo/open-media-devroom ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/8] avformat/matroskadec: Check before allocations
That way one doesn't have to free later. In this case (concerning TTA
extradata), this also fixes a memleak when the output samplerate is
invalid.
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroskadec.c | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index bd6f08575b..3ce1d399e9 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -2545,30 +2545,29 @@ static int matroska_parse_tracks(AVFormatContext *s)
memcpy(&extradata[12], track->codec_priv.data,
track->codec_priv.size);
} else if (codec_id == AV_CODEC_ID_TTA) {
-extradata_size = 30;
-extradata = av_mallocz(extradata_size +
AV_INPUT_BUFFER_PADDING_SIZE);
-if (!extradata)
-return AVERROR(ENOMEM);
-ffio_init_context(&b, extradata, extradata_size, 1,
- NULL, NULL, NULL, NULL);
-avio_write(&b, "TTA1", 4);
-avio_wl16(&b, 1);
if (track->audio.channels > UINT16_MAX ||
track->audio.bitdepth > UINT16_MAX) {
av_log(matroska->ctx, AV_LOG_WARNING,
"Too large audio channel number %"PRIu64
" or bitdepth %"PRIu64". Skipping track.\n",
track->audio.channels, track->audio.bitdepth);
-av_freep(&extradata);
if (matroska->ctx->error_recognition & AV_EF_EXPLODE)
return AVERROR_INVALIDDATA;
else
continue;
}
-avio_wl16(&b, track->audio.channels);
-avio_wl16(&b, track->audio.bitdepth);
if (track->audio.out_samplerate < 0 || track->audio.out_samplerate
> INT_MAX)
return AVERROR_INVALIDDATA;
+extradata_size = 30;
+extradata = av_mallocz(extradata_size +
AV_INPUT_BUFFER_PADDING_SIZE);
+if (!extradata)
+return AVERROR(ENOMEM);
+ffio_init_context(&b, extradata, extradata_size, 1,
+ NULL, NULL, NULL, NULL);
+avio_write(&b, "TTA1", 4);
+avio_wl16(&b, 1);
+avio_wl16(&b, track->audio.channels);
+avio_wl16(&b, track->audio.bitdepth);
avio_wl32(&b, track->audio.out_samplerate);
avio_wl32(&b, av_rescale((matroska->duration *
matroska->time_scale),
track->audio.out_samplerate,
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/8] avformat/matroskadec, avcodec/tta: Set extradata_size to 22
Up until c4e0e314, the seek table has been included in the tta extradata, so that the size of said extradata was 22 (the size of a TTA1 header) + 4 * number of frames. The decoder rejected anything below a size of 30 and so the Matroska demuxer exported 30 byte long extradata, of which only 18 were set (it ignores a CRC-32 and simply leaves it at 0). But this is unnecessary since said commit, so reduce the size to 22. Furthermore, replace 30 by 22 in a comment about the extradata size in libavcodec/tta.c. Signed-off-by: Andreas Rheinhardt --- libavcodec/tta.c | 2 +- libavformat/matroskadec.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/libavcodec/tta.c b/libavcodec/tta.c index 304f3a81df..3fbee06987 100644 --- a/libavcodec/tta.c +++ b/libavcodec/tta.c @@ -129,7 +129,7 @@ static av_cold int tta_decode_init(AVCodecContext * avctx) s->avctx = avctx; -// 30bytes includes TTA1 header +// 22 bytes for a TTA1 header if (avctx->extradata_size < 22) return AVERROR_INVALIDDATA; diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c index 3ce1d399e9..d50211bf4f 100644 --- a/libavformat/matroskadec.c +++ b/libavformat/matroskadec.c @@ -2558,7 +2558,7 @@ static int matroska_parse_tracks(AVFormatContext *s) } if (track->audio.out_samplerate < 0 || track->audio.out_samplerate > INT_MAX) return AVERROR_INVALIDDATA; -extradata_size = 30; +extradata_size = 22; extradata = av_mallocz(extradata_size + AV_INPUT_BUFFER_PADDING_SIZE); if (!extradata) return AVERROR(ENOMEM); -- 2.20.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/8] avformat/matroskadec: Use bytestream API instead of AVIOContext
It avoids the overhead of function calls.
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroskadec.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index d50211bf4f..32bd6b8446 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -2545,6 +2545,7 @@ static int matroska_parse_tracks(AVFormatContext *s)
memcpy(&extradata[12], track->codec_priv.data,
track->codec_priv.size);
} else if (codec_id == AV_CODEC_ID_TTA) {
+uint8_t *ptr;
if (track->audio.channels > UINT16_MAX ||
track->audio.bitdepth > UINT16_MAX) {
av_log(matroska->ctx, AV_LOG_WARNING,
@@ -2562,16 +2563,15 @@ static int matroska_parse_tracks(AVFormatContext *s)
extradata = av_mallocz(extradata_size +
AV_INPUT_BUFFER_PADDING_SIZE);
if (!extradata)
return AVERROR(ENOMEM);
-ffio_init_context(&b, extradata, extradata_size, 1,
- NULL, NULL, NULL, NULL);
-avio_write(&b, "TTA1", 4);
-avio_wl16(&b, 1);
-avio_wl16(&b, track->audio.channels);
-avio_wl16(&b, track->audio.bitdepth);
-avio_wl32(&b, track->audio.out_samplerate);
-avio_wl32(&b, av_rescale((matroska->duration *
matroska->time_scale),
- track->audio.out_samplerate,
- AV_TIME_BASE * 1000));
+ptr = extradata;
+bytestream_put_be32(&ptr, AV_RB32("TTA1"));
+bytestream_put_le16(&ptr, 1);
+bytestream_put_le16(&ptr, track->audio.channels);
+bytestream_put_le16(&ptr, track->audio.bitdepth);
+bytestream_put_le32(&ptr, track->audio.out_samplerate);
+bytestream_put_le32(&ptr, av_rescale(matroska->duration *
matroska->time_scale,
+ track->audio.out_samplerate,
+ AV_TIME_BASE * 1000));
} else if (codec_id == AV_CODEC_ID_RV10 ||
codec_id == AV_CODEC_ID_RV20 ||
codec_id == AV_CODEC_ID_RV30 ||
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 4/8] avformat/matroskadec: Avoid allocating array for lace sizes
The maximal number of frames in a lace can be 256; hence one has a not
excessive upper bound on the size of an array that can hold the sizes of
all the frames in a lace. Yet up until now, said array has been
dynamically allocated. This has been changed.
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroskadec.c | 32 ++--
1 file changed, 10 insertions(+), 22 deletions(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 32bd6b8446..2f289a90b3 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -2990,19 +2990,14 @@ static void matroska_clear_queue(MatroskaDemuxContext
*matroska)
static int matroska_parse_laces(MatroskaDemuxContext *matroska, uint8_t **buf,
int *buf_size, int type,
-uint32_t **lace_buf, int *laces)
+uint32_t lace_size[256], int *laces)
{
int res = 0, n, size = *buf_size;
uint8_t *data = *buf;
-uint32_t *lace_size;
if (!type) {
*laces= 1;
-*lace_buf = av_malloc(sizeof(**lace_buf));
-if (!*lace_buf)
-return AVERROR(ENOMEM);
-
-*lace_buf[0] = size;
+lace_size[0] = size;
return 0;
}
@@ -3010,9 +3005,6 @@ static int matroska_parse_laces(MatroskaDemuxContext
*matroska, uint8_t **buf,
*laces= *data + 1;
data += 1;
size -= 1;
-lace_size = av_malloc_array(*laces, sizeof(*lace_size));
-if (!lace_size)
-return AVERROR(ENOMEM);
switch (type) {
case 0x1: /* Xiph lacing */
@@ -3093,7 +3085,6 @@ static int matroska_parse_laces(MatroskaDemuxContext
*matroska, uint8_t **buf,
}
*buf = data;
-*lace_buf = lace_size;
*buf_size = size;
return res;
@@ -3531,7 +3522,7 @@ static int matroska_parse_block(MatroskaDemuxContext
*matroska, AVBufferRef *buf
int res = 0;
AVStream *st;
int16_t block_time;
-uint32_t *lace_size = NULL;
+uint32_t lace_size[256];
int n, flags, laces = 0;
uint64_t num;
int trust_default_duration = 1;
@@ -3590,10 +3581,9 @@ static int matroska_parse_block(MatroskaDemuxContext
*matroska, AVBufferRef *buf
}
res = matroska_parse_laces(matroska, &data, &size, (flags & 0x06) >> 1,
- &lace_size, &laces);
-
-if (res)
-goto end;
+ lace_size, &laces);
+if (res < 0)
+return res;
if (track->audio.samplerate == 8000) {
// If this is needed for more codecs, then add them here
@@ -3627,7 +3617,7 @@ static int matroska_parse_block(MatroskaDemuxContext
*matroska, AVBufferRef *buf
lace_size[n],
timecode, pos);
if (res)
-goto end;
+return res;
} else if (st->codecpar->codec_id == AV_CODEC_ID_WEBVTT) {
res = matroska_parse_webvtt(matroska, track, st,
@@ -3635,7 +3625,7 @@ static int matroska_parse_block(MatroskaDemuxContext
*matroska, AVBufferRef *buf
timecode, lace_duration,
pos);
if (res)
-goto end;
+return res;
} else {
res = matroska_parse_frame(matroska, track, st, buf, data,
lace_size[n],
timecode, lace_duration, pos,
@@ -3643,7 +3633,7 @@ static int matroska_parse_block(MatroskaDemuxContext
*matroska, AVBufferRef *buf
additional, additional_id,
additional_size,
discard_padding);
if (res)
-goto end;
+return res;
}
if (timecode != AV_NOPTS_VALUE)
@@ -3652,9 +3642,7 @@ static int matroska_parse_block(MatroskaDemuxContext
*matroska, AVBufferRef *buf
size -= lace_size[n];
}
-end:
-av_free(lace_size);
-return res;
+return 0;
}
static int matroska_parse_cluster(MatroskaDemuxContext *matroska)
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 6/8] avformat/matroskadec: Remove unnecessary check
870e7552 introduced validating the lace sizes when they are parsed and
removed the old check; yet when merging this libav commit in 6902c3ac,
the old check for whether the frame extends beyond the frame has been kept.
It is unnecessary and has been removed.
Signed-off-by: Andreas Rheinhardt
---
Same as https://ffmpeg.org/pipermail/ffmpeg-devel/2019-August/248369.html
libavformat/matroskadec.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 88c43ee0c1..595d9553a2 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -2989,10 +2989,10 @@ static void matroska_clear_queue(MatroskaDemuxContext
*matroska)
}
static int matroska_parse_laces(MatroskaDemuxContext *matroska, uint8_t **buf,
-int *buf_size, int type,
+int size, int type,
uint32_t lace_size[256], int *laces)
{
-int n, size = *buf_size;
+int n;
uint8_t *data = *buf;
if (!type) {
@@ -3079,7 +3079,6 @@ static int matroska_parse_laces(MatroskaDemuxContext
*matroska, uint8_t **buf,
}
*buf = data;
-*buf_size = size;
return 0;
}
@@ -3574,7 +3573,7 @@ static int matroska_parse_block(MatroskaDemuxContext
*matroska, AVBufferRef *buf
}
}
-res = matroska_parse_laces(matroska, &data, &size, (flags & 0x06) >> 1,
+res = matroska_parse_laces(matroska, &data, size, (flags & 0x06) >> 1,
lace_size, &laces);
if (res < 0)
return res;
@@ -3597,11 +3596,6 @@ static int matroska_parse_block(MatroskaDemuxContext
*matroska, AVBufferRef *buf
for (n = 0; n < laces; n++) {
int64_t lace_duration = block_duration*(n+1) / laces -
block_duration*n / laces;
-if (lace_size[n] > size) {
-av_log(matroska->ctx, AV_LOG_ERROR, "Invalid packet size\n");
-break;
-}
-
if ((st->codecpar->codec_id == AV_CODEC_ID_RA_288 ||
st->codecpar->codec_id == AV_CODEC_ID_COOK ||
st->codecpar->codec_id == AV_CODEC_ID_SIPR ||
@@ -3633,7 +3627,6 @@ static int matroska_parse_block(MatroskaDemuxContext
*matroska, AVBufferRef *buf
if (timecode != AV_NOPTS_VALUE)
timecode = lace_duration ? timecode + lace_duration :
AV_NOPTS_VALUE;
data += lace_size[n];
-size -= lace_size[n];
}
return 0;
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 5/8] avformat/matroskadec: Simplify control flow of parsing laces
Up until now, when an error happened in one of the inner loops in
matroska_parse_laces, a variable designated for the return value has
been set to an error value and break has been used to exit the
current loop/case. This was done so that the end of matroska_parse_laces
is reached, because said function allocated memory which is later used
and freed in the calling function and passed at the end of
matroska_parse_laces.
But given that there is no allocation any more, one can now return
immediately. And this commit does this.
Signed-off-by: Andreas Rheinhardt
---
Supersedes https://ffmpeg.org/pipermail/ffmpeg-devel/2019-August/248368.html
libavformat/matroskadec.c | 26 ++
1 file changed, 10 insertions(+), 16 deletions(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 2f289a90b3..88c43ee0c1 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -2992,7 +2992,7 @@ static int matroska_parse_laces(MatroskaDemuxContext
*matroska, uint8_t **buf,
int *buf_size, int type,
uint32_t lace_size[256], int *laces)
{
-int res = 0, n, size = *buf_size;
+int n, size = *buf_size;
uint8_t *data = *buf;
if (!type) {
@@ -3011,13 +3011,12 @@ static int matroska_parse_laces(MatroskaDemuxContext
*matroska, uint8_t **buf,
{
uint8_t temp;
uint32_t total = 0;
-for (n = 0; res == 0 && n < *laces - 1; n++) {
+for (n = 0; n < *laces - 1; n++) {
lace_size[n] = 0;
while (1) {
if (size <= total) {
-res = AVERROR_INVALIDDATA;
-break;
+return AVERROR_INVALIDDATA;
}
temp = *data;
total+= temp;
@@ -3029,8 +3028,7 @@ static int matroska_parse_laces(MatroskaDemuxContext
*matroska, uint8_t **buf,
}
}
if (size <= total) {
-res = AVERROR_INVALIDDATA;
-break;
+return AVERROR_INVALIDDATA;
}
lace_size[n] = size - total;
@@ -3039,8 +3037,7 @@ static int matroska_parse_laces(MatroskaDemuxContext
*matroska, uint8_t **buf,
case 0x2: /* fixed-size lacing */
if (size % (*laces)) {
-res = AVERROR_INVALIDDATA;
-break;
+return AVERROR_INVALIDDATA;
}
for (n = 0; n < *laces; n++)
lace_size[n] = size / *laces;
@@ -3054,21 +3051,19 @@ static int matroska_parse_laces(MatroskaDemuxContext
*matroska, uint8_t **buf,
if (n < 0 || num > INT_MAX) {
av_log(matroska->ctx, AV_LOG_INFO,
"EBML block data error\n");
-res = n<0 ? n : AVERROR_INVALIDDATA;
-break;
+return n < 0 ? n : AVERROR_INVALIDDATA;
}
data += n;
size -= n;
total = lace_size[0] = num;
-for (n = 1; res == 0 && n < *laces - 1; n++) {
+for (n = 1; n < *laces - 1; n++) {
int64_t snum;
int r;
r = matroska_ebmlnum_sint(matroska, data, size, &snum);
if (r < 0 || lace_size[n - 1] + snum > (uint64_t)INT_MAX) {
av_log(matroska->ctx, AV_LOG_INFO,
"EBML block data error\n");
-res = r<0 ? r : AVERROR_INVALIDDATA;
-break;
+return r < 0 ? r : AVERROR_INVALIDDATA;
}
data+= r;
size-= r;
@@ -3076,8 +3071,7 @@ static int matroska_parse_laces(MatroskaDemuxContext
*matroska, uint8_t **buf,
total += lace_size[n];
}
if (size <= total) {
-res = AVERROR_INVALIDDATA;
-break;
+return AVERROR_INVALIDDATA;
}
lace_size[*laces - 1] = size - total;
break;
@@ -3087,7 +3081,7 @@ static int matroska_parse_laces(MatroskaDemuxContext
*matroska, uint8_t **buf,
*buf = data;
*buf_size = size;
-return res;
+return 0;
}
static int matroska_parse_rm_audio(MatroskaDemuxContext *matroska,
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 7/8] avformat/matroskadec: Improve frame size parsing error messages
When parsing the sizes of the frames in a lace fails, sometimes no
error message was raised (e.g. when using xiph or fixed-size lacing).
Only EBML lacing generated error messages (which were wrongly declared
as AV_LOG_INFO), but even here not all errors resulted in an error
message. So add a generic error message to catch them all.
Moreover, if parsing one of the EBML numbers fails, ebml_read_num already
emits its own error messages, so that all that is needed is a generic error
message to indicate that this happened during parsing the sizes of the
frames in a block; in other words, the error messages specific to
parsing EBML lace numbers can be and have been removed.
Signed-off-by: Andreas Rheinhardt
---
Supersedes https://ffmpeg.org/pipermail/ffmpeg-devel/2019-August/248376.html
libavformat/matroskadec.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 595d9553a2..6c81d1c4c8 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -3048,11 +3048,10 @@ static int matroska_parse_laces(MatroskaDemuxContext
*matroska, uint8_t **buf,
uint64_t num;
uint64_t total;
n = matroska_ebmlnum_uint(matroska, data, size, &num);
-if (n < 0 || num > INT_MAX) {
-av_log(matroska->ctx, AV_LOG_INFO,
- "EBML block data error\n");
-return n < 0 ? n : AVERROR_INVALIDDATA;
-}
+if (n < 0)
+return n;
+if (num > INT_MAX)
+return AVERROR_INVALIDDATA;
data += n;
size -= n;
total = lace_size[0] = num;
@@ -3060,11 +3059,10 @@ static int matroska_parse_laces(MatroskaDemuxContext
*matroska, uint8_t **buf,
int64_t snum;
int r;
r = matroska_ebmlnum_sint(matroska, data, size, &snum);
-if (r < 0 || lace_size[n - 1] + snum > (uint64_t)INT_MAX) {
-av_log(matroska->ctx, AV_LOG_INFO,
- "EBML block data error\n");
-return r < 0 ? r : AVERROR_INVALIDDATA;
-}
+if (r < 0)
+return r;
+if (lace_size[n - 1] + snum > (uint64_t)INT_MAX)
+return AVERROR_INVALIDDATA;
data+= r;
size-= r;
lace_size[n] = lace_size[n - 1] + snum;
@@ -3575,8 +3573,10 @@ static int matroska_parse_block(MatroskaDemuxContext
*matroska, AVBufferRef *buf
res = matroska_parse_laces(matroska, &data, size, (flags & 0x06) >> 1,
lace_size, &laces);
-if (res < 0)
+if (res < 0) {
+av_log(matroska->ctx, AV_LOG_ERROR, "Error parsing frame sizes.\n");
return res;
+}
if (track->audio.samplerate == 8000) {
// If this is needed for more codecs, then add them here
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 8/8] avformat/matroskadec: Reuse AVIOContext
When parsing EBML lacing, for every number read, a new AVIOContext has
been initialized (via ffio_init_context()) just for this number. This
has been changed: The context is kept now.
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroskadec.c | 45 ++-
1 file changed, 21 insertions(+), 24 deletions(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 6c81d1c4c8..162697ff12 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -1024,28 +1024,17 @@ static int ebml_read_master(MatroskaDemuxContext
*matroska,
}
/*
- * Read signed/unsigned "EBML" numbers.
+ * Read a signed "EBML number"
* Return: number of bytes processed, < 0 on error
*/
-static int matroska_ebmlnum_uint(MatroskaDemuxContext *matroska,
- uint8_t *data, uint32_t size, uint64_t *num)
-{
-AVIOContext pb;
-ffio_init_context(&pb, data, size, 0, NULL, NULL, NULL, NULL);
-return ebml_read_num(matroska, &pb, FFMIN(size, 8), num, 1);
-}
-
-/*
- * Same as above, but signed.
- */
static int matroska_ebmlnum_sint(MatroskaDemuxContext *matroska,
- uint8_t *data, uint32_t size, int64_t *num)
+ AVIOContext *pb, int64_t *num)
{
uint64_t unum;
int res;
/* read as unsigned number first */
-if ((res = matroska_ebmlnum_uint(matroska, data, size, &unum)) < 0)
+if ((res = ebml_read_num(matroska, pb, 8, &unum, 1)) < 0)
return res;
/* make signed (weird way) */
@@ -2989,7 +2978,7 @@ static void matroska_clear_queue(MatroskaDemuxContext
*matroska)
}
static int matroska_parse_laces(MatroskaDemuxContext *matroska, uint8_t **buf,
-int size, int type,
+int size, int type, AVIOContext *pb,
uint32_t lace_size[256], int *laces)
{
int n;
@@ -3047,27 +3036,33 @@ static int matroska_parse_laces(MatroskaDemuxContext
*matroska, uint8_t **buf,
{
uint64_t num;
uint64_t total;
-n = matroska_ebmlnum_uint(matroska, data, size, &num);
+int offset;
+
+avio_skip(pb, 4);
+
+n = ebml_read_num(matroska, pb, 8, &num, 1);
if (n < 0)
return n;
if (num > INT_MAX)
return AVERROR_INVALIDDATA;
-data += n;
-size -= n;
+
total = lace_size[0] = num;
+offset = n;
for (n = 1; n < *laces - 1; n++) {
int64_t snum;
int r;
-r = matroska_ebmlnum_sint(matroska, data, size, &snum);
+r = matroska_ebmlnum_sint(matroska, pb, &snum);
if (r < 0)
return r;
if (lace_size[n - 1] + snum > (uint64_t)INT_MAX)
return AVERROR_INVALIDDATA;
-data+= r;
-size-= r;
+
lace_size[n] = lace_size[n - 1] + snum;
total += lace_size[n];
+offset += r;
}
+data += offset;
+size -= offset;
if (size <= total) {
return AVERROR_INVALIDDATA;
}
@@ -3510,6 +3505,7 @@ static int matroska_parse_block(MatroskaDemuxContext
*matroska, AVBufferRef *buf
{
uint64_t timecode = AV_NOPTS_VALUE;
MatroskaTrack *track;
+AVIOContext pb;
int res = 0;
AVStream *st;
int16_t block_time;
@@ -3518,9 +3514,10 @@ static int matroska_parse_block(MatroskaDemuxContext
*matroska, AVBufferRef *buf
uint64_t num;
int trust_default_duration = 1;
-if ((n = matroska_ebmlnum_uint(matroska, data, size, &num)) < 0) {
+ffio_init_context(&pb, data, size, 0, NULL, NULL, NULL, NULL);
+
+if ((n = ebml_read_num(matroska, &pb, 8, &num, 1)) < 0)
return n;
-}
data += n;
size -= n;
@@ -3572,7 +3569,7 @@ static int matroska_parse_block(MatroskaDemuxContext
*matroska, AVBufferRef *buf
}
res = matroska_parse_laces(matroska, &data, size, (flags & 0x06) >> 1,
- lace_size, &laces);
+ &pb, lace_size, &laces);
if (res < 0) {
av_log(matroska->ctx, AV_LOG_ERROR, "Error parsing frame sizes.\n");
return res;
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] tools: add a fuzzer tool for bitstream filters
On Mon, 02. Dec 13:15, James Almer wrote:
> Signed-off-by: James Almer
> ---
> Untested.
>
> The BSF can be set the same way a decoder can in target_dec_fuzzer. The
> codec_id will be randomly chosen from the supported list, if any.
>
> tools/Makefile| 3 +
> tools/target_bsf_fuzzer.c | 166 ++
> 2 files changed, 169 insertions(+)
> create mode 100644 tools/target_bsf_fuzzer.c
>
> diff --git a/tools/Makefile b/tools/Makefile
> index 370ee35416..001093105b 100644
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -5,6 +5,9 @@ TOOLS-$(CONFIG_ZLIB) += cws2fws
> tools/target_dec_%_fuzzer.o: tools/target_dec_fuzzer.c
> $(COMPILE_C) -DFFMPEG_DECODER=$*
>
> +tools/target_bsf_%_fuzzer.o: tools/target_bsf_fuzzer.c
> + $(COMPILE_C) -DFFMPEG_BSF=$*
> +
> tools/target_dem_fuzzer.o: tools/target_dem_fuzzer.c
> $(COMPILE_C)
>
> diff --git a/tools/target_bsf_fuzzer.c b/tools/target_bsf_fuzzer.c
> new file mode 100644
> index 00..6849aaed0d
> --- /dev/null
> +++ b/tools/target_bsf_fuzzer.c
> @@ -0,0 +1,166 @@
> +/*
> + * 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 "config.h"
> +#include "libavutil/imgutils.h"
> +
> +#include "libavcodec/avcodec.h"
> +#include "libavcodec/bsf.h"
> +#include "libavcodec/bytestream.h"
> +#include "libavcodec/internal.h"
> +
> +int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size);
> +
> +static void error(const char *err)
> +{
> +fprintf(stderr, "%s", err);
> +exit(1);
> +}
> +
> +static AVBitStreamFilter *f = NULL;
> +
> +static const uint64_t FUZZ_TAG = 0x4741542D5A5A5546ULL;
> +
> +int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size) {
> +const uint64_t fuzz_tag = FUZZ_TAG;
> +const uint8_t *last = data;
> +const uint8_t *end = data + size;
> +AVBSFContext *bsf = NULL;
> +AVPacket in, out;
> +uint64_t keyframes = 0;
> +int res;
> +
> +if (!f) {
> +#ifdef FFMPEG_BSF
> +#define BSF_SYMBOL0(BSF) ff_##BSF##_bsf
> +#define BSF_SYMBOL(BSF) BSF_SYMBOL0(BSF)
> +extern AVBitStreamFilter BSF_SYMBOL(FFMPEG_BSF);
> +f = &BSF_SYMBOL(FFMPEG_BSF);
> +#else
> +extern AVBitStreamFilter ff_null_bsf;
> +f = &ff_null_bsf;
> +#endif
> +av_log_set_level(AV_LOG_PANIC);
> +}
> +
> +res = av_bsf_alloc(f, &bsf);
> +if (res < 0)
> +error("Failed memory allocation");
> +
> +if (size > 1024) {
> +GetByteContext gbc;
> +int extradata_size;
> +size -= 1024;
> +bytestream2_init(&gbc, data + size, 1024);
> +bsf->par_in->width = bytestream2_get_le32(&gbc);
> +bsf->par_in->height = bytestream2_get_le32(&gbc);
> +bsf->par_in->bit_rate = bytestream2_get_le64(&gbc);
> +bsf->par_in->bits_per_coded_sample = bytestream2_get_le32(&gbc);
> +
> +if (f->codec_ids) {
> +int i, j, idx = bytestream2_get_byte(&gbc);
Can you just read a bigger number instead of checking ++j == 8 below?
Maybe bytestream2_get_be24()?
> +int id = AV_CODEC_ID_NONE;
> +for (i = 0, j = 0; f->codec_ids[i] != AV_CODEC_ID_NONE; i++) {
> +// Iterate through all supported codec ids and get a random
> one
> +if (idx & (1 << j)) {
> +// There's at least one bsf that reports supporting more
> than eight codecs
> +if (++j == 8) {
> +idx = bytestream2_get_byte(&gbc);
> +j = 0;
> +}
> +continue;
> +}
> +id = f->codec_ids[i];
> +break;
> +}
The selection of the codecs doesn't seem uniform.
The probability of each codec is more like (1/2)^n, where n is codec index. I'm
not sure if the fuzzer will eventually learn this.
It may be better to use: id = idx % num_supported_codecs. But of course
num_supported_codecs would have to be evaluated first.
> +// Force using a codec if all were skipped
> +if (id == AV_CODEC_ID_NONE)
> +id = f->codec_ids[0];
> +bsf->par_in->co
Re: [FFmpeg-devel] [PATCH] tools: add a fuzzer tool for bitstream filters
On 12/3/2019 4:31 PM, Andriy Gelman wrote:
> On Mon, 02. Dec 13:15, James Almer wrote:
>> Signed-off-by: James Almer
>> ---
>> Untested.
>>
>> The BSF can be set the same way a decoder can in target_dec_fuzzer. The
>> codec_id will be randomly chosen from the supported list, if any.
>>
>> tools/Makefile| 3 +
>> tools/target_bsf_fuzzer.c | 166 ++
>> 2 files changed, 169 insertions(+)
>> create mode 100644 tools/target_bsf_fuzzer.c
>>
>> diff --git a/tools/Makefile b/tools/Makefile
>> index 370ee35416..001093105b 100644
>> --- a/tools/Makefile
>> +++ b/tools/Makefile
>> @@ -5,6 +5,9 @@ TOOLS-$(CONFIG_ZLIB) += cws2fws
>> tools/target_dec_%_fuzzer.o: tools/target_dec_fuzzer.c
>> $(COMPILE_C) -DFFMPEG_DECODER=$*
>>
>> +tools/target_bsf_%_fuzzer.o: tools/target_bsf_fuzzer.c
>> +$(COMPILE_C) -DFFMPEG_BSF=$*
>> +
>> tools/target_dem_fuzzer.o: tools/target_dem_fuzzer.c
>> $(COMPILE_C)
>>
>> diff --git a/tools/target_bsf_fuzzer.c b/tools/target_bsf_fuzzer.c
>> new file mode 100644
>> index 00..6849aaed0d
>> --- /dev/null
>> +++ b/tools/target_bsf_fuzzer.c
>> @@ -0,0 +1,166 @@
>> +/*
>> + * 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 "config.h"
>> +#include "libavutil/imgutils.h"
>> +
>> +#include "libavcodec/avcodec.h"
>> +#include "libavcodec/bsf.h"
>> +#include "libavcodec/bytestream.h"
>> +#include "libavcodec/internal.h"
>> +
>> +int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size);
>> +
>> +static void error(const char *err)
>> +{
>> +fprintf(stderr, "%s", err);
>> +exit(1);
>> +}
>> +
>> +static AVBitStreamFilter *f = NULL;
>> +
>> +static const uint64_t FUZZ_TAG = 0x4741542D5A5A5546ULL;
>> +
>> +int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size) {
>> +const uint64_t fuzz_tag = FUZZ_TAG;
>> +const uint8_t *last = data;
>> +const uint8_t *end = data + size;
>> +AVBSFContext *bsf = NULL;
>> +AVPacket in, out;
>> +uint64_t keyframes = 0;
>> +int res;
>> +
>> +if (!f) {
>> +#ifdef FFMPEG_BSF
>> +#define BSF_SYMBOL0(BSF) ff_##BSF##_bsf
>> +#define BSF_SYMBOL(BSF) BSF_SYMBOL0(BSF)
>> +extern AVBitStreamFilter BSF_SYMBOL(FFMPEG_BSF);
>> +f = &BSF_SYMBOL(FFMPEG_BSF);
>> +#else
>> +extern AVBitStreamFilter ff_null_bsf;
>> +f = &ff_null_bsf;
>> +#endif
>> +av_log_set_level(AV_LOG_PANIC);
>> +}
>> +
>> +res = av_bsf_alloc(f, &bsf);
>> +if (res < 0)
>> +error("Failed memory allocation");
>> +
>> +if (size > 1024) {
>> +GetByteContext gbc;
>> +int extradata_size;
>> +size -= 1024;
>> +bytestream2_init(&gbc, data + size, 1024);
>> +bsf->par_in->width =
>> bytestream2_get_le32(&gbc);
>> +bsf->par_in->height =
>> bytestream2_get_le32(&gbc);
>> +bsf->par_in->bit_rate =
>> bytestream2_get_le64(&gbc);
>> +bsf->par_in->bits_per_coded_sample =
>> bytestream2_get_le32(&gbc);
>> +
>
>> +if (f->codec_ids) {
>
>> +int i, j, idx = bytestream2_get_byte(&gbc);
>
> Can you just read a bigger number instead of checking ++j == 8 below?
> Maybe bytestream2_get_be24()?
The idea was read bytes until one bit was a 0 to signal to stop the
loop. It would in theory work even with a bsf that supports INT_MAX
amount of codecs, and eventually stop anyway since the GetByteContext
would run out of data and start returning zeroes.
>
>> +int id = AV_CODEC_ID_NONE;
>> +for (i = 0, j = 0; f->codec_ids[i] != AV_CODEC_ID_NONE; i++) {
>> +// Iterate through all supported codec ids and get a random
>> one
>> +if (idx & (1 << j)) {
>> +// There's at least one bsf that reports supporting
>> more than eight codecs
>
>> +if (++j == 8) {
>> +idx = bytestream2_get_byte(&gbc);
>> +j = 0;
>> +}
>> +continue;
>> +}
>> +id = f->codec_ids[i];
>> +break;
>> +}
>
> The selection of the codecs
Re: [FFmpeg-devel] [PATCH 1/3] avformat/movenc: write the major brand also as the first compatible brand
On 12/3/2019 5:19 AM, Michael Niedermayer wrote: > On Mon, Dec 02, 2019 at 01:18:36PM -0300, James Almer wrote: >> Signed-off-by: James Almer >> --- > >> This is meant to be squashed with patch 2/3, otherwise it will write >> duplicate >> compatible brands, and a lot of tests will have to be updated twice. > > I dont think 2 updates are a problem if it keeps the commits more readable Alright. > > [...] > > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avdevice/xcbgrab: Handle reply and error properly
On Tue, 3 Dec 2019, Kusanagi Kouichi wrote:
On 2019-11-19 22:59:30 +0900, Kusanagi Kouichi wrote:
Fix a NULL dereference and leaks.
Signed-off-by: Kusanagi Kouichi
---
libavdevice/xcbgrab.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavdevice/xcbgrab.c b/libavdevice/xcbgrab.c
index b7e689343e..063fecf838 100644
--- a/libavdevice/xcbgrab.c
+++ b/libavdevice/xcbgrab.c
@@ -168,6 +168,7 @@ static int xcbgrab_frame(AVFormatContext *s, AVPacket *pkt)
"sequence:%u resource_id:%u minor_code:%u major_code:%u.\n",
e->response_type, e->error_code,
e->sequence, e->resource_id, e->minor_code, e->major_code);
+free(e);
return AVERROR(EACCES);
}
@@ -276,6 +277,7 @@ static int xcbgrab_frame_shm(AVFormatContext *s, AVPacket
*pkt)
e->response_type, e->error_code,
e->sequence, e->resource_id, e->minor_code, e->major_code);
+free(e);
return AVERROR(EACCES);
}
@@ -537,6 +539,8 @@ static int create_stream(AVFormatContext *s)
gc = xcb_get_geometry(c->conn, c->screen->root);
geo = xcb_get_geometry_reply(c->conn, gc, NULL);
+if (!geo)
+return AVERROR_EXTERNAL;
if (c->x + c->width > geo->width ||
c->y + c->height > geo->height) {
@@ -546,6 +550,7 @@ static int create_stream(AVFormatContext *s)
c->width, c->height,
c->x, c->y,
geo->width, geo->height);
+free(geo);
return AVERROR(EINVAL);
}
--
2.24.0
ping
Applied, thanks.
Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avdevice/xcbgrab: Improve non-shm performance
On Tue, 3 Dec 2019, Kusanagi Kouichi wrote:
On 2019-11-19 22:59:56 +0900, Kusanagi Kouichi wrote:
Use AVBufferPool.
You don't need a buffer pool for the non-shm case, you should wrap the XCB
data in a buffer ref instead. I will reply with a patch that shows how it
is done, please check if it works correctly, as I am not 100% sure how xcb
data structures should be allocated/freed.
What actually would benefit from a buffer pool is the SHM case. A pool of
SHM buffers which are wrapped in a buffer ref can avoid yet another
memcpy. Is the amount of SHM space that is usually available is limited
or not? If so, how much is the limit? Can we safely allocate at least
10-20 buffers?
Regards,
Marton
before:
$ ffmpeg -benchmark -f x11grab -video_size 1920x1200 -r 200 -t 3 -i +0,0 -f
null -
...
frame= 600 fps=102 q=-0.0 Lsize=N/A time=00:00:03.00 bitrate=N/A speed=0.51x
video:314kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing
overhead: unknown
bench: utime=1.551s stime=3.428s rtime=5.884s
bench: maxrss=40132kB
after:
$ ffmpeg -benchmark -f x11grab -video_size 1920x1200 -r 200 -t 3 -i +0,0 -f
null -
...
frame= 600 fps=138 q=-0.0 Lsize=N/A time=00:00:03.00 bitrate=N/A speed=0.69x
video:314kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing
overhead: unknown
bench: utime=1.231s stime=2.407s rtime=4.349s
bench: maxrss=40096kB
Signed-off-by: Kusanagi Kouichi
---
libavdevice/xcbgrab.c | 38 +++---
1 file changed, 31 insertions(+), 7 deletions(-)
diff --git a/libavdevice/xcbgrab.c b/libavdevice/xcbgrab.c
index b7e689343e..fde9c534cd 100644
--- a/libavdevice/xcbgrab.c
+++ b/libavdevice/xcbgrab.c
@@ -42,6 +42,7 @@
#include "libavutil/opt.h"
#include "libavutil/parseutils.h"
#include "libavutil/time.h"
+#include "libavutil/buffer.h"
#include "libavformat/avformat.h"
#include "libavformat/internal.h"
@@ -71,6 +72,8 @@ typedef struct XCBGrabContext {
int region_border;
int centered;
+AVBufferPool *buf_pool;
+
const char *video_size;
const char *framerate;
@@ -146,6 +149,16 @@ static int xcbgrab_reposition(AVFormatContext *s,
return 0;
}
+static AVBufferRef *xcbgrab_allocate_buffer(const int size)
+{
+AVPacket pkt;
+
+if (av_new_packet(&pkt, size))
+return NULL;
+
+return pkt.buf;
+}
+
static int xcbgrab_frame(AVFormatContext *s, AVPacket *pkt)
{
XCBGrabContext *c = s->priv_data;
@@ -154,7 +167,7 @@ static int xcbgrab_frame(AVFormatContext *s, AVPacket *pkt)
xcb_drawable_t drawable = c->screen->root;
xcb_generic_error_t *e = NULL;
uint8_t *data;
-int length, ret;
+int length;
iq = xcb_get_image(c->conn, XCB_IMAGE_FORMAT_Z_PIXMAP, drawable,
c->x, c->y, c->width, c->height, ~0);
@@ -174,17 +187,21 @@ static int xcbgrab_frame(AVFormatContext *s, AVPacket
*pkt)
if (!img)
return AVERROR(EAGAIN);
+pkt->buf = av_buffer_pool_get(c->buf_pool);
+if (!pkt->buf) {
+free(img);
+return AVERROR(ENOMEM);
+}
+
data = xcb_get_image_data(img);
length = xcb_get_image_data_length(img);
-ret = av_new_packet(pkt, length);
-
-if (!ret)
-memcpy(pkt->data, data, length);
-
+memcpy(pkt->buf->data, data, length);
free(img);
+pkt->data = pkt->buf->data;
+pkt->size = pkt->buf->size;
-return ret;
+return 0;
}
static void wait_frame(AVFormatContext *s, AVPacket *pkt)
@@ -442,6 +459,7 @@ static av_cold int xcbgrab_read_close(AVFormatContext *s)
#endif
xcb_disconnect(ctx->conn);
+av_buffer_pool_uninit(&ctx->buf_pool);
return 0;
}
@@ -665,6 +683,12 @@ static av_cold int xcbgrab_read_header(AVFormatContext *s)
return ret;
}
+c->buf_pool = av_buffer_pool_init(c->frame_size, xcbgrab_allocate_buffer);
+if (ret < 0) {
+xcbgrab_read_close(s);
+return AVERROR(ENOMEM);
+}
+
#if CONFIG_LIBXCB_SHM
if ((c->has_shm = check_shm(c->conn)))
c->segment = xcb_generate_id(c->conn);
--
2.24.0
ping
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] tools: add a fuzzer tool for bitstream filters
Signed-off-by: James Almer
---
tools/Makefile| 3 +
tools/target_bsf_fuzzer.c | 153 ++
2 files changed, 156 insertions(+)
create mode 100644 tools/target_bsf_fuzzer.c
diff --git a/tools/Makefile b/tools/Makefile
index 370ee35416..001093105b 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -5,6 +5,9 @@ TOOLS-$(CONFIG_ZLIB) += cws2fws
tools/target_dec_%_fuzzer.o: tools/target_dec_fuzzer.c
$(COMPILE_C) -DFFMPEG_DECODER=$*
+tools/target_bsf_%_fuzzer.o: tools/target_bsf_fuzzer.c
+ $(COMPILE_C) -DFFMPEG_BSF=$*
+
tools/target_dem_fuzzer.o: tools/target_dem_fuzzer.c
$(COMPILE_C)
diff --git a/tools/target_bsf_fuzzer.c b/tools/target_bsf_fuzzer.c
new file mode 100644
index 00..f3e584fdf4
--- /dev/null
+++ b/tools/target_bsf_fuzzer.c
@@ -0,0 +1,153 @@
+/*
+ * 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 "config.h"
+#include "libavutil/imgutils.h"
+
+#include "libavcodec/avcodec.h"
+#include "libavcodec/bsf.h"
+#include "libavcodec/bytestream.h"
+#include "libavcodec/internal.h"
+
+int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size);
+
+static void error(const char *err)
+{
+fprintf(stderr, "%s", err);
+exit(1);
+}
+
+static AVBitStreamFilter *f = NULL;
+
+static const uint64_t FUZZ_TAG = 0x4741542D5A5A5546ULL;
+
+int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size) {
+const uint64_t fuzz_tag = FUZZ_TAG;
+const uint8_t *last = data;
+const uint8_t *end = data + size;
+AVBSFContext *bsf = NULL;
+AVPacket in, out;
+uint64_t keyframes = 0;
+int res;
+
+if (!f) {
+#ifdef FFMPEG_BSF
+#define BSF_SYMBOL0(BSF) ff_##BSF##_bsf
+#define BSF_SYMBOL(BSF) BSF_SYMBOL0(BSF)
+extern AVBitStreamFilter BSF_SYMBOL(FFMPEG_BSF);
+f = &BSF_SYMBOL(FFMPEG_BSF);
+#else
+extern AVBitStreamFilter ff_null_bsf;
+f = &ff_null_bsf;
+#endif
+av_log_set_level(AV_LOG_PANIC);
+}
+
+res = av_bsf_alloc(f, &bsf);
+if (res < 0)
+error("Failed memory allocation");
+
+if (size > 1024) {
+GetByteContext gbc;
+int extradata_size;
+size -= 1024;
+bytestream2_init(&gbc, data + size, 1024);
+bsf->par_in->width = bytestream2_get_le32(&gbc);
+bsf->par_in->height = bytestream2_get_le32(&gbc);
+bsf->par_in->bit_rate = bytestream2_get_le64(&gbc);
+bsf->par_in->bits_per_coded_sample = bytestream2_get_le32(&gbc);
+
+if (f->codec_ids) {
+int i, id;
+for (i = 0; f->codec_ids[i] != AV_CODEC_ID_NONE; i++);
+id = f->codec_ids[bytestream2_get_byte(&gbc) % i];
+bsf->par_in->codec_id = id;
+bsf->par_in->codec_tag = bytestream2_get_le32(&gbc);
+}
+
+extradata_size = bytestream2_get_le32(&gbc);
+
+bsf->par_in->sample_rate= bytestream2_get_le32(&gbc);
+bsf->par_in->channels =
(unsigned)bytestream2_get_le32(&gbc) % FF_SANE_NB_CHANNELS;
+bsf->par_in->block_align= bytestream2_get_le32(&gbc);
+keyframes = bytestream2_get_le64(&gbc);
+
+if (extradata_size < size) {
+bsf->par_in->extradata = av_mallocz(extradata_size +
AV_INPUT_BUFFER_PADDING_SIZE);
+if (bsf->par_in->extradata) {
+bsf->par_in->extradata_size = extradata_size;
+size -= bsf->par_in->extradata_size;
+memcpy(bsf->par_in->extradata, data + size,
bsf->par_in->extradata_size);
+}
+}
+if (av_image_check_size(bsf->par_in->width, bsf->par_in->height, 0,
bsf))
+bsf->par_in->width = bsf->par_in->height = 0;
+}
+
+res = av_bsf_init(bsf);
+if (res < 0) {
+av_bsf_free(&bsf);
+return 0; // Failure of av_bsf_init() does not imply that a issue was
found
+}
+
+av_init_packet(&in);
+av_init_packet(&out);
+out.data = NULL;
+out.size = 0;
+while (data < end) {
+// Search for the TAG
+while (data + sizeof(fuzz_tag) < end) {
+if (data[0] == (fuzz_tag & 0xFF) && AV_RN64(data) =
[FFmpeg-devel] [PATCH 1/2] avcodec/twinvqdec: Correct overflow in block align check
Fixes: signed integer overflow: 538976288 * 8 cannot be represented in type
'int'
Fixes:
19126/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TWINVQ_fuzzer-5687464110325760
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/twinvqdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/twinvqdec.c b/libavcodec/twinvqdec.c
index c2353f51b5..c00ebb2ad5 100644
--- a/libavcodec/twinvqdec.c
+++ b/libavcodec/twinvqdec.c
@@ -404,7 +404,7 @@ static av_cold int twinvq_decode_init(AVCodecContext *avctx)
tctx->frame_size = avctx->bit_rate * tctx->mtab->size
/ avctx->sample_rate + 8;
tctx->is_6kbps = 0;
-if (avctx->block_align && avctx->block_align * 8 / tctx->frame_size > 1) {
+if (avctx->block_align && avctx->block_align * 8LL / tctx->frame_size > 1)
{
av_log(avctx, AV_LOG_ERROR,
"VQF TwinVQ should have only one frame per packet\n");
return AVERROR_INVALIDDATA;
--
2.23.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] avformat, avcodec: add dfcmv demuxer and decoder
A few example CMV files can be found in the data/initial_movies folder
of Dwarf Fortress (http://www.bay12games.com/dwarves/).
The demuxer does not currently handle audio cues. There are warning
messages logged for each audio file that should be played. As far as I
know, the only two existing CMV files with audio cues in them are in the
examples folder mentioned above.
(Reformatted to hopefully make the patch not break in GMail's weird
forced word wrapping)
Signed-off-by: Ben Lubar
---
Changelog|1 +
configure|1 +
doc/general.texi |2 +
libavcodec/Makefile |1 +
libavcodec/allcodecs.c |1 +
libavcodec/avcodec.h |1 +
libavcodec/codec_desc.c |7 +
libavcodec/dfcmv.c | 1133 ++
libavcodec/version.h |4 +-
libavformat/Makefile |1 +
libavformat/allformats.c |1 +
libavformat/dfcmv.c | 232
libavformat/version.h|2 +-
13 files changed, 1384 insertions(+), 3 deletions(-)
create mode 100644 libavcodec/dfcmv.c
create mode 100644 libavformat/dfcmv.c
diff --git a/Changelog b/Changelog
index f30f398a9f..eed4fa8a50 100644
--- a/Changelog
+++ b/Changelog
@@ -27,6 +27,7 @@ version :
- axcorrelate filter
- mvdv decoder
- mvha decoder
+- Dwarf Fortress CMV demuxer and decoder
version 4.2:
diff --git a/configure b/configure
index ca7137f341..622deed689 100755
--- a/configure
+++ b/configure
@@ -3258,6 +3258,7 @@ caf_demuxer_select="iso_media riffdec"
caf_muxer_select="iso_media"
dash_muxer_select="mp4_muxer"
dash_demuxer_deps="libxml2"
+dfcmv_demuxer_deps="zlib"
dirac_demuxer_select="dirac_parser"
dts_demuxer_select="dca_parser"
dtshd_demuxer_select="dca_parser"
diff --git a/doc/general.texi b/doc/general.texi
index a5b77e0de1..bbc90a2f58 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -429,6 +429,7 @@ library:
@tab Video format used by CD+G karaoke disks
@item Phantom Cine @tab @tab X
@item Cineform HD @tab @tab X
+@item Dwarf Fortress Curses MoVie (.cmv files) @tab @tab X
@item Commodore CDXL@tab @tab X
@tab Amiga CD video format
@item Core Audio Format @tab X @tab X
@@ -843,6 +844,7 @@ following image formats are supported:
@item Delphine Software International CIN video @tab @tab X
@tab Codec used in Delphine Software International games.
@item Discworld II BMV Video @tab @tab X
+@item Dwarf Fortess Curses MoVie (CMV) @tab @tab X
@item Canopus Lossless Codec @tab @tab X
@item Cinepak@tab @tab X
@item Cirrus Logic AccuPak @tab X @tab X
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index c1f35b40d8..24e146e90f 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -267,6 +267,7 @@ OBJS-$(CONFIG_DDS_DECODER) += dds.o
OBJS-$(CONFIG_DIRAC_DECODER) += diracdec.o dirac.o
diracdsp.o diractab.o \
dirac_arith.o dirac_dwt.o dirac_vlc.o
OBJS-$(CONFIG_DFA_DECODER) += dfa.o
+OBJS-$(CONFIG_DFCMV_DECODER) += dfcmv.o
OBJS-$(CONFIG_DNXHD_DECODER) += dnxhddec.o dnxhddata.o
OBJS-$(CONFIG_DNXHD_ENCODER) += dnxhdenc.o dnxhddata.o
OBJS-$(CONFIG_DOLBY_E_DECODER) += dolby_e.o kbdwin.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index c33edf23c9..8571cce906 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -83,6 +83,7 @@ extern AVCodec ff_cscd_decoder;
extern AVCodec ff_cyuv_decoder;
extern AVCodec ff_dds_decoder;
extern AVCodec ff_dfa_decoder;
+extern AVCodec ff_dfcmv_decoder;
extern AVCodec ff_dirac_decoder;
extern AVCodec ff_dnxhd_encoder;
extern AVCodec ff_dnxhd_decoder;
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 735a3c2d76..bd0446fe92 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -410,6 +410,7 @@ enum AVCodecID {
AV_CODEC_ID_SCREENPRESSO,
AV_CODEC_ID_RSCC,
AV_CODEC_ID_AVS2,
+AV_CODEC_ID_DFCMV,
AV_CODEC_ID_Y41P = 0x8000,
AV_CODEC_ID_AVRP,
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 570bd2f382..4ce8416b8e 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -1403,6 +1403,13 @@ static const AVCodecDescriptor codec_descriptors[] = {
.long_name = NULL_IF_CONFIG_SMALL("AVS2-P2/IEEE1857.4"),
.props = AV_CODEC_PROP_LOSSY,
},
+{
+.id= AV_CODEC_ID_DFCMV,
+.type = AVMEDIA_TYPE_VIDEO,
+.name = "dfcmv",
+.long_name = NULL_IF_CONFIG_SMALL("Dwarf Fortress Curses MoVie"),
+.props = AV_CODEC_PROP_INTRA_ONLY,
+},
{
.id= AV_CODEC_ID_Y41P,
.type = AVMEDIA_TYPE_VIDEO,
diff --git a/libavcodec/dfcmv.c b/libavcodec/dfcmv.c
new file mode 100644
index 00..9a1f4ac4d8
--- /dev/null
+++ b/libavcodec/dfcmv.c
@@ -0,0 +1,1133 @@
+#inc
[FFmpeg-devel] [PATCH] avdevice/xcbgrab: wrap non-shm image replies in a buffer ref
This avoids a memcpy improving performance if SHM is not used.
Signed-off-by: Marton Balint
---
libavdevice/xcbgrab.c | 22 +++---
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/libavdevice/xcbgrab.c b/libavdevice/xcbgrab.c
index 063fecf838..440361c8fa 100644
--- a/libavdevice/xcbgrab.c
+++ b/libavdevice/xcbgrab.c
@@ -146,6 +146,11 @@ static int xcbgrab_reposition(AVFormatContext *s,
return 0;
}
+static void xcbgrab_image_reply_free(void *opaque, uint8_t *data)
+{
+free(opaque);
+}
+
static int xcbgrab_frame(AVFormatContext *s, AVPacket *pkt)
{
XCBGrabContext *c = s->priv_data;
@@ -154,7 +159,7 @@ static int xcbgrab_frame(AVFormatContext *s, AVPacket *pkt)
xcb_drawable_t drawable = c->screen->root;
xcb_generic_error_t *e = NULL;
uint8_t *data;
-int length, ret;
+int length;
iq = xcb_get_image(c->conn, XCB_IMAGE_FORMAT_Z_PIXMAP, drawable,
c->x, c->y, c->width, c->height, ~0);
@@ -178,14 +183,17 @@ static int xcbgrab_frame(AVFormatContext *s, AVPacket
*pkt)
data = xcb_get_image_data(img);
length = xcb_get_image_data_length(img);
-ret = av_new_packet(pkt, length);
+av_init_packet(pkt);
+pkt->data = data;
+pkt->size = length;
+pkt->buf = av_buffer_create(pkt->data, pkt->size,
xcbgrab_image_reply_free, img, 0);
-if (!ret)
-memcpy(pkt->data, data, length);
-
-free(img);
+if (!pkt->buf) {
+free(img);
+return AVERROR(ENOMEM);
+}
-return ret;
+return 0;
}
static void wait_frame(AVFormatContext *s, AVPacket *pkt)
--
2.16.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avfilter/buffersrc: deprecate sws_param option
On Tue, Dec 03, 2019 at 03:35:24PM +0800, quinkbl...@foxmail.com wrote: > From: Zhao Zhili > > --- > doc/filters.texi| 4 +--- > libavfilter/buffersrc.c | 14 -- > libavfilter/version.h | 5 - > 3 files changed, 17 insertions(+), 6 deletions(-) > > diff --git a/doc/filters.texi b/doc/filters.texi > index 5fdec6f015..9b3c2d7c2d 100644 > --- a/doc/filters.texi > +++ b/doc/filters.texi > @@ -21014,9 +21014,7 @@ Specify the frame rate expected for the video stream. > The sample (pixel) aspect ratio of the input video. > > @item sws_param > -Specify the optional parameters to be used for the scale filter which > -is automatically inserted when an input change is detected in the > -input size or format. > +This option is deprecated and ignored. This should document how to set the parameters for automatically inserted filters. Because as is, it leaves the user with no idea how or if that can be still done Thanks [...] -- 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 https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/2] avcodec/atrac9dec: Check q_unit_cnt more completely before using it to access at9_tab_band_ext_group
Fixes: index 8 out of bounds for type 'const uint8_t [8][3]'
Fixes:
19127/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ATRAC9_fuzzer-5709394985091072
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/atrac9dec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/atrac9dec.c b/libavcodec/atrac9dec.c
index e3e4f2f14e..5415d1348e 100644
--- a/libavcodec/atrac9dec.c
+++ b/libavcodec/atrac9dec.c
@@ -199,7 +199,7 @@ static inline int parse_band_ext(ATRAC9Context *s,
ATRAC9BlockData *b,
int ext_band = 0;
if (b->has_band_ext) {
-if (b->q_unit_cnt < 13)
+if (b->q_unit_cnt < 13 || b->q_unit_cnt > 20)
return AVERROR_INVALIDDATA;
ext_band = at9_tab_band_ext_group[b->q_unit_cnt - 13][2];
if (stereo) {
--
2.23.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/2] lavc/hevc_mp4toannexb: Simplify error check
From: Andriy Gelman
Signed-off-by: Andriy Gelman
---
libavcodec/hevc_mp4toannexb_bsf.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/libavcodec/hevc_mp4toannexb_bsf.c
b/libavcodec/hevc_mp4toannexb_bsf.c
index 36fd6f0b15c..49daf4a616c 100644
--- a/libavcodec/hevc_mp4toannexb_bsf.c
+++ b/libavcodec/hevc_mp4toannexb_bsf.c
@@ -152,8 +152,7 @@ static int hevc_mp4toannexb_filter(AVBSFContext *ctx,
AVPacket *out)
extra_size= add_extradata * ctx->par_out->extradata_size;
got_irap |= is_irap;
-if (INT_MAX < 4 + nalu_size ||
-INT_MAX - 4 < extra_size + nalu_size) {
+if (INT_MAX < 4 + nalu_size + extra_size) {
ret = AVERROR_INVALIDDATA;
goto fail;
}
--
2.24.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/2] lavc/hevc_mp4toannexb: Fix interger overflow
From: Andriy Gelman
Check packet grow size against INT_MAX instead of SIZE_MAX.
Found with libFuzzer:
4294967044 cannot be represented as int.
Signed-off-by: Andriy Gelman
---
libavcodec/hevc_mp4toannexb_bsf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/hevc_mp4toannexb_bsf.c
b/libavcodec/hevc_mp4toannexb_bsf.c
index 09bce5b34c2..36fd6f0b15c 100644
--- a/libavcodec/hevc_mp4toannexb_bsf.c
+++ b/libavcodec/hevc_mp4toannexb_bsf.c
@@ -152,8 +152,8 @@ static int hevc_mp4toannexb_filter(AVBSFContext *ctx,
AVPacket *out)
extra_size= add_extradata * ctx->par_out->extradata_size;
got_irap |= is_irap;
-if (SIZE_MAX - nalu_size < 4 ||
-SIZE_MAX - 4 - nalu_size < extra_size) {
+if (INT_MAX < 4 + nalu_size ||
+INT_MAX - 4 < extra_size + nalu_size) {
ret = AVERROR_INVALIDDATA;
goto fail;
}
--
2.24.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] tools: add a fuzzer tool for bitstream filters
On Tue, Dec 03, 2019 at 04:59:26PM -0300, James Almer wrote:
> On 12/3/2019 4:31 PM, Andriy Gelman wrote:
> > On Mon, 02. Dec 13:15, James Almer wrote:
> >> Signed-off-by: James Almer
> >> ---
> >> Untested.
> >>
> >> The BSF can be set the same way a decoder can in target_dec_fuzzer. The
> >> codec_id will be randomly chosen from the supported list, if any.
> >>
> >> tools/Makefile| 3 +
> >> tools/target_bsf_fuzzer.c | 166 ++
> >> 2 files changed, 169 insertions(+)
> >> create mode 100644 tools/target_bsf_fuzzer.c
[...]
> >
> >
> >> +while (data < end) {
> >
> >> +// Search for the TAG
> >> +while (data + sizeof(fuzz_tag) < end) {
> >> +if (data[0] == (fuzz_tag & 0xFF) && AV_RN64(data) == fuzz_tag)
> >> +break;
> >> +data++;
> >> +}
> >
> > Is the idea here to add "FUZZ_TAG" via the -dict option when running the
> > fuzzer?
>
> I don't know, but Michael might.
I dont know how or if FUZZ_TAG "connects" back into the fuzzer.
But the same issue also exist for every chunk, slice, packet header
the fuzzer has to generate valid data
thx
[...]
--
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
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avformat, avcodec: add dfcmv demuxer and decoder
On Tue, Dec 03, 2019 at 03:27:12PM -0600, Ben Lubar wrote: > A few example CMV files can be found in the data/initial_movies folder > of Dwarf Fortress (http://www.bay12games.com/dwarves/). > > The demuxer does not currently handle audio cues. There are warning > messages logged for each audio file that should be played. As far as I > know, the only two existing CMV files with audio cues in them are in the > examples folder mentioned above. > > (Reformatted to hopefully make the patch not break in GMail's weird > forced word wrapping) > > Signed-off-by: Ben Lubar > --- > Changelog|1 + > configure|1 + > doc/general.texi |2 + > libavcodec/Makefile |1 + > libavcodec/allcodecs.c |1 + > libavcodec/avcodec.h |1 + > libavcodec/codec_desc.c |7 + > libavcodec/dfcmv.c | 1133 ++ > libavcodec/version.h |4 +- > libavformat/Makefile |1 + > libavformat/allformats.c |1 + > libavformat/dfcmv.c | 232 > libavformat/version.h|2 +- > 13 files changed, 1384 insertions(+), 3 deletions(-) > create mode 100644 libavcodec/dfcmv.c > create mode 100644 libavformat/dfcmv.c libavcodec and libavformat changes should be in seperate patches also the patch seems corrupted: Applying: avformat, avcodec: add dfcmv demuxer and decoder error: corrupt patch at line 69 error: could not build fake ancestor Patch failed at 0001 avformat, avcodec: add dfcmv demuxer and decoder thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB He who knows, does not speak. He who speaks, does not know. -- Lao Tsu signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] lavc/hevc_mp4toannexb: Fix interger overflow
On Tue, Dec 3, 2019 at 10:41 PM Andriy Gelman
wrote:
> From: Andriy Gelman
>
> Check packet grow size against INT_MAX instead of SIZE_MAX.
>
> Found with libFuzzer:
> 4294967044 cannot be represented as int.
>
> Signed-off-by: Andriy Gelman
> ---
> libavcodec/hevc_mp4toannexb_bsf.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/hevc_mp4toannexb_bsf.c
> b/libavcodec/hevc_mp4toannexb_bsf.c
> index 09bce5b34c2..36fd6f0b15c 100644
> --- a/libavcodec/hevc_mp4toannexb_bsf.c
> +++ b/libavcodec/hevc_mp4toannexb_bsf.c
> @@ -152,8 +152,8 @@ static int hevc_mp4toannexb_filter(AVBSFContext *ctx,
> AVPacket *out)
> extra_size= add_extradata * ctx->par_out->extradata_size;
> got_irap |= is_irap;
>
> -if (SIZE_MAX - nalu_size < 4 ||
> -SIZE_MAX - 4 - nalu_size < extra_size) {
> +if (INT_MAX < 4 + nalu_size ||
> +INT_MAX - 4 < extra_size + nalu_size) {
> ret = AVERROR_INVALIDDATA;
> goto fail;
> }
> --
>
> 1. Typo in "Interger".
2. You did not really fix the overflow problem: If nalu_size is (say)
UINT32_MAX, 4 + nalu_size is 3 (no undefined behaviour involved here) and
if extra_size is > 0 and <= INT_MAX - 4, then we don't go to fail here.
Your check merely ensures that (after possible (defined) overflow) 4 +
nalu_size + extra_size is >= 0 and <= INT_MAX, so that the automatic
conversion to int (the type of the parameter of av_grow_packet()) is
lossless. But in a scenario outlined here, the memcpy operations that
follow will surely segfault.
3. There is another problem here: There is no check that the NAL unit is
actually contained in the packet. A packet of size 10 bytes could contain a
NAL unit with a size field indicating a size of (say) 1 GB and it would be
allocated; it would not segfault, though, because the safe version of the
bytestream2 API is used. (I think I already told you this, didn't I?)
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 1/3] lavc/hevc_mp4toannexb: Fix integer overflow
From: Andriy Gelman
Check packet grow size against INT_MAX instead of SIZE_MAX.
Found with libFuzzer:
4294967044 cannot be represented as int.
Signed-off-by: Andriy Gelman
---
libavcodec/hevc_mp4toannexb_bsf.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/hevc_mp4toannexb_bsf.c
b/libavcodec/hevc_mp4toannexb_bsf.c
index 09bce5b34c2..bf4c25b3b7b 100644
--- a/libavcodec/hevc_mp4toannexb_bsf.c
+++ b/libavcodec/hevc_mp4toannexb_bsf.c
@@ -66,7 +66,7 @@ static int hevc_extradata_to_annexb(AVBSFContext *ctx)
for (j = 0; j < cnt; j++) {
int nalu_len = bytestream2_get_be16(&gb);
-if (4 + AV_INPUT_BUFFER_PADDING_SIZE + nalu_len > SIZE_MAX -
new_extradata_size) {
+if (4 + AV_INPUT_BUFFER_PADDING_SIZE + nalu_len > INT_MAX -
new_extradata_size) {
ret = AVERROR_INVALIDDATA;
goto fail;
}
@@ -152,8 +152,8 @@ static int hevc_mp4toannexb_filter(AVBSFContext *ctx,
AVPacket *out)
extra_size= add_extradata * ctx->par_out->extradata_size;
got_irap |= is_irap;
-if (SIZE_MAX - nalu_size < 4 ||
-SIZE_MAX - 4 - nalu_size < extra_size) {
+if (INT_MAX < 4 + (uint64_t)nalu_size ||
+INT_MAX - 4 < extra_size + (uint64_t)nalu_size) {
ret = AVERROR_INVALIDDATA;
goto fail;
}
--
2.24.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 2/3] lavc/hevc_mp4toannexb: Simplify error check
From: Andriy Gelman
Signed-off-by: Andriy Gelman
---
libavcodec/hevc_mp4toannexb_bsf.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/libavcodec/hevc_mp4toannexb_bsf.c
b/libavcodec/hevc_mp4toannexb_bsf.c
index bf4c25b3b7b..faf516634b2 100644
--- a/libavcodec/hevc_mp4toannexb_bsf.c
+++ b/libavcodec/hevc_mp4toannexb_bsf.c
@@ -152,8 +152,7 @@ static int hevc_mp4toannexb_filter(AVBSFContext *ctx,
AVPacket *out)
extra_size= add_extradata * ctx->par_out->extradata_size;
got_irap |= is_irap;
-if (INT_MAX < 4 + (uint64_t)nalu_size ||
-INT_MAX - 4 < extra_size + (uint64_t)nalu_size) {
+if (INT_MAX < 4 + (uint64_t)nalu_size + extra_size) {
ret = AVERROR_INVALIDDATA;
goto fail;
}
--
2.24.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 3/3] lavc/hevc_mp4toannexb: Exit earlier if there is no nalu payload remaining
From: Andriy Gelman
Since the nal unit payload is located after the length prefix, there is
no reason to continue reading if there is no nal unit payload remaining.
---
libavcodec/hevc_mp4toannexb_bsf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/hevc_mp4toannexb_bsf.c
b/libavcodec/hevc_mp4toannexb_bsf.c
index faf516634b2..c0968b63239 100644
--- a/libavcodec/hevc_mp4toannexb_bsf.c
+++ b/libavcodec/hevc_mp4toannexb_bsf.c
@@ -136,7 +136,7 @@ static int hevc_mp4toannexb_filter(AVBSFContext *ctx,
AVPacket *out)
bytestream2_init(&gb, in->data, in->size);
-while (bytestream2_get_bytes_left(&gb)) {
+while (bytestream2_get_bytes_left(&gb) > s->length_size) {
uint32_t nalu_size = 0;
int nalu_type;
int is_irap, add_extradata, extra_size, prev_size;
--
2.24.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] lavc/hevc_mp4toannexb: Fix interger overflow
On Tue, 03. Dec 23:30, Andreas Rheinhardt wrote:
> On Tue, Dec 3, 2019 at 10:41 PM Andriy Gelman
> wrote:
>
> > From: Andriy Gelman
> >
> > Check packet grow size against INT_MAX instead of SIZE_MAX.
> >
> > Found with libFuzzer:
> > 4294967044 cannot be represented as int.
> >
> > Signed-off-by: Andriy Gelman
> > ---
> > libavcodec/hevc_mp4toannexb_bsf.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavcodec/hevc_mp4toannexb_bsf.c
> > b/libavcodec/hevc_mp4toannexb_bsf.c
> > index 09bce5b34c2..36fd6f0b15c 100644
> > --- a/libavcodec/hevc_mp4toannexb_bsf.c
> > +++ b/libavcodec/hevc_mp4toannexb_bsf.c
> > @@ -152,8 +152,8 @@ static int hevc_mp4toannexb_filter(AVBSFContext *ctx,
> > AVPacket *out)
> > extra_size= add_extradata * ctx->par_out->extradata_size;
> > got_irap |= is_irap;
> >
> > -if (SIZE_MAX - nalu_size < 4 ||
> > -SIZE_MAX - 4 - nalu_size < extra_size) {
> > +if (INT_MAX < 4 + nalu_size ||
> > +INT_MAX - 4 < extra_size + nalu_size) {
> > ret = AVERROR_INVALIDDATA;
> > goto fail;
> > }
> > --
> >
> > 1. Typo in "Interger".
> 2. You did not really fix the overflow problem: If nalu_size is (say)
> UINT32_MAX, 4 + nalu_size is 3 (no undefined behaviour involved here) and
> if extra_size is > 0 and <= INT_MAX - 4, then we don't go to fail here.
> Your check merely ensures that (after possible (defined) overflow) 4 +
> nalu_size + extra_size is >= 0 and <= INT_MAX, so that the automatic
> conversion to int (the type of the parameter of av_grow_packet()) is
> lossless. But in a scenario outlined here, the memcpy operations that
> follow will surely segfault.
thanks, I've resent.
> 3. There is another problem here: There is no check that the NAL unit is
> actually contained in the packet. A packet of size 10 bytes could contain a
> NAL unit with a size field indicating a size of (say) 1 GB and it would be
> allocated; it would not segfault, though, because the safe version of the
> bytestream2 API is used. (I think I already told you this, didn't I?)
Yes true, but I didn't make this problem. You are welcome to send the patch.
Thanks for looking over,
Andriy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 1/3] lavc/hevc_mp4toannexb: Fix integer overflow
On Wed, Dec 4, 2019 at 1:04 AM Andriy Gelman
wrote:
> From: Andriy Gelman
>
> Check packet grow size against INT_MAX instead of SIZE_MAX.
>
> Found with libFuzzer:
> 4294967044 cannot be represented as int.
>
> Signed-off-by: Andriy Gelman
> ---
> libavcodec/hevc_mp4toannexb_bsf.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/hevc_mp4toannexb_bsf.c
> b/libavcodec/hevc_mp4toannexb_bsf.c
> index 09bce5b34c2..bf4c25b3b7b 100644
> --- a/libavcodec/hevc_mp4toannexb_bsf.c
> +++ b/libavcodec/hevc_mp4toannexb_bsf.c
> @@ -66,7 +66,7 @@ static int hevc_extradata_to_annexb(AVBSFContext *ctx)
> for (j = 0; j < cnt; j++) {
> int nalu_len = bytestream2_get_be16(&gb);
>
> -if (4 + AV_INPUT_BUFFER_PADDING_SIZE + nalu_len > SIZE_MAX -
> new_extradata_size) {
> +if (4 + AV_INPUT_BUFFER_PADDING_SIZE + nalu_len > INT_MAX -
> new_extradata_size) {
>
There is actually FF_MAX_EXTRADATA_SIZE constant to limit the size of
extradata (it is chosen so small that one can parse the extradata via a
GetBitContext). (But honestly, it is not used consistently.)
> ret = AVERROR_INVALIDDATA;
> goto fail;
> }
> @@ -152,8 +152,8 @@ static int hevc_mp4toannexb_filter(AVBSFContext *ctx,
> AVPacket *out)
> extra_size= add_extradata * ctx->par_out->extradata_size;
> got_irap |= is_irap;
>
> -if (SIZE_MAX - nalu_size < 4 ||
> -SIZE_MAX - 4 - nalu_size < extra_size) {
> +if (INT_MAX < 4 + (uint64_t)nalu_size ||
>
The cast is unnecessary: INT_MAX - 4 < nalu_size does the same. And INT_MAX
- 4 can even be computed at compile-time.
> +INT_MAX - 4 < extra_size + (uint64_t)nalu_size) {
>
If you check that the extradata is not too big (namely <= INT_MAX - 4),
then you can simplify this to INT_MAX - 4 - extra_size < nalu_size. The
left side is positive, so it does not wrap around when converting it to
uint32_t. This makes the first check superfluous.
But it only checks for overflow, not for the scenario of a NAL unit
extending beyond the input packet.
ret = AVERROR_INVALIDDATA;
> goto fail;
> }
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] lavc/hevc_mp4toannexb: Fix interger overflow
On 12/3/2019 9:09 PM, Andriy Gelman wrote:
> On Tue, 03. Dec 23:30, Andreas Rheinhardt wrote:
>> On Tue, Dec 3, 2019 at 10:41 PM Andriy Gelman
>> wrote:
>>
>>> From: Andriy Gelman
>>>
>>> Check packet grow size against INT_MAX instead of SIZE_MAX.
>>>
>>> Found with libFuzzer:
>>> 4294967044 cannot be represented as int.
>>>
>>> Signed-off-by: Andriy Gelman
>>> ---
>>> libavcodec/hevc_mp4toannexb_bsf.c | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/libavcodec/hevc_mp4toannexb_bsf.c
>>> b/libavcodec/hevc_mp4toannexb_bsf.c
>>> index 09bce5b34c2..36fd6f0b15c 100644
>>> --- a/libavcodec/hevc_mp4toannexb_bsf.c
>>> +++ b/libavcodec/hevc_mp4toannexb_bsf.c
>>> @@ -152,8 +152,8 @@ static int hevc_mp4toannexb_filter(AVBSFContext *ctx,
>>> AVPacket *out)
>>> extra_size= add_extradata * ctx->par_out->extradata_size;
>>> got_irap |= is_irap;
>>>
>>> -if (SIZE_MAX - nalu_size < 4 ||
>>> -SIZE_MAX - 4 - nalu_size < extra_size) {
>>> +if (INT_MAX < 4 + nalu_size ||
>>> +INT_MAX - 4 < extra_size + nalu_size) {
>>> ret = AVERROR_INVALIDDATA;
>>> goto fail;
>>> }
>>> --
>>>
>>> 1. Typo in "Interger".
>
>> 2. You did not really fix the overflow problem: If nalu_size is (say)
>> UINT32_MAX, 4 + nalu_size is 3 (no undefined behaviour involved here) and
>> if extra_size is > 0 and <= INT_MAX - 4, then we don't go to fail here.
>> Your check merely ensures that (after possible (defined) overflow) 4 +
>> nalu_size + extra_size is >= 0 and <= INT_MAX, so that the automatic
>> conversion to int (the type of the parameter of av_grow_packet()) is
>> lossless. But in a scenario outlined here, the memcpy operations that
>> follow will surely segfault.
>
> thanks, I've resent.
>
>> 3. There is another problem here: There is no check that the NAL unit is
>> actually contained in the packet. A packet of size 10 bytes could contain a
>> NAL unit with a size field indicating a size of (say) 1 GB and it would be
>> allocated; it would not segfault, though, because the safe version of the
>> bytestream2 API is used. (I think I already told you this, didn't I?)
>
> Yes true, but I didn't make this problem. You are welcome to send the patch.
>
> Thanks for looking over,
> Andriy
For whatever reason, the new patchset you sent has
ffmpeg-devel@ffmpeg.org in the in-reply-to field, which makes clients
like mine attach it to some unrelated thread.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 3/3] lavc/hevc_mp4toannexb: Exit earlier if there is no nalu payload remaining
On Wed, Dec 4, 2019 at 1:04 AM Andriy Gelman
wrote:
> From: Andriy Gelman
>
> Since the nal unit payload is located after the length prefix, there is
> no reason to continue reading if there is no nal unit payload remaining.
> ---
> libavcodec/hevc_mp4toannexb_bsf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/hevc_mp4toannexb_bsf.c
> b/libavcodec/hevc_mp4toannexb_bsf.c
> index faf516634b2..c0968b63239 100644
> --- a/libavcodec/hevc_mp4toannexb_bsf.c
> +++ b/libavcodec/hevc_mp4toannexb_bsf.c
> @@ -136,7 +136,7 @@ static int hevc_mp4toannexb_filter(AVBSFContext *ctx,
> AVPacket *out)
>
> bytestream2_init(&gb, in->data, in->size);
>
> -while (bytestream2_get_bytes_left(&gb)) {
> +while (bytestream2_get_bytes_left(&gb) > s->length_size) {
>
So if there is some data left, you simply ignore it. It could also be
argued that this is invalid data.
(The packet you are dealing with here is padded btw, so you don't need to
worry about reading beyond the end when reading the size field; which
actually can't happen anyway, because the safe version of the bytestream
API is used throughout.)
> uint32_t nalu_size = 0;
> int nalu_type;
> int is_irap, add_extradata, extra_size, prev_size;
> --
> 2.24.0
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/3] avfilter/vf_convolution: add X86 SIMD for filter_column()
> -Original Message- > From: ffmpeg-devel On Behalf Of > chen > Sent: Tuesday, December 3, 2019 4:59 PM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH 3/3] avfilter/vf_convolution: add X86 > SIMD for filter_column() > > comments inline in code > > > At 2019-12-03 15:52:07, xuju...@sjtu.edu.cn wrote: > >From: Xu Jun [...] > >+ > >+cvtdq2ps m4, m4 > >+mulps m4, m0 ; sum *= rdiv > >+addps m4, m1 ; sum += bias > > >+addps m4, m5 ; sum += 0.5 > I don't know how about precision mismatch if we pre-compute (bias+0.5) I think it is hard to prove it is safe to do pre-compute. > > > >+cvttps2dq m4, m4 > >+packssdw m4, m4 > >+packuswb m4, m4 > >+movss [dstq + dst_offq], m4 > >+add c_offq, mmsize/4 > >+add dst_offq, mmsize/4 > >+ > >+add off16q, mmsize/4 > >+cmp off16q, widthq > >+jl .loop16 > >+ > >+add widthq, rq > >+cmp off16q, widthq > >+jge .paraend > >+ > > >+.loopr: > no idea about this loop, if we can read beyond, we can reuse above SIMD > code Reuse above SIMD code may write to the memory that does not belong to this slice-thread. IMO, the code to handle remainder columns is still necessary. Ruiling > > > >+xor sumd, sumd > >+xor iq, iq > >+.loopr_i: > >+mov ciq, [ptrq + iq * gprsize] > >+movzx rd, byte [ciq + c_offq] > >+imul rd, [matrixq + 4*iq] > >+add sumd, rd > >+ > >+add iq, 1 > >+cmp iq, radq > >+jl .loopr_i > >+ > >+pxor m4, m4 > >+cvtsi2ss m4, sumd > >+mulss m4, m0 ; sum *= rdiv > >+addss m4, m1 ; sum += bias > >+addss m4, m5 ; sum += 0.5 > >+cvttps2dq m4, m4 > >+packssdw m4, m4 > >+packuswb m4, m4 > >+movd sumd, m4 > >+mov [dstq + dst_offq], sumb > >+add c_offq, 1 > >+add dst_offq, 1 > >+add off16q, 1 > >+cmp off16q, widthq > >+jl .loopr > >+ > >+.paraend: > >+sub c_offq, widthq > >+sub dst_offq, widthq > >+add c_offq, strideq > >+add dst_offq, dstrideq > >+ > >+sub heightq, 1 > >+cmp heightq, 0 > >+jg .loopy > >+ > >+.end: > >+RET > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/3] avfilter/vf_convolution: add X86 SIMD for filter_column()
At 2019-12-04 08:59:08, "Song, Ruiling" wrote: >> -Original Message- >> From: ffmpeg-devel On Behalf Of >> chen >> Sent: Tuesday, December 3, 2019 4:59 PM >> To: FFmpeg development discussions and patches > de...@ffmpeg.org> >> Subject: Re: [FFmpeg-devel] [PATCH 3/3] avfilter/vf_convolution: add X86 >> SIMD for filter_column() >> >> comments inline in code >> >> >> At 2019-12-03 15:52:07, xuju...@sjtu.edu.cn wrote: >> >From: Xu Jun >[...] >> >+ >> >+cvtdq2ps m4, m4 >> >+mulps m4, m0 ; sum *= rdiv >> >+addps m4, m1 ; sum += bias >> >> >+addps m4, m5 ; sum += 0.5 >> I don't know how about precision mismatch if we pre-compute (bias+0.5) >I think it is hard to prove it is safe to do pre-compute. Agree, I also worried precision issue since float operator is execute order dependent. How about ROUNDPS? > >> >> >> >+cvttps2dq m4, m4 >> >+packssdw m4, m4 >> >+packuswb m4, m4 >> >+movss [dstq + dst_offq], m4 >> >+add c_offq, mmsize/4 >> >+add dst_offq, mmsize/4 >> >+ >> >+add off16q, mmsize/4 >> >+cmp off16q, widthq >> >+jl .loop16 >> >+ >> >+add widthq, rq >> >+cmp off16q, widthq >> >+jge .paraend >> >+ >> >> >+.loopr: >> no idea about this loop, if we can read beyond, we can reuse above SIMD >> code >Reuse above SIMD code may write to the memory that does not belong to this >slice-thread. >IMO, the code to handle remainder columns is still necessary. Depends on algorithm & size, For example width=23 Process #0 [0:15] Process #1 [7:22] Both of them is multiple of 16 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH V3 2/2] lavf/libsrt: enable other encryption parameters
On Tue, Dec 3, 2019 at 11:01 PM Michael Niedermayer
wrote:
>
> On Tue, Dec 03, 2019 at 06:57:27PM +0800, Jun Zhao wrote:
> > From: Jun Zhao
> >
> > Enable the SRTO_ENFORCEDENCRYPTION/SRTO_KMREFRESHRATE/
> > SRTO_KMPREANNOUNCE for srt encryption control.
> >
> > Signed-off-by: Jun Zhao
> > ---
> > doc/protocols.texi | 16
> > libavformat/libsrt.c | 18 ++
> > 2 files changed, 34 insertions(+), 0 deletions(-)
> >
> > diff --git a/doc/protocols.texi b/doc/protocols.texi
> > index eab6242..04f6e8b 100644
> > --- a/doc/protocols.texi
> > +++ b/doc/protocols.texi
> > @@ -1282,6 +1282,22 @@ only if @option{pbkeylen} is non-zero. It is used on
> > the receiver only if the received data is encrypted.
> > The configured passphrase cannot be recovered (write-only).
> >
> > +@item enforced_encryption=@var{1|0}
> > +If true, both connection parties must have the same password
> > +set (including empty, that is, with no encryption). If the
> > +password doesn't match or only one side is unencrypted,
> > +the connection is rejected. Default is true.
> > +
> > +@item kmrefreshrate=@var{n}
> > +The number of packets to be transmitted after which the
> > +encryption key is switched to a new key.
> > +
> > +@item kmpreannounce=@var{n}
> > +The interval between when a new encryption key is sent and
> > +when switchover occurs. This value also applies to the
> > +subsequent interval between when switchover occurs and
> > +when the old encryption key is decommissioned.
> > +
> > @item payload_size=@var{bytes}
> > Sets the maximum declared size of a packet transferred
> > during the single call to the sending function in Live
> > diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c
> > index 0a748a1..06f2c02 100644
> > --- a/libavformat/libsrt.c
> > +++ b/libavformat/libsrt.c
> > @@ -62,6 +62,9 @@ typedef struct SRTContext {
> > int64_t maxbw;
> > int pbkeylen;
> > char *passphrase;
> > +int enforced_encryption;
> > +int kmrefreshrate;
> > +int kmpreannounce;
> > int mss;
> > int ffs;
> > int ipttl;
>
> > @@ -102,6 +105,9 @@ static const AVOption libsrt_options[] = {
> > { "maxbw", "Maximum bandwidth (bytes per second) that the
> > connection can use", OFFSET(maxbw),AV_OPT_TYPE_INT64,{
> > .i64 = -1 }, -1, INT64_MAX, .flags = D|E },
> > { "pbkeylen", "Crypto key len in bytes {16,24,32} Default: 16
> > (128-bit)", OFFSET(pbkeylen), AV_OPT_TYPE_INT, {
> > .i64 = -1 }, -1, 32,.flags = D|E },
> > { "passphrase", "Crypto PBKDF2 Passphrase size[0,10..64] 0:disable
> > crypto", OFFSET(passphrase), AV_OPT_TYPE_STRING, { .str
> > = NULL }, .flags = D|E },
>
> > +{ "enforced_encryption", "Enforces that both connection parties
> > have the same passphrase set ", OFFSET(enforced_encryption),
> > AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 1, .flags = D|E },
>
> is this intended to be INT and not AV_OPT_TYPE_BOOL ?
Now -1 means auto (default value depend on libsrt library itself) ,
this is the reason don't use the AV_OPT_TYPE_BOOL same as other srt
option in FFmpeg.
>
>
>
> > +{ "kmrefreshrate", "The number of packets to be transmitted
> > after which the encryption key is switched to a new key",
> > OFFSET(kmrefreshrate), AV_OPT_TYPE_INT, { .i64 = -1 }, -1,
> > INT_MAX, .flags = D|E },
> > +{ "kmpreannounce", "The interval between when a new encryption
> > key is sent and when switchover occurs", OFFSET(kmpreannounce),
> > AV_OPT_TYPE_INT, { .i64 = -1 }, -1, INT_MAX, .flags = D|E },
> > { "mss","The Maximum Segment Size",
> > OFFSET(mss), AV_OPT_TYPE_INT, { .i64
> > = -1 }, -1, 1500, .flags = D|E },
> > { "ffs","Flight flag size (window size) (in bytes)",
> > OFFSET(ffs), AV_OPT_TYPE_INT, { .i64
> > = -1 }, -1, INT_MAX, .flags = D|E },
> > { "ipttl", "IP Time To Live",
> > OFFSET(ipttl),AV_OPT_TYPE_INT, { .i64
> > = -1 }, -1, 255, .flags = D|E },
>
> The added options are alot more randomly formated than the surrounding ones
Will change the format like others
>
>
> otherwise the patch should be good
>
> thx
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/3] avfilter/vf_convolution: add X86 SIMD for filter_column()
> -Original Message- > From: ffmpeg-devel On Behalf Of > chen > Sent: Wednesday, December 4, 2019 9:36 AM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH 3/3] avfilter/vf_convolution: add X86 > SIMD for filter_column() > > > > At 2019-12-04 08:59:08, "Song, Ruiling" wrote: > >> -Original Message- > >> From: ffmpeg-devel On Behalf Of > >> chen > >> Sent: Tuesday, December 3, 2019 4:59 PM > >> To: FFmpeg development discussions and patches >> de...@ffmpeg.org> > >> Subject: Re: [FFmpeg-devel] [PATCH 3/3] avfilter/vf_convolution: add X86 > >> SIMD for filter_column() > >> > >> comments inline in code > >> > >> > >> At 2019-12-03 15:52:07, xuju...@sjtu.edu.cn wrote: > >> >From: Xu Jun > >[...] > >> >+ > >> >+cvtdq2ps m4, m4 > >> >+mulps m4, m0 ; sum *= rdiv > >> >+addps m4, m1 ; sum += bias > >> > >> >+addps m4, m5 ; sum += 0.5 > >> I don't know how about precision mismatch if we pre-compute (bias+0.5) > > >I think it is hard to prove it is safe to do pre-compute. > Agree, I also worried precision issue since float operator is execute order > dependent. > How about ROUNDPS? Seems no exactly match. > > > > > >> > >> > >> >+cvttps2dq m4, m4 > >> >+packssdw m4, m4 > >> >+packuswb m4, m4 > >> >+movss [dstq + dst_offq], m4 > >> >+add c_offq, mmsize/4 > >> >+add dst_offq, mmsize/4 > >> >+ > >> >+add off16q, mmsize/4 > >> >+cmp off16q, widthq > >> >+jl .loop16 > >> >+ > >> >+add widthq, rq > >> >+cmp off16q, widthq > >> >+jge .paraend > >> >+ > >> > >> >+.loopr: > >> no idea about this loop, if we can read beyond, we can reuse above SIMD > >> code > >Reuse above SIMD code may write to the memory that does not belong to > this slice-thread. > > >IMO, the code to handle remainder columns is still necessary. > > > Depends on algorithm & size, > For example width=23 > Process #0 [0:15] > Process #1 [7:22] > Both of them is multiple of 16 Sounds interesting. But FFmpeg does not do like this now. One question is will this get a penalty for writing to same address of memory (both are writing to 7-15) from different threads? > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 1/3] lavc/hevc_mp4toannexb: Fix integer overflow
On Wed, 04. Dec 01:26, Andreas Rheinhardt wrote:
> On Wed, Dec 4, 2019 at 1:04 AM Andriy Gelman
> wrote:
>
> > From: Andriy Gelman
> >
> > Check packet grow size against INT_MAX instead of SIZE_MAX.
> >
> > Found with libFuzzer:
> > 4294967044 cannot be represented as int.
> >
> > Signed-off-by: Andriy Gelman
> > ---
> > libavcodec/hevc_mp4toannexb_bsf.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/libavcodec/hevc_mp4toannexb_bsf.c
> > b/libavcodec/hevc_mp4toannexb_bsf.c
> > index 09bce5b34c2..bf4c25b3b7b 100644
> > --- a/libavcodec/hevc_mp4toannexb_bsf.c
> > +++ b/libavcodec/hevc_mp4toannexb_bsf.c
> > @@ -66,7 +66,7 @@ static int hevc_extradata_to_annexb(AVBSFContext *ctx)
> > for (j = 0; j < cnt; j++) {
> > int nalu_len = bytestream2_get_be16(&gb);
> >
> > -if (4 + AV_INPUT_BUFFER_PADDING_SIZE + nalu_len > SIZE_MAX -
> > new_extradata_size) {
> > +if (4 + AV_INPUT_BUFFER_PADDING_SIZE + nalu_len > INT_MAX -
> > new_extradata_size) {
> >
>
> There is actually FF_MAX_EXTRADATA_SIZE constant to limit the size of
> extradata (it is chosen so small that one can parse the extradata via a
> GetBitContext). (But honestly, it is not used consistently.)
If we decide to use it should be a separate commit IMO.
>
>
> > ret = AVERROR_INVALIDDATA;
> > goto fail;
> > }
> > @@ -152,8 +152,8 @@ static int hevc_mp4toannexb_filter(AVBSFContext *ctx,
> > AVPacket *out)
> > extra_size= add_extradata * ctx->par_out->extradata_size;
> > got_irap |= is_irap;
> >
> > -if (SIZE_MAX - nalu_size < 4 ||
> > -SIZE_MAX - 4 - nalu_size < extra_size) {
> > +if (INT_MAX < 4 + (uint64_t)nalu_size ||
> >
>
> The cast is unnecessary: INT_MAX - 4 < nalu_size does the same. And INT_MAX
> - 4 can even be computed at compile-time.
>
>
> > +INT_MAX - 4 < extra_size + (uint64_t)nalu_size) {
> >
>
> If you check that the extradata is not too big (namely <= INT_MAX - 4),
> then you can simplify this to INT_MAX - 4 - extra_size < nalu_size. The
> left side is positive, so it does not wrap around when converting it to
> uint32_t. This makes the first check superfluous.
Yes, that's a good idea. And I think that extra_size <= INT_MAX - 4 always holds
because we pad extradata with AV_INPUT_PADDING_SIZE (and the checks are done in
the initialization). But I'll double check.
Thanks,
--
Andriy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH V2 2/2] libswscale/x86/yuv2rgb: add ssse3 version
> -Original Message- > From: ffmpeg-devel On Behalf Of > Michael Niedermayer > Sent: Tuesday, December 3, 2019 04:11 PM > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] [PATCH V2 2/2] libswscale/x86/yuv2rgb: add ssse3 > version > > On Mon, Dec 02, 2019 at 11:12:42AM +0800, Ting Fu wrote: > > Tested using this command: > > /ffmpeg -pix_fmt yuv420p -s 1920*1080 -i ArashRawYuv420.yuv \ -vcodec > > rawvideo -s 1920*1080 -pix_fmt rgb24 -f null /dev/null > > > > The fps increase from 389 to 640 on my local machine. > > > > Signed-off-by: Ting Fu > > --- > > libswscale/x86/yuv2rgb.c | 8 +- > > libswscale/x86/yuv2rgb_template.c | 58 ++- > > libswscale/x86/yuv_2_rgb.asm | 162 +++--- > > 3 files changed, 209 insertions(+), 19 deletions(-) > > one of these patches seems to produce new warnings like: > libswscale/x86/yuv2rgb_template.c: In function ‘yuv420_rgb15’: > libswscale/x86/yuv2rgb_template.c:113:5: warning: passing argument 5 of > ‘ff_yuv_420_rgb15_ssse3’ from > Hi Michael, This warning is because that the type of one formal parameter in ff_yuv_420_rgbXX_() has been set as uint8_t. But it is uint64_t actually. I have corrected it in PATCH V3. Thank you for your review, I would pay more attention to the warning. Ting Fu > > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > The real ebay dictionary, page 2 > "100% positive feedback" - "All either got their money back or didnt complain" > "Best seller ever, very honest" - "Seller refunded buyer after failed scam" ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH V3 1/2] libswscale/x86/yuv2rgb: Change inline assembly into nasm code
Tested using this command:
./ffmpeg -pix_fmt yuv420p -s 1920*1080 -i ArashRawYuv420.yuv \
-vcodec rawvideo -s 1920*1080 -pix_fmt rgb24 -f null /dev/null
The fps increase from 151 to 389 on my local machine.
Signed-off-by: Ting Fu
---
libswscale/x86/Makefile | 1 +
libswscale/x86/swscale.c | 16 +-
libswscale/x86/yuv2rgb.c | 81 +++---
libswscale/x86/yuv2rgb_template.c | 441 ++
libswscale/x86/yuv_2_rgb.asm | 270 ++
5 files changed, 395 insertions(+), 414 deletions(-)
create mode 100644 libswscale/x86/yuv_2_rgb.asm
diff --git a/libswscale/x86/Makefile b/libswscale/x86/Makefile
index f317d5dd9b..831d5359aa 100644
--- a/libswscale/x86/Makefile
+++ b/libswscale/x86/Makefile
@@ -12,3 +12,4 @@ X86ASM-OBJS += x86/input.o
\
x86/output.o \
x86/scale.o \
x86/rgb_2_rgb.o \
+ x86/yuv_2_rgb.o \
diff --git a/libswscale/x86/swscale.c b/libswscale/x86/swscale.c
index 0eed4f18d5..e9d474a1e8 100644
--- a/libswscale/x86/swscale.c
+++ b/libswscale/x86/swscale.c
@@ -29,6 +29,14 @@
#include "libavutil/cpu.h"
#include "libavutil/pixdesc.h"
+const DECLARE_ALIGNED(8, uint64_t, ff_dither4)[2] = {
+0x0103010301030103LL,
+0x0200020002000200LL,};
+
+const DECLARE_ALIGNED(8, uint64_t, ff_dither8)[2] = {
+0x0602060206020602LL,
+0x0004000400040004LL,};
+
#if HAVE_INLINE_ASM
#define DITHER1XBPP
@@ -38,14 +46,6 @@ DECLARE_ASM_CONST(8, uint64_t, bFC)=
0xFCFCFCFCFCFCFCFCLL;
DECLARE_ASM_CONST(8, uint64_t, w10)= 0x0010001000100010LL;
DECLARE_ASM_CONST(8, uint64_t, w02)= 0x0002000200020002LL;
-const DECLARE_ALIGNED(8, uint64_t, ff_dither4)[2] = {
-0x0103010301030103LL,
-0x0200020002000200LL,};
-
-const DECLARE_ALIGNED(8, uint64_t, ff_dither8)[2] = {
-0x0602060206020602LL,
-0x0004000400040004LL,};
-
DECLARE_ASM_CONST(8, uint64_t, b16Mask)= 0x001F001F001F001FLL;
DECLARE_ASM_CONST(8, uint64_t, g16Mask)= 0x07E007E007E007E0LL;
DECLARE_ASM_CONST(8, uint64_t, r16Mask)= 0xF800F800F800F800LL;
diff --git a/libswscale/x86/yuv2rgb.c b/libswscale/x86/yuv2rgb.c
index 5e2f77c20f..ed9b613cab 100644
--- a/libswscale/x86/yuv2rgb.c
+++ b/libswscale/x86/yuv2rgb.c
@@ -37,7 +37,7 @@
#include "libavutil/x86/cpu.h"
#include "libavutil/cpu.h"
-#if HAVE_INLINE_ASM
+#if HAVE_X86ASM
#define DITHER1XBPP // only for MMX
@@ -50,70 +50,51 @@ DECLARE_ASM_CONST(8, uint64_t, pb_03) =
0x0303030303030303ULL;
DECLARE_ASM_CONST(8, uint64_t, pb_07) = 0x0707070707070707ULL;
//MMX versions
-#if HAVE_MMX_INLINE && HAVE_6REGS
-#undef RENAME
+#if HAVE_MMX
#undef COMPILE_TEMPLATE_MMXEXT
#define COMPILE_TEMPLATE_MMXEXT 0
-#define RENAME(a) a ## _mmx
-#include "yuv2rgb_template.c"
-#endif /* HAVE_MMX_INLINE && HAVE_6REGS */
+#endif /* HAVE_MMX */
// MMXEXT versions
-#if HAVE_MMXEXT_INLINE && HAVE_6REGS
-#undef RENAME
+#if HAVE_MMXEXT
#undef COMPILE_TEMPLATE_MMXEXT
#define COMPILE_TEMPLATE_MMXEXT 1
-#define RENAME(a) a ## _mmxext
-#include "yuv2rgb_template.c"
-#endif /* HAVE_MMXEXT_INLINE && HAVE_6REGS */
+#endif /* HAVE_MMXEXT */
-#endif /* HAVE_INLINE_ASM */
+#include "yuv2rgb_template.c"
av_cold SwsFunc ff_yuv2rgb_init_x86(SwsContext *c)
{
-#if HAVE_MMX_INLINE && HAVE_6REGS
int cpu_flags = av_get_cpu_flags();
-#if HAVE_MMXEXT_INLINE
-if (INLINE_MMXEXT(cpu_flags)) {
-switch (c->dstFormat) {
-case AV_PIX_FMT_RGB24:
-return yuv420_rgb24_mmxext;
-case AV_PIX_FMT_BGR24:
-return yuv420_bgr24_mmxext;
-}
-}
-#endif
-
-if (INLINE_MMX(cpu_flags)) {
+if (EXTERNAL_MMX(cpu_flags) || EXTERNAL_MMXEXT(cpu_flags)) {
switch (c->dstFormat) {
-case AV_PIX_FMT_RGB32:
-if (c->srcFormat == AV_PIX_FMT_YUVA420P) {
-#if HAVE_7REGS && CONFIG_SWSCALE_ALPHA
-return yuva420_rgb32_mmx;
+case AV_PIX_FMT_RGB32:
+if (c->srcFormat == AV_PIX_FMT_YUVA420P) {
+#if CONFIG_SWSCALE_ALPHA
+return yuva420_rgb32;
#endif
-break;
-} else
-return yuv420_rgb32_mmx;
-case AV_PIX_FMT_BGR32:
-if (c->srcFormat == AV_PIX_FMT_YUVA420P) {
-#if HAVE_7REGS && CONFIG_SWSCALE_ALPHA
-return yuva420_bgr32_mmx;
+break;
+} else
+return yuv420_rgb32;
+case AV_PIX_FMT_BGR32:
+if (c->srcFormat == AV_PIX_FMT_YUVA420P) {
+#if CONFIG_SWSCALE_ALPHA
+return yuva420_bgr32;
#endif
-break;
-} else
-return yuv420_bgr32_mmx;
-case AV_PIX_FMT_RGB24:
-return yuv420_rgb24_mmx
[FFmpeg-devel] [PATCH V3 2/2] libswscale/x86/yuv2rgb: add ssse3 version
Tested using this command:
/ffmpeg -pix_fmt yuv420p -s 1920*1080 -i ArashRawYuv420.yuv \
-vcodec rawvideo -s 1920*1080 -pix_fmt rgb24 -f null /dev/null
The fps increase from 389 to 640 on my local machine.
Signed-off-by: Ting Fu
---
libswscale/x86/yuv2rgb.c | 8 +-
libswscale/x86/yuv2rgb_template.c | 58 ++-
libswscale/x86/yuv_2_rgb.asm | 162 +++---
3 files changed, 209 insertions(+), 19 deletions(-)
diff --git a/libswscale/x86/yuv2rgb.c b/libswscale/x86/yuv2rgb.c
index ed9b613cab..b83dd7089a 100644
--- a/libswscale/x86/yuv2rgb.c
+++ b/libswscale/x86/yuv2rgb.c
@@ -61,13 +61,19 @@ DECLARE_ASM_CONST(8, uint64_t, pb_07) =
0x0707070707070707ULL;
#define COMPILE_TEMPLATE_MMXEXT 1
#endif /* HAVE_MMXEXT */
+//SSSE3 versions
+#if HAVE_SSSE3
+#define COMPILE_TEMPLATE_SSSE3 1
+#endif
+
#include "yuv2rgb_template.c"
av_cold SwsFunc ff_yuv2rgb_init_x86(SwsContext *c)
{
int cpu_flags = av_get_cpu_flags();
-if (EXTERNAL_MMX(cpu_flags) || EXTERNAL_MMXEXT(cpu_flags)) {
+if (EXTERNAL_MMX(cpu_flags) || EXTERNAL_MMXEXT(cpu_flags) ||
+EXTERNAL_SSSE3(cpu_flags)) {
switch (c->dstFormat) {
case AV_PIX_FMT_RGB32:
if (c->srcFormat == AV_PIX_FMT_YUVA420P) {
diff --git a/libswscale/x86/yuv2rgb_template.c
b/libswscale/x86/yuv2rgb_template.c
index bcc8eb7602..97a3645b90 100644
--- a/libswscale/x86/yuv2rgb_template.c
+++ b/libswscale/x86/yuv2rgb_template.c
@@ -40,6 +40,30 @@
const uint8_t *pv = src[2] + (y >> vshift) * srcStride[2]; \
x86_reg index = -h_size / 2; \
+extern void ff_yuv_420_rgb24_ssse3(x86_reg index, uint8_t *image, const
uint8_t *pu_index,
+ const uint8_t *pv_index, const uint64_t
*pointer_c_dither,
+ const uint8_t *py_2index);
+extern void ff_yuv_420_bgr24_ssse3(x86_reg index, uint8_t *image, const
uint8_t *pu_index,
+ const uint8_t *pv_index, const uint64_t
*pointer_c_dither,
+ const uint8_t *py_2index);
+extern void ff_yuv_420_rgb15_ssse3(x86_reg index, uint8_t *image, const
uint8_t *pu_index,
+ const uint8_t *pv_index, const uint64_t
*pointer_c_dither,
+ const uint8_t *py_2index);
+extern void ff_yuv_420_rgb16_ssse3(x86_reg index, uint8_t *image, const
uint8_t *pu_index,
+ const uint8_t *pv_index, const uint64_t
*pointer_c_dither,
+ const uint8_t *py_2index);
+extern void ff_yuv_420_rgb32_ssse3(x86_reg index, uint8_t *image, const
uint8_t *pu_index,
+ const uint8_t *pv_index, const uint64_t
*pointer_c_dither,
+ const uint8_t *py_2index);
+extern void ff_yuv_420_bgr32_ssse3(x86_reg index, uint8_t *image, const
uint8_t *pu_index,
+ const uint8_t *pv_index, const uint64_t
*pointer_c_dither,
+ const uint8_t *py_2index);
+extern void ff_yuva_420_rgb32_ssse3(x86_reg index, uint8_t *image, const
uint8_t *pu_index,
+const uint8_t *pv_index, const uint64_t
*pointer_c_dither,
+const uint8_t *py_2index, const uint8_t
*pa_2index);
+extern void ff_yuva_420_bgr32_ssse3(x86_reg index, uint8_t *image, const
uint8_t *pu_index,
+const uint8_t *pv_index, const uint64_t
*pointer_c_dither,
+const uint8_t *py_2index, const uint8_t
*pa_2index);
extern void ff_yuv_420_rgb24_mmxext(x86_reg index, uint8_t *image, const
uint8_t *pu_index,
const uint8_t *pv_index, const uint64_t
*pointer_c_dither,
const uint8_t *py_2index);
@@ -84,7 +108,12 @@ static inline int yuv420_rgb15(SwsContext *c, const uint8_t
*src[],
c->greenDither = ff_dither8[y & 1];
c->redDither = ff_dither8[(y + 1) & 1];
#endif
+
+#if COMPILE_TEMPLATE_SSSE3
+ff_yuv_420_rgb15_ssse3(index, image, pu - index, pv - index,
&(c->redDither), py - 2 * index);
+#else
ff_yuv_420_rgb15_mmx(index, image, pu - index, pv - index,
&(c->redDither), py - 2 * index);
+#endif
}
return srcSliceH;
}
@@ -102,7 +131,12 @@ static inline int yuv420_rgb16(SwsContext *c, const
uint8_t *src[],
c->greenDither = ff_dither4[y & 1];
c->redDither = ff_dither8[(y + 1) & 1];
#endif
+
+#if COMPILE_TEMPLATE_SSSE3
+ff_yuv_420_rgb16_ssse3(index, image, pu - index, pv - index,
&(c->redDither), py - 2 * index);
+#else
ff_yuv_420_rgb16_mmx(index, image, pu - index, pv - index,
&(c->redDither), py - 2 * index);
+#endif
}
return srcSliceH;
}
@@ -115,7 +149,9 @@ static inline int yuv420_rgb24(SwsContext *c, const uint8_t
*src[],
Re: [FFmpeg-devel] [PATCH 1/2] libswscale/x86/yuv2rgb: Change inline assembly into nasm code
> -Original Message- > From: ffmpeg-devel On Behalf Of Carl > Eugen Hoyos > Sent: Tuesday, December 3, 2019 04:23 PM > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] [PATCH 1/2] libswscale/x86/yuv2rgb: Change inline > assembly into nasm code > > Am Di., 3. Dez. 2019 um 04:53 Uhr schrieb Fu, Ting : > > > > > > > > > -Original Message- > > > From: ffmpeg-devel On Behalf Of > > > Carl Eugen Hoyos > > > Sent: Monday, December 2, 2019 05:49 PM > > > To: FFmpeg development discussions and patches > > > > > > Subject: Re: [FFmpeg-devel] [PATCH 1/2] libswscale/x86/yuv2rgb: > > > Change inline assembly into nasm code > > > > > > Am Mo., 2. Dez. 2019 um 04:17 Uhr schrieb Fu, Ting : > > > > > > > > > > > > > > > > > -Original Message- > > > > > From: ffmpeg-devel On Behalf > > > > > Of Michael Niedermayer > > > > > Sent: Friday, November 29, 2019 05:33 AM > > > > > To: FFmpeg development discussions and patches > > > > > > > > > > Subject: Re: [FFmpeg-devel] [PATCH 1/2] libswscale/x86/yuv2rgb: > > > > > Change inline assembly into nasm code > > > > > > > > > > On Thu, Nov 28, 2019 at 02:07:07PM +0800, Ting Fu wrote: > > > > > > Signed-off-by: Ting Fu > > > > > > --- > > > > > > libswscale/x86/Makefile | 1 + > > > > > > libswscale/x86/swscale.c | 16 +- > > > > > > libswscale/x86/yuv2rgb.c | 81 ++ > > > > > > libswscale/x86/yuv2rgb_template.c | 441 > > > > > > ++ > > > > > > libswscale/x86/yuv_2_rgb.asm | 270 ++ > > > > > > 5 files changed, 394 insertions(+), 415 deletions(-) create > > > > > > mode > > > > > > 100644 libswscale/x86/yuv_2_rgb.asm > > > > > > > > > > This changes the output, i presume that is unintentional > > > > > > > > > > ./ffmpeg -cpuflags 0 -i matrixbench_mpeg2.mpg -t 1 -vf > > > > > format=yuv420p,format=rgb565le -an -f framecrc - > > > > > > > > > > 0, 0, 0,1, 829440, 0x1bd78b86 > > > > > 0, 1, 1,1, 829440, 0x85910b33 > > > > > ... > > > > > vs. > > > > > 0, 0, 0,1, 829440, 0x31f4a2bd > > > > > 0, 1, 1,1, 829440, 0xf0c66218 > > > > > ... > > > > > > > > > > > > > > > > > > Hi Michael, > > > > > > > > This unexpected change is because of the missing verify of current > > > > SIMD > > > support. > > > > So, when cpuflag=0, ffmpeg used mmx code to compute as default. > > > > I added if (EXTERNAL_XXX(cpu_flags)) to verify the SIMD in > > > libswscale/x86/yuv2rgb.c. > > > > > > Could the patch be split to make this change easier to understand? > > > > Hi Carl, > > > > I didn’t come across any good idea to separate the PATCH. > > Since the [PATCH 1/2] is consisted of mmx code for > yuv2rgb24/bgr24/rgb32/bgr32/rgb15/rgb16 and they're all come from former > inline assembly. > > Should it be separated into something like PATCH 1: mmx > > yuv2rgb24/bgr24 PATCH 2: mmx yuv2rgb32/bgr32 PATCH 3: mmx > > yuv2rgb15/rgb16 Or adding more comments in nasm file would be more > > helpful? > > > > Can you show me if there is any better solution? I cannot be more grateful > > to > it. > > I didn't want to imply that I know of a better way, just that your answer to > Michael's question made me wonder if adding EXTERNAL_XXX() in a separate > patch would fix his concern. Hi Carl, The EXTERNAL_XXX() is added to fix the bug of compute under "-cpuflags 0" condition. Without which the ffmpeg would use mmx code as default to compute unscale yuv2rgb part. So, in my opinion it is inconvenient to put it in a separate part. Plus, I have added more comments in the nasm file in PATCH V3. Hope it helps. Thank you so much for your review. Ting Fu > > Carl Eugen > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org > with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 3/3] lavc/hevc_mp4toannexb: Exit earlier if there is no nalu payload remaining
On Wed, 04. Dec 01:39, Andreas Rheinhardt wrote:
> On Wed, Dec 4, 2019 at 1:04 AM Andriy Gelman
> wrote:
>
> > From: Andriy Gelman
> >
> > Since the nal unit payload is located after the length prefix, there is
> > no reason to continue reading if there is no nal unit payload remaining.
> > ---
> > libavcodec/hevc_mp4toannexb_bsf.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/hevc_mp4toannexb_bsf.c
> > b/libavcodec/hevc_mp4toannexb_bsf.c
> > index faf516634b2..c0968b63239 100644
> > --- a/libavcodec/hevc_mp4toannexb_bsf.c
> > +++ b/libavcodec/hevc_mp4toannexb_bsf.c
> > @@ -136,7 +136,7 @@ static int hevc_mp4toannexb_filter(AVBSFContext *ctx,
> > AVPacket *out)
> >
> > bytestream2_init(&gb, in->data, in->size);
> >
> > -while (bytestream2_get_bytes_left(&gb)) {
> > +while (bytestream2_get_bytes_left(&gb) > s->length_size) {
> >
>
> So if there is some data left, you simply ignore it. It could also be
> argued that this is invalid data.
> (The packet you are dealing with here is padded btw, so you don't need to
> worry about reading beyond the end when reading the size field; which
> actually can't happen anyway, because the safe version of the bytestream
> API is used throughout.)
I suppose it would be invalid data.
If there are <= s->length_size bytes left then there is no nal unit payload and
there is no point to even parse nalu_size. Plus you avoid calling
av_grow_packet() an
extra time.
Thanks,
--
Andriy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v3] avfilter/buffersrc: deprecate sws_param option
From: Zhao Zhili
---
patch v3: document how to set the parameters for automatically inserted filters.
doc/filters.texi| 7 +++
libavfilter/buffersrc.c | 14 --
libavfilter/version.h | 5 -
3 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 5fdec6f015..7a700c7cc4 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -21014,9 +21014,8 @@ Specify the frame rate expected for the video stream.
The sample (pixel) aspect ratio of the input video.
@item sws_param
-Specify the optional parameters to be used for the scale filter which
-is automatically inserted when an input change is detected in the
-input size or format.
+This option is deprecated and ignored. Use
@ref{sws_flags,,sws_flags,ffmpeg-scaler}
+instead to specify swscale flags for those automatically inserted scalers.
@item hw_frames_ctx
When using a hardware pixel format, this should be a reference to an
@@ -21041,7 +21040,7 @@
buffer=size=320x240:pixfmt=6:time_base=1/24:pixel_aspect=1/1
Alternatively, the options can be specified as a flat string, but this
syntax is deprecated:
-@var{width}:@var{height}:@var{pix_fmt}:@var{time_base.num}:@var{time_base.den}:@var{pixel_aspect.num}:@var{pixel_aspect.den}[:@var{sws_param}]
+@var{width}:@var{height}:@var{pix_fmt}:@var{time_base.num}:@var{time_base.den}:@var{pixel_aspect.num}:@var{pixel_aspect.den}
@section cellauto
diff --git a/libavfilter/buffersrc.c b/libavfilter/buffersrc.c
index bae7d86695..73a7eb82ca 100644
--- a/libavfilter/buffersrc.c
+++ b/libavfilter/buffersrc.c
@@ -52,7 +52,9 @@ typedef struct BufferSourceContext {
int w, h;
enum AVPixelFormat pix_fmt;
AVRationalpixel_aspect;
+#if FF_API_SWS_PARAM_OPTION
char *sws_param;
+#endif
AVBufferRef *hw_frames_ctx;
@@ -287,10 +289,16 @@ static av_cold int init_video(AVFilterContext *ctx)
if (!(c->fifo = av_fifo_alloc(sizeof(AVFrame*
return AVERROR(ENOMEM);
-av_log(ctx, AV_LOG_VERBOSE, "w:%d h:%d pixfmt:%s tb:%d/%d fr:%d/%d
sar:%d/%d sws_param:%s\n",
+av_log(ctx, AV_LOG_VERBOSE, "w:%d h:%d pixfmt:%s tb:%d/%d fr:%d/%d
sar:%d/%d\n",
c->w, c->h, av_get_pix_fmt_name(c->pix_fmt),
c->time_base.num, c->time_base.den, c->frame_rate.num,
c->frame_rate.den,
- c->pixel_aspect.num, c->pixel_aspect.den, (char
*)av_x_if_null(c->sws_param, ""));
+ c->pixel_aspect.num, c->pixel_aspect.den);
+
+#if FF_API_SWS_PARAM_OPTION
+if (c->sws_param)
+av_log(ctx, AV_LOG_WARNING, "sws_param option is deprecated and
ignored\n");
+#endif
+
return 0;
}
@@ -312,7 +320,9 @@ static const AVOption buffer_options[] = {
{ "pixel_aspect", "sample aspect ratio",OFFSET(pixel_aspect),
AV_OPT_TYPE_RATIONAL, { .dbl = 0 }, 0, DBL_MAX, V },
{ "time_base", NULL, OFFSET(time_base),
AV_OPT_TYPE_RATIONAL, { .dbl = 0 }, 0, DBL_MAX, V },
{ "frame_rate",NULL, OFFSET(frame_rate),
AV_OPT_TYPE_RATIONAL, { .dbl = 0 }, 0, DBL_MAX, V },
+#if FF_API_SWS_PARAM_OPTION
{ "sws_param", NULL, OFFSET(sws_param),
AV_OPT_TYPE_STRING,.flags = V },
+#endif
{ NULL },
};
diff --git a/libavfilter/version.h b/libavfilter/version.h
index 7e8d849e0c..bf57d64d1f 100644
--- a/libavfilter/version.h
+++ b/libavfilter/version.h
@@ -31,7 +31,7 @@
#define LIBAVFILTER_VERSION_MAJOR 7
#define LIBAVFILTER_VERSION_MINOR 67
-#define LIBAVFILTER_VERSION_MICRO 100
+#define LIBAVFILTER_VERSION_MICRO 101
#define LIBAVFILTER_VERSION_INT AV_VERSION_INT(LIBAVFILTER_VERSION_MAJOR, \
@@ -59,6 +59,9 @@
#ifndef FF_API_FILTER_GET_SET
#define FF_API_FILTER_GET_SET (LIBAVFILTER_VERSION_MAJOR < 8)
#endif
+#ifndef FF_API_SWS_PARAM_OPTION
+#define FF_API_SWS_PARAM_OPTION (LIBAVFILTER_VERSION_MAJOR < 8)
+#endif
#ifndef FF_API_NEXT
#define FF_API_NEXT (LIBAVFILTER_VERSION_MAJOR < 8)
#endif
--
2.22.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avdevice/xcbgrab: Improve non-shm performance
On 2019-12-03 21:25:37 +0100, Marton Balint wrote: > > > On Tue, 3 Dec 2019, Kusanagi Kouichi wrote: > > > On 2019-11-19 22:59:56 +0900, Kusanagi Kouichi wrote: > > > Use AVBufferPool. > > You don't need a buffer pool for the non-shm case, you should wrap the XCB > data in a buffer ref instead. I will reply with a patch that shows how it is > done, please check if it works correctly, as I am not 100% sure how xcb data > structures should be allocated/freed. > Is it safe to omit AV_INPUT_BUFFER_PADDING_SIZE bytes padding? My first version is identical to yours. Valgrind reported no error. But I'm not sure. > What actually would benefit from a buffer pool is the SHM case. A pool of > SHM buffers which are wrapped in a buffer ref can avoid yet another memcpy. > Is the amount of SHM space that is usually available is limited or not? If > so, how much is the limit? Can we safely allocate at least 10-20 buffers? > > Regards, > Marton > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
