Some tools for Ogg Media files

[Suiryc]

Hi

For those who are interested, I tried to make a command line multiplexer for ogm files (see attachment).

It should work with AVI (video stream only), Ogg/Ogm, AC3 and SRT subtitle files as input.
I also included a tool to extract information from an Ogg/Ogm file.

Be aware that thoses tools aren't perfect (far from it), so USE AT YOUR OWN RISK!

NB :
- you need the ogg.dll and vorbis.dll files (installed by OggDS filter I think) for the tools to work
- these programs are inspired (not based) by ogmtools (developped by Moritz Bunkus)
- these programs don't use DirectShow

Attachment removed. See posts below to find the latest versions of those tools :)

[Koepi]

Great job, I hope the tools work as expected.

Any plans to make them opensource later on?
I'd like to add that to the oggmux sourceforge project, making it a real OGM suite there...

Thanks for your work,

best regards,
Koepi

[Suiryc]

Great job, I hope the tools work as expected.

Me too :).
One more thing : compared to OggMux one cannot specify user comments (i.e. language of audio or subtitle, nor chapters), nor make the output file splitted.

Any plans to make them opensource later on?
Yes of course, just need to be sure this works, and clean up a little the source code ;)


Now, new day, new tool : the Demuxer :) (see attached file)

You should be able able to demux known stream type, i.e. :
- video stream -> AVI file (be aware there may be problems with files larger than 2GB)
- vorbis stream -> Ogg file
- AC3 stream -> AC3 file
- Subtitle stream -> SRT subtitle file

NB :
- again "USE AT YOUR OWN RISK"
- again needing ogg.dll
- again inspired by Moritz Bunkus ogmtools
- again not using DirectShow

Attachment removed, see posts below to find the tool :)

[Dark-Cracker]

hi,

very nice work :) but if i can suggest u could try to make an oggcut tool because a lot of people (especialy under win2k) have reported a crash with the tobias tool (oggcut) .

bye

[Taranli Maren]

Thank you very much. This is going to be quite useful, though I have had a problem with the ogm demuxer. It said "Video stream Packet contains more than one Frame, skipped." And the avi ends up smaller than its supposed to be. It plays, but only if I skip to the second keyframe, it crashes when I try to play the first keyframe. The two ogg files also ended up smaller than they were before, but they played perfectly. The srt was good. The video was divx5 compressed if that makes a difference. The ogm was muxed originally with oggmux.

Thanks :)

[Koepi]

Heh, I just started coding an OggDeMux based on Tobias' filters, but I delay that again - it's so complicated to figure all these filter properties out in a program :-/

Well, maybe I find some motivation again later, but for now I'm fed up with DShow framework again ;)

Would've been nice to see the difference...

Best regards,
Koepi

[Suiryc]

Originally posted by Taranli Maren
It said "Video stream Packet contains more than one Frame, skipped."
Strange, I though this message should never appear (I just included it in my sources in case ...). Will see if there could be something else causing that ...

And the avi ends up smaller than its supposed to be.
I also ended up with smaller AVI files after demuxing, but VirtualDub said me there were the same number of frames, so it seems OK.
Anyway if there are problems here I cannot do anything since I completely rely on AVILib :)
This may be the fact I use AVILib which may behave differently than the encoder (VirtualDub, ...) that have been used to make the original video.

It plays, but only if I skip to the second keyframe, it crashes when I try to play the first keyframe.
This is due (I think) to the "Video stream Packet contains more than one Frame, skipped" message.
As I said this should not happen because this would mean a Packet say it contains at least two video frames, which make then impossible to know where begins the second one and the others :/
Oh yeah, could you use "OGMInfo -p -v3 -l C:\Log.txt ..." on your ogm file and send the first lines (headers and first Page containing "D Packet" from the video stream) so that I could see what is the problem with the first frames in your video stream ? :)

The two ogg files also ended up smaller than they were before, but they played perfectly.
Are you sure ? There should not be any difference (not even a single byte) before muxing and after demuxing ogg vorbis streams.
But it may be due to DirectShow ... I noticed last time that an ogm file I made using OggMux ended with a "redundant" End Of Stream page for the vorbis stream (while the stream had already ended earlier in the file) ...

The video was divx5 compressed if that makes a difference.
No this should not make a difference.


Happy to see it helps some of you :)

[Taranli Maren]

I may be giving you too much here, but better safe than sorry...


0, 1V Page 0 ( 0) 28+ 57 bytes, (INITPAGE, !CONTINUED), pos 0, 0.00-> 0.00ms SYNC, 1 packet(s)
0, 1V H Video Header : DX50, 640x480, 23.976 fps
0, 1V H Packet 0 : 57 bytes, , BOS, !EOS, pos 0
1, 1v Page 0 ( 0) 28+ 30 bytes, (INITPAGE, !CONTINUED), pos 0, 0.00-> 0.00ms SYNC, 1 packet(s)
1, 1v H Vorbis Header : 91200 bps, 2 channels, 48000 Hz
1, 1v H Packet 0 : 30 bytes, , BOS, !EOS, pos 0
2, 2v Page 0 ( 0) 28+ 30 bytes, (INITPAGE, !CONTINUED), pos 0, 0.00-> 0.00ms SYNC, 1 packet(s)
2, 2v H Vorbis Header : 91200 bps, 2 channels, 48000 Hz
2, 2v H Packet 0 : 30 bytes, , BOS, !EOS, pos 0
3, 1T Page 0 ( 0) 28+ 57 bytes, (INITPAGE, !CONTINUED), pos 0, 0.00ms-> SYNC, 1 packet(s)
3, 1T H Text Header
3, 1T H Packet 0 : 57 bytes, , BOS, !EOS, pos 0
4, 2T Page 0 ( 0) 28+ 57 bytes, (INITPAGE, !CONTINUED), pos 0, 0.00ms-> SYNC, 1 packet(s)
4, 2T H Text Header
4, 2T H Packet 0 : 57 bytes, , BOS, !EOS, pos 0
0, 1V Page 1 ( 0) 28+ 48 bytes, ( ...... , !CONTINUED), pos 0, 0.00-> 0.00ms SYNC, 1 packet(s)
0, 1V C Packet 1 : 48 bytes, , !BOS, !EOS, pos 0, Comment Packet
Vendor : Xiphophorus libVorbis I 20011217
1, 1v Page 1 ( 0) 28+ 68 bytes, ( ...... , !CONTINUED), pos 0, 0.00-> 0.00ms SYNC, 1 packet(s)
1, 1v v Packet 1 : 68 bytes, , !BOS, !EOS, pos 0
2, 2v Page 1 ( 0) 28+ 69 bytes, ( ...... , !CONTINUED), pos 0, 0.00-> 0.00ms SYNC, 1 packet(s)
2, 2v v Packet 1 : 69 bytes, , !BOS, !EOS, pos 0
3, 1T Page 1 ( 0) 28+ 68 bytes, ( ...... , !CONTINUED), pos 0, 0.00ms-> SYNC, 1 packet(s)
3, 1T C Packet 1 : 68 bytes, , !BOS, !EOS, pos 0, Comment Packet
Vendor : Xiphophorus libVorbis I 20011217
Comment 1 : LANGUAGE=English
4, 2T Page 1 ( 0) 28+ 68 bytes, ( ...... , !CONTINUED), pos 0, 0.00ms-> SYNC, 1 packet(s)
4, 2T C Packet 1 : 68 bytes, , !BOS, !EOS, pos 0, Comment Packet
Vendor : Xiphophorus libVorbis I 20011217
Comment 1 : LANGUAGE=English
0, 1V Page 2 ( 0) 44+ 4335 bytes, ( ...... , !CONTINUED), pos 0, 0.00-> 0.00ms SYNC, 0 packet(s)
1, 1v Page 2 ( 0) 42+ 3606 bytes, ( ...... , !CONTINUED), pos 0, 0.00-> 0.00ms SYNC, 1 packet(s)
1, 1v v Packet 2 : 3606 bytes, , !BOS, !EOS, pos 0
2, 2v Page 2 ( 0) 42+ 3606 bytes, ( ...... , !CONTINUED), pos 0, 0.00-> 0.00ms SYNC, 1 packet(s)
2, 2v v Packet 2 : 3606 bytes, , !BOS, !EOS, pos 0
3, 1T Page 2 ( 0) 28+ 5 bytes, ( ...... , !CONTINUED), pos 0, 0.00ms-> SYNC, 1 packet(s)
3, 1T D Packet 2 : 5 bytes, SYNCPOINT, !BOS, !EOS, pos 0, 0.00-> 7087.00ms, 7087 samples

4, 2T Page 2 ( 0) 28+ 5 bytes, ( ...... , !CONTINUED), pos 0, 0.00ms-> SYNC, 1 packet(s)
4, 2T D Packet 2 : 5 bytes, SYNCPOINT, !BOS, !EOS, pos 0, 0.00-> 7087.00ms, 7087 samples

0, 1V Page 3 ( 0) 44+ 4335 bytes, ( ...... , CONTINUED), pos 0, 0.00-> 0.00ms SYNC, 0 packet(s)
0, 1V Page 4 ( 0) 44+ 4283 bytes, ( ...... , CONTINUED), pos 0, 0.00-> 0.00ms SYNC, 1 packet(s)
0, 1V D Packet 2 : 9638 bytes, SYNCPOINT, !BOS, !EOS, pos 0, 0.00-> 83.42ms, 2 samples
0, 1V Page 5 ( 0) 44+ 4224 bytes, ( ...... , CONTINUED), pos 3, 0.00-> 125.12ms SYNC, 2 packet(s)
0, 1V D Packet 3 : 5278 bytes, !SYNCPOINT, !BOS, !EOS, pos -1, 0.00-> 41.71ms, 0 samples
0, 1V D Packet 4 : 731 bytes, !SYNCPOINT, !BOS, !EOS, pos 3, 41.71-> 83.42ms, 0 samples
1, 1v Page 3 ( 0) 50+ 4131 bytes, ( ...... , !CONTINUED), pos 22080, 0.00-> 460.00ms SYNC, 23 packet(s)
1, 1v v Packet 3 : 12 bytes, , !BOS, !EOS, pos -1
1, 1v v Packet 4 : 112 bytes, , !BOS, !EOS, pos -1
1, 1v v Packet 5 : 176 bytes, , !BOS, !EOS, pos -1
1, 1v v Packet 6 : 187 bytes, , !BOS, !EOS, pos -1
1, 1v v Packet 7 : 195 bytes, , !BOS, !EOS, pos -1
1, 1v v Packet 8 : 188 bytes, , !BOS, !EOS, pos -1
1, 1v v Packet 9 : 186 bytes, , !BOS, !EOS, pos -1
1, 1v v Packet 10 : 186 bytes, , !BOS, !EOS, pos -1
1, 1v v Packet 11 : 188 bytes, , !BOS, !EOS, pos -1
1, 1v v Packet 12 : 180 bytes, , !BOS, !EOS, pos -1
1, 1v v Packet 13 : 198 bytes, , !BOS, !EOS, pos -1
1, 1v v Packet 14 : 193 bytes, , !BOS, !EOS, pos -1
1, 1v v Packet 15 : 176 bytes, , !BOS, !EOS, pos -1
1, 1v v Packet 16 : 191 bytes, , !BOS, !EOS, pos -1
1, 1v v Packet 17 : 194 bytes, , !BOS, !EOS, pos -1
1, 1v v Packet 18 : 197 bytes, , !BOS, !EOS, pos -1
1, 1v v Packet 19 : 198 bytes, , !BOS, !EOS, pos -1
1, 1v v Packet 20 : 183 bytes, , !BOS, !EOS, pos -1
1, 1v v Packet 21 : 194 bytes, , !BOS, !EOS, pos -1
1, 1v v Packet 22 : 196 bytes, , !BOS, !EOS, pos -1
1, 1v v Packet 23 : 201 bytes, , !BOS, !EOS, pos -1
1, 1v v Packet 24 : 190 bytes, , !BOS, !EOS, pos -1
1, 1v v Packet 25 : 210 bytes, , !BOS, !EOS, pos 22080

[Suiryc]

Thanks.

Originally posted by Taranli Maren
I may be giving you too much here, but better safe than sorry...


...
0, 1V D Packet 2 : 9638 bytes, ... 0.00-> 83.42ms, 2 samples
...

So here is the problem. I wonder how the decompressor can handle this (I mean if what say the ogm file is correct and there are realy 2 frames).
I can't do anything here, except giving this "new" version of the demuxer (it won't skip the data but send it to AVILib as if it where one frame, and warn you that there were n frames in a packet, so don't know what this will give). Please try and tell if this solve the first frame problem.

PS : when the attachement is validated, I will remove the previous one.

Attachment removed. See posts below to find the latest version of the tool :)

[Selur]

thx, for the tool !!
and like "Dark- Cracker" mentioned a oggCut tool would really be appreciated (especially if it can handle 2GB+ ogm files), but no hurry it's just a thing I'd like to have mentioned,..

Cu Selur

[alky]

do you have a little html page or something i could look for new versions?

[Suiryc]

Sorry, don't have a HTML page.
I only posted those tools here, and I will let you know when I make some changes.

[Taranli Maren]

Sorry it took me so long to get back to this. That new version works. The avi plays properly, though the filesize is still different, thats not a problem. Thanks :)

[Mosu]

It's always good to see that one's source code is useful to others :)

[Suiryc]

@Taranli Maren :
I finally found what was the problem with your video :). It is due to dropped frames.
When you have dropped frames in your video, say 1 good frame and then 4 dropped ones, then the OGM (obtained with the DirectShow Ogg Multiplexer) will have a Packet that say to contain 5 samples.
Here you are lucky because you have only one dropped frame, and since I didn't know what happens with dropped frames, in fact my Demuxer acts like it throw away them (so the final AVI clip is shortened by the number of dropped frames you have in your video).

@Mosu :
Hi, your tools was a great help at the beginning because I wanted to see if it was possible to mux "manually" streams to OGM :).
Before I publish my sources, I can however tell you about a problem I encountered while rewriting the whole thing (well in fact I didn't quite understand all what was doing your source code, so I rewrote it from scratch :D ) : The granulepos correspond to the end of data and not the beginning.
Why do I tell you that? Simple : as you when I mux, at the end I decide in which order place the Pages in the file, and of course this order is defined by the timestamp of the Page, the timestamp is calculated depending on he granulepos and the samplerate. The problem : as the granulepos correspond to the end of the Page, it's the same with the timestamp, so in fact ordering Pages depending on their timestamp is not that good (I experienced severe stuttering with my first tests :( ). In my case I introduced a new variable named last_granulepos that contains the last known granulepos of the stream, and I calculate the "beginning" timestamp of a Page with that value, and of course now the video is more "stable" :).
Hope this will help you, and again thanks for your tools :).


Well I think that today I will post the latest versions of my tools, plus a cutter (well in fact it's just a splitter at the moment ...).
Expect something great ;) (I hope :D )

[Mosu]

Hi.

The granulepos correspond to the end of data and not the beginning.

Yes, I know, and I've already experimented with it a bit. But as a matter of fact the OggDS drivers don't do that correctly either.

Nevertheless I've just modified the relevant files (the packetizers and ogminfo, which now bases decisions about 'being out of sync' on the start time (the last page's granulepos of the current stream) rather than on it's end time). The reason I haven't done it before is that with the interleaving being slightly wrong did not give me any problems at all - neither with mplayer nor with OggDS (e.g. ZoomPlayer, WMP6).

Now it should (like 'I hope but am not sure' ;)) be ok. I'll release a new version soon (as soon as I get MP3 support working correctly...)

[Suiryc]

Eh eh my newest version also include MP3 support, and another format (but you will know more when I post the tools).


BTW your idea of using Reader and Packetizer was really great, but I found a thing that helped me a lot compared to what you did :
You have a Reader for each type of input file (me too), and a Packetizer for each type of stream (one for video, one for vorbis, one for PCM), but I succeeded in having only one Packetizer for everything, which is a bit more handy (I think).
The hard thing was to find how to calculate sample_rate and timestamp in each case : in fact there is one formula that apply to everything, but I found it the hard way (first by guessing it - and it was a good guess :) - and then by "verifying" it).
So compared to you what I do is fill the stream_header in the Reader, and send it to the Packetizer (which then have everything it needs to calculate timestamps).

