--use-stream-immediate --auto-adjust-pts-delay
Posted: 03 Mar 2010 15:36
Hi,
Background:
I am trying to get reliable low latency live stream playback working with VLC. Source is multicast h264 or mpeg4.
I start playback (normally by loading an sdp file) and everything is fine. Latency is excellent (<200ms).
Problem:
Say the encoder sends some dodgy frames or the network has a minor glitch and drops packets for half a second. VLC backs off on the caching,
For example:
Error at MB: 1499
header damaged
[0xdc1edec] main input error: ES_OUT_SET_(GROUP_)PCR is called too late, increasing pts_delay to 300 ms
[0xdc1edec] main input error: ES_OUT_SET_(GROUP_)PCR is called too late, increasing pts_delay to 316 ms
[0xdc1edec] main input error: ES_OUT_SET_(GROUP_)PCR is called too late, increasing pts_delay to 417 ms
[0xdc1edec] main input error: ES_OUT_SET_(GROUP_)PCR is called too late, increasing pts_delay to 600 ms
[0xdc1edec] main input error: ES_OUT_SET_(GROUP_)PCR is called too late, increasing pts_delay to 898 ms
[0xdc1edec] main input error: ES_OUT_SET_(GROUP_)PCR is called too late, increasing pts_delay to 1321 ms
[0xdc1edec] main input error: ES_OUT_SET_(GROUP_)PCR is called too late, increasing pts_delay to 1980 ms
The stream continues to play but now has a 2 second delay. This is no good for me because the application for this involves real time camera control on the video stream so it needs to always be in that <100ms range really. What I'd like is for VLC to behave differently and either:
1) Never try and back off on the buffer/caching and just show corrupt data/skip frames/etc
2) After it has backed off, speed up very slightly until it's back to a smaller buffer range again (e.g constantly trying to play a 25fps stream at 26fps?)
From googling, --use-stream-immediate --auto-adjust-pts-delay sound like they may have been designed for this kind of usage, but they seem to have been deprecated. What's the replacement method for doing this?
Thanks,
Ian
Background:
I am trying to get reliable low latency live stream playback working with VLC. Source is multicast h264 or mpeg4.
I start playback (normally by loading an sdp file) and everything is fine. Latency is excellent (<200ms).
Problem:
Say the encoder sends some dodgy frames or the network has a minor glitch and drops packets for half a second. VLC backs off on the caching,
For example:
Error at MB: 1499
header damaged
[0xdc1edec] main input error: ES_OUT_SET_(GROUP_)PCR is called too late, increasing pts_delay to 300 ms
[0xdc1edec] main input error: ES_OUT_SET_(GROUP_)PCR is called too late, increasing pts_delay to 316 ms
[0xdc1edec] main input error: ES_OUT_SET_(GROUP_)PCR is called too late, increasing pts_delay to 417 ms
[0xdc1edec] main input error: ES_OUT_SET_(GROUP_)PCR is called too late, increasing pts_delay to 600 ms
[0xdc1edec] main input error: ES_OUT_SET_(GROUP_)PCR is called too late, increasing pts_delay to 898 ms
[0xdc1edec] main input error: ES_OUT_SET_(GROUP_)PCR is called too late, increasing pts_delay to 1321 ms
[0xdc1edec] main input error: ES_OUT_SET_(GROUP_)PCR is called too late, increasing pts_delay to 1980 ms
The stream continues to play but now has a 2 second delay. This is no good for me because the application for this involves real time camera control on the video stream so it needs to always be in that <100ms range really. What I'd like is for VLC to behave differently and either:
1) Never try and back off on the buffer/caching and just show corrupt data/skip frames/etc
2) After it has backed off, speed up very slightly until it's back to a smaller buffer range again (e.g constantly trying to play a 25fps stream at 26fps?)
From googling, --use-stream-immediate --auto-adjust-pts-delay sound like they may have been designed for this kind of usage, but they seem to have been deprecated. What's the replacement method for doing this?
Thanks,
Ian