[vlc-devel] RTP/H.264 to MPEG-TS mux bug

[Tim Ouellette]

Some of you may have seen a cry for help out about a month ago about
transcoding and rebroadcasting some Panasonic cameras (If you read
FFMpeg devel).  I believe I have isolated the issue down to a specific
point that will hopefully allow someone to provide me with the knowledge
to write a hack around for my personal use and/or to implement a long
term solution that can be written back into the main branch of VLC.

 

Here is where I believe the issue lays and I'll provide supporting
documentation at the end.

 

When I view the camera directly in VLC the picture quality is good and I
receive very minor disruptions during viewing.  However when I request
that the audio be transcoded and then be remuxed to an MPEG-TS that's
when issues start to arise.  Because H.264 and RTP do not carry a DTS
and only a time stamp the DTS values for the TS packets must be
calculated (guessed?).  I believe occasionally a packet is created with
a DTS that is very far into the future (between 80,000 and 400,000 more
than the previous packet).  That packet is then appended onto the output
chain and processed by the UDP transmission tool.  When the UDP tool
realizes that it just got a packet that has a new DTS with a value less
than the OLD DTS (the packet right after the future packet) it dumps the
output chain and starts over.  This is the cause of my video freezes
that can be up to 4 seconds in duration.

 

I believe the way to hack around this issue (in my case) is to place a
check right before a new TS packet is placed on the chain to be sent
out.  It would look something like this

 

//psudo code

If (new_packet->i_dts > previous_packet->i_dts + 80000) // packet is too
far into the future

   Return;

// else continue with processing to add this packet to the chain

 

I believe that I can afford to drop a couple of packets verse having my
restreamed image freeze up for a couple of seconds. 

 

If someone could provide some information where I can look to add this
in or if you would like access VIA SSH to a machine that is configured
to build VLC and has this camera on the network for testing and/or
confirmation of the problem please let me know.  I would be happy to
provide this information.

 

Pastebin has  a full output log from one restream attempt . (cam5.log)

http://pastebin.com/QqcPVfPB

 

Additionally here is a link to Panasonics documentation about how they
write their H264 and RTP information to the packets. Pages 250-270 seem
to fully document the formats.

http://www.getupload.org/en/file/20640/CGI-Common-Ref-Panasonic-Network-
camera-ver1-21-pdf.html

You have to wait about45 seconds for the ads and then the file will
download, sorry it was a free service I found.

 

Here is my complete CLI: 

./cvlc -vvv rtsp://10.0.2.5/MediaInput/h264
--sout='#transcode{acodec=mpga,ab128,channels=1,samplerate=44100}:udp{mu
x=ts,dst=239.0.0.5:1234}' :ttl=4 :sout-keep --rtsp-tcp
--rtp-caching=1200 --rtsp-caching=1800 --sout-udp-caching=900
--rtp-max-misorder=25 --sout-ts-shaping=4000 >cam5.log 2>&1

 

Many thanks to a bunch of the people who have been helping me to date in
#VideoLan.  Other than that I love VLC, I truly applaud all of the great
work and effort that has gone into this product to make it what it is
today.

 

Thanks for reading

 

Tim Ouellette

Sr. Systems Engineer

Video Dynamics Inc.

703.709.8400

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20110429/d9e76503/attachment.html>