OGM is not dead - oggds now in xiph CVS

[pirata]

COMPETITION vs COLLABORATION

I don't think competition is good in the free source world. It is indeed good in the closed-source, but that's outside this forum.

I am one of those just waiting for the new matroska features to be added. I don't know about you, but I still cannot mux several, different audio streams in a mkv file. There are no chapters at all. And on top of that, I see people saying competition will be good. What will competition do? Shall it lead the devs to squeeze even more work hours out of their precious spare time? Will it force them to sleep less to do more? Don't think so. I rather think they already do all they can.

I do not agree with those who celebrate seeing the developer community going divided again, pushing 2 different containers, both of them still unable to do completely what we want. Both of them having a long way before they fulfill our needs.

The advent of Matroska had brought developers together. Some of them creating the perfect editor, others developing the best player, and others working hard on the directshow filters. We all have waited a long time to see this happen. We all hoped more and more manpower would join them, so that things would become speedier. That's the nice way about free source code.

Now, other people, who really seem to have spare time to do some nice coding, decide they want to create their own container. Maybe they like specially how OGM and OGG were conceived, and do not like the way matroska was. Or maybe they do it just for kicks. Either way, it is precious coding power that goes through the window. Again.

Hey people, why don't we create our own Linux? I vote for the new name: Xunil!

[defeatist]

I agree with pirata. I humbly request that the Matroska team maintain focus on their goal of entirely replacing AVI with MKV, a goal which OGM never could and IMHO never can attain. I even more humbly request the same focus of the community.

For as long as OGM has been available I have tried to avoid AVI in its favor. My primary reason for doing so has been my preference for OggVorbis, which I consider far superior to MP3. In addition of crouse is the fact that OGM's features far surpass those of AVI. In these ways I have been biased towards OGM. However, I cannot deny the inexplicable problems I have had with OGM in almost every scenario. EVERY OGM I have muxed and played has displayed the following general problems:

1) Loss of position when changing playback speed in any player
2) Loss of all frames until next keyframe when CPU usage peaks
3) Heavy jitter when background tasks use x CPU % (x is always greater for AVI & MKV)
4) Inability to seek to any non-keyframe in a reasonable time

More specifically, my results with AC3 in OGM have been uniformly horrible. I experience seemingly random sync (i.e. a/v sync fluctuates unpredictably) during playback. I do not experience this problem with the same XVID/AC3 tracks in MKV or AVI. I realize some have had better results, but that very fact displays OGM's greatest problem: its unpredictability of performance on any given system.

I realize all of the above problems can be attributed to the DirectShow filters and not the container itself. However, all the versions I have used display the same problems, and I doubt any forthcoming filters (if they ever appear) will solve them. It is my poorly educated but fairly experienced suspicion that OGM is, by its very nature and specifications, unsuited for audio-video containment.

The OGG container that Tobias modified was not designed to hold video data. As far as I know, OGM is essentially a hack (admittedly an educated, clean, and legal one) of an audio-oriented container. It's very foundation contradicts its application via OGM. Furthermore, Tobias never intended its widespread usage (and it's arguable that such usage does not exist).

Matroska, on the other hand, was conceived and has been designed to be THE replacement for AVI, which remains in usage by the vast majority of encoders. Its foundation is equal to its application. Its form fits its function.

I used to believe AVI was still prefered mostly because of ignorance of OGM's existance and of OggVorbis' superiority to MP3. Now, however, I suspect otherwise. Perhaps AVI prevails because its more educated users have found that OGM's weaknesses (eg. lack of predictability, support, development, and future-proofing) overcome its advantages (eg. support of chapters, oggtags, OggVorbis, streaming, multiple audio tracks). Obviously OGM has been used almost exclusively for dual-audio encodes because AVI cannot do so without a hack. Mode2-form2 burning is a similar scenario.

{suddenly I'm extremely famished.... [insert more subversion, er, _arguments_ here!]}

My overall point is that OGM has been a good temporary solution for AVI's shortcomings, but it will soon be completely replaced by a much more appropriate and future-proof container, Matroska. I believe it is in our best interests to focus our usage and support on one container. I'm simply too hungry to explain why.

Please forgive the poor construction of this argument and respond as if it were coherent. Thank you so much for your time! :)

