Re: [FFmpeg-devel] [PATCH] avcodec/mpegvideo: also export 0, 0 motion vectors

[Clément Bœsch]

On Mon, Jan 19, 2015 at 11:58:09PM +0100, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/mpegvideo.c  |2 --
>  tests/ref/fate/filter-codecview-mvs |   30 +++---
>  2 files changed, 15 insertions(+), 17 deletions(-)
> 
> diff --git a/libavcodec/mpegvideo.c b/libavcodec/mpegvideo.c
> index ce4fa59..6966572 100644
> --- a/libavcodec/mpegvideo.c
> +++ b/libavcodec/mpegvideo.c
> @@ -2138,8 +2138,6 @@ static int add_mb(AVMotionVector *mb, uint32_t mb_type,
>int src_x, int src_y,
>int direction)
>  {
> -if (dst_x == src_x && dst_y == src_y)
> -return 0;
>  mb->w = IS_8X8(mb_type) || IS_8X16(mb_type) ? 8 : 16;
>  mb->h = IS_8X8(mb_type) || IS_16X8(mb_type) ? 8 : 16;
>  mb->src_x = src_x;

OK I guess.

[...]

-- 
Clément B.


pgpOsAmiuvsLP.pgp
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Port mp=eq/eq2 to FFmpeg

[wm4]

On Thu, 22 Jan 2015 01:38:11 +0530
arwa arif  wrote:

> From 703cc1887903c2868537e19e99b76927bec07884 Mon Sep 17 00:00:00 2001
> From: Arwa Arif 
> Date: Mon, 19 Jan 2015 03:56:48 +0530
> Subject: [PATCH] Port mp=eq/eq2 to FFmpeg
> 
> Code adapted from James Darnley's previous commits

> [...]

> +#if HAVE_MMX && HAVE_6REGS
> +static void process_MMX(EQParameters *param, uint8_t *dst, int dst_stride,
> +uint8_t *src, int src_stride, int w, int h)
> +{
> +int i;
> +int pel;
> +int dstep = dst_stride - w;
> +int sstep = src_stride - w;
> +short brvec[4];
> +short contvec[4];
> +
> +brvec[0] = brvec[1] = brvec[2] = brvec[3] = param->b;
> +contvec[0] = contvec[1] = contvec[2] = contvec[3] = param->c;
> +
> +while (h--) {
> +__asm__ volatile (
> +"movq (%5), %%mm3  \n\t"
> +"movq (%6), %%mm4  \n\t"
> +"pxor %%mm0, %%mm0 \n\t"
> +"movl %4, %%eax\n\t"
> +//ASMALIGN(4)
> +"1:\n\t"
> +"movq (%0), %%mm1  \n\t"
> +"movq (%0), %%mm2  \n\t"
> +"punpcklbw %%mm0, %%mm1\n\t"
> +"punpckhbw %%mm0, %%mm2\n\t"
> +"psllw $4, %%mm1   \n\t"
> +"psllw $4, %%mm2   \n\t"
> +"pmulhw %%mm4, %%mm1   \n\t"
> +"pmulhw %%mm4, %%mm2   \n\t"
> +"paddw %%mm3, %%mm1\n\t"
> +"paddw %%mm3, %%mm2\n\t"
> +"packuswb %%mm2, %%mm1 \n\t"
> +"add $8, %0\n\t"
> +"movq %%mm1, (%1)  \n\t"
> +"add $8, %1\n\t"
> +"decl %%eax\n\t"
> +"jnz 1b\n\t"
> +: "=r" (src), "=r" (dst)
> +: "0" (src), "1" (dst), "r" (w>>3), "r" (brvec), "r" 
> (contvec)
> +: "%eax"
> +);
> +
> +for (i = w&7; i; i--) {
> +pel = ((*src++ * param->c) >> 12) + param->b;
> +if (pel & 768) 
> +pel = (-pel) >> 31;
> +*dst++ = pel;
> +}
> +
> +src += sstep;
> +dst += dstep;
> +}
> +__asm__ volatile ( "emms \n\t" ::: "memory" );
> +}
> +#endif

IMO the asm shouldn't be added at all. It's not important enough for a
ported video filter, but has high maintenance overhead - there's a
reason the FFmpeg loathes inline asm, right?

How much does the inline asm help with speed? When I tested it on a
reasonably modern CPU a while ago, there was barely any advantage.

> +av_cold void ff_eq_init_x86(EQContext *eq)
> +{
> +#if HAVE_MMX_INLINE
> +int cpu_flags = av_get_cpu_flags();
> +
> +if (cpu_flags & AV_CPU_FLAG_MMX) {
> +eq->process = process_MMX;
> +}
> +#endif
> +}

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavformat/img2dec: fix warning when !HAVE_GLOB

[Nicolas George]

Le duodi 2 pluviôse, an CCXXIII, Christophe Gisquet a écrit :
> the attached patch fixes a warning under MinGW (no idea about msys2).

return AVERROR(EATTACHMENTFORGOTTEN);

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/dashenc: fix format string generation

[Michael Niedermayer]

On Wed, Jan 21, 2015 at 09:36:53AM -0600, Rodger Combs wrote:
> ---
>  libavformat/dashenc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

applied

merged commit that changes it to PRId64

thanks

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [shan...@gmail.com: [libav-devel] Decoder for CEA-608 and World System Teletext]

[Michael Niedermayer]

On Thu, Jan 22, 2015 at 06:42:30AM +, Shan wrote:
> On 2015-01-20T11:52:39+0100 u...@pkh.me relayed:
> 
> > The patches are welcome though, it might be easier to
> > work with.
> 
> Here's a base64 patch for the  CEA-608, EIA-708, Teletext, DVB VBI and
> MXF VANC decoder, as well as some other related changes as well as
> support in mpegts for Fortis OEM recordings with no PAT.

[...]

> @@ -862,7 +865,7 @@
>  avio_w8(ctx->pb, stream->lpcm_header[0]);
>  avio_w8(ctx->pb, stream->lpcm_header[1]);
>  avio_w8(ctx->pb, stream->lpcm_header[2]);
> -} else if (id >= 0x40) {


> +} else if (id >= 0x40 && <= 0x90) {

This does not build

also thats not the only build failure:


libavformat/mpegtsenc.c: In function ‘mpegts_write_pmt’:
libavformat/mpegtsenc.c:532:13: error: invalid storage class for function 
‘putstr8’
libavformat/mpegtsenc.c:532:1: warning: ISO C90 forbids mixed declarations and 
code [-Wdeclaration-after-statement]
libavformat/mpegtsenc.c:548:13: error: invalid storage class for function 
‘mpegts_write_sdt’
libavformat/mpegtsenc.c:586:23: error: invalid storage class for function 
‘mpegts_add_service’
libavformat/mpegtsenc.c:613:16: error: invalid storage class for function 
‘get_pcr’
libavformat/mpegtsenc.c:619:13: error: invalid storage class for function 
‘mpegts_prefix_m2ts_header’
libavformat/mpegtsenc.c:631:13: error: invalid storage class for function 
‘section_write_packet’
libavformat/mpegtsenc.c:638:12: error: invalid storage class for function 
‘mpegts_write_header’
libavformat/mpegtsenc.c:871:13: error: invalid storage class for function 
‘retransmit_si_info’
libavformat/mpegtsenc.c:888:12: error: invalid storage class for function 
‘write_pcr_bits’
libavformat/mpegtsenc.c:903:13: error: invalid storage class for function 
‘mpegts_insert_null_packet’
libavformat/mpegtsenc.c:919:13: error: invalid storage class for function 
‘mpegts_insert_pcr_only’
libavformat/mpegtsenc.c:944:13: error: invalid storage class for function 
‘write_pts’
libavformat/mpegtsenc.c:959:13: error: invalid storage class for function 
‘set_af_flag’
libavformat/mpegtsenc.c:975:13: error: invalid storage class for function 
‘extend_af’
libavformat/mpegtsenc.c:983:17: error: invalid storage class for function 
‘get_ts_payload_start’
libavformat/mpegtsenc.c:995:13: error: invalid storage class for function 
‘mpegts_write_pes’
libavformat/mpegtsenc.c:1258:12: error: invalid storage class for function 
‘check_hevc_startcode’
libavformat/mpegtsenc.c:1272:12: error: invalid storage class for function 
‘mpegts_write_packet_internal’
libavformat/mpegtsenc.c:1420:13: error: invalid storage class for function 
‘mpegts_write_flush’
libavformat/mpegtsenc.c:1437:12: error: invalid storage class for function 
‘mpegts_write_packet’
libavformat/mpegtsenc.c:1447:12: error: invalid storage class for function 
‘mpegts_write_end’
libavformat/mpegtsenc.c:1550:1: error: expected declaration or statement at end 
of input
libavformat/mpegtsenc.c:1537:16: warning: unused variable ‘ff_mpegts_muxer’ 
[-Wunused-variable]
make: *** [libavformat/mpegtsenc.o] Error 1
libavformat/mpegenc.c: In function ‘flush_packet’:
libavformat/mpegenc.c:868:38: error: expected expression before ‘<=’ token
make: *** [libavformat/mpegenc.o] Error 1
libavcodec/allcodecs.c: In function ‘avcodec_register_all’:
libavcodec/allcodecs.c:487:45: error: ‘CONFIG_CIA608_DECODER’ undeclared (first 
use in this function)
libavcodec/allcodecs.c:487:45: note: each undeclared identifier is reported 
only once for each function it appears in
libavcodec/allcodecs.c:562:28: warning: redundant redeclaration of 
‘ff_dvbvbi_parser’ [-Wredundant-decls]
libavcodec/allcodecs.c:504:28: note: previous declaration of ‘ff_dvbvbi_parser’ 
was here
make: *** [libavcodec/allcodecs.o] Error 1
libavcodec/codec_desc.c:2578:15: error: ‘AV_CODEC_ID_DVB_TELETEXT’ undeclared 
here (not in a function)
libavcodec/codec_desc.c: In function ‘avcodec_descriptor_next’:
libavcodec/codec_desc.c:2897:5: warning: comparison of unsigned expression < 0 
is always false [-Wtype-limits]

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/mpegvideo: also export 0, 0 motion vectors

[Michael Niedermayer]

On Thu, Jan 22, 2015 at 09:59:54AM +0100, Clément Bœsch wrote:
> On Mon, Jan 19, 2015 at 11:58:09PM +0100, Michael Niedermayer wrote:
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/mpegvideo.c  |2 --
> >  tests/ref/fate/filter-codecview-mvs |   30 +++---
> >  2 files changed, 15 insertions(+), 17 deletions(-)
> > 
> > diff --git a/libavcodec/mpegvideo.c b/libavcodec/mpegvideo.c
> > index ce4fa59..6966572 100644
> > --- a/libavcodec/mpegvideo.c
> > +++ b/libavcodec/mpegvideo.c
> > @@ -2138,8 +2138,6 @@ static int add_mb(AVMotionVector *mb, uint32_t 
> > mb_type,
> >int src_x, int src_y,
> >int direction)
> >  {
> > -if (dst_x == src_x && dst_y == src_y)
> > -return 0;
> >  mb->w = IS_8X8(mb_type) || IS_8X16(mb_type) ? 8 : 16;
> >  mb->h = IS_8X8(mb_type) || IS_16X8(mb_type) ? 8 : 16;
> >  mb->src_x = src_x;
> 
> OK I guess.

applied

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

He who knows, does not speak. He who speaks, does not know. -- Lao Tsu


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] avformat/flvenc: accept AVMEDIA_TYPE_SUBTITLE instead of DATA for subtitles

[Paul B Mahol]

On 1/20/15, Michael Niedermayer  wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/flvenc.c |   12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
>

lgtm
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avformat/flvenc: accept AVMEDIA_TYPE_SUBTITLE instead of DATA for subtitles

[Michael Niedermayer]

On Thu, Jan 22, 2015 at 11:43:25AM +, Paul B Mahol wrote:
> On 1/20/15, Michael Niedermayer  wrote:
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavformat/flvenc.c |   12 +++-
> >  1 file changed, 11 insertions(+), 1 deletion(-)
> >
> 
> lgtm

applied

thanks

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] configure: add --build-date and --build-time options

