position info not updated after http seek

[rocket888]

I'm running both the standard gui interface and an http interface (on xp home sp2). I send in remote commands to seek and in almost all cases the the current play time is not updated (i.e. one in about 10 times it works as expected). However, the seek did work and the video is ok too, it's just the info on the current play position which is wrong.

The slider moves but the status bar time doesn't change. In addition, reading back the output from

http://localhost:8080/requests/status.xml

shows the value for the time to be unchanged (i.e. its stuck).

If I touch the slider in the gui (just left mouse click on it without dragging it) and then it works again.

Anyone else seeing this? Should I report a bug on this?

[VLC_help]

If the same issues exist in nightlies, then do a bug report.
http://nightlies.videolan.org/
http://trac.videolan.org/vlc

[tcf]

Hi,

I used VLC 0.7.2 a long time in my http streaming environment without any problems.
Updated VLC to a newer release (0.8.6i), now I have exactly the same problems on
seeking with the VLC http interface.

Jumps are not processed correctly, for example a jump to 10:00 of the film
will sometimes come up at 13:12. And another thing is, if I do a backwards jump
then the time shown in the VLC status bar is not updated. This will remain
as long until the film reaches the "jumping point", then time counting continues.

This occurs on mostly of my MPEG2 files, but not on all, I've not recognized any
shared patterns or dependencies. I tried VLC on the fly transconding and external
remuxing with ProjectX, but all this didn't helped.

Then I tested out some older VLC versions and found out, that 0.8.5 is the last
release with correct http seeking function, 0.8.6 and higher versions up to 0.8.6i
produced errors as described above. I've also tested some of the actual 0.9.0 nightly builds,
but it don't worked for me at all - no streaming data is sent to the client.

Probably one of the devs can have a look at this

THX & Regards
tcf

[rocket888]

I just created a new post (before I saw the reply here) where I found that if I convert my mpeg2 files to dvd format (I use 2 programs, video redo tvsuite, and AVS video converter) that seeking is nearly flawless. Since I have no real clue what is different between these two (I thought .vob files were basically just mpeg2 files) I can't see why the dramatic improvement.

Maybe dvd format, with those other little files, has timing info that helps, or perhaps a different section of code runs when it's in dvd format. I don't burn a dvd, I just play the video_ts directory via open directory.

[tcf]

Yes, DVD format/VOB files are imho slightly modified mpeg2 files, I've posted a reply in your thread about that.

Recoding or remuxing to another format may be some kind of workaround, but not acceptable for me, it's a time-consuming and unneccesary process, because vlc is equipped to serve/transcode streams to clients on the fly.

At this time situation is as follows:

version 0.8.5: http seeking works perfectly on all files, but streaming/transcoding modules contain several bugs which are fixed in latest release

version 0.8.6i: http seeking works on some files, on most not. Streaming/transcoding itself works good

version 0.9.0x/nightlies: http streaming don't work at all, I get a dll error message on start if --extraintf=http is enabled on program execution

The seek problem also affects the bookmarks on client side, when the time delivered from vlc is wrong.
A re-jump could then lead to a false re-entering position in the film.
It seems that something with the time calculation on mpeg2 files is wrong.
Definitely it's a bug in actual vlc releases which causes this behaviour, in old 0.8.5 release it's ok.

@rocket888
@VLC_help
Is there already a bug ticket for this issue or do we have to announce that on vlc trac?
This issue is somewhat frustrating, would be great if this could be fixed in one of the next 0.8.6-bugfix releases

THX & Regards
tcf4004

[tcf]

I would like to clarify something from the post above:

I wrote above "working perfectly in 0.8.5 release"
this means that the http seeking itself works perfectly. But the time shown by vlc is often "compressed", for example
a 90 min film is shown as 25 minutes, and one second in display matches to several seconds in the film.
But, and this is the important thing, vlc time in 0.8.5 is updated in a slowly but constant and reproduceable way.
There are no bookmarking or seeking/jumping issues by this behaviour, only time shown is "compressed".