As I didn't know that much thing about multimedia and everything, it was also hard for me to find how to correctly fill this damn stream_header :devil: , and maybe you are experiencing same things with your MP3 support :
I had the really bad idea that stream_header.samples_per_unit was related to the number of samples contained in one Frame (i.e. 1 sample - 1 frame - for video, and for example n samples for 1 Frame of MP3 - n=384 for LayerI and 1152 for LayerII/III) ... but I ended up with really bad timing at the end (I first experienced that with AC3 : there was no problem playing the file, but the indicated time was completely wrong). Finally I found that it is related to the final sample_rate (i.e. if the MP3 or AC3 is 48KHz, then samples_per_unit must be set to 48000, and so on).
Maybe this will help you (or maybe I am the only person on earth who didn't knew that :scared: ).

[tiki4]

Mmh, I've got a question, maybe someone of you can help me. As all of you know it has been quite a hassle to get a format like AC3 into an Ogg container. The problem seemed to be in the first place, that the muxing in Graphedit using the direct show filters didn't work out right.
Then someone had the idea to use a muxed AVI with AC3 sound and mux that stuff directly into the Ogg file. That method works but one cannot add additional soundtracks as the AC3 sound is always played.
When I saw this thread with the new command line muxer I had the idea to use the ogmuxer first on the AC3 stream to create a n Ogg file containing only the AC3 soundtrack. Then I used Koepi's program to mux an XviD AVI without sound, the Ogg containing the AC3 stream and an additional 2 channel Ogg Vorbis stream into the final OGM.
Unfortunately the playback has the same problem as before. The AC3 stream is always played and one has to use mmswitch.ax to switch between the AC3 and the Vorbis soundtrack.
When I render the file in Graphedit the output pin of the AC3 stream says something like AVIform.
Does that mean that the problem is in the OggDS implementation and there's no way to cirumvent that problem? I'd be really interested in a solution as MC Vorbis never worked the right way and the channel coupling may take some more month to get implemented.

Any ideas are welcome.

Regards,

tiki4

[Suiryc]

Hi,

Time for a little update :).
As the zipped file exceeded the 200K limit (213K :( ), I first used RAR (with Solid Compression) (see attachement)...
So you will have to unzip and then unrar it (sorry for that guys).

So what are the changes ?
First I added buffering to speed up a little the process (for all the tools).
I then tried to push AVILib to its (in theory) possible limits (i.e. 4GB AVI files), but I failed on that :(. So I took some extreme measures, and decided to try some routines coming from a well known tool .... VirtualDub (1.4.10).
This push my tools in a real alpha state because as you know VirtualDub is a Windows GUI application, and so behave its tools. But my tools here are commandline ones :D . So I had to "remove" some functions (those relying on the GUI part of VirtualDub), and thus I cannot guarantee you that all will work like a charm in every situation.
So more than ever : USE AT YOUR OWN RISK!

Now changes for each tools:
- OGMinfo
-> added some more info (granulepos estimation, & timestamp estimation for Vorbis streams)

- OGMuxer
-> removed the use of AVILib
-> added some reading routines coming from VirtualDub 1.4.10
-> added some functions coming from OggMux (the automatisation setup file parsing). In other words you can use your omx file with OGMuxer
-> enabled MP3 files as input
-> added another known input file type : it begins with an 'A', finish with an 'F' and have a '$' in the middle (yes you read well). As for AVI only the video stream is muxed

- OGDemuxer
-> removed the use of AVILib
-> added some writing routines coming from VirtualDub 1.4.10

And the new tool : OGMCutter (well in fact it's only a splitter at the moment).
OGMCutter should be able to cut your ogm file on (video) keyframes, choosing them depending on the split size you gave.
OGMCutter should also be able to "adjust" the comments that are in the original file (Title and Chapters) according to where it cut (see the txt file that come with OGMCutter).


So what is good in all that :
- the use of some routines coming from VirtualDub should break the 2GB limit of the previous version of the tools (I successfully muxed a 2.3GB / 3 hours AVI file into an OGM file)

BUT

- as I said VirtualDub is a GUI and I had to "cut" some parts, so maybe there will be more problems with the latest version of the tools than before
- there is also a bad news : it seems that >2GB OGM files give headaches to Windows (when I select such a file in the Explorer, then the "explorer.exe" process - i.e. the Windows' Desktop - stay forever @ 99% of CPU use and I have to "kill" it :(, and moreover when I try to read the file with WMP6.4 the video stutter and I cannot seek). Fortunately when I cut the file into 702MB there is no more problem :).


Enjoy.

Attachment removed. See posts below to find the latest versions of those tools

[Suiryc]

Originally posted by tiki4
The problem seemed to be in the first place, that the muxing in Graphedit using the direct show filters didn't work out right.
...
Does that mean that the problem is in the OggDS implementation and there's no way to cirumvent that problem?

There is the same problem when you mux everything with OGMuxer : the AC3 track is allways played. So I also think it's related to OggDS (but maybe there is no solution for that, who knows).

[Taranli Maren]

I'm confused, if the grame was dropped during encoding, then wouldn't it just be missing? so it wouldn't shorten the length of the avi my any amount. or are you saying that your demuxer is dropping the frame for some reason? This was encoded from a dvd, as opposed to video capture, so it doesn't seem like there should be any dropped frames in encode-time. (Except for the ones decimate drops as part of ivtc)

[Mosu]

If frames are drop during encoding the encoder may insert 'empty' frames into an AVI. For an AVI there is an index entry for this frame, but the data has zero length. For a OGM this translates into a video packet whose length header is set to the number of 'empty' frames that were present in the AVI. If there were no 'empty' frames then the length header is not present.

Now if someone wants to recreate an AVI from an OGM then he has to recreate these 'empty' entries in the AVI index aswell. Otherwise the audio/video synchronization will be of. The problem is that apparently only the video frame was dropped, but not the corresponding audio frame.

[Suiryc]

Originally posted by Taranli Maren
or are you saying that your demuxer is dropping the frame for some reason?

Yes, and the reason is : I didn't know at that time that dropped frames would cause that, so while processing my demuxer was telling to the AVI writer to write 1 frame (whereas it should also write a 0-length frames for each dropped one).

But the new version should handle that now.

[eclipsedvd]

Hi,

here is a little addon to Cyrius Tools.

Now, you can demux/cut ogm files with the right-click on the mouse

http://www.eclipsedvd.firstream.net/FILES/OGMTools_20020912.exe

Greets
ECLiPSE

[Suiryc]

:)

Oh BTW I forgot something with the A$F support : I forgot to reuse the code (that I uses with AVI support) for correctly handling dropped frames. Normally there should be no problem with the resulting OGM file except that demuxing it back to an AVI file could result in shortened clip (as I said before).
So if I were you I wouldn't use A$F too much for the moment (it's corrected in my sources but ATM I am trying to add audio support).

[Emp3r0r]

great work guys, can't wait to test the AC3 support and the >2GB file support, thanks for the tools

[Belgabor]

Originally posted by Suiryc
:)

Oh BTW I forgot something with the A$F support : I forgot to reuse the code (that I uses with AVI support) for correctly handling dropped frames. Normally there should be no problem with the resulting OGM file except that demuxing it back to an AVI file could result in shortened clip (as I said before).
So if I were you I wouldn't use A$F too much for the moment (it's corrected in my sources but ATM I am trying to add audio support).

while you're at it, plz add some error tolerance if possible. This could be the perfect way to rescue those f**ked up a$fs we all learned to love.

Cheers
Belgabor

[sherpya]

I don't known if is the right place, anyway I've made a python library
to parse and handle ogg chapter list.
It's not for newbe (sorry) but I think it's better than nothing :D
Peraps I'm currently using it.
You can download caplib.py (http://forum.doom9.it/software/other/caplib.py)

The lib is designed to be used by a small python prog:
You can open ogg chapter files
Split an ogg chapter file
Parse result from a html page donwloaded from http://www.bn.com/
(search for a title and select "From the DVD->Scene Index")
Can import titles from a list parse from html file

A simple example:

#!/usr/bin/env python
import caplib
a = caplib.Caps("lotrcaps.txt")
b = caplib.Caps("lotr.html", format='bn')


a.import_titles(b)

c,d = a.split_at("01:30:00.000")
print c
print "*" * 78
print d


Note: It's not very tested it only the first public version.

@Suiryc
It would be great to integrate your tools into virtualdub

[The Link]

Cool! There are other python users than me on this forum. Hope I get some time to have a look at this.

[Suiryc]

Originally posted by Belgabor
while you're at it, plz add some error tolerance if possible. This could be the perfect way to rescue those f**ked up a$fs we all learned to love.

:D

Well it seems there is no good way to export "special" audio format (for example WMA or DivX Audio) from A$F (or AVI) to Ogg. The Ogg file won't play the audio (saying it lacks a codec ... don't know why .... it seems to be OK with MP3 audio in AVI so either it's a "problem" with OggDS, or it's a restriction from Micro$soft that doesn't allow format other than AVI and A$F to play those kind of stream).
Well anyway I have my "VirtualDub 1.4.10 special A$F" version (I had to add some things because of this damn "VBR Audio" check) ... (hey sometimes you find really strange things in those A$F files ... like a >10MB Script Command stream that doesn't seem to do anything :rolleyes: )


Originally posted by sherpya
It would be great to integrate your tools into virtualdub
Well this is another thing ...

[Belgabor]

Anything with more error tolerance than the original VDub implementation floating around would be really nice :)

Cheers
Belgabor

P.S: I second sherpyas wish ;)

[Suiryc]

Originally posted by Belgabor
Anything with more error tolerance than the original VDub implementation floating around would be really nice :)

Cheers
Belgabor

P.S: I second sherpyas wish ;)

The VirtualDub old (i.e. Version 1.3) A$F support doesn't have error tolerance ? (I just took the code, modified some things, added others so that it was "up-to-date" with version 1.4.10)

[TobiasWaldvogel]

Streams which are created with my DirectShow filters MAY contain more than one frame per packet. I just take the frames that I get from the preceeding filter (in most cases the AVI splitter) and store them in the stream with the corresponding timestamps. It seems that the AVI splitter sometimes sends more than 1 frames at a time . Thats's all. In Windows there the MPEG4 decoders accept more than one frame per packet. Currently I don't know how to seperate them. Any ideas are welcome.

Kind regards,
Tobias

[Suiryc]

Originally posted by TobiasWaldvogel
Streams which are created with my DirectShow filters MAY contain more than one frame per packet. I just take the frames that I get from the preceeding filter (in most cases the AVI splitter) and store them in the stream with the corresponding timestamps. It seems that the AVI splitter sometimes sends more than 1 frames at a time . Thats's all. In Windows there the MPEG4 decoders accept more than one frame per packet. Currently I don't know how to seperate them. Any ideas are welcome.

The only case where I saw more than one frame in a Packet (with your DirectShow filter) was due to dropped frames. So in fact there wasn't really various frames in the Packet, just the (first) good one. As DirectShow still give good timestamps (because it takes care of the dropped frames), there is no problem (I mean while playing the OGM file times are still good).

So I don't think there is need to separate them (since in that case it's impossible because there is in reality only one frame)
IMO DirectShow won't send more than one frame at a time to your filter (it would be crazy to do so because that would mean each filter involved in video processing under DirectShow should have the ability to separate adjacent frames whatever is the format of the frame : uncompressed, Indeo, DivX 3.11, DivX 4, DivX 5, XviD, and so on ...).

Now my commanline muxer acts like your DirectShow filter concerning dropped frames in the AVI source file.

There is however one thing you may know : with an AVI file that had at the very beginning one good frame and 4 bad ones, the first video Page (with data) had a granulepos of 0 with your DirectShow filter (the way I do it with my muxer the granulepos would have been 4, i.e. the granulepos of the last data in the Packet).
But this doesn't seem to be a problem while decoding (well in fact I cannot really tell because of the dropped frames that make the video like "stuttering").

Then a question concerning the subtitle stream : why having choosed the beginning of the Page for granulepos and not the end (as described in the Ogg secification) ?

And while I am at it (I know I may ask too much things at a time :) ), I have one question concerning the way your DirectShow filter give audio streams to the next filters : the type of audio is based on the stream_header.subtype field, isn't it ? (so if I have "0161" in the subtype field, your filter tells that the audio format - I think of the wFormatTag field in WAVEFORMAT or WAVEFORMATEX structure here - is 0x0161 ?)
This would help me knowing if the fact that my OGM file containing a video stream and a WMA (or DivX Audio) stream won't play the audio (saying it lacks codec whereas the codec is here) is related to your filter or (more likely) to a restriction of Micro$oft in their filters.

Thanks.

[TobiasWaldvogel]

Originally posted by Suiryc
Then a question concerning the subtitle stream : why having choosed the beginning of the Page for granulepos and not the end (as described in the Ogg secification) ?

I don't set the page granulepos. I just set the packet granulepos and the ogg library sets the page position accordingly. Therefore the page granulepos is always the first position of the last complete packet in a page. This applies also to vorbis packets. The page granulepos is never set manually.

And while I am at it (I know I may ask too much things at a time :) , I have one question concerning the way your DirectShow filter give audio streams to the next filters : the type of audio is based on the stream_header.subtype field, isn't it ? (so if I have "0161" in the subtype field, your filter tells that the audio format - I think of the wFormatTag field in WAVEFORMAT or WAVEFORMATEX structure here - is 0x0161 ?)
This would help me knowing if the fact that my OGM file containing a video stream and a WMA (or DivX Audio) stream won't play the audio (saying it lacks codec whereas the codec is here) is related to your filter or (more likely) to a restriction of Micro$oft in their filters.

You are right, for other audio format (not vorbis) I use a waveformatex structure for pbFormat and subtype contains the wFormatTag field. 0x0161 is WindowsMedia but it seems that the WMA decoder ONLY connects to the AFS reader. If you try to connect it to an AVI or WAV containing audio with ID 0x0161 it happens the same. It seems that Microsoft wants to limit the use of Windows Media to ASF/WMA

[Suiryc]

Originally posted by TobiasWaldvogel
I don't set the page granulepos. I just set the packet granulepos and the ogg library sets the page position accordingly. Therefore the page granulepos is always the first position of the last complete packet in a page. This applies also to vorbis packets. The page granulepos is never set manually.

Sorry for having said it like that because in fact I know that (I talked of Page because in the case of subtitle streams there is only one Packet in a Page, which means Packet granulepos = Page granulepos - and of course even I don't set the Page granulepos manually, the ogg library is kind enough to do that :) ).

In fact I was wondering if I were misunderstanding the Ogg specification or the way subtitle streams are described :
Page's granulepos is described as the granular position of the last fully decodable data of the Page ("The position specified is the total samples encoded after including all packets finished on this page" is what is said). And for Packet containing text data, it is said that "lenbytes" (that represents the number of samples in the Packet) is expressed in ms.
So when the first Page/Packet containing text data says it contains 5000 samples (i.e. the subtitle lasts 5 seconds), I was surprised to see that its granulepos was 0 (i.e. the position of the first sample), whereas I would expect it to be 5000 (number of samples in the Page/Packet).

[inoteb]

Originally posted by Suiryc


There is the same problem when you mux everything with OGMuxer : the AC3 track is allways played. So I also think it's related to OggDS (but maybe there is no solution for that, who knows).

I agree with that: 3 month ago I made several tests with OGM containing [Avi+AC3]+Ogg, and never reach success really. (see ).
Nevertheless, Blight put a nice code in ZoomPlayer to change from one audio track (AC3) to the other (Ogg), so the 2 are not superimposed anymore...
I quote him:
"To support multiple audio tracks in zoom player, originally written for AVI, I included code that checks the number of renderers then shuts them off only keeping the first renderer active. This assures only one audio track at a time is active.
I wrote it in such a way that it isn't AVI specific, so in theory, it should work with anything with more than one audio renderer.
All the detected audio renders are then listed under the "Audio Track" entry of the context menu."

I'd love to hear Tobias' opinion on the subject. I know you're working with the TCMP team to improve the OggMedia support. But can we expect new releases of your DS filters (Ogg & subtitles) fixing some issues (particularly concerning AC3 and SRT display, if there is solutions, of course!) in the future ?

Regards,
inoteb ;-]

PS @Suiryc
"OGMCutter should also be able to "adjust" the comments that are in the original file (Title and Chapters) according to where it cut" :
I love that!!! :D I gonna try it very soon...

[sherpya]

Originally posted by Suiryc

And while I am at it (I know I may ask too much things at a time :) ), I have one question concerning the way your DirectShow filter give audio streams to the next filters : the type of audio is based on the stream_header.subtype field, isn't it ? (so if I have "0161" in the subtype field, your filter tells that the audio format - I think of the wFormatTag field in WAVEFORMAT or WAVEFORMATEX structure here - is 0x0161 ?)
This would help me knowing if the fact that my OGM file containing a video stream and a WMA (or DivX Audio) stream won't play the audio (saying it lacks codec whereas the codec is here) is related to your filter or (more likely) to a restriction of Micro$oft in their filters.

Thanks.

You will able to use "outside the asf reader" only hacked dlls (aka divx audio)
0x160/0x161 are handled by windows media audio v1/2
0x162 is the new media audio from corona
There is only a "Direct Media Object" for decode it (0x162) and connects only to ASFReader.
So wmv9 is more "Blackboxed" than previous versions
Note divxaudio in divx3.22 package is an acm driver not a directshow filter
Btw beware, take a look here:

http://www.advogato.org/article/101.html


---
A question:
I've seen ogm splitter is able to split correctly chapter list.
It would be possible to "trim" out chapters not bound in the file
Also it would be (or it is) possible to mux subtitles and chapter
into an existing ogm file?

[Suiryc]

Originally posted by sherpya
You will able to use "outside the asf reader" only hacked dlls (aka divx audio)
I installed DivX audio (from Nimo codec pack) and I was able to have the audio coming from an AVI file that have audio at 0x0161 format.
But it didn't worked with the OGM file :(

