2017-02-22 22:33 GMT+01:00, Rostislav Pehlivanov <atomnu...@gmail.com>: > On 22 February 2017 at 20:18, Damien Riegel < > damien.rie...@savoirfairelinux.com> wrote: > >> On Fri, Feb 17, 2017 at 03:01:05PM -0500, Damien Riegel wrote: >> > Hi, >> > >> > On Thu, Feb 16, 2017 at 06:19:00PM +0000, Rostislav Pehlivanov wrote: >> > > > >> > > > No, do this in libavfilter and do not introduce another useless >> pseudo >> > > > codec >> > > > >> > > >> > > *libavformat, sorry >> > >> > The advantage of using a pseudo codec just to depack the stream is that >> > the input and the codec are in separate threads in ffmpeg, so it can >> > handle a heavier workload. >> >> Please find attached a v2, with the implementation in libavformat. Note >> that I don't want to send it as a patch of its own because the >> performance issue is not addressed. >> >> Basically, our test case is a raw input stream YUV 4:2:2 10 bits 1080p >> at 60fps. With the pseudo-codec, we are able to transcode it to h264 and >> dump it to a file. With unpacking done in the libavformat, the input >> thread gets too busy and can't stand the load. >> >> In the implementation you made [1] unpacking was done in libavcodec, so >> why is it not an acceptable solution for mainline? >> >> > I now think it was ok to have a custom codec format because V210 is > implemented in such a way in lavc.
(Since every time I stumble over "bitpacked" I wonder where this came from...) V210 exists in several multimedia containers, so adding a codec was unavoidable. I don't think this is true for bitpacked, or is it? Carl Eugen _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
