[FFmpeg-devel] [PATCH v1 1/2] codec: vrawdepay: add decoder for RFC4175

Carl Eugen Hoyos ceffmpeg at gmail.com
Wed Apr 11 21:03:01 EEST 2018


2017-02-22 22:33 GMT+01:00, Rostislav Pehlivanov <atomnuker at gmail.com>:
> On 22 February 2017 at 20:18, Damien Riegel <
> damien.riegel at 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


More information about the ffmpeg-devel mailing list