[robUx4]

Thanx for these 2 tempered posts (very rare recently). I'm glad you both got the ideas behind matroska : make people work together, give the user what they need, replace other existing containers by keeping the advantage of each (AVI, VOB, MP4, OGM, RM, AAF and others).

Historically OGM has been here before matroska and thus already have a instaled based, some people who know well about it, etc. I don't think it will ever die. AFAIK, it was created to serve Tobias' personal needs. So I guess he'll keep on using it anyway, as for other people.

What will competition bring ? More knowledge in the basket. Each advance on one side can benefit to the other side (like all the framing of RealMedia files that Gabest reverse-engineered can be put in OGM too). And it's also stimulating for the devs (including myself). So you'll probably get things sooner that ETA and it should be better than "the competitor". Otherwise it's not worth it... On the other hand OGM and matroska are not built the same, they don't share the same foundations. One is designed for streaming (and only that), the other is designed for editability (?). We tried our best to make matroska as streamable as possible, while OGM has probably received the same treatment for editability. I personally think we did a better job of catching up and that's why I have always been confident about matroska's future, even before any code existed (which seemed to piss down-to-earth people at Xiph).

So let the real competition begin and we'll see who wins in the end (much bigger user base). It's not always the best technical solution that wins. So everything is possible.

[Koepi]

Ok, dunno where to start.

you convinced me.

I give up.

no ogm ever again.

use matroska.

it is sooooo much better and leaves no right for another format.

EDIT: just in case you didn't notice, this is sarcastic. Of course I don't give up but will help to make OGM even more usable as it is already!

[bb]

I use OGM. I don't use Matroska (at least not yet). Why?

Because OGM works great. And it has been available long before any other container format that could support Ogg Vorbis.

I will continue using OGM. And I hope development will continue.

bb

[robUx4]

Koepi, plz don't make things so black & white. Of course you're not going to have me tell you (or anyone else) that matroska doesn't compare so well to OGM (or anything else) because I worked to make it the "best possible" and think I (we) made it. On a technical side, I think all people that has worked on both OGM and matroska think the same (they'll say it themselves and probably not in this thread). But I still hope for you and the OGM community that you keep on improving it/fixing it. I also hope you'll find one or more developpers that know about containers and DirectShow to work on the filter. Don't count on Xiph for that...

After all, if we can convince people to leave AVI and use more modern alternatives (smaller, more reliable, more versatile, etc), we'll both win !

Edit: Now I think we've enough talked about matroska in this thread. I hope it will be the last instance...

[Nic]

Hmmmm, I do think OGM still deserves its place. From day one, it became popular and very easy to use. It had more of an impact than matroska has now. Im very glad the sources have been released, the fact they weren't is what stopped me using OGM.

I think instead of comparing matroska and OGM now though, this thread should just be about OGM. And what people deem to need fixing and adding, starting off with the small things and then getting to the big important ones.

So lets have no more comparing and instead use this thread to try and improve OGM. Because discussing the pros and cons will only inflame people.

Sound fair? :)

-Nic

[Koepi]

I'll try to collect a todo-list now.