Btw beware, take a look here:
http://www.advogato.org/article/101.html
Yeah I know, but my test were more for educational purpose than anything else, since there is no interest in "converting" A$F to something else (OGM here) if you cannot have the audio with it :(

So I doubt anyone use this "functionality" (I even don't)
And unless somebody tells me not to do so, I would consider to remove that ...

A question:
I've seen ogm splitter is able to split correctly chapter list.
It would be possible to "trim" out chapters not bound in the file?
Well I made it the easiest way here : I know where I cut, and I look at all the chapters in the comments and adjust the time.
It would be easy to throw away chapters that belong to next parts, but it is another thing for those belonging to previous parts, because comments are like that :
CHAPTER01=...
CHAPTER01NAME=...
CHAPTER02=...
CHAPTER02NAME=...
...

In the first time I threw away chapters belonging to previous parts, for example the first chapter, which make the comments like that :
CHAPTER02=...
CHAPTER02NAME=...

The problem is that (at least in BSPlayer) then chapters are not taken into account anymore (because there is not the first chapter - CHAPTER01 things -).
So the solution would be to look at all the chapters, throw away those not belonging to the current part, search the lowest one (here CHAPTER02) and also adjust the chapter number.
This is possible of course, but I thought it was maybe too much here.
I also thought that keeping all the chapters was the best solution after cutting : in each file you know what are all the chapters in the entire clip, and their time (unless they belong to a previous part).

Of course if some of you think that just throwing away chapters is better in some situations, I could allow that too (then you would precise whether you want to keep all the chapters, or if you want to "trim" them).


Also it would be (or it is) possible to mux subtitles and chapter into an existing ogm file?

Yes it is possible.
You can use an omx file (same as OggMux) :
in the "movie" tag you use your ogm file, in the subtitles tag, you precise your subtitle file with the comment, and in the chapters tag you precise the file (same formats supported that OggMux) containing the chapters.
That's all :).

Well you wouldn't be able to use this omx file with OggMux since the video file must be an AVI one, but omx file was a convenient way for me to add comments and chapters functionality :)
With OGMuxer you would also be able to precise other OGM files, or even AC3/MP3/SRT ones in the soundtracks or subtitles tags because I just take the filename and open the file (my program determines automatically the format).

[sherpya]

About the divx audio, what are you using to demux the audio?
DirectShow or ACM? (I will look the enitire thread maybe I've yet replied to this).
Anyway you don't need to decode the stream but extracting divxaudio to a file becomes a wma file?
If you put an avi file with divx audio into graphedit you will see
divxaudio is decoded by windows media audio dmo decoder
and accepts the input from avi splitter (and also from an avi parser)
Then I think it's also possibile... however I don't known about to insert a dmo into a graph

for chapter splitting in my python library I do this for the next split part:

- chapter list for the previous is truncated
- chapter number restart from 1
- find the time for the last chapter of the previous split and insert it as chapter 1 with time 0, this only if the first chapter of the second split is not at the ogm split time (I doubt for it :D )
This replicates last chapter (and for me it's ok) but you can also add an option to prevent this.


Edit: Ogm files with wma audio wont play in wmplayer 6.4 because doesn't support dmo, peraps with 9 oggds crashes, just to wait the new tobias's release that fixes issue with wmp9 or found an hacked wma filter (only for version 1/2, version 3 hasn't directshow filter)

[Suiryc]

Originally posted by sherpya
About the divx audio, what are you using to demux the audio?
DirectShow or ACM? (I will look the entire thread maybe I've yet replied to this)

No, I use a "hacked" VirtualDub (if we are talking of the same thing).
I ask this VirtualDub to open the file, and to give me the video and audio stream (so no problem here).
I loop on the number of frames for each stream and give this to my program tools, which then create Packets that are given to the Ogg library which returns Pages I write in the file.

So, normally, I have the real good audio stream in the OGM file, but the stream is then not usable with DirectShow (when I open the file in graphedit it says it couldn't render one of the streams, and of course it is the audio one).



For the chapter thing I should be able to implement that.

[Emp3r0r]

I have an older OGM that has AC3 in it which I created with the old method of muxing with avi first then into the ogm file. I demuxed it to the .avi and the .ac3 and the .ac3 file plays fine in WMP6.4 but when I try to remux it using ogmuxer I get the following error
G:\Documents and Settings\Jeremy\My Documents\My Movies>ogmuxer -o matrix.ogm matrix.ac3
OGMuxer v0.9a2 - an Ogg Media File multiplexer
Copyright (C) 2002 Cyrius

Using some of the VirtualDub 1.4.10 reading routines
VirtualDub Copyright (C) 1998-2001 Avery Lee
<http://www.virtualdub.org>

Warnning in parse_args (OGMuxer.cpp) @ 257 : matrix.ac3 is not of a known type,
skippeddoes my .ac3 file need a special wav header?

PS: I will try with an .ac3 file created by dvd2avi and see if i get the same error

[update] ok it must be a bummed .ac3 file because the other .ac3 I tried worked fine, i'll try and demux it using graphedit and see if that fixes my problem

[sherpya]

Originally posted by Suiryc


So, normally, I have the real good audio stream in the OGM file, but the stream is then not usable with DirectShow (when I open the file in graphedit it says it couldn't render one of the streams, and of course it is the audio one).

I've wmp9 installed so I'm able to render such audio files, wmp9 installs WMA DMO Decoder, but I'm not able to play wma into ogm (muxed with oggmux, not tried with your muxer)
But remember this is only possible for audio, windows media video stream will connect ONLY to an ASFReader


For the chapter thing I should be able to implement that.
This is fine
:D

@Emp3r0r
If you have used nandub to demux ac3 the file now has a "wave" header, even besweet won't work with wave ac3 files.
I've solved it with graphedit:
render the file and connect a "Dump" (is in the audiofilter package) after wave parser, then delete the other (rendering filters)
Press play...
Note: Render of an ac3 file in graphedit don't work if you don't have installed an ac3 decoder filter (in audiofilters package)

[DSPguru]

Originally posted by sherpya
even besweet won't work with wave ac3 files.are you sure about it ?
i always thought it handles it correctly... :o
anyway, you can remove that wav header with BeSplit.. (also mentioned in the 'Audio FAQ' sticky thread)

[Koepi]

I can verify this, you have to fix the Wav-ac3 with besplit, after that besweet works with it.

Regards,
Koepi

[Suiryc]

Originally posted by sherpya
I've wmp9 installed so I'm able to render such audio files, wmp9 installs WMA DMO Decoder, but I'm not able to play wma into ogm (muxed with oggmux, not tried with your muxer)
No need to try with my muxer, only the version I have here (and not the one I released) can "try" to do that ;)

If you have used nandub to demux ac3 the file now has a "wave" header, even besweet won't work with wave ac3 files.
Well if files are not 100% normal (i.e. without any Wave header - so do not demux with VirtualDub/Nandub and then try to mux with my muxer, because this won't wotk : you have to remove the wave header), they won't work.

BTW few months ago I succeeded in encoding Waved AC3 to MP3 using BeSweet :/.
As DSPguru said I think that BeSweet can handle Wave headers on those kinf of files.

[Mosu]

So when the first Page/Packet containing text data says it contains 5000 samples (i.e. the subtitle lasts 5 seconds), I was surprised to see that its granulepos was 0 (i.e. the position of the first sample), whereas I would expect it to be 5000 (number of samples in the Page/Packet).

I agree. Although I've made the same mistake (actually I've just tried to emulate the OggDS behaviour and not thought about it all that much) with my Linux tools I'd strongly suggest that you, Tobias, correct your filter's approach. I'd like the OGM files (produced bei either OggDS, the Windows tools or my Linux tools) to be as standards compliant as possible, and at the moment subtitle support is definitely broken.

[Suiryc]

Originally posted by Mosu
I'd like the OGM files (produced bei either OggDS, the Windows tools or my Linux tools) to be as standards compliant as possible
It's what we all want to do I think :)

While we are at it, I have a question for both of you (Tobias & Mosu) : what is according to you the granular position of the first sample in a stream? 0 (like in VirtualDub : first frame = frame 0) or 1?
Because with OggDS video & text samples seem to start at granularpos 0 (i.e. first sample = granularpos 0, and so on), but it seems that Vorbis samples (in Ogg files) starts at granularpos 1 (i.e. the first sample in the stream is at granularpos 1 - I think it's like that because every Page's granularpos is an even number, but correct me if I am wrong here).

Presently I assume that it is 0, but every time I make a modification I wonder if it is good or not (because of the Vorbis case).

If anyone knows the answer, please don't leave me in the dark here :)

[Mosu]

Originally posted by Suiryc

While we are at it, I have a question for both of you (Tobias & Mosu) : what is according to you the granular position of the first sample in a stream? 0 (like in VirtualDub : first frame = frame 0) or 1?

My current implementation sets it to 1 for the first video frame, because Xiph's documentation clearly states that a page's granulepos (and therefore the packet's granulepos as well) corresponds to the end position.

On the other hand my OGMTools emulate the OggDS behaviour regarding the subtitle's granulepos... The problem is that there are already files that use the 'broken' method, and these would not be displayed correctly if the behaviour was changed. Perhaps Tobias can add an option to switch between the two interpretations while demultiplexing and fix the multiplexing method.

MPlayer, THE movie player for Linux, has only recently got support for subtitles in OGM which emulates the OggDS behaviour as well. But I will submit patches to change that as soon as Tobias indicates that he will do that for his filters.

Tobias, you see, we'd really like you to do that :)

[Suiryc]

Originally posted by Mosu
My current implementation sets it to 1 for the first video frame, because Xiph's documentation clearly states that a page's granulepos (and therefore the packet's granulepos as well) corresponds to the [B]end position
In the beginning I was doing the same (because of the Xiph's documentation too), but then I saw what seem to do OggDS in such cases I changed to the present situation because I thought that even if my tools (try to) comply to the standard, it's of no use if the filter that render the file behave another way ...

Now I think I will come back to the previous behavior (i.e. first sample = granulepos 1).

Thanks :)

[Mosu]

I know what you mean - that's why I also implemented the subtitle support the way I have. The problem with video and granulepos starting with 1 or 0 however does not pose such a great problem - the video will not be off by that much (I know, 40ms at 25fps, but we start noticing delays at approx. 80ms).

[Mosu]

Just an update. After talking with Tobias I'll be sticking to the current granulepos calculation for subtitle streams and start granulepos values for video streams at 0 for the first frame.

[Suiryc]

OK

I updated my tools according to that also now.
I put those here (http://cyrius.bunkus.org).

I made updates on the splitter (as sherpya proposed), so now you can :
- throw away chapters belonging to a previous part
- throw away chapters belonging to a next part
- keep the last chapter of the previous part (unless the first of the current part start at the very beginning)
- keep all chapters or any combination of the 3 above

You can also prevent my tool from changing the title of the clip (i.e. prevent it from adding " - Part #" at the end of this title, like it does for the filename).

I think this should be enough for everybody ;)

[Emp3r0r]

It's good for me ;) Maybe it is time to start making that GUI i've been dreaming about with an autochapter feature using bn.com like the python libarary.

[mrgone]

wow, cool
these come handy
right what i need now

[ookzDVD]

http://membres.lycos.fr/suiryc

hmmm.... I have a problem connection to that site :(
I hope somebody could provide a mirror. thank you.

[Suiryc]

Hi, I changed some little things to see if the problem is related to my pages (I hope I am not that bad at coding html pages ;) ) or to the site itself.

I received propositions for mirroring or even hosting my pages so if problems remain you will have to wait till this is done ;).

Hope other guys are enjoying my little tools :)


PS : oh I forgot to say I released my sources ...

[Suiryc]

Alright now you will find my tools here : http://cyrius.bunkus.org.

This site is up thanks to Mosu (Moritz Bunkus), so we should all thank him at least twice : first for developing ogmtools (on which I based my tools) and then for being kind enough to host my little tools :)

Thanks again Mosu :D

Regards.

[joerg]

I just want to thank you, Suiryc, for your great tools! I was desperately looking for a good ogm splitter, when I found your tools, which worked just great. Before I tried to use OggMux for both muxing and splitting and it silently crashed i.e. just terminated itself) when splitting or created unusable files. Furthermore it doesn't adjust the chapter-info for the two parts. So I couldn't use it for splitting - only for muxing. Then I tried Ogg File Cutter which worked basically OK, but didn't allow me to specify a MB-size for splitting - so to find the right cut point prooved to be quite difficult. AFAIK it also doesn't support chapter info adjustment when splitting.
Then I found your OGMCutter - which is just great! Thanks a lot :)
eclipsedvd: your shell enhancements for the OGMTools won't work for me :( When I select I want to split files a Window opens for a fraction of a second and closes again immediately. I must admit, though, that I replaced the tools from your package with their latest versions before trying the splitting the first time. Could that be a problem? If you have no idea what might be the problem here: can you at least tell me how to remove the non-working extensions from the context menu?

[Suiryc]

Happy to see the tools seem to work :)

Originally posted by joerg
eclipsedvd: your shell enhancements for the OGMTools won't work for me :( When I select I want to split files a Window opens for a fraction of a second and closes again immediately. I must admit, though, that I replaced the tools from your package with their latest versions before trying the splitting the first time. Could that be a problem? If you have no idea what might be the problem here: can you at least tell me how to remove the non-working extensions from the context menu?

:/
Strange I made only internal changes so all should be OK (even if you replaced the orignal version with the latest one).
Just a stupid question here : you tried the splitting on a file larger than 650MB or 700MB (the two splitting options that are in eclipsedvd enhancement) ? Because I know only 3 ways my splitter stop at the beginning :
1. your ogm is corrupt or something like that (I hope it's not the case ;)
2. the splitting size is too small (i.e. my splitter was unable to cut the file because the size of a part would exceed what you wanted - unlikely to happen except if you precised a really realy small split size, or if there are only one key-frame in your clip, or if there is a bug in my tool ;) ) ... well even for that my splitter first analyse the file so the window should have lasted more time
3. the size of the file already exceeds the splitting size you precised
4. oh there is fourth one : my tool is buggy (very unlikely to happen ;) )

If you still want to remove those extensions here is what you can do :
- open regedit
- go to HKEY_CLASSES_ROOT
- find "ogmfile"
- -> Shell
- remove the "Split" (Split@700MB) and "Split 2" (Split@650MB) keys

[TobiasWaldvogel]

[QUOTE]Originally posted by Mosu


My current implementation sets it to 1 for the first video frame, because Xiph's documentation clearly states that a page's granulepos (and therefore the packet's granulepos as well) corresponds to the [B]end position.

The text from the Ogg docu is "The position specified is the total samples encoded after including all packets finished on this page". As the Ogg framing can only take the granulepos from the packets this means that "granulepos" of the packets also must also reflect the total number of sample, i.e. 1 for the video packet.
In case of vorbis the behavior is a little bit different: the first packet has a granulepos of 0 but this still fits in the rules because a single packet can't be decoded. You will need at least two packets.

I will change that in the next release and reflect the new behaviour with a different identifier in the header packet. I thought it in something like "videoV2" to maintain backward compatibility to all streams allready created. Anyway you can easily update them by just demultiplexing and multiplexing them again. (E.g. with my DS-based OggCut example just open them and save them again without any further action).

Concerning the subtitles the unit used for granulepos is in ms. I would suggest to interpret samples as "ms" and therefore to put the end time in ms as granulepos. Currently I'm treating subtitles as "one" sample but now I think it would be more natural to interpret samples as ms.

I.e. a subtitle which starts at 00:00:01.000 and ends at 00:00:02.799 would have granulepos 2s + 799ms + 1 (because we start 0) = 2800 and with length (inside the packet) set to 1800

I will add this in the next version of the filters and give you all the details to adapt you tools accordingly. I'm sorry for any inconvinience this may cause.

Kind regards,
Tobias

[TobiasWaldvogel]

I'm also going to change the architecture of the filters. I currently creating some libraries which will be load dynamically according to the streamtype. The idea behind is to make it easier to adapt other formats like flac and speex and to make it easier to develop new tools (outside DS).

The functions are desgined to be called without knowledge of the stream contents. These librariese will provide the following functions:

For Splitting:
- translate page granulespos to a reference time (100ns units)
- translate packet granulepos to a reference time (100ns units)

For Multiplexing:
- translate reference time to packet granulepos

For Decoding:
- deliver the header packets to the library
- return mediatype
- PacketIn
- BufferOut

For Encoding
- Return the header packets
- return the mediatype
- BuferIn
- PacketOut


I will give some more details in the next days.

Kind regards,
Tobias

[Mosu]

I still agree that your proposition looks better than the current implementation. I'll follow your lead as soon as you've got something working with the new scheme. If you want to change the identifier to 'videoV2' or whatever then by all means do so :)

[Suiryc]

Originally posted by TobiasWaldvogel
I.e. a subtitle which starts at 00:00:01.000 and ends at 00:00:02.799 would have granulepos 2s + 799ms + 1 (because we start 0) = 2800 and with length (inside the packet) set to 1800

(I hope my math skills aren't too bad now :/)
If the subtitle end @ 2s799, there have been 2799 ms (samples) till the beginning (0->1, 1->2, ..., 2798->2799). This mean the granulepos of the last sample is 2798 (ms).
So if we start counting granulepos from 0, then we should set the Packet's granulepos to 2798, and if we start counting granulepos from 1 then it is 2799 (which correspond to the Xiph's documentation : granulepos = total samples encoded and fully decodable).

Maybe you made a shortcut and your "ends at 00:00:02.799" meant "last sample of the subtitle starts @ 00:00:02.799", or maybe I should go back to school and learn some math again (:p).

[TobiasWaldvogel]

Originally posted by Suiryc


(I hope my math skills aren't too bad now :/)
If the subtitle end @ 2s799, there have been 2799 ms (samples) till the beginning (0->1, 1->2, ..., 2798->2799). This mean the granulepos of the last sample is 2798 (ms).

Maybe it was not quite clear. I meant the last time unit (sample) when the subtitle is displayed is 00:00:02.799, which means that 00:00:02.799 is included.

Kind regards,
Tobias

[Suiryc]

Question concerning data included in the stream_header structure.
Here is what I "think" :

- time_unit is the unit time expressed in a 100ns time reference
(100ns is the reference time for Windows' DirectShow)
So the real time unit is time_unit / 10000000
- samples_per_unit is the number of samples per unit of time
So the number of samples per second is :
samples_per_second = samples_per_unit / (time_unit / 10000000)

samples_per_second 10000000
Or : -------------------- = -----------
samples_per_unit time_unit


The applications are :
- for a video stream there is only 1 sample per unit, so samples_per_second = fps = 10000000 / time_unit
- for an audio stream the unit is 1s, so time_unit = 10000000 and samples_per_unit = samples_per_second
- for a text stream, the unit is 1ms, so time_unit = 10000. As one sample lasts 1ms, samples_per_second = 1000 => samples_per_unit = 1

This made me think about this formula (I put it in my sources) :

granulepos = sample number (since the beginning) (if start @ 1)
1000000 : to get microseconds from seconds
10000000 : reference of the time_unit (100 ns)
So samples_per_unit * (10000000 / time_unit) = samples_per_second
And then timestamp (in s) = (granulepos-1) / samples_per_second
Or timestamp (in micros) = 1000000 * (granulepos-1) / samples_per_unit
This give : (sh is the stream_header)

(granulepos-1) * 1000000 * sh.time_unit
timestamp = ----------------------------------------- micros
10000000 * sh.samples_per_unit

which can be simplified by :

(granulepos-1) * sh.time_unit
timestamp = -------------------------------- micros
10 * sh.samples_per_unit


So the question (for 1M bucks ;) ) : is this good (or at least not too bad)?
If yes, does the precedent applications (for video, audio and text) are the unique ones (i.e. we cannot use other values)?

Thanks

[Suiryc]

Originally posted by Suiryc
Maybe you made a shortcut and your "ends at 00:00:02.799" meant "last sample of the subtitle starts @ 00:00:02.799", or maybe I should go back to school and learn some math again (:p).
Originally posted by TobiasWaldvogel
Maybe it was not quite clear. I meant the last time unit (sample) when the subtitle is displayed is 00:00:02.799, which means that 00:00:02.799 is included

:)

[TobiasWaldvogel]

The formula for the current timestamps (from the packets) is just

granulepos * sh.time_unit
timestamp = -------------------------------- micros
10 * sh.samples_per_unit


In future it will be


(granulepos-packet_len) * sh.time_unit
timestamp = -------------------------------- micros
10 * sh.samples_per_unit


where packetlen is in samples


// Returns the length of a packet in media time (not for vorbis packets)
extern ogg_int32_t stream_packet_len(stream_header* sh,
ogg_packet* op)
{
if (op->packet[0] & PACKET_TYPE_HEADER) return E_NOTDATA;

ogg_int16_t lenbytes;

lenbytes = (*op->packet & PACKET_LEN_BITS01)>>6;
lenbytes |= (*op->packet & PACKET_LEN_BITS2) <<1;

if (lenbytes == 0) return sh->default_len;

ogg_int32_t len = 0;
while (lenbytes)
{
(len) <<= 8;
(len) |= op->packet[lenbytes];
lenbytes--;
}
return len;
}


Kind regards,
Tobias

[Koepi]

Uh, nice to see that the development is going on again!

While you're at timestamps/granulepos here, is it possible to get a more keyframe accurate jump/cut behaviour implemented?

My idea was to fetch an avi-parser like from mplayer or from aviplay and allow the oggmuxer DSF to directly open an avi file... is that possible/desireable?

Regards,
Koepi

[Suiryc]

Originally posted by TobiasWaldvogel

(granulepos-packet_len) * sh.time_unit
timestamp = -------------------------------- micros
10 * sh.samples_per_unit


where packetlen is in samples

This is the beginning time of the Packet. (the formula I posted was a general one i.e. I was getting the timestamp of sample at position granulepos, and not directly the beginning timestamp of a Packet).
This is what I presently use - in another way - for sorting Pages before writing them to file.

[Suiryc]

@Koepi & Tobias

Well I saw that some guys are trying to activate the delay feature in OggMux using TimeLine objects.
I have restricted knowledge in DShow, but I think that maybe there is another thing to do : add a delay possibility directly within OggDS (if possible of course).
Why ? Because I once tried to manually insert delay with my muxer (i.e. I "delayed" the granulepos of the data Packets), and the result was not so good :
For small delays this seem to work but I am not sure the real delay in audio is the one I wanted.
For big delays (for example 2s) the clip doesn't start by itself and I have to seek a little in the clip.

So with my restricted knowledge I think that the problem may be (unless I did something wrong of course ;)) :
the audio decoder after OggDS expect data since the very beginning, and if OggDS doesn't feed it (or tell it to wait a certain time) it gets angry.

Maybe Tobias can enlighten us here : do you think that just delaying the granulepos - manually in my muxer or using TimeLine objects in OggMux - is OK ?

[alky]

just a note: you can remove the mux/demux from the context using the filetypes-properties of the windows explorer

[joerg]

Originally posted by Suiryc
Happy to see the tools seem to work :)
Just a stupid question here : you tried the splitting on a file larger than 650MB or 700MB (the two splitting options that are in eclipsedvd enhancement) ?

Yes, it's 1,35 GB in size.


Because I know only 3 ways my splitter stop at the beginning :
1. your ogm is corrupt or something like that (I hope it's not the case ;)

As the splitter worked from the commandline, I'd say that cannot be the reason.

2. the splitting size is too small (i.e. my splitter was unable to cut the file because the size of a part would exceed what you wanted - unlikely to happen except if you precised a really realy small split size, or if there are only one key-frame in your clip, or if there is a bug in my tool ;) ) ... well even for that my splitter first analyse the file so the window should have lasted more time

As I tried to use the "split @ 700MB" - so that's unlikely, isn't it?

3. the size of the file already exceeds the splitting size you precised

The filesize is large enough (see above).

4. oh there is fourth one : my tool is buggy (very unlikely to happen ;) )

Unlikely as it works from the commandline.
So are there more options? btw: I'm using Windows XP SP1 if that matters.

If you still want to remove those extensions here is what you can do :

Thanks for the info. I do not want to remove the extensions, but unless I can get them to work for me, they are of no use for me.
Is there a possibility to keep the Window open so I can read the message, which probably shows up in there?

[joerg]

eclipsedvd and Suiryc: I just found and fixed the problem with the shell extensions. The %1 in the commandline, which gets replaced by the filename was not enclosed in "" - and because my filename had spaces in it, it wouldn't work. Now, after fixing this, everything works fine for me :)

