[FFmpeg-devel] [RFC]lavc/ffv1dec: Scale msb-packed output to full 16bit
michael at niedermayer.cc
Thu Nov 17 23:11:49 EET 2016
On Thu, Nov 17, 2016 at 09:13:55PM +0100, Carl Eugen Hoyos wrote:
> 2016-11-17 14:49 GMT+01:00 Rostislav Pehlivanov <atomnuker at gmail.com>:
> > On 16 November 2016 at 11:15, Carl Eugen Hoyos <cehoyos at ag.or.at> wrote:
> >> Hi!
> >> Attached patch improves output for some ffv1 files imo.
> >> Current slowdown for the existing decode-line timer is
> >> 2%, I wonder if this can be improved through refactoring.
> >> Please comment, Carl Eugen
> >> _______________________________________________
> >> ffmpeg-devel mailing list
> >> ffmpeg-devel at ffmpeg.org
> >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > So AFAIK the encoder pushes the values to the LSBs but the decoder didn't
> > shift them back up?
> I don't think the encoder does any shifts here but I may misunderstand.
> > I think you should add a comment explaining that happens.
> Many (older) decoders have to do this and there is nowhere a
> comment, I really believe that this is not particularly convoluted
> > Also 2% on a decoder doesn't sound that great,
> It's 2% in a function of a decoder.
> > did you try using an if case for the entire loop for when the
> > values need to be shifted?
> That is what I tried to suggest with "refactoring", I suspect
> Michael wasn't too happy about the idea.
can the whole "what to put in the lsb" question be avoided by adding
gray10 support to ffv1dec ?
if so this might be the best solution
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Old school: Use the lowest level language in which you can solve the problem
New school: Use the highest level language in which the latest supercomputer
can solve the problem without the user falling asleep waiting.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 181 bytes
Desc: Digital signature
More information about the ffmpeg-devel