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

[Damien Riegel]

On Wed, Feb 22, 2017 at 09:33:03PM +0000, Rostislav Pehlivanov wrote:
> 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.

I'll respin a v3 with codec marked as experimental and renamed to
something different. Which name would suit? rfc4175? rtpvideo?

For the assembly, I'd rather send it later as a separate patch, does
that work for you?

Thanks,
-- 
Damien