XCD: automatic media detection and licensing

[avih]

gawen:

concerning the licenses again.

1. as we all agreed, we're switching the xcd.sf.net account to BSD license (instead of GPL).

2. i did send a support request to sourceforge team already about this issue, but let me post my thoughts here as well:

de_xt tool is based on vcdtools which is GPL, i guess your linux kernel is either GPL or some kind of Debian license. mplayer is GPL mostly (some parts are not GPL).

since we want to include all the tools under a single 'roof' (do we?) how do we license different 'sunprojects' under different licenses? also, the spesification themselves are not code, and i think BSD/GPL/etc doesn't reference them. any idea about what should we do about the specs themselves then?

avi

ps.
'the player shouldn't access the cd' is partially correct. the correct one is NOTHING should access the CD (including the kernel or other applications/scripts/etc).

pps
i've reactivated http://xcd.sf.net

[spyder]

I have completed the first beta of my XCD/CDXA tools for Java. Currently it includes a java version of dat2file and a InputStream class for reading M2F2 files directly within any java app. I will modify the sources of JavaLayer to use this stream and post it here unless there are licensing issues. I hava attached the ZIP file containing the compiled versions along with the source code.

I would like to put these files in the XCD SourceForge CVS. I guess I would have to be a member of the XCD project. How do I sign up? Until XCD matures a little more(gets error info), I will work on possibly MCF in Java.

[avih]

spyder:
gimme some time to set up the account correctly. currently only the initial draft is uploaded.

also, since m2f2 is not XCD (it doesn't have error correction), i prefere not calling all the m2f2 work XCD ok?

i'll let u know when the project starts rolling, and add you as a developer.

avi.

[spyder]

avih:

Thanks. The actual files say nothing of XCD except the Readme says XCD/CDXA I think. I will change it from now on until the XCD spec is finished.

[Gawen]

Belongs on what we want. If i interpret our intentions correctly we all want the best possible availability for the format. So we should put the format specs under the best licence we can give without putting it fully into PD. BSD should be good for it.

On the other hand there is software derived from different sources with different licenses. Well, we should use the best we can without violating the will of the others, wich made software components we reused. And this is no problem if we tell this openly. We should "label" the software components with the best licence we can.

And there is no need to do more. We want the industry to adopt the format. If they like it, they can use the format specs for compatibility and for free. Now its their choice either to say:

- "Ok, there are programs we may use, its no problem for us to put our changes under the same licenses too."

- "Ok, but GPL is not acceptable for us, we will order our coders to do a rewrite, thanks for the examples."
- "Ok, but we dont like GPL and have no coders to rewrite, could you do a rewrite for us, we will hire you for that?"

The last point is the only important one, would we have the capabilities to do a rewrite if someone would like to hire us for that? Its the only "service case". Every other usage would be self service and the only thing that could happen is being asked "How can we do this or that?", "Could you have a look on my implementation and certify it?".

The parts i do are just compiles of existing software, an OS, a Player. As long as i dont change the source i only need to give credits on where they can be found. They all are GPLed. Nobody working in the bizz would ask us to do rewrites of them, because anyone would know it takes a little more workforce and time to do a complete OS.

So what about the other parts? What is in where? We need a matrix we can publish. If nobody can have a misunderstanding, we are not in trouble. We just have to be straight, open, helpful, friendly. Thats all. We are giving a concept for free, including a reference implementation. If we can make someone get $ signs in his eyes with it, we will see.

I am working now for 15 years in the bizz (call me grandpa) and there is nothing i see trouble with yet. We can only get in trouble if there are black holes, trapps that other could tap in. If we tell the truth, beginning with the executive summary and ending with the specs and the attached licences and credits, this can become a widely used format very quick.

[spyder]

I have finished modifying the source for JavaLayer 0.2.0(GPL) to use my CDXA class. It only required that I change two lines, one to import my package and change it from creating a BufferedInputStream to creating a CDXAInputStream.

That's how easy it is to make a Java app read from CDXA now.

To use this read the Readme inside the Jar file or extract the jar file to your classpath and run:

java javazoom.jl.player.jlp [inputFile.dat]

I have attached the compiled version and source in a jar file inside a zip file.

[avig70]

Hello all

Here is a idea I'm playing around with for some time.

Is it possible to make a bootable CD that once you turn the computer on it contains a programm that makes the computer dedicated to playing the movie on the CD.

You could probebly play movies on much older machines once you don't need to run the windows or the linux kernel along with other things that run in the background.

It will need some kind of minimal kernel to interface specific hardware devices but it will be allot less overhead and dedicateto runing the OS and allot more resources to playing the movie

Avi

[Koepi]

AviG,

guess what that BootCD stuff is all about we are writing from?

But thanks for repeating it in some clear, simple words :P

SCNR, :)

