[FFmpeg-devel] add MJPEG support into RTP output
Martin Storsjö
martin
Thu Apr 8 14:57:05 CEST 2010
On Thu, 8 Apr 2010, shawn shawn wrote:
> According to all said, i have change it,
> 1. use ff_rtp_send_data, not split it
> 2. change a=rtpmap:%d MJPEG/30000\r\n to a=rtpmap:%d JPEG/90000\r\n
Since this should use the static payload type 26 (right?), this kind of
shouldn't be needed at all.
> 3. tidy up some code and add some comment about rfc number
> 4. add a new file rtpenc_mjpeg.c
Ok, now it's starting to look a bit better. You still haven't addressed my
comment about using a struct for creating the header may have
endian-issues with the bitfields, and may have other issues with
compiler-dependent struct packing.
You may have taken inspiration to the struct from the RFC, but note this
comment in the RFC just above the example code:
For clarity and brevity, the structure definitions are only valid for
32-bit big-endian (most significant octet first) architectures. Bit
fields are assumed to be packed tightly in big-endian bit order, with
no additional padding. Modifications would be required to construct a
portable implementation.
So instead of trying to mimic the data format with a struct, whose layout
you can't control totally to the level needed by a communications
protocol, you'll have to manually build the corresponding header in an
uint8_t buffer, using normal bit operators and e.g. AV_WB* macros.
> 5. "tspec", "type", and "q" fields always set to 0, because rfc
> defined a range, maybe we can set some input parameters, but now i
> have not do it.
After browsing the RFC a briefly, I'm not sure that leaving all these as
zero is ok.
> I have test VLC media player, add this header it not work, if don't
> add it can work, However, according to rfc documents 2435,
> i think we should add it.
I don't understand what you're trying to say here. In which configuration
does it work, and in which does it not work?
// Martin
More information about the ffmpeg-devel
mailing list