The VideoLAN Forums

It seems there is a problem with RTSP MPEG4 video playback with the VLC 2.0.1 Windows binary provided by videolan.org.
I am using Windows 7.
I tried to play this stream: rtsp://mediasrv.oit.umass.edu/densmore/nenf-boston.mov
I can play the same stream at Linux with the binary from http://packman.links2linux.de/ without a problem:

Do 2.0.2 nightly builds work better?
http://nightlies.videolan.org/build/win32/?C=M;O=D

The problem is still there with 2.0.2 or 2.1.0 nightly builds.
H.264 RTSP streams are working. The problem is only there with MPEG4 video RTSP Streams.

Kind regards

Found ticket related to this : http://trac.videolan.org/vlc/ticket/6579

After setting --avcodec-threads=1 (Set in Preferences) ,
I can now play your link with VLC 2.0.1 on Windows7

Thanks for the hint. Changing FFmpeg(libavcodec) threads from "0"(auto) to "1"does help.


I am looking forward, that this bug will be solved with an update of FFmpeg with the next VLC release.

Kind regards.

Sadly this problem still exist with VLC 2.0.2 . Was there no libavcodec update with this release, or does this alone don't solve the problem? Well setting ffmpeg threads to 1 help.

I am seeing the same problem with 2.0.2, even if I set the threads from 0 to 1

Connection failed:
VLC could not connect to "192.168.11.253:554".
Your input can't be opened:
VLC is unable to open the MRL 'rtsp://192.168.11.253/video'. Check the log for details.

Message log with verbosity set to 2 (blah= rtsp path)
main debug: adding item `blah/video' ( blah/video )
qt4 debug: Adding a new MRL to recent ones: blah/video
main debug: rebuilding array of current - root Playlist
main debug: rebuild done - 12 items, index 10
main debug: processing request item: blah/video, node: null, skip: 0
main debug: resyncing on blah/video
main debug: blah/video is at 11
main debug: starting playback of the new playlist item
main debug: resyncing on blah/video
main debug: blahvideo is at 11
main debug: creating new input thread
main debug: Creating an input for 'blah/video'
main debug: using timeshift granularity of 50 MiB, in path 'C:\Users\cknutson\AppData\Local\Temp'
main debug: `blah/video' gives access `rtsp' demux `' path `192.168.11.253/video'
main debug: creating demux: access='rtsp' demux='' location='192.168.11.253/video' file='\\192.168.11.253\video'
main debug: looking for access_demux module: 1 candidate
live555 debug: version 2011.12.23
main debug: no fetch required for (null) (art currently (null))
qt4 debug: IM: Setting an input
live555 debug: connection timeout
live555 error: Failed to connect with blah/video
main debug: no access_demux module matching "rtsp" could be loaded
main debug: TIMER module_need() : 5005.090 ms - Total 5005.090 ms / 1 intvls (Avg 5005.090 ms)
main debug: creating access 'rtsp' location='192.168.11.253/video', path='\\192.168.11.253\video'
main debug: looking for access module: 1 candidate
main debug: net: connecting to 192.168.11.253 port 554
main warning: connection timed out
access_realrtsp error: cannot connect to 192.168.11.253:554
access_realrtsp debug: could not connect to: 192.168.11.253/video
main debug: no access module matching "rtsp" could be loaded
main debug: TIMER module_need() : 5000.159 ms - Total 5000.159 ms / 1 intvls (Avg 5000.159 ms)
main error: open of `blah/video' failed
main debug: dead input
main debug: changing item without a request (current 11/12)
main debug: nothing to play
qt4 debug: IM: Deleting the input
main debug: TIMER input launching for blah/video' : 10036.370 ms - Total 10036.370 ms / 1 intvls (Avg 10036.370 ms)

@catknutson: Looks to me like a connection problem.

The multi-threading MPEG-4 video decoder problem seems to be gone with VLC version 2.0.4.

Kind regards

I am getting

error: header damaged or not mpeg4 header (f_code=0)

error while playing mpeg4 rtsp link. I modified the ffmpeg_thread count 1 as suggested. But the playback doesn't continue after getting this issue. Is there any other changes required to fix this issue?
Also I have one more question. If I modify the thread count to 1 by default the following code might get affected(it is present in modules\codec\avcodec\video.c).

I don't think setting ffmpeg-threads=1 a proper solution for this issue. The issue may be due to ffmpeg mpeg4 decoder. I don't know if this is fixed with ffmpeg decoder present in latest vlc-contrib.