Wowza Community

RTP streaming & trick play

Hi,

I stream a full HD H264 video from Wowza server (configured for VOD) and play the stream with VLC.

I need to use the Step forward/backward feature of VLC to move in the video. Step forward works not too bad, but step backward does not: the client gets frozen for a while and eventually start to play again the stream close to the original position.

In the message popup of VLC, i see some “Buffering 5%” entries constantly coming (the value is not changing). Then I get lots of warning/error in VLC like:

PTS is out of range

buffer is late, triggering upsampling

Could it be a misconfig in Wowza server, or an issue with VLC ?

Thanks for your help

Christophe

Wowza does not support trick play over RTSP/RTP.

Charlie

I studied our output and I believe it to conform to the RTSP/RTP specification. I do see that seeking backwards in VLC does not work. I believe this to be a problem with VLC. I am not sure what is different with our stream as compared to Darwin/QuickTime streaming server.

Charlie

@tahir24434,

I responded to your similar post here:

video seekbar problem in vlc (using RTSP protocol))

(Please don’t post duplicates.)

Richard

Christophe,

Testing with the Wowza stream “sample.mp4”, VLC 1.05 and Wowza 2.2.3 with vod application, the seek bar works well forward and backward.

What version of VLC are you using? What version of Wowza? And what file are you streaming.

Richard

Test with the Wowza sample.mp4 file also.

Richard

Flash or Silverlight are better choices for streaming to desktops.

Flash does RTMP or HTTP (Sanjose) streaming. Silverlight does HTTP Smooth streaming.

Richard

You can do Flash RTMP or Sanjose with AIR application.

Richard

In my test with Wowza 2.2.3 and VLC 1.15 on Windows 7, VLC will pause when seeking backwards. Seeking forward is okay. There is nothing different happening in Wowza. I’m not sure, but this seems like a problem with VLC.

Richard

Corrected VLC version in previous. I am using 1.1.5

Richard

We’re looking at this and will get back to you.

Thanks for the report.

Richard

I don’t think trick play will be possible with RTSP because of the variety of clients.

Richard

Hi,

Charlie, thanks for your answer. This can explain my problems, but I’m quite confused…

When I seek to a position in the stream, the server logs displays a pause, seek, play.

When I seek forward, it works fine (of course, there is a delay before the video plays, I guess this is the time for the server to seek in the video file). But, when I seek backwards, it does not work …

If seeking was not implemented, I guess it would not work at all…

I mentioned trick play in my post title, but, I’m interested in seeking, not fast forward/backward.

Christophe

Hi Richard,

I’m running Wowza media server 2.1.2 (Ubuntu 10.04 32 bits). CPU/RAM/Disk IO/Network are ok while streaming. I will try the very last version.

VLC: 1.1.5 on MacOS X (I tried also 1.1.3)

Here are the details of my video file (from ffmpeg):

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from ‘test2.mp4’:

Metadata:

major_brand : isom

minor_version : 512

compatible_brands: isomiso2avc1mp41

encoder : Lavf52.82.0

Duration: 00:02:00.03, start: 0.000000, bitrate: 8689 kb/s

Stream #0.0(eng): Video: h264, yuv420p, 1920x800, 8540 kb/s, 23.98 fps, 500k tbr, 2500k tbn, 47.95 tbc

Stream #0.1(fin): Audio: aac, 48000 Hz, stereo, s16, 142 kb/s

Thanks for your help

Christophe

Hi,

So I installed the last version of the server (2.1.2), and tested with sample.mp4.

I get the same issue. here are the server logs:

INFO rtsp connect 1263996624 -

INFO stream create - -

INFO rtsp describe 1263996624 -

INFO stream play sample.mp4 -

INFO server comment - RTPUDPTransport.bind[vod/definst]: 0.0.0.0/0.0.0.0:6982

INFO server comment - RTPUDPTransport.bind[vod/definst]: 0.0.0.0/0.0.0.0:6983

INFO server comment - RTPUDPTransport.bind[vod/definst]: 0.0.0.0/0.0.0.0:6984

INFO server comment - RTPUDPTransport.bind[vod/definst]: 0.0.0.0/0.0.0.0:6985

INFO rtsp play 1263996624 -

INFO server comment - UDPTransport.firstPacket: 0.0.0.0/0.0.0.0:6985

INFO server comment - UDPTransport.firstPacket: 0.0.0.0/0.0.0.0:6983

INFO stream pause sample.mp4 -

INFO rtsp pause 1263996624 -

INFO stream seek sample.mp4 -

INFO rtsp play 1263996624 -

INFO stream pause sample.mp4 -

INFO rtsp pause 1263996624 -

INFO stream seek sample.mp4 -

INFO rtsp play 1263996624 -

INFO stream pause sample.mp4 -

INFO rtsp pause 1263996624 -

INFO stream seek sample.mp4 -

INFO rtsp play 1263996624 -

Here VLC is frozen for a while, and play again whe the video reaches the initial position (before skip backward).

Christophe

Actually, this might be a VLC, or a VLC compatibility issue…

I tried with QuickTime player and it works fine…

I will also try with an older version of VLC as you were successful with 1.0.5

Tests with VLC 1.0.5 are little better: sometimes seeking works, but, sometimes it still freeze.

I’m not 100% sure, but it looks like when I seek to an intermediate frame (a non I frame), it freezes: after seeking I can see some image coming on top of the initial image (so a P frame is recieved?), and then it freezes.

In the message window of VLC, it continously display “buffering x%”, not changing the value.

In terms of quality:

  • Quicktime quality is not good: I get lots of jittering and sometimes some pixelisation

  • VLC: some jittering on sequences where the image is not changing by a lot. When the images are changing more, the quality is better. Looks like an issue when the biterate is much lower on intermediate frames.

Thanks for your answer.

If using Flash containers with Wowza server, can I still get seeking ?

Which player are supported ? (I need an application, not browser embedded players)

Thanks for your answer. But I cannot use AIR…

I discovered that ffplay support RTMP, but seeking does not work… Not sure were is the problem, probably some weak support from ffplay. To bad because the video quality was good actually.

Wowza: 2.1.2

VLC: 1.0.5 (Linux 32 bits or MacOSX)

VLC seeking works fine with another streaming server.