On 1/6/17, u-9...@aetey.se <u-9...@aetey.se> wrote: > Hello, > > On slow hardware a 16-bit framebuffer depth makes a remarkable difference > in performance and still provides a good look. > > When videos are to be played on slow terminals there is a single > best speed performer, cinepak (tell me if you know a better codec in this > respect, the only comparable one I know of is VQA-15, but there is no > reasonable encoder for it, nor a safe decoder). > > Unfortunately cinepak as present in ffmpeg yields rgb24 which has to be > repacked depending on the framebuffer format. > > The attached patch makes cinepak to provide rgb565 in native endianness. > This cuts in half (!) the mplayer CPU consumption on i686 with Xorg > in the corresponding mode/depth, compared to decoding to rgb24. > > The optimization is possible because cinepak is a VC codec and pixel > format packing at codebook fill is much more efficient than at a later > stage. (Thanks Michael for the suggestion, long ago). > > Of course the picture quality is slightly affected if this decoder version > is used with larger framebuffer depths. A run-time switch would be to > prefer, if this optimization against all odds would be welcome upstream :) > > I am posting this as a proof of concept, lacking run-time format > switching. As said, this patch yields half CPU consumption or double > speed at decoding for rgb565 terminals. > > Regards, > Rune >
You could easily add option to decoder for picking output format... See how it is done for encoders. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