[Bluedan]

Ahem, back to present.
Suiryc, I tested your tool and it worked fluently. Great!
Nevertheless, I have a suggestion: Could you implement a function to just restrict one part to the desired size? Yesterday I had the case that your tool cut my ~1.35GB stream with size preset 700MB into 3 pieces with the last one being 1,3MB. I think in most cases people want to cut for 2CDs, so if one is slightly oversized... most recorders can overburn nowadays. Still it takes some time to process such a stream again.
I admit that it is in addition a personal problem but my DVD-Rom, preferably as "first drive", is unable to read overburned CD, though it's quality fabrique Pioneer DVD-116, while my Lite-on recorder is able to. So in my "personal" case one (normally the first) CD mustfit the size.
I hate to ask for such things like: "hey mastermind, can you put together a personal solution for me, which is totally useless to other people except myself?"
But rethinking, I find that with the very tight and exact file size prediction of todays codecs in use (XVID, DIVX, RM9 what else?) there's little chance that the second part will surpass a plus of 10 MB if cut size preset is set to 700-702MB? What do you think ?

So far there is no tool to join OGM steams, right?

[Mosu]

My Linux tools implement a '-n' switch that tells ogmsplit how many files it should create at most - even if the last one is bigger than the intended size. This is rather trivial to implement so I'd think suiryc will do that. This is a feature that greatly eases the splitting in a lot of cases - simply split at 700 and go for 2 files max. Several people are very happy with this feature, so it won't be useless :)

[Mosu]

Oh btw, Tobias - I hope you don't take too long with your new version. I'm eager to adjust my tools :)

[Suiryc]

Originally posted by Bluedan
Suiryc, I tested your tool and it worked fluently. Great!
:)

Yesterday I had the case that your tool cut my ~1.35GB stream with size preset 700MB into 3 pieces with the last one being 1,3MB.
You could have also tried with 702MB as plit size (using the commandline) ;)
but ...
My Linux tools implement a '-n' switch that tells ogmsplit how many files it should create at most - even if the last one is bigger than the intended size. This is rather trivial to implement so I'd think suiryc will do that. This is a feature that greatly eases the splitting in a lot of cases - simply split at 700 and go for 2 files max. Several people are very happy with this feature, so it won't be useless :)
I will do that too :)

I hate to ask for such things like: "hey mastermind, can you put together a personal solution for me, which is totally useless to other people except myself?"
Mastermind? Who is that guy? ;)
No problem here. You know sometimes you think that what you want is totally useless for other people but it's generally not the case (at least I am sure that other people would like a workaround here).

So far there is no tool to join OGM steams, right?
Nope. (AFAIK)
I could give this a try, but with the options I added in my splitter (concerning chapters) I will have a lot of things to verify before the merged file looks like the original one (or at least is not too far) ;)

[Suiryc]

Originally posted by joerg
eclipsedvd and Suiryc: I just found and fixed the problem with the shell extensions. The %1 in the commandline, which gets replaced by the filename was not enclosed in "" - and because my filename had spaces in it, it wouldn't work. Now, after fixing this, everything works fine for me :)
Allways something we don't think at first :devil:

[MaTTeR]

Seems to work great for splitting and info. Great work!

Any chance of a GUI or did I miss the link somewhere in this thread?

[Suiryc]

No GUI for the moment.
If anyone want to do one, feel free to do so ;)

[Suiryc]

@ those who use my tools
Could you confirm you have absolutely no problem of desynchronized audio/video after muxing or splitting (nor at the beginning of the file nor at the end).
(my tools still needs test before we can say they work fine ;), especially with multichannels audio streams)

[Mosu]

Toabis, just to make sure. Please use 'videoV2', 'audioV2' and 'testV2' as the new streamtypes - or something like that. Don't reuse any existing tag as this will make playing older files that much harder. I'm pretty sure that you'd do that anyway, but if we change it we better change it in a way that won't introduce new problems.

[Suiryc]

The -n feature have been added.
I updated the Cutter and the Muxer regarding a little bug that could have caused problems with multichannels Vorbis streams.

Enjoy.

@Tobias
Does your cutter follow the Vorbis' team advice, i.e. that when cutting a vorbis stream the two last packets of a part should be duplicated as the two first ones in the next part (due to the "overlapping nature of vorbis")?
And do you think that every cutter should strictly follow this path (presently I just cut the stream where I need and do not report the two last packets)?

[alky]

i made a very small gui for the demuxer and cutter using Perl/Tk it should work on every win32 system after installing active perl fom http://www.activestate.com/Products/ActivePerl

you can grab the 2kb zip file here: http://members.chello.at/demmer

[MaTTeR]

@alky

Thanks for the GUI effort. Seems to work just fine with WinXP.

[Bluedan]

Cannot d/l gui from your site ATM !

[alky]

Bluedan: why not?

anyway copied it to a 2nd server...

[Bluedan]

Not sure why. Makes no difference if opera or IE, Tiny Firewall enabled or disabled...
Would you PM me, because it's sunday ??

[Bluedan]

OK. Success. 'Mirror' link does it. First one still don't.

[Bluedan]

Maybe I found a bug so far.
I demand somebody to confirm that:
2nd split ogm (XVid + 2x OggVorbis) with ~700MB (~1.35GB in total) in size has a slight synch problem towards the end. Sound is late for a quarter second, so already noticable. I used builds 0.9a3 for that splitting task.
Will check if it's not decoding related on my Intel 667MHz CPU (probably not...) concerning filter chain.

[Sigmatador]

You can:
-Demux
-Split at 700
-Split at 650
with a right click

http://www.eclipsedvd.firstream.net/FILES/OGMTools_20020912.exe

[Dark-Cracker]

Hi,

just a little comment. i think in the final release of your tool u need merge the muxer and the splitter and add the possibility to mux & split on the fly (exemple : mux the avi and the 2 ogg file and split at the same time after the desired size, not first mux and after split, this will be great for the little harddisk and avoid a lot of tempory file) i hope this feature was not to hard to add.

and a silly question how react your muxer if the audio lenght was not the same than the video lenght ? (with one or 2 audio file) does it stop the video at the same audio lenght ? or does it stretch the audio stream ? or it use the video lenght ?

Thank u, very nice work.
continu comme ca :)

sorry for my bad english.

[Suiryc]

Originally posted by Bluedan
Maybe I found a bug so far.
I demand somebody to confirm that:
2nd split ogm (XVid + 2x OggVorbis) with ~700MB (~1.35GB in total) in size has a slight synch problem towards the end. Sound is late for a quarter second, so already noticable. I used builds 0.9a3 for that splitting task.
Will check if it's not decoding related on my Intel 667MHz CPU (probably not...) concerning filter chain.
Synch problem on one stream or both?
And there are no synch problem at the beginning (in the first minutes)?
Are those (or one of those) streams 5.1? If yes could you also try the 0.9a4 version (maybe this won't change anything but who knows).

[Suiryc]

Originally posted by Dark-Cracker
Hi,

just a little comment. i think in the final release of your tool u need merge the muxer and the splitter and add the possibility to mux & split on the fly (exemple : mux the avi and the 2 ogg file and split at the same time after the desired size, not first mux and after split, this will be great for the little harddisk and avoid a lot of tempory file) i hope this feature was not to hard to add.
Unfortunately this was not so easy to make the splitter.
I have to admit that Ogg Media file structure is great but very hard to use for precise editing (unlikely to AVI there are no kind of index at the beginning of the file telling what are the data in the file and where are those data). Thus for a precise cutting I have to parse a first time the whole file to know what I need about the video stream (framerate, where are the keyframes, an approximation of how many bytes will do the part if I cut on this keyframe, ...).
When I have those information, I can then reparse the file and cut where this is needed (and I am 99.99% sure that the filesizes won't exceed the split size).
This mean that for merging the muxer and the splitter I would need to make something similar, except that I don't have only one file as input but many files, which is of course harder :(
Anyway as you could see I think that the way I made the Splitter is the maximum one can do, and is really too much to implement in the muxer ;)
Another solution would be to pay less attention to the filesize, and just follow the video stream : when I find a keyframe and the filesize is bigger than the split size, then cut, but in this case you could end with filesize bigger (maybe much bigger if there was a keyframe just before and the next one is far away) than the split size.
Then there is the third solution (the one I prefer, but had not enough time for the moment to do so) : mix the 2 precedent solutions, i.e. just parse the video stream and store where are the keyframes, then reparse all input files and cut where I think this is the best (according to where are the keyframes and an estimation of how many bytes would represent to go till the next keyframe).

So there is still work to do ;)

and a silly question how react your muxer if the audio lenght was not the same than the video lenght ? (with one or 2 audio file) does it stop the video at the same audio lenght ? or does it stretch the audio stream ? or it use the video lenght ?
Simple answer : my muxer follow the longest stream.
So if your video is longer, then at the end you have video with no sound, and if the audio is longer it is (should be, I never tested) the contrary.

So I see coming a next request here : "add an option to end other streams when video finish" ... ;)

Thank u, very nice work.
continu comme ca :)
"Merci"

sorry for my bad english.
Not as bad as mine ;)

[Dark-Cracker]

hi,

>Another solution would be to pay less attention to the filesize, and >just follow the video stream : when I find a keyframe and the >filesize is bigger than the split size, then cut, but in this case >you could end with filesize bigger (maybe much bigger if there was a >keyframe just before and the next one is far away) than the split >size.

thank u very much for your quick answer :) for muxing the joiner and the splitter , i was thinking it was hard :) but i think to splipt after the next keyframe once u have past the desired filesize is a good solution i think u could obtain at more 2 mo and if you try to find the desired less 1 or 2 Mo u could find the keyframe just before the desired filesize. but u have a still a lot of work i suppose this feature will be added in the final release :) (i hope)

if u are interested u can perhaps ask to koepi or cyberdemonII some informations because the have already solve this matter with the muxer & joiner.

>So I see coming a next request here : "add an option to end other >streams when video finish" ...

hum u read in my minds :)

good luck for your next release.
Bye.

[DaveEL]

Originally posted by Suiryc

Another solution would be to pay less attention to the filesize, and just follow the video stream : when I find a keyframe and the filesize is bigger than the split size, then cut, but in this case you could end with filesize bigger (maybe much bigger if there was a keyframe just before and the next one is far away) than the split size.


How about

Read frames in to a buffer untill you reach a keyframe, if size of outputfile + buffer size is over split size start a new file and output the buffer to the new file or if its under the split size add frames in the buffer to the current output file. Then start reading frames in to the buffer again.

DaveEL

[Suiryc]

Originally posted by DaveEL
How about

Read frames in to a buffer untill you reach a keyframe, if size of outputfile + buffer size is over split size start a new file and output the buffer to the new file or if its under the split size add frames in the buffer to the current output file. Then start reading frames in to the buffer again.

DaveEL
Easier to say than to do ;)

Here is the whole problem : I want to cut very precisely.
Presently for writing the OGM file here is what I do :
- I read data from each input file (frame per frame)
- I construct a Packet for each frame, specifying what is necessary (position)
- I give the Packet to the Ogg layer, which in return give me (when it has enough data) a Page (that contains 1 or more Packets)

I read data coming from input files as they arrive, and the Ogg Layer returns pages when they are full.
So it is possible that, at one point, I read the (key) frame of the video stream that correspond to time 1'20"000, and then the data coming from a Vorbis stream that correspond to time 1'20"500, ...
The filesize is still good, so I continue. I give the data to the Ogg layer, which returns Pages etc etc...
It is possible that in the buffer I get this (and this is a really simple case here, believe me ;)) :
"
...
Page of Vorbis stream :
- Packet 1 -> time 1'19"980
- ...
- Packet 20 -> time 1'20"500
Page of video stream
- Packet 1 -> time 1'20"000 (keyframe)
Page of Vorbis stream :
- Packet 1 -> time 1'20"520
...
"
Because the Packet coming from Vorbis stream at time 1'20'500 is included in a Page that starts @ 1'19"980 (so before the video frame 1'20"000).

So I continue till the next keyframe. This one is beyond the split size, so it is time to cut. I put the data in the buffer, and the last keyframe was @ 1'20"000. So I should cut just before the Page containing the Packet corresponding to that frame (the one in red).

I thus close the current output file, open the next file, flush the buffer and continue ...
So I will have this in the beginning of the next file :
"
Page of video stream :
- Packet 1 -> time 1'20"000 (reseted to 0'0"000)
Page of Vorbis stream :
- Packet 1 -> time 1'20"520 (reseted to 0'0"520)
"
The problem for me : the first 520ms of the vorbis stream are in the previous file.
Well, but 520ms is not that much, so if it is the cost for having a good cut, why not ... (I am joking here ;))
But I have another problem : in tests I made, if the first data coming from a stream are too far away, then the clip is frozen at the beginning and I have to seek :(

But this was a simple case, because generally what you have is this :
"
Page of video stream
- Packet 1 -> time ... (delta)
- Packet 2 -> time ... (delta)
- Packet 3 -> time ... (delta)
- first part / 2 of Packet
Page of video stream
- second part / 2 of Packet -> time ... (key-frame)
Page of video stream
- Packet 1 -> time ... (delta)
- Packet 2 -> time ... (key)
...
"
And the problems are also here :
1. For knowing all that I have to parse again the Page the Ogg layer gave me (to know what is inside)
2. If I have to cut just before the red frame, how do I do ? (this frame is in the middle of a Page, so I have to "undo" the Page, and take the good packets etc etc ... but hey remember it's a buffer which is already written and I am trying to change a lot of thing here :()
3. There is another thing that I forgot to mention : each Page contains it's position in the stream (page number, and granular position). But what is in my buffer is already set according to the current output file (page number=150, granularpos=... <=> time=1'20"00), and I cannot use it like that for the next output file (I must reset time to 0, and page number too).

And there could be other problems I forgot to mention :(

Pheew. Hey I wasn't kidding when saying that using Ogg Media File for precise editing wasn't that easy ;)

[Bluedan]

@suiryc
ad 1)
Well, frankly I didn't test the second audio, but so far I suppose it's the same because they are both identical in format and length: english and german soundtrack, OggVorbis 2ch stereo.

ad 2)
Yes: synch in the beginning while off-synch at the end. With the audio being late only at the end an artificial 'offset' introduced since the cutting point is unlikely because it's static.
I doubt that the problem is clearly due to your programme. If it inserts some 'space' frames accidently during parsing the whole file (as you described above) then why the first part is synch?
BTW, I tested the stream before cutting and it was totally synch.
There's some chance that I have an issue with my drives/aspi/dma system instead, which is good for you.
-> OT: Did you ever have a DVD-Rom stepping back to PIO-mode suddenly and refusing to be switched back to DMA (MB-BIOS set to DMA of course)??

Sorry that this post will be unsatisfying as I currently don't have the CDs at hand - lend them to a friend, stupid - to copy the parts again to HD.
But I will report soon.
Thanks for your patience.

[Suiryc]

Originally posted by Bluedan
Yes: synch in the beginning while off-synch at the end. With the audio being late only at the end an artificial 'offset' introduced since the cutting point is unlikely because it's static.
I really hope this is not due to my program (because in this case I have no idea what could have caused that, at least for the moment).

I doubt that the problem is clearly due to your programme. If it inserts some 'space' frames accidently during parsing the whole file (as you described above) then why the first part is synch?
Theorically my program won't cause troubles for the first part, but for the next ones it's another thing ;)

BTW, I tested the stream before cutting and it was totally synch.
There's some chance that I have an issue with my drives/aspi/dma system instead, which is good for you.
:)
Also sometimes DirectShow seems to behave strangely.
I have sometimes desynch of about +/-60ms with a clip, but if I stop the clip, and then play it again the desynch returns to +/-1ms :/ (it's my favorite test clip : 1'40", 25fps, set to about 1400kbps if I remember well, 1 AC3 2ch 192kbps track, 1 Ogg 2ch track, 1 subtitle track ; the desynch is on the AC3 track according to DirectShow).
And sometimes when seeking desynch appears and after waiting a little this is resynched :/

-> OT: Did you ever have a DVD-Rom stepping back to PIO-mode suddenly and refusing to be switched back to DMA (MB-BIOS set to DMA of course)??
OT : Nope. But I had (with Win2000) the surprise to see that after installing some drivers Windows though all my devices (Hard-disks, CD-Rewriter, DVD-Rom) were SCSI ones (which made disk access really slower and no possibility to burn CD-Roms :( because of course my devices are not SCSI ).

Sorry that this post will be unsatisfying as I currently don't have the CDs at hand - lend them to a friend, stupid - to copy the parts again to HD.
But I will report soon.
Thanks for your patience.
No problem here.
If the problem remains here is what you can do for me (if possible) :
Use "OGMInfo -v3 -l <log_file> ..." on your clips (the original one and the two parts), and send me (Zipped of course, and if don't exceed 5-6MB) (suiryc AT yahoo DOT com) those parts :
- First and last 1000 lines of log file for each part (the two cut files)
- First and last 1000 lines + 2000 lines around where it was cut of the log file of the orignal clip

To know where it was cut :
- Open the log file of the first cut file
- go to the end
- Search the lasts Page numbers of the video stream (should be like "... 1V Page # ...."
- Open the log file of the original clip
- Go to the same Page numbers of the video stream (should be around the middle of your log file), and keep the 1000 lines before and 1000 lines after where you are (plus the first and last 1000 lines of the file).

This will help me knowing if the desynch is really due to my program or if it doesn't appear to be any desynch in the file (at least in term of structure).

Thanks :)

Originally posted by Dark-Cracker
if u are interested u can perhaps ask to koepi or cyberdemonII some informations because the have already solve this matter with the muxer & joiner.
You are talking of OggMux ?
If yes, then there are few chances this will help me because OggMux rely on DirectShow/OggDS.
So OggMux constructs the graph, say when to start, when to end, retrieve some information on the graph (to know where to cut, ...), etc etc ... , and DirectShow "follow" (it seems sometimes DirectShow is stubborn ;)) its orders.
(Nb : this is more easy to say than to do, you can believe me because I already worked a "little" with DirectShow ;))
On the contrary I have to do the job of DirectShow/OggDS concerning parsing of the input files and muxing the streams, and I surely do it differently (I take data as they arrive from the input files and synchronize streams before writing, while DirectShow synchronize the streams before sending them in the graph).
This make easier for OggMux to have synchronized streams in the output files, while I have to take care of this point myself in my tools.

Anyway thanks for the tip :)

[Emp3r0r]

-> OT: Did you ever have a DVD-Rom stepping back to PIO-mode suddenly and refusing to be switched back to DMA (MB-BIOS set to DMA of course)?? I've have this problem but I got a new DVD drive today. I'm hoping to see up to 7X like I saw on this XEON machine with a SCSI hard drive, but I doubt it.

BACK ON TOPIC: Can you add an option to verify that ogmuxer can use an input file. "ogmuxer -v test.ac3" returns true if it is a valid file ogmuxer can handle, thanks

[Suiryc]

No problem, will do that :)
Wait for the next version (will come with a merger that already works ... at least I could merge what I split with OGMCutter ;)).

[AmiRage]

I just tried OGMuxer 0.9a4, but strangely it failed to identify the AVI containing an XviD video stream (no audio) created with VirtualDub. So I used OggMux 0.9.2 to mux this XviD video stream, two OGG audio streams, two subtitles and the chapters into one 1.4 GB great OGM file.

Then I used OGMCutter 0.9a4 to cut this one into two parts (option -c 3). OGMCutter told me about a last, third part of about 4 MB, ...