[Andreas Cadhalpun]

Hi,

On 22.01.2015 02:58, Timothy Gu wrote:

I'd rather have an option disabling it. Sounds cleaner.


In which way cleaner?

Replacing the date/time with a reproducible one is the least invasive 
change. Removing it altogether would produce a different end result.


Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] configure: add --build-date and --build-time options

[wm4]

On Thu, 22 Jan 2015 15:03:40 +0100
Andreas Cadhalpun  wrote:

> Hi,
> 
> On 22.01.2015 02:58, Timothy Gu wrote:
> > I'd rather have an option disabling it. Sounds cleaner.
> 
> In which way cleaner?
> 
> Replacing the date/time with a reproducible one is the least invasive 
> change. Removing it altogether would produce a different end result.
> 
> Best regards,
> Andreas

If the build date is not correct, then what value does the build date
have at all?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Duration/bitrate estimation

[Michael Niedermayer]

On Thu, Jan 22, 2015 at 12:05:24AM -0500, Marcus Johnson wrote:
> What functions are used to estimate the duration and bit rate of a file?
> I'd like to add support for these features for the DTS format, and would
> rather not dig around the source looking for it.

you can set AVStream.duration and AVCodecContext.bit_rate from the
dts demuxer if these are known
otherwise the duration is estimated in avformat_find_stream_info()
and the functions called by it if there is sufficient information
available

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] libx265: Pass through user-set frame type

