Prevent ffmpeg from complaining "computer too slow?"

[janezp]

Dear All,

I seem to have same problem as many users before. I almost found the solution for MY particular case, but a final part in the puzzle still bothers me.

(bit of background explanation, if you know the answer to the question in subject, please skip to the end, thanks)

In short: VLC keeps losing frames, when playing high-bitrate streams over RTSP, playback stutters, and in many
times it is practically no video (only 1 picture every few frames gets displayed). Practically useless.

It is NOT the case of my computer being too slow (2.1 Ghz Core2 Duo, 2 GB RAM, SuseLinux 10.3 - load in KDE System Guard never
goes above 5% or so, same with "top"). VLC somehow (and this is long-standing problem I believe) thinks the playback is more behind,
than it really is. Instead of dropping a frame or two, and getting on, frame after frame keeps getting discarded with error message, and
when this happens, rarely single frame gets past this devilish loop.

Similarly to this description:

viewtopic.php?t=33246
and the details are, I believe, best described here:
http://www.via.ecp.fr/via/ml/vlc-devel/ ... 00582.html
(the key is, vlc does not ever resync, even when it dropped bad frames)

(there are many more references to this problem on the net)

My command line (vlc 0.8.6f - built from source) is as follows:

./vlc -vvv --loop rtsp://10.0.0.4:554/mpeg4/1/media.amp (I am playing live stream from Axis 207W camera)

Stream is 30fps, MPEG4.

At 6 MBit, the stream is unplayable, and practically every frame gives "warning: late picture skipped".
At 2 Mbit, the warning comes up only once a while (few seconds, single frame, vlc usually recovers)

One common suggestion is to increase the cache size. I cannot afford this, since I am using vlc
to decode live, realtime stream for automatic processing, and 1 second delay makes the video
unusable for me. In fact, I put vlc to its limits by reducing cache size to 45 ms, which is nothing.
(lifting size to 1000 improves 2 mbit stream, but does nothing to 6 mbit stream, it still does not play.)

However, simply by adding --no-drop-late-frames, the most of the problem magically dissapears. No
more warnings, video is running (not VERY smoothly, but with 45 ms cache it cannot anyway). It does
not seem to lag excessively or build up any lag as time passes.

(end of lenghty introduction)

The only headache remaining is ffmpeg, which stubbornly declares "video is 5 seconds late, computer too
slow?"), every 5 seconds or so, abruptly killing almost-smooth playback, which then needs second or two
to reinitialize. How do I prevent this (by giving instructions to ffmpeg through vlc command line?).

The most obvious options, --sout-ffmpeg-hurry-up and --no-sout-ffmpeg-hurry-up do not make any difference!

Since I compiled ffmpeg by myself, I can modify the code and disable this behaviour, but I have to know what to
modify, to disable it? Anyway, it would suit me best if there is a way to supply the right parameter to ffmpeg
via vlc, if there is a way.

In hope to get the final part of the puzzle & that I helped someone with similar problem...

Janez.

[janezp]

The only headache remaining is ffmpeg, which stubbornly declares "video is 5 seconds late, computer too
slow?"), every 5 seconds or so, abruptly killing almost-smooth playback, which then needs second or two
to reinitialize. How do I prevent this (by giving instructions to ffmpeg through vlc command line?).

In case anyone besides me needs such dirty hack, addition of the line:

Code: Select all

p_sys->i_late_frames = 0;

somewhere before line 421 in vlc-0.86f/modules/codec/ffmpeg/video.c solved the problem.

Now the playback is what I wanted.

I may have broken something else, so use it at your own risk.