Problems with VirtualDubMod, Vobsub and OGM

[pirata]

Hi you all guys!

I am having troubles with vobsub and OGM files. My OGM (the first I ever made) contains several audio streams and several subtitles. It is split into 3 OGM files (for burning onto CD). All the muxing and splitting was done via VirtualDubMod.

Audio streams sound and switch pretty good, and also do most of the sub streams. The only problem is with the first subtitle stream. It does not show! The problem actually appears only in the second chunk, where some seeking is needed in order for the subtitles of the first subtitle stream to turn visible, and in the third chunk, where they do not appear at all!

I use latest Zoom Player and latest vobsub. I've tried with Tobias latest subtitle filter, and they show right (but it does have another issues vobsub solves).

Maybe a VirtualDubMod problem? (bad ogm generated?)

What should I do?

[Atamido]

Is the OGM portion of VirtualDubMod going to be continued as the development of OGM is being ceased? Xiph hasn't released any type of official spec yet, so its hard to say. If they don't release an official spec for storing video in OGG for 6 months, then OGM development of VirtualDubMod should probably be continued. At least until Matroska is working.

[Manao]

Try to make a bug report on the sourceforge page of the vdubmod project : here (http://sourceforge.net/tracker/?atid=512619&group_id=65889&func=browse) , and adress it to Suiryc. But if the Tobias' subtitle filter can read it, I doubt it's the fault of the muxing.

Could you try to switch two subtitles streams, to see what happens ?

And what are the "another issues vobsub solves" ?

[pirata]

And what are the "another issues vobsub solves" ?

12:12:123 --> 12:12:133
xxxxxxxxxxx

12:12:124 --> 13:13:131
sssssssssss

Notice that there is one milisecond of time in between the 2 subs.
Tobias sub filter won't show the second subtitle line. VobSub will.

I have news: I tried to demux the subs from the third OGM chunk (the one where it is impossible to make them visible), and the output srt was empty. The other sub streams generated correct srt files when demuxed. Maybe a bug in VDubMod. The source subtitle file is OK.

I tried with the second movie chunk and the resulting srt file ended at a given point of time. It was incomplete!

I turned to the original whole movie OGM file and demuxed the subtitle. It also was incomplete and ended at the same point of the movie as the srt file extracted from the second movie chunk.

SO: VirtualDubMod didn't mux the subtitle correctly. VobSub and Zoom Player are not guilty.

I don't know the reason why the muxer failed. I have checked the point where the subtitle stream ends, and the subtitle timings are exactly as I specified above, something like

12:12:123 --> 12:12:133
xxxxxxxxxxx

12:12:124 --> 13:13:131
sssssssssss

This happens as a result of setting the minimal subtitle duration to some value using the tool Subtitle Workshop. It is a useful option which fixes lots of crappy subs that display long subtitles just a few miliseconds!

Why does this happen? The same subtitle stream is plenty of such situations before the point where the muxing broke. Also are the other subtitle streams. However, the muxer didn't fail in that cases. Why does in this one?


I am reporting this to the VDubMod project webpage.

[N_F]

So far I've been unsuccesful in demuxing any subtitle file (.srt) from an ogg file with VDM.

I don't remember who wrote it, but there is a program called OGMDemuxer (file name is OGMDemuxer.exe) that has succeded in this where VDM has failed.

So it is possible the .srt file is muxed properly, just not demuxed properly.

[pirata]

OK guys there was a problem with the srt file I didn't noticed. It was like this:



123
12:12:123 --> 12:12:133 <---This is the one subtitle not showed
xxxxxxxxxxx

124

12:12:124 --> 13:13:131 <---There is a blank line here.
sssssssssss



That was all.

I have been able to demux every stream out of a OGM file, if I remember right. Now, with the latest VDubMod I am not anymore.
This is what I will tell the people developing the program.


Greetings.

[N_F]

Originally posted by pirata
I have been able to demux every stream out of a OGM file, if I remember right. Now, with the latest VDubMod I am not anymore.
This is what I will tell the people developing the program.

I didn't use the earlier versions so that's seems correct. Though I only have the problem with the subtitle streams, the audio are demuxed properly.

[Suiryc]

Originally posted by pirata
I don't know the reason why the muxer failed. I have checked the point where the subtitle stream ends, and the subtitle timings are exactly as I specified above, something like

12:12:123 --> 12:12:133
xxxxxxxxxxx

12:12:124 --> 13:13:131
sssssssssss

Then it is normal there are problems with this.
Subtitles in OGM don't handle overlapping AFAIK and here there is one.
This is the reason why SubtiDS won't show the sub, and why my muxer will end past the first sub ...

[pirata]

@ Cyrius: SORRY!! I meant

123
12:12:123 --> 12:12:133 <---This is the one subtitle not showed
xxxxxxxxxxx

124

12:12:134 --> 13:13:131 <---There is a blank line here.
sssssssssss


There was an error in the second timing. The problem lies in the empty line between 124 (subtitle number) and the second timing. It is not SRT standard-compliant.

BY THE WAY: question for you, Cyrius. I am muxing DivX video + ogg + AC3 and the AC3 is superb, while the OGG playback tends to freeze when seeking ( you seek and leave the time bar and the timer goes on while the video is frozen or run for a while and then freezes). Interleave value problem in VDubMod?

Of course there is also the unavoidable freezing when the movie starts to play. It doesn't seem to happen when the movie is just a short clip (e.g. movie chunk for tests). I think it is due to the AC3 streams. Can it be that the OGM file header needs something that VDubMod doesn't put in?

Also: sometimes, when muxing MP3 with OGG, the movie don't even start to play. The player timer don't even move. You seek, and the movie stays frozen (also the timer). Why? VDubMod problem or OGM Directshow problem?

Also I hope you noticed the demuxing problems we have with the latest VDubMod. When I demux a subtitle stream, I get an empty SRT file.

Finally, a feature request: when will it be possible to join OGMs in VirtualDubMod?

[Suiryc]

Originally posted by pirata
There was an error in the second timing. The problem lies in the empty line between 124 (subtitle number) and the second timing. It is not SRT standard-compliant.
ok

BY THE WAY: question for you, Cyrius. I am muxing DivX video + ogg + AC3 and the AC3 is superb, while the OGG playback tends to freeze when seeking ( you seek and leave the time bar and the timer goes on while the video is frozen or run for a while and then freezes). Interleave value problem in VDubMod?
I hope no. I interleave streams in similar ways so this would have also affected the other audio streams.

Of course there is also the unavoidable freezing when the movie starts to play. It doesn't seem to happen when the movie is just a short clip (e.g. movie chunk for tests). I think it is due to the AC3 streams. Can it be that the OGM file header needs something that VDubMod doesn't put in?
I don't think so. If it would be the case the problem would appear in short and long clips.

Also: sometimes, when muxing MP3 with OGG, the movie don't even start to play. The player timer don't even move. You seek, and the movie stays frozen (also the timer). Why? VDubMod problem or OGM Directshow problem?
If it is not the case make sure to disable the "Enable all streams" in OggDS filter properties. This solve this kind of problem when having multiple streams.

Also I hope you noticed the demuxing problems we have with the latest VDubMod. When I demux a subtitle stream, I get an empty SRT file.
Strange I didn't changed anything I think :/ Will have a look at that.

Finally, a feature request: when will it be possible to join OGMs in VirtualDubMod?
I don't have an answer for this yet. This is not easy to implement ...

[Suiryc]

Originally posted by pirata
Also I hope you noticed the demuxing problems we have with the latest VDubMod. When I demux a subtitle stream, I get an empty SRT file.
Hey hey easy bug ;) I fixed this.