[Derek Buitenhuis]

Signed-off-by: Derek Buitenhuis 
---
 libavcodec/libx265.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
index 923c750..aee7ae2 100644
--- a/libavcodec/libx265.c
+++ b/libavcodec/libx265.c
@@ -224,6 +224,11 @@ static int libx265_encode_frame(AVCodecContext *avctx, 
AVPacket *pkt,
 
 x265pic.pts  = pic->pts;
 x265pic.bitDepth = 
av_pix_fmt_desc_get(avctx->pix_fmt)->comp[0].depth_minus1 + 1;
+
+x265pic.sliceType = pic->pict_type == AV_PICTURE_TYPE_I ? X265_TYPE_I :
+pic->pict_type == AV_PICTURE_TYPE_P ? X265_TYPE_P :
+pic->pict_type == AV_PICTURE_TYPE_B ? X265_TYPE_B :
+X265_TYPE_AUTO;
 }
 
 ret = x265_encoder_encode(ctx->encoder, &nal, &nnal,
-- 
1.8.3.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libx265: Pass through user-set frame type

[Derek Buitenhuis]

On 1/22/2015 2:44 PM, Derek Buitenhuis wrote:
> Signed-off-by: Derek Buitenhuis 
> ---
>  libavcodec/libx265.c | 5 +
>  1 file changed, 5 insertions(+)

This is v2.

- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] configure: add --build-date and --build-time options

[Andreas Cadhalpun]

Hi,

On 22.01.2015 15:31, wm4 wrote:

If the build date is not correct, then what value does the build date
have at all?


How do you know it is 'correct' currently?
One can change the system clock (or use faketime).

What value has the 'correct' build date?
If you build an ffmpeg version from a year ago today it will contain the 
current date. That's rather misleading.


With the --build-{date,time} options one can specify meaningful values 
such as the time of the last change to the source.


Best regards,
Andreas

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avformat/network: Check for av_malloc* failures in ff_tls_init()

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 libavformat/network.c |6 +-
 libavformat/network.h |2 +-
 libavformat/tls.c |3 ++-
 libavformat/utils.c   |3 ++-
 4 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/libavformat/network.c b/libavformat/network.c
index 9f02ec6..e9eab29 100644
--- a/libavformat/network.c
+++ b/libavformat/network.c
@@ -66,7 +66,7 @@ GCRY_THREAD_OPTION_PTHREAD_IMPL;
 #endif
 #endif
 
-void ff_tls_init(void)
+int ff_tls_init(void)
 {
 avpriv_lock_avformat();
 #if CONFIG_OPENSSL
@@ -77,6 +77,8 @@ void ff_tls_init(void)
 if (!CRYPTO_get_locking_callback()) {
 int i;
 openssl_mutexes = av_malloc_array(sizeof(pthread_mutex_t), 
CRYPTO_num_locks());
+if (!openssl_mutexes)
+return AVERROR(ENOMEM);
 for (i = 0; i < CRYPTO_num_locks(); i++)
 pthread_mutex_init(&openssl_mutexes[i], NULL);
 CRYPTO_set_locking_callback(openssl_lock);
@@ -96,6 +98,8 @@ void ff_tls_init(void)
 gnutls_global_init();
 #endif
 avpriv_unlock_avformat();
+
+return 0;
 }
 
 void ff_tls_deinit(void)
diff --git a/libavformat/network.h b/libavformat/network.h
index 0d1081a..86fb656 100644
--- a/libavformat/network.h
+++ b/libavformat/network.h
@@ -78,7 +78,7 @@ extern int ff_network_inited_globally;
 int ff_network_init(void);
 void ff_network_close(void);
 
-void ff_tls_init(void);
+int ff_tls_init(void);
 void ff_tls_deinit(void);
 
 int ff_network_wait_fd(int fd, int write);
diff --git a/libavformat/tls.c b/libavformat/tls.c
index d6a6be3..942083b 100644
--- a/libavformat/tls.c
+++ b/libavformat/tls.c
@@ -175,7 +175,8 @@ static int tls_open(URLContext *h, const char *uri, int 
flags)
 const char *proxy_path;
 int use_proxy;
 
-ff_tls_init();
+if ((ret = ff_tls_init()) < 0)
+return ret;
 
 if (c->listen)
 snprintf(opts, sizeof(opts), "?listen=1");
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 1124783..2f07efc 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -4097,7 +4097,8 @@ int avformat_network_init(void)
 ff_network_inited_globally = 1;
 if ((ret = ff_network_init()) < 0)
 return ret;
-ff_tls_init();
+if ((ret = ff_tls_init()) < 0)
+return ret;
 #endif
 return 0;
 }
-- 
1.7.9.5

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] configure: add --build-date and --build-time options

[Benoit Fouet]

Hi,

Le 21/01/2015 23:10, Andreas Cadhalpun a écrit :

Hi,

Debian tries to make binary packages build reproducible [1].

FFmpeg embeds date and time in the program and documentation, which 
makes it hard to have binary reproducible packages.


The attached patch allows to specify the build date and time to use 
with a configure option, solving this problem.




If this patch is accepted in the content, then, I'd decorrelate 
BUILD_DATE and BUILD_TIME a bit more than what it is in your patch (see 
below).



Best regards,
Andreas

1: https://wiki.debian.org/ReproducibleBuilds/About

configure-add-build-date-and-build-time-options.patch


 From 285003006eb2b9cd1a6e2dcd6351c7f8b3090366 Mon Sep 17 00:00:00 2001
From: Andreas Cadhalpun
Date: Wed, 21 Jan 2015 22:31:04 +0100
Subject: [PATCH] configure: add --build-date and --build-time options

These allow to make the build binary reproducible by specifying the
date/time that should be used instead of the current date/time.

Signed-off-by: Andreas Cadhalpun
---
  cmdutils.c   |  2 +-
  configure| 14 ++
  doc/Makefile |  9 +
  ffprobe.c|  4 ++--
  4 files changed, 26 insertions(+), 3 deletions(-)


[...]


diff --git a/configure b/configure
index a0dbafb..4f44cea 100755
--- a/configure
+++ b/configure


[...]


@@ -5712,6 +5716,16 @@ cat > $TMPH <  
+if [ -n "$build_date" ] || [ -n "$build_time" ]; then

