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

[Nuno Mota]

Hi,
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). Any
ideas how to solve this issue?

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. 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?

Thank you for your attention.
Nuno Mota
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20110601/71f0dc7e/attachment.html>