Cut point @ Packet 101107 ( 697.95MB) : part size = 697.95MB
Cut point @ Packet 201340 (1395.67MB) : part size = 697.72MB
Last part size = 4.03MB

... but the last (small) part was never created?! Intended?

Then I used a slightly higher value for the MBs:

Cut point @ Packet 101486 ( 699.82MB) : part size = 699.82MB
Last part size = 699.88MB

Result: A perfectly cut OGM, which so far seems to work perfect. Sync audio and subtitles. But I'll have a closer look at it comparing the big and the smaller files. (Update: One chapter is too late after splitting.)

Now I wanted to cut down the second part into pieces of about 15 MB to get a sample of the movie including audio tracks, subtitles and chapters, but OGMCutter failed. The processing and parts calculating works, but after creating one or two of the parts OGMCutter only eats all CPU time but never finishes further parts?! (Update: When using 50 MB as split size it stops after 5 parts ... using 75 MB it at least worked. Strange!)

Any idea?

Thanks in advance. ... and thanks for the tools!

Update: After several steps of further down-cutting the subtitles seem to be me missing in one of the parts although they're still shown in the menu. And again one of the last parts wasn't created.

[bb]

Originally posted by Emp3r0r
I've have this problem but I got a new DVD drive today. I'm hoping to see up to 7X like I saw on this XEON machine with a SCSI hard drive, but I doubt it.
My DVD drive always fell back to PIO mode, but after I switched the master/slave status of my DVD ROM and my CD burner, I got both back to DMA modes.

BTW: the 7x speed has nothing to do with your HDD speed.

bb

[Bluedan]

@Suiryc
Still waiting for my CD 'test files' to return....

@BB
Which order precisely? DVD ->slave + burner ->master ?
The other way round it's mostly advised though I don't know the reason for it's obviously more important that both devices can achieve the same speed class/ same transfer protocol (PIO or DMA). Nevertheless Windows XP dares indicating different protocols for devices on the same IDE channel, which shouldn't be possible AFAIK....

[bb]

@Bluedan:
DVD ROM Slave, CD-RW burner Master: didn't work
DVD ROM Master, CD-RW burner Slave: worked

bb

[Suiryc]

Originally posted by AmiRage
I just tried OGMuxer 0.9a4, but strangely it failed to identify the AVI containing an XviD video stream (no audio) created with VirtualDub. So I used OggMux 0.9.2 to mux this XviD video stream, two OGG audio streams, two subtitles and the chapters into one 1.4 GB great OGM file.
Is there an error giving some precisions about where and why it failed ? (or did it only said this wasn't a known type ?)

... but the last (small) part was never created?! Intended?
No the last part should also be here :/
Will do some tests.

Update: One chapter is too late after splitting.
What was the original time of this chapter, and what is the delay after cutting ? (was this chapter near the end or the beginnig of the part ?)

Now I wanted to cut down the second part into pieces of about 15 MB ...
Will do some tests too :)

Update: After several steps of further down-cutting the subtitles seem to be me missing in one of the parts although they're still shown in the menu. And again one of the last parts wasn't created.
Well it seems that "some" bugs remain in this cutter :p

[AmiRage]

Originally posted by Suiryc
Is there an error giving some precisions about where and why it failed ? (or did it only said this wasn't a known type ?)

Error in AVIReader::init_streams (AVIReader.cpp) @ 128 : Unknown information format in AVI source file D:\...
Error in AVIReader::init_streams (AVIReader.cpp) @ 129 : Process aborted due to previous error

Originally posted by Suiryc
What was the original time of this chapter, and what is the delay after cutting ? (was this chapter near the end or the beginnig of the part ?)

Original chapters (total time 02:14:46):

CHAPTER01=00:00:00.000
CHAPTER01NAME=Chapter 1
CHAPTER02=00:01:15.200
CHAPTER02NAME=Chapter 2
CHAPTER03=00:11:17.040
CHAPTER03NAME=Chapter 3
CHAPTER04=00:14:52.080
CHAPTER04NAME=Chapter 4
CHAPTER05=00:27:12.440
CHAPTER05NAME=Chapter 5
CHAPTER06=00:36:29.920
CHAPTER06NAME=Chapter 6
CHAPTER07=00:47:47.520
CHAPTER07NAME=Chapter 7
CHAPTER08=00:59:24.560
CHAPTER08NAME=Chapter 8
CHAPTER09=01:17:24.240
CHAPTER09NAME=Chapter 9
CHAPTER10=01:28:26.560
CHAPTER10NAME=Chapter 10
CHAPTER11=01:40:02.240
CHAPTER11NAME=Chapter 11
CHAPTER12=01:51:16.120
CHAPTER12NAME=Chapter 12
CHAPTER13=02:02:07.240
CHAPTER13NAME=Chapter 13
CHAPTER14=02:12:07.200
CHAPTER14NAME=Chapter 14
CHAPTER15=02:13:13.520
CHAPTER15NAME=Chapter 15

Chapters after cutting (WMP 6.4 timing -> estimation only):

Part 1 (total time 01:07:39):

CHAPTER01=00:00:00.000 -> OK
CHAPTER01NAME=Chapter 1
CHAPTER02=00:01:15.200 -> OK
CHAPTER02NAME=Chapter 2
CHAPTER03=00:11:17.040 -> OK
CHAPTER03NAME=Chapter 3
CHAPTER04=00:14:52.080 -> OK
CHAPTER04NAME=Chapter 4
CHAPTER05=00:27:12.440 -> OK
CHAPTER05NAME=Chapter 5
CHAPTER06=00:36:29.920 -> OK
CHAPTER06NAME=Chapter 6
CHAPTER07=00:47:47.520 -> OK
CHAPTER07NAME=Chapter 7
CHAPTER08=00:59:24.560 -> OK
CHAPTER08NAME=Chapter 8

=> conclusion: although real entries not always identical to chapter file the result is the same comparing the complete ogm file and the first part of the cut one ... menu chapter info is identical.

Part 2 (total time 01:07:06):

CHAPTER09=01:17:24.240
-> OggMux-ed original entry at 01:17:33
-> OGMCutter entry at 00:09:45 (menu -> chapter info 00:09:44.880)
-> about 8 seconds before the original
CHAPTER09NAME=Chapter 9
CHAPTER10=01:28:26.560
-> OggMux-ed original entry at 01:28:26
-> OGMCutter entry at 00:20:59 (menu -> chapter info 00:20:47.200)
-> about 12 seconds behind the original
CHAPTER10NAME=Chapter 10
CHAPTER11=01:40:02.240
-> OggMux-ed original entry at 01:40:04
-> OGMCutter entry at 00:32:25 (menu -> chapter info 00:32:22.880)
-> OK
CHAPTER11NAME=Chapter 11
CHAPTER12=01:51:16.120
-> OggMux-ed original entry at 01:51:28
-> OGMCutter entry at 00:43:36 (menu -> chapter info 00:43:36.760)
-> about 10 seconds before the original
CHAPTER12NAME=Chapter 12
CHAPTER13=02:02:07.240
-> OggMux-ed original entry at 02:02:12
-> OGMCutter entry at 00:54:32 (menu -> chapter info 00:54:27.880)
-> OK
CHAPTER13NAME=Chapter 13
CHAPTER14=02:12:07.200
-> OggMux-ed original entry at 02:12:07
-> OGMCutter entry at 01:04:27 (menu -> chapter info 01:04:27.840)
-> OK
CHAPTER14NAME=Chapter 14
CHAPTER15=02:13:13.520
-> OggMux-ed original entry at 02:13:25
-> OGMCutter entry at 01:05:46 (menu -> chapter info 01:05:34.160)
-> OK
CHAPTER15NAME=Chapter 15

Now I'm really confused. The timing calculations seem to be ok, but why am I getting this large differences in entry??

Update: Hmmm ... I believe there's a problem with OggMux 0.9.2?!?! ... not with OGMCutter. It seems that OGMCutter even corrects the errors.

Update 2: I'm still totally confused.

[Manao]

Strange bug :

I only use ogmcutter, since I mux audio, video, subtitles and chapters with oggmux.

It works flawlessly, except for one encode ( 1 video stream ( Xvid ), 2 audio stream ( ogg vorbis, different quality settings ), 2 subtitles, and chapters ). This one is cut, but not at the same point for video and audio. I used ogminfo on the resulting first part, it returned different duration for the different streams : 4 minute miss on the video stream, audio ( vorbis streams ) duration are almost the same, subtitles a little shorter ( but I think it's normal, since there is no subtitles at the moment of cutting ). The second part is alright ( at least it seems ).

I tried to change the cutting frame, the same problem occured.

My system : Win XP, oggdsf 0.9.9.3, oggsubtitle dsf 1.3.3.0
Command line : ogmcutter -c 7 -s 717000K -n 2 "video.ogm"

If you want more details, I still have the files, so ask and I will attach any further information needed.


Otherwise, ogmcutter is great and _really_ helpfull.

[Suiryc]

Originally posted by AmiRage
Error in AVIReader::init_streams (AVIReader.cpp) @ 128 : Unknown information format in AVI source file D:\...
Hmm, this error means that information about the video stream are not in a BITMAPINFOHEADER structure :/. Do you used special options for making the video (in VirtualDub or in XviD) ?

Original chapters (total time 02:14:46):
CHAPTER01=00:00:00.000
CHAPTER01NAME=Chapter 1
CHAPTER02=00:01:15.200
CHAPTER02NAME=Chapter 2
...
CHAPTER09=01:17:24.240
CHAPTER09NAME=Chapter 9
CHAPTER10=01:28:26.560
CHAPTER10NAME=Chapter 10
...

Chapters after cutting (WMP 6.4 timing -> estimation only):
Part 1 (total time 01:07:39):
...
Part 2 (total time 01:07:06):
CHAPTER09=01:17:24.240
-> OggMux-ed original entry at 01:17:33
-> OGMCutter entry at 00:09:45 (menu -> chapter info 00:09:44.880)
-> about 8 seconds before the original
CHAPTER09NAME=Chapter 9
CHAPTER10=01:28:26.560
-> OggMux-ed original entry at 01:28:26
-> OGMCutter entry at 00:20:59 (menu -> chapter info 00:20:47.200)
-> about 12 seconds behind the original
CHAPTER10NAME=Chapter 10

OK if those times are OK, this mean :
Chapter 09 @ 00:09:45 in second part, first part = 01:07:39 => Chapter 09 should be @ 01:17:24 in the original file (01:17:24.240 in reality : OK).
Chapter 10 @ 00:20:59 in second part, first part = 01:07:39 => Chapter 10 should have been @ 01:28:38 in the original file (01:28:26.560 in reality : 12s delay).
But I wonder : you say entry @ 00:20:59 and menu -> chapter info = 00:20:47.200 :confused:. If the menu->chapter info is what you have in your player then why OGMCutter entry @ 00:20:59 ? (maybe you wrote too fast), because with 00:20:47 then Chapter 10 should have been @ 01:28:26 (01:28:26.560 in reality : OK) ...

Update 2: I'm still totally confused.
Me too :p
Where do you took the first times (for all chapters) ? From the txt file, from OGMInfo or from OggMux ?


BTW I wasn't able to reproduct any of your bugs (nor the last part not written, nor the process not finishing while cutting in small pieces, nor the subtitles missing in some parts, nor the problem with chapters).
I tried on a 250MB and a 495MB file, cutting in 100*3MB, 50*10MB and 245MB+245MB+5MB. Well maybe I changed something (but I don't remember doing so) that could have solved such problems in the version I have :confused:
Are those problems specific to you or are there other persons experiencing such things ?

Just a question (maybe this is not related at all, but who knows) : what version of the vorbis dlls (if you installed those yourself) or OggDS (that install the previous dlls) were you using ?

PS : for the subtitles there is only one thing I didn't tested at the moment, this is what happens if my cutting point correspond exactly to the end or the beginning of a subtitle ... (well now that I think about it, in theory if this correspond exactly to the beginning of a subtitle, then this subtitle will surely be "skipped" by the Subtitler Mixer - seems that if a subtitle starts @ 0 in the file it is not shown, or at least not each time you play the file - ).

@Manao
Normally the text stream is cut so that it lasts as long as the video stream. But maybe OGMInfo showed wrong durations ...
You say that according to OGMInfo the video lasts 4 minutes less than the other streams (BTW for the text stream you wanted to say "a little shorter than the audio streams" or "than the video stream"?). Is this true when playing in your favorite player ? (i.e. does the last 4 minutes of video in the first part really lacks ?)
Could you do the same I asked to Bluedan ? (make logfiles and keep first and last 1000 lines of each file, plus the 2000 lines around where it was cut in the logfile of the original file)
If Zipped files are not too big (6MB) you can send here : suiryc AT yahoo DOT com.
Thanks :)

[Manao]

For the subtitle streams, they are a little shorter than the vorbis streams. The video won't play video further than the end of the video stream announced by OGMInfo, but I can still hear the sound track and view the subtitles.

For the second part, I was wrong, it doesn't play right. Seems that the video is in the second part, which makes a 4 minutes delay for the audio. Of course, at the end of the second part, I hear nothing. The 'good' news is that the subtitles are still in synch with the audio in the second part.

I will mail you the log, as soon as I succeed in cutting the requested parts ( 200 Mo, it takes a long time to edit )

[AmiRage]

Originally posted by Suiryc
Hmm, this error means that information about the video stream are not in a BITMAPINFOHEADER structure :/. Do you used special options for making the video (in VirtualDub or in XviD) ?I didn't set anything special. Not that I know.

OK if those times are OK, this mean :
Chapter 09 @ 00:09:45 in second part, first part = 01:07:39 => Chapter 09 should be @ 01:17:24 in the original file (01:17:24.240 in reality : OK).
Chapter 10 @ 00:20:59 in second part, first part = 01:07:39 => Chapter 10 should have been @ 01:28:38 in the original file (01:28:26.560 in reality : 12s delay).
But I wonder : you say entry @ 00:20:59 and menu -> chapter info = 00:20:47.200 :confused:. If the menu->chapter info is what you have in your player then why OGMCutter entry @ 00:20:59 ? (maybe you wrote too fast), because with 00:20:47 then Chapter 10 should have been @ 01:28:26 (01:28:26.560 in reality : OK) ...
00:20:59 is the time Windows Media Player 6.4 jumps in. Although in the menu a chapter entry of 00:20:47.200 is shown.
Where do you took the first times (for all chapters) ? From the txt file, from OGMInfo or from OggMux ?
Everything behind CHAPTER is from the original chapter-file used while muxing.

"OggMux-ed original entry at ..." is the time WMP (or ZoomPlayer or BSPlayer) jumps in the original uncut OggMux-ed OGM file when actually choosing this chapter in the player.

"OGMCutter entry at ..." is the time WMP (or ZoomPlayer or BSPlayer) jumps in the OGMCutter-cut second part of the file when actually choosing this chapter in the player.

"menu -> chapter info" is the info shown in the chapter menu of the player.

Just a question (maybe this is not related at all, but who knows) : what version of the vorbis dlls (if you installed those yourself) or OggDS (that install the previous dlls) were you using ?
I'm using OggDSF 0.9.9.3 and SubTitDS 1.3.0.0.

[Suiryc]

Originally posted by AmiRage
00:20:59 is the time Windows Media Player 6.4 jumps in. Although in the menu a chapter entry of 00:20:47.200 is shown.
Ah ah, maybe I found the problem here. OGMCutter set the chapter @ 00:20:47.200 (which is correct), but your player jumped to 00:20:59.
If you have the "seek on keyframe" checked in OggDS, this should mean the first keyframe after time 00:20:47.200 (time of the chapter) is at 00:20:59.
Now what I don't understand is why the behavior is not allways the same :
- for chapter 9, in the original file you arrive 8 seconds later, with OGMCutter you arrive at the good time
- for chapter 10, in the original file you arrive at the good time, but in OGMCutter you arrive 12 seconds later

The fact the player behave differently between the two files could mean (unless this is due to OggDS) that when cutting OGMCutter delayed the chapter times by a few frames (normally 1 should be the max, even if I think that 0 should be the reality ;) ).
For chapter 10 OGMCutter could have delayed this time so that it arrives a few frames after the real time (so if you have a keyframe just at this point in the original file, your jump is good, but this is not anymore the case with the cut part because then the chapter is set after this keyframe).
But for chapter 9 it seems to be the contrary :confused:

[AmiRage]

I think you're right with the keyframes.

These are the keyframes in the original AVI/XviD stream between chapter 9 and 10:

(1:28:14.560)
(1:28:26.560)
(1:28:38.560)
(1:28:46.320)

CHAPTER10=01:28:26.560

... so the chapter entry in the original OGM file is identical to the keyframe, but after cutting the next keyframe is used.

Don't know about the other differences so far, but will take a closer look at it.

[Suiryc]

Originally posted by AmiRage
I think you're right with the keyframes.

These are the keyframes in the original AVI/XviD stream between chapter 9 and 10:

(1:28:14.560)
(1:28:26.560)
(1:28:38.560)
(1:28:46.320)

CHAPTER10=01:28:26.560

... so the chapter entry in the original OGM file is identical to the keyframe, but after cutting the next keyframe is used.

Don't know about the other differences so far, but will take a closer look at it.
Oh yeah I forgot : to know more about your ogm files (where are the keyframes) you can use my modified version of VirtualDub.
So you can verify keyframes are at the same place in your original OGM file, and where they are in your cut files :)

[Suiryc]

Alright I maybe found what was the problem for Manao.
Anyway I found a bug in my sources (a damn integer variable that should have been floating-point one !!! stupid me :(), causing problems with times (delays in the cut parts other than the first one) if your video framerate is not an integer one (i.e. 25fps ... if your video is 23.976 or 29.... or anything that is not integer, like for Manao you must have experienced big troubles - few seconds up to several minutes of delay between video and other streams - with OGMCutter).

Maybe it is your case AmiRage.

Site updated

Thanks for your help :)

[AmiRage]

OGMCutter 0.9a5 still works well respectively the same way as the version before when cutting my 25fps OGM file. ;)

I just downloaded your OGM-VD version and will have a closer look at the keyframes.

[Suiryc]

@AmiRage
I finally found what was causing the last parts not being created.
Correcting that.

Also it seems that chapters are somehow delayed by 1 frame (searching what cause that and why).

My error, in my tests chapters are not delayed ...

[Suiryc]

I updated versions on the site.

Fixed some bugs and added some features (test file in the muxer, ...) in all tools (except the demuxer).

I put the merger I made. It should be able to merge streams you cut with OGMCutter.

I also updated the VirtualDub version. It should now be able to write (_only_) the video stream (coming from any kind of input file) into an OGM file. At least all options in VirtualDub are avaible on this video stream (compression, filters, subsets, framerate change, ...).

Enjoy :)

[Nightweaver]

Originally posted by Suiryc
Alright now you will find my tools here : http://cyrius.bunkus.org.

This site is up thanks to Mosu (Moritz Bunkus), so we should all thank him at least twice : first for developing ogmtools (on which I based my tools) and then for being kind enough to host my little tools :)

Thanks again Mosu :D

Regards.

Just a wee request ... can you possibly add that link to your sig suiryc? It'd make it a little easier to find for the lazy people like me ;)

[Emp3r0r]

bump, I second that

Also, how similar are the theora streams and ogm streams? Specifically, do the containers follow the same standards? (please excuse my ignorance)