+echo "#define BUILD_DATE \"${build_date}\"" >> $TMPH
+echo "#define BUILD_TIME \"${build_time}\"" >> $TMPH
+echo "BUILD_DATE=$build_date" >> config.mak
+echo "BUILD_TIME=$build_time" >> config.mak
+else
+echo "#define BUILD_DATE __DATE__" >> $TMPH
+echo "#define BUILD_TIME __TIME__" >> $TMPH
+fi
+


changing this by:
if [ -n "$build_date" ]; then
echo "#define BUILD_DATE \"${build_date}\"" >> $TMPH
echo "BUILD_DATE=$build_date" >> config.mak
else
echo "#define BUILD_DATE __DATE__" >> $TMPH
fi

same for BUILD_TIME.

Or at least change your patch to not assume that one is set when the 
other is.


--
Ben

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libx265: Pass through user-set frame type

[Michael Niedermayer]

On Thu, Jan 22, 2015 at 02:44:55PM +, Derek Buitenhuis wrote:
> Signed-off-by: Derek Buitenhuis 
> ---
>  libavcodec/libx265.c | 5 +
>  1 file changed, 5 insertions(+)

LGTM

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

What does censorship reveal? It reveals fear. -- Julian Assange


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Port mp=eq/eq2 to FFmpeg

[arwa arif]

On Thu, Jan 22, 2015 at 2:59 PM, wm4  wrote:

> On Thu, 22 Jan 2015 01:38:11 +0530
> arwa arif  wrote:
>
> > From 703cc1887903c2868537e19e99b76927bec07884 Mon Sep 17 00:00:00 2001
> > From: Arwa Arif 
> > Date: Mon, 19 Jan 2015 03:56:48 +0530
> > Subject: [PATCH] Port mp=eq/eq2 to FFmpeg
> >
> > Code adapted from James Darnley's previous commits
>
> > [...]
>
> > +#if HAVE_MMX && HAVE_6REGS
> > +static void process_MMX(EQParameters *param, uint8_t *dst, int
> dst_stride,
> > +uint8_t *src, int src_stride, int w, int h)
> > +{
> > +int i;
> > +int pel;
> > +int dstep = dst_stride - w;
> > +int sstep = src_stride - w;
> > +short brvec[4];
> > +short contvec[4];
> > +
> > +brvec[0] = brvec[1] = brvec[2] = brvec[3] = param->b;
> > +contvec[0] = contvec[1] = contvec[2] = contvec[3] = param->c;
> > +
> > +while (h--) {
> > +__asm__ volatile (
> > +"movq (%5), %%mm3  \n\t"
> > +"movq (%6), %%mm4  \n\t"
> > +"pxor %%mm0, %%mm0 \n\t"
> > +"movl %4, %%eax\n\t"
> > +//ASMALIGN(4)
> > +"1:\n\t"
> > +"movq (%0), %%mm1  \n\t"
> > +"movq (%0), %%mm2  \n\t"
> > +"punpcklbw %%mm0, %%mm1\n\t"
> > +"punpckhbw %%mm0, %%mm2\n\t"
> > +"psllw $4, %%mm1   \n\t"
> > +"psllw $4, %%mm2   \n\t"
> > +"pmulhw %%mm4, %%mm1   \n\t"
> > +"pmulhw %%mm4, %%mm2   \n\t"
> > +"paddw %%mm3, %%mm1\n\t"
> > +"paddw %%mm3, %%mm2\n\t"
> > +"packuswb %%mm2, %%mm1 \n\t"
> > +"add $8, %0\n\t"
> > +"movq %%mm1, (%1)  \n\t"
> > +"add $8, %1\n\t"
> > +"decl %%eax\n\t"
> > +"jnz 1b\n\t"
> > +: "=r" (src), "=r" (dst)
> > +: "0" (src), "1" (dst), "r" (w>>3), "r"
> (brvec), "r" (contvec)
> > +: "%eax"
> > +);
> > +
> > +for (i = w&7; i; i--) {
> > +pel = ((*src++ * param->c) >> 12) + param->b;
> > +if (pel & 768)
> > +pel = (-pel) >> 31;
> > +*dst++ = pel;
> > +}
> > +
> > +src += sstep;
> > +dst += dstep;
> > +}
> > +__asm__ volatile ( "emms \n\t" ::: "memory" );
> > +}
> > +#endif
>
> IMO the asm shouldn't be added at all. It's not important enough for a
> ported video filter, but has high maintenance overhead - there's a
> reason the FFmpeg loathes inline asm, right?
>
> How much does the inline asm help with speed? When I tested it on a
> reasonably modern CPU a while ago, there was barely any advantage.
>
>
I checked the runtime of the codes with and without asm, it turns out that
there is not much difference. The difference is coming out to be in
milliseconds.

26.014s with asm and
26.129 without asm.

 So, should I remove the asm part?


> > +av_cold void ff_eq_init_x86(EQContext *eq)
> > +{
> > +#if HAVE_MMX_INLINE
> > +int cpu_flags = av_get_cpu_flags();
> > +
> > +if (cpu_flags & AV_CPU_FLAG_MMX) {
> > +eq->process = process_MMX;
> > +}
> > +#endif
> > +}
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] configure: add --build-date and --build-time options

[Andreas Cadhalpun]

Hi,

On 22.01.2015 17:02, Benoit Fouet wrote:

If this patch is accepted in the content, then, I'd decorrelate
BUILD_DATE and BUILD_TIME a bit more than what it is in your patch (see
below).


Do you think one would ever want to specify one, but not the other?


[...]


@@ -5712,6 +5716,16 @@ cat > $TMPH <> $TMPH
+echo "#define BUILD_TIME \"${build_time}\"" >> $TMPH
+echo "BUILD_DATE=$build_date" >> config.mak
+echo "BUILD_TIME=$build_time" >> config.mak
+else
+echo "#define BUILD_DATE __DATE__" >> $TMPH
+echo "#define BUILD_TIME __TIME__" >> $TMPH
+fi
+


changing this by:
if [ -n "$build_date" ]; then
 echo "#define BUILD_DATE \"${build_date}\"" >> $TMPH
 echo "BUILD_DATE=$build_date" >> config.mak
else
 echo "#define BUILD_DATE __DATE__" >> $TMPH
fi

same for BUILD_TIME.


It would also require changes to the sed calls in doc/Makefile, making 
them more complex.



Or at least change your patch to not assume that one is set when the
other is.


It doesn't assume it's set, it just treats it not being set in the same 
way as if it was set to the empty string.


I would have added only one option for both date and time, but that's 
not possible, because they are used separately in ffprobe.c.


Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Suggested Patch for timecode timebase calculation in mov.c

[jon]

I never heard back about this and I think I have a new better solution 
now. I don't think the current mov.c timecode processing is handling the 
case where the timecode is in counter mode. Please read the following 
page 190 from:


