On Tue, Jul 14, 2015 at 3:17 PM, Paul B Mahol <one...@gmail.com> wrote:
> Dana 14. 7. 2015. 13:09 osoba "Robert Krüger" <krue...@lesspain.de> > napisala je: > > > > On Mon, Jul 6, 2015 at 3:12 PM, Michael Niedermayer <michae...@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 <one...@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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