best regards,
Koepi

[avig70]

sorry

avig

[Gawen]

@AviG

I am working on that stuff, but dont exspect it to run mpeg-4 files fullscreen on a very old maschine. I use a networkless Kernel 2.4.18 with graphics hardware optimization and multiple ide/scsi disk drivers booting in VESA framebuffer mode and playing than with a statically compiled mplayer. The Kernel is not the limit, the player is not the limit, its limited by zooming mpeg-4 films to fullscreen. These operations are very cpu intensive, so the lower limit at my testfield is actually a coppermine celeron at 800 Mhz. I will try to optimize this, but mpeg decoding has its limits. Thats why STB manufacturers use dedicated high speed DSPs for this job. Another limit is memory bandwidth for the pictures size. 100Mhz buses get filled up very quick when copying the decoded frames to the graphics port at sizes > 640*480. My target is to get it running on a 100$ VIA Eden mainboard (mini size with VIA CIII CPU soldered on board).

[avig70]

Hello again

I have a P-III 550Mhz and it runs the MPEG4 films full screen with no problem on 800X600X32 so I'm not quite shure what you meen.

I've also ran it on P-III 450Mhz and it had a little problem so I guess thats as low as you can go as far as MHz are concerned.

And another thing why is the memory involved ?? arne't you supposed to write directly to the video adaptor ? I probebly didn't understand you.

Avig

[Gawen]

@AviG

I am not going to discuss your hardware and my project here with you. If you want to learn about the limitations of memory buses writing raw data to low level badly supported ports, take out your old HP calculator and calculate the limitations of a 100MHz 32 Bit memory bus transfering mixed datastreams in and audio and video datastreams out to sound hardware and the VESA interface. There will be a prototype in the next days and you are invited to optimize it, i will be happy to apply the speed patches you send me.

Again, thanks a lot for your interest.

Gawen

[Koepi]

Hm, 100MHz x 32 Bit doesn't sound too bad for me as this makes ~400MB/sec possible (100.000.000 x 4 Bytes).
Uncompressed video would need max (assuming 720x576 resolution) ~30MB/sec at 25fps, ~35MB/sec 30fps (once more assuming we have 24bit color depth which isn't necessarily the case with vesa fb, usually you have 16 bit color depth there).

Even if we pull up the resolution to 1024x768x24bit, it would result in ~56.25MB/sec at 25fps respectivly 67.5MB/sec at 30fps.

This doesn't seem to be the bottle neck :)

I just wanted to throw this in, and hell yeah, I know about wait-states and so on ;)

Best regards,
Koepi

[avig70]

@Gawen

Didn't meen to upset you but...

Let me know where to discuss it and I'll go there.

It just seems like you're kernel might be initializing the CPU registers in the wrong way..

Thats all I wanted to say, and I'll be happy to take a look at the code and learn.

Thanks
Avig

[avih]

@avig70

gawen is still working. let him play with it, and whe'n he's minimally satisfied, i'm sure he'll post the work. you'll then be able to tweak it as much as u like. just let the man make some progress first ;)

avi

[Gawen]

@ los dos avis

You may eat me, when the first prototype is ready! *g* I shouldnt post info about pre proto performance probs.

If it had to perform on only one I/O chipset and cpu, say Intel I81x and PIII, it would be easier, but i need DMA on all major chipsets, with PIO access FPS values tend to 5-10 frames/s. I stopped counting the kernel compiles last night and test on 3 PCs with different PCI/IDE bridges in parallel. Wish me luck!

@koepi