https://developer.apple.com/library/mac/documentation/QuickTime/QTFF/qtff.pdf

Specifically:

"Number of frames
An 8-bit integer that contains the number of frames per second for the 
timecode format. If the time is a counter, this is the number of frames 
for each counter tick."


I have sample media in counter mode if it helps. I tried to send that 
before as well, but I think it was too large. Please let me know how 
else I can help with this enhancement. Feel free to send clarification 
questions to me.


Thanks,
Jon

On 09/09/2014 12:01 PM, jon wrote:

Hi ffmpeg developers.

I am still new to attempting contributing here, so please let me know if
there is a better approach for this. I am attaching a patch I would like
to incorporate for calculating the stream time_base of the timecode data
track in mov's. Please advise.

Thanks!
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 556411f1ef9f12097a5f779e858e815c26dc92e6..3ceb53424e597de99040d3d669f10421cc208b4d 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -1658,6 +1658,13 @@ static int mov_parse_stsd_data(MOVContext *c, AVIOContext *pb,
 st->codec->flags2 |= CODEC_FLAG2_DROP_FRAME_TIMECODE;
 st->codec->time_base.den = st->codec->extradata[16]; /* number of frame */
 st->codec->time_base.num = 1;
+/* adjust for per frame dur in counter mode */
+if (tmcd_ctx->tmcd_flags & 0x0008) {
+int timescale = AV_RB32(st->codec->extradata + 8);
+int framedur = AV_RB32(st->codec->extradata + 12);
+st->codec->time_base.den *= timescale;
+st->codec->time_base.num *= framedur;
+}
 if (size > 30) {
 uint32_t len = AV_RB32(st->codec->extradata + 18); /* name atom length */
 uint32_t format = AV_RB32(st->codec->extradata + 22);
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] nvenc: Compensate for hardware trying to mess with aspect ratio of DVD content.

[Philip Langdale]

On Thu, 22 Jan 2015 13:12:59 +0800
Agatha Hu  wrote:

> Disabling compensation is the best result, adding a flag is
> acceptable, but NVENC5.0 has just released, such option won't be
> available until 6.0 is available, so...
> Still waiting for nvenc teams feedback, the worst case is adding the 
> 'de-compensation' logic for 4:3 and 16:9

If they can get a flag in eventually, that's still a good improvement.
We'll need the de-compensation logic in the short term, regardless of
anything else.

Thanks,

--phil
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Port mp=eq/eq2 to FFmpeg

[James Almer]

On 22/01/15 6:29 AM, wm4 wrote:
> IMO the asm shouldn't be added at all. It's not important enough for a
> ported video filter, but has high maintenance overhead - there's a
> reason the FFmpeg loathes inline asm, right?

Unless the asm is slower than the C code as compiled by recent versions of gcc, 
or 
its output not bitexact to the C version while at the same time looking worse, 
then 
i see no reason to remove it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/mov: Stricter sanity checks on the display_matrix

[Michael Niedermayer]

On Wed, Jan 21, 2015 at 05:02:01PM +0100, Michael Niedermayer wrote:
> Fixes "broken" tkhd
> Found-by: koda
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/mov.c |3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

applied


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Port mp=eq/eq2 to FFmpeg

[wm4]

On Thu, 22 Jan 2015 21:45:04 +0530
arwa arif  wrote:

> On Thu, Jan 22, 2015 at 2:59 PM, wm4  wrote:
> 
> > On Thu, 22 Jan 2015 01:38:11 +0530
> > arwa arif  wrote:
> >
> > > From 703cc1887903c2868537e19e99b76927bec07884 Mon Sep 17 00:00:00 2001
> > > From: Arwa Arif 
> > > Date: Mon, 19 Jan 2015 03:56:48 +0530
> > > Subject: [PATCH] Port mp=eq/eq2 to FFmpeg
> > >
> > > Code adapted from James Darnley's previous commits
> >
> > > [...]
> >
> > > +#if HAVE_MMX && HAVE_6REGS
> > > +static void process_MMX(EQParameters *param, uint8_t *dst, int
> > dst_stride,
> > > +uint8_t *src, int src_stride, int w, int h)
> > > +{
> > > +int i;
> > > +int pel;
> > > +int dstep = dst_stride - w;
> > > +int sstep = src_stride - w;
> > > +short brvec[4];
> > > +short contvec[4];
> > > +
> > > +brvec[0] = brvec[1] = brvec[2] = brvec[3] = param->b;
> > > +contvec[0] = contvec[1] = contvec[2] = contvec[3] = param->c;
> > > +
> > > +while (h--) {
> > > +__asm__ volatile (
> > > +"movq (%5), %%mm3  \n\t"
> > > +"movq (%6), %%mm4  \n\t"
> > > +"pxor %%mm0, %%mm0 \n\t"
> > > +"movl %4, %%eax\n\t"
> > > +//ASMALIGN(4)
> > > +"1:\n\t"
> > > +"movq (%0), %%mm1  \n\t"
> > > +"movq (%0), %%mm2  \n\t"
> > > +"punpcklbw %%mm0, %%mm1\n\t"
> > > +"punpckhbw %%mm0, %%mm2\n\t"
> > > +"psllw $4, %%mm1   \n\t"
> > > +"psllw $4, %%mm2   \n\t"
> > > +"pmulhw %%mm4, %%mm1   \n\t"
> > > +"pmulhw %%mm4, %%mm2   \n\t"
> > > +"paddw %%mm3, %%mm1\n\t"
> > > +"paddw %%mm3, %%mm2\n\t"
> > > +"packuswb %%mm2, %%mm1 \n\t"
> > > +"add $8, %0\n\t"
> > > +"movq %%mm1, (%1)  \n\t"
> > > +"add $8, %1\n\t"
> > > +"decl %%eax\n\t"
> > > +"jnz 1b\n\t"
> > > +: "=r" (src), "=r" (dst)
> > > +: "0" (src), "1" (dst), "r" (w>>3), "r"
> > (brvec), "r" (contvec)
> > > +: "%eax"
> > > +);
> > > +
> > > +for (i = w&7; i; i--) {
> > > +pel = ((*src++ * param->c) >> 12) + param->b;
> > > +if (pel & 768)
> > > +pel = (-pel) >> 31;
> > > +*dst++ = pel;
> > > +}
> > > +
> > > +src += sstep;
> > > +dst += dstep;
> > > +}
> > > +__asm__ volatile ( "emms \n\t" ::: "memory" );
> > > +}
> > > +#endif
> >
> > IMO the asm shouldn't be added at all. It's not important enough for a
> > ported video filter, but has high maintenance overhead - there's a
> > reason the FFmpeg loathes inline asm, right?
> >
> > How much does the inline asm help with speed? When I tested it on a
> > reasonably modern CPU a while ago, there was barely any advantage.
> >
> >
> I checked the runtime of the codes with and without asm, it turns out that
> there is not much difference. The difference is coming out to be in
> milliseconds.
> 
> 26.014s with asm and
> 26.129 without asm.
> 
>  So, should I remove the asm part?

Then I'd definitely vote for remove.

The asm probably mattered on ancient CPUs and ancient compilers, but
there's no reason to keep it anymore.

> 
> > > +av_cold void ff_eq_init_x86(EQContext *eq)
> > > +{
> > > +#if HAVE_MMX_INLINE
> > > +int cpu_flags = av_get_cpu_flags();
> > > +
> > > +if (cpu_flags & AV_CPU_FLAG_MMX) {
> > > +eq->process = process_MMX;
> > > +}
> > > +#endif
> > > +}
> >
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Port mp=eq/eq2 to FFmpeg

[James Almer]

On 22/01/15 4:27 PM, wm4 wrote:
> Then I'd definitely vote for remove.
> 
> The asm probably mattered on ancient CPUs and ancient compilers, but
> there's no reason to keep it anymore.

No. If the handwritten asm is better than the C code, even if slightly, then 
it should not be removed.
And if someone dislikes its inline asm nature then they are free to port it, 
like i did with a couple other filters before.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Port mp=eq/eq2 to FFmpeg

[wm4]

On Thu, 22 Jan 2015 16:43:16 -0300
James Almer  wrote:

> On 22/01/15 4:27 PM, wm4 wrote:
> > Then I'd definitely vote for remove.
> > 
> > The asm probably mattered on ancient CPUs and ancient compilers, but
> > there's no reason to keep it anymore.
> 
> No. If the handwritten asm is better than the C code, even if slightly, then 
> it should not be removed.
> And if someone dislikes its inline asm nature then they are free to port it, 
> like i did with a couple other filters before.

For such a small difference, your statement is ridiculous.

No, really.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Port mp=eq/eq2 to FFmpeg

[James Almer]

On 22/01/15 4:52 PM, wm4 wrote:
> On Thu, 22 Jan 2015 16:43:16 -0300
> James Almer  wrote:
> 
>> On 22/01/15 4:27 PM, wm4 wrote:
>>> Then I'd definitely vote for remove.
>>>
>>> The asm probably mattered on ancient CPUs and ancient compilers, but
>>> there's no reason to keep it anymore.
>>
>> No. If the handwritten asm is better than the C code, even if slightly, then 
>> it should not be removed.
>> And if someone dislikes its inline asm nature then they are free to port it, 
>> like i did with a couple other filters before.
> 
> For such a small difference, your statement is ridiculous.
> 
> No, really.

Grab any audio file and try to decode it, manually disabling different audio 
dsp 
functions it uses from libavcodec/libswresample and recompiling, and see how 
much 
each of them affect overall decoding speed.
You'll find that many don't even seem to have any effect if you only check with 
time, yet are still 2 to 4 times faster than their C counterparts.

Do you want to remove them as well?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Port mp=eq/eq2 to FFmpeg

[Clément Bœsch]

On Thu, Jan 22, 2015 at 09:45:04PM +0530, arwa arif wrote:
[...]
> I checked the runtime of the codes with and without asm, it turns out that
> there is not much difference. The difference is coming out to be in
> milliseconds.
> 
> 26.014s with asm and
> 26.129 without asm.
> 
>  So, should I remove the asm part?
> 

If you want to compare the speed of the ASM itself, you need to compare
with START_TIMER and STOP_TIMER macros.

But before you do that, I'd like to raise an issue (which might be kind of
off topic, sorry about that).

