[FFmpeg-devel] [PATCH 3/3] swscale: ayuv16le output support

[Robert Krüger]

On Tue, Jul 14, 2015 at 3:17 PM, Paul B Mahol <onemda at gmail.com> wrote:

> Dana 14. 7. 2015. 13:09 osoba "Robert Krüger" <krueger at lesspain.de>
> napisala je:
> >
> > On Mon, Jul 6, 2015 at 3:12 PM, Michael Niedermayer <michaelni at gmx.at>
> > wrote:
> >
> > > On Mon, Jul 06, 2015 at 03:10:41PM +0200, Michael Niedermayer wrote:
> > > > On Mon, Jul 06, 2015 at 11:56:21AM +0000, Paul B Mahol wrote:
> > > > > Signed-off-by: Paul B Mahol <onemda at gmail.com>
> > > > > ---
> > > > >  libswscale/output.c                      | 48
> > > ++++++++++++++++++++++++++++++++
> > > > >  libswscale/utils.c                       |  2 +-
> > > > >  tests/ref/fate/filter-pixfmts-copy       |  1 +
> > > > >  tests/ref/fate/filter-pixfmts-crop       |  1 +
> > > > >  tests/ref/fate/filter-pixfmts-field      |  1 +
> > > > >  tests/ref/fate/filter-pixfmts-fieldorder |  1 +
> > > > >  tests/ref/fate/filter-pixfmts-hflip      |  1 +
> > > > >  tests/ref/fate/filter-pixfmts-il         |  1 +
> > > > >  tests/ref/fate/filter-pixfmts-null       |  1 +
> > > > >  tests/ref/fate/filter-pixfmts-scale      |  1 +
> > > > >  tests/ref/fate/filter-pixfmts-vflip      |  1 +
> > > > >  11 files changed, 58 insertions(+), 1 deletion(-)
> > > >
> > > >  filter-pixfmts-fieldorder
> > > > TEST    filter-pixfmts-hflip
> > > > reference file './tests/ref/fate/filter-pixdesc-ayuv16le' not found
> > > > ./tests/fate-run.sh: 282: ./tests/fate-run.sh: cannot open
> > > tests/data/fate/filter-pixdesc-ayuv16le.diff: No such file
> > > > Test filter-pixdesc-ayuv16le failed. Look at
> > > tests/data/fate/filter-pixdesc-ayuv16le.err for details.
> > > > make: *** [fate-filter-pixdesc-ayuv16le] Error 1
> > > >
> > > > patch should be ok otherwise
> > >
> > > (assuming roberts tests find no issues of course)
> > >
> > >
> > Verified that this creates valid input for the Apple Prores Encoder which
> > is great.
> >
> > A side-note: In our transcoding set-up I just quickly compared the
> > performance of that conversion (in the test case from yuv420p ->
> AYUV16LE)
> > is still slower than our previous setup with conversion yuv420p ->
> > YUVA444P10LE using swscale and then doing the YUVA444P10LE -> AYUV16LE
> > conversion in Java but I guess that is because there is no asm for this.
> >
>
> By how much is it slower?
>
>
it's roughly like this (sample is 1080p):

swscale conversion YUV420P -> YUVA444P16LE: 10ms + Java Conversion
YUVA444P16LE -> AYUV16LE: 20ms

vs.

swscale conversion YUV420P ->  AYUV16LE: 40ms

So the old variant takes 75% of the time of the new one but it's probably
an unfair comparison if the path YUV420P -> YUVA444P16LE uses asm and the
Java converter in this case only repacks with no subsampling and the JIT
does a decent job at optimizing this.