(one more thing :D) Can you make ogmtools commandline work like "ogmuxer C:\matrix.omx" so that I can drag and drop a file on the exe? (sorry, I know I'm lazy ;) )

thanks

[Suiryc]

Originally posted by Emp3r0r
Also, how simular are the theora streams and ogm streams? Specifically, do the containers follow the same standards? (please excuse my ignorance)
As far as I could see theora presently rely on Xiph's Ogg specifications (as OGM does). Only headers changed (to simplify : it's like a new Vorbis stream).
(one more thing :D) Can you make ogmtools commandline work like "ogmuxer C:\matrix.omx" so that I can drag and drop a file on the exe? (sorry, I know I'm lazy ;) )

thanks
I don't know, I'm lazy too ;)

Originally posted by Nightweaver
Just a wee request ... can you possibly add that link to your sig suiryc? It'd make it a little easier to find for the lazy people like me ;)
It's now in my sig for you lazy people over there ;)
But you know there is also that little thing (like a button, with kind of home drawn on it) called "www" below all my posts ;)

[AmiRage]

So, here we go ... still a 25.000 fps video stream:

(1) VirtualDub 1.4.10 - XviD-video-only-AVI (202150 frames - 2:14:46.000)
(2) OGGMux 0.9.2 - complete OGM (202150 frames - 2:14:46.000)
(3) OGMCutter 0.9a5 - cut of the complete OGM (101484 frames - 1:07:39.360 and 100666 frames - 1:07:06.640)

Corresponding keyframes always in one line.

Keyframes at chapter change:
(1)/(2)/(3)

CHAPTER01=00:00:00.000
0:00:00.000/0:00:00.000/0:00:00.000

CHAPTER02=00:01:15.200
0:01:13.520/0:01:13.520/0:01:13.520
0:01:15.200/0:01:15.200/0:01:15.200
0:01:17.960/0:01:17.960/0:01:17.960
-> player jump in at (2) 0:01:17.960/(3) 0:01:17.960

CHAPTER03=00:11:17.040
0:11:09.480/0:11:09.480/0:11:09.480
0:11:17.200/0:11:17.200/0:11:17.200
0:11:17.240/0:11:17.240/0:11:17.240
0:11:17.280/0:11:17.280/0:11:17.280
-> player jump in at (2) 0:11:17.200/(3) 0:11:17.200

CHAPTER04=00:14:52.080
0:14:49.640/0:14:49.640/0:14:49.640
0:14:52.120/0:14:52.120/0:14:52.120
0:14:56.640/0:14:56.640/0:14:56.640
-> player jump in at (2) 0:14:52.120/(3) 0:14:52.120

CHAPTER05=00:27:12.440
0:27:04.440/0:27:04.440/0:27:04.440
0:27:16.440/0:27:16.440/0:27:16.440
0:27:28.440/0:27:28.440/0:27:28.440
-> player jump in at (2) 0:27:16.440/(3) 0:27:16.440

CHAPTER06=00:36:29.920
0:36:21.520/0:36:21.520/0:36:21.520
0:36:33.520/0:36:33.520/0:36:33.520
0:36:40.480/0:36:40.480/0:36:40.480
-> player jump in at (2) 0:36:33.520/(3) 0:36:33.520

CHAPTER07=00:47:47.520
0:47:35.560/0:47:35.560/0:47:35.560
0:47:47.560/0:47:47.560/0:47:47.560
0:47:54.080/0:47:54.080/0:47:54.080
-> player jump in at (2) 0:47:47.560/(3) 0:47:47.560

CHAPTER08=00:59:24.560
0:59:24.560/0:59:24.560/0:59:24.560
0:59:27.840/0:59:27.840/0:59:27.840
0:59:39.840/0:59:39.840/0:59:39.840
-> player jump in at (2) 0:59:27.840/(3) 0:59:27.840

CHAPTER09=01:17:24.240 - (3) 00:09:44.880
1:17:20.560/1:17:20.560/0:09:41.200
1:17:24.240/1:17:24.240/0:09:44.880 (!!!)
1:17:33.040/1:17:33.040/0:09:53.680 (!!!)
1:17:45.040/1:17:45.040/0:10:05.680
-> player jump in at (2) 1:17:33.040/(3) 0:09:44.880

CHAPTER10=01:28:26.560 - (3) 00:20:47.200
1:28:14.560/1:28:14.560/0:20:35.200
1:28:26.560/1:28:26.560/0:20:47.200 (!!!)
1:28:38.560/1:28:38.560/0:20:59.200 (!!!)
1:28:46.320/1:28:46.320/0:21:06.960
-> player jump in at (2) 1:28:26.560/(3) 0:20:59.200

CHAPTER11=01:40:02.240 - (3) 00:32:22.880
1:40:02.240/1:40:02.240/0:32:22.880
1:40:04.880/1:40:04.880/0:32:25.520
1:40:07.720/1:40:07.720/0:32:28.360
-> player jump in at (2) 1:40:04.880/(3) 0:32:25.520

CHAPTER12=01:51:16.120 - (3) 00:43:36.760
1:51:09.240/1:51:09.240/0:43:29.880
1:51:16.120/1:51:16.120/0:43:36.760 (!!!)
1:51:28.120/1:51:28.120/0:43:48.760 (!!!)
1:51:34.480/1:51:34.480/0:43:55.120
-> player jump in at (2) 1:51:28.120/(3) 0:43:36.760

CHAPTER13=02:02:07.240 - (3) 00:54:27.880
2:02:07.240/2:02:07.240/0:54:27.880
2:02:12.000/2:02:12.000/0:54:32.640
2:02:14.080/2:02:14.080/0:54:34.720
-> player jump in at (2) 2:02:12.000/(3) 0:54:32.640

CHAPTER14=02:12:07.200 - (3) 01:04:27.880
2:12:04.800/2:12:04.800/1:04:25.440
2:12:07.200/2:12:07.200/1:04:27.840
2:12:07.320/2:12:07.320/1:04:27.960
2:12:07.360/2:12:07.360/1:04:28.000
-> player jump in at (2) 2:12:07.200/(3) 1:04:27.840

CHAPTER15=02:13:13.520 - (3) 01:05:34.160
2:13:13.520/2:13:13.520/1:05:34.160
2:13:25.520/2:13:25.520/1:05:46.160
2:13:37.520/2:13:37.520/1:05:58.160
-> player jump in at (2) 2:13:25.520/(3) 1:05:46.160


So the problem seems to be the chapter change on a keyframe.

[Suiryc]

Originally posted by AmiRage
So, here we go ... still a 25.000 fps video stream:

(1) VirtualDub 1.4.10 - XviD-video-only-AVI (202150 frames - 2:14:46.000)
(2) OGGMux 0.9.2 - complete OGM (202150 frames - 2:14:46.000)
(3) OGMCutter 0.9a5 - cut of the complete OGM (101484 frames - 1:07:39.360 and 100666 frames - 1:07:06.640)

...

CHAPTER09=01:17:24.240 - (3) 00:09:44.880
1:17:20.560/1:17:20.560/0:09:41.200
1:17:24.240/1:17:24.240/0:09:44.880 (!!!)
1:17:33.040/1:17:33.040/0:09:53.680 (!!!)
1:17:45.040/1:17:45.040/0:10:05.680
-> player jump in at (2) 1:17:33.040/(3) 0:09:44.880
So in the original clip, there was a keyframe at the same time than the chapter. In the cut part it's still the case (at least my cutter work as I expected here :)).
But : with the original clip the player jumped to the next keyframe while with my cut part it jumped on the "correct" keyframe.

CHAPTER10=01:28:26.560 - (3) 00:20:47.200
1:28:14.560/1:28:14.560/0:20:35.200
1:28:26.560/1:28:26.560/0:20:47.200 (!!!)
1:28:38.560/1:28:38.560/0:20:59.200 (!!!)
1:28:46.320/1:28:46.320/0:21:06.960
-> player jump in at (2) 1:28:26.560/(3) 0:20:59.200
Here it is the same with keyframe on chapter.
But now it is the contrary : with the original clip the player jumped on the "correct" keyframe, while with my cut part it jumped to the next one.

So seems either my tools report weird positions (sometimes before the real one, sometimes after the real one) or it is related to OggDS (when seeking on keyframes), or both :/

[AmiRage]

So seems either my tools report weird positions (sometimes before the real one, sometimes after the real one) or it is related to OggDS (when seeking on keyframes), or both :/
So currently the rule has to be: Never use a keyframe as chapter beginning. :D

I guess I'll slightly change the chapter entries.

BTW ... is it difficult to integrate a function to cut out certain pieces?

[Suiryc]

Originally posted by AmiRage
So currently the rule has to be: Never use a keyframe as chapter beginning. :D
Think so :)

BTW ... is it difficult to integrate a function to cut out certain pieces?
You mean cut from frame (or time) A to frame (or time) B ?
It should not be too difficult since I already parse the file a first time to know what I need about the video stream ...

[AmiRage]

Originally posted by Suiryc
You mean cut from frame (or time) A to frame (or time) B ?
Yes, that's what I meant! :)

So for example it's possible to directly cut out a small sample of a specific movie which features all that OGM has to offer: video/audio streams, subtitles, chapters ...

Please! Please! .... :D

[Psyche]

@Suyric:
Would you please be so kind as to incorporate in OGMInfo a calculation for actual bitrate of the streams? The formula would be this:

bytes_bodies 1
--------------- * sample_rate * 8 * ----- = bitrate (kbits/s)
no_of_samples 1000

You would make me very happy. :D

Thank you.

[Suiryc]

@AmiRage & Psyche
I updated OGMCutter (v1.0a1) and OGMInfo (v1.3b1).

For the cutter : you can now precise points (by frame number or time) where to cut in the clip (-f option).
Those points are used to define subsets (first subset is thrown, second subset is kept, third subset is thrown, ...).
You can still use the -n (maximum number of parts) and/or -s (split size) together with the new -f option, resulting in applying those options on each kept subset (to summarize : if you want to keep only certain parts of the clip, but still want to have parts smaller than a certain size, it's possible).
See the txt file that comes with OGMCutter for more information.

You can also "simulate" the cutting process (in this case OGMCutter will stop just after having printed where it would cut).

Enjoy :)

Nb : Hope I didn't broke anything with the cutter ;)

[joerg]

A possibility to specify the exact cut points in frames or seconds (like implemented in the latest version of OGMCutter) _without_ throwing away any parts would IMHO be a useful feature.

[Psyche]

Thanks!

[Suiryc]

Originally posted by joerg
A possibility to specify the exact cut points in frames or seconds (like implemented in the latest version of OGMCutter) _without_ throwing away any parts would IMHO be a useful feature.
Ah ah, it should be also possible :), with a little trick :)

To summarize :
you use -f "1000 2000 3000" to create 4 subsets :
1 for beginning to frame 1000 (thrown)
1 for frame 1000 to frame 2000 (kept)
1 for frame 2000 to frame 3000 (thrown)
1 for frame 3000 to the end (kept)

Now say you want to keep the whole clip but force split near those frames (1000, 2000 and 3000), then you should use -f "0 1000 1000 2000 2000 3000 3000", i.e. create 8 subsets :
1 for beginning to frame 0 (thrown)
1 for frame 0 to frame 1000 (kept)
1 for frame 1000 to frame 1000 (thrown)
1 for frame 1000 to frame 2000 (kept)
...

:)

Doing so (kind of "invalid" subsets since empty) will make OGMCutter modify the subsets by setting subsets boundaries on the first next keyframe.
So suppose in your clip the first keyframes next to frames 1000, 2000 and 3000 are frames 1075, 2000 and 3009, then the option above will make OGMCutter create 4 parts :
frame 0 -> frame 1075 (excluded)
frame 1075 -> frame 2000 (excluded)
frame 2000 -> frame 3009 (excluded)
frame 3009 -> end of clip

At least in theory ;)

[joerg]

Thanks for the info! Didn't think about that possibility before :)

[Suiryc]

For those who are interested, I put v0.9a6 (still testing because I changed a lot of thing inside) of OGMuxer on the site.
What's new :

Version 0.9a6
- fixed what could have caused problems when using OGM (with more than 1 stream)
file as input
- added a lazy mode for Emp3r0r :p : you can precise the Setup file as unique option
thus allowing drag'n'drop of such Setup file
- (great) internal rework
- seems a little faster to process now :)
- added WAV format for input
- will now process all audio streams coming from an AVI file
- can "reprocess" audio streams coming from an AVI or WAV file (instead of just
writing the data as is, reprocess them regarding their type - valid for MP3 or
AC3 streams in AVI and WAV files)
Nb : This is of great help when the audio stream is a VBR one :) (on my test
reprocessing fixes a synchronisation problem I have when not using reprocessing)
See OGMuxer.txt for more information.

[AmiRage]

Thanks for the info and the new versions. Will give it a try at the weekend.

... and could you please add the version to your archive names on your homepage? I'm always confused wether or not the version I already have on my harddisk is an older or newer one. :D

[Suiryc]

Originally posted by AmiRage
... and could you please add the version to your archive names on your homepage? I'm always confused wether or not the version I already have on my harddisk is an older or newer one. :D
:confused: I am not sure to understand exactly what you want : You want me to put a list that enumerate old versions of my tools ? (there is no problem for that, but I thought the version number was enough ...)

BTW I am currently working on "merging" the muxer and the cutter :)
Well of course this means there will be at least three times more bugs : those coming from the muxer, those coming from the cutter, and those I (not on purpose :p) added when putting code from the cutter into the muxer :D

[inoteb]

I think AmiRage would like you add the version number to the name of the downloadable zip. For instance : OGMInfo_1.3b1.zip instead of OGMInfo.zip, as you've already done for latest OGMuxer (OGMuxer_0.9a6.zip)

Nice to merge muxer & cutter ! I'm eagerly waiting for a GUI... Is anybody working on that ? (I wish I could, but I'm incapable of it)

[Suiryc]

Originally posted by inoteb
I think AmiRage would like you add the version number to the name of the downloadable zip. For instance : OGMInfo_1.3b1.zip instead of OGMInfo.zip, as you've already done for latest OGMuxer (OGMuxer_0.9a6.zip)
I didn't added version number in file name because it was easier for me when zipping files (don't have to change the name) and updating the site (I know I'm lazy :D).
So I will change that :)

Nice to merge muxer & cutter ! I'm eagerly waiting for a GUI... Is anybody working on that ? (I wish I could, but I'm incapable of it)
At least not me for the moment :p
For the muxer I simplified a lot of things so that it can be easily merged into another C++ program (when I say merge I mean add source code, not only use the tool with commandline).
The next version will even be able to tell this program of its current progress (well it is not multithreaded nor a DLL, but it's better than nothing :)).

[Emp3r0r]

I can't figure out what my problem is with the following omx file<movie>
re.avi
</movie>

<title>
Resident Evil
</title>

<soundtracks>
re.ogg
English
</soundtracks>

<subtitles>
</subtitles>

<chapters>
re.txt
</chapters>

<target>
re.ogm
</target>

[Suiryc]

Unless an error tell you what is the problem, I think maybe your problem is : OGMuxer don't start anything and take 100% process ?
If yes I would bet it's because I don't see the<split>
</split>
section.
Even if OGMuxer doesn't handle splitting, it stays "compliant" with the omx format of Koepi :p

[Emp3r0r]

You are absolutely right! :D Anyway, after adding <split>
0
</split>the file works perfectly fine from the commandlind using either "ogmuxer re.omx" or "ogmuxer -s re.omx" BUT when I drag and drop the file it doesn't work. I fixed the problem by adding full paths and then drag and drop worked<movie>
C:\Documents and Settings\Administrator\My Documents\Video Processing\VOBs\re\re.avi
</movie>

<title>
Resident Evil
</title>

<soundtracks>
C:\Documents and Settings\Administrator\My Documents\Video Processing\VOBs\re\re.ogg
English
</soundtracks>

<subtitles>
</subtitles>

<chapters>
C:\Documents and Settings\Administrator\My Documents\Video Processing\VOBs\re\re.txt
</chapters>

<target>
C:\Documents and Settings\Administrator\My Documents\Video Processing\VOBs\re\re.ogm
</target>

<split>
0
</split>
Great Work Suiryc! and thanks for your help.

[Suiryc]

Originally posted by Emp3r0r
You are absolutely right! :D Anyway, after adding <split>
0
</split>the file works perfectly fine from the commandlind using either "ogmuxer re.omx" or "ogmuxer -s re.omx" BUT when I drag and drop the file it doesn't work. I fixed the problem by adding full paths and then drag and drop worked
Well normal since OGMuxer works in the current path (so its own path if you drag'n'drop). :p
C:\Documents and Settings\Administrator\My Documents\Video Processing\VOBs\re\re.avi
Hum, nobody told you it was bad to use the Administrator account for common usage ;)
(Nb : I do the same too :p)

[Emp3r0r]

Well normal since OGMuxer works in the current path (so its own path if you drag'n'drop). Actually, what is weird is that ogmuxer.exe is in the same path as re.omx, re.avi, re.ogg, re.txt
Which mean they all have the same path.

Hum, nobody told you it was bad to use the Administrator account for common usage ;) Actually, I changed the path to say administrator to protect the name of the persons account I am using ;)

[Suiryc]

Originally posted by Emp3r0r
Actually, what is weird is that ogmuxer.exe is in the same path as re.omx, re.avi, re.ogg, re.txt
Which mean they all have the same path.
:confused: So I was wrong ... Will see if I can do something for improving that :D

[Suiryc]

I put v1.0a1 of OGMuxer on the site.
This is the version that merge the muxer and the cutter.
There may be lot of bugs in it but if you want to test you can :D

Nb : If you use audio reprocessing and splitting/cutting capabilities of this version the program eats more memory :D.
(exemple where using both capabilities : 700MB AVI (~1h) containing video+AC3+MP3, + 40MB Ogg file + SRT file => a maximum of ~40MB used during my test)

[tecxx]

i just tried oggmcutter to split my 1.4 gig video with rearranging the chapter info.

it's just great. thanks a lot!!!

ps: someone should put the chapter code into ogmuxer

[Suiryc]

Originally posted by tecxx
ps: someone should put the chapter code into ogmuxer
:confused: (you mean OGMuxer or OggMux ?)

