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/
_______________________________________________
live-devel mailing list
[email protected]
http://lists.live555.com/mailman/listinfo/live-devel