You are great in calculating the ideal case where no postprocessing is neccesary. Of cause, then it works. Divide by 2 for IRQ/WS overhead, add some streams for cd reading, resizing, colorspace conversion ... if done by different program units that communicate via memory bus ... , you run into a realtime performance prob. But do i have to explain this to an XviD team member? :sly:

[unplugged]

burning method:

1. load Nero
2. select File/Burn Image
3. load the BIN file (NOT CUE!)
4. select Mode 2
5. burn!

This has been reported to work even on problematic burners, where no other method have been successful.

To remember that this kind of binary CD images need the "famous" capability of RAW writing :) by the CD-R/RW writer unit...

Not much time ago there was been a lot of discussions about old and new burners regarding RAW writing support (entire sector... ECC EDC...), remember the first CloneCD launch era!! :D


about M2F2 interest:
Without discrediting XCD intentions and efforts, I have to add some thoughts derived from the M2F2 spuring concept too:
Why do not *also* consider a simpler "slick" version of XCD specifically oriented to host already-known file-systems (firstly CDFS), this to do a strict container based variant?
Describing the binary, simply a primitive layer with very little ID/Info header and a cluster structure with *only* EDC CRC-check embedded.
Just a quite RAW container to mount inside any needed standard filesystem (layer 2). With unique strategy to read problematic sectors by rereading at lower speeds :o, or simply rereading. (using cluster CRC data as triggering mechanism of course).
Just to have no overhead CDs not difficult to implement (small driver mount-engage filesystem routines), to contain media (stream) content that doesn't require high read speeds (no more than 4x-8x, 600-1200Kb/s) and mostly sequential reads.
You could quickly say that burning such kind of CDs is a jump in the dark... :) but mode 2 form 2 CDs are commonly readed differently by CD-ROM units, at lower speeds of course (more accurately), just after fresh insert.
Make a try with PlayStation CDs (M2F2 too) or Philips Video CDs by inserting these on home PC, typically CD-ROM unit rotation speed is identical as for ISO-CDs (40-50x) but if you test effective burst speeds the unit transfer is pretty close to 12x!!!
In most of cases (talking about CD-ROM units) these CDs are readed more carefully.
In fact, by experience make on fly copy of a M2F2 CD is a PAIN!!! :devil:


--------------------------------
http://www.elby.de
check if you have DAO-RAW or at least SAO-RAW.
Right? :rolleyes:

[avih]

@unplugged:

thanx for the info and ideas.

we already think of read speed control. in fact we're just discussing it few mins ago on irc with matter and dext.

regarding the cd format: we want it as compatible as possible, so we chose the s/vcd paradigm since there are many players that can read such format already (as well as windows and linux). we're always open to new ideas though.

i must say i don't know much about cd formats (dext and koepi know much more than me regarding that). we can discuss different cd formats though if they have advantages.

thx again
avi

[spyder]

Does anyone here know the best way to get GCC working on Windows? I am looking for a version of GCC 2.96 or later(hopefully 3.0) with GCJ for Windows. I want to test my Java code compiled to native code that way. Since all I am using are base classes from JDK 1.3 (should be compatible with 1.1) my programs should work well with it. Maybe I could figure out a way to make a native CDXA MP3 player if I could compile my classes into a DLL and use it from VB(the only other Windows language I am good at).

[spyder]

To anyone who downloaded my modified JavaLayer app there was no manifest in the JAR for it to work correctly without unpacking so here is a fixed version. It works very well.

[Koepi]

@Gawen:

Guess what "I just wanted to throw this in, and hell yeah, I know about wait-states and so on" is supposed to mean.

Please read my mails correctly :P

Regs,
Koepi

[Belgabor]