OggDS:
- Muxing of audio formats: AC3, AAC (already ok - needs a splitter filter though [or must be a headerless file -> AACMachine can do that] more or less fixes for OggMux necessary), MP+, FLAC, RealVideo/Audio
- Support for additional subtitle formats and overlapping timecodes (more than one person speaking): SSA/ASS and coming USF (see SubDS filter's todo-list)
- charset should be UTF-8 (SRT doesn't accept UTF-8. This should be unified)
- Chapters: The chapter seeking algo seems to be of by one.
- Support for Vorbisgain tags ( -> LWIN_GAIN as well)
- Add support for IAMMediaContent interface to pass some tags like "TITLE" a.s.o. to the player
- Fix the tray icon to show also the title instead of "Ogg DSF"
- Fix some problems with tray icon, which cause some players to crash when closeing
- Fix vorbis.dll (the project on the Xiph CVS has an error, which results in vorbisenc to be compiled in vorbis.dll and to get an unusual big size)
- Add support for 639-2 codes in the language tag. The corresponding LCID is then reported to the player. ( E.g. English[eng] )
- Variable Framerate support
- (planned by Tobias: multilanguage chapter names - corresponding to the audio language choosen)

SubDS:
- <font> tags in SRT(not only color, but fontsize etc)
- positioning like ASS's {\an}
- "subs collisions" so that 2+ ppl can speak at the same time in the movie (today's OGM don't accept SRTs which include overlapped data in timeline)
- UTF-8 support; without which, OGM has no future about i18n/m17n. Many minor languages don't have their proper code pages, but have all Code Points needed scattered in Unicode table. For example, I happened to get a script in Tatar (a minor language spoken in a part of Russia), and was disappointed to find I can't put Tatar subs as SRT in today's OGM no matter what. (Hence I softsubbed in Tatar using another format.)
- SSA/ASS and coming USF

Keep suggestions coming, this is a first version of a todo-list only. I'll try to keep it updated - or maybe I'll start a new, clean thread where no strange comments are going to be made [I'd delete them there] ;)

Regards
Koepi

[b]EDIT: cleaned up the todo-lists a little.

[Nic]

"Fixed some problems with tray icon..."
Are the things that you've prefixed with "fixed", are they things you've just fixed. Or things that need fixing? :)

[DAvenger]

Originally posted by Nic
"Fixed some problems with tray icon..."
Are the things that you've prefixed with "fixed", are they things you've just fixed. Or things that need fixing? :)

:D

It's a changelog from 0.9.9.5 while the released source is only 0.9.9.3 :( So it is necessary to do these things once again :eek:

[bond]

Originally posted by Koepi
- AAC (already ok - needs a splitter filter though [or must be a headerless file -> AACMachine can do that])perhaps someone should talk to the mpeg4ip guys to add a "mp4/aac -> aac headerless" option to mp4creator, that would surely help...

- Variable Framerate supportgreat ;)

i for my side will support both containers as much as i can during development
(up to now i would choose matroska because it has smaller overheads and doesnt seem to be like an not officially supported (by xiph) hack. sorry, but this opinion can change of course)

very important for me will also be how well the containers will support xcd (error correction etc.)!

[hans-jürgen]

Originally posted by bond
perhaps someone should talk to the mpeg4ip guys to add a "mp4/aac -> aac headerless" option to mp4creator, that would surely help... faac.exe -r (see the help screen or the Wiki page for more)

[bond]

Originally posted by hans-jürgen
faac.exe -r (see the help screen or the Wiki page for more)ok, this is possible when someone encodes with faac or aacmachine but what about nero, quicktime, sorenson, etc... and what if someone doesnt encode the files by himself (for example buys them on itunes)?

a switch in mp4creator would solve all that issues...

[Koepi]

You can buy the sound of an already encoded movie on itunes or somewhere else? Now you got me, I didn't know that ;)

Let's please stay realistic: OGM is meant to be a container for something you encode yourself. So you have the choice of your encoding tools. AACMachine and faac support the necessary output (which I btw. didn't verify myself excessive btw., if someone with a dshow aac decoder could check that as well it would be nice).
In that case I don't see the problem to use the tool that delivers what you need. Specialy since those tools are freeware.

I'll clean up the todo-list in some minutes so it doesn't look like I'm already working on anything - it's unlikely that I code (much) for OggDS since I don't have the time like I had a year ago :(

Regards
Koepi

[bond]

Originally posted by Koepi
Let's please stay realistic: OGM is meant to be a container for something you encode yourself.encoding a soundtrack in quicktime or nero is VERY realistic (even more realistic than encoding with aacmachine or faac because of better quality (with or without sbr) and better multichannel support is coming for quicktime, available in nero (broken in aacmachine))

but nobody has to use .ogm ;)

EDIT1 : why not putting itunes downloaded music together with a selfmade clip into .ogm? that's not unrealistic although not widely done i guess

EDIT2: all we need is a mp4creator version that outputs headerless aacs, that's not much ;)

[Koepi]

Originally posted by bond
but nobody has to use .ogm ;)

I won't force you or anyone to use it. It's your choice. It's all about choices.

