really need some info and/or suggestions

[Chuck Crisler]

I have been working on a single problem for several weeks. I think that I
now know the source and need some guidance to implement the solution. I am
using gstreamer 0.10.30 and can't change right now.

Our system distributes video using multicast MP2T. We are adding support
for iPads. The iPads run a program called iDoubs which uses x264 and
ffmpeg. iDoubs only supports RTP. Our system does provide conversion
to/from RTP to bring video in or send it out.

If we generate video in the system and transmux it to RTP for an iPad, it
works fine. If an iPad generates video for our system it also works fine on
our systems. However, video sent back to another connected iPad fails to
display the video. This stream originated as RTP, was transmuxed to MP2T
and then transmuxed back to RTP. The RTP stream isn't perfect but it is
legal. I can insert a system running a gstreamer script and successfully
display the stream. Also, I have displayed the stream using other
technologies. The problem is that every RTP packet has the marker bit set
rather than just the last one in a frame. iDoubs keys off of the marker bit
to call the decoder, so it is calling the decoder with partial frames.

The problem seems to be that when we convert from RTP to MP2T the MPEG
muxer treats different RTP packets as separate frames and actually inserts
start codes at the beginning of the data from the next packet. That doesn't
seem to cause display problems but does cause problems in the conversion
back to RTP. The h264parse element searches the input buffer for the next
start code and assumes that the subsequent data is a new frame, so it sets
the marker bit. It will accumulate multiple MP2T packets to make a MTU
sized RTP packet.

Typically you should fix a problem at the source, which means that the MPEG
parser should also parse the next input buffer to see if the first
macroblock ID is zero. If not, perhaps it should assume that the buffer is
still part of the original frame and not insert the start code. My concern
about that approach is that the current display of the MP2T stream works
and I don't want to break that. Also, that buffer might not begin on a
macroblock boundary, so I would have to parse the stream to find the
macroblock.

A second approach is to modify the h264parse element to do the same thing.
After finding a start code, look to see if the next macroblock ID is zero.
If not, effectively ignore and remove the start code. My concern here is
that I have seen that packets are broken inside of macroblocks (I thought
that was a no-no) so I can't assume that the beginning of a buffer is also
the beginning of a macroblock. I would have to parse the entire stream,
skipping the start code to see if it parsed and if the macroblock ID was
non-zero. Not easy given the variable coding of H264.

I don't know much about MP2T and I am not sure which approach is 'better'.
I would greatly appreciate guidance and info from those who know these
protocols.

Thank you,
Chuck Crisler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20130327/d179e79e/attachment.html>