[FFmpeg-devel] add MJPEG support into RTP output
Thu Apr 8 12:40:14 CEST 2010
Martin Storsj? wrote:
>> 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.
> 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.
Yes... So, maybe the best thing to do is to use the current approach for
packetisers that put more than one frame in a packet (generally, audio),
and to use the new approach for the other packetisers (generally, video).
But some comments in the code are needed to clarify this thing (otherwise,
people will surely use the wrong code as an example when writing new
Anyway, I think this is orthogonal respect to the MJPEG patch: let's
merge the MJPEG packetiser using the current (ff_rtp_send_data())
approach, and let's split ff_rtp_send_data() later (if we decide that
For the moment, I'd focus on making the MJPEG packetiser suitable
for svn (I had a look at RFC 2435, and I think there still is some
work to do).
More information about the ffmpeg-devel