I didn't realize that nero's plugin delivers amazing quality. Maybe we need a tool to simply strip off the headers as pre-processing step. It would be possible to use within OggMux (like the delay-code). Or now with the OggDS sources, accept that kind of input directly and strip the headers there. But we need information about the file format for that. Damn. So much work for a single audio format.

But anyways, it's on the todo list. And that's not because I like joking, I think the list is realistic.

Koepi

[bond]

Originally posted by Koepi
I didn't realize that nero's plugin delivers amazing quality.according to rjamorim's last listening test @128 (results here (http://rarewares.hydrogenaudio.org/test/aac128test/results.html)) quicktime performed best, followed by nero, sorenson and aacmachine (these 3 were equal), faac was by far the worst (i wouldnt recommend using it at the moment.

and nero will support sbr technology in nero6 (will be released on 18 july) and for the next version of quicktime it is planned to inlcude multichannel encoding

Maybe we need a tool to simply strip off the headers as pre-processing step.that's what i am talking about all the time ;)
mp4creator (from mpeg4ip) now can already convert aac <-> mp4 and add different headers to the files (mpeg-2 oder 4), there just has to be a "remove header" function added

[Koepi]

Ah ok, sorry, then I misunderstood you. My apologies.

(I finally downloaded the OggDS sources from Xiph's CVS btw ;) they're really tiny...)

Regards
Koepi

[bond]

so the only big issue is to find someone who wants to continue tobis' work?

koepi, if you are willing to code a little bit perhaps it would be good if you want to open a sourceforge project as a start?

[outlyer]

any chance to add graphic subtitles to the todo list? png based subtitles would be nice, not huge and would save ocr for the lazy ones :D

[kxy]

SubtitDS will not work with b-frame.

[Animaniac]

In terms of subtitles, I'd really like to see Gabest's subtitle source filters used instead. I've had nothing but problems with SubTitDS which manages to always load itself on playback, and in turn conflict with VSFilter. SubTitDS also does not support YV12 and always converts it to YUV2. VSFilter can handle OGM subs without SubTitDS, so it would really be great to continue with Gabest's subtitle tools and just upgrade the mu'xer and the splitter. I'd also like to see the splitter to loose the stream switching, since it's what's preventing different audio streams using different channels/bits/frequency. Most modern players (read: MPC) have their own audio switching and OggDS's switching tends to conflict with such systems. Furthermore built-in stream switching goes against the DirectShow model of autonoumous filters that focus on one task. Another bug is that MatrixMixer does not link up with 6 channel outputs, only 2 channel outputs.

[Hiro2k]

Originally posted by outlyer
any chance to add graphic subtitles to the todo list? png based subtitles would be nice, not huge and would save ocr for the lazy ones :D

Or for those really messy subs that ask you in each sentence what a character is! *points at Eva!*

[Atamido]

A particular team of people were talking about using image subs, and one of the issues that came up was amount of processor usage required to decode an image. PNG take ALOT of processor time to decode. The result of using them for subtitles in video would likely result in a jerk in the video everytime a new subtitle needed to be displayed.

Mosu decided to try and use the original sub images and lightly compress them so that they took up less space. Decoding these takes very little, and so is good for video playback. You may want to look into the same thing for OGM.
Edit: I typed the wrong compression type originally. :(

[Nic]

One of the guys I worked with did the OGM support for VideoLan so ill see if I can rope him in. Ill take a look at the sources as well (although I know nothing about subtitles, so im not sure if i'd be much help there)

(recently split with my gf, so ive got so much time free now ;) )

-Nic

ps
For those who fear CVS but still want to look at the source to see how they could help:
http://nic.dnsalias.com/OggDS_src.zip

[outlyer]

Originally posted by Animaniac
In terms of subtitles, I'd really like to see Gabest's subtitle source filters used instead.
I agree, Gabest's are a much better option now.

[Koepi]

Unfortunately I'm not yet able to build that project, the .vcproj files are giving me a minor headache... ;)

We should support the mux'ing of subtitles from within the OggMuxer I'd say. As palyback filter there msot times gabest's filters are used - and the SubTitDS files aren't in the CVS anyways ;)

Regards
Koepi

[Animaniac]

Originally posted by Koepi
Unfortunately I'm not yet able to build that project, the .vcproj files are giving me a minor headache... ;)