In 2009, this was committed: 973859f5230e77beea7bb59dc081870689d6d191

It disables the tree-vectorize optimizations (we compile FFmpeg at -O3
where it's enabled by default, but we explicitly disables it).

In this particular case, it seems that GCC is able to vectorize the C
version using SSE* code, which means it's actually potentially faster¹
than the home written MMX version we have²

I'd suggest we try to revert that commit, and next time we write or port
optimizations we make a fair comparison. That is, with code generated by a
modern compiler without such option. If the old MMX code is actually
making the code slower, we should not waste our time with it.

Benchmarks welcome.

[1] http://pastie.org/pastes/9852329/text (-O3)
[2] http://pastie.org/pastes/9852328/text (-O3 -fno-tree-vectorize / current)


-- 
Clément B.


pgp8e9FOxf5WX.pgp
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Port mp=eq/eq2 to FFmpeg

[wm4]

On Thu, 22 Jan 2015 16:59:24 -0300
James Almer  wrote:

> On 22/01/15 4:52 PM, wm4 wrote:
> > On Thu, 22 Jan 2015 16:43:16 -0300
> > James Almer  wrote:
> > 
> >> On 22/01/15 4:27 PM, wm4 wrote:
> >>> Then I'd definitely vote for remove.
> >>>
> >>> The asm probably mattered on ancient CPUs and ancient compilers, but
> >>> there's no reason to keep it anymore.
> >>
> >> No. If the handwritten asm is better than the C code, even if slightly, 
> >> then 
> >> it should not be removed.
> >> And if someone dislikes its inline asm nature then they are free to port 
> >> it, 
> >> like i did with a couple other filters before.
> > 
> > For such a small difference, your statement is ridiculous.
> > 
> > No, really.
> 
> Grab any audio file and try to decode it, manually disabling different audio 
> dsp 
> functions it uses from libavcodec/libswresample and recompiling, and see how 
> much 
> each of them affect overall decoding speed.
> You'll find that many don't even seem to have any effect if you only check 
> with 
> time, yet are still 2 to 4 times faster than their C counterparts.
> 
> Do you want to remove them as well?

That's hard to tell; if they're not bottlenecks (and can never be),
then this asm would have been a case of premature optimization.

In this case, it seems unlikely that vf_eq will ever be a bottleneck,
or that the asm would help if it was. (You can still add back the asm if
this changes... it's part of the git history, and won't run away.)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Port mp=eq/eq2 to FFmpeg

[wm4]

On Wed, 21 Jan 2015 20:38:20 +0530
arwa arif  wrote:

> >
> > I still expect that eq and eq2 should have the same performances,
> > since the adjust callback is set depending on the parameter values. So
> > we should have a single eq filter.
> >
> > Please investigate about why you get different benchmark values.
> >
> 
> I used this command: ffmpeg -benchmark -i  matrixbench_mpeg2.mpg -vf mp=eq2
> -f null -
> And everytime I am running this command, I am getting a different result
> even for the same input and same filter.

It could be that this command line doesn't actually run any of the
actual filter code, because the parameters (brightness etc.) are set to
"neutral" by default. Did you make sure the C and ASM filter code is
actually run?

> 
> So, I tried using the time.h library for getting the time, the results for
> eq and eq2 are 37.71 and 35.56 seconds respectively.
> 
> I don't know why eq is coming out to be slower than eq2. (In fact, eq2 is
> accessing more functions than eq).
> 
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avformat: allow .264 as extension for raw H.264 stream

