Resistance is futile if newbies like it.
on
AOL's new Linux PC
·
· Score: 1
Yeah I know, nobody's got a gun to your head and all that.
Still, even though I loathe AOL as a service provider, I'm constantly bugged by novice users to "help fix my internet thingie" and deal with various other issues. Chances are if AOL does release their own OS, I'll be forced to learn how to use it because other people will constantly ask me to help them with it and assume I know all about it.
Now the question is, how much damage will this do to the unity of the Linux community (which isn't all that unified to begin with) when half the users are in favor of this "Hey! AOL is getting people to use Linux and is gonna give MS some competition!" and half are morally opposed to it "Oh god no! Now the most popular distro will be the one that's dumbed down the most and forums will be flooded with AOL users asking the same questions over and over!"
Sounds like poll time to me. "Would an AOL-made and supported free distribution of Linux be a good thing, or a bad thing?"
So what's it called now? AOLinux?
on
AOL's new Linux PC
·
· Score: 3, Interesting
So how long before we see AOL make their own distribution with all the "harmful" features (i.e. any type of user system control, the ability to not boot into a GUI, etc) stripped?
I'm surprised they didn't buy Corel a few years ago and try this already. "Here's a free OS on our free 1000 hour CDs! Oh, your office apps won't run now? Buy ours for only $49.95 each!"
I was all set to save up and buy an e-cycle (the original electric) YEARS ago. BTW this diesel hybrid is not news, it's been mentioned on their site for over a year now.
I wanted the electric one, even with 50mi range. They kept pushing dates back, then suddenly it's "Oh, we've decided to build this new hybrid bike instead, so it'll be a few more years."
I'm betting they'll stall for more investment money and then in another year or so go "Wait wait, we'll make a fuel cell bike instead! Just hang on another 3 years!"
Run! A giant rabbit is gonna eat our MS passports!
on
Vorpal Rabbit-o-Saurus
·
· Score: 1
I always wanted to play that game too, but nooo, my parents had to get me a Colecovision instead, so I was stuck with games like mousetrap. Ok, so it wasn't that bad, but I still remember being annoyed all my friends could trade games and I couldn't.
Oh and that Coleco Adam was worthless, the tape drive on mine broke in like a month.:P
Yup, it is so far. I got it a few days ago. I found it and ordered it between when I wrote the original post and when slashdot got around to putting it up. Thanks though.
I mean random data as in values that fit the range (-128 to 127) that pixel values would fall into when stored as bytes in memory. So basicly snow. I'm sure if viewed it would look awful, but yes it will compress in a lossy codec, and just look awful.
I'd like to publish source eventually but I'm wary of having it stolen and then getting sued by someone else claiming it's "theirs" so I'm not sure what I'm gonna do with it yet. I don't know how to protect myself.
Oh and I have inter-frame compression, just not in the way current codecs like the mpeg family do. I have a completely different design.
On writing for linux instead (anonymous 1, Seann):
Problems with this are 1. I don't use linux. 2. I have no desire to use linux. 3. I have some but probably not enough experience using linux in the past to get something like this to work. 4. I'm not aware of any standard capture and playback API for linux, though I will look up video for linux for a possible later port. 5. Even if I get it working on linux, 99% of the people who'd want to use it don't use linux for encoding. 6. BSD rules. But it still sucks for video as much as linux. =)
If you can show me a linux API that I can use in less than 300 hours of fumbling around that works with the wintv go, radeon vivo, and gainward geforce4 ti4400 vivo in my test systems as capture devices, then I'll consider it. If it involves delving through kernel rebuilds and obscure device creation and such, forget it.
On using Directshow (Cecil, crapulent):
I have researched this and am reasonably confident I CAN produce a directshow filter (since I've already made one for the basic transform that works). However, if you'd care to read my original post more closely, I mentioned that premiere, virtualdub, and avicap all used VFW, and NOT directshow. I do agree that propigating old standards is horrible and should be done away with, but if I want any kind of apps to be able to use this for testing and real world applications, I have to interface with them. They all use the VFW interface, unless you count Graphedit, and I won't even go there. If you can think of a stable encoding app that actually uses directshow filters, please let me know.
On doing static transforms first (crapulent):
I've got a working transform function that's been ok for several months now. I've tested it with random generated data, my athlon xp1800 manages about 150fps. I also wrote SMP support for it so my friend's dual athlon mp1900 gets about 340fps. Transforming isn't a problem.
The problem comes from the "read an avi" part. I don't know how to use the API to get data from the avi, and that's my original question. As for directshow, no apps use it, so even if I wrote a filter, it would be useless for anything but accelerated decode in players, which is pointless without something encoded in the format first, which I can't do.
I do actually have a working directshow filter right now that implements the base transform, but it only works with graphedit, which likes to crash every few seconds no matter what I'm using.
On using transcode (WasterDave):
This sounds interesting and useful. I will look into it, thanks. Oh and yes I do know what 4:2:0 YUV is. =)
On emailing virtualdub's author (anonymous):
I tried this once I think, maybe I'll give it another shot as I think it was a long time ago now.
On huffyuv being slashdotted (anonymous):
Good. It'll save me the trouble of driving over to berkeley and slapping him with a printout of his own code.
Other stuff:
I've come across this book http://www.amazon.com/exec/obidos/tg/detail/ -/0471 310158/qid=1031113475/sr=8-1/ref=sr_8_1/102-492848 4-5485757?v=glance&s=books&n=507846 and ordered it. I hope it's helpful, but if anyone knows another book that is I can use all the help I can get at this point. If anyone from xiph's video project can give me some tips, I do visit your IRC server from time to time, and I'd really appreciate any help you can give. Ditto anyone from xvid, though I don't think you guys have an IRC server that I know of.
Ok, so the problem is there's too much frame data and no way to get it back over the bus to the system for storage.
Proposed solution: Seperate capture device.
Method of connection: DVI digital output.
All modern graphics cards have digital DVI out these days. Most of them can run it simultaneously with a VGA monitor or second DVI, depending on your card. Some can even fullscreen an app on one interface while having it windowed on the other. Perfect for this.
So, you tap the DVI into a custom piece of hardware designed to do the capture. Say a box with a couple hundred megs of ram (what's a gig of PC133 these days, $80?) with the bandwidth to do the capture (PC133 = 1066MB/sec, well above the 225MB/sec estimate from another post). Then you add in a hardware compression chip a la mpeg2 hardware encoder or mpeg4 hardware encoder, whichever you please. Then dump the compressed result to a hard drive.
Hell, I bet you could put this entire thing except the hard drive on a PCI card, put it in a slot, and run your video card's DVI out to the PCI card's input port, then capture back to the disk. All you need is a way to decode DVI. Since it's already a digital signal designed to display an image, I don't think decoding it to say, a TGA format would be that impossible to do. After all, LCDs have to have some kind of decoder for it right?
Is this really any less feasible than those old mpeg2 PCI decoders that used pass through connections to the video card? I mean it'll need the ram for temp storage and probably a bit more processing power to encode instead of decode, but I don't see it being unfeasible. I bet you could mass produce one for $299 that worked with any 3D card on the market.
Need it right now? Two PCs, one renders, one captures. Optimize each box for its task. One with a fast CPU, fast GPU, the other with a vid capture/hardware encoding card, and RAID array. Of course then you could only capture output dependant on the source machine, so doing individual frames might be slightly tricky, but I'm betting the timing issues for syncing could be worked out in software.
I don't know why everyone else keeps just putting whatever they feel like but I always use these conventions when writing about data:
mbps (ALL LOWERCASE) = megaBITS in BASE10 per second.
MB/sec (BOTH UPPERCASE) = megaBYTES in BASE2 per second.
Oh BTW, for those looking for controllers, 3ware, http://www.3ware.com has mentioned they'll have SerialATA versions of their RAID5 controllers in 4, 8, 12, and 16 channel versions next quarter via converter bridges, and probably native SATA-II controllers.
What dissapoints me most is the power connector. 15 pins? Come on. I thought power was going to be included in the 7 pin cable. Now we have a power cable 2x larger than the data cable, and it's still going to be a pain.
Slashdot Mirror
Yeah I know, nobody's got a gun to your head and all that.
Still, even though I loathe AOL as a service provider, I'm constantly bugged by novice users to "help fix my internet thingie" and deal with various other issues. Chances are if AOL does release their own OS, I'll be forced to learn how to use it because other people will constantly ask me to help them with it and assume I know all about it.
Now the question is, how much damage will this do to the unity of the Linux community (which isn't all that unified to begin with) when half the users are in favor of this "Hey! AOL is getting people to use Linux and is gonna give MS some competition!" and half are morally opposed to it "Oh god no! Now the most popular distro will be the one that's dumbed down the most and forums will be flooded with AOL users asking the same questions over and over!"
Sounds like poll time to me. "Would an AOL-made and supported free distribution of Linux be a good thing, or a bad thing?"
So how long before we see AOL make their own distribution with all the "harmful" features (i.e. any type of user system control, the ability to not boot into a GUI, etc) stripped?
I'm surprised they didn't buy Corel a few years ago and try this already. "Here's a free OS on our free 1000 hour CDs! Oh, your office apps won't run now? Buy ours for only $49.95 each!"
I was all set to save up and buy an e-cycle (the original electric) YEARS ago. BTW this diesel hybrid is not news, it's been mentioned on their site for over a year now.
I wanted the electric one, even with 50mi range. They kept pushing dates back, then suddenly it's "Oh, we've decided to build this new hybrid bike instead, so it'll be a few more years."
I'm betting they'll stall for more investment money and then in another year or so go "Wait wait, we'll make a fuel cell bike instead! Just hang on another 3 years!"
Flee in terror! It's coming!
I always wanted to play that game too, but nooo, my parents had to get me a Colecovision instead, so I was stuck with games like mousetrap. Ok, so it wasn't that bad, but I still remember being annoyed all my friends could trade games and I couldn't.
:P
Oh and that Coleco Adam was worthless, the tape drive on mine broke in like a month.
Yup, it is so far. I got it a few days ago. I found it and ordered it between when I wrote the original post and when slashdot got around to putting it up. Thanks though.
How'd you do that? I can't even really tell if huffyuv is 16bit or 32bit. Where do you check?
Thank you for this link. I had searched for it before but all the links I found had basicly said "VFW is dead, use DirectShow. -- Love, Microsoft."
I mean random data as in values that fit the range (-128 to 127) that pixel values would fall into when stored as bytes in memory. So basicly snow. I'm sure if viewed it would look awful, but yes it will compress in a lossy codec, and just look awful. I'd like to publish source eventually but I'm wary of having it stolen and then getting sued by someone else claiming it's "theirs" so I'm not sure what I'm gonna do with it yet. I don't know how to protect myself. Oh and I have inter-frame compression, just not in the way current codecs like the mpeg family do. I have a completely different design.
On writing for linux instead (anonymous 1, Seann):
/ -/0471 310158/qid=1031113475/sr=8-1/ref=sr_8_1/102-492848 4-5485757?v=glance&s=books&n=507846
Problems with this are
1. I don't use linux.
2. I have no desire to use linux.
3. I have some but probably not enough experience using linux in the past to get something like this to work.
4. I'm not aware of any standard capture and playback API for linux, though I will look up video for linux for a possible later port.
5. Even if I get it working on linux, 99% of the people who'd want to use it don't use linux for encoding.
6. BSD rules. But it still sucks for video as much as linux. =)
If you can show me a linux API that I can use in less than 300 hours of fumbling around that works with the wintv go, radeon vivo, and gainward geforce4 ti4400 vivo in my test systems as capture devices, then I'll consider it. If it involves delving through kernel rebuilds and obscure device creation and such, forget it.
On using Directshow (Cecil, crapulent):
I have researched this and am reasonably confident I CAN produce a directshow filter (since I've already made one for the basic transform that works). However, if you'd care to read my original post more closely, I mentioned that premiere, virtualdub, and avicap all used VFW, and NOT directshow. I do agree that propigating old standards is horrible and should be done away with, but if I want any kind of apps to be able to use this for testing and real world applications, I have to interface with them. They all use the VFW interface, unless you count Graphedit, and I won't even go there. If you can think of a stable encoding app that actually uses directshow filters, please let me know.
On doing static transforms first (crapulent):
I've got a working transform function that's been ok for several months now. I've tested it with random generated data, my athlon xp1800 manages about 150fps. I also wrote SMP support for it so my friend's dual athlon mp1900 gets about 340fps. Transforming isn't a problem.
The problem comes from the "read an avi" part. I don't know how to use the API to get data from the avi, and that's my original question. As for directshow, no apps use it, so even if I wrote a filter, it would be useless for anything but accelerated decode in players, which is pointless without something encoded in the format first, which I can't do.
I do actually have a working directshow filter right now that implements the base transform, but it only works with graphedit, which likes to crash every few seconds no matter what I'm using.
On using transcode (WasterDave):
This sounds interesting and useful. I will look into it, thanks. Oh and yes I do know what 4:2:0 YUV is. =)
On emailing virtualdub's author (anonymous):
I tried this once I think, maybe I'll give it another shot as I think it was a long time ago now.
On huffyuv being slashdotted (anonymous):
Good. It'll save me the trouble of driving over to berkeley and slapping him with a printout of his own code.
Other stuff:
I've come across this book
http://www.amazon.com/exec/obidos/tg/detail
and ordered it. I hope it's helpful, but if anyone knows another book that is I can use all the help I can get at this point. If anyone from xiph's video project can give me some tips, I do visit your IRC server from time to time, and I'd really appreciate any help you can give. Ditto anyone from xvid, though I don't think you guys have an IRC server that I know of.
Ok, so the problem is there's too much frame data and no way to get it back over the bus to the system for storage. Proposed solution: Seperate capture device. Method of connection: DVI digital output. All modern graphics cards have digital DVI out these days. Most of them can run it simultaneously with a VGA monitor or second DVI, depending on your card. Some can even fullscreen an app on one interface while having it windowed on the other. Perfect for this. So, you tap the DVI into a custom piece of hardware designed to do the capture. Say a box with a couple hundred megs of ram (what's a gig of PC133 these days, $80?) with the bandwidth to do the capture (PC133 = 1066MB/sec, well above the 225MB/sec estimate from another post). Then you add in a hardware compression chip a la mpeg2 hardware encoder or mpeg4 hardware encoder, whichever you please. Then dump the compressed result to a hard drive. Hell, I bet you could put this entire thing except the hard drive on a PCI card, put it in a slot, and run your video card's DVI out to the PCI card's input port, then capture back to the disk. All you need is a way to decode DVI. Since it's already a digital signal designed to display an image, I don't think decoding it to say, a TGA format would be that impossible to do. After all, LCDs have to have some kind of decoder for it right? Is this really any less feasible than those old mpeg2 PCI decoders that used pass through connections to the video card? I mean it'll need the ram for temp storage and probably a bit more processing power to encode instead of decode, but I don't see it being unfeasible. I bet you could mass produce one for $299 that worked with any 3D card on the market. Need it right now? Two PCs, one renders, one captures. Optimize each box for its task. One with a fast CPU, fast GPU, the other with a vid capture/hardware encoding card, and RAID array. Of course then you could only capture output dependant on the source machine, so doing individual frames might be slightly tricky, but I'm betting the timing issues for syncing could be worked out in software.
And to think I was making do with a $50 plastic table from Home Depot me and my roommates pitched in to buy.
I don't know why everyone else keeps just putting whatever they feel like but I always use these conventions when writing about data: mbps (ALL LOWERCASE) = megaBITS in BASE10 per second. MB/sec (BOTH UPPERCASE) = megaBYTES in BASE2 per second. Oh BTW, for those looking for controllers, 3ware, http://www.3ware.com has mentioned they'll have SerialATA versions of their RAID5 controllers in 4, 8, 12, and 16 channel versions next quarter via converter bridges, and probably native SATA-II controllers. What dissapoints me most is the power connector. 15 pins? Come on. I thought power was going to be included in the 7 pin cable. Now we have a power cable 2x larger than the data cable, and it's still going to be a pain.