Re: [FFmpeg-devel] [PATCH 07/11] avcodec/mips: loongson optimize h264qpel with mmi v2

[周晓勇]

that is my fault and thank you for pointing out the mistake, it should be:


diff --git a/libavcodec/mips/h264qpel_mmi.c b/libavcodec/mips/h264qpel_mmi.c
index d641a51..737c68c 100644
--- a/libavcodec/mips/h264qpel_mmi.c
+++ b/libavcodec/mips/h264qpel_mmi.c
@@ -1901,9 +1901,9 @@ static void put_pixels8_l2_shift5_mmi(uint8_t *dst, 
int16_t *src16,
 : "memory"
 );
 
-src8  += 2L * src8Stride;
+src8  += 2 * src8Stride;
 src16 += 48;
-dst   += 2L * dstStride;
+dst   += 2 * dstStride;
 } while (h -= 2);
 }
 
@@ -2260,9 +2260,9 @@ static void avg_pixels8_l2_shift5_mmi(uint8_t *dst, 
int16_t *src16,
 : "memory"
 );
 
-src8  += 2L * src8Stride;
+src8  += 2 * src8Stride;
 src16 += 48;
-dst   += 2L * dstStride;
+dst   += 2 * dstStride;
 } while (b -= 2);
 }










At 2016-05-24 03:47:30, "Michael Niedermayer"  wrote:
>On Tue, May 17, 2016 at 03:08:13PM +0800, 周晓勇 wrote:
>> avcodec/mips/h264qpel_mmi: Version 2 of the optimizations for loongson mmi
>> 
>> 1. no longer use the register names directly and optimized code format
>> 2. to be compatible with O32, specify type of address variable with 
>> mips_reg and handle the address variable with PTR_ operator
>> 3. temporarily annotated func put_(avg_)h264_qpel16_hv_lowpass_mmi and 
>> related funcs which couldn't pass fate testing in O32 ABI
>> 4. use uld and mtc1 to workaround cpu 3A2000 gslwlc1 bug (gslwlc1 
>> instruction extension bug in O32 ABI)
>> 5. put_pixels_ an avg_pixels_ functions use hpeldsp optimizations instead
>
>[...]
>> @@ -1373,161 +1412,589 @@ static void put_h264_qpel4_hv_lowpass_mmi(uint8_t 
>> *dst, const uint8_t *src,
>>  }
>>  }
>>  
>> -static void put_h264_qpel8_hv_lowpass_mmi(uint8_t *dst, const uint8_t *src,
>> -int dstStride, int srcStride)
>> -{
>> -int16_t _tmp[104];
>> -int16_t *tmp = _tmp;
>> -int i;
>> -src -= 2*srcStride;
>> +static inline void put_h264_qpel8or16_hv1_lowpass_mmi(int16_t *tmp,
>> +const uint8_t *src, ptrdiff_t tmpStride, ptrdiff_t srcStride, int 
>> size)
>> +{
>> +int w = (size + 8) >> 2;
>> +double ftmp[11];
>> +uint64_t tmp0;
>> +uint64_t low32;
>> +
>> +src -= 2 * srcStride + 2;
>[...]
>
>> +src8  += 2L * src8Stride;
>> +src16 += 48;
>> +dst   += 2L * dstStride;
>
>why does this use long types  instead of ints while other code uses
>ints ?
>
>> +} while (h -= 2);
>> +}
>> +
>> +static void put_h264_qpel16_h_lowpass_l2_mmi(uint8_t *dst, const uint8_t 
>> *src,
>> +const uint8_t *src2, ptrdiff_t dstStride, ptrdiff_t src2Stride)
>> +{
>> +put_h264_qpel8_h_lowpass_l2_mmi(dst, src, src2, dstStride, src2Stride);
>> +put_h264_qpel8_h_lowpass_l2_mmi(dst + 8, src + 8, src2 + 8, dstStride,
>> +src2Stride);
>> +
>> +src += 8 * dstStride;
>> +dst += 8 * dstStride;
>> +src2 += 8 * src2Stride;
>
>
>
>[...]
>
>-- 
>Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
>I do not agree with what you have to say, but I'll defend to the death your
>right to say it. -- Voltaire
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Prores encoding optmizations

[compn]

On Mon, 23 May 2016 14:30:54 +0200
Håvard Espeland  wrote:

> Currently, we are also developing a version of the same encoder for
> Nvidia TX1 with Cuda/Neon SIMD for supporting multiple high quality
> streams in real time using ffmpeg. I guess there is little interest
> in merging this as well, but please let us know otherwise.

we always welcome patches, even if we dont merge them immediately.

please share with us the cuda simd when you get it working.

theres always the chance that we will convert it to yasm.

prores is a highly used codec, so there is lots of interest in making
it faster.

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

Re: [FFmpeg-devel] [PATCH 09/11] avcodec/mips: loongson optimize blockdsp with mmi v2

[Michael Niedermayer]

On Tue, May 17, 2016 at 07:14:24PM +0800, 周晓勇 wrote:
> avcodec/mips/blockdsp_mmi: Version 2 of the optimizations for loongson mmi
> 
> 1. no longer use the register names directly and optimized code format
> 2. to be compatible with O32, specify type of address variable with 
> mips_reg and handle the address variable with PTR_ operator
> 
> 
> 
> 
> 
> 
> 
> 在 2016-05-13 18:06:56，"周晓勇"  写道：
> 
> From 9e5ade4c99eb23f72a89f0054f8b5626c9acceb3 Mon Sep 17 00:00:00 2001
> From: ZhouXiaoyong 
> Date: Fri, 13 May 2016 14:30:10 +0800
> Subject: [PATCH 09/11] avcodec/mips: loongson optimize blockdsp with mmi v2
> 
> 
> ---
>  libavcodec/mips/blockdsp_mmi.c | 195 
> ++---
>  1 file changed, 103 insertions(+), 92 deletions(-)

applied

thanks

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

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus


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

Re: [FFmpeg-devel] [PATCH 10/11] avcodec/mips: loongson optimize pixblockdsp with mmi v2

[Michael Niedermayer]

On Tue, May 17, 2016 at 07:15:46PM +0800, 周晓勇 wrote:
> avcodec/mips/pixblockdsp_mmi: Version 2 of the optimizations for loongson mmi
> 
> 1. no longer use the register names directly and optimized code format
> 2. to be compatible with O32, specify type of address variable with 
> mips_reg and handle the address variable with PTR_ operator
> 
> 
> 
> 
> 
> 
> 在 2016-05-13 18:07:28，"周晓勇"  写道：
> 
> From f5f4ee7744c5354e2f76743d22ac81b1341bb7fb Mon Sep 17 00:00:00 2001
> From: ZhouXiaoyong 
> Date: Fri, 13 May 2016 14:41:33 +0800
> Subject: [PATCH 10/11] avcodec/mips: loongson optimize pixblockdsp with mmi v2

applied

thanks

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

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.


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

Re: [FFmpeg-devel] [PATCH 11/11] avcodec/mips: loongson optimize idctdsp with mmi v2

[Michael Niedermayer]

On Tue, May 17, 2016 at 07:16:42PM +0800, 周晓勇 wrote:
> avcodec/mips/idctdsp_mmi: Version 2 of the optimizations for loongson mmi
> 
> 1. no longer use the register names directly and optimized code format
> 2. to be compatible with O32, specify type of address variable with 
> mips_reg and handle the address variable with PTR_ operator
> 
> 
> 
> 
> 
> 
> 在 2016-05-13 18:07:59，"周晓勇"  写道：
> 
> From 37d9b61f529064a6a78c99f86ff371fefa2b357a Mon Sep 17 00:00:00 2001
> From: ZhouXiaoyong 
> Date: Fri, 13 May 2016 16:51:14 +0800
> Subject: [PATCH 11/11] avcodec/mips: loongson optimize idctdsp with mmi v2

applied

thanks

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

Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf


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/dca_exss: always update downmix flags

[Michael Niedermayer]

On Mon, May 23, 2016 at 06:41:27PM +0300, foo86 wrote:
> Fixes potential parsing failure when total number of channels indicated
> by EXSS asset descriptor decreases mid-stream and stale embedded downmix
> flags are referenced.
> ---
>  libavcodec/dca_exss.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)

