Re: [FFmpeg-devel] avcodec/proresenc_aw improvements

2018-10-21 Thread Martin Vignali
> > >if avtc->profile < 0 or > 4, return an error. > > Should 5 not become ProRes XQ (ap4x) as in prores_ks? > > Yes, plan to add it later. Need some test before. Martin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org

Re: [FFmpeg-devel] avcodec/proresenc_aw improvements

2018-10-20 Thread Reto Kromer
Martin Vignali wrote: >if avtc->profile < 0 or > 4, return an error. Should 5 not become ProRes XQ (ap4x) as in prores_ks? Best regards, Reto ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] avcodec/proresenc_aw improvements

2018-10-20 Thread Martin Vignali
> > See coverity bug report, avctx->profile is not checked for valid values i > think. > > Hello, Doesn't find where avctx->profile can have an invalid value seems to be checked in prores_encode_init if FF_PROFILE_UNKNOWN use pix fmt YUV422P10 or YUV444P10 to select the profile (can pix_fmt be

Re: [FFmpeg-devel] avcodec/proresenc_aw improvements

2018-07-23 Thread Martin Vignali
> > > > > Do you think it's better to only authorize few colorspace ? > > depends on what happens if "others" are stored. > if the official decoders fail with a blank screen then its probably > not a good idea to use such a value. If OTOH they ignore values they > do not support then it may be ok.

Re: [FFmpeg-devel] avcodec/proresenc_aw improvements

2018-07-22 Thread Michael Niedermayer
On Sun, Jul 22, 2018 at 01:04:29PM +0200, Martin Vignali wrote: > > > > > 001 : use scantable in prores_data instead of a duplicate one. > > > > This could negativly affect the performance of the changed inner loop > > have you checked that the changed function does not become slower ? > > > > > >

Re: [FFmpeg-devel] avcodec/proresenc_aw improvements

2018-07-22 Thread Martin Vignali
> > > 001 : use scantable in prores_data instead of a duplicate one. > > This could negativly affect the performance of the changed inner loop > have you checked that the changed function does not become slower ? > > > No, i will make some tests. > > -*buf++ = 6; > > +*buf++ =

Re: [FFmpeg-devel] avcodec/proresenc_aw improvements

2018-07-21 Thread Michael Niedermayer
On Sat, Jul 21, 2018 at 02:33:24PM +0200, Martin Vignali wrote: [...] > 004 : calculate dct part before the quantif search. Avoid to recalculate it > each time > On a basic test Prores decoding -> prores encoding, the global speed > improvment is around 2% nice speedup [...] -- Michael

Re: [FFmpeg-devel] avcodec/proresenc_aw improvements

2018-07-21 Thread Michael Niedermayer
On Sat, Jul 21, 2018 at 02:33:24PM +0200, Martin Vignali wrote: > Hello, > > Patch in attach improve some part of the prores_aw encoder. > > 001 : use scantable in prores_data instead of a duplicate one. This could negativly affect the performance of the changed inner loop have you checked

Re: [FFmpeg-devel] avcodec/proresenc_aw improvements

2018-07-21 Thread Martin Vignali
> > Am I correct that the output files also change? > Patch 002 : change the header of the output file only, not the compress data. Patch 003 : change the output file mainly for near uniform bloc, where the low scale quantif value where used. But IMHO is better by default to be close to official

Re: [FFmpeg-devel] avcodec/proresenc_aw improvements

2018-07-21 Thread Carl Eugen Hoyos
2018-07-21 14:33 GMT+02:00, Martin Vignali : > Patch in attach improve some part of the prores_aw encoder. > > 001 : use scantable in prores_data instead of a duplicate one. > 002 : use for the frame header, primaries, transfert, colorspace like in > proresenc_ks avoid color shift on some software