[VOD] Protocol used for trick modes (ffwd, fbwd, seek)

[mnemonic]

Hi all,

I am curious which protocol VLC uses to realize the trick modes fast forward, fast backward and seek when streaming VOD media.

I am currently developing a remote control which uses RTSP to control unicast streams to a given client.
It seems, that VLC uses RTSP for starting a stream (play), pausing and stop according to RFC 2326 (RTSP) but not for the trick modes.

I carefully watched the traffic between the server (VLC) and the client (VLC) with the use of Wireshark. I can see the requests and responses for play, pause and stop but not for fast forward and fast backward. To me it appears that this modes are kind of magic as I have no indication how it is realized - it seems as if there are no requests, but I know they must be there.
At least I can not control the stream with the "Scale" header field as requested by RFC 2326. Sending a request like

Code: Select all

PLAY rtsp://XXX.XXX.XXX.XX:1500/voodoo RTSP/1.0 Scale: 3 Session: xxxxxxxxxxxx CSeq: 9 User-Agent: xxxxxxxxx

has no effect. The server just replies with

Code: Select all

RTSP/1.0 200 OK Server: VLC Server Content-Length: 0 Cseq: 9 Cache-Control: no-cache Session: xxxxxxxxxxxx;timeout=5

and keeps playing back the stream without any speedup.

I don't need a solution that conforms to some RFC, I just need to know how VLC does this.
I hope that somebody can shed some light on this issue and tell me how this is done, or at least point me to the right direction.

Kind regards and thanks.

[dionoea]

This is most likely to be a bug in VLC. I'm no RTSP expert so I can't help you out. You might want to post an email on vlc-devel@videolan.org

[mnemonic]

Hello dionoea,

first of all, thank you for your reply.

I already made my way into the sources of VLC after realizing, that there really isn't any fast forward or fast backward. If I press the FFW button (client side, GUI) it seems that VLC does a FFW on the internal buffer because it stops after a few seconds and hangs until I press play again (that would explain why I just don't see any requests).

After looking into the sources I can say that my theory is right because FFW an FBW are simply not implemented, though seek is.
So we most likely don't have a bug here.

I am currently digging through the sources and trying to understand how things are done. Currently I am dissecting vlm.c.

I'll try later today to find out how to join the developers mailing list to get some assistance if I am hanging hard.
At this point I am pretty optimistic, that I am able to implement the chain for FFW (FBW respectively) up to the call to vlm_MediaControl(.) with some "ffw" parameter inside vlm_MediaVodControl(.).
Unfortunately I can not tell if FFW is possible at all, because I did not get the time to dig deep enough into the sources. So I definitively need expertise from an experienced developer.

Kind regards.

[Leonidus]

hey mnemonic...........can u plz tell me what did u exactly do......as in even i am working on i voip project..........and planning to use vlc player for multicasting and then capturing packets vis wireshark..........it would be gr8 if u canhelp me with it.................thnx alot........

[juliaxyz]

Does anyone know the explanation to this magic trick? Anyone know the Real life game or magic trick where you guess what object the person is pointing at in a room?
The game works like this. One person is in another room or blindfolded. Another person points to an object. The third person watches what item they pointed too. That same person then asks the blindfolded person, now with no blindfold, if several random objects are the object the that the person pointed too. They always say no it is not until the right object is said. They get the object everytime. What is the trick to this? Thanks!
____________________
yahoo keyword tool ~ overture ~ traffic estimator ~ adwords traffic estimator