Big problem with VLC.. and an easy fix?
Posted: 18 Jul 2006 15:37
Short version:
- Right now, under certain, often-occuring conditions, VLC will simply stop playing/encoding/transcoding video. Fairly easily reproducable.
- Also, while I have no insight in the complexities of VLC, and I am not a coder, I think that a 'quick and dirty' fix that will at least IMPROVE things is easy to make.
Now the longer version.
- If the source (stream/file/whatever) is slow, for any reason (network hiccup, cdrom with dust requiring re-reads). VLC starts seeing 'late pictures' which it skips. Often, it never recovers.
- One constant in all of this, whether you're playing or {en/trans}coding is that VLC starts giving messages:
- I suspect it has to do with a difference in the timestamp the source sends, and the timestamp VLC feels it has to play next.
- If the user told VLC to 'play' or 'encode' something, they will probably want SOMETHING, and a big hiccup OR an exit with a big error message is better than VLC just running forever without doing anything after a while.
The solution, well, I am sure that an ELEGANT solution would be difficult to make, it would probably require all the various input systems to have new API features that present the source of this problem uniformly etc etc etc. I probably can't begin to comprehend the complexity of this
But a quick and practical fix can be simple.. I think..:
- Offer us a few commandline switches that allow us to specify when to restart the VLC decoder completely. Some kind of automatic panic button.
For example some (mostly?) hypothetical optional settings:
--max-late-pictures <int> (self-explanatory Id say)
--max-late-pictures-in-a-row <int> (ditto)
--min-output-framerate-percent <int> - If the source says its 25fps and for some reason we're playing less than 5%..
--max-late-picture-sync-delta <int> (where 'delta' is that amount from the error message: "late picture skipped (2998000)")
and if those <int>'s are reached, just completely reboot VLC.. Disconnect from the source, reconnect, rebuffer, start playing/encoding all over, whatever it takes. I think this is what most other media players (and encoders?) do. When they get confused, start again.
Now again, I'm not a coder and sadly can't contribute to this myself, but I consider this a very urgent flaw in VLC.. would someone be able to implement this? Provide a better fix? Anything? Right now personally I just can't use VLC to transcode a MMS stream since there is no way for me to tell when VLC has encountered an error and given up! Also using VLC to just play a video stream off the internet over a less-than-perfect link will work very badly. Implementing some sort of 'fail safe' system should not be too hard (right?) and will greatly increase VLC's error recovery/robustness.. everybody happy!
- Right now, under certain, often-occuring conditions, VLC will simply stop playing/encoding/transcoding video. Fairly easily reproducable.
- Also, while I have no insight in the complexities of VLC, and I am not a coder, I think that a 'quick and dirty' fix that will at least IMPROVE things is easy to make.
Now the longer version.
- If the source (stream/file/whatever) is slow, for any reason (network hiccup, cdrom with dust requiring re-reads). VLC starts seeing 'late pictures' which it skips. Often, it never recovers.
- One constant in all of this, whether you're playing or {en/trans}coding is that VLC starts giving messages:
Code: Select all
late picture skipped (2688000)
late picture skipped (2998000)
late picture skipped (3797000)- If the user told VLC to 'play' or 'encode' something, they will probably want SOMETHING, and a big hiccup OR an exit with a big error message is better than VLC just running forever without doing anything after a while.
The solution, well, I am sure that an ELEGANT solution would be difficult to make, it would probably require all the various input systems to have new API features that present the source of this problem uniformly etc etc etc. I probably can't begin to comprehend the complexity of this
But a quick and practical fix can be simple.. I think..:
- Offer us a few commandline switches that allow us to specify when to restart the VLC decoder completely. Some kind of automatic panic button.
For example some (mostly?) hypothetical optional settings:
--max-late-pictures <int> (self-explanatory Id say)
--max-late-pictures-in-a-row <int> (ditto)
--min-output-framerate-percent <int> - If the source says its 25fps and for some reason we're playing less than 5%..
--max-late-picture-sync-delta <int> (where 'delta' is that amount from the error message: "late picture skipped (2998000)")
and if those <int>'s are reached, just completely reboot VLC.. Disconnect from the source, reconnect, rebuffer, start playing/encoding all over, whatever it takes. I think this is what most other media players (and encoders?) do. When they get confused, start again.
Now again, I'm not a coder and sadly can't contribute to this myself, but I consider this a very urgent flaw in VLC.. would someone be able to implement this? Provide a better fix? Anything? Right now personally I just can't use VLC to transcode a MMS stream since there is no way for me to tell when VLC has encountered an error and given up! Also using VLC to just play a video stream off the internet over a less-than-perfect link will work very badly. Implementing some sort of 'fail safe' system should not be too hard (right?) and will greatly increase VLC's error recovery/robustness.. everybody happy!
but well, it's worth enabling.
). But I do want to focus on and clarify the technical aspects of this thread.