@spyder
As I gather from the info on the mplayer homepage GCC 2.96 is a buggy RedHat patch to 2.95 and, again from that page, GCC 3.0.X is still buggy, too. So 2.95 would be the best thing to use. (admitted, they mostly worked for me on my linux box, but at least 2.96 has some issues with some progs. If I didnt fear totally messing my system, I'd try to downgrade)

Regards
Belgabor

[blixi]

Hmm I wouldn't trust all what the mplayer team says. I've compiled mplayer with the 2.96 a lot of times without problems...
Since the gcc3.0 is a littlebit older now than a few days there should be no problem. The only thing with the gcc3.0: he is a littlebit more accurate with interpreting ansi-c++, so then you write code that doesn't conform to ansi-c++ the new gcc is bailin out earlier..

blIxi

[nah]

Hello,

I've just update my GUI to use with the Mode2CDMaker 1.2pre from DeXT. I've modified the prg to take in account the source file name (don't know if it will bug the Image created but I've made some test with Deamon and CDRW on ogg, avi, mp3 files, and it seems OK). I've add a fixe entension to the files : .r, just to use corectly with my GUI.
The prgs are on my Web page : http://membres.lycos.fr/zorgzorg

A+

[Belgabor]

@blixi
That seems to depend on the options you use and on architecture. I had several versions or option combos which didnt compile with 2.96 but did with 3.0.2, others didnt compile with either (as I have no 2.95 I cant say if they'd have compiled anyhow though ;))

Regards
Belgabor

[oddball]

The only problem I can see with booting from CD and it auto playing the movie file (I'll assume movies will be it's main use here), is that if you have a TV out card you won't get TV out. You can view on the main monitor and that is all. Might be usefull for laptop users and those who don't pipe to TV though I guess.

[kappa]

Originally posted by oddball
The only problem I can see with booting from CD and it auto playing the movie file (I'll assume movies will be it's main use here), is that if you have a TV out card you won't get TV out. You can view on the main monitor and that is all. Might be usefull for laptop users and those who don't pipe to TV though I guess.

I have an ATI All-in-Wonder 128 Pro for the computer in my living room and it supports TV-out natively (even form the bios-bootup screen). I think all ATI cards behave similarly.

[oddball]

Yes. My Matrox G400 does the same I think with the correct enabling on the video cards BIOS. I think I tend to get probs in the mode booting back into Windows with it switching to 50Hz and having to manually switch it back in display properties from what I remember of trying it before. Not tried with more recent drivers however.

[avig70]

@nah

You have a small bug.

You treat shortcuts as if they were files and you put them in the files pane instead of treating them like folders and to be able to double click on them and go to the directory needed.

Also its not possible ot mark a few files at once and if the filesize is too small then a message box shows up and tells that the file is too small in some language that I don't recognize.

And a few suggestions:

1.) I think you should add some description near the panes themselfs to make the program more intuitive.

2.) Make the folder pane on the left side of the window and the file pane on the right side.

3.) Make a browse botton where ever you want us to find files or folders, I don't meen to impliment a file explorer like you did for the "list of files" but to make a small botton in the end of every line.

I've added a picture to ilustrate the changes. Here is a link ftp://ftp.ecitele.com/pub/Avig/untitled2.jpg

Avi

[DeXT]

For those interested, today I've released the 1.2pre2 version of mode2cdmaker. Still in preview state because I've not added Form1 stuff yet, but you'll find a couple of neat features:

* progress & speed counter
* optional long file names support (ISO-9660 Level 2, though)

Apart from this there are some bugfixes, too (not very important, though) and small XA compatibility improvements.

Thanks to the tests made by MaTTeR tonight, finally one of his DVD drives was able to read Mode2 CDs. I've not included the new format yet since this will require a change in the DSF in order to read it so I'll wait to the next filter release, which avih is working on now.

Oh and about the long filenames feature, to use it just add a -l option to the command line. The file names will be converted to ISO-9660 Level 2 (i.e. all uppercase, and no spaces), and the last file extension will be replaced bythe default M2F2 extension. As an example:

mode2cdmaker "d:\movies\this is my movie.avi" -l

The movie would appear as: THIS_IS_MY_MOVIE.DAT

This is mostly a "play" feature, remember that in XCD it's very likely that only Level 1 file names are being allowed, at least until we add Joliet support.

webs.ono.com/de_xt