[rocket888]

This problem has been reported (by me) as ticket # 1660.

Has anyone else found that the dvd format does indeed avoid this problem?

I agree that this is not a viable workaround for all users. I am hopeful that this dvd data point, along with the above mention that this is a newly appearing problem, should allow a developer to find the source of the problem.

My understanding of .vob vs. mpeg2 is quite limited. I had thought they were roughly the same, and sofware like video-redo is able to convert from one to the other without changing the video stream (it's how they can do it so quickly). But they do, it seems, re-mux the video and the audio - but I don't know much about how this process is actually done either.

I also found one other issue, but this might not have anything to do with this. I was getting lots of audio problems after conversion to dvd format. I was getting the messages that audio drift was too big, and the audio would get choppy. For this, I found that if I changed from mpeg audio to lpcm/wav (when creating the dvd with video-redo-tvsuite) that this seems to have solved this problem. This does, unfortunately, increase the size of the output dvd files. In my case, I wasn't sure if playing these videos over my wireless lan was the problem as well. However, I have no idea if these issues are related.

[tcf]

Thanks for reporting this bug @rocket888

Well, I'm not an mpeg2/vob expert, but what I know is the following:
MPEG2 and VOB contain in general the same stream, but in vobs there are additional header informations present and the stream is probably new packetized, but the mpeg2 raw data could be quite the same.

I don't know the video-redo suite, but in general there are two ways to get mpeg2 raw data into dvd/vob format:

a) via re-quantize - GOP details are reduced using a mathematical algorithm, this is what for example dvd shrink and other programs do and probably video-redo too, takes less than 1 hour
b) via re-encode - whole material is completely new encoded, this takes several hours

[tcf]

Hi rocket888,

I've read you bug tracking entry #1660, I would still have another request to you

Perhaps you can add the following text/infos to the trac entry for more clarify:

- Wrong film-entering not only occurs by doing a backwards jump, other direct jumps are
also affected. For example, if you jump to 10:00, entry come sometimes up at
13:34 and so on.

- Last working version (http seek) is the 0.8.5 which is from 11.12.2006.
Version 0.8.6 and higher contains the bug. This means, the error is present since
19.04.2007 (this is the date where 0.8.6 was released).

Thank you very much!

PS: I don't expect fast fixing of this issue, because the bug is sorted in "bugs
paradize" release, and it's unknown when this release comes up. Perhaps it will
be fixed in the 0.9.x release, and not in 0.8.x. But the streaming architecture
and commands have changed in 0.9.x, so that old frontends will not function with this.

Therefore it would be REALLY GREAT if this annoying bug could be fixed in an 0.8.x release.

Regards
tcf4004

[tcf]

Done a lot of testing, now I can say the following:

Basically this is a time calculating problem on variable bitrates
and/or defect respective non-spec-conform timestamps in the stream.

There's already a cmdline option which allows VLC to seek correctly with the old behaviour,
as in version 0.8.5 (and 0.7.2 too).

Simply start VLC with the following options:

Code: Select all

vlc.exe --extraintf=http --no-ps-trust-timestamps

Now on all MPEG2-PS seeking, bookmarking and re-entry working good with this workaround
But with this workaround is the effect, that time shown is "compressed" again,
that means for example, 3 secs in the film matches 1 sec in the VLC time display.

But this is ok for me, cause point-accurate seeking and re-entry is more important for me
than a 1:1 time display.

@rocket888
Can you please test your non-converted streams with this additional option, if it works for you too?

[rocket888]

Yes, this has the same behavior for me. However, the time being off, 2 hrs vs 3:15 for a long one, and 26 min vs 46 on a shorter one (an hour show with commercials removed) means all my seek buttons would be off so this won't work for me. But it did seem to solve the other problems as you mention, however, I didn't fully test it.