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 michae...@gmx.at --- 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] Fwd: Help with codecs
Fernandon Bautista fernandobautista017 at 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
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 andreas.cadhal...@googlemail.com 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 andreas.cadhal...@googlemail.com --- 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
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 andreas.cadhal...@googlemail.com --- 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
[FFmpeg-devel] [PATCH] aacdec: remove a duplicated line
got_frame_ptr is set again after the if block. Signed-off-by: Andreas Cadhalpun andreas.cadhal...@googlemail.com --- 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 michae...@gmx.at napisala je: Fixes: CID1197065 Signed-off-by: Michael Niedermayer michae...@gmx.at --- 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] 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 andreas.cadhal...@googlemail.com --- 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
[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 d...@dericed.com 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 @@ xsd:sequence xsd:element name=disposition type=ffprobe:streamDispositionType minOccurs=0 maxOccurs=1/ xsd:element name=tag type=ffprobe:tagType minOccurs=0 maxOccurs=unbounded/ - /xsd:sequence - xsd:sequence -xsd:element name=tag type=ffprobe:tagType minOccurs=0 maxOccurs=unbounded/ xsd:element name=side_data_list type=ffprobe:packetSideDataListType minOccurs=0 maxOccurs=1 / /xsd:sequence -- 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 d...@dericed.com 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 @@ xsd:complexType name=programVersionType xsd:attribute name=version type=xsd:string use=required/ xsd:attribute name=copyrighttype=xsd:string use=required/ + xsd:attribute name=build_date type=xsd:string/ + xsd:attribute name=build_time type=xsd:string/ xsd:attribute name=compiler_ident type=xsd:string use=required/ xsd:attribute name=configurationtype=xsd:string use=required/ /xsd:complexType -- 2.3.5 ___ 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 michae...@gmx.at --- 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
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 andreas.cadhal...@googlemail.com --- 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 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 msacheck_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 mimic adpcm_sbpro_3 dvdsub
Re: [FFmpeg-devel] [PATCH] ff_h[yc]scale_fast_mmext always clobbers %rbx
On 11 May 2015 at 16:18, Michael Niedermayer michae...@gmx.at wrote: On Mon, May 11, 2015 at 03:55:40PM -0700, Nick Lewycky wrote: On 8 May 2015 at 14:28, Michael Niedermayer michae...@gmx.at wrote: On Fri, May 08, 2015 at 12:43:20PM -0700, Nick Lewycky wrote: On 8 May 2015 at 12:06, Michael Niedermayer michae...@gmx.at wrote: On Fri, May 08, 2015 at 10:50:49AM -0700, Nick Lewycky wrote: On 6 May 2015 at 18:03, Michael Niedermayer michae...@gmx.at 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 contents. CALL_MMXEXT_FILTER_CODE moves RBX to ESI and calls mmxextFilterCode: movl(%%REG_b), %%esi \n\t\ call*%4\n\t\ // Crash... That callee ultimately segfaults: = 0x7fffefa45000: movq (%rdx,%rax,1),%mm3 = 0x7fffefa45004: movd (%rcx,%rsi,1),%mm0 Program received signal SIGSEGV, Segmentation fault. 0x7fffefa45004 in ?? () = 0x7fffefa45004: movd (%rcx,%rsi,1),%mm0 I'm trying to fix this segfault. also ideally changes to this code should be tested against gcc/clang/icc of various versions with and without PIC, 32 and 64 bit this code is more tricky than than the average so theres a good change changes to it will break
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 andreas.cadhal...@googlemail.com 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
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 msacheck_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
Re: [FFmpeg-devel] [PATCH 1/4] avutil: add av_format_option_for_user() callback system
James Almer jamrial at 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 AVOption to value 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
On Mon, May 11, 2015 at 6:41 AM, 周晓勇 zhouxiaoy...@loongson.cn wrote: From 3d5a9d0d38c96d6b6ec51b082102f3a231b5b881 Mon Sep 17 00:00:00 2001 From: ZhouXiaoyong zhouxiaoy...@loongson.cn 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 zhouxiaoy...@loongson.cn --- 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 zhouxiaoy...@loongson.cn + * + * 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 stdint.h + +#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 zhouxiaoy...@loongson.cn + *Zhang Shuangshuang zhangshuangshu...@ict.ac.cn + * + * 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 (n4) +level = block[0] * s-y_dc_scale; +else +level = block[0] * s-c_dc_scale; +
Re: [FFmpeg-devel] [PATCH 2/2] avcodec: optimize mpegvideo decoder for Loongson-3 v1
-原始邮件- 发件人: Carl Eugen Hoyos ceho...@ag.or.at 发送时间: 2015年5月12日 星期二 收件人: ffmpeg-devel@ffmpeg.org 抄送: 主题: Re: [FFmpeg-devel] [PATCH 2/2] avcodec: optimize mpegvideo decoder for Loongson-3 v1 周晓勇 zhouxiaoyong at 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 1/2] configure: disabled -mips64 option for loongson and remove redundant flags
-原始邮件- 发件人: Michael Niedermayer michae...@gmx.at 发送时间: 2015年5月12日 星期二 收件人: FFmpeg development discussions and patches ffmpeg-devel@ffmpeg.org 抄送: 主题: 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 michae...@gmx.at 发送时间: 2015年5月11日 星期一 收件人: FFmpeg development discussions and patches ffmpeg-devel@ffmpeg.org 抄送: 主题: 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 zhouxiaoy...@loongson.cn 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 zhouxiaoy...@loongson.cn --- 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
周晓勇 zhouxiaoyong at 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] 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 c...@passwd.hu --- 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] 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 c...@passwd.hu --- 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
[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 andreas.cadhal...@googlemail.com --- 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
[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 andreas.cadhal...@googlemail.com --- 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
Re: [FFmpeg-devel] [PATCH 2/2] cafdec: free extradata before allocating it
Andreas Cadhalpun andreas.cadhalpun at 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] [PATCH 1/2] cafdec: check avio_read return value
Andreas Cadhalpun andreas.cadhalpun at 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] 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 michae...@gmx.at napisala je: Fixes: CID1197065 Signed-off-by: Michael Niedermayer michae...@gmx.at --- 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] 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 andreas.cadhal...@googlemail.com 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 andreas.cadhal...@googlemail.com --- 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 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 andreas.cadhal...@googlemail.com 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 andreas.cadhal...@googlemail.com --- 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] 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 andreas.cadhal...@googlemail.com 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
[FFmpeg-devel] [PATCH] configure: disabled -mips64 option for loongson and remove redundant cpuflags
From 159cc99c2dc1cb4b68b48787cc53002cc7993c14 Mon Sep 17 00:00:00 2001 From: ZhouXiaoyong zhouxiaoy...@loongson.cn 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 msacheck_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
Re: [FFmpeg-devel] [PATCH]Tell users about -use_absolute_path
Stefano Sabatini stefasab at 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
Re: [FFmpeg-devel] [PATCH]Tell users about -use_absolute_path
On Tue, 12 May 2015 13:16:14 + (UTC) Carl Eugen Hoyos ceho...@ag.or.at wrote: Stefano Sabatini stefasab at 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 stefasab at 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] [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 andreas.cadhal...@googlemail.com 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 andreas.cadhal...@googlemail.com --- 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
[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 h.lepp...@gmail.com Date: Tue Apr 22 15:22:53 2014 +0200 avconv: add support for DXVA2 decoding Signed-off-by: Anton Khirnov an...@khirnov.net 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] [RFC] DXVA2 decoding and FFmpeg
On Tue, May 12, 2015 at 3:33 PM, Stefano Sabatini stefa...@gmail.com 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 h.lepp...@gmail.com Date: Tue Apr 22 15:22:53 2014 +0200 avconv: add support for DXVA2 decoding Signed-off-by: Anton Khirnov an...@khirnov.net 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