(you'll have to wait for the server cache to update)

[nah]

Hi,

I've updated my GUI on the Avig70 advice, but still using 1.2pre from DeXT (with minor modif), because the 1.2Pre2 doesn't want to work with option -l. (I'm looking the code but have no time to fix it)
The prgs are on my Web page : http://membres.lycos.fr/zorgzorg

[DeXT]

Sorry, my mistake. I was doing some modifications related to the Form1 support and I forgot to change something before compiling the release version. This eventually broke up the long filenames support.

I've updated the 1.2pre2 release with the new build, please get the new file, now it all should work as expected.

Sorry again...

[kxy]

Not sure this is a bug, or my mis-understanding of your command line

I did this,
mode2cdmaker.exe -o Spy -m "d:\spy game\spy game.avi" -v Spy_Game -e avi -l Spy_Game

The final output file turn out to be SPY_GAME.SPY_GAME, as you might guessed from the above I want spy_game.avi or "spy game.avi"

[DeXT]

Yes it is a misunderstanding plus a side effect of the way the command line is analysed in mode2cdmaker. Perhaps I did not explain it very well in my previous post.

Yon do not have to put anything after "-l" option. This is a switch and tells the tool to use original, long file names instead of the short 8+3 versions. So the right command line should be:

mode2cdmaker.exe -o Spy -m "d:\spy game\spy game.avi" -v Spy_Game -e avi -l

Then let's analyze why the file extension turned "SPY_GAME". The last used option which takes a parameter is -e, i.e. the default file extension. The tool "remembers" the last option which takes a parameter so you can put several file names after an -m (and eventually -f) option as a separate file. -l is a modifier and do not count as "option" (now I guess I should change this). So it has the same effect as writing "-e AVI Spy_Game", which turns "Spy_Game" the default extension (the AVI one is overriden).

In the next version the tool will just show a command line syntax error in this situation.

Thanks for your report. Your feedback is an invaluable source to help me to make a user-friendly application.

[kxy]

Thanks for your report. Your feedback is an invaluable source to help.
No thank you DeXT, for making such a wonderful tool. :)

In the next version the tool will just show a command line syntax error
What if some wants some weird extension? How about do a preview of the output file. Something like the output file will be "blah blah.extention", would you like to continue?


Another question, with the long name support, does the spacing work? Or can you make the spacing work? In another word,

mode2cdmaker.exe -o Spy -m "d:\spy game\spy game.avi" -v "Spy Game" -e avi -l

output: "spy game.avi"

[DeXT]

Originally posted by kxy

What if some wants some weird extension? How about do a preview of the output file. Something like the output file will be "blah blah.extention", would you like to continue? There is no problem at all with "weird" extensions, as long as the long filenames are enabled. The ISO-9660 allows for up to 30 character extensions. If -l option is not specified the extension will be trimmed to 3 chars (since we must accomodate it for a 8+3 filename).

This preview of the resulting file name is a very good idea. I'll implement it in the next version.

Another question, with the long name support, does the spacing work? Or can you make the spacing work? In another word,

mode2cdmaker.exe -o Spy -m "d:\spy game\spy game.avi" -v "Spy Game" -e avi -l

output: "spy game.avi" If we follow the ISO-9660 recomendations, whitespaces are not allowed. Althought it eventually "works" under windows, the resulting CD will not be standard and will likely not be readable under other operating systems. So at this point my tool will convert any illegal filename into a ISO-9660 filename (named "d-char").

There are two extended CD filesystem formats which could be used, named Romeo and Joliet. The Romeo one is pretty old and no specs are publically available through the Net. Joliet is the most common one but it's somewhat hard to implement. Anyways it's on my "TODO" list.

I have the suspect that Romeo is no more than an "illegal" ISO-9660, i.e. the file names containing lowercase letters, spaces an more than one extension. If that's the case this is pretty easy to implement. I'll try to find some information about this subject.

Beware that, as I already said, none of this will count for the XCD format except probably Joliet.

Thanks for your support.

[jurij]

hi! i need help!
I made a 790MB OGM file and when i play from hd it works, bt after converting to bin a burning i can't make it read from the cd.
The OGM contains divx5 video, 2 vorbis 64kbit audio files and 2 .srt subtitles files.
It is weird because with avi files it worked perfectly.
What can it be?

[avih]

try to use daemon tools to mount the bin image. and then play the file from the virtual cd-rom. if it plays correctly then either the burn itself did something wrong or the cd got damaged (remember there are no error correction). if, however, the file doesn't play from the virtual cd rom then there's probably a conflict with the filter registration. in that case i suggest trying to use graphedit on the file from the virtual cd rom and see if it plays.

to use graphedit do the follows:
1. open graphedit.
2. insert new filter (dshow->RIFF/CDXA source).
3. select the file from the virtual cd-rom in the file dialog that appears.
4. right click on the output pin and select 'render'

if it worked ok you should see few more filters added to the graph, and you'll be able to press 'play' to play the file.

let us know how it worked.

cheers
avi.

[jurij]

the sintax i used was:
mode2cdmaker.exe -o Stargate -m "c:\stargate.ogm" -v Stargate -e ogm -l
i noticed that the ogm file in the cd is bigger that the one on the hd!
i did a test with a smaller ogm file:
on cd: 66.985.004 bytes
on hd: 66.186.225 bytes

plus i notced that with vorbis audio muxed i oggcut crashes!!!!

[jurij]

with daemon tool did the same thing that with the burned cd, it didn't play at all.
with graphedit it worked, i could watch the video and hear the audio tracks.
Now what am i suppose to do?

[DeXT]

In my webpage (webs.ono.com/de_xt) you'll find a file called vcd_source_patch.zip, just download it and double clic on disable_vcd.reg. This will probably solve your problem.

This is a known problem that will be fixed in the next filter release without the need to use this patch. And you'll gain SVCD direct playing support without the need to install Elecard filters.

About this greater file size, well this is normal, there is about a 1% overhead since every 2324 bytes in the input file takes 2352 bytes in the CD.

I don't know if OggCut uses DirectShow to read the input file, but if it reads it directly it won't work because only DS-aware apps are supported.

Hope this helps.

[jurij]

i tried to disable but it still is not working :( HELP :((((((((

[DeXT]

Hmmm, seems you have a conflict with another existing DS filter. Try to uninstall and third party AC3 and MPEG-2 filter (mainly Elecard), we have received some reports on this subject.

Try to drag & drop the DAT file in GraphEdit and see what's happening (which filter tries to take over it). This may help us to determine potential conflicts.

[mustaneekeri]

DeXT, can u say estimate or more accurate date when form1 files are supported by Mode2CDMaker?

[jurij]

OKKKKKKKK!!!!!
In the cd i burned the file is called stargate.ogm.
if i copy it to my hd and rename to stargate.DAT then it works.
if i drag stargate.OGM in graphedit it only gives me the filter OggSplitter
I tough it was suppose to work also if the files in the cd didn't have the .dat extension.

[avig70]

If it doesn't work with a different suffix, maybe its a good idea not to allow this option ???

[DeXT]

I've looked at it, seems you cannot use a registered media type extension for RIFF/CDXA files because the original filter will try to take over that content. This is true for OGG/OGM and MP3, but not for AVI.

But as I said using the original extension is not recommended by any means since the file contents are no longer the same so you should use a new extension. This will be done the same way in XCD and MCD, too (custom extensions).

[jurij]

now what am i suppose to do? can i make it work with the ogm suffix in any way? what is it for to set the media type extension as i want if it won't work when .ogm?

[Koepi]

jurij,

I want to remind you that this is still experimenting stuff and thus can produce flawed CDs.
The "real" XCD won't necessarily be backwards-compatible and support the CDs you burned now.

If you're not willing to loose some CDs either use daemon-tools or leave your hands of this stuff until it gets retail ware ;)

That option is still useful if you burn avi to and m2f2 CD. AVI has riff-headers anyway and thus can cope with that.
mpeg1, mpeg2, mpeg4, ogm and mcf don't use riff headers and thus these headers inserted by the file reader (direct show) must get stripped again to make them playable.

Regards,
Koepi

[DeXT]

@jurij: what you are supposed to do is, not to burn with OGM extension, but DAT. As I said OGM and MP3 won't work.

In order to be able to play that OGM file you'll need to delete the OGM media type extension in the registry, and I'm sure you won't want to do that. So that CD is pretty useless, sorry.

Koepi says it all, this is TEST stuff. Not guaranteed to work.

@mustaneekeri: I forgot, well I'll have to go out for a week starting with May 23, so I'd like to have it working before I go. This is my personal bet, but I cannot guarantee it of course.