We should support the mux'ing of subtitles from within the OggMuxer I'd say. As palyback filter there msot times gabest's filters are used - and the SubTitDS files aren't in the CVS anyways ;)

Regards
Koepi

Last I used OggMux, it required SubTitDS. Is that dependency still there?

Another additon to the list, the Ogg splitter should handle FLAC in Ogg so that it is compatible with CoreFLAC when it becomes availible.

Edit: Icecast support for Vorbis Streaming would also be nice.

[bond]

it would be also great to make the splitter compatible with corevorbis (dont know why it doesnt work now :confused: )

[Nic]

It doesn't work now (I think); Mainly because the corevorbis guys changed the GUID. I think the Ogg Splitter sends its first few packets of data to the vorbis decoder to set the decoder up. Which is a little bit of a hack. So I think your right; CoreVorbis and CoreAAC are on the menu ;)

-Nic

[DaveEL]

Originally posted by outlyer
any chance to add graphic subtitles to the todo list? png based subtitles would be nice, not huge and would save ocr for the lazy ones :D

Prehaps its best to keep with the xiph recomendations of MNG overlays in ogg for ogm http://wiki.xiph.org/MNGOverlay ?

DaveEL

[Belgabor]

Um, I might be wrong, but isnt mng png with animation features? Will that save any processor power?!?

[outlyer]

Um, I might be wrong, but isnt mng png with animation features?It is.

Will that save any processor power?!?I don't believe so; BTW I wonder if using PNG with a compression level 5, for example, would eat much resources.

[Nic]

http://nic.dnsalias.com/OggDSsrc_VC6.zip

Contains the source but with VC6 project files instead of .net ones. This should make it more accessible. You may need the Ogg SDK, Platform SDK and/or the DirectX 9 SDK to compile it.

I'm sure me and Koepi will keep you posted on developments :)

-Nic

[el00343]

Originally posted by Nic
http://nic.dnsalias.com/OggDSsrc_VC6.zip

Contains the source but with VC6 project files instead of .net ones. This should make it more accessible. You may need the Ogg SDK, Platform SDK and/or the DirectX 9 SDK to compile it.

I'm sure me and Koepi will keep you posted on developments :)

-Nic

Keep up the good work guys.The community will have a lot to thank you for.

[kilg0r3]

Since mkv currently has not that good error skipping capabilities, I#d be glad if ogm could be extended in a way as to carry rv9 video streams.

[bond]

Originally posted by Nic
I'm sure me and Koepi will keep you posted on developments :)so you both will work on .ogm?
would be great :)

[Nic]

Hopefully...although I know Koepi's busy. At present im just finishing off AAC support to Cyrius' OGMuxer.

-Nic

ps
LoL...Finished that. Now going to make OGMuxer into a nice DLL, then make a nice GUI to it. Thats part one I wanted done (Hope Cyrius doesn't mind, my coding style is disimilar to his...not sure if he'd want it merged back in with his source)

[bond]

great to hear that :)

[RadicalEd]

Originally posted by outlyer
It is.

Jasc has .mng labeled as "Animation Shop Animation". It would make sense if they were really just using animated png, but I wonder if they're the same format or not :\
I guess it's likely. Still animated png would be more appropriate than making it sound like a proprietary format.

[h9903209]

thx for everyone who is willing to continue development in ogm, as lots of encode nowadays use ogm, seems impossible to convert all to mkv again... and for oggDS todo list, I really want to improve the speed of searching to any non-keyframe.

If I uncheck "search to keyframe" in oggDS, it takes so much time to jump e.g. 5 seconds. Usually when I review anime which I already watch once, I would always jump in 2 or 5 seconds, but in oggDS the jump takes soooooo long! While if I check "search to keyframe", the jump would become unstable though fast, sometimes jump for >10 seconds even I just want to jump 2 seconds...

[zulu]

LoL...Finished that. Now going to make OGMuxer into a nice DLL, then make a nice GUI to it. Thats part one I wanted done (Hope Cyrius doesn't mind, my coding style is disimilar to his...not sure if he'd want it merged back in with his source)