I put v1.0a2 of OGMuxer on the site. I fixed some bugs mainly introduced in version 1.0a1 (making OGMuxer unusable in cases like : using a Vorbis stream, using an .omx file, ... :( ).

I also put another modification of VirtualDub. Now the (first) audio stream is also processed when saving to an OGM file.

PS : this means that when you have an OGM file with only one audio and one video stream this VirtualDub could replace OGMCutter (except if there are comments like chapters : they won't be updated).

[Kurd]

great, now Vdub works with Ogm. Now i can splitt OGm files with Vdub, so i changed my ripping Method of my Episodes to OGM too.

[Suiryc]

Before changing anything you should first try it to see if this works well enough (I cannot guarantee that this will work in all possible situations, and that there won't be any problem like desynchronisation between video and audio).

It would be bad if this tool screw up your favorite clips :(

[meleth]

Hi,

I'm sure someone has asked this before, but it would be nice to be able to name the sound and subtitle streams in your muxer tool. Somehow i can't seem to be able to find a switch for this. Is there another program that can be used to do this?

[Suiryc]

You mean precise the language of the audio/subtitle stream, or the title of the clip ?

If so presently the only solution is to use a .omx file (same as OggMux).

So for example the commandline would be
OGMuxer -s C:\MySetupFile.omx
The omx file must contain the complete path of the files you want to include (unless all files are in the same directory).

[meleth]

ahh ok cool.. one question about the omx file. When adding more than 1 soundtrack should it look like this?

<soundtracks>
blah.mp3
English
blah2.mp3
Swahili
</soundtracks>

Edit: Oh yeah, what will happend if you tell it to split on a frame that's now a keyframe? Will it take the previous or the next one? or will it simply not work?

[Suiryc]

Originally posted by meleth
<soundtracks>
blah.mp3
English
blah2.mp3
Swahili
</soundtracks>
Yes :)

Edit: Oh yeah, what will happen if you tell it to split on a frame that's not a keyframe? Will it take the previous or the next one? or will it simply not work?
If I remember well (normally it should also be in the .txt file that comes with OGMuxer), this is the nearest previous key-frame that is chosen (it is the current frame if it is already a key-frame).

Well this apply when splitting. If you cut a part then your part will end on the frame you chosen.
The exception is if you want to cut multiple parts at a time and that the frames you specified are too near :
So if you want to keep frames 0->200 and then frames 250->500, if there is a keyframe at 210, you will get frames 0->200 and 210->500, but if the keyframe is only at 198, then you get frames 0->198 and 198->500

[meleth]

ok cool thanks.

[AmiRage]

Hi Suiryc!

I think there's a small bug concerning the ogm title naming.

The titles of the two ogm files I just created using OGMuxer 1.0a6 and an omx file are "(omx file title) - Part 1 - Part 1" and "(omx file title) - Part 1 - Part 2".

[Suiryc]

Thanks (I saw this too a few hours ago).

I will put version 1.0a7 online soon ...
Done

[meleth]

Hi, I get this ere when trying to use an omx file. Now i've tried with both current and absolute path but it doesn't seem to help. The filenames are correctly spelled, it's been doublechecked quite some times now:P

Error in InputFile::InputFile (InputFile.cpp) @ 63 : Could not open the file []
Error in InputFile::InputFile (InputFile.cpp) @ 64 : Process aborted due to previous error

Any ideas? The omx file looks like this.

<movie>
slayers1.avi
</movie>

<title>
Slayers
</title>

<soundtracks>
eng.mp3
English
jap.mp3
Japanese
</soundtracks>

<subtitles>
slayers.srt
</subtitles>

<target>
slayers.avi
</target>

<split>
0
</split>

[Suiryc]

Hi

I think <subtitles>
slayers.srt
</subtitles>
should be<subtitles>
slayers.srt
English
</subtitles>
(language of the subtitle lacks)
:)

[meleth]

k, i'm retarded for not seeing that.

[Suiryc]

:p
... and I think it is better to change<target>
slayers.avi
</target>
to<target>
slayers.ogm
</target>
(or change the extension of the resulting file if you already muxed)
:)

[AmiRage]

I'm (again) desperately trying to cut some small sample out of a 800 megs OGM file using OGMCutter 1.0a1.

ogmcutter -f "1950 2200 50000 50250" "[filename]"

The processing of the input file is passed without any problem, but when the cutting process reaches this small part OGMCuttter eats all the cpu time and a largely increasing amount of memory (180 megs plus).

Any idea?

Update: Some info about the file: It's an OGM containing an XviD video and two OGG audio streams, two subtitles and chapter info.

[Suiryc]

Again with those small samples ... :)

Did you tried with OGMuxer too ? (you can cut the ogm file with it ... this is a specal case since there is only one input file but it should work too)

For the memory I know where it comes from : if there is something wrong (a bug of course ;)) that prevent the tool for getting enough information to write to the file, then it will process the rest of the input file ... in memory (fortunately this cannot happen except if there is a bug :p ).

Now to know where is this bug, this is another thing. I will make some tests to see if I can reproduce that.

[AmiRage]

It's the same using OGMuxer.

[Beave]

Thanks Suiryc for your great tools. I just came across them.

I first tried your OGMuxer to split and mux a file using a vbscript. It works when using this system: --frames "0 10000 10000 20000 20000". Maybe if you couls add another option for just splitting without throwing anything away would be great, but not totally nessecary.

What I greatly miss is the possibility to name those Parts after splitting. Something like

OGMuxer -s setup.omx -o "Friends.ogm" --frames "..." --partnames "301" "302" 303" "304"...

I'm encoding episodes from series to fit on one CD. So I take for example 6 episodes in one piece, encode them and want to split them afterwards. I modify the Log-File between the 2 Passes to put the keyframes at the splitpoints, so the vobsubfiles of each episode will work.

I tried your VirtualDub Modification and it works great for cutting an OGM with only one audio. Adding chapters is possible, but muxing a video with audio is not possible yet.
Unfortunatly the avs options don't work here. If I want to open a file via AviSynth it gives an error "File doesn't seem to be a valid PNG file". A bug, or something wrong with my AviSynth installation?

Anyways, keep up the good work.

[Suiryc]

Originally posted by Beave
I tried your VirtualDub Modification and it works great for cutting an OGM with only one audio. Adding chapters is possible, but muxing a video with audio is not possible yet.
Unfortunatly the avs options don't work here. If I want to open a file via AviSynth it gives an error "File doesn't seem to be a valid PNG file". A bug, or something wrong with my AviSynth installation?

Anyways, keep up the good work.
Eheh it's a little bug that was introduced with the PNG support. I just fixed it (I put version 2 of today on the site).
This should work again with AVS files now :)


Good idea about letting the user choose titles for the parts. I will see what I can do for that :).
I think the best would be something like : --maintitle "..." for the main title, and --titles #n "title 1" ... "title n" (as presently the parameters of commandline without option are considered as input files, I need to know here the number of titles you choosed).
Then if there is only one part, use the main title, for each part use the title proposed by the user, and if the number of parts exceed the number of titles, use the main title + " - Part #n" (which can be disabled anyway using the --title option).

[Beave]

Yeah, that sounds fine to me.

[Suiryc]

I thought of something maybe more usefull for the titles. If I can, why not something like : --title "bla ... bla{{...%n...}}" to replace the actual --title option.
So if there are parts, use the {{...%n...}} block and replace %n by the part number, and just delete the block when there is no part.
This can replace the --title option because with that the user decide if something must be added to the title or not (and he/she also decide what will be added, i.e. maybe something different than " - Part %n").

What do you (users) think ?


@AmiRage
I tested to cut samples of 10 or less frames (with a clip containing two audio streams, subtitles and chapters), but this was OK :/
I will do some more tests with other clips ...
What is the framerate of your clip ?

[AmiRage]

Originally posted by Suiryc
What do you (users) think ?Sounds good and flexible! :D

Originally posted by Suiryc
What is the framerate of your clip ?



5 Streams : 2 Vorbis, 0 Audio, 1 Video, 2 Text, 0 Old, 0 Unknown, 0 Invalid

=== STREAM 0 (VIDEO 1) ===
Stream Header :
Type : video
SubType : XVID
Size : 56
Time Unit : 400000 (in reference time)
Samples per Unit : 1
Sample Rate : 25.000
Default Len : 1 (in media unit)
Buffer Size : 60234
Bits per Sample : 24
Width : 640
Height : 384
End Of Stream reached : yes
Number of Pages : 175030 (0 skipped)
Number of Packets : 101235 announced / 101235 found (0 skipped), 101233 containing data (not header nor comments)
Number of Samples : 101233 announced / 101233 found
Samples per Packet : 1.0
Packets per Page : 0.6
Bytes : 7709407 (headers) + 747842141 (bodies) = 755551548 (720.55MB)
Percentages : 1.020% for headers + 98.980% for data
Packet bytes : 747842141
Bytes per Page : 44 (header) + 4272 (body) = 4316
Bytes per Packet : 7387
Duration : 01:07:29.320
Estimated BitRate : 1477.5 kbps
Frames per Second : 25.000 fps

=== STREAM 1 (VORBIS 1) ===
Stream Header :
Type :
SubType :
Size : 56
Time Unit : 10000000 (in reference time)
Samples per Unit : 44100
Sample Rate : 44100.000
Default Len : 1 (in media unit)
Buffer Size : -1
Bits per Sample : 2
Number of Channels : 2
BlockAlign : 0
Average Bytes per Second : 12000 (96.0 kbps)
End Of Stream reached : yes
Number of Pages : 10196 (0 skipped)
Number of Packets : 260947 announced / 260947 found (0 skipped), 260944 containing data (not header nor comments)
Number of Samples : 178575552 announced / 178575616 found
Samples per Packet : 684.3
Packets per Page : 25.6
Bytes : 544753 (headers) + 42830664 (bodies) = 43375417 (41.37MB)
Percentages : 1.256% for headers + 98.744% for data
Packet bytes : 42830664
Bytes per Page : 53 (header) + 4200 (body) = 4254
Bytes per Packet : 164
Duration : 01:07:29.332
Estimated BitRate : 84.6 kbps

=== STREAM 2 (VORBIS 2) ===
Stream Header :
Type :
SubType :
Size : 56
Time Unit : 10000000 (in reference time)
Samples per Unit : 44100
Sample Rate : 44100.000
Default Len : 1 (in media unit)
Buffer Size : -1
Bits per Sample : 2
Number of Channels : 2
BlockAlign : 0
Average Bytes per Second : 12000 (96.0 kbps)
End Of Stream reached : yes
Number of Pages : 8879 (0 skipped)
Number of Packets : 245866 announced / 245866 found (0 skipped), 245863 containing data (not header nor comments)
Number of Samples : 178575168 announced / 178575232 found
Samples per Packet : 726.3
Packets per Page : 27.7
Bytes : 485613 (headers) + 37198686 (bodies) = 37684299 (35.94MB)
Percentages : 1.289% for headers + 98.711% for data
Packet bytes : 37198686
Bytes per Page : 54 (header) + 4189 (body) = 4244
Bytes per Packet : 151
Duration : 01:07:29.323
Estimated BitRate : 73.5 kbps

=== STREAM 3 (TEXT 1) ===
Stream Header :
Type : text
SubType :
Size : 56
Time Unit : 10000 (in reference time)
Samples per Unit : 1
Sample Rate : 1000.000
Default Len : 1 (in media unit)
Buffer Size : 16384
Bits per Sample : 0
End Of Stream reached : yes
Number of Pages : 203 (0 skipped)
Number of Packets : 203 announced / 203 found (0 skipped), 201 containing data (not header nor comments)
Number of Samples : 4049320 announced / 4049320 found
Samples per Packet : 20145.9
Packets per Page : 1.0
Bytes : 5684 (headers) + 5721 (bodies) = 11405 (0.01MB)
Percentages : 49.838% for headers + 50.162% for data
Packet bytes : 5721
Bytes per Page : 28 (header) + 28 (body) = 56
Bytes per Packet : 28
Duration : 01:07:29.320
Estimated BitRate : 0.0 kbps

=== STREAM 4 (TEXT 2) ===
Stream Header :
Type : text
SubType :
Size : 56
Time Unit : 10000 (in reference time)
Samples per Unit : 1
Sample Rate : 1000.000
Default Len : 1 (in media unit)
Buffer Size : 16384
Bits per Sample : 0
End Of Stream reached : yes
Number of Pages : 203 (0 skipped)
Number of Packets : 203 announced / 203 found (0 skipped), 201 containing data (not header nor comments)
Number of Samples : 4049320 announced / 4049320 found
Samples per Packet : 20145.9
Packets per Page : 1.0
Bytes : 5684 (headers) + 5608 (bodies) = 11292 (0.01MB)
Percentages : 50.337% for headers + 49.663% for data
Packet bytes : 5608
Bytes per Page : 28 (header) + 27 (body) = 55
Bytes per Packet : 27
Duration : 01:07:29.320
Estimated BitRate : 0.0 kbps


Total bytes : 8751141 (page headers) + 827882820 (page bodies) = 836633961 (797.88MB)
Percentages : 1.046% for headers + 98.954% for data

It can't be in some way related to the used filesystem or something?!

[Suiryc]

Originally posted by AmiRage
It can't be in some way related to the used filesystem or something?!
I don't think so (at least it cannot be a filesize problem ;)).
Why are you wondering?

PS : have you tried cutting other parts in the clip (to see if it is a general problem, or related to the part you wanted to cut) ?

[AmiRage]

Originally posted by Suiryc
Why are you wondering?

PS : have you tried cutting other parts in the clip (to see if it is a general problem, or related to the part you wanted to cut) ? I'm wondering because you're not experiencing my problem. :D

And yes, I tested several different short cuts ... always the same. It seems to get worser when the cut-part is closer to the beginning of my 800 megs file (if the rest is processed in memory only then this is explainable).

When using the same cut entry but a longer part it works.

I'll too make some further testing ...

[AmiRage]

A small update on my experiences concerning the small part big problem issue. :D

I just made some test runs with different cut part lengths (250, 1000 and 2000 frames) with the cut entry somewhere in the middle (to be exact at frame 50000) of the above mentioned OGM file.

Always after keeping the second part and echoing "Status in OGMCutter.cpp : Skipping Part 3 ..." the cpu load's rising to 100 percent ... but ... the longer the cutted part the smaller the period of this cpu peak.

So when cutting 2000 frames a peak load period too appears, but this one is relatively short ... and OGMCutter completes without severe problems, but the smaller the frame number to be cutted gets the (exponentially) longer this peak load period remains.

[Suiryc]

Originally posted by AmiRage
Always after keeping the second part and echoing "Status in OGMCutter.cpp : Skipping Part 3 ..." the cpu load's rising to 100 percent ... but ... the longer the cutted part the smaller the period of this cpu peak.
In all cases does the part you wanted to be cut is correctly generated ?

I made other tests on other clips (also cutting @ frame 50000 to see) but never get anything that weird :/

What is your OS? Does anybody else have the same problems?

[AmiRage]

Originally posted by Suiryc

In all cases does the part you wanted to be cut is correctly generated ?

What is your OS? Does anybody else have the same problems? Yes, the parts are correctly. But I didn't try "very" small parts as this would run for several hours.

My OS is Windows XP.

Just made two additional test runs:

(1) ogmcutter -f "50000 51500 75000 76500 90000 91500"
=> cpu peak load after the first kept part, rest runs without any problems/peaks

(2) ogmcutter -f "75000 76500 90000 91500"
=> cpu peak load again after the first kept part, rest runs without any problems/peaks

Strange?! :D

[Suiryc]

I have Windows XP too.

Did you tried "format c:" ? Allways solved a lot of problems for me under Windows ;)

Stupid question : you have the latest ogg.dll and vorbis.dll files ? (included with OggDS)

[AmiRage]

Originally posted by Suiryc
Stupid question : you have the latest ogg.dll and vorbis.dll files ? (included with OggDS) Yes, i have, and this installation of Windows XP including SP1 is clean and never saw another version of OggDS/SubTitDS than the latest available. :rolleyes:

[Beave]

I tried some small cuts and everthing works fine here. Sorry, AmiRage.

@Suiryc
How is the new OGMUxer Version going? I had the idea that i could also start the OGMuxer for each part seperatly to give it a unique name. But OGMuxer would start analyze the File each time it starts, right?

Are you planning on enhancing VirtualDubOGM? Maybe it will even be possible to mux all the streams in VDubOGM and cut them? That would be great. But your tools would probably become obsolete then (at least when it comes to user interaction).

[AmiRage]

Originally posted by Beave
I tried some small cuts and everthing works fine here. Sorry, AmiRage.
Thanks, I'd guess I'm giving up on OGM for the moment. I don't know why, but I'm currently only experiencing problems with OGM.

Maybe I'll install only Windows XP plus OggDS/SubTitDS on weekend for test purposes ... :mad:

[Suiryc]

@Beave
Yes each time you use OGMuxer it will analyze the file.
Yes I think of enhancing VirtualDubAVS&OGM, but presently I have other things to do (try to find what is AmiRage problem, there is also something weird with OokzDVD concerning the subtitles, maybe my mods will be included in VirtualDubMpg2 project, ...) ;)

@AmiRage
I will make a special version for you that will output everything it does.
Maybe this will give me some more hints on what's going on ...

[AmiRage]

Originally posted by Suiryc
@AmiRage
I will make a special version for you that will output everything it does.
Maybe this will give me some more hints on what's going on ... Thanks, but I'll first make some test runs with OggDS 0.9.9.4 as this version worked/works flawlessly so far ...

[Suiryc]

You will find the "debug" version here (http://cyrius.bunkus.org/OGMCutter_1.0a1_Debug.zip).
You use it as usual except you put " > C:\Log.txt" at the end of your command line.
This will send all outputs to the Log.txt file.
You will only see the progress of each step (so 2 times 0->100%).

At the end (or when you killed the app because it took all your memory ;)), you compress the Log.txt file (should be 80MB for your 800MB file; use, in order of preference, WinRAR, WinACE or WinZIP). The compressed file should be between 1.25-1.75MB), and you send me the file (suiryc AT yahoo DOT com).

Thanks

[AmiRage]

Thanks for the debug version.

It's running now for about 25 minutes at peak load while consuming about 240 megs of RAM. :D ... Progress: 2.13 %.

It's only a matter of days ... ;)

[Suiryc]

Your problem is really strange ...

At first sight everything seems to work as expected (the log file doesn't reveal anything weird :/), nevertheless your system doesn't tell the same ...

When creating the first file it is normal there is a memory peak because I allocate a 8MB buffer between my routines and writing into the file ... but 180MB is far beyond that ;)

In your various tests, can you tell me if the memory was freed during processing ? (i.e. you have the 180MB memory peak, but then a few seconds after - and before the end of the process - all went back to "normal")
Does the memory is linearly allocated ? (i.e. it is not a "real" pick where the memory used go from 20-30 to 180MB in no time)

I don't think I asked this or if you mentioned it, but does this happen only with this clip or with others too ?

Then does anybody having similar specs (Windows XP - SP1 + latest OggDS / SubtiDS) experience the same problems when cutting small parts ?


PS : and finally did you tried with a former version of OggDS (0.9.9.4) ?

[AmiRage]

Originally posted by Suiryc Your problem is really strange ...
Thanks!
In your various tests, can you tell me if the memory was freed during processing ? (i.e. you have the 180MB memory peak, but then a few seconds after - and before the end of the process - all went back to "normal")IIRC it was freed. But I'll do some further testing on this.
Does the memory is linearly allocated ? (i.e. it is not a "real" pick where the memory used go from 20-30 to 180MB in no time)The memory usage is growing linearly. Some further observation here too.
I don't think I asked this or if you mentioned it, but does this happen only with this clip or with others too ?Currently I only tested with this 2 x 800 MB clip I created using OGMuxer. But I'll test it with another clip when space and time allows.
PS : and finally did you tried with a former version of OggDS (0.9.9.4) ?Yes, exactly the same problem. Even when creating the clip with 0.9.9.4

[AmiRage]

I'm getting crazy about this ...

(1) The memory is always freed at the end.

(2) My Problem seems to be related to (my?) subtitles ...

I just muxed the same source material with different combinations and made exactly the same cut runs:

1. 1 XviD and 1 OGG -> no problem
2. 1 XviD and 2 OGGs -> no problem
3. 1 XviD, 2 OGGs, chapters -> no problem
4. 1 XviD, 2 OGGs, 1 subtitle (Danish), chapters -> CPU peak/increasing memory usage on/after first writing
5. 1 XviD, 2 OGGs, 1 subtitle (Finnish), chapters -> CPU peak/increasing memory usage on/after first writing
6. 1 XviD, 2 OGGs, 2 subtitles, chapters -> CPU peak/increasing memory usage on/after first writing
7. 1 XviD, 1 OGG, 1 subtitle, chapters -> CPU peak/increasing memory usage on/after first writing
8. 1 XviD, 1 subtitle, chapters -> CPU peak/increasing memory usage on/after first writing
9. 1 XviD, 1 subtitle -> CPU peak/increasing memory usage on/after first writing

