<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></style><title>Re: [Live-devel] RTSP considerations and more. RTP
vs TS</title></head><body>
<blockquote type="cite" cite>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.</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite>First in the vlc devel list I'm
discussing this issue:</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite>>> The problem you mentioned in the
forum is kind of a big fail (yes i'm<br>
>> mundu :). When fast rewinding the time gets stuck and then it
doesn't<br>
>> update. If you press play it will only start from the time
you issued<br>
>> the setRate(negative), and not at the time where I pressed
play again.<br>
>> Do you know where vlc actually updates its time?<br>
</blockquote>
<blockquote type="cite" cite>> There are several issues with rtsp
and time update. In fact the time<br>
> will always update at 1x speed.<br>
> That's because rtsp servers re-calculate timestamps, and vlc
thinks it<br>
> receives the pictures at 1x speed.<br>
> Time update is based on timestamps</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite>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).</blockquote>
<div><br></div>
<div>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.</div>
<div><br></div>
<div><br></div>
<blockquote type="cite" cite><font face="Arial">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). </font></blockquote>
<blockquote type="cite" cite><font face="Arial">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.</font></blockquote>
<div><br></div>
<div>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.</div>
<div><br></div>
<div><br></div>
<blockquote type="cite" cite><font face="Arial"> 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?</font></blockquote>
<div><br></div>
<div>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.</div>
<div><br></div>
<div>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.</div>
<x-sigsep><pre>--
</pre></x-sigsep>
<div><br>
Ross Finlayson<br>
Live Networks, Inc.<br>
http://www.live555.com/</div>
</body>
</html>