Nooooooo! :eek:
Uhhmm...this is _exactly_ what i am working on atm.
Anyway, competition doesn't hurt... :D


zulu

[unmei]

originally posted by h9903209
seems impossible to convert all to mkv again

:D i dont think the idea is to convert the old files to new format. neither avi->ogm nor avi->mkv nor ogm<->mkv.
The only reason to do this would be if the old avis have desync issues or dont play anymore (like you had windoze, and now have linux and dont want to keep avi support).
IMHO the new containers are here to extend the possibilities for new encodes, not to repack your old collection (w00, i would hate that - copying tons of cds to harddrive, repack, burn again *shudder*)

[Nic]

@zulu: good! :) Its not competition is more choice for the user :)

@all: Does the OggDS Vorbis decoder work well? I could change it to work with CoreVorbis easily, but im not sure if its worth doing and possibly breaking something for someone else.

Any other bugs worth mentioning?

Cheers,
-Nic

[bond]

vorbis decoder seems to work but enabling the use of corevorbis (or any other decoder to come) would be great (it's all about choices ;) )

hm what about splitting the oggds.dll into 4 different files (decoder, encoder, splitter, muxer) dont know if this causes much work?

[Nic]

Hmmm. The way the Ogg Splitter does Vorbis initialisation now isn't good and not compatible with CoreVorbis. Does the normal tobias filter support multichannel well? I dont want to break anything by chance if there is no advantage...

I like the OggDS.DLL being one file. Makes it very complete and simple, almost tempted to put a version of CoreAAC in there as well ;)
(Splitting it to seperate files would be very easy....whats other peoples opinion. I want to keep things as straight forward as possible)

-Nic

[Animaniac]

I'd really like to see the CoreVorbis be used in place of the OggDS Vorbis decoder. I'd also like to see the switcher turned into a separate filter and/or the "enable all streams" option to work correctly, since it breaks consistency when used with audio switching filter in MPC. I really think the separate filter route is better since users can have greater choice.

Edit: Would it be possible to "fix" the Ogg demu'xer to work with CoreVorbis? I've had trouble with multichannel using the OggDS Vorbis filter. This filter also doesn't like linking with Matrix Mixer for 6 channel streams, but likes linking with 2 channel streams for some odd reason.

[Suiryc]

Originally posted by Nic
Hopefully...although I know Koepi's busy. At present im just finishing off AAC support to Cyrius' OGMuxer.

-Nic

ps
LoL...Finished that. Now going to make OGMuxer into a nice DLL, then make a nice GUI to it. Thats part one I wanted done (Hope Cyrius doesn't mind, my coding style is disimilar to his...not sure if he'd want it merged back in with his source)
lol
You are welcomed.

I don't really have a coding style (that was my first real program ... and I picked some coding things here and there ... and I have to admit some parts are really crappy ^^;).

I know making a DLL out of it may interest some people here (and the GUI too).
Some times ago I wanted to turn it into a set of DLLs that could be used to mux and/or split more easily but I had a lot of work on VirtualDubMod so I gave up.

[Nic]

Animaniac: thanx, that gives me reason to make it work with corevorbis instead. Ill do that tonight, ill look into the stream switcher

@cyrius: cheers! It works well, I had to make some minor changes (you couldn't add anything after the stream_header passed to the packetizer constructor, etc). Ill release the source probably tomorrow or over the weekend and you can see what Ive done :)

Cheers,
-Nic

[bond]

Originally posted by Animaniac
I really think the separate filter route is better since users can have greater choice.yup that was my thought too because

why installing a specific vorbis decoder if you want to use another one (for what reason ever)
and why installing an vorbis encoder or an ogm muxer filter if you dont really need one?
and if it is possible to split the switcher too i would do so (i am using the morgan one for a long time now)

i know i am no programmer but i think it would be really a good idea to open a "ogm" project on sourceforge (like gabest' guliverkli project) and then release 4 (or 5) different sub-project-files (which then can also be updated independently from the others)

so the files and sources are kept together but every user can choose only what he really needs (and if there are components available from other sources which can do more or better than the one from oggds.dll, there would be no need to work on this specific part just to keep the whole package up-to-date, but to concentrate on the more important other unfinished parts)

but that's just my opinion ;)