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

[Kieran Kunhya]

On Wed, 22 Feb 2017, 21:39 Rostislav Pehlivanov, <atomnuker at gmail.com>
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.
>
> 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.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Further to what Rostislav said, please mark this as experimental. You're
not going to be able to do more than one stream for architectural reasons
and I don't want people blaming FFmpeg.

Kieran