Re: [FFmpeg-devel] [PATCH] fate: Test pullup and fieldmatch with 5 instead of 1 frame
On Mon, May 11, 2015 at 12:59:57PM +0200, Michael Niedermayer wrote: > On Mon, May 11, 2015 at 07:34:11AM +0200, Clément Bœsch wrote: > > On Mon, May 11, 2015 at 12:44:14AM +0200, Michael Niedermayer wrote: > > > Signed-off-by: Michael Niedermayer > > > --- > > > tests/fate-run.sh|3 ++- > > > tests/fate/filter-video.mak |4 ++-- > > > tests/ref/fate/filter-pixfmts-fieldmatch | 10 +- > > > tests/ref/fate/filter-pixfmts-pullup | 24 > > > 4 files changed, 21 insertions(+), 20 deletions(-) > > > > > > > Hum, 5 frames test with telecine... I'd really go for more. > > ok, how many frames should we use ? > Dunno, maybe 15 to 25. BTW, I have the feeling that 5 frames is not really enough for testing a some of the other filters as well. The first two things that come to my mind are: - the filters that rely on perms=random might not have enough coverage on the permissions - the filters that use video samples might not come across interesting/appropriate frames (whether it's based on the content or the properties of frames such as P/B/I for pp filters) Fortunately, pixfmts and video_filter command seems not used that much. -- Clément B. pgpXaGZoTrKks.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] avutil: add av_format_option_for_user() callback system
James Almer gmail.com> writes: > If this is meant to solve the whole debate from the > "Tell users about -use_absolute_path" thread, then i > think it's a bit overkill. "Set to " > is generic enough that works in any situation, be it > for API user or ffmpeg.c Could you provide an actual wording, so I could finally commit the patch? Thanks, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avcodec: optimize mpegvideo decoder for Loongson-3 v1
周晓勇 loongson.cn> writes: > > why are the optimized functions and the code that > > sets them in the context in 2 seperate files ? > > this seems unneccesarily complicated > > > > i case mipstec optimize the same functions of > mpegvideodec using msa they could use filename > mpegviedo_mips.c and write init functions into > mpegvideo_init.c Separating init code and asm code is necessary if one is compiled with a C compiler, the other with yasm / nasm. In your case, putting asm and init code in one file makes everything easier. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] examples/demuxing_decoding: use correct size of video_dst_data[0]
On Mon, 11 May 2015 23:34:32 +0200
Andreas Cadhalpun wrote:
> Currently video_dst_bufsize is used, which is set to the return value
> of av_image_alloc, but this is the combined size of all planes.
> Only the first plane is written in fwrite.
>
> The size of the first plane is the product of video_dst_linesize[0] and
> height.
>
> This fixes 'Syscall param write(buf) points to uninitialised byte(s)'
> valgrind warnings.
>
> Signed-off-by: Andreas Cadhalpun
> ---
> doc/examples/demuxing_decoding.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/doc/examples/demuxing_decoding.c
> b/doc/examples/demuxing_decoding.c
> index feeeb96..81c8a92 100644
> --- a/doc/examples/demuxing_decoding.c
> +++ b/doc/examples/demuxing_decoding.c
> @@ -47,7 +47,6 @@ static FILE *audio_dst_file = NULL;
>
> static uint8_t *video_dst_data[4] = {NULL};
> static int video_dst_linesize[4];
> -static int video_dst_bufsize;
>
> static int video_stream_idx = -1, audio_stream_idx = -1;
> static AVFrame *frame = NULL;
> @@ -109,7 +108,7 @@ static int decode_packet(int *got_frame, int cached)
>pix_fmt, width, height);
>
> /* write to rawvideo file */
> -fwrite(video_dst_data[0], 1, video_dst_bufsize, video_dst_file);
> +fwrite(video_dst_data[0], 1, video_dst_linesize[0] * height,
> video_dst_file);
This would still write the line padding to the file, wouldn't it? This
means it wouldn't write the full frame, _and_ each line would have
garbage at the end of it.
(Also I can't make sense of these examples...)
> }
> } else if (pkt.stream_index == audio_stream_idx) {
> /* decode audio frame */
> @@ -290,7 +289,6 @@ int main (int argc, char **argv)
> fprintf(stderr, "Could not allocate raw video buffer\n");
> goto end;
> }
> -video_dst_bufsize = ret;
> }
>
> if (open_codec_context(&audio_stream_idx, fmt_ctx, AVMEDIA_TYPE_AUDIO)
> >= 0) {
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avcodec: optimize mpegvideo decoder for Loongson-3 v1
On Mon, May 11, 2015 at 6:41 AM, 周晓勇 wrote:
> From 3d5a9d0d38c96d6b6ec51b082102f3a231b5b881 Mon Sep 17 00:00:00 2001
> From: ZhouXiaoyong
> Date: Mon, 11 May 2015 09:27:00 +0800
> Subject: [PATCH 2/2] avcodec: optimize mpegvideo decoder for Loongson-3 v1
>
> Signed-off-by: ZhouXiaoyong
> ---
> libavcodec/mips/Makefile |4 +
> libavcodec/mips/mpegvideo_init.c | 44 +++
> libavcodec/mips/mpegvideo_loongson.c | 563
> ++
> libavcodec/mips/mpegvideo_loongson.h | 40 +++
> libavcodec/mpegvideo.c |2 +
> libavcodec/mpegvideo.h |1 +
> 6 files changed, 654 insertions(+), 0 deletions(-)
>
> diff --git a/libavcodec/mips/Makefile b/libavcodec/mips/Makefile
> index eaedd7f..c9b3294 100644
> --- a/libavcodec/mips/Makefile
> +++ b/libavcodec/mips/Makefile
> @@ -22,3 +22,7 @@ OBJS-$(CONFIG_HEVC_DECODER) +=
> mips/hevcdsp_init_mips.o
> OBJS-$(CONFIG_H264DSP)+= mips/h264dsp_init_mips.o
> MSA-OBJS-$(CONFIG_HEVC_DECODER) += mips/hevcdsp_msa.o
> MSA-OBJS-$(CONFIG_H264DSP)+= mips/h264dsp_msa.o
> +
> +#Loongson-3 SIMD Optimization
> +LOONGSON3-OBJS-$(CONFIG_MPEGVIDEO)+= mips/mpegvideo_init.o
> +LOONGSON3-OBJS-$(CONFIG_MPEGVIDEO)+= mips/mpegvideo_loongson.o
> diff --git a/libavcodec/mips/mpegvideo_init.c
> b/libavcodec/mips/mpegvideo_init.c
> new file mode 100644
> index 000..ba8c801
> --- /dev/null
> +++ b/libavcodec/mips/mpegvideo_init.c
> @@ -0,0 +1,44 @@
> +/*
> + * Loongson optimized mpegvideo
> + *
> + * Copyright (c) 2015 Loongson Technology Corporation Limited
> + * Copyright (c) 2015 Zhou Xiaoyong
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
> USA
> + */
> +
> +#include
> +
> +#include "config.h"
> +#include "libavutil/attributes.h"
> +#include "libavcodec/mpegvideo.h"
> +#include "mpegvideo_loongson.h"
> +
> +av_cold void ff_MPV_common_init_loongson(MpegEncContext *s)
> +{
> +s->dct_unquantize_h263_intra = ff_dct_unquantize_h263_intra_mmi;
> +s->dct_unquantize_h263_inter = ff_dct_unquantize_h263_inter_mmi;
> +s->dct_unquantize_mpeg1_intra = ff_dct_unquantize_mpeg1_intra_mmi;
> +s->dct_unquantize_mpeg1_inter = ff_dct_unquantize_mpeg1_inter_mmi;
> +
> +if (s->flags & CODEC_FLAG_BITEXACT) {
> +s->dct_unquantize_mpeg2_intra =
> ff_dct_unquantize_mpeg2_intra_bitexact_mmi;
> +}
> +
> +s->dct_unquantize_mpeg2_inter = ff_dct_unquantize_mpeg2_inter_mmi;
> +s->denoise_dct = ff_denoise_dct_mmi;
> +}
> diff --git a/libavcodec/mips/mpegvideo_loongson.c
> b/libavcodec/mips/mpegvideo_loongson.c
> new file mode 100644
> index 000..50a97f3
> --- /dev/null
> +++ b/libavcodec/mips/mpegvideo_loongson.c
> @@ -0,0 +1,563 @@
> +/*
> + * Loongson optimized mpegvideo
> + *
> + * Copyright (c) 2015 Loongson Technology Corporation Limited
> + * Copyright (c) 2015 Zhou Xiaoyong
> + *Zhang Shuangshuang
> + *
> + * 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 "mpegvideo_loongson.h"
> +
> +void ff_dct_unquantize_h263_intra_mmi(MpegEncContext *s, int16_t *block,
> +int n, int qscale)
> +{
> +int64_t level, qmul, qadd, nCoeffs;
> +
> +qmul = qscale << 1;
> +assert(s->block_last_index[n]>=0 || s->h263_aic);
> +
> +if (!s->h263_aic) {
> +if (n<4)
> +level = block[0] * s->y_dc_scale;
> +else
> +level = block[0] * s->c_dc_scale;
> +
Re: [FFmpeg-devel] [PATCH 1/2] configure: disabled -mips64 option for loongson and remove redundant flags
> -原始邮件- > 发件人: "Michael Niedermayer" > 发送时间: 2015年5月12日 星期二 > 收件人: "FFmpeg development discussions and patches" > 抄送: > 主题: Re: [FFmpeg-devel] [PATCH 1/2] configure: disabled -mips64 option for > loongson and remove redundant flags > > On Tue, May 12, 2015 at 10:32:19AM +0800, 周晓勇 wrote: > > > > > > > > > -原始邮件- > > > 发件人: "Michael Niedermayer" > > > 发送时间: 2015年5月11日 星期一 > > > 收件人: "FFmpeg development discussions and patches" > > > > > > 抄送: > > > 主题: Re: [FFmpeg-devel] [PATCH 1/2] configure: disabled -mips64 option for > > > loongson and remove redundant flags > > > > > > On Mon, May 11, 2015 at 12:38:46PM +0800, 周晓勇 wrote: > > > > From 9837274dcee5e1900160901cf28d883246a7ecfb Mon Sep 17 00:00:00 2001 > > > > From: Zhou Xiaoyong > > > > Date: Mon, 11 May 2015 03:28:52 -0400 > > > > Subject: [PATCH 1/2] configure: disabled -mips64 option for loongson > > > > and remove redundant flags > > > > > > > > 1.Option -march=loongson3a conflicts with -mips64 or -mips64r2. > > > > 2.Option -mhard-float has been added. > > > > > > > > Signed-off-by: Zhou Xiaoyong > > > > --- > > > > configure |5 + > > > > 1 files changed, 1 insertions(+), 4 deletions(-) > > > > > > > > diff --git a/configure b/configure > > > > index 1b41367..7716e66 100755 > > > > --- a/configure > > > > +++ b/configure > > > > @@ -3937,7 +3937,6 @@ elif enabled mips; then > > > > enable fast_cmov > > > > enable fast_unaligned > > > > disable aligned_stack > > > > -cpuflags="-march=$cpu" > > > > ;; > > > > generic) > > > > disable mips32r5 > > > > @@ -4691,7 +4690,7 @@ elif enabled mips; then > > > > if enabled mips64 && (enabled mipsdspr1 || enabled mipsdspr2); then > > > > add_cflags "-mips64r2" > > > > add_asflags "-mips64r2" > > > > -elif enabled mips64 && enabled mipsfpu; then > > > > +elif enabled mips64 && enabled mipsfpu && disabled loongson3; then > > > > > > this breaks build on mips: > > > CC libavcodec/ac3dec_fixed.o > > > In file included from ffmpeg/libavcodec/ac3dec_fixed.c:169: > > > ffmpeg/libavcodec/ac3dec.c: In function ‘ac3_decode_init’: > > > ffmpeg/libavcodec/ac3dec.c:213: warning: ‘request_channels’ is deprecated > > > (declared at ffmpeg/libavcodec/avcodec.h:2038) > > > ffmpeg/libavcodec/ac3dec.c:215: warning: ‘request_channels’ is deprecated > > > (declared at ffmpeg/libavcodec/avcodec.h:2038) > > > /tmp/ccgKabta.s: Assembler messages: > > > /tmp/ccgKabta.s:5229: Error: opcode not supported on this processor: > > > mips32r2 (mips32r2) `dmult $25,$24' > > > /tmp/ccgKabta.s:5231: Error: opcode not supported on this processor: > > > mips32r2 (mips32r2) `dsrl $25,$25,32' > > > > > > [...] > > > > > > > weird, i have no problem with this patch. all pass except some fate. > > ./configure --enable-gpl --cc='ccache gcc' --enable-pthreads > > --samples=/home/loongson/fate/ --enable-nonfree --enable-version3 > > --assert-level=2 --cpu=loongson3a > > above was cross build for non loongson MIPS > with mips-linux-gnu-gcc-4.4 (Debian 4.4.5-8) 4.4.5 > it works before the patch but not afterwards > > > after the patch > HAVE_LOONGSON3=yes > > [...] mips-linux-gnu-gcc-4.4 is not compatible with loongson OS FC-19, because the FC-19's API is O32. you could not use odd register of loongson cpu in O32 mode. i do the test of cross-build in my x86 using our cross-compiler gcc-4.8.3-d197-o32-loongson with configure below: ./configure --enable-gpl --enable-pthreads --samples=/home/coffeez/fate/ --enable-nonfree --enable-version3 --assert-level=2 --enable-cross-compile --target-os=linux --cc=/home/xuchenghua/toolchain/cross-tools/gcc-4.8.3-d197-o32-loongson/usr/bin/mips64el-redhat-linux-gcc --host-cc=/usr/bin/gcc --host-ld=/home/xuchenghua/toolchain/cross-tools/gcc-4.8.3-d197-o32-loongson/usr/bin/mips64el-redhat-linux-ld --arch=mips --cpu=loongson3a --disable-doc it pass all only at the end report ffserver error. why disable doc? it reported ld doc/print_option.o error. what configure do you use when cross build? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avcodec: optimize mpegvideo decoder for Loongson-3 v1
> -原始邮件- > 发件人: "Carl Eugen Hoyos" > 发送时间: 2015年5月12日 星期二 > 收件人: ffmpeg-devel@ffmpeg.org > 抄送: > 主题: Re: [FFmpeg-devel] [PATCH 2/2] avcodec: optimize mpegvideo decoder for > Loongson-3 v1 > > 周晓勇 loongson.cn> writes: > > > > why are the optimized functions and the code that > > > sets them in the context in 2 seperate files ? > > > this seems unneccesarily complicated > > > > > > > i case mipstec optimize the same functions of > > mpegvideodec using msa they could use filename > > mpegviedo_mips.c and write init functions into > > mpegvideo_init.c > > Separating init code and asm code is necessary if > one is compiled with a C compiler, the other with > yasm / nasm. In your case, putting asm and init > code in one file makes everything easier. > ok, i will repatch it. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fate: Test pullup and fieldmatch with 5 instead of 1 frame
On Tue, May 12, 2015 at 10:21:47AM +0200, Clément Bœsch wrote: > On Mon, May 11, 2015 at 12:59:57PM +0200, Michael Niedermayer wrote: > > On Mon, May 11, 2015 at 07:34:11AM +0200, Clément Bœsch wrote: > > > On Mon, May 11, 2015 at 12:44:14AM +0200, Michael Niedermayer wrote: > > > > Signed-off-by: Michael Niedermayer > > > > --- > > > > tests/fate-run.sh|3 ++- > > > > tests/fate/filter-video.mak |4 ++-- > > > > tests/ref/fate/filter-pixfmts-fieldmatch | 10 +- > > > > tests/ref/fate/filter-pixfmts-pullup | 24 > > > > > > > > 4 files changed, 21 insertions(+), 20 deletions(-) > > > > > > > > > > Hum, 5 frames test with telecine... I'd really go for more. > > > > ok, how many frames should we use ? > > > > Dunno, maybe 15 to 25. applied with that change > > BTW, I have the feeling that 5 frames is not really enough for testing a > some of the other filters as well. The first two things that come to my > mind are: > > - the filters that rely on perms=random might not have enough coverage on > the permissions > - the filters that use video samples might not come across > interesting/appropriate frames (whether it's based on the content or the > properties of frames such as P/B/I for pp filters) > > Fortunately, pixfmts and video_filter command seems not used that much. are there any more tests which need changes ? if so please change them or tell me which are affected Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB There will always be a question for which you do not know the correct answer. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] configure: disabled -mips64 option for loongson and remove redundant flags
On Tue, May 12, 2015 at 06:20:48PM +0800, 周晓勇 wrote: > > > > > -原始邮件- > > 发件人: "Michael Niedermayer" > > 发送时间: 2015年5月12日 星期二 > > 收件人: "FFmpeg development discussions and patches" > > 抄送: > > 主题: Re: [FFmpeg-devel] [PATCH 1/2] configure: disabled -mips64 option for > > loongson and remove redundant flags > > > > On Tue, May 12, 2015 at 10:32:19AM +0800, 周晓勇 wrote: > > > > > > > > > > > > > -原始邮件- > > > > 发件人: "Michael Niedermayer" > > > > 发送时间: 2015年5月11日 星期一 > > > > 收件人: "FFmpeg development discussions and patches" > > > > > > > > 抄送: > > > > 主题: Re: [FFmpeg-devel] [PATCH 1/2] configure: disabled -mips64 option > > > > for loongson and remove redundant flags > > > > > > > > On Mon, May 11, 2015 at 12:38:46PM +0800, 周晓勇 wrote: > > > > > From 9837274dcee5e1900160901cf28d883246a7ecfb Mon Sep 17 00:00:00 2001 > > > > > From: Zhou Xiaoyong > > > > > Date: Mon, 11 May 2015 03:28:52 -0400 > > > > > Subject: [PATCH 1/2] configure: disabled -mips64 option for loongson > > > > > and remove redundant flags > > > > > > > > > > 1.Option -march=loongson3a conflicts with -mips64 or -mips64r2. > > > > > 2.Option -mhard-float has been added. > > > > > > > > > > Signed-off-by: Zhou Xiaoyong > > > > > --- > > > > > configure |5 + > > > > > 1 files changed, 1 insertions(+), 4 deletions(-) > > > > > > > > > > diff --git a/configure b/configure > > > > > index 1b41367..7716e66 100755 > > > > > --- a/configure > > > > > +++ b/configure > > > > > @@ -3937,7 +3937,6 @@ elif enabled mips; then > > > > > enable fast_cmov > > > > > enable fast_unaligned > > > > > disable aligned_stack > > > > > -cpuflags="-march=$cpu" > > > > > ;; > > > > > generic) > > > > > disable mips32r5 > > > > > @@ -4691,7 +4690,7 @@ elif enabled mips; then > > > > > if enabled mips64 && (enabled mipsdspr1 || enabled mipsdspr2); > > > > > then > > > > > add_cflags "-mips64r2" > > > > > add_asflags "-mips64r2" > > > > > -elif enabled mips64 && enabled mipsfpu; then > > > > > +elif enabled mips64 && enabled mipsfpu && disabled loongson3; > > > > > then > > > > > > > > this breaks build on mips: > > > > CC libavcodec/ac3dec_fixed.o > > > > In file included from ffmpeg/libavcodec/ac3dec_fixed.c:169: > > > > ffmpeg/libavcodec/ac3dec.c: In function ‘ac3_decode_init’: > > > > ffmpeg/libavcodec/ac3dec.c:213: warning: ‘request_channels’ is > > > > deprecated (declared at ffmpeg/libavcodec/avcodec.h:2038) > > > > ffmpeg/libavcodec/ac3dec.c:215: warning: ‘request_channels’ is > > > > deprecated (declared at ffmpeg/libavcodec/avcodec.h:2038) > > > > /tmp/ccgKabta.s: Assembler messages: > > > > /tmp/ccgKabta.s:5229: Error: opcode not supported on this processor: > > > > mips32r2 (mips32r2) `dmult $25,$24' > > > > /tmp/ccgKabta.s:5231: Error: opcode not supported on this processor: > > > > mips32r2 (mips32r2) `dsrl $25,$25,32' > > > > > > > > [...] > > > > > > > > > > weird, i have no problem with this patch. all pass except some fate. > > > ./configure --enable-gpl --cc='ccache gcc' --enable-pthreads > > > --samples=/home/loongson/fate/ --enable-nonfree --enable-version3 > > > --assert-level=2 --cpu=loongson3a > > > > above was cross build for non loongson MIPS > > with mips-linux-gnu-gcc-4.4 (Debian 4.4.5-8) 4.4.5 > > it works before the patch but not afterwards > > > > > > after the patch > > HAVE_LOONGSON3=yes > > > > [...] > > mips-linux-gnu-gcc-4.4 is not compatible with loongson OS FC-19, because the > FC-19's API is O32. you could not use odd register of loongson cpu in O32 > mode. > i do the test of cross-build in my x86 using our cross-compiler > gcc-4.8.3-d197-o32-loongson with configure below: its build on x86 linux for imgtec MIPS, your patch breaks that [...] > what configure do you use when cross build? ./configure --cross-prefix=/usr/mips-linux-gnu/bin/ --cc='ccache mips-linux-gnu-gcc-4.4' --arch=mips --target-os=linux --enable-cross-compile && make -j12 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Republics decline into democracies and democracies degenerate into despotisms. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Fix flac with high lpc precision
On Wednesday 06 May 2015 09:27:22 am Carl Eugen Hoyos wrote:
> Hi!
>
> Attached is my attempt to fix ticket #4421 based on the
> analysis by trac user lvqcl. If the patch is ok,
> I will add the encoder check to the decoder and
> the version bump.
I failed to implement an autodetection.
Implementation of the option to force buggy decoding was
less straightforward than expected, two patches attached.
Please review, Carl Eugen
From b48b02f32538272b20abf99daf2fc5ce9fc26a48 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Tue, 12 May 2015 12:47:57 +0200
Subject: [PATCH 1/2] lavc/flacdec: Sanitize FLACSTREAMINFO usage.
---
libavcodec/flacdec.c | 83 --
1 file changed, 46 insertions(+), 37 deletions(-)
diff --git a/libavcodec/flacdec.c b/libavcodec/flacdec.c
index 34a0a70..00b4726 100644
--- a/libavcodec/flacdec.c
+++ b/libavcodec/flacdec.c
@@ -48,7 +48,7 @@
typedef struct FLACContext {
-FLACSTREAMINFO
+struct FLACStreaminfo flac_stream_info;
AVCodecContext *avctx; ///< parent AVCodecContext
GetBitContext gb; ///< GetBitContext initialized to
start at the current frame
@@ -70,7 +70,7 @@ static int allocate_buffers(FLACContext *s);
static void flac_set_bps(FLACContext *s)
{
enum AVSampleFormat req = s->avctx->request_sample_fmt;
-int need32 = s->bps > 16;
+int need32 = s->flac_stream_info.bps > 16;
int want32 = av_get_bytes_per_sample(req) > 2;
int planar = av_sample_fmt_is_planar(req);
@@ -79,13 +79,13 @@ static void flac_set_bps(FLACContext *s)
s->avctx->sample_fmt = AV_SAMPLE_FMT_S32P;
else
s->avctx->sample_fmt = AV_SAMPLE_FMT_S32;
-s->sample_shift = 32 - s->bps;
+s->sample_shift = 32 - s->flac_stream_info.bps;
} else {
if (planar)
s->avctx->sample_fmt = AV_SAMPLE_FMT_S16P;
else
s->avctx->sample_fmt = AV_SAMPLE_FMT_S16;
-s->sample_shift = 16 - s->bps;
+s->sample_shift = 16 - s->flac_stream_info.bps;
}
}
@@ -106,12 +106,13 @@ static av_cold int flac_decode_init(AVCodecContext *avctx)
return AVERROR_INVALIDDATA;
/* initialize based on the demuxer-supplied streamdata header */
-ff_flac_parse_streaminfo(avctx, (FLACStreaminfo *)s, streaminfo);
+ff_flac_parse_streaminfo(avctx, &s->flac_stream_info, streaminfo);
ret = allocate_buffers(s);
if (ret < 0)
return ret;
flac_set_bps(s);
-ff_flacdsp_init(&s->dsp, avctx->sample_fmt, s->channels, s->bps);
+ff_flacdsp_init(&s->dsp, avctx->sample_fmt,
+s->flac_stream_info.channels, s->flac_stream_info.bps);
s->got_streaminfo = 1;
return 0;
@@ -131,9 +132,10 @@ static int allocate_buffers(FLACContext *s)
int buf_size;
int ret;
-av_assert0(s->max_blocksize);
+av_assert0(s->flac_stream_info.max_blocksize);
-buf_size = av_samples_get_buffer_size(NULL, s->channels, s->max_blocksize,
+buf_size = av_samples_get_buffer_size(NULL, s->flac_stream_info.channels,
+ s->flac_stream_info.max_blocksize,
AV_SAMPLE_FMT_S32P, 0);
if (buf_size < 0)
return buf_size;
@@ -143,8 +145,10 @@ static int allocate_buffers(FLACContext *s)
return AVERROR(ENOMEM);
ret = av_samples_fill_arrays((uint8_t **)s->decoded, NULL,
- s->decoded_buffer, s->channels,
- s->max_blocksize, AV_SAMPLE_FMT_S32P, 0);
+ s->decoded_buffer,
+ s->flac_stream_info.channels,
+ s->flac_stream_info.max_blocksize,
+ AV_SAMPLE_FMT_S32P, 0);
return ret < 0 ? ret : 0;
}
@@ -168,12 +172,13 @@ static int parse_streaminfo(FLACContext *s, const uint8_t
*buf, int buf_size)
metadata_size != FLAC_STREAMINFO_SIZE) {
return AVERROR_INVALIDDATA;
}
-ff_flac_parse_streaminfo(s->avctx, (FLACStreaminfo *)s, &buf[8]);
+ff_flac_parse_streaminfo(s->avctx, &s->flac_stream_info, &buf[8]);
ret = allocate_buffers(s);
if (ret < 0)
return ret;
flac_set_bps(s);
-ff_flacdsp_init(&s->dsp, s->avctx->sample_fmt, s->channels, s->bps);
+ff_flacdsp_init(&s->dsp, s->avctx->sample_fmt,
+s->flac_stream_info.channels, s->flac_stream_info.bps);
s->got_streaminfo = 1;
return 0;
@@ -347,7 +352,7 @@ static inline int decode_subframe(FLACContext *s, int
channel)
{
int32_t *decoded = s->decoded[channel];
int type, wasted = 0;
-int bps = s->bps;
+int bps = s->flac_stream_info.bps;
int i, tmp, ret;
if (channel == 0) {
@@ -421,66 +426,69 @@ static int decode_frame(FLACContext *s)
return ret;
}
-if (s->channels && fi.channels != s->chann
Re: [FFmpeg-devel] [PATCH] lavf/img2dec: add option to disable pattern matching
On date Tuesday 2015-05-12 02:22:02 +0200, Marton Balint encoded:
> Signed-off-by: Marton Balint
> ---
> doc/demuxers.texi | 4
> libavformat/img2.h| 3 ++-
> libavformat/img2dec.c | 9 ++---
> libavformat/version.h | 2 +-
> 4 files changed, 13 insertions(+), 5 deletions(-)
>
> diff --git a/doc/demuxers.texi b/doc/demuxers.texi
> index 3f7c45e..b7ddebb 100644
> --- a/doc/demuxers.texi
> +++ b/doc/demuxers.texi
> @@ -258,6 +258,10 @@ Select the pattern type used to interpret the provided
> filename.
>
> @var{pattern_type} accepts one of the following values.
> @table @option
> +@item none
> +Disable pattern matching, therefore the video will only contain the specified
> +image. You should use this option if you do not want to create sequences from
> +multiple images and your filenames may contain special pattern characters.
> @item sequence
> Select a sequence pattern type, used to specify a sequence of files
> indexed by sequential numbers.
> diff --git a/libavformat/img2.h b/libavformat/img2.h
> index e4bcb26..f6b9dd9 100644
> --- a/libavformat/img2.h
> +++ b/libavformat/img2.h
> @@ -33,7 +33,8 @@
> enum PatternType {
> PT_GLOB_SEQUENCE,
> PT_GLOB,
> -PT_SEQUENCE
> +PT_SEQUENCE,
> +PT_NONE
> };
>
> typedef struct VideoDemuxData {
> diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c
> index ba29110..0830f00 100644
> --- a/libavformat/img2dec.c
> +++ b/libavformat/img2dec.c
> @@ -177,7 +177,7 @@ static int img_read_probe(AVProbeData *p)
> int ff_img_read_header(AVFormatContext *s1)
> {
> VideoDemuxData *s = s1->priv_data;
> -int first_index, last_index;
> +int first_index = 1, last_index = 1;
> AVStream *st;
> enum AVPixelFormat pix_fmt = AV_PIX_FMT_NONE;
>
> @@ -282,7 +282,7 @@ int ff_img_read_header(AVFormatContext *s1)
> "is not supported by this libavformat build\n");
> return AVERROR(ENOSYS);
> #endif
> -} else if (s->pattern_type != PT_GLOB_SEQUENCE) {
> +} else if (s->pattern_type != PT_GLOB_SEQUENCE && s->pattern_type !=
> PT_NONE) {
> av_log(s1, AV_LOG_ERROR,
> "Unknown value '%d' for pattern_type option\n",
> s->pattern_type);
> return AVERROR(EINVAL);
> @@ -377,7 +377,9 @@ int ff_img_read_packet(AVFormatContext *s1, AVPacket *pkt)
> }
> if (s->img_number > s->img_last)
> return AVERROR_EOF;
> -if (s->use_glob) {
> +if (s->pattern_type == PT_NONE) {
> +av_strlcpy(filename_bytes, s->path, sizeof(filename_bytes));
> +} else if (s->use_glob) {
> #if HAVE_GLOB
> filename = s->globstate.gl_pathv[s->img_number];
> #endif
> @@ -538,6 +540,7 @@ const AVOption ff_img_options[] = {
> { "glob_sequence","select glob/sequence pattern type", 0,
> AV_OPT_TYPE_CONST, {.i64=PT_GLOB_SEQUENCE}, INT_MIN, INT_MAX, DEC,
> "pattern_type" },
> { "glob", "select glob pattern type",0,
> AV_OPT_TYPE_CONST, {.i64=PT_GLOB }, INT_MIN, INT_MAX, DEC,
> "pattern_type" },
> { "sequence", "select sequence pattern type",0,
> AV_OPT_TYPE_CONST, {.i64=PT_SEQUENCE }, INT_MIN, INT_MAX, DEC,
> "pattern_type" },
> +{ "none", "disable pattern matching",0,
> AV_OPT_TYPE_CONST, {.i64=PT_NONE }, INT_MIN, INT_MAX, DEC,
> "pattern_type" },
>
> { "pixel_format", "set video pixel format",
> OFFSET(pixel_format), AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, DEC },
> { "start_number", "set first number in the sequence",
> OFFSET(start_number), AV_OPT_TYPE_INT,{.i64 = 0 }, INT_MIN, INT_MAX,
> DEC },
> diff --git a/libavformat/version.h b/libavformat/version.h
> index 071fe5d..e16d316 100644
> --- a/libavformat/version.h
> +++ b/libavformat/version.h
> @@ -31,7 +31,7 @@
>
> #define LIBAVFORMAT_VERSION_MAJOR 56
> #define LIBAVFORMAT_VERSION_MINOR 33
> -#define LIBAVFORMAT_VERSION_MICRO 100
> +#define LIBAVFORMAT_VERSION_MICRO 101
>
> #define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
> LIBAVFORMAT_VERSION_MINOR, \
LGTM.
--
FFmpeg = Fierce & Fostering Meaningless Portable Exuberant Giant
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/img2dec: add option to disable pattern matching
On Tue, May 12, 2015 at 01:26:56PM +0200, Stefano Sabatini wrote:
> On date Tuesday 2015-05-12 02:22:02 +0200, Marton Balint encoded:
> > Signed-off-by: Marton Balint
> > ---
> > doc/demuxers.texi | 4
> > libavformat/img2.h| 3 ++-
> > libavformat/img2dec.c | 9 ++---
> > libavformat/version.h | 2 +-
> > 4 files changed, 13 insertions(+), 5 deletions(-)
> >
> > diff --git a/doc/demuxers.texi b/doc/demuxers.texi
> > index 3f7c45e..b7ddebb 100644
> > --- a/doc/demuxers.texi
> > +++ b/doc/demuxers.texi
> > @@ -258,6 +258,10 @@ Select the pattern type used to interpret the provided
> > filename.
> >
> > @var{pattern_type} accepts one of the following values.
> > @table @option
> > +@item none
> > +Disable pattern matching, therefore the video will only contain the
> > specified
> > +image. You should use this option if you do not want to create sequences
> > from
> > +multiple images and your filenames may contain special pattern characters.
> > @item sequence
> > Select a sequence pattern type, used to specify a sequence of files
> > indexed by sequential numbers.
> > diff --git a/libavformat/img2.h b/libavformat/img2.h
> > index e4bcb26..f6b9dd9 100644
> > --- a/libavformat/img2.h
> > +++ b/libavformat/img2.h
> > @@ -33,7 +33,8 @@
> > enum PatternType {
> > PT_GLOB_SEQUENCE,
> > PT_GLOB,
> > -PT_SEQUENCE
> > +PT_SEQUENCE,
> > +PT_NONE
> > };
> >
> > typedef struct VideoDemuxData {
> > diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c
> > index ba29110..0830f00 100644
> > --- a/libavformat/img2dec.c
> > +++ b/libavformat/img2dec.c
> > @@ -177,7 +177,7 @@ static int img_read_probe(AVProbeData *p)
> > int ff_img_read_header(AVFormatContext *s1)
> > {
> > VideoDemuxData *s = s1->priv_data;
> > -int first_index, last_index;
> > +int first_index = 1, last_index = 1;
> > AVStream *st;
> > enum AVPixelFormat pix_fmt = AV_PIX_FMT_NONE;
> >
> > @@ -282,7 +282,7 @@ int ff_img_read_header(AVFormatContext *s1)
> > "is not supported by this libavformat build\n");
> > return AVERROR(ENOSYS);
> > #endif
> > -} else if (s->pattern_type != PT_GLOB_SEQUENCE) {
> > +} else if (s->pattern_type != PT_GLOB_SEQUENCE && s->pattern_type
> > != PT_NONE) {
> > av_log(s1, AV_LOG_ERROR,
> > "Unknown value '%d' for pattern_type option\n",
> > s->pattern_type);
> > return AVERROR(EINVAL);
> > @@ -377,7 +377,9 @@ int ff_img_read_packet(AVFormatContext *s1, AVPacket
> > *pkt)
> > }
> > if (s->img_number > s->img_last)
> > return AVERROR_EOF;
> > -if (s->use_glob) {
> > +if (s->pattern_type == PT_NONE) {
> > +av_strlcpy(filename_bytes, s->path, sizeof(filename_bytes));
> > +} else if (s->use_glob) {
> > #if HAVE_GLOB
> > filename = s->globstate.gl_pathv[s->img_number];
> > #endif
> > @@ -538,6 +540,7 @@ const AVOption ff_img_options[] = {
> > { "glob_sequence","select glob/sequence pattern type", 0,
> > AV_OPT_TYPE_CONST, {.i64=PT_GLOB_SEQUENCE}, INT_MIN, INT_MAX, DEC,
> > "pattern_type" },
> > { "glob", "select glob pattern type",0,
> > AV_OPT_TYPE_CONST, {.i64=PT_GLOB }, INT_MIN, INT_MAX, DEC,
> > "pattern_type" },
> > { "sequence", "select sequence pattern type",0,
> > AV_OPT_TYPE_CONST, {.i64=PT_SEQUENCE }, INT_MIN, INT_MAX, DEC,
> > "pattern_type" },
> > +{ "none", "disable pattern matching",0,
> > AV_OPT_TYPE_CONST, {.i64=PT_NONE }, INT_MIN, INT_MAX, DEC,
> > "pattern_type" },
> >
> > { "pixel_format", "set video pixel format",
> > OFFSET(pixel_format), AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, DEC },
> > { "start_number", "set first number in the sequence",
> > OFFSET(start_number), AV_OPT_TYPE_INT,{.i64 = 0 }, INT_MIN, INT_MAX,
> > DEC },
> > diff --git a/libavformat/version.h b/libavformat/version.h
> > index 071fe5d..e16d316 100644
> > --- a/libavformat/version.h
> > +++ b/libavformat/version.h
> > @@ -31,7 +31,7 @@
> >
> > #define LIBAVFORMAT_VERSION_MAJOR 56
> > #define LIBAVFORMAT_VERSION_MINOR 33
> > -#define LIBAVFORMAT_VERSION_MICRO 100
> > +#define LIBAVFORMAT_VERSION_MICRO 101
> >
> > #define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
> > LIBAVFORMAT_VERSION_MINOR, \
>
> LGTM.
applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] examples/demuxing_decoding: use correct size of video_dst_data[0]
On 12.05.2015 00:28, Michael Niedermayer wrote:
> this breaks demuxing_decoding with pixel formats that use more than
> 1 plane
>
> for example:
> doc/examples/demuxing_decoding lena255.jpg out.raw /dev/null
> Could not find audio stream in input file 'lena255.jpg'
> Input #0, image2, from 'lena255.jpg':
> Duration: 00:00:00.04, start: 0.00, bitrate: 3124 kb/s
> Stream #0:0: Video: mjpeg, yuvj444p(pc, bt470bg/unknown/unknown),
> 255x255, 25 tbr, 25 tbn, 25 tbc
> Demuxing video from file 'lena255.jpg' into 'out.raw'
> video_frame n:0 coded_n:0 pts:NOPTS
> Demuxing succeeded.
> Play the output video file with the command:
> ffplay -f rawvideo -pix_fmt yuvj444p -video_size 255x255 out.raw
>
> but the printed command line for ffplay does not work as the stored
> image is not containing teh chroma planes
I see. Attached is a patch that should fix the warnings without breaking
anything. (It's not exactly beautiful, but it works.)
Best regards,
Andreas
>From a52993c013dc2d64cd2f099fe472704fd2a75d6d Mon Sep 17 00:00:00 2001
From: Andreas Cadhalpun
Date: Tue, 12 May 2015 14:15:52 +0200
Subject: [PATCH] examples/demuxing_decoding: fully initialize the
video_dst_data buffer
av_image_fill_pointers always alignes the palette, but the padding bytes
don't (and can't) get initialized in av_image_copy.
Thus initialize them explicitly.
This fixes 'Syscall param write(buf) points to uninitialised byte(s)'
valgrind warnings.
Signed-off-by: Andreas Cadhalpun
---
doc/examples/demuxing_decoding.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/doc/examples/demuxing_decoding.c b/doc/examples/demuxing_decoding.c
index feeeb96..4678604 100644
--- a/doc/examples/demuxing_decoding.c
+++ b/doc/examples/demuxing_decoding.c
@@ -71,6 +71,7 @@ static int decode_packet(int *got_frame, int cached)
{
int ret = 0;
int decoded = pkt.size;
+const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(pix_fmt);
*got_frame = 0;
@@ -108,6 +109,14 @@ static int decode_packet(int *got_frame, int cached)
(const uint8_t **)(frame->data), frame->linesize,
pix_fmt, width, height);
+if ((desc->flags & AV_PIX_FMT_FLAG_PAL ||
+ desc->flags & AV_PIX_FMT_FLAG_PSEUDOPAL) &&
+video_dst_data[1] - video_dst_data[0] > video_dst_linesize[0] * height) {
+/* zero-initialize the padding before the palette */
+memset(video_dst_data[0] + video_dst_linesize[0] * height, 0,
+ video_dst_data[1] - video_dst_data[0] - video_dst_linesize[0] * height);
+}
+
/* write to rawvideo file */
fwrite(video_dst_data[0], 1, video_dst_bufsize, video_dst_file);
}
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] examples/demuxing_decoding: use correct size of video_dst_data[0]
On 12.05.2015 11:17, wm4 wrote: > On Mon, 11 May 2015 23:34:32 +0200 > Andreas Cadhalpun wrote: >> @@ -109,7 +108,7 @@ static int decode_packet(int *got_frame, int cached) >>pix_fmt, width, height); >> >> /* write to rawvideo file */ >> -fwrite(video_dst_data[0], 1, video_dst_bufsize, video_dst_file); >> +fwrite(video_dst_data[0], 1, video_dst_linesize[0] * height, >> video_dst_file); > > This would still write the line padding to the file, wouldn't it? It wouldn't, because the video_dst_data buffer has no line padding. (That's the only purpose of this buffer, see the comment above av_image_copy.) > This > means it wouldn't write the full frame, _and_ each line would have > garbage at the end of it. > > (Also I can't make sense of these examples...) This one is quite useful for fuzzing, because it has much less overhead than ffmpeg. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Tell users about -use_absolute_path
On date Friday 2015-05-08 13:25:17 +0200, Carl Eugen Hoyos encoded:
> Hi!
>
> Attached patch intends to make it more obvious what the user has
> to do to decode reference mov files.
>
> Please comment, Carl Eugen
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 54930a4..eaeb0d0 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -2648,6 +2648,11 @@ static int mov_open_dref(AVIOContext **pb, const char
> *src, MOVDref *ref,
> "this is a possible security issue\n");
> if (!avio_open2(pb, ref->path, AVIO_FLAG_READ, int_cb, NULL))
> return 0;
> +} else {
> +av_log(fc, AV_LOG_ERROR,
> + "Absolute path %s not tried for security reasons, "
> + "pass -use_absolute_path 1 to force using absolute paths\n",
set the use_absolute_path option to 1 to force using absolute paths.\n
If you want to be more specific:
set the use_absolute_path libavformat muxer option to 1 to force using
absolute paths.
--
FFmpeg = Funny & Freak MultiPurpose Earthshaking Ghost
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] examples/demuxing_decoding: use correct size of video_dst_data[0]
On Tue, May 12, 2015 at 02:31:38PM +0200, Andreas Cadhalpun wrote:
> On 12.05.2015 00:28, Michael Niedermayer wrote:
> > this breaks demuxing_decoding with pixel formats that use more than
> > 1 plane
> >
> > for example:
> > doc/examples/demuxing_decoding lena255.jpg out.raw /dev/null
> > Could not find audio stream in input file 'lena255.jpg'
> > Input #0, image2, from 'lena255.jpg':
> > Duration: 00:00:00.04, start: 0.00, bitrate: 3124 kb/s
> > Stream #0:0: Video: mjpeg, yuvj444p(pc, bt470bg/unknown/unknown),
> > 255x255, 25 tbr, 25 tbn, 25 tbc
> > Demuxing video from file 'lena255.jpg' into 'out.raw'
> > video_frame n:0 coded_n:0 pts:NOPTS
> > Demuxing succeeded.
> > Play the output video file with the command:
> > ffplay -f rawvideo -pix_fmt yuvj444p -video_size 255x255 out.raw
> >
> > but the printed command line for ffplay does not work as the stored
> > image is not containing teh chroma planes
>
> I see. Attached is a patch that should fix the warnings without breaking
> anything. (It's not exactly beautiful, but it works.)
>
> Best regards,
> Andreas
>
> demuxing_decoding.c |9 +
> 1 file changed, 9 insertions(+)
> ee1725417c3d550a65ba846e9195ded4ebdf4a3d
> 0001-examples-demuxing_decoding-fully-initialize-the-vide.patch
> From a52993c013dc2d64cd2f099fe472704fd2a75d6d Mon Sep 17 00:00:00 2001
> From: Andreas Cadhalpun
> Date: Tue, 12 May 2015 14:15:52 +0200
> Subject: [PATCH] examples/demuxing_decoding: fully initialize the
> video_dst_data buffer
>
> av_image_fill_pointers always alignes the palette, but the padding bytes
> don't (and can't) get initialized in av_image_copy.
>
> Thus initialize them explicitly.
>
> This fixes 'Syscall param write(buf) points to uninitialised byte(s)'
> valgrind warnings.
>
> Signed-off-by: Andreas Cadhalpun
> ---
> doc/examples/demuxing_decoding.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/doc/examples/demuxing_decoding.c
> b/doc/examples/demuxing_decoding.c
> index feeeb96..4678604 100644
> --- a/doc/examples/demuxing_decoding.c
> +++ b/doc/examples/demuxing_decoding.c
> @@ -71,6 +71,7 @@ static int decode_packet(int *got_frame, int cached)
> {
> int ret = 0;
> int decoded = pkt.size;
> +const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(pix_fmt);
>
> *got_frame = 0;
>
> @@ -108,6 +109,14 @@ static int decode_packet(int *got_frame, int cached)
>(const uint8_t **)(frame->data), frame->linesize,
>pix_fmt, width, height);
>
> +if ((desc->flags & AV_PIX_FMT_FLAG_PAL ||
> + desc->flags & AV_PIX_FMT_FLAG_PSEUDOPAL) &&
> +video_dst_data[1] - video_dst_data[0] >
> video_dst_linesize[0] * height) {
> +/* zero-initialize the padding before the palette */
> +memset(video_dst_data[0] + video_dst_linesize[0] * height, 0,
> + video_dst_data[1] - video_dst_data[0] -
> video_dst_linesize[0] * height);
> +}
i wonder if this shouldnt be moved to av_image_alloc() ?
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Tell users about -use_absolute_path
Stefano Sabatini gmail.com> writes: > > + "pass -use_absolute_path 1 to force using absolute paths\n", > set the use_absolute_path libavformat muxer > option to 1 to force using absolute paths. Ok with "use_absolute_path demuxer option"? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [RFC] DXVA2 decoding and FFmpeg
Hi guys, I'm playing with DXVA2 hardware decoding on Windows, and these are my findings. DVXA2 decoding was enabled in avconv/ffmpeg through the commit: commit 35177ba77ff60a8b8839783f57e44bcc4214507a Author: Hendrik Leppkes Date: Tue Apr 22 15:22:53 2014 +0200 avconv: add support for DXVA2 decoding Signed-off-by: Anton Khirnov DXVA2 decoding is enabled when a dxva2api.h header is found in the path. From my understanding the header is provided by VLC: http://download.videolan.org/pub/contrib/dxva2api.h (I suppose the header was created in order to make compilation work with MinGW). When compiling with MinGW from mingw.org I had to change the GetShellWindow call in the line: hr = IDirect3D9_CreateDevice(ctx->d3d9, adapter, D3DDEVTYPE_HAL, GetShellWindow(), D3DCREATE_SOFTWARE_VERTEXPROCESSING | D3DCREATE_MULTITHREADED | D3DCREATE_FPU_PRESERVE, &d3dpp, &ctx->d3d9device); to GetDesktopWindow in the ffmpeg_dxva2.c file. I applied the fix suggested here: http://ffmpeg.org/pipermail/libav-user/2014-December/007673.html Then I performed some tests with the command: ffmpeg -hwaccel dxva2 INPUT -threads 1 -f null - The -threads 1 option seems required or ffmpeg will fail with decoding errors. In the ffmpeg(1) manual I can read this big warning: Note that most acceleration methods are intended for playback and will not be faster than software decoding on modern CPUs. Additionally, ffmpeg will usually need to copy the decoded frames from the GPU memory into the system memory, resulting in further performance loss. This option is thus mainly useful for testing. I tested with several HW combinations, and I always find that pure software decoding is always several time faster than DXVA2 decoding. In some cases I got invalid output (same with VLC) which may be related to a problem in the graphics card or driver (a VIA VX900). On the other hand when testing with VLC I noticed better performances (in general, a significantly reduced usage of the CPU, usually of an order of 3), so I have to conclude that at least VLC is able to make good use of DXVA2 hardware acceleration. I'm aware that the need to copy GPU data back to the CPU memory as required by ffmpeg defeats the advantage (if any) of hardware decoding, especially given that multithreading decoding cannot be adopted with DXVA2. My questions are: There are some cases when DXVA2 (or in general HW decoding) can be used effectively in ffmpeg? Can you tell if there is something which could be improved in the current ffmpeg_dxva2.c implementation? (My guess is that this code is somehow based on the VLC code). Would it make sense to integrate DXVA2 decoding in ffplay.c, assuming it would be worth the effort, at least for testing/didactic purposes? Related resources: https://trac.ffmpeg.org/ticket/604 https://ffmpeg.org/pipermail/ffmpeg-user/2012-May/006600.html http://forum.doom9.org/showthread.php?t=170793 TIA for any comments. -- FFmpeg = Fostering and Fantastic Maxi Picky Erudite God ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Tell users about -use_absolute_path
On Tue, 12 May 2015 13:16:14 + (UTC) Carl Eugen Hoyos wrote: > Stefano Sabatini gmail.com> writes: > > > > + "pass -use_absolute_path 1 to force using absolute paths\n", > > > set the use_absolute_path libavformat muxer > > option to 1 to force using absolute paths. > > Ok with "use_absolute_path demuxer option"? I'd prefer "use_absolute_path libavformat option". (The ideal fix would be using the new open callback and implementing this in ffmpeg.c, where you can use native ffmpeg.c option syntax.) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Tell users about -use_absolute_path
On date Tuesday 2015-05-12 13:16:14 +, Carl Eugen Hoyos encoded: > Stefano Sabatini gmail.com> writes: > > > > + "pass -use_absolute_path 1 to force using absolute paths\n", > > > set the use_absolute_path libavformat muxer > > option to 1 to force using absolute paths. > > Ok with "use_absolute_path demuxer option"? Fine with me, thanks. -- FFmpeg = Faithful Fancy Multipurpose Perfectionist Exploitable Goblin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] DXVA2 decoding and FFmpeg
On Tue, May 12, 2015 at 3:33 PM, Stefano Sabatini wrote: > Hi guys, > > I'm playing with DXVA2 hardware decoding on Windows, and these are my > findings. > > DVXA2 decoding was enabled in avconv/ffmpeg through the commit: > > commit 35177ba77ff60a8b8839783f57e44bcc4214507a > Author: Hendrik Leppkes > Date: Tue Apr 22 15:22:53 2014 +0200 > > avconv: add support for DXVA2 decoding > > Signed-off-by: Anton Khirnov > > DXVA2 decoding is enabled when a dxva2api.h header is found in the > path. From my understanding the header is provided by VLC: > http://download.videolan.org/pub/contrib/dxva2api.h > > (I suppose the header was created in order to make compilation work > with MinGW). When compiling with MinGW from mingw.org I had to change > the GetShellWindow call in the line: > > hr = IDirect3D9_CreateDevice(ctx->d3d9, adapter, D3DDEVTYPE_HAL, > GetShellWindow(), > D3DCREATE_SOFTWARE_VERTEXPROCESSING | > D3DCREATE_MULTITHREADED | D3DCREATE_FPU_PRESERVE, > &d3dpp, &ctx->d3d9device); > > to GetDesktopWindow in the ffmpeg_dxva2.c file. I applied the fix > suggested here: > http://ffmpeg.org/pipermail/libav-user/2014-December/007673.html You should use mingw-w64, it provides both a dxva2api.h and can compile the code without any modifications. Using the "original" mingw32 is not recommended, and barely supported. > > Then I performed some tests with the command: > ffmpeg -hwaccel dxva2 INPUT -threads 1 -f null - > > The -threads 1 option seems required or ffmpeg will fail with decoding > errors. Indeed, multi-threading with hwaccel is not something that should be used, as it will break, although the API allows it for BS reasons. There wouldn't be a performance improvement either way. > > In the ffmpeg(1) manual I can read this big warning: > Note that most acceleration methods are intended for playback and > will not be faster than software decoding on modern > CPUs. Additionally, ffmpeg will usually need to copy the decoded > frames from the GPU memory into the system memory, resulting in > further performance loss. This option is thus mainly useful for > testing. > > I tested with several HW combinations, and I always find that pure > software decoding is always several time faster than DXVA2 > decoding. In some cases I got invalid output (same with VLC) which may > be related to a problem in the graphics card or driver (a VIA VX900). I don't think I've ever tested on such a chip. I didn't even know VIA still made PC hardware. Therefor,I have no idea how fast/slow or compatible it is. > > On the other hand when testing with VLC I noticed better performances > (in general, a significantly reduced usage of the CPU, usually of an > order of 3), so I have to conclude that at least VLC is able to make > good use of DXVA2 hardware acceleration. > > I'm aware that the need to copy GPU data back to the CPU memory as > required by ffmpeg defeats the advantage (if any) of hardware > decoding, especially given that multithreading decoding cannot be > adopted with DXVA2. > > My questions are: > > There are some cases when DXVA2 (or in general HW decoding) can be > used effectively in ffmpeg? Can you tell if there is something which > could be improved in the current ffmpeg_dxva2.c implementation? (My > guess is that this code is somehow based on the VLC code). Its not based on the VLC code, its roughly based on code from my own project that uses ffmpeg for DXVA2, but really, the workflow is going to be pretty similar in any implementation either way, since the MS API dictates that, more or less. DXVA2 decoding can be faster then software decoding, depending on your hardware. If you used a low-end Intel CPU, say a Pentium or i3 (Ivy or Haswell), or use a recent NVIDIA GPU (Kepler or Maxwell), then DXVA2 decoding on the GPU can potentially give you ~400 fps for 1080p, while the CPU will likely not manage that. On a high-end CPU, the software decoder can potentially exceed that, however. One limitation is as the manual said, it needs to be copied from the GPU to system memory. ffmpeg_dxva2.c does not implement a optimized copy function for this, it uses plain old memcpy. Intel introduced a new instruction for this in SSE4, MOVNTDQA, which is optimized for copying from USWC memory (Uncacheable Speculative Write Combining) to system memory. Using this may help speed up the process significantly, and VLC probably uses it. The original primary goal of this code was however to be able to test and debug the hwaccels much easier, and not directly to provide a playback/transcoding feature, so such optimizations were not performed for brevity. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] examples/demuxing_decoding: use correct size of video_dst_data[0]
On 12.05.2015 14:51, Michael Niedermayer wrote:
> On Tue, May 12, 2015 at 02:31:38PM +0200, Andreas Cadhalpun wrote:
>> @@ -108,6 +109,14 @@ static int decode_packet(int *got_frame, int cached)
>>(const uint8_t **)(frame->data), frame->linesize,
>>pix_fmt, width, height);
>>
>> +if ((desc->flags & AV_PIX_FMT_FLAG_PAL ||
>> + desc->flags & AV_PIX_FMT_FLAG_PSEUDOPAL) &&
>> +video_dst_data[1] - video_dst_data[0] >
>> video_dst_linesize[0] * height) {
>> +/* zero-initialize the padding before the palette */
>> +memset(video_dst_data[0] + video_dst_linesize[0] * height,
>> 0,
>> + video_dst_data[1] - video_dst_data[0] -
>> video_dst_linesize[0] * height);
>> +}
>
> i wonder if this shouldnt be moved to av_image_alloc() ?
It's a bit nicer to do this in av_image_fill_pointers.
New patch attached.
Best regards,
Andreas
>From 636d367e35363cb3388897aeded7d836d381cb11 Mon Sep 17 00:00:00 2001
From: Andreas Cadhalpun
Date: Tue, 12 May 2015 15:51:21 +0200
Subject: [PATCH] imgutils: initialize palette padding bytes in
av_image_fill_pointers
av_image_fill_pointers always aligns the palette, but the padding
bytes don't (and can't) get initialized in av_image_copy.
Thus initialize them in av_image_fill_pointers.
This fixes 'Syscall param write(buf) points to uninitialised byte(s)'
valgrind warnings.
Signed-off-by: Andreas Cadhalpun
---
libavutil/imgutils.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavutil/imgutils.c b/libavutil/imgutils.c
index a8bc18d..bef3390 100644
--- a/libavutil/imgutils.c
+++ b/libavutil/imgutils.c
@@ -125,7 +125,11 @@ int av_image_fill_pointers(uint8_t *data[4], enum AVPixelFormat pix_fmt, int hei
if (desc->flags & AV_PIX_FMT_FLAG_PAL ||
desc->flags & AV_PIX_FMT_FLAG_PSEUDOPAL) {
+i = size[0];
size[0] = (size[0] + 3) & ~3;
+/* zero-initialize the padding before the palette */
+if (data[0] && size[0] - i > 0)
+memset(data[0] + i, 0, size[0] - i);
data[1] = ptr + size[0]; /* palette is stored here as 256 32 bits words */
return size[0] + 256 * 4;
}
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Fwd: Help with codecs
Fernandon Bautista gmail.com> writes: > Along with these email I have attached an audio file If you want to help, please provide a useful sample. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter/vf_zoompan: free out AVFrame on failure
Fixes: CID1197065 Signed-off-by: Michael Niedermayer --- libavfilter/vf_zoompan.c |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/libavfilter/vf_zoompan.c b/libavfilter/vf_zoompan.c index d126851..c49193a 100644 --- a/libavfilter/vf_zoompan.c +++ b/libavfilter/vf_zoompan.c @@ -127,7 +127,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in) ZPContext *s = ctx->priv; double var_values[VARS_NB], nb_frames, zoom, dx, dy; const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(in->format); -AVFrame *out; +AVFrame *out = NULL; int i, k, x, y, w, h, ret = 0; var_values[VAR_IN_W] = var_values[VAR_IW] = in->width; @@ -232,6 +232,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in) ret = ff_filter_frame(outlink, out); if (ret < 0) break; +out = NULL; sws_freeContext(s->sws); s->sws = NULL; @@ -245,6 +246,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in) fail: sws_freeContext(s->sws); s->sws = NULL; +av_frame_free(&out); av_frame_free(&in); return ret; } -- 1.7.9.5 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] aacdec: don't return frames without data
Since commit 676a395a aac->frame->data is not necessarily allocated at
the end of aac_decode_frame_int if avctx->channels is 0.
In this case a bogus frame without any data, but non-zero nb_samples is
returned.
Signed-off-by: Andreas Cadhalpun
---
libavcodec/aacdec.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavcodec/aacdec.c b/libavcodec/aacdec.c
index d55df43..a405faf 100644
--- a/libavcodec/aacdec.c
+++ b/libavcodec/aacdec.c
@@ -3073,6 +3073,12 @@ static int aac_decode_frame_int(AVCodecContext *avctx,
void *data,
AV_WL32(side, 2*AV_RL32(side));
}
+if (!ac->frame->data[0] && samples) {
+av_log(avctx, AV_LOG_ERROR, "no frame data found\n");
+err = AVERROR_INVALIDDATA;
+goto fail;
+}
+
*got_frame_ptr = !!samples;
if (samples) {
ac->frame->nb_samples = samples;
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] examples/demuxing_decoding: use correct size of video_dst_data[0]
On Tue, May 12, 2015 at 04:02:44PM +0200, Andreas Cadhalpun wrote:
> On 12.05.2015 14:51, Michael Niedermayer wrote:
> > On Tue, May 12, 2015 at 02:31:38PM +0200, Andreas Cadhalpun wrote:
> >> @@ -108,6 +109,14 @@ static int decode_packet(int *got_frame, int cached)
> >>(const uint8_t **)(frame->data),
> >> frame->linesize,
> >>pix_fmt, width, height);
> >>
> >> +if ((desc->flags & AV_PIX_FMT_FLAG_PAL ||
> >> + desc->flags & AV_PIX_FMT_FLAG_PSEUDOPAL) &&
> >> +video_dst_data[1] - video_dst_data[0] >
> >> video_dst_linesize[0] * height) {
> >> +/* zero-initialize the padding before the palette */
> >> +memset(video_dst_data[0] + video_dst_linesize[0] *
> >> height, 0,
> >> + video_dst_data[1] - video_dst_data[0] -
> >> video_dst_linesize[0] * height);
> >> +}
> >
> > i wonder if this shouldnt be moved to av_image_alloc() ?
>
> It's a bit nicer to do this in av_image_fill_pointers.
yes but thats not safe
for example rawdec calls avpicture_fill() on the input buffer
which uses av_image_fill_pointers()
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
During times of universal deceit, telling the truth becomes a
revolutionary act. -- George Orwell
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Fwd: Help with codecs
On Tue, May 12, 2015 at 05:16:51PM +0200, Fernandon Bautista wrote: > Dear all, > > we have some audio files that we need to convert to WAVE audio, Microsoft > PCM, 16 bit, mono 8000 Hz format. They are encoded in a proprietary > software codec that it only runs on Windows. We need to process the audio > decoding in Linux servers and thus we need to find an alternative. > > Base on the provider, we expect the audios to be one of those codecs ( > http://www.shouldiremoveit.com/Verint-Multimedia-Support-Package-100067-program.aspx > ): > > g7231 > g726 > g729 > > We have tried all of them: > > ffmpeg -acodec g723_1 -i test.wav -acodec pcm_s16le -map 0 -f wav > test_out.wav > ffmpeg -acodec g726 -i test.wav -acodec pcm_s16le -map 0 -f wav > test_out.wav > ffmpeg -acodec g729 -i test.wav -acodec pcm_s16le -map 0 -f wav > test_out.wav > > without exit. > > Along with these email I have attached an audio file(which does not contain > any conversation because of privacy issues). We would really appreciate if > you could suggest any advice or direction. please provide a longer audio sample both the original with unknown compression and the decompressed by windows pcm Ideal may be a sine sweep and some diverse music also please dont attach large files but upload them somewhere and provide a link (see our bug reporting instructions if you dont know where to upload) Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are too smart to engage in politics are punished by being governed by those who are dumber. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] aacdec: don't return frames without data
On Tue, May 12, 2015 at 08:27:21PM +0200, Andreas Cadhalpun wrote: > Since commit 676a395a aac->frame->data is not necessarily allocated at > the end of aac_decode_frame_int if avctx->channels is 0. > > In this case a bogus frame without any data, but non-zero nb_samples is > returned. > > Signed-off-by: Andreas Cadhalpun > --- > libavcodec/aacdec.c | 6 ++ > 1 file changed, 6 insertions(+) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Into a blind darkness they enter who follow after the Ignorance, they as if into a greater darkness enter who devote themselves to the Knowledge alone. -- Isha Upanishad signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] examples/demuxing_decoding: use correct size of video_dst_data[0]
On 12.05.2015 21:12, Michael Niedermayer wrote:
> On Tue, May 12, 2015 at 04:02:44PM +0200, Andreas Cadhalpun wrote:
>> On 12.05.2015 14:51, Michael Niedermayer wrote:
>>> On Tue, May 12, 2015 at 02:31:38PM +0200, Andreas Cadhalpun wrote:
@@ -108,6 +109,14 @@ static int decode_packet(int *got_frame, int cached)
(const uint8_t **)(frame->data),
frame->linesize,
pix_fmt, width, height);
+if ((desc->flags & AV_PIX_FMT_FLAG_PAL ||
+ desc->flags & AV_PIX_FMT_FLAG_PSEUDOPAL) &&
+video_dst_data[1] - video_dst_data[0] >
video_dst_linesize[0] * height) {
+/* zero-initialize the padding before the palette */
+memset(video_dst_data[0] + video_dst_linesize[0] *
height, 0,
+ video_dst_data[1] - video_dst_data[0] -
video_dst_linesize[0] * height);
+}
>>>
>>> i wonder if this shouldnt be moved to av_image_alloc() ?
>>
>> It's a bit nicer to do this in av_image_fill_pointers.
>
> yes but thats not safe
>
> for example rawdec calls avpicture_fill() on the input buffer
> which uses av_image_fill_pointers()
OK, then let's do it in av_image_alloc.
Best regards,
Andreas
>From c244cba6812bcb15f871b72e721fc3310f6c983f Mon Sep 17 00:00:00 2001
From: Andreas Cadhalpun
Date: Tue, 12 May 2015 21:45:42 +0200
Subject: [PATCH] imgutils: initialize palette padding bytes in av_image_alloc
av_image_fill_pointers always aligns the palette, but the padding
bytes don't (and can't) get initialized in av_image_copy.
Thus initialize them in av_image_alloc.
This fixes 'Syscall param write(buf) points to uninitialised byte(s)'
valgrind warnings.
Signed-off-by: Andreas Cadhalpun
---
libavutil/imgutils.c | 8
1 file changed, 8 insertions(+)
diff --git a/libavutil/imgutils.c b/libavutil/imgutils.c
index a8bc18d..ef0e671 100644
--- a/libavutil/imgutils.c
+++ b/libavutil/imgutils.c
@@ -219,6 +219,14 @@ int av_image_alloc(uint8_t *pointers[4], int linesizes[4],
if (desc->flags & AV_PIX_FMT_FLAG_PAL || desc->flags & AV_PIX_FMT_FLAG_PSEUDOPAL)
avpriv_set_systematic_pal2((uint32_t*)pointers[1], pix_fmt);
+if ((desc->flags & AV_PIX_FMT_FLAG_PAL ||
+ desc->flags & AV_PIX_FMT_FLAG_PSEUDOPAL) &&
+pointers[1] - pointers[0] > linesizes[0] * h) {
+/* zero-initialize the padding before the palette */
+memset(pointers[0] + linesizes[0] * h, 0,
+ pointers[1] - pointers[0] - linesizes[0] * h);
+}
+
return ret;
}
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] aacdec: remove a duplicated line
got_frame_ptr is set again after the if block.
Signed-off-by: Andreas Cadhalpun
---
libavcodec/aacdec.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavcodec/aacdec.c b/libavcodec/aacdec.c
index a405faf..48cf637 100644
--- a/libavcodec/aacdec.c
+++ b/libavcodec/aacdec.c
@@ -3076,13 +3076,12 @@ static int aac_decode_frame_int(AVCodecContext *avctx,
void *data,
if (!ac->frame->data[0] && samples) {
av_log(avctx, AV_LOG_ERROR, "no frame data found\n");
err = AVERROR_INVALIDDATA;
goto fail;
}
-*got_frame_ptr = !!samples;
if (samples) {
ac->frame->nb_samples = samples;
ac->frame->sample_rate = avctx->sample_rate;
} else
av_frame_unref(ac->frame);
*got_frame_ptr = !!samples;
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vf_zoompan: free out AVFrame on failure
Dana 12. 5. 2015. 20:07 osoba "Michael Niedermayer" napisala je: > > Fixes: CID1197065 > > Signed-off-by: Michael Niedermayer > --- > libavfilter/vf_zoompan.c |4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/libavfilter/vf_zoompan.c b/libavfilter/vf_zoompan.c > index d126851..c49193a 100644 > --- a/libavfilter/vf_zoompan.c > +++ b/libavfilter/vf_zoompan.c > @@ -127,7 +127,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in) > ZPContext *s = ctx->priv; > double var_values[VARS_NB], nb_frames, zoom, dx, dy; > const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(in->format); > -AVFrame *out; > +AVFrame *out = NULL; > int i, k, x, y, w, h, ret = 0; > > var_values[VAR_IN_W] = var_values[VAR_IW] = in->width; > @@ -232,6 +232,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in) > ret = ff_filter_frame(outlink, out); > if (ret < 0) > break; > +out = NULL; > > sws_freeContext(s->sws); > s->sws = NULL; > @@ -245,6 +246,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in) > fail: > sws_freeContext(s->sws); > s->sws = NULL; > +av_frame_free(&out); > av_frame_free(&in); > return ret; > } > -- > 1.7.9.5 > LGTM > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] doc/ffprobe.xsd: remove extra sequence from streamType
I found that ffprobe.xsd could no longer validate records, this patch makes the xsd valid once again. Best Regards, Dave Rice >From f55d5dfd3a4980f6f86efee76d18453c7b534b2a Mon Sep 17 00:00:00 2001 From: Dave Rice Date: Tue, 12 May 2015 16:44:52 -0400 Subject: [PATCH] remove extra sequence from streamType This makes the XSD valid again. Fixes a regression from a72b61a. --- doc/ffprobe.xsd | 3 --- 1 file changed, 3 deletions(-) diff --git a/doc/ffprobe.xsd b/doc/ffprobe.xsd index d473c9b..dab55ee 100644 --- a/doc/ffprobe.xsd +++ b/doc/ffprobe.xsd @@ -170,9 +170,6 @@ - - - -- 2.3.5 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] doc/ffprobe.xsd: add build_date and build_time as optional attributes
This patch puts back two attributes that were removed in 7b35a01. If I understand correctly the intent of patch 7b35a01 was to no longer use build_date and build_time as attributes of programVersion, but the patch also had the effect of making all records generated with an earlier ffprobe build with build_date and build_time as invalid. This patch puts the two attributes back but without mandating their use, thus older ffprobe records as backwards compatible with the current schema and their use is no longer required. Best Regards, Dave Rice >From 7321e45ff04e5b97908c6525c929bb24363ed135 Mon Sep 17 00:00:00 2001 From: Dave Rice Date: Tue, 12 May 2015 16:52:55 -0400 Subject: [PATCH] doc/ffprobe.xsd: add build_date and build_time as optional attributes This partly undoes 7b35a01. --- doc/ffprobe.xsd | 2 ++ 1 file changed, 2 insertions(+) diff --git a/doc/ffprobe.xsd b/doc/ffprobe.xsd index d473c9b..ab65bd4 100644 --- a/doc/ffprobe.xsd +++ b/doc/ffprobe.xsd @@ -275,6 +275,8 @@ + + -- 2.3.5 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] cafdec: check avio_read return value
If avio_read fails, the buffer can contain uninitialized values.
Signed-off-by: Andreas Cadhalpun
---
libavformat/cafdec.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/libavformat/cafdec.c b/libavformat/cafdec.c
index e31c0a5..abbb353 100644
--- a/libavformat/cafdec.c
+++ b/libavformat/cafdec.c
@@ -129,7 +129,10 @@ static int read_kuki_chunk(AVFormatContext *s, int64_t
size)
avio_skip(pb, size);
return AVERROR_INVALIDDATA;
}
-avio_read(pb, preamble, ALAC_PREAMBLE);
+if (avio_read(pb, preamble, ALAC_PREAMBLE) != ALAC_PREAMBLE) {
+av_log(s, AV_LOG_ERROR, "failed to read preamble\n");
+return AVERROR_INVALIDDATA;
+}
if (ff_alloc_extradata(st->codec, ALAC_HEADER))
return AVERROR(ENOMEM);
@@ -144,14 +147,22 @@ static int read_kuki_chunk(AVFormatContext *s, int64_t
size)
av_freep(&st->codec->extradata);
return AVERROR_INVALIDDATA;
}
-avio_read(pb, st->codec->extradata, ALAC_HEADER);
+if (avio_read(pb, st->codec->extradata, ALAC_HEADER) !=
ALAC_HEADER) {
+av_log(s, AV_LOG_ERROR, "failed to read kuki header\n");
+av_freep(&st->codec->extradata);
+return AVERROR_INVALIDDATA;
+}
avio_skip(pb, size - ALAC_PREAMBLE - ALAC_HEADER);
} else {
AV_WB32(st->codec->extradata, 36);
memcpy(&st->codec->extradata[4], "alac", 4);
AV_WB32(&st->codec->extradata[8], 0);
memcpy(&st->codec->extradata[12], preamble, 12);
-avio_read(pb, &st->codec->extradata[24], ALAC_NEW_KUKI - 12);
+if (avio_read(pb, &st->codec->extradata[24], ALAC_NEW_KUKI - 12)
!= ALAC_NEW_KUKI - 12) {
+av_log(s, AV_LOG_ERROR, "failed to read new kuki header\n");
+av_freep(&st->codec->extradata);
+return AVERROR_INVALIDDATA;
+}
avio_skip(pb, size - ALAC_NEW_KUKI);
}
} else {
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] cafdec: free extradata before allocating it
This fixes a memleak if read_kuki_chunk is executed more than once.
Signed-off-by: Andreas Cadhalpun
---
libavformat/cafdec.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavformat/cafdec.c b/libavformat/cafdec.c
index abbb353..cc6ed0c 100644
--- a/libavformat/cafdec.c
+++ b/libavformat/cafdec.c
@@ -134,6 +134,7 @@ static int read_kuki_chunk(AVFormatContext *s, int64_t size)
return AVERROR_INVALIDDATA;
}
+av_freep(&st->codec->extradata);
if (ff_alloc_extradata(st->codec, ALAC_HEADER))
return AVERROR(ENOMEM);
@@ -166,6 +167,7 @@ static int read_kuki_chunk(AVFormatContext *s, int64_t size)
avio_skip(pb, size - ALAC_NEW_KUKI);
}
} else {
+av_freep(&st->codec->extradata);
if (ff_get_extradata(st->codec, pb, size) < 0)
return AVERROR(ENOMEM);
}
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] cafdec: check avio_read return value
Andreas Cadhalpun googlemail.com> writes: > If avio_read fails, the buffer can contain uninitialized values. Patch ok. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] cafdec: free extradata before allocating it
Andreas Cadhalpun googlemail.com> writes: > This fixes a memleak if read_kuki_chunk is executed more than once. LGTM. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Fwd: Help with codecs
Fernandon Bautista gmail.com> writes: > As you advised for me to do, along with this > email I have attached a couple of files more. I opened ticket #4553, thank you for the sample! Please remember not to top-post here, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vf_zoompan: free out AVFrame on failure
On Tue, May 12, 2015 at 10:12:11PM +0200, Paul B Mahol wrote: > Dana 12. 5. 2015. 20:07 osoba "Michael Niedermayer" > napisala je: > > > > Fixes: CID1197065 > > > > Signed-off-by: Michael Niedermayer > > --- > > libavfilter/vf_zoompan.c |4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > diff --git a/libavfilter/vf_zoompan.c b/libavfilter/vf_zoompan.c > > index d126851..c49193a 100644 > > --- a/libavfilter/vf_zoompan.c > > +++ b/libavfilter/vf_zoompan.c > > @@ -127,7 +127,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame > *in) > > ZPContext *s = ctx->priv; > > double var_values[VARS_NB], nb_frames, zoom, dx, dy; > > const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(in->format); > > -AVFrame *out; > > +AVFrame *out = NULL; > > int i, k, x, y, w, h, ret = 0; > > > > var_values[VAR_IN_W] = var_values[VAR_IW] = in->width; > > @@ -232,6 +232,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame > *in) > > ret = ff_filter_frame(outlink, out); > > if (ret < 0) > > break; > > +out = NULL; > > > > sws_freeContext(s->sws); > > s->sws = NULL; > > @@ -245,6 +246,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame > *in) > > fail: > > sws_freeContext(s->sws); > > s->sws = NULL; > > +av_frame_free(&out); > > av_frame_free(&in); > > return ret; > > } > > -- > > 1.7.9.5 > > > > LGTM applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The bravest are surely those who have the clearest vision of what is before them, glory and danger alike, and yet notwithstanding go out to meet it. -- Thucydides signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] aacdec: remove a duplicated line
On Tue, May 12, 2015 at 10:06:22PM +0200, Andreas Cadhalpun wrote: > got_frame_ptr is set again after the if block. > > Signed-off-by: Andreas Cadhalpun > --- > libavcodec/aacdec.c | 1 - > 1 file changed, 1 deletion(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is dangerous to be right in matters on which the established authorities are wrong. -- Voltaire signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ff_h[yc]scale_fast_mmext always clobbers %rbx
On 11 May 2015 at 16:18, Michael Niedermayer wrote: > On Mon, May 11, 2015 at 03:55:40PM -0700, Nick Lewycky wrote: > > On 8 May 2015 at 14:28, Michael Niedermayer wrote: > > > > > On Fri, May 08, 2015 at 12:43:20PM -0700, Nick Lewycky wrote: > > > > On 8 May 2015 at 12:06, Michael Niedermayer > wrote: > > > > > > > > > On Fri, May 08, 2015 at 10:50:49AM -0700, Nick Lewycky wrote: > > > > > > On 6 May 2015 at 18:03, Michael Niedermayer > > > wrote: > > > > > > > > > > > > > On Wed, May 06, 2015 at 04:08:09PM -0700, Nick Lewycky wrote: > > > > > > > > On 6 May 2015 at 15:06, Michael Niedermayer < > michae...@gmx.at> > > > > > wrote: > > > > > > > > > > > > > > > > > Hi > > > > > > > > > > > > > > > > > > On Wed, May 06, 2015 at 11:52:59AM -0700, Nick Lewycky > wrote: > > > > > > > > > > Newer versions of clang will allocate %rbx as one of the > > > inline > > > > > asm > > > > > > > > > inputs, > > > > > > > > > > > > > > > > > > Thats great > > > > > > > > > > > > > > > > > > > > > > > > > > > > even in PIC. This occurs when building ffmpeg with clang > > > > > > > > > -fsanitize=address > > > > > > > > > > -O1 -fPIE. Because the asm does clobber %bx whether PIC > is > > > on or > > > > > off, > > > > > > > > > just > > > > > > > > > > include %bx in the clobber list regardless of whether > PIC is > > > on > > > > > or > > > > > > > off. > > > > > > > > > > > > > > > > > > you cant include *bx in the clobber list with PIC > > > > > > > > > it breaks compilers that are less great, like gcc > > > > > > > > > > > > > > > > > > > > > > > > > Doh!! I did check for this, but only tried x86-64, not > x86-32. > > > Sorry! > > > > > > > > > > > > > > > > gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3 > > > > > > > > > ../libswscale/x86/hscale_fast_bilinear_simd.c: In function > > > > > > > > > ‘ff_hyscale_fast_mmxext’: > > > > > > > > > ../libswscale/x86/hscale_fast_bilinear_simd.c:205:5: > error: PIC > > > > > > > register > > > > > > > > > clobbered by ‘%ebx’ in ‘asm’ > > > > > > > > > ../libswscale/x86/hscale_fast_bilinear_simd.c: In function > > > > > > > > > ‘ff_hcscale_fast_mmxext’: > > > > > > > > > ../libswscale/x86/hscale_fast_bilinear_simd.c:276:5: > error: PIC > > > > > > > register > > > > > > > > > clobbered by ‘%ebx’ in ‘asm’ > > > > > > > > > > > > > > > > > > > > > > > > > > > also what exactly are you trying to fix ? > > > > > > > > > or rather what exactly goes how exactly wrong with the > code as > > > it > > > > > is > > > > > > > > > if rbx is used ? > > > > > > > > > > > > > > > > > > > > > > > > > Ok, let's look at ff_hcscale_fast_mmext. Preprocessor > directives > > > > > > > evaluated > > > > > > > > in PIC x86-64, the inline constraints work out to: > > > > > > > > > > > > > > > > :: "m" (src1), "m" (dst1), "m" (filter), "m" > (filterPos), > > > > > > > >"m" (mmxextFilterCode), "m" (src2), "m"(dst2) > > > > > > > > ,"m" (ebxsave) > > > > > > > > ,"m"(retsave) > > > > > > > > : "%"REG_a, "%"REG_c, "%"REG_d, "%"REG_S, "%"REG_D > > > > > > > > > > > > > > > > so clang looks at that and decides that it can pick src1 = > > > (%r10), > > > > > dst1 = > > > > > > > > (%r8), filter = (%r11), filterPos = (%r12), mmxextFilterCode > = > > > > > (%r15), > > > > > > > src2 > > > > > > > > = (%rbx), dst2 = (%r14), ebxsave = (%r13), retsave = (%r9). > The > > > > > problem > > > > > > > > there is src2 being (%rbx). > > > > > > > > > > > > > > > > Now let's look at how we use them: > > > > > > > > > > > > > > > > "mov %0, %%"REG_c" \n\t" > > > > > > > > "mov %1, %%"REG_D" \n\t" > > > > > > > > "mov %2, %%"REG_d" \n\t" > > > > > > > > "mov %3, %%"REG_b" \n\t" // > Clobbers > > > %rbx / > > > > > > > src2 > > > > > > > > / %5 here > > > > > > > > "xor %%"REG_a", %%"REG_a" \n\t" > > > > > > > > PREFETCH" (%%"REG_c") \n\t" > > > > > > > > PREFETCH" 32(%%"REG_c") \n\t" > > > > > > > > PREFETCH" 64(%%"REG_c") \n\t" > > > > > > > > > > > > > > > > CALL_MMXEXT_FILTER_CODE > > > > > > > > CALL_MMXEXT_FILTER_CODE > > > > > > > > CALL_MMXEXT_FILTER_CODE > > > > > > > > CALL_MMXEXT_FILTER_CODE > > > > > > > > "xor %%"REG_a", %%"REG_a" \n\t" > > > > > > > > "mov %5, %%"REG_c" \n\t" // %5 is > read > > > too > > > > > > > late, > > > > > > > > we get %3 / filterPos instead > > > > > > > > "mov %6, %%"REG_D" \n\t" > > > > > > > > PREFETCH" (%%"REG_c") \n\t" > > > > > > > > PREFETCH" 32(%%"REG_c") \n\t" > > > > > > > > PREFETCH" 64(%%"REG_c") \n\t" > > > > > > > > > > > > > > > > CALL_MMXEXT_FILTER_CODE // Crash... > > > > > > > > > > > > > > > > The two marked instructions are intended to refer to > different > > > > > content
Re: [FFmpeg-devel] [PATCH] examples/demuxing_decoding: use correct size of video_dst_data[0]
On Tue, May 12, 2015 at 09:48:45PM +0200, Andreas Cadhalpun wrote:
> On 12.05.2015 21:12, Michael Niedermayer wrote:
> > On Tue, May 12, 2015 at 04:02:44PM +0200, Andreas Cadhalpun wrote:
> >> On 12.05.2015 14:51, Michael Niedermayer wrote:
> >>> On Tue, May 12, 2015 at 02:31:38PM +0200, Andreas Cadhalpun wrote:
> @@ -108,6 +109,14 @@ static int decode_packet(int *got_frame, int cached)
> (const uint8_t **)(frame->data),
> frame->linesize,
> pix_fmt, width, height);
>
> +if ((desc->flags & AV_PIX_FMT_FLAG_PAL ||
> + desc->flags & AV_PIX_FMT_FLAG_PSEUDOPAL) &&
> +video_dst_data[1] - video_dst_data[0] >
> video_dst_linesize[0] * height) {
> +/* zero-initialize the padding before the palette */
> +memset(video_dst_data[0] + video_dst_linesize[0] *
> height, 0,
> + video_dst_data[1] - video_dst_data[0] -
> video_dst_linesize[0] * height);
> +}
> >>>
> >>> i wonder if this shouldnt be moved to av_image_alloc() ?
> >>
> >> It's a bit nicer to do this in av_image_fill_pointers.
> >
> > yes but thats not safe
> >
> > for example rawdec calls avpicture_fill() on the input buffer
> > which uses av_image_fill_pointers()
>
> OK, then let's do it in av_image_alloc.
>
> Best regards,
> Andreas
>
> imgutils.c |8
> 1 file changed, 8 insertions(+)
> d5adef96014b1b086bdebacf6301d2f8ed104625
> 0001-imgutils-initialize-palette-padding-bytes-in-av_imag.patch
> From c244cba6812bcb15f871b72e721fc3310f6c983f Mon Sep 17 00:00:00 2001
> From: Andreas Cadhalpun
> Date: Tue, 12 May 2015 21:45:42 +0200
> Subject: [PATCH] imgutils: initialize palette padding bytes in av_image_alloc
applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] configure: disabled -mips64 option for loongson and remove redundant flags
@@ -3937,7 +3937,6 @@ elif enabled mips; then enable fast_cmov enable fast_unaligned disable aligned_stack -cpuflags="-march=$cpu" ;; generic) disable mips32r5 @@ -4716,8 +4715,6 @@ elif enabled mips; then check_inline_asm mipsfpu '"madd.d $f0, $f2, $f4, $f6"' enabled msa && check_cflags "-mmsa" && check_ldflags "-mmsa" && check_inline_asm msa '"addvi.b $w0, $w1, 1"' -enabled loongson3 && add_cflags "-mhard-float" && add_asflags "-mhard-float" && -check_inline_asm loongson3 '"gsldxc1 $f0, 0($2, $3)"' enabled mips32r5 && add_asflags "-mips32r5 -mfp64" enabled mips64r6 && add_asflags "-mips64r6 -mfp64" they are redundant, so removed. @@ -4691,7 +4690,7 @@ elif enabled mips; then if enabled mips64 && (enabled mipsdspr1 || enabled mipsdspr2); then add_cflags "-mips64r2" add_asflags "-mips64r2" -elif enabled mips64 && enabled mipsfpu; then +elif enabled mips64 && enabled mipsfpu && disabled loongson3; then add_cflags "-mips64" add_asflags "-mips64" elif enabled mipsdspr1 || enabled mipsdspr2; then on 64bit OS(run the configure on Loongson CentOS6.4) the mips64 will be enabled, so if not added disabled loongson3 the flags -mips64 will be added. -mips64 conflicts with -march=loongson3a. do you need our cross compiler gcc-4.8.3-d197-o32-loongson to verify? my test has passed. ./configure --enable-gpl --enable-pthreads --samples=/home/coffeez/fate/ --enable-nonfree --enable-version3 --assert-level=2 --target-os=linux --cross-prefix='/home/xuchenghua/toolchain/cross-tools/gcc-4.8.3-d197-o32-loongson/usr/bin/' --cc='ccache mips64el-redhat-linux-gcc-4.8.3' --as='mips64el-redhat-linux-as' --ranlib='mips64el-redhat-linux-ranlib' --cxx='mips64el-redhat-linux-g++' --ar='mips64el-redhat-linux-ar' --nm='mips64el-redhat-linux-nm' --arch=mips --cpu=loongson3a --enable-doc --disable-stripping install prefix/usr/local source path . C compilerccache mips64el-redhat-linux-gcc-4.8.3 C library glibc host C compiler gcc host C libraryglibc ARCH mips (loongson3a) big-endianno runtime cpu detection yes MIPS FPU enabled yes MIPS32R5 enabled no MIPS64R6 enabled no MIPS DSP R1 enabled no MIPS DSP R2 enabled no MIPS MSA enabled no LOONGSON3 enabled yes debug symbols yes strip symbols no optimize for size no optimizations yes staticyes sharedno postprocessing supportyes new filter supportyes network support yes threading support pthreads safe bitstream reader yes SDL support no opencl enabledno texi2html enabled no perl enabled yes pod2man enabled yes makeinfo enabled yes makeinfo supports HTMLyes External libraries: iconv Enabled decoders: aac binkh263i aac_latmbinkaudio_dct h263p aascbinkaudio_rdft h264 ac3 bintext hevc ac3_fixed bmp hnm4_video adpcm_4xm bmv_audio hq_hqa adpcm_adx bmv_video hqx adpcm_afc brender_pix huffyuv adpcm_ctc93 iac adpcm_dtk cavsidcin adpcm_eaccaptionidf adpcm_ea_maxis_xa cdgraphics iff_byterun1 adpcm_ea_r1 cdxliff_ilbm adpcm_ea_r2 cinepak imc adpcm_ea_r3 cljrindeo2 adpcm_ea_xascllcindeo3 adpcm_g722 comfortnoiseindeo4 adpcm_g726 cookindeo5 adpcm_g726lecpiainterplay_dpcm adpcm_ima_amv cscdinterplay_video adpcm_ima_apc cyuvjacosub adpcm_ima_dk3 dca jpeg2000 adpcm_ima_dk4 dfa jpegls adpcm_ima_ea_eacs dirac jv adpcm_ima_ea_sead dnxhd kgv1 adpcm_ima_iss dpx kmvc adpcm_ima_oki dsd_lsbflagarith adpcm_ima_qtdsd_lsbf_planar loco adpcm_ima_rad dsd_msbfmace3 adpcm_ima_smjpegdsd_msbf_planar mace6 adpcm_ima_wav dsicinaudio mdec adpcm_ima_wsdsicinvideo metasound adpcm_msdss_sp microdvd adpcm_sbpro_2 dvbsub mimi
Re: [FFmpeg-devel] [PATCH 1/2] configure: disabled -mips64 option for loongson and remove redundant flags
On Wed, May 13, 2015 at 10:16:26AM +0800, 周晓勇 wrote: [...] > @@ -4716,8 +4715,6 @@ elif enabled mips; then > check_inline_asm mipsfpu '"madd.d $f0, $f2, $f4, $f6"' > enabled msa && check_cflags "-mmsa" && check_ldflags "-mmsa" && > check_inline_asm msa '"addvi.b $w0, $w1, 1"' > -enabled loongson3 && add_cflags "-mhard-float" && add_asflags > "-mhard-float" && > -check_inline_asm loongson3 '"gsldxc1 $f0, 0($2, $3)"' [...] the patch removes the code which disabled loongson3 so longson3 is enabled even on imgtec mips that is the patch breaks building for imgtec mips you can probably reproduce it with a cross compiler from http://emdebian.org/ [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The bravest are surely those who have the clearest vision of what is before them, glory and danger alike, and yet notwithstanding go out to meet it. -- Thucydides signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] configure: disabled -mips64 option for loongson and remove redundant cpuflags
>From 159cc99c2dc1cb4b68b48787cc53002cc7993c14 Mon Sep 17 00:00:00 2001 From: ZhouXiaoyong Date: Wed, 13 May 2015 12:33:30 +0800 Subject: [PATCH] configure: disabled -mips64 option for loongson and remove redundant cpuflags 1.Option -march=loongson3a conflicts with -mips64 or -mips64r2. 2.Option -mhard-float has been added. --- configure | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/configure b/configure index 3e304b0..2eada0e 100755 --- a/configure +++ b/configure @@ -3937,7 +3937,6 @@ elif enabled mips; then enable fast_cmov enable fast_unaligned disable aligned_stack -cpuflags="-march=$cpu" ;; generic) disable mips32r5 @@ -4691,7 +4690,7 @@ elif enabled mips; then if enabled mips64 && (enabled mipsdspr1 || enabled mipsdspr2); then add_cflags "-mips64r2" add_asflags "-mips64r2" -elif enabled mips64 && enabled mipsfpu; then +elif enabled mips64 && enabled mipsfpu && disabled loongson3; then add_cflags "-mips64" add_asflags "-mips64" elif enabled mipsdspr1 || enabled mipsdspr2; then @@ -4716,8 +4715,7 @@ elif enabled mips; then check_inline_asm mipsfpu '"madd.d $f0, $f2, $f4, $f6"' enabled msa && check_cflags "-mmsa" && check_ldflags "-mmsa" && check_inline_asm msa '"addvi.b $w0, $w1, 1"' -enabled loongson3 && add_cflags "-mhard-float" && add_asflags "-mhard-float" && -check_inline_asm loongson3 '"gsldxc1 $f0, 0($2, $3)"' +enabled loongson3 && check_inline_asm loongson3 '"gsldxc1 $f0, 0($2, $3)"' enabled mips32r5 && add_asflags "-mips32r5 -mfp64" enabled mips64r6 && add_asflags "-mips64r6 -mfp64" -- 2.1.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