[Werner Robitza]

In addition to .h264, .264 is also commonly used by people to name raw H.264
streams. Enables automatic recognition of the h264 format for the .264
extension.

Signed-off-by: Werner Robitza 
---
 libavformat/rawenc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/rawenc.c b/libavformat/rawenc.c
index 8b50fe1..9b77cdc 100644
--- a/libavformat/rawenc.c
+++ b/libavformat/rawenc.c
@@ -205,7 +205,7 @@ AVOutputFormat ff_h263_muxer = {
 AVOutputFormat ff_h264_muxer = {
 .name  = "h264",
 .long_name = NULL_IF_CONFIG_SMALL("raw H.264 video"),
-.extensions= "h264",
+.extensions= "h264,264",
 .audio_codec   = AV_CODEC_ID_NONE,
 .video_codec   = AV_CODEC_ID_H264,
 .write_header  = force_one_stream,
-- 
1.9.3 (Apple Git-50)

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Port mp=eq/eq2 to FFmpeg

[Christophe Gisquet]

So...

2015-01-21 21:08 GMT+01:00 arwa arif :
> Updated the patch.

There are trailing spaces, and the patch does not apply here (error on
libavfilter/x86/Makefile)

Furthemore, I think that hunk is incorrect:

+set_gamma(eq);
+set_contrast(eq);
+set_brightness(eq);
+set_saturation(eq);
+
+for (i = 0; i < 3; i++) {
+eq->param[i].c = (eq->param[i].contrast) * 65536.0;
+eq->param[i].b = (eq->param[i].brightness + 1.0) * 255.5 -
128.0 - (eq->param[i].contrast) * 128.0;
+}
+
+eq->process = process_c;
+
+if (ARCH_X86)
+ff_eq_init_x86(eq);

The adjust function pointer may be set to eq->process potentially, but
eq->process won't ever be set at that moment, as it is set in the last
part.

Once fixed, I get with gcc 4.9.2, Mingw64 (not msys2) on a core i5-460
(up to sse4.2)
C:   16098398 decicycles in eq, 2048 runs, 0 skips CRC=0xb4a713e1
MMX:  5912547 decicycles in eq, 2048 runs, 0 skips CRC=0x1dfc0418
vect: 8663446 decicycles in eq, 2048 runs, 0 skips CRC=0xb4a713e1
Note: vect is -O3 -msse4.2 -ftree-vectorize

-- 
Christophe
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat: allow .264 as extension for raw H.264 stream

[Michael Niedermayer]

On Thu, Jan 22, 2015 at 10:02:36PM +0100, Werner Robitza wrote:
> In addition to .h264, .264 is also commonly used by people to name raw H.264
> streams. Enables automatic recognition of the h264 format for the .264
> extension.
> 
> Signed-off-by: Werner Robitza 
> ---
>  libavformat/rawenc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

applied

thanks

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin


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/3] avcodec/nvenc: Fix b-frame parameter handling

[Michael Niedermayer]

On Fri, Jan 16, 2015 at 01:02:38AM +0100, Timo Rothenpieler wrote:
> ---
>  libavcodec/nvenc.c | 20 
>  1 file changed, 8 insertions(+), 12 deletions(-)
> 
> diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
> index 5cd7727..90856be 100644
> --- a/libavcodec/nvenc.c
> +++ b/libavcodec/nvenc.c
> @@ -155,7 +155,6 @@ typedef struct NvencContext
>  char *preset;
>  int cbr;
>  int twopass;
> -int gobpattern;
>  int gpu;
>  } NvencContext;
>  
> @@ -582,6 +581,13 @@ static av_cold int nvenc_encode_init(AVCodecContext 
> *avctx)
>  memcpy(&ctx->encode_config, &preset_config.presetCfg, 
> sizeof(ctx->encode_config));
>  ctx->encode_config.version = NV_ENC_CONFIG_VER;
>  
> +/* 0 is intra-only, 1 is I/P only, 2 is one B Frame, 3 two B frames, and 
> so on. */
> +ctx->encode_config.frameIntervalP = avctx->max_b_frames + 1;

how can the user choose between intra only and IP ?

i would have assumed that gop_size <= 1 would select intra only


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] mark null encoder as ts-nonstrict , avoids error messages for null output

[Michael Niedermayer]

On Wed, Aug 27, 2014 at 08:13:24PM -0500, Rodger Combs wrote:
> > On Thu, Aug 21, 2014 at 02:00:22PM +0200, Hendrik Leppkes wrote:
> > > On Thu, Aug 21, 2014 at 1:38 PM, compn  > > > wrote:
> > > > https://gist.github.com/anonymous/0e26f490ec13d67996fd 
> > > > 
> > > >
> > > > commit e94a44543a96b13aa6a23efce2f0378a5479d530
> > > > Author: Rodger Combs  > > > >
> > > > Date:   Wed Aug 20 15:38:12 2014 -0700
> > > >
> > > > avformat/nullenc: mark null as timestamp-nonstrict
> > > > This avoids unnecessary error messages for null output
> > > >
> > > > diff --git a/libavformat/nullenc.c b/libavformat/nullenc.c
> > > > index 7c08c39..58b88a1 100644
> > > > --- a/libavformat/nullenc.c
> > > > +++ b/libavformat/nullenc.c
> > > > @@ -32,5 +32,5 @@ AVOutputFormat ff_null_muxer = {
> > > >  .audio_codec   = AV_NE(AV_CODEC_ID_PCM_S16BE, 
> > > > AV_CODEC_ID_PCM_S16LE),
> > > >  .video_codec   = AV_CODEC_ID_RAWVIDEO,
> > > >  .write_packet  = null_write_packet,
> > > > -.flags = AVFMT_VARIABLE_FPS | AVFMT_NOFILE | 
> > > > AVFMT_NOTIMESTAMPS | AVFMT_RAWPICTURE,
> > > > +.flags = AVFMT_TS_NONSTRICT | AVFMT_VARIABLE_FPS | 
> > > > AVFMT_NOFILE | AVFMT_NOTIMESTAMPS | AVFMT_RAWPICTURE,
> > > >  };
> > > 
> > > There is a lot of other muxers out there that also have NOTIMESTAMPS
> > > set, and not this flag.
> > > 
> > > IMHO the code that complains about invalid timestamps should be
> > > adjusted to not do it when NOTIMESTAMPS is set, instead of this.
> > 
> > maybe but for testing/fate at least we should retain timestamp
> > checks, null is used alot for testing if one looks at trac
> > iam not sure what is the best thing to do here
> 
> How about adding a lavf option? I could imagine a few ways that could be 
> done, but my favorite is to make `AVFMT_NOTIMESTAMPS` imply 
> `AVFMT_TS_NONSTRICT` (on the checking code's end), and add an option to 
> re-enable the error (possibly downgraded to a warning?) even with non-strict 
> encoders. We could also have the option disable the error with strict 
> encoders (but that seems less sensible to me).

possible, yes, i dont know what is best


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/h264: Partially decode and display single fields try #2

[Michael Niedermayer]

On Wed, Jan 21, 2015 at 02:28:36PM +, Kieran Kunhya wrote:
> > yes, its overall 3 lines shorter as well
> > ive locally changed it to this:
> 
> Thanks, much easier to understand.

applied

thanks

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] nvenc: Propagate desired number of reference frames.

[Philip Langdale]

Signed-off-by: Philip Langdale 
---
 libavcodec/nvenc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index c52beb7..34ec112 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -614,6 +614,8 @@ static av_cold int nvenc_encode_init(AVCodecContext *avctx)
 memcpy(&ctx->encode_config, &preset_config.presetCfg, 
sizeof(ctx->encode_config));
 ctx->encode_config.version = NV_ENC_CONFIG_VER;
 
+ctx->encode_config.encodeCodecConfig.h264Config.maxNumRefFrames = 
avctx->refs;
+
 /* 0 is intra-only, 1 is I/P only, 2 is one B Frame, 3 two B frames, and 
so on. */
 ctx->encode_config.frameIntervalP = avctx->max_b_frames + 1;
 
-- 
2.1.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] libavutil: Added twofish block cipher

[Michael Niedermayer]

Hi

On Wed, Jan 21, 2015 at 01:26:18AM +0530, supraja reddy wrote:
> Hello,
> 
> Thanks for you reviews.
> 
> I see this is only use during init but if it still matters speedwise
> > and assuming this is a galois field multiplication the it can be
> > written as
> >
> > EXP_GF256[LOG_GF256[a] + LOG_GF256[b]]  (for a!=0 && b!=0)
> >
> > Do you want me to insert tables EXP_GF256 and LOG_GF256 in the code or are
> there any existing tables ?

i think there are no existing tables


> 
> I have updated the patch with other changes suggested. Please let me know
> if there is anything else to be changed.
> 

[...]

> +static uint32_t tf_h(uint32_t X, uint32_t L[4], int k)
> +{
> +uint8_t y[4], l[4];
> +AV_WL32(y, X);
> +if (k == 4) {
> +AV_WL32(l, L[3]);
> +y[0] = q1[y[0]] ^ l[0];
> +y[1] = q0[y[1]] ^ l[1];
> +y[2] = q0[y[2]] ^ l[2];
> +y[3] = q1[y[3]] ^ l[3];
> +}
> +if (k >= 3) {
> +AV_WL32(l, L[2]);
> +y[0] = q1[y[0]] ^ l[0];
> +y[1] = q1[y[1]] ^ l[1];
> +y[2] = q0[y[2]] ^ l[2];
> +y[3] = q0[y[3]] ^ l[3];
> +}
> +AV_WL32(l, L[1]);
> +y[0] = q1[q0[q0[y[0]] ^ l[0]] ^ (L[0] & 0xff)];
> +y[1] = q0[q0[q1[y[1]] ^ l[1]] ^ ((L[0] >> 8) & 0xff)];
> +y[2] = q1[q1[q0[y[2]] ^ l[2]] ^ ((L[0] >> 16) & 0xff)];
> +y[3] = q0[q1[q1[y[3]] ^ l[3]] ^ (L[0] >> 24)];
> +
> +l[0] = y[0] ^ MD2[y[1]] ^ MD1[y[2]] ^ MD1[y[3]];
> +l[1] = MD1[y[0]] ^ MD2[y[1]] ^ MD2[y[2]] ^ y[3];
> +l[2] = MD2[y[0]] ^ MD1[y[1]] ^ y[2] ^ MD2[y[3]];
> +l[3] = MD2[y[0]] ^ y[1] ^ MD2[y[2]] ^ MD1[y[3]];
> +
> +return AV_RL32(l);
> +}

I think this can be implemented with a few 8bit->32bit LUTs which are
computed during init


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] web/download: Change main snapshot url to point to github

[Michael Niedermayer]

The url did just end at a "403 - Snapshots not allowed"

We also could point to ffmpeg.org, but the snapshots there are upto 24h old
with the current cronjob
---
 src/download |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/download b/src/download
index 20c42f8..4e56bc1 100644
--- a/src/download
+++ b/src/download
@@ -197,7 +197,7 @@
 git://source.ffmpeg.org/ffmpeg.git
 
   http://git.videolan.org/?p=ffmpeg.git";>Browse
-  http://git.videolan.org/?p=ffmpeg.git;a=snapshot;h=HEAD;sf=tgz";>Snapshot
+  https://github.com/FFmpeg/FFmpeg/tarball/master";>Snapshot (github)
 
   
   Main FFmpeg Git repository
-- 
1.7.9.5

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Suggested Patch for timecode timebase calculation in mov.c

[Michael Niedermayer]

On Thu, Jan 22, 2015 at 09:09:53AM -0800, jon wrote:
> I never heard back about this and I think I have a new better

are you subscribed to ffmpeg-devel ?


> solution now. I don't think the current mov.c timecode processing is
> handling the case where the timecode is in counter mode. Please read
> the following page 190 from:
> 
> https://developer.apple.com/library/mac/documentation/QuickTime/QTFF/qtff.pdf
> 
> Specifically:
> 
> "Number of frames
> An 8-bit integer that contains the number of frames per second for
> the timecode format. If the time is a counter, this is the number of
> frames for each counter tick."
> 
> I have sample media in counter mode if it helps. I tried to send
> that before as well, but I think it was too large. Please let me
> know how else I can help with this enhancement. Feel free to send
> clarification questions to me.

yes, please provide a sample
you can upload it via ftp see http://ffmpeg.org/bugreports.html
any url that allows downloading from with wget works too


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

What does censorship reveal? It reveals fear. -- Julian Assange


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/3] avutil/buffer: factor buffer_replace() out

[Michael Niedermayer]

On Thu, Jan 15, 2015 at 01:04:54AM +0100, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  libavutil/buffer.c |   21 -
>  1 file changed, 16 insertions(+), 5 deletions(-)

applied

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel