[Live-devel] RTSP considerations and more. RTP vs TS

[Ross Finlayson]

>currently I'm developing an RTSP client using VLC bindings. However 
>i had to make a few adjustments to the VLC source code in order to 
>achieve fast rewind. Tests were successful, but there are still a 
>few bugs to be attended. I have two questions relating this issue.
>
>First in the vlc devel list I'm discussing this issue:
>
>  >> The problem you mentioned in the forum is kind of a big fail (yes i'm
>>>  mundu :). When fast rewinding the time gets stuck and then it doesn't
>>>  update. If you press play it will only start from the time you issued
>>>  the setRate(negative), and not at the time where I pressed play again.
>>>  Do you know where vlc actually updates its time?
>
>  > There are several issues with rtsp and time update. In fact the time
>>  will always update at 1x speed.
>>  That's because rtsp servers re-calculate timestamps, and vlc thinks it
>>  receives the pictures at 1x speed.
>>  Time update is based on timestamps
>
>It seems that VLC doesn't have a way to properly figure out at what 
>time the video is currently playing when issuing for example a 
>set_rate(-2).

The "LIVE555 Streaming Media" library *does* provide such a function: 
"MediaSubsession::getNormalPlayTime()".  Furthermore, this function 
*is* called by VLC's LIVE555 interface code ("live555.cpp").  Note, 
however, that this is VLC code, not ours - so it's outside the scope 
of this mailing list.


>Another question relates to the TS vs RTP. As you know set top boxes 
>request raw-UDP because they don't need RTP overhead. However I'm 
>currently trying to understand the benefits of eradicating the 
>transport stream container as it proves to be the most greedy in 
>terms of overhead. I mean RTP uses 12 bytes of overhead while 6 TS 
>packets inside a RTP packet uses 24 bytes. Twice as much as the RTP 
>overhead. Not to mention that both have timestamp information 
>(redundant information). In a Video on demand application while 
>streaming HD content, this proves to be to much in a long-term use. 
>(And normally TS is to multiplex several Programs not just a movie). 
>I raise this question only focused on an Internet service and not 
>TV( STBs and DVB uses TS so no questions there). My question is, 
>what is the downsize of using H264 without a container when it comes 
>to trick play.

The only downside (sic) of doing trickplay on H.264/RTP streams 
(rather than on H.264 video-only Transport Streams) is that our 
server implementation currently doesn't support this.


>  As far as I know the indexer already searches for H264 I-Frames, am 
>i wrong? But i read in a paper that the computational costs of doing 
>such a thing is too much. Is this true?

I don't really understand this question, but I think the answer is 
"no".  There's no reason in principle why our server couldn't support 
trick play when streaming raw H.264 files over RTP - e.g., by using 
an 'index file' on such files (just as we use an index file for trick 
play when streaming Transport Stream files).  However, we just 
haven't implemented such a thing yet.

Note, though, that there's another benefit for using Transport 
Streams - they include audio as well as video.  If you wanted to 
stream from raw H.264 files, then you wouldn't get any audio (because 
H.264 files are, by definition, video only).  That would be OK if 
your stream doesn't contain any audio (e.g., if it's from a security 
camera), but if your stream contains audio, then you'd need to tie it 
to the video stream in some way.  Transport Streams provide one 
standard way of doing this.
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20110612/f362ba8a/attachment.html>