MPEG2 video length reported wrong

[LaLaja]

When I open a MPEG2 video file VLC reports the length of it about 1/3 of the right length. The file is created by capturing Satelite TV and a run through VideoREDO afterwards to remove the stream errors. I had this problem before with a compression software PowerConverter. VideoRedo, PowerDVD, MSplayer, Zoomplayer, WinAVI report the length properly. Any suggestion?

[The DJ]

You do get the full range of the video available? Just the timecode is incorrect?

In that case the video is probably VBR. VLC then makes a best assumption based on the bitrate info in the stream and the amount of total mpeg blocks.
This is highly inaccurate. However the only way to accuratly determine this is by reading trough the entire file (which vlc would rather not do of course ) or by comparing the timestamp at the end, with the time at the beginning, but the timestamps in mpeg are not garantueed to be continious, so this is inaccurate as well.

[LaLaja]

Yes right, got the whole length. Why do the others so much better? What does VBR stand for?
VideoREDO is supposed to correct all the errors in the timestamping or not?

[The DJ]

VBR is variable bit rate.

Other take the "compare 1st and last timestamp" approach. But this is just as incorrect as our method, because like i said timestamping is not by definition a continious timeline in MPEG.

[Thing 1]

Would it be possible to make it a configurable option how "incorrectly" it determines the timing values?

The times are ALWAYS wrong in VLC. They are ALWAYS right in other programs.

If I could, I'd fix it myself, but I can't so I'll ask instead.

Sincerely,
Thing 1

[another guest]

I'd also appreciate it, if you could include such an option.
I, too, have the impression that the other method of guessing the length seems to be more accurat than the one currently used (in most cases).

[The DJ]

We are working on that, but it's not trivial. The problem is that as soon as you change how the time is calculated, it becomes much more difficult to do the seeking. Basically it's best to create some kind of "index".

This is not what VLC was designed for unfortunetly. But it is in the TODO list, and will probably be added some time in the future.

Fact remains that there is a high chance of errors in reading the time like this. You are trusting that the person who created the file did this properly. However if he did not, then the broken times can seriously affect several streaming related areas in VLC. Because a lot of ppl use VLC for MPEG-TS in a lot of different situations, we cannot afforc to make mistakes here.

[Tappen]

I understand that trusting the end time-code is dangerous, but at this point VLC is only decoder out of dozens I've tried which gets the time wrong, and it gets it wrong on every single MPEG2 file I've ever tried. Sure an index would be the best solution, but in the meantime an option flag to indicate we wanted to trust the end time-code instead of the VBR would make a lot of people happy.