[pirata]

If it is not the case make sure to disable the "Enable all streams" in OggDS filter properties. This solve this kind of problem when having multiple streams.



It has always been set that way.

ALso: the virtualdubmod window resizes automatically when opening a file. It results annoying. Most of the time I'm interested in the input window and it is reduced to a 1/4 size, as a result of that mechanism. It should be configurable to some extent.

About all the playback problems: have you heard something about Tobias lately? They all seem Directshow problems...

About the bug you fixed (where was the problem? you said you hadn't changed nothing...): should we download a new version? Which one?

[Suiryc]

Originally posted by pirata
ALso: the virtualdubmod window resizes automatically when opening a file. It results annoying. Most of the time I'm interested in the input window and it is reduced to a 1/4 size, as a result of that mechanism. It should be configurable to some extent.
A lot of users already complained about that so we disabled the code till Stone-D make it a setting.
For this you can download the bug-fix version proposed on the SourceForge page. (the initial resizing of the window is however not disabled in this version ...)

About all the playback problems: have you heard something about Tobias lately? They all seem Directshow problems...
Nope, except that he joined XipH and that the sources of his filters should be put in their CVS.

About the bug you fixed (where was the problem? you said you hadn't changed nothing...): should we download a new version? Which one?
Well actually this bug was introduced when I allowed to demux an OGM stream with ot without a WAV header. Both demuxing process use the same routines and in the case of a WAV header this one is placed at the beginning of the file. Some other changes were introduced in the routines to take this into account but I forgot to do all those changes in the routines demuxing to a SRT file (so I didn't lie : I didn't change anything ;)) resulting in the bug you experienced (actually the whole SRT file was written but at the end of the process this file was truncated past the first 48 bytes :().
The fixed sources aren't commited in the CVS yet so you will have to wait a bit before a bug-fix .exe is out ;).

[pirata]

Any date for the next release encompassing all the bugfixes?

[Belgabor]

Yes, yesterday