[FFmpeg-devel] add MJPEG support into RTP output

[Nash Tsai]

On Thu, Apr 8, 2010 at 4:18 PM, Martin Storsj? <martin at martin.st> wrote:
>
> On Thu, 8 Apr 2010, Luca Abeni wrote:
>
> > Martin Storsj? wrote:
> > [...]
> > > All current packetizers buffer the data they're going to send within
> > > RTPMuxContext->buf, but splitting ff_rtp_send_data this way does allow us to
> > > avoid one layer of buffering, if each individual packetizer wants to. You
> > > need to hear from Luca A if he's ok with this approach.
> >
> > Well, I am not sure about this. I am currently undecided, but it other
> > people like the idea of splitting ff_rtp_send_data(), I am ok with it.
> > Let's just be sure that there are enough people in favour of this solution.
>
> I'm a bit undecided, too. I like the current one for simplicity, but it
> does indeed require one extra copy of data.

What I can see here is that it's trying to reuse the implementations
of writing RTP header and update seq number on what is already inside
ff_rtp_send_data(), and have better performance without making a copy
of data, isn't this be better?

>
> > In any case, what I do not want to see is a non-uniformity between the
> > various packetisers. If we decide to split ff_rtp_send_data(), then all
> > the packetisers must be converted. Having some packetisers implemented in
> > the old way and some in the new one is (IMHO) not acceptable.
>
> Yes, uniformity is important.

I tend to agree this, but with sacrifice of performance it's rather
hard for me to fully agree on it.

>
> Even if this approach works quite well for video formats (where one frame
> is split into multiple packets), but it doesn't necessarily work as well
> for audio formats. There we usually buffer up a few frames into a packet,
> and we might not be able to write out all data into the output
> ByteIOContext until we've got all the frames for the packet, so there we
> need some kind of intermediate buffer anyway.
>
> // Martin
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel

Nash Tsai