Hi
I read through your online documentation and am not sure which platforms you support. You refer to redhat at one point, so I'm assuming Linux is supported, but it would be nice to know in advance if you have tried this out on any other systems (just for those of us who dont use Linux). Examples would include FreeBSD, Solaris, etc.
Thanks
Also, how necessary was it to require *both* KDE and QT?
Can
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, ZZplayer was developped under Linux for KDE (=> QT) and use SMPEG & SDL.
I suppose that ZZplayer can be run on any platforme that support such librairies, but that was really tested by the developper in the case of version 0.8.
You can try and repport problem if any!
About the GUI : futur release of ZZplayer will supporte multiple GUI (kde, QT2.2, KDE2 and gnome were planned).
Also, how necessary was it to require *both* KDE and QT?
with kde, qt was necessary! and kde add some usefulthings (DnD, config-files...)
If you want only QT (2.2) support, next version (0.9) will probably support it before complete kde2 support!
regards.
Fred
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
this probably isnt a good thread to continue under, BUT:
i've done some hacking with mtvp (which we all know and love), basically wrapping around the ioctls and figuring out what they do... there are a couple of observations i would like to make:
1) it appears that ZZplayer is using the wrong size. the payload in a mode2 sector is 2324 bytes, not 2336. zzplayer is using 2336, which means its passing 12 bytes of garbage onto the mpeg decoder. this should be fixed. (this is obviously for MpegVCD.cpp). i *do* have a patch, but read on.
2) in terms of "other systems", you have some xfree86-dependent code, namely the stuff that tries to determine the screen resolution for full-screen mode. if you're planning on porting to other platforms, you should probably find a more portable solution (i looked on solaris, and couldnt find any, but then i dont know too much about X). if not, a static configuration such as 640x480 would be acceptable to most, i assume. also, i think you should add xfree86 to the list of requirements for zzplayer, as it is currently misleading.
3) your vcd code, while being mostly "portable" (you're just doing ioctls) doesnt work on solaris, because you're using an ioctl that solaris doesnt support. i only care about solaris (bigot, i know), and so i've ported the stuff to work with at least my machine, a sun4u, sparc, uniprocessor, etc. i dont know if multithreading is ever going to be an issue, but if it is, then you should protect all of your global data by locks of sorts, or else ugly stuff will happen. some points that i had to fix before being able to port:
3.1 - i'm not sure about linux or freebsd, but the equivalent of /dev/cdrom is a character device in solaris, so IS_BLK() in MpegVCD.ccp should be changed to IS_CHR(). i think this *should* be a character device no matter what, but i cant tell the linux ppl what to do with their os. i was at one point sure that freebsd had made the cdrom device a character device as well, but i wont bet on it.
3.2 - you dont check error codes.. that's *VERY* bad. especially for vcd_read() which could had a number of reasons for failing.
3.3 - after my vcd decode finished i got in an infinite loop of poll()'s (as reported by truss).. so there are some issues here. for some reason signals were also being blocked or ignored so i had to kill -9 it.
3.4 - the configure script is broken. not beyond hope, but it's broken. i had to hand-patch a lot of stuff. some issues that come to mind right off:
there should be a --with-kde-dir flag. the jumble currently there didnt work when i put kde in /home/me. also make distclean didnt seem to get rid of a bunch of garbage out there, and the pathnames end up replicated in every makefile. it's much simpler to set the variables in the top-level makefile and then have the makefiles in the subdirectories read the values, rather than re-setting them in each makefile (which makes it tedious to change the values).
3.5 - it's probably a good idea to perror() or dump some other sort of diagnostic messages on errors. it currently hangs or core dumps (not necessarily my favorite situations).
4) i need and want a vcd player, and since i was able to port zzplayer, i plan to continue work on it. i can send you my diffs for sparc solaris. i havent tested this on an x86 machine, but i can do that too. some additional features you might want to support would include having something to browse the vcd... that cant be very hard (there are ioctls to get the on-disk contents), and it would be more user-friendly than having to type it out on the command line (after all, you *DO* have a gui, unlike mtvp).
5) this goes along with the general code: you have a number of divide's and %'s in vcd_read... presumably this code is being called *very* frequently (it is), and hence (knowing that divisions take a extraordinary amount of time), and since you already know the lba, i might encourage you to use a different ioctl to get the stuff off disk.. perhaps CDROMREADMODE2 which i see in linux/cdrom.h, which seems to do the equivalent of CDROMCDXA on solaris.. that will presumably save you some time, since this is a critical data path.
6) in fillPipe() you end with 'while(1);' with a comment that you're waiting for killthread. if you're waiting for killthread then you should pause(), *not* cause yourself to be scheduled on the CPU while you're not doing anything worthwhile. also depending on your threading model there might not be thread pre-emption, at which point this code will hang (GNUpth is one such example). pause() is what you want here.
that's all i had to say. sorry it's a bit lengthy. i'd be delighted to be added to the list of developers and help out as much as i can. i'm not a c++ or gui genius, but i can check error return codes and all that good stuff :). i *am* a kernel programmer in fact.
regards,
Can
ps: i guess under the GPL license i'm permitted to steal your code, make whatever modifications i want and call it "my" project, specifically for solaris, but i'd much rather collaborate :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I added the VCD support because many people asked me. But I am not a VCD fan. I bought one to do some tests with ZZPlayer...
1) Cause I'm not a CDROM expert, I stole the code for read a VCD from plaympeg. But I looked into xreadvcd, and they are not using the same way to read VCD. xreadvcd writes 2324 bytes !!!
I didn't know who was right. Now I know ;-)
2) Ok, I will add Xfree86 in the requirements list for the next release.
3) What can I say ? I know nothing about solaris or xBSD, I am just a Linux user.
3.4) Did you try the last CVS configure script.
4) Do you talk about VCD navigation like DVD ? I know it's possible on VCD.
5) If you see the mpeg decoder, a divide is nothing. But I am agree with you, Why waste CPU time ?
6) Shame on me. I promisse myself to change that but I did nothing.
PS : With the GPL licence, you can steal *my* code, but you cannot distribute your project with the ZZplayer name.
Anyway, I will be happy if you want to join the ZZplayer team to improve the VCD support and have a ZZplayer more portable.
Please send me a email with your sourceforge login at nicolas.vignal@fnac.net
Regards
Nicolas
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi
I read through your online documentation and am not sure which platforms you support. You refer to redhat at one point, so I'm assuming Linux is supported, but it would be nice to know in advance if you have tried this out on any other systems (just for those of us who dont use Linux). Examples would include FreeBSD, Solaris, etc.
Thanks
Also, how necessary was it to require *both* KDE and QT?
Can
Hello,
Well, ZZplayer was developped under Linux for KDE (=> QT) and use SMPEG & SDL.
I suppose that ZZplayer can be run on any platforme that support such librairies, but that was really tested by the developper in the case of version 0.8.
You can try and repport problem if any!
About the GUI : futur release of ZZplayer will supporte multiple GUI (kde, QT2.2, KDE2 and gnome were planned).
Also, how necessary was it to require *both* KDE and QT?
with kde, qt was necessary! and kde add some usefulthings (DnD, config-files...)
If you want only QT (2.2) support, next version (0.9) will probably support it before complete kde2 support!
regards.
Fred
Hi,
To compile ZZplayer 0.8 you MUST have QT, KDE, SDL, SMPEG on your computer.
The last ZZplayer version should work under FreeBSD. You just need to customize the configure script. To see the options :
#configure --help
I know the 0.6 version is working on FreeBSD.
I don't know about solaris and others.
If you are running ZZplayer on a different plateform than linux, please send us an email.
Regards
Nicolas
this probably isnt a good thread to continue under, BUT:
i've done some hacking with mtvp (which we all know and love), basically wrapping around the ioctls and figuring out what they do... there are a couple of observations i would like to make:
1) it appears that ZZplayer is using the wrong size. the payload in a mode2 sector is 2324 bytes, not 2336. zzplayer is using 2336, which means its passing 12 bytes of garbage onto the mpeg decoder. this should be fixed. (this is obviously for MpegVCD.cpp). i *do* have a patch, but read on.
2) in terms of "other systems", you have some xfree86-dependent code, namely the stuff that tries to determine the screen resolution for full-screen mode. if you're planning on porting to other platforms, you should probably find a more portable solution (i looked on solaris, and couldnt find any, but then i dont know too much about X). if not, a static configuration such as 640x480 would be acceptable to most, i assume. also, i think you should add xfree86 to the list of requirements for zzplayer, as it is currently misleading.
3) your vcd code, while being mostly "portable" (you're just doing ioctls) doesnt work on solaris, because you're using an ioctl that solaris doesnt support. i only care about solaris (bigot, i know), and so i've ported the stuff to work with at least my machine, a sun4u, sparc, uniprocessor, etc. i dont know if multithreading is ever going to be an issue, but if it is, then you should protect all of your global data by locks of sorts, or else ugly stuff will happen. some points that i had to fix before being able to port:
3.1 - i'm not sure about linux or freebsd, but the equivalent of /dev/cdrom is a character device in solaris, so IS_BLK() in MpegVCD.ccp should be changed to IS_CHR(). i think this *should* be a character device no matter what, but i cant tell the linux ppl what to do with their os. i was at one point sure that freebsd had made the cdrom device a character device as well, but i wont bet on it.
3.2 - you dont check error codes.. that's *VERY* bad. especially for vcd_read() which could had a number of reasons for failing.
3.3 - after my vcd decode finished i got in an infinite loop of poll()'s (as reported by truss).. so there are some issues here. for some reason signals were also being blocked or ignored so i had to kill -9 it.
3.4 - the configure script is broken. not beyond hope, but it's broken. i had to hand-patch a lot of stuff. some issues that come to mind right off:
there should be a --with-kde-dir flag. the jumble currently there didnt work when i put kde in /home/me. also make distclean didnt seem to get rid of a bunch of garbage out there, and the pathnames end up replicated in every makefile. it's much simpler to set the variables in the top-level makefile and then have the makefiles in the subdirectories read the values, rather than re-setting them in each makefile (which makes it tedious to change the values).
3.5 - it's probably a good idea to perror() or dump some other sort of diagnostic messages on errors. it currently hangs or core dumps (not necessarily my favorite situations).
4) i need and want a vcd player, and since i was able to port zzplayer, i plan to continue work on it. i can send you my diffs for sparc solaris. i havent tested this on an x86 machine, but i can do that too. some additional features you might want to support would include having something to browse the vcd... that cant be very hard (there are ioctls to get the on-disk contents), and it would be more user-friendly than having to type it out on the command line (after all, you *DO* have a gui, unlike mtvp).
5) this goes along with the general code: you have a number of divide's and %'s in vcd_read... presumably this code is being called *very* frequently (it is), and hence (knowing that divisions take a extraordinary amount of time), and since you already know the lba, i might encourage you to use a different ioctl to get the stuff off disk.. perhaps CDROMREADMODE2 which i see in linux/cdrom.h, which seems to do the equivalent of CDROMCDXA on solaris.. that will presumably save you some time, since this is a critical data path.
6) in fillPipe() you end with 'while(1);' with a comment that you're waiting for killthread. if you're waiting for killthread then you should pause(), *not* cause yourself to be scheduled on the CPU while you're not doing anything worthwhile. also depending on your threading model there might not be thread pre-emption, at which point this code will hang (GNUpth is one such example). pause() is what you want here.
that's all i had to say. sorry it's a bit lengthy. i'd be delighted to be added to the list of developers and help out as much as i can. i'm not a c++ or gui genius, but i can check error return codes and all that good stuff :). i *am* a kernel programmer in fact.
regards,
Can
ps: i guess under the GPL license i'm permitted to steal your code, make whatever modifications i want and call it "my" project, specifically for solaris, but i'd much rather collaborate :)
Hi,
I added the VCD support because many people asked me. But I am not a VCD fan. I bought one to do some tests with ZZPlayer...
1) Cause I'm not a CDROM expert, I stole the code for read a VCD from plaympeg. But I looked into xreadvcd, and they are not using the same way to read VCD. xreadvcd writes 2324 bytes !!!
I didn't know who was right. Now I know ;-)
2) Ok, I will add Xfree86 in the requirements list for the next release.
3) What can I say ? I know nothing about solaris or xBSD, I am just a Linux user.
3.4) Did you try the last CVS configure script.
4) Do you talk about VCD navigation like DVD ? I know it's possible on VCD.
5) If you see the mpeg decoder, a divide is nothing. But I am agree with you, Why waste CPU time ?
6) Shame on me. I promisse myself to change that but I did nothing.
PS : With the GPL licence, you can steal *my* code, but you cannot distribute your project with the ZZplayer name.
Anyway, I will be happy if you want to join the ZZplayer team to improve the VCD support and have a ZZplayer more portable.
Please send me a email with your sourceforge login at nicolas.vignal@fnac.net
Regards
Nicolas