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

Rostislav Pehlivanov atomnuker at gmail.com
Wed Feb 22 23:33:03 EET 2017


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. So I think the first version of your
patch was better. You just didn't bother to list a valid reason besides
"offload it to another thread" and I didn't think of V210 at the time.
libavformat has no support for assembly so putting the unpacking there
would be slower too. I suggest posting a v3 of the patch which is like v1
(but please rename the codec name to something better) and which uses the
assembly for unpacking from the repository you linked.

PS: In that repo its _not_ done in lavc and it was never done in lavc, the
point was to use lavc's assembly framework so that if you linked to it and
used the private functions you'd be able to use them _outside_ of lavc.
This was because upipe, which is something made to handle the stinkiest
kind of crap broadcasting people invent because ffmpeg couldn't (and it
absolutely doesn't have to), didn't have any support for assembly.
Eventually support for that was added and everything from the repo plus
more has been implemented there.


More information about the ffmpeg-devel mailing list