VLC shows hiccups while encoding
Posted: 30 Mar 2010 11:08
Hello,
VLC shows hiccups when sending video to display while encoding that video to H.264.
While working with VLC for encoding of H.264 we noticed a hiccup every few seconds (changing intervals). The video would halt very briefly and then resume, where there seemed to be missing a few frames.
To address this issue, we made a setup as follows:
-To an Intel-based machine we added the Osprey 210 video capture card
-We run a live image of Ubuntu 9.04, updated the packages (apt-get update) and installed OpenSSH, Xawtv and VLC
Then we started VLC with the command: vlc –I “dummy” -vvv --vlm-conf cvlc.vlm
and the following configuration in the cvlc.vlm:
new video_channel_1 broadcast enabled
setup video_channel_1 input v4l2:///dev/video0:fps=50:standard=pal:input=0:width=720:height=576:adev="shared_osprey"
setup video_channel_1 output '#duplicate{dst=display,dst="transcode{vcodec=h264,venc=x264,vb=300,fps=25, width=352,height=288,acodec=mp4a,ab=64,channels=2,samplerate=44100}:rtp{dst=192.168.10.65,port-video=5010,port-audio=5008,sdp="rtsp://0.0.0.0:8080/stream1.sdp",name="AV Stream"}"}'
control video_channel_1 play
We then received messages from VLC stating ‘late picture skipped’.
To verify, we ran Xawtv,but this showed no hiccups at all, indicating that the Osprey card and the driver are working fine.
However, running VLC without encoding (getting VLC to play the Osprey card output via the GUI) did show the hiccups.
This strengthened our belief that the issue is after the Linux driver, but before the encoding.
Next we experimented with the following, all without success:
-We increased the priority of VLC with the commands
-renice -19 –p `pidof vlc`
-chrt –rr –p 99 –p `pidof vlc`
-We tested several options for VLC in the VLM including
-threads (various values)
-thread-input (various values)
-file-cache (1000, 3000, 10000)
-mux-cache (10000)
-v4l2-cache (10000)
-gnutls-cache (10000)
--no-drop-late-frames (added to the command line)
--no-skip-frames (added to the command line)
-In spite of our assumption that the driver for the Osprey is working fine, we added the following to the bttv conf file:
-bttv option gbuffers=16
As indicated, all these experiments led to the same result
-Hiccups in the video
-Error messages ‘late picture skipped’
Finally we tested the combination of the same hardware with Windows XP Pro and VLC 1.0.5. This lead to a whole series of different errors, including
-output PTS is out of range
-input PTS is out of range
-timing screwed, stopping resampling
-buffer is <number> in advance triggering downsampling
(Although we are not looking for a solution for the Windows case, we thought mentioning it could maybe help understand the issue)
Any help in understanding what is the issue (particularly for the Linux setup) and how we could avoid the hiccup and the error messages would be appreciated.
Thanks,
Johan
VLC shows hiccups when sending video to display while encoding that video to H.264.
While working with VLC for encoding of H.264 we noticed a hiccup every few seconds (changing intervals). The video would halt very briefly and then resume, where there seemed to be missing a few frames.
To address this issue, we made a setup as follows:
-To an Intel-based machine we added the Osprey 210 video capture card
-We run a live image of Ubuntu 9.04, updated the packages (apt-get update) and installed OpenSSH, Xawtv and VLC
Then we started VLC with the command: vlc –I “dummy” -vvv --vlm-conf cvlc.vlm
and the following configuration in the cvlc.vlm:
new video_channel_1 broadcast enabled
setup video_channel_1 input v4l2:///dev/video0:fps=50:standard=pal:input=0:width=720:height=576:adev="shared_osprey"
setup video_channel_1 output '#duplicate{dst=display,dst="transcode{vcodec=h264,venc=x264,vb=300,fps=25, width=352,height=288,acodec=mp4a,ab=64,channels=2,samplerate=44100}:rtp{dst=192.168.10.65,port-video=5010,port-audio=5008,sdp="rtsp://0.0.0.0:8080/stream1.sdp",name="AV Stream"}"}'
control video_channel_1 play
We then received messages from VLC stating ‘late picture skipped’.
To verify, we ran Xawtv,but this showed no hiccups at all, indicating that the Osprey card and the driver are working fine.
However, running VLC without encoding (getting VLC to play the Osprey card output via the GUI) did show the hiccups.
This strengthened our belief that the issue is after the Linux driver, but before the encoding.
Next we experimented with the following, all without success:
-We increased the priority of VLC with the commands
-renice -19 –p `pidof vlc`
-chrt –rr –p 99 –p `pidof vlc`
-We tested several options for VLC in the VLM including
-threads (various values)
-thread-input (various values)
-file-cache (1000, 3000, 10000)
-mux-cache (10000)
-v4l2-cache (10000)
-gnutls-cache (10000)
--no-drop-late-frames (added to the command line)
--no-skip-frames (added to the command line)
-In spite of our assumption that the driver for the Osprey is working fine, we added the following to the bttv conf file:
-bttv option gbuffers=16
As indicated, all these experiments led to the same result
-Hiccups in the video
-Error messages ‘late picture skipped’
Finally we tested the combination of the same hardware with Windows XP Pro and VLC 1.0.5. This lead to a whole series of different errors, including
-output PTS is out of range
-input PTS is out of range
-timing screwed, stopping resampling
-buffer is <number> in advance triggering downsampling
(Although we are not looking for a solution for the Windows case, we thought mentioning it could maybe help understand the issue)
Any help in understanding what is the issue (particularly for the Linux setup) and how we could avoid the hiccup and the error messages would be appreciated.
Thanks,
Johan