for a while now I've been studying electronic engineering and more specificatlly digital systems (microcontrollers, FPGAs, logic sequencers, etc.). I have made many little projects just for fun like IR receivers and transmitters, digital communication, smart sensors and so on. Now I want to make something actually usefull.
Since I spend alot of time backing up dvds I thought I could design some hardware for this and since XVID is an open technology I want to design something that would help in XVID encoding. I am thinking of perhaps dome kind of USB2.0 or perhaps firewire device that the encoder could use to offload some processing like conversions, quantisations or something else. I've got to say that I am not familiar with XVID code or infact with any MPEG-4 encoding code so I am ansure as to what would be usefull to offload.
So, could I have some suggestions from XVID developers as to what they would like to see in a device like that. Also if you could point me towards location of these features in the latest CVS builds of XVID.
If I do make something I'll hand over the full schematics and designs to XVID team to do with them what they will. Also I know of several electronics manufactureres near me that could probably mass produce these kind of devices.
Nice Idea
But if you make a hardware decoder (i think it's more simple) based in a simple cd/dvd player with a av out?!?! Firmware Upgradable.
I hope you have some support from the Xvid Team.
Nice idea, though I think that a PCI device would be better. And then the price. The main thing would be to develop a chip capable of encoding... That could be used in standalone DVD recorders (esp. for HDTV maybe), but I think its quite a big project. And even if you have finished the hardware design... who is gonna produce it for you? Oh, ok, reread your post
Well... from a customers view there is the price. I want to have ensured that the device offers at least the same quality than the software encoder has. I want it to be as fast as. And it should cost a whole bunch less than a new CPU would, because that one would boost speed too, and not only in XviD.
But a chip which can be used in both PC and standalones, maybe for playback even, would be quite interesting, if it is really fast. My favorite XviD settings bring my XP2600 down to 3 fps. Realtime would be neccessary. And maybe some small filtering (such things as UnDot etc.).
About hardware decoders: There are quite a few out there, some working with XviD. And I believe future commercial hardware decoders will be capable of playing back XviD fine, no matter what settings have been used.
well...
I am not really thinking of a full encoder or a decoder because that would really be a big job and I'm alone and kind of harrased by deadlines right now. But simple off-loading of some of tasks of the encoder, even through PCI (even though that would mean writing drivers and a hellovalot of testing to make sure it can share the bus properlly - no I don't think I'd go for PCI). For now to start with I just want a little project to work on by myself in my own time just to get the feel for things. The reason why I suggested USB is that it would make it simple to connect - it could be anything really. Maybe one day I might even suggest AGP
So for now I am not talking about anything that could be officialy stuck into XVID, but if I experiment with these ideas it could interest other people and, who knows, maybe open a hardware branch of XVID tree.
Here are a few things that might tickle the brainbuds of developers:
with something simple like a PIC16F877 microcontroller I can work with individual bits more or less the same way you can work with bytes.
Alot of microcontrollers have a RISC CPU - so the program will be quite simple and changable.
with something like a cheap Altera FPGA I can create just about any logic circuit on a bit level or byte level.
device like these could have upgradable firmware.
with microcontrollers you can use C so procedures from the XVID code could be implemented almost directly with minimum conversions unless they use specific x86 code which ofcourse would have to rewriten or simulated.
these devices at cheap prices can work at 20mHz to 100mHz, at more expensive prices upto gHz. But this speed rating is slightly different to x86 CPUs because the device would be dedicated to doing it's task and they can easily (not really easily) be setup to work in parallel.
Hmm... I just started studying electrical engineering (just about to finish the first semester ), but I wonder how the speed of this device could be. And USB isn't really the fastest thing... maybe with USB 2 or Firewire... If the chips would be designed to do the encoding stuff, ok. But your microcontrollers sound like small CPUs to me. What could they help? If even modern CPUs struggle with these tasks.
But some sort of hardware open source sounds interesting... maybe in a few years I can join
yes, I was originally suggesting usb2 or firewire, though the chips are slow - they are dedicated and they work in parrallel with the main CPU thus taking the load off the main CPU.
But the performance boost would be very low... huh?
@kadajawi
ok fine, let's say I make a full hardware encoder and let's say it runs at 2 frames per hour and let's say it is connected via RS232
now if you says that's not a cool bit of hacking i'd say you are in a wrong class
haha, I'm no where near that... still got to learn But I'm not talking from a developers point, but as a user. And as such I would say I wouldn't buy that One of the first thing we were told was something like quot;first and foremost: cost, cost, cost.quot;. If it's not going to sell, don't do it.
Not to sound pessimistic, but I think it would be difficult to find an area, where it would be any significant help.
Most of the time is used for doing motion estimation. If you turn off VHQ and turn Motion Precision down to 5 or below, you'll see XviD blazing away.
Motion Estimation would require the chip to have a huge amount of fast RAM available, as this is traditionally a memoryintensive task. Even a PCI-bus implementation would very fast become a bottleneck.
Furthermore ME is rather complex. An fDCT would be much simpler to do, but the gain would also be much smaller. |
Post at 2011-4-15 16:37
| This Author's Posts Only