The subtitle(s) only seem(s) to cause trouble on cutting, but not on muxing. And "cutting" while muxing is also no problem.

[Suiryc]

Ah ah, some more hints :)
Could you send me those damn subtitles :) (maybe I could obtain the same problems muxing other clips with those subtitles) (I like having memory peaks ;) )

It's normal the memory is freed at the end (Windows does it if the program forget to do so).

[AmiRage]

Originally posted by Suiryc
Could you send me those damn subtitles :)Are you an adult? :D ... especially when you're able to read danish or finnish. :)

I'll make some further test runs with each of the languages, post the results and send you the subtitles.

[Suiryc]

Originally posted by AmiRage
Are you an adult? :D ... especially when you're able to read danish or finnish. :)
Well I am not able to read danish or finnish (I am French, can write/speak english, and know a few words in spanish), but this will be enough to mux the subtitles with another clip :D
And yes I am an adult :p


PS : why are you asking that? Did some words in my posts have other meanings that the one I thought? (my english is not perfect :( )

[AmiRage]

Originally posted by Suiryc
PS : why are you asking that? Did some words in my posts have other meanings that the one I thought? (my english is not perfect :( ) No! :D ... because of the content of the subtitles. :)

P.S.: Subs already on their way!

[Emp3r0r]

@siuric: I use your ogmuxer all the time and I have a few more feature requests as it seems it would make make life easier if ogmuxer could do the following things:

Take .omx file that will handle the following additions
<size>794</size><!--target size-->
<firstframe>680</firstframe><!--first important frame-->
<lastframe>189827</lastframe><!--last important frame-->
<titlemode>false</titlemode><!--no parts in title-->

and returns a file that is as close to 794 megs as possible and keeping as many frames between 680 and 189827 (frames at beginning should keep precidence over frames at end) with all chapters modified (only if frames from beginning must be cut) and no Part 1 in the movie title. It should also report wether it was successful at creating the ogg stream including all frames between firstframe and lastframe at the target size and report (if unsuccessful) the size required to fullfill the inclusion of all important frames.

I can explain more if you don't see my reasoning, otherwise just tell me if any of this is unreasonable. Thanks

[Emp3r0r]

Ok, I thought of one more thing which would be affected by my requests. I usually overwrite the first frame of my movies with the title frame (so it shows in thumbnails in explorer or when I push stop in zoomplayer). Anyway, how hard is the process of appending a keyframe (1 frame ogg stream) in front of an existing ogg stream?

[Suiryc]

@AmiRage
LOL :), you know what is the problem? People don't talk enough (no kidding) :D
This won't be easy to correct my tools so that they work correctly in this case, but I will do my best :)


@Emp3r0r
Looks like you sometimes get oversized clips ;)
For the title don't worry I am modifying the feature so that you can choose how it will looks like (i.e. a fixed title, a special title for a certain number of parts, or a title that adapts according to the part number - and where you choose that you put " - Part %n" or anything you want in it).

For the first_frame->last_frame you can also use
--frames "first_frame last_frame" --split max_size --simulate
that will tell you how OGMuxer would have cut your clip (so you can see in how many parts the first_frame->last_frame would have been cut, and what is the size of each part).

For the adding of a frame at the beginning, I think it is possible to do.
But I will add this feature when I have enough time or if other people think it is usefull (I think you understand I cannot add a feature at each user request if this feature only concerns this user ... because if not I would have to code till the end of my life ;) ).

[AmiRage]

Originally posted by Suiryc
LOL :), you know what is the problem? People don't talk enough (no kidding) :D
This won't be easy to correct my tools so that they work correctly in this case, but I will do my best :)Come on, you're kidding!? :D Or is this really true? This is the cause for my problems? :D :D :D I can't believe it.

[Suiryc]

Well at least it is my best explanation for what is happening.

The fact is that sometimes there is too much time between two subtitles.
This, combined with the fact I do not handle this situation correctly, make my routines expect data from the subtitle stream between those two subtitles, and data coming from other streams are stored in memory in the meantime.

One example : the first subtitle starts @ 00:11:??.???. If I wanted to cut the clip between 00:00:10.000 and 00:00:20.000, then I would have data representing about 10 minutes of the clip pending.
Your clip lasts about 1 hour, for 800MB, so 10 minutes = 800 / 6 = 130MB (just for the data, I need some more memory for the structures holding those data) pending in memory.

[AmiRage]

Thanks for explaining. Hope you can find a way for this special case of subtitles. :D

Thanks in advance.

[Suiryc]

Well OGMCutter v1.0a2 should solve your problem :)

I also put the modification concerning titles modification in it.

[Beave]

Well OGMCutter v1.0a2 should solve your problem
I also put the modification concerning titles modification in it.

Why didn't you put it into OGMuxer? I thought OGMuxer can do the same thing, so OGMCutter is redundant.

[AmiRage]

Originally posted by Suiryc
Well OGMCutter v1.0a2 should solve your problem :)
Thanks, Suiryc! The first test with a small cut at the very beginning of the OGM ...

ogmcutter -f "1700 1950"

... worked very well with a IMHO lower overall cpu and memory (about 10 MB) load and no peak load during the cutting process.

... but ... :D ... the second test run using ...

ogmcutter -f "10000 11500 50000 51500 90000 91500"

... made the peak load reappear on the second cut. :confused:

Update: The problem hasn't gone away, it now doesn't happen on the first cut (so far) but on following parts.

[Suiryc]

Originally posted by Beave
Why didn't you put it into OGMuxer? I thought OGMuxer can do the same thing, so OGMCutter is redundant.
I am going to put it OGMuxer too.
But I didn't code the two tools the same way, so it's a bit different to do for OGMuxer ...


@AmiRage
Well I will do some other tests then

[Suiryc]

Oops I think I forgot something in the code ;)

So for AmiRage, OGMCutter v1.0a3 should work now (I really hope so :))

And for Beave there is OGMuxer v1.0a8 that also have the title modification feature. (this version has not been updated regarding AmiRage problem because it seems there are less problems with OGMuxer so I need to investigate a bit to know what I need to modify)

[AmiRage]

Originally posted by Suiryc
Oops I think I forgot something in the code ;)

So for AmiRage, OGMCutter v1.0a3 should work now (I really hope so :))
No it works fast and fluently ... although there are some very short higher CPU load peaks, but it works really great. Thanks so much! :)

Maybe I can find some other specials ... :D

[AmiRage]

New topic: OGMerger! :D

I just recognized that when merging OGMs with and without chapter info, the chapter info is dropped when the first to be merged part has no own chapter info.

Is it possible to get an option to merge with ignoring all chapter info and/or to set an chapter entry on each beginning of the to be merged parts?! :)

[Suiryc]

Originally posted by AmiRage
... although there are some very short higher CPU load peaks, but it works really great.
It is normal there are some CPU (or memory) load peaks. At certain times during processing I store "some" information in memory, and there is a time when I need to free this memory (=> CPU load peak / for example between "first pass" and "second pass").
Then there are certain times (when I am to create a new file or to open the input file) when I need to allocate a big buffer (8MB) and fill it (=> memory peak / CPU load peak too) :)

New topic: OGMerger! :D
:scared:
If I correct the bug concerning chapters will this be enough ? :D

[AmiRage]

Originally posted by Suiryc
:scared:
If I correct the bug concerning chapters will this be enough ? :D For today it's enough, thanks! :cool:

BTW ... how about renumbering of present chapters on merge? :D

Update: Any idea why Windows Media Player 6.4 closes itself on a former cut when playing a merged OGM with OggDS 0.9.9.5 while this works with 0.9.9.4?

I'd really like to use OGM, but there are still a lot of problems for me. :confused:

[Suiryc]

@AmiRage
I corrected some bugs in OGMerger concerning comments merging. Should work better now :)
No idea why there are problems WMPalyer 6.4 ... Does it also happen with other players ?
(Will see if I do not write "bad" things with the merger ....)

I now updated OGMuxer (and re-updated OGMCutter :) ) concerning cutting subtitles that lasts too much time (or where there is too much time between two subtitles). I hope I didn't screw up anything :rolleyes:

[AmiRage]

Originally posted by Suiryc
@AmiRage
I corrected some bugs in OGMerger concerning comments merging. Should work better now :)
No idea why there are problems WMPalyer 6.4 ... Does it also happen with other players ?
(Will see if I do not write "bad" things with the merger ....)
Other players more or less play the OGM, but BSPlayer crashes on exit (unhandled exception) and ZoomPlayer crashes too on exit (access violation in ntdll.dll and afterwards an endless loop of access violations in OggDS.dll). And this also happens with my original OGMs muxed with OGMuxer (... and as "always" no such problems when using 0.9.9.4 so far).

I don't think that it's your (tools') fault.

When reporting problems in the appropriate thread noone seems to care at all or the players are blamed. I'll try your newest version (Thanks!!) and when still having problems I'll most likely cancel my further experiments with OGM for now.

[AmiRage]

The chapter integration now works with your latest release version when the first input file has no chapters! Thanks!

"Warnning in Packetizer::process_buffer_packet (Packetizer.cpp) @ 447 : Trying to process buffered Packet while there is no Packet in buffer!"

... is this anything to worry about?

[Suiryc]

Originally posted by AmiRage
"Warning in Packetizer::process_buffer_packet (Packetizer.cpp) @ 447 : Trying to process buffered Packet while there is no Packet in buffer!"

... is this anything to worry about?
For me yes ;). This warning tell me there is something I did wrong ...
For you this should not mean big problem.

[meleth]

Hey,

Could this ( http://forum.doom9.org/showthread.php?s=&threadid=36847 ) be a problem cause my ogmuxer? Or is it related to the subtitle filter?

[Suiryc]

This recall me a bug that occured at the beginning (before I released it) with OGMuxer, but that I fixed a long time ago (before I released the first version).

This also recalled me another thread (see my answer to your post) where it seems there was a problem of SubtiDS not properly installed, and maybe a conflict with DVobSub.

[Apfelstruhdl]

Just tried the tools. Great work. Especially the kframe accurate cutting option.

but would it be possible to add to oginfo all tags that have been set for a stream??

[Suiryc]

Originally posted by Apfelstruhdl
Just tried the tools. Great work. Especially the kframe accurate cutting option.

but would it be possible to add to oginfo all tags that have been set for a stream??
You mean the comments for the stream (like "TITLE=...", "LANGUAGE=...", ...)? To saw them just use the -v3 option in command line. (the comments should be part of the second Packet in the stream).

[Apfelstruhdl]

k
but could you add them also at the end in the info section.
as i like to use oginfo without any v option as i can't do anything with the first info :rolleyes: and with v3 th log will be very long afaik

[Suiryc]

Luckily everything was already in place to print the comments in the info section :).
OGMInfo 1.3b2 is on the site.

[Apfelstruhdl]

thx

really fast reaction on wishes of customers :D :D :D

every company should do it like that

[Suiryc]

v1.1a1 of OGMuxer is online.
What's new :
- uses a basic XML-like parser to read the setup file
- this allows the use of another type (with more options) of setup file (see OGMuxer.txt and Setup-New.omx).
- with this new setup file you can force the type of a file
- apply an offset (like in VDub)
- and add your own comments

[Selur]

@Suiryc: Could u please add the "Strg+Alt+J" feature from nanDub into VirtualDubMod? (u enter a size in MB and nanDub jumps to the next keyframe which lies under your size limit)

Cu Selur

Ps.: I love your tools!! Great work man!!

[Suiryc]

Originally posted by Selur
@Suiryc: Could u please add the "Strg+Alt+J" feature from nanDub into VirtualDubMod? (u enter a size in MB and nanDub jumps to the next keyframe which lies under your size limit)
It will be in the next release.
Next time could you use the "tracker -> feature request" section on SourceForge page please ? This way it may be easier for us to keep a trace of what people wants :D

Thanks :)

[Selur]

"It will be in the next release."
Cool, thx!!

"Next time could you use the "tracker -> feature request" section on SourceForge page please ?"
Sure,.. hadn't seen it before, but will use it next time, promised :)

Cu Selur

[Palikrovol]

Originally posted by Suiryc
v1.1a1 of OGMuxer is online.
What's new :
- uses a basic XML-like parser to read the setup file
- this allows the use of another type (with more options) of setup file (see OGMuxer.txt and Setup-New.omx).
- with this new setup file you can force the type of a file
- apply an offset (like in VDub)
- and add your own comments

Hi.

I'm trying to mux a video and three audios with OGMuxer and aply a -3200ms delay to the third ogg audio, but in the final ogm there is no delay.

My setup.omx is:


<input file="C:\Tmp\_DVD_\eXistenZ.avi">
<comment name="TITLE">eXisteZ</comment>
<comment name="DIRECTOR">David Cronenberg</comment>
<comment name="YEAR">1999</comment>
<comment name="FPS">25</comment>
</input>

<input file="C:\Tmp\_DVD_\t01 (0db center downmix).ogg">
<comment name="LANGUAGE">English</comment>
</input>

<input file="C:\Tmp\_DVD_\t02 (0db center downmix).ogg">
<comment name="LANGUAGE">Español</comment>
</input>

<input file="C:\Tmp\_DVD_\eXistenZ-divX-deutsch.ogg" delay="-3200">
<comment name="LANGUAGE">Deutsch</comment>
</input>

<output file="f:\eXistenZ.ogm">
<title>eXistenZ</title>
</output>


Is it correct?

Or is that the delay is not yet implemented? I have read that there are some problems with delays.

[Suiryc]

My error :(

I made a last change in the code but already had written the file ... so in fact you have to use offset="-3200" instead of delay="-3200" ^^'

PS : beware you wrote eXisteZ (not ExistenZ) for the title ;)

[Palikrovol]

Originally posted by Suiryc
My error :(

I made a last change in the code but already had written the file ... so in fact you have to use offset="-3200" instead of delay="-3200" ^^'

PS : beware you wrote eXisteZ (not ExistenZ) for the title ;)

OK, now it works, thanks (and good work)

btw, the title of the movie is 'eXistenZ' (David Cronenberg), but thanks anyway :)

[Suiryc]

btw, the title of the movie is 'eXistenZ' (David Cronenberg), but thanks anyway :) [/B]
lol that's what I said, and I warned you that in the .omx file you used eXisteZ as title (instead of eXistenZ)

[Palikrovol]

Originally posted by Suiryc
lol that's what I said, and I warned you that in the .omx file you used eXisteZ as title (instead of eXistenZ)

OK :D
I thought you mean the X and Z :)

[Suiryc]

Latest release of OGMuxer (1.1a2) allow stream discarding in AVI/OGM files (except the video stream in the AVI file).
Usefull when you only want to get the video stream of the AVI :)

[Loul]

After loosing so much time to get how to mux vbr mp3 into ogm files I finnally got it that Ogmux couldn't do it and won't do it as the developper doesn't want to implement that function.

Then I got that Suiryc developped that great Ogmuxer tool.

So far it seems to work great... except that it doesn't seem to allow you to tag the different streams especially the audio ones.

For instance when I mux a non audio avi with 2 vbr mp3 streams, I end up with a working ogm file but when you clik on the usual icon in the taskbar to swap between audio streams you got those named 1, 2 (etc.).

I'd like to have then named English and French (for instance) but the tagging option doesn't seem to exist in Ogmuxer, am I right ?

And if so would it be possible to add those simple functions ?

After doing some more searches it seems that you could tag existing ogm files with virtualdubmod (any other mean available ?).

Strangely when I load Ogmuxer muxed files in virtualdub no sound is playing even you can see that the two audio streams exist by using the Ogm information & Show inputs command in the menus.
Audio comments and Audio comments 2 menus are greyed ...

Again is it normal ? Am I doing something wrong ?

Is it today possible to have vbr mp3 muxed with TAGGED audio streams ?
By what means ?

Many thanks, I'm drowning under so many Doom9 threads. I'm going to have an aspirin :'(

[Manao]

You should read the setup-new.omx ( it is a text file ) which comes with the last version of ogmuxer. It allows all kind of tags. But if you want a more friendly interface, use VirtualDubMod

For VDubMod, it can't play sound. If the ogm file plays fine with a player, there is no problem.

For tagged mp3, it is possible : you put themt in ogm, with VDubMod or ogmuxer, and you tag them

[Loul]

Thanks for your indication Manao.

Ok it's in that omx file (well I wouldn't have guessed it), it's far from crystal clear for me but the example that can be found on page 11 of this thread is much clearer.

Anyway I finally got how to do it in VdubMod, so that's great :-).

Now it's time for me to risk to face the moderator's wrath but I feel that following the evolution of the different projects discussed in doom9 through the search engine is quite difficult especially for non developpers (you end up browsing numerous endless and complicated threads from their start in search of a simple answer).

It would be SO good if there would be a monthly summary could made for each big project.

For instance I can't get it if anybody succeeded in achieving muxing 5.1 ogg streams into ogm files and having them playback well.

I found some threads on the subject but they are long and old.

#doom9 is great but much people there are much more into dvd-r and don't know much about new a/V formats.
#pcdvd and #divx-rippers are not very talkative (to say the least).

So well don't be to rude with people trying to get up to date :-)

Anyway, I'd like to thanks everybody, and long life to doom9 !

[inoteb]

Originally posted by Loul
For instance I can't get it if anybody succeeded in achieving muxing 5.1 ogg streams into ogm files and having them playback well.
As far as I'm concerned, it's been a while I gave up the idea of muxing AC3 5.1 in OggMedia container : too much attempts... and nothing really satisfactory.
Now I'm waiting patiently for Matroska :p

[_TAG_]

[i've read the readme.txt and this thread, but found no answer; so if it's an easy one, sorry...]

i'm about to do my first 2cd rip into .ogm, so i have one big file; when i cut the movie, will the subtitles work right or will i need to split them with an external tool and then mux them?

[Manao]

It will work, but you have to use the last version of ogmcutter ( or vdubmod ).

[JimiK]

I'm quite sure it will split the subs correctly. This is really a great set of programms. If I does not, you can still use VirtualDubMod to split your OGMs. It will split the subs correctly for sure.
Best regards,
JimiK
Edit: O.K. Manao, you win, and it didn't even take me five minutes to answer. ;)

[_TAG_]

a huge thanks to all... the fastest response time in history...
if ASUS had this customer care responsiveness they'd be a real company... :D

[Beave]

I actually wrote an email to ASUS in July 2001, they replied in December 2002...

Sorry of topic, but somehow fitted here.

[Suiryc]

^^
OK since some people bugged me those last weeks :p I released a new version of OGMuxer (1.1a4).
What's new :
Version 1.1a4
- added DTS as new possible input
Nb : you need the Intervideo Audio decoder (with DTS support) and a 'AVI<->AC3/DTS'
filter to be able to play the generated OGM file with the DTS track.
You need a valid DTS track. Be warned that vStrip doesn't seem to correctly demux
DTS tracks from VOB files (and thus those files won't be muxed correctly). VOBRator
seems OK. Didn't tested with other programs (e.g. SmartRipper or DVDDecrypter).
DTS tracks using a 14 bits format aren't supported.
I only had short (sample) DTS files to test this and it seemed OK. So use at your
own risks and don't expect it to work flawlessly each time.
As you can see you should be able to play a bit with DTS.


Have fun

[curna]

Well, I was using OGMerger yesterday and I can confirm there is a bug with subtitles when merging.

I first create one 1400 MB file, with chapters and subs. Then I divided it using virtualdubmod in two 700 MB files. However, I had to merge those two parts once again.

My problem is that in the merged file, the subs where only those from the second file and where displayed during the first part.


P.S: Thanks for the tools, Suiryc

[mosky7]

very nice