Re: [FFmpeg-devel] [PATCH] fate: Test pullup and fieldmatch with 5 instead of 1 frame

2015-05-12 Thread Clément Bœsch
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

2015-05-12 Thread Carl Eugen Hoyos
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]

2015-05-12 Thread Andreas Cadhalpun
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

2015-05-12 Thread Michael Niedermayer
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

2015-05-12 Thread Andreas Cadhalpun
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

2015-05-12 Thread Paul B Mahol
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

2015-05-12 Thread Andreas Cadhalpun
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]

2015-05-12 Thread Michael Niedermayer
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

2015-05-12 Thread Michael Niedermayer
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

2015-05-12 Thread Dave Rice
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

2015-05-12 Thread Dave Rice
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

2015-05-12 Thread Michael Niedermayer
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

2015-05-12 Thread Michael Niedermayer
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

2015-05-12 Thread 周晓勇
@@ -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

2015-05-12 Thread Nick Lewycky
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]

2015-05-12 Thread Michael Niedermayer
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

2015-05-12 Thread Michael Niedermayer
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

2015-05-12 Thread Carl Eugen Hoyos
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

2015-05-12 Thread Hendrik Leppkes
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

2015-05-12 Thread 周晓勇



 -原始邮件-
 发件人: 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

2015-05-12 Thread 周晓勇



 -原始邮件-
 发件人: 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

2015-05-12 Thread Carl Eugen Hoyos
周晓勇 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

2015-05-12 Thread Michael Niedermayer
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

2015-05-12 Thread Stefano Sabatini
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

2015-05-12 Thread Andreas Cadhalpun
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

2015-05-12 Thread Andreas Cadhalpun
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

2015-05-12 Thread Carl Eugen Hoyos
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

2015-05-12 Thread Carl Eugen Hoyos
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

2015-05-12 Thread Michael Niedermayer
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]

2015-05-12 Thread Andreas Cadhalpun
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]

2015-05-12 Thread Michael Niedermayer
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]

2015-05-12 Thread Andreas Cadhalpun
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

2015-05-12 Thread Stefano Sabatini
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

2015-05-12 Thread 周晓勇
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

2015-05-12 Thread Carl Eugen Hoyos
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

2015-05-12 Thread wm4
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

2015-05-12 Thread Stefano Sabatini
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]

2015-05-12 Thread Andreas Cadhalpun
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

2015-05-12 Thread Stefano Sabatini
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

2015-05-12 Thread Hendrik Leppkes
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