applied

thanks

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

Modern terrorism, a quick summary: Need oil, start war with country that
has oil, kill hundread thousand in war. Let country fall into chaos,
be surprised about raise of fundamantalists. Drop more bombs, kill more
people, be surprised about them taking revenge and drop even more bombs
and strip your own citizens of their rights and freedoms. to be continued


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

Re: [FFmpeg-devel] [PATCH 07/11] avcodec/mips: loongson optimize h264qpel with mmi v2

[Michael Niedermayer]

On Tue, May 17, 2016 at 03:08:13PM +0800, 周晓勇 wrote:
> avcodec/mips/h264qpel_mmi: Version 2 of the optimizations for loongson mmi
> 
> 1. no longer use the register names directly and optimized code format
> 2. to be compatible with O32, specify type of address variable with 
> mips_reg and handle the address variable with PTR_ operator
> 3. temporarily annotated func put_(avg_)h264_qpel16_hv_lowpass_mmi and 
> related funcs which couldn't pass fate testing in O32 ABI
> 4. use uld and mtc1 to workaround cpu 3A2000 gslwlc1 bug (gslwlc1 
> instruction extension bug in O32 ABI)
> 5. put_pixels_ an avg_pixels_ functions use hpeldsp optimizations instead

[...]
> @@ -1373,161 +1412,589 @@ static void put_h264_qpel4_hv_lowpass_mmi(uint8_t 
> *dst, const uint8_t *src,
>  }
>  }
>  
> -static void put_h264_qpel8_hv_lowpass_mmi(uint8_t *dst, const uint8_t *src,
> -int dstStride, int srcStride)
> -{
> -int16_t _tmp[104];
> -int16_t *tmp = _tmp;
> -int i;
> -src -= 2*srcStride;
> +static inline void put_h264_qpel8or16_hv1_lowpass_mmi(int16_t *tmp,
> +const uint8_t *src, ptrdiff_t tmpStride, ptrdiff_t srcStride, int 
> size)
> +{
> +int w = (size + 8) >> 2;
> +double ftmp[11];
> +uint64_t tmp0;
> +uint64_t low32;
> +
> +src -= 2 * srcStride + 2;
[...]

> +src8  += 2L * src8Stride;
> +src16 += 48;
> +dst   += 2L * dstStride;

why does this use long types  instead of ints while other code uses
ints ?

> +} while (h -= 2);
> +}
> +
> +static void put_h264_qpel16_h_lowpass_l2_mmi(uint8_t *dst, const uint8_t 
> *src,
> +const uint8_t *src2, ptrdiff_t dstStride, ptrdiff_t src2Stride)
> +{
> +put_h264_qpel8_h_lowpass_l2_mmi(dst, src, src2, dstStride, src2Stride);
> +put_h264_qpel8_h_lowpass_l2_mmi(dst + 8, src + 8, src2 + 8, dstStride,
> +src2Stride);
> +
> +src += 8 * dstStride;
> +dst += 8 * dstStride;
> +src2 += 8 * src2Stride;



[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire


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

Re: [FFmpeg-devel] Reg ffmpeg sampling issue Please help me

[Lou Logan]

On Mon, 23 May 2016 16:18:01 +0530, Venkat Rao wrote:

> Hi ,
> 
>  This is Venkat, I am new bee working with this open source codec. I need
> help on this libav transcoding.
[...]

Wrong mailing list. ffmpeg-devel is only for patch submissions and
discussions related to the development of FFmpeg. FFmpeg library usage
help questions should be asked at libav-user.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH][libavfilter] codecview: improved options

[Davinder Singh]

On Mon, May 23, 2016 at 10:15 PM Davinder Singh  wrote:

> On Sun, May 15, 2016 at 1:26 AM Michael Niedermayer 
> wrote:
>
>> it would be better if the previous syntax would still work, in addition
>> to any new things
>>
>> bug reports, mailing list posts, user experience and scripts may
>> use the old syntax
>>
>>
>> [...]
>>
>>
>> --
>> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>>
>> Good people do not need laws to tell them to act responsibly, while bad
>> people will find a way around the laws. -- Plato
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
> [...]
>

minor change:
removed frame type condition (... || s->frame_type) from PATCH line 62 and
81, as specifying only frame_type won't do anything.

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

[FFmpeg-devel] [PATCH] avcodec/dca_exss: always update downmix flags

[foo86]

Fixes potential parsing failure when total number of channels indicated
by EXSS asset descriptor decreases mid-stream and stale embedded downmix
flags are referenced.
---
 libavcodec/dca_exss.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/libavcodec/dca_exss.c b/libavcodec/dca_exss.c
index 87b2f42..28f138f 100644
--- a/libavcodec/dca_exss.c
+++ b/libavcodec/dca_exss.c
@@ -112,12 +112,10 @@ static int parse_descriptor(DCAExssParser *s, 
DCAExssAsset *asset)
 int nspeakers[8];
 
 // Embedded stereo flag
-if (asset->nchannels_total > 2)
-asset->embedded_stereo = get_bits1(>gb);
+asset->embedded_stereo = asset->nchannels_total > 2 && 
get_bits1(>gb);
 
 // Embedded 6 channels flag
-if (asset->nchannels_total > 6)
-asset->embedded_6ch = get_bits1(>gb);
+asset->embedded_6ch = asset->nchannels_total > 6 && 
get_bits1(>gb);
 
 // Speaker mask enabled flag
 if (asset->spkr_mask_enabled = get_bits1(>gb)) {
-- 
2.8.1

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

Re: [FFmpeg-devel] [PATCH] lavf: add textdata virtual demuxer and demuxer

[Moritz Barsnick]

On Thu, May 19, 2016 at 19:29:40 +0200, Stefano Sabatini wrote:
> > > +ffmpeg -i INPUT -codec copy -map 0 -an -vn data.fftd

BTW, is this possibly the first and only muxer which can actually remux
timed_id3? I have been trying to *extract* timed_id3, but haven't
figured out into which format I can dump data streams.

> Something like this should work:
> ffmpeg -i INPUT -codec copy -map 0 -an -vn data.fftd

It turns out that my timed_id3 streams are either empty, or are not
being read. AFAICT, the information I was hoping to find in there was
apparently actually provided by Icy-metadata. (I was expecting either
track information for radio programs or subtitles for video streams in
the timed_id3.)

(I had been dumping HLS's MPEG-TS segments to MPEG-TS files, and they
were showing timed_id3 data streams.)

So, no testing possibly from me, at least until I know for sure what's
in those streams of mine.

Moritz

P.S.: Does the patch trigger deprecation warnings due to its own
  nature, or due to something earlier in the chain? ffmpeg-cli
  even?

barsnick@sunshine:~/Downloads/Radio/NRK/Amund/2015-12-28 > ffmpeg -i 
nrk-outputfile-NzyUCD.ts -map 0:d -c copy nrk-outputfile-NzyUCD.fftd
ffmpeg version N-80066-g566be4f Copyright (c) 2000-2016 the FFmpeg developers
  built with icc (ICC) 14.0.3 20140422
  configuration: --prefix=/usr/new/tools/video/install/ffmpeg/2016-05-22 
--cc=icc --cxx=icpc --enable-gpl --enable-version3 --enable-nonfree 
--disable-shared --enable-gnutls --enable-libcdio --enable-libfreetype 
--enable-libx264 --enable-libvpx --enable-libmp3lame --enable-openal 
--enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libtwolame 
--enable-libopenjpeg --enable-librtmp --enable-libass --enable-libv4l2 
--enable-libvidstab --enable-libfdk-aac --enable-libsmbclient --enable-libzvbi 
--enable-libtesseract --enable-libzmq
  libavutil  55. 24.100 / 55. 24.100
  libavcodec 57. 43.100 / 57. 43.100
  libavformat57. 37.100 / 57. 37.100
  libavdevice57.  0.101 / 57.  0.101
  libavfilter 6. 46.100 /  6. 46.100
  libswscale  4.  1.100 /  4.  1.100
  libswresample   2.  0.101 /  2.  0.101
  libpostproc54.  0.100 / 54.  0.100
[mpegts @ 0xaf60900] start time for stream 1 is not set in 
estimate_timings_from_pts
Input #0, mpegts, from 'nrk-outputfile-NzyUCD.ts':
  Duration: 02:56:59.75, start: 10.099667, bitrate: 176 kb/s
  Program 1
Stream #0:0[0x100]: Audio: aac (LC) ([15][0][0][0] / 0x000F), 48000 Hz, 
stereo, fltp, 175 kb/s
Stream #0:1[0x101]: Data: timed_id3 (ID3  / 0x20334449)
[fftextdata @ 0xaf687a0] Using AVStream.codec to pass codec parameters to 
muxers is deprecated, use AVStream.codecpar instead.
Output #0, fftextdata, to 'nrk-outputfile-NzyUCD.fftd':
  Metadata:
encoder : Lavf57.37.100
Stream #0:0: Data: timed_id3 (ID3  / 0x20334449)
Stream mapping:
  Stream #0:1 -> #0:0 (copy)
Press [q] to stop, [?] for help
size=   0kB time=00:00:00.00 bitrate=N/A speed=   0x
video:0kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing 
overhead: unknown
Output file is empty, nothing was encoded (check -ss / -t / -frames parameters 
if used)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/libopenh264enc: update to openh264 1.6

[Gregory J Wolfe]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Hendrik Leppkes
> Sent: Saturday, May 21, 2016 3:25 AM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] lavc/libopenh264enc: update to
> openh264 1.6
> 
> On Mon, Mar 7, 2016 at 6:05 PM, Stefano Sabatini 
> wrote:
> > In particular, the slice mode API was changed in commit:
> >
> > commit 33c378f7b791310e4cb64b53e2bb8f3f3bded105
> > Author: sijchen 
> > Date:   Tue Nov 10 09:50:06 2015 -0800
> >
> > change API for slicing part for easier usage (the UseLoadBalancing flag 
> > is
> still under working)
> >
> > This fixes compilation with latest version of openh264.
> > ---
> 
> From the author of this wrapper:
> 
> [20:23:22]  just fwiw, the openh264 patch that somebody just
> sent, for fixing compilation with 1.6 (which is not released) is just
> awful. it changes defaults for lots of options, it changes names for
> options, etc, all in one single patch (which breaks compilation with
> any earlier version)
> [20:23:47]  if one wants to add support for 1.6, it shouldn't
> break support for earlier versions. and 1.6 isn't released, so the
> actual api for that version may still change
> [20:24:06]  so I would just tell people to stick it and not try
> to "support" an unreleased version which is still open for changes
> 
> I agree with this assessment, dropping support for any and all
> released versions of the library in favor of a unreleased
> in-development version seems bad.
> Can't we support both, and address his comments about changing the
> options etc?
> 
> - Hendrik

FWIW, we at Kodak Alaris are actively using openh264 1.6 (OK so it's
not officially released) with FFmpeg.  I have manually applied the 1.6
related patches, AND I have an FFmpeg change (soon to be submitted)
to support other new capabilities in 1.6.  What I would like to see is
openh264 1.6 become an official release (soon!), with interface changes
conditionally compiled so as not to break builds using older versions.
Also, perhaps the  pre-1.6 options could be transparently mapped into
the new 1.6 options so that there would be a smooth transition.

If it would help move this along, I will tentatively volunteer to the do
some or all of the work.

Greg W., Kodak Alaris

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

Re: [FFmpeg-devel] [PATCH] fix few compiler warnings

[Hendrik Leppkes]

On Mon, May 23, 2016 at 1:59 PM, Michael Niedermayer
 wrote:
> On Mon, May 23, 2016 at 07:24:23AM -0400, Ronald S. Bultje wrote:
>> Hi,
>>
>> On Sun, May 22, 2016 at 11:39 PM, Michael Niedermayer <
>> mich...@niedermayer.cc> wrote:
>>
>> > On Sun, May 22, 2016 at 01:51:05AM +, Davinder Singh wrote:
>> > > On Sun, May 22, 2016 at 2:09 AM Michael Niedermayer
>> > 
>> > > wrote:
>> > >
>> > > > On Sat, May 21, 2016 at 02:21:17PM +, Davinder Singh wrote:
>> > > > > hi,
>> > > > >
>> > > > > this patch fixes following compiler warnings:
>> > > > >
>> > > > > libavcodec/cfhd.c:346:78: warning: format specifies type 'unsigned
>> > short'
>> > > > > but the argument has type 'int' [-Wformat]
>> > > > > av_log(avctx, AV_LOG_DEBUG, "Small chunk length %"PRIu16"
>> > > > > %s\n", data * 4, tag < 0 ? "optional" : "required");
>> > > > > ~~
>> > > > >   ^~~~
>> > > > > libavcodec/cfhd.c:472:110: warning: format specifies type 'unsigned
>> > > > short'
>> > > > > but the argument has type 'int' [-Wformat]
>> > > > > av_log(avctx, AV_LOG_DEBUG, "Start of lowpass coeffs
>> > > > component
>> > > > > %"PRIu16" height:%d, width:%d\n", s->channel_num, lowpass_height,
>> > > > > lowpass_width);
>> > > > >
>> > > > >  ~~^~
>> > > > > libavcodec/cfhd.c:490:77: warning: format specifies type 'unsigned
>> > short'
>> > > > > but the argument has type 'int' [-Wformat]
>> > > > > av_log(avctx, AV_LOG_DEBUG, "Lowpass coefficients
>> > > > %"PRIu16"\n",
>> > > > > lowpass_width * lowpass_height);
>> > > > >   ~~
>> > > > >  ^~
>> > > > >
>> > > > >
>> > > > >
>> > > > > libavcodec/dv_tablegen.c:30:60: warning: format specifies type
>> > 'char' but
>> > > > > the argument has type 'uint32_t' (aka 'unsigned int') [-Wformat]
>> > > > >"{0x%"PRIx32", %"PRId8"}", data[i].vlc,
>> > data[i].size)
>> > > > >
>> > ~~~^~~~
>> > > > > libavcodec/tableprint.h:37:29: note: expanded from macro
>> > > > > 'WRITE_1D_FUNC_ARGV'
>> > > > >printf(" "fmtstr",", __VA_ARGS__);\
>> > > > > ^~~
>> > > > > libavcodec/dv_tablegen.c:30:60: warning: format specifies type
>> > 'char' but
>> > > > > the argument has type 'uint32_t' (aka 'unsigned int') [-Wformat]
>> > > > >"{0x%"PRIx32", %"PRId8"}", data[i].vlc,
>> > data[i].size)
>> > > > >
>> > ~~~^~~~
>> > > > >
>> > > > >
>> > > > >
>> > > > > libavfilter/af_hdcd.c:896:57: warning: shifting a negative signed
>> > value
>> > > > is
>> > > > > undefined [-Wshift-negative-value]
>> > > > > state->readahead = readaheadtab[bits & ~(-1 << 8)];
>> > > > >
>> > > > >
>> > > > >
>> > > > > libavfilter/vf_hwdownload.c:59:5: warning: ignoring return value of
>> > > > > function declared with warn_unused_result attribute [-Wunused-result]
>> > > > > ff_formats_ref(infmts,  >inputs[0]->out_formats);
>> > > > > ^~ ~~~
>> > > > > libavfilter/vf_hwdownload.c:60:5: warning: ignoring return value of
>> > > > > function declared with warn_unused_result attribute [-Wunused-result]
>> > > > > ff_formats_ref(outfmts, >outputs[0]->in_formats);
>> > > > > ^~ ~~~
>> > > > >
>> > > > >
>> > > > >
>> > > > > libavutil/opencl.c:456:17: warning: variable 'kernel_source' is used
>> > > > > uninitialized whenever 'for' loop exits because its condition is
>> > false
>> > > > > [-Wsometimes-uninitialized]
>> > > > > for (i = 0; i < opencl_ctx.kernel_code_count; i++) {
>> > > > > ^~~~
>> > > > > libavutil/opencl.c:466:10: note: uninitialized use occurs here
>> > > > > if (!kernel_source) {
>> > > > >  ^
>> > > > > libavutil/opencl.c:456:17: note: remove the condition if it is always
>> > > > true
>> > > > > for (i = 0; i < opencl_ctx.kernel_code_count; i++) {
>> > > > > ^~~~
>> > > > > libavutil/opencl.c:448:30: note: initialize the variable
>> > 'kernel_source'
>> > > > to
>> > > > > silence this warning
>> > > > > const char *kernel_source;
>> > > > >  ^
>> > > > >   = NULL
>> > > >
>> > > > >  libavcodec/cfhd.c   |6 +++---
>> > > > >  libavcodec/dv_tablegen.c|2 +-
>> > > > >  libavfilter/af_hdcd.c   |2 +-
>> > > > >  libavfilter/vf_hwdownload.c |6 --
>> > > > >  libavutil/opencl.c  |2 +-
>> > > >
>> > > > please split this patch
>> > > > the fixed warnings are unrelated to each other and possibly 

Re: [FFmpeg-devel] Prores encoding optmizations

[Håvard Espeland]

>> Have you test your optimizations in the other prores encoder (prores
> kostya) (who i think have more features (interlaced encoding and 444
> versions)) ?

No, we haven’t done this yet. The goal for us was performance without loosing 
accuracy. We choose Anatoliy simply because it was faster.
It doesn’t look like the intrinsics is acceptable in ffmpeg. If so, we will use 
this for our needs and not continue with pursuing to clean up the code and 
submit this upstream. I have shared the WIP of the patch in this thread, so 
anyone might feel free to port the code to asm and submit it.

Currently, we are also developing a version of the same encoder for Nvidia TX1 
with Cuda/Neon SIMD for supporting multiple high quality streams in real time 
using ffmpeg. I guess there is little interest in merging this as well, but 
please let us know otherwise.

In all cases, we will of course respect the ffmpeg license and share the source 
code with our customers.

Best,

Håvard Espeland
CTO
LABO Mixed Realities AS


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

Re: [FFmpeg-devel] Prores encoding optmizations

[Håvard Espeland]

Hi Paul,

> On 23 May 2016, at 13:13, Paul B Mahol  wrote:
> 
> On 5/23/16, Haavard Espeland  wrote:
>> Hi guys,
>> 
>> We have been working on Prores Anatoliy optimizations to get the speed up on
>> an embedded x86 platform. Fdct (10bit), scaling and encoding of code words
>> have been optimized with AVX2 instructions, and the performance is increased
>> by roughly 45% for the standard profile Prores 4:2:2 on our machine without
>> any significant PSNR or file size differences from master.
>> 
>> It is written using SIMD intrinsics, and I do understand you have a slightly
>> negative view on instrinsics in ffmpeg, but we do not have the resources to
>> rewrite this in nasm/yasm.
>> 
>> Is there any point in cleaning up this patch for submission, or should we
>> just keep it locally in our tree?
> 
> I would like to see that code.

Please find attached the WIP patch against master. It is not meant for review 
or as a suggestion for inclusion since it requires significant cleanup / 
refactoring before that. What I wanted to find out if doing this is worth the 
effort, i.e., will it be considered for inclusion without a rewrite to asm, 
which we cannot do now, unfortunately.

Remember to configure with ./configure --extra-cflags=“--march=native” since we 
haven’t made a proper way to build with intrinsics yet.




prores_avx2_wip.patch
Description: Binary data


Best,

Håvard

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

Re: [FFmpeg-devel] Prores encoding optmizations

[Martin Vignali]

2016-05-23 13:44 GMT+02:00 Håvard Espeland :

>
> > The SIMD won't be accepted if it's intrinsics. The codeword encoding is
> not
> > SIMD, is it? So that may be worth upstreaming.
>
> All optimizations we’ve done are SIMD so it does not apply. Basically what
> we do for codewords is to process the shifting/masking for eight codewords
> at a time. The put_bits calls are of course executed sequentially as before.
>
>
> > When you say "no significant PSNR or file size differences", though, it
> > sounds like the output changed? Did it? Can you explain why?
>
> For the tractor sequence we get the following results.
> time ./ffmpeg -y -i ~/Downloads/tractor_1080p25.y4m -codec:v prores_aw
> -an  -profile:v 2 /tmp/video.mov
>
> ffmpeg-master:
> frame=  690 fps= 22 q=-0.0 Lsize=  611897kB time=00:00:27.56
> bitrate=181881.2kbits/s speed=0.876x
> video:611891kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB
> muxing overhead: 0.000996%
>
> real0m31.491s
> user2m3.452s
> sys 0m1.168s
> [Parsed_psnr_0 @ 0x3ab6da0] PSNR y:49.596357 u:54.113644 v:54.561940
> average:51.331354 min:49.684050 max:53.658792
>
> AVX2 optimizations:
> frame=  690 fps= 32 q=-0.0 Lsize=  611896kB time=00:00:27.56
> bitrate=181881.0kbits/s speed=1.27x
> video:611890kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB
> muxing overhead: 0.000996%
>
> real0m23.396s
> user1m25.092s
> sys 0m1.252s
> [Parsed_psnr_0 @ 0x2838da0] PSNR y:49.595523 u:54.114016 v:54.562335
> average:51.330827 min:49.683836 max:53.658654
>
> As you can see, there is 1kb size difference in the output file and some
> minor variations in psnr. I believe the difference might be due to rounding
> since we are using float point math and round towards zero, while ffmpeg
> master uses fixed points for dct. If we pursue to clean up the code and
> send it upstream we might also look into improving this so we get identical
> results.
>
> Have you test your optimizations in the other prores encoder (prores
kostya) (who i think have more features (interlaced encoding and 444
versions)) ?


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

Re: [FFmpeg-devel] [PATCH] fix few compiler warnings

[Michael Niedermayer]

On Mon, May 23, 2016 at 07:24:23AM -0400, Ronald S. Bultje wrote:
> Hi,
> 
> On Sun, May 22, 2016 at 11:39 PM, Michael Niedermayer <
> mich...@niedermayer.cc> wrote:
> 
> > On Sun, May 22, 2016 at 01:51:05AM +, Davinder Singh wrote:
> > > On Sun, May 22, 2016 at 2:09 AM Michael Niedermayer
> > 
> > > wrote:
> > >
> > > > On Sat, May 21, 2016 at 02:21:17PM +, Davinder Singh wrote:
> > > > > hi,
> > > > >
> > > > > this patch fixes following compiler warnings:
> > > > >
> > > > > libavcodec/cfhd.c:346:78: warning: format specifies type 'unsigned
> > short'
> > > > > but the argument has type 'int' [-Wformat]
> > > > > av_log(avctx, AV_LOG_DEBUG, "Small chunk length %"PRIu16"
> > > > > %s\n", data * 4, tag < 0 ? "optional" : "required");
> > > > > ~~
> > > > >   ^~~~
> > > > > libavcodec/cfhd.c:472:110: warning: format specifies type 'unsigned
> > > > short'
> > > > > but the argument has type 'int' [-Wformat]
> > > > > av_log(avctx, AV_LOG_DEBUG, "Start of lowpass coeffs
> > > > component
> > > > > %"PRIu16" height:%d, width:%d\n", s->channel_num, lowpass_height,
> > > > > lowpass_width);
> > > > >
> > > > >  ~~^~
> > > > > libavcodec/cfhd.c:490:77: warning: format specifies type 'unsigned
> > short'
> > > > > but the argument has type 'int' [-Wformat]
> > > > > av_log(avctx, AV_LOG_DEBUG, "Lowpass coefficients
> > > > %"PRIu16"\n",
> > > > > lowpass_width * lowpass_height);
> > > > >   ~~
> > > > >  ^~
> > > > >
> > > > >
> > > > >
> > > > > libavcodec/dv_tablegen.c:30:60: warning: format specifies type
> > 'char' but
> > > > > the argument has type 'uint32_t' (aka 'unsigned int') [-Wformat]
> > > > >"{0x%"PRIx32", %"PRId8"}", data[i].vlc,
> > data[i].size)
> > > > >
> > ~~~^~~~
> > > > > libavcodec/tableprint.h:37:29: note: expanded from macro
> > > > > 'WRITE_1D_FUNC_ARGV'
> > > > >printf(" "fmtstr",", __VA_ARGS__);\
> > > > > ^~~
> > > > > libavcodec/dv_tablegen.c:30:60: warning: format specifies type
> > 'char' but
> > > > > the argument has type 'uint32_t' (aka 'unsigned int') [-Wformat]
> > > > >"{0x%"PRIx32", %"PRId8"}", data[i].vlc,
> > data[i].size)
> > > > >
> > ~~~^~~~
> > > > >
> > > > >
> > > > >
> > > > > libavfilter/af_hdcd.c:896:57: warning: shifting a negative signed
> > value
> > > > is
> > > > > undefined [-Wshift-negative-value]
> > > > > state->readahead = readaheadtab[bits & ~(-1 << 8)];
> > > > >
> > > > >
> > > > >
> > > > > libavfilter/vf_hwdownload.c:59:5: warning: ignoring return value of
> > > > > function declared with warn_unused_result attribute [-Wunused-result]
> > > > > ff_formats_ref(infmts,  >inputs[0]->out_formats);
> > > > > ^~ ~~~
> > > > > libavfilter/vf_hwdownload.c:60:5: warning: ignoring return value of
> > > > > function declared with warn_unused_result attribute [-Wunused-result]
> > > > > ff_formats_ref(outfmts, >outputs[0]->in_formats);
> > > > > ^~ ~~~
> > > > >
> > > > >
> > > > >
> > > > > libavutil/opencl.c:456:17: warning: variable 'kernel_source' is used
> > > > > uninitialized whenever 'for' loop exits because its condition is
> > false
> > > > > [-Wsometimes-uninitialized]
> > > > > for (i = 0; i < opencl_ctx.kernel_code_count; i++) {
> > > > > ^~~~
> > > > > libavutil/opencl.c:466:10: note: uninitialized use occurs here
> > > > > if (!kernel_source) {
> > > > >  ^
> > > > > libavutil/opencl.c:456:17: note: remove the condition if it is always
> > > > true
> > > > > for (i = 0; i < opencl_ctx.kernel_code_count; i++) {
> > > > > ^~~~
> > > > > libavutil/opencl.c:448:30: note: initialize the variable
> > 'kernel_source'
> > > > to
> > > > > silence this warning
> > > > > const char *kernel_source;
> > > > >  ^
> > > > >   = NULL
> > > >
> > > > >  libavcodec/cfhd.c   |6 +++---
> > > > >  libavcodec/dv_tablegen.c|2 +-
> > > > >  libavfilter/af_hdcd.c   |2 +-
> > > > >  libavfilter/vf_hwdownload.c |6 --
> > > > >  libavutil/opencl.c  |2 +-
> > > >
> > > > please split this patch
> > > > the fixed warnings are unrelated to each other and possibly differnt
> > > > developers would like to reply to different parts
> > > >
> > > > [...]
> > > >
> > > > --
> > > > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> > > >
> > > 

Re: [FFmpeg-devel] [PATCH] fix few compiler warnings

[Michael Niedermayer]

On Sun, May 22, 2016 at 01:51:05AM +, Davinder Singh wrote:
[...]

>  opencl.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> b3b89a601cc0447677a9f0f375c20f1f63d66f42  
> 0005-libavutil-opencl-fixed-uninitialized-var-warning.patch
> From 9259a055b908c12c7ab7c5f08aae95f3cdaacfa8 Mon Sep 17 00:00:00 2001
> From: dsmudhar 
> Date: Sun, 22 May 2016 06:29:27 +0530
> Subject: [PATCH 5/7] libavutil/opencl: fixed uninitialized var warning
> 
> ---
>  libavutil/opencl.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavutil/opencl.c b/libavutil/opencl.c
> index 08b5034..af35770 100644
> --- a/libavutil/opencl.c
> +++ b/libavutil/opencl.c
> @@ -445,7 +445,7 @@ cl_program av_opencl_compile(const char *program_name, 
> const char *build_opts)
>  int i;
>  cl_int status, build_status;
>  int kernel_code_idx = 0;
> -const char *kernel_source;
> +const char *kernel_source = NULL;

applied

thx

[...]

-- 
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

Re: [FFmpeg-devel] Prores encoding optmizations

[Håvard Espeland]

> The SIMD won't be accepted if it's intrinsics. The codeword encoding is not
> SIMD, is it? So that may be worth upstreaming.

All optimizations we’ve done are SIMD so it does not apply. Basically what we 
do for codewords is to process the shifting/masking for eight codewords at a 
time. The put_bits calls are of course executed sequentially as before.


> When you say "no significant PSNR or file size differences", though, it
> sounds like the output changed? Did it? Can you explain why?

For the tractor sequence we get the following results.
time ./ffmpeg -y -i ~/Downloads/tractor_1080p25.y4m -codec:v prores_aw -an  
-profile:v 2 /tmp/video.mov

ffmpeg-master:
frame=  690 fps= 22 q=-0.0 Lsize=  611897kB time=00:00:27.56 
bitrate=181881.2kbits/s speed=0.876x
video:611891kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB 
muxing overhead: 0.000996%

real0m31.491s
user2m3.452s
sys 0m1.168s
[Parsed_psnr_0 @ 0x3ab6da0] PSNR y:49.596357 u:54.113644 v:54.561940 
average:51.331354 min:49.684050 max:53.658792

AVX2 optimizations:
frame=  690 fps= 32 q=-0.0 Lsize=  611896kB time=00:00:27.56 
bitrate=181881.0kbits/s speed=1.27x
video:611890kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB 
muxing overhead: 0.000996%

real0m23.396s
user1m25.092s
sys 0m1.252s
[Parsed_psnr_0 @ 0x2838da0] PSNR y:49.595523 u:54.114016 v:54.562335 
average:51.330827 min:49.683836 max:53.658654

As you can see, there is 1kb size difference in the output file and some minor 
variations in psnr. I believe the difference might be due to rounding since we 
are using float point math and round towards zero, while ffmpeg master uses 
fixed points for dct. If we pursue to clean up the code and send it upstream we 
might also look into improving this so we get identical results.

Best,

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

Re: [FFmpeg-devel] [PATCH] fix few compiler warnings

[Ronald S. Bultje]

Hi,

On Sun, May 22, 2016 at 11:39 PM, Michael Niedermayer <
mich...@niedermayer.cc> wrote:

> On Sun, May 22, 2016 at 01:51:05AM +, Davinder Singh wrote:
> > On Sun, May 22, 2016 at 2:09 AM Michael Niedermayer
> 
> > wrote:
> >
> > > On Sat, May 21, 2016 at 02:21:17PM +, Davinder Singh wrote:
> > > > hi,
> > > >
> > > > this patch fixes following compiler warnings:
> > > >
> > > > libavcodec/cfhd.c:346:78: warning: format specifies type 'unsigned
> short'
> > > > but the argument has type 'int' [-Wformat]
> > > > av_log(avctx, AV_LOG_DEBUG, "Small chunk length %"PRIu16"
> > > > %s\n", data * 4, tag < 0 ? "optional" : "required");
> > > > ~~
> > > >   ^~~~
> > > > libavcodec/cfhd.c:472:110: warning: format specifies type 'unsigned
> > > short'
> > > > but the argument has type 'int' [-Wformat]
> > > > av_log(avctx, AV_LOG_DEBUG, "Start of lowpass coeffs
> > > component
> > > > %"PRIu16" height:%d, width:%d\n", s->channel_num, lowpass_height,
> > > > lowpass_width);
> > > >
> > > >  ~~^~
> > > > libavcodec/cfhd.c:490:77: warning: format specifies type 'unsigned
> short'
> > > > but the argument has type 'int' [-Wformat]
> > > > av_log(avctx, AV_LOG_DEBUG, "Lowpass coefficients
> > > %"PRIu16"\n",
> > > > lowpass_width * lowpass_height);
> > > >   ~~
> > > >  ^~
> > > >
> > > >
> > > >
> > > > libavcodec/dv_tablegen.c:30:60: warning: format specifies type
> 'char' but
> > > > the argument has type 'uint32_t' (aka 'unsigned int') [-Wformat]
> > > >"{0x%"PRIx32", %"PRId8"}", data[i].vlc,
> data[i].size)
> > > >
> ~~~^~~~
> > > > libavcodec/tableprint.h:37:29: note: expanded from macro
> > > > 'WRITE_1D_FUNC_ARGV'
> > > >printf(" "fmtstr",", __VA_ARGS__);\
> > > > ^~~
> > > > libavcodec/dv_tablegen.c:30:60: warning: format specifies type
> 'char' but
> > > > the argument has type 'uint32_t' (aka 'unsigned int') [-Wformat]
> > > >"{0x%"PRIx32", %"PRId8"}", data[i].vlc,
> data[i].size)
> > > >
> ~~~^~~~
> > > >
> > > >
> > > >
> > > > libavfilter/af_hdcd.c:896:57: warning: shifting a negative signed
> value
> > > is
> > > > undefined [-Wshift-negative-value]
> > > > state->readahead = readaheadtab[bits & ~(-1 << 8)];
> > > >
> > > >
> > > >
> > > > libavfilter/vf_hwdownload.c:59:5: warning: ignoring return value of
> > > > function declared with warn_unused_result attribute [-Wunused-result]
> > > > ff_formats_ref(infmts,  >inputs[0]->out_formats);
> > > > ^~ ~~~
> > > > libavfilter/vf_hwdownload.c:60:5: warning: ignoring return value of
> > > > function declared with warn_unused_result attribute [-Wunused-result]
> > > > ff_formats_ref(outfmts, >outputs[0]->in_formats);
> > > > ^~ ~~~
> > > >
> > > >
> > > >
> > > > libavutil/opencl.c:456:17: warning: variable 'kernel_source' is used
> > > > uninitialized whenever 'for' loop exits because its condition is
> false
> > > > [-Wsometimes-uninitialized]
> > > > for (i = 0; i < opencl_ctx.kernel_code_count; i++) {
> > > > ^~~~
> > > > libavutil/opencl.c:466:10: note: uninitialized use occurs here
> > > > if (!kernel_source) {
> > > >  ^
> > > > libavutil/opencl.c:456:17: note: remove the condition if it is always
> > > true
> > > > for (i = 0; i < opencl_ctx.kernel_code_count; i++) {
> > > > ^~~~
> > > > libavutil/opencl.c:448:30: note: initialize the variable
> 'kernel_source'
> > > to
> > > > silence this warning
> > > > const char *kernel_source;
> > > >  ^
> > > >   = NULL
> > >
> > > >  libavcodec/cfhd.c   |6 +++---
> > > >  libavcodec/dv_tablegen.c|2 +-
> > > >  libavfilter/af_hdcd.c   |2 +-
> > > >  libavfilter/vf_hwdownload.c |6 --
> > > >  libavutil/opencl.c  |2 +-
> > >
> > > please split this patch
> > > the fixed warnings are unrelated to each other and possibly differnt
> > > developers would like to reply to different parts
> > >
> > > [...]
> > >
> > > --
> > > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> > >
> > > I have often repented speaking, but never of holding my tongue.
> > > -- Xenocrates
> > > ___
> > > ffmpeg-devel mailing list
> > > ffmpeg-devel@ffmpeg.org
> > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > >
>
> >  af_hdcd.c |2 +-
> >  1 file 

Re: [FFmpeg-devel] Prores encoding optmizations

[Paul B Mahol]

On 5/23/16, Haavard Espeland  wrote:
> Hi guys,
>
> We have been working on Prores Anatoliy optimizations to get the speed up on
> an embedded x86 platform. Fdct (10bit), scaling and encoding of code words
> have been optimized with AVX2 instructions, and the performance is increased
> by roughly 45% for the standard profile Prores 4:2:2 on our machine without
> any significant PSNR or file size differences from master.
>
> It is written using SIMD intrinsics, and I do understand you have a slightly
> negative view on instrinsics in ffmpeg, but we do not have the resources to
> rewrite this in nasm/yasm.
>
> Is there any point in cleaning up this patch for submission, or should we
> just keep it locally in our tree?

I would like to see that code.

>
> Best regards,
>
> Haavard Espeland
> CTO
> LABO Mixed Realities AS
> ___
> 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] Prores encoding optmizations

[Ronald S. Bultje]

Hi Havard,

On Mon, May 23, 2016 at 6:36 AM, Håvard Espeland  wrote:

> Hi guys,
>
> We have been working on Prores Anatoliy optimizations to get the speed up
> on an embedded x86 platform. Fdct (10bit), scaling and encoding of code
> words have been optimized with AVX2 instructions, and the performance is
> increased by roughly 45% for the standard profile Prores 4:2:2 on our
> machine without any significant PSNR or file size differences from master.
>
> It is written using SIMD intrinsics, and I do understand you have a
> slightly negative view on instrinsics in ffmpeg, but we do not have the
> resources to rewrite this in nasm/yasm.
>
> Is there any point in cleaning up this patch for submission, or should we
> just keep it locally in our tree?


The SIMD won't be accepted if it's intrinsics. The codeword encoding is not
SIMD, is it? So that may be worth upstreaming.

When you say "no significant PSNR or file size differences", though, it
sounds like the output changed? Did it? Can you explain why?

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

[FFmpeg-devel] Reg ffmpeg sampling issue Please help me

[Venkat Rao]

Hi ,

 This is Venkat, I am new bee working with this open source codec. I need
help on this libav transcoding.
 I need to develop audio Transcoder which takes input as a audio raw file
and and will get information externally like parameters: what type of
codec, bit rate, number of channels etc. and I need to convert this raw
file to mp3 or wav format.

I am using example code "transcoding.c" file. which convert same codec
form. I modified this code for taking raw file and converting to mp3, then
facing issue like "[libmp3lame @ 0x620be0] more samples than frame size
(avcodec_encode_audio2)".

Please help me on this, help me how can I improve my code to support raw
input and convert to mp3 format. Thanks :)
-- 

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