You can't say boradband via cable companies has a doomed future based on your singular personal experience, it just seemed ludicrous.
Ultimately, I think both technologies have about equal potential, with one beating the other depending on where you are.
DSL is offered by companies that typically have more experience in offering high-bandiwdth internet connections, so service and reliability I think is indeed, mostly better with DSL on average. However, as Cable companies have learned their lessons, it becomes harder and harder to distinguish the two. DSL still seems to typically offer better latency (around my area, at least), but cable services offer better throughput.
To home consumers, the fine details don't make much of a difference. Availability makes all the difference. I can't get DSL at any decent rate. None of my family can get it at all. I do, and my family could, all have cable modem at 2 megabit downstream, 768k up. In addition to that, a sort of unintended benefit of cable modem service is that there is a good chance the installer won't bother with a video filter and you get free cable with the net connection. I know, not a fair comparison because cable companies hate this, but realistically speaking, it must be considered.
No, 386 was the first '32 bit' chip of Intel's line. The pentium marked the first processor which had a name that could be copyrighted, so Cryix and AMD couldn't produce clones under the name name (as they had done with earlier processors (my 286 was actually an AMD processor).
Don't know if it is rot, but a disc of mine in an expensive box set is delaminating or something around the outer edge. It's really annoying. Since replacement means about a hundred dollar investment, I decided to contact the manufacturer to see if I could do an exchange (no warranty, beyond the retailers money-back guarantee) and the answer was of course, no, not so long as there is no mass reported defect, they will not do replacements.
Now I think movie studios shouldn't be able to keep things going as they are. If we are truly being sold the right to view the contents, and not the disc and its contents themselves and are denied a sufficient legal backup mechanism, we should be able to trade in bad discs for good discs, especially if they are still being actively pressed.
I truly understand they have no obligation, but it makes me mad that they fight against us being able to back up the media, yet provide no alternative when a disc goes bad. It would be one thing if available as a 10 dollar disc, but these $100+ DVD Box Sets are really annoying when one disc goes wacked..
I had an AI class with him. In one of those classes, he demoed this stuff. It was using the Unreal Tournament engine. Two demos he gave. One, two characters were put in a maze, without scripted moves and only knowledge of their immediate surroundings, and the knowledge of where they want to be and how to open doors (seemed like they had to go press and hold triggers or something, it's been awhile. Wasn't too terribly exciting by itself. This is along the lines I think when I think about traditional AI research, but doesn't strike me as very useful to a game..
The other was the user walked around an aquarium, and fish swam however they saw fit. The interesting part was the plaques that gave information about the animals. There was a database of factoids, and some rules about grammar and various languages, but no pre-written plaques. When viewed, the plaques contained a generated paragraph which presented some of the facts. The paragraph was always different every time you looked, and it could do it in several languages. This demonstrated how it could be used in an educational application, but also how it could be used to make NPC dialog more dynamic and realistic ('Times are Tough...').
The ultimate goal was to have a few stated conditions, and maybe end conditions, and allow the gamer full control over the environment, and have the story adapt to the conditions the player causes, if the story as planned to that point becomes impossible due to a players actions (say player is on an island with only one boat around, and he is expected to go to another island, but destroys the boat instead), a new story is generated on the fly. The computer adlibs. Also, if the game absolutely, positively requires that the player go to another island, some mechanisms can be put in, such as if the boat is not there, helicopter or another boat comes in and the occupants conveniently walk away from it.
He described the goal to be a fully interactive story, that is never the same twice through. A very interesting boon to RPGs as we know it. The aquarium demo at least showed promise for better NPC dialog. I don't know if they have anything to show the evolving story yet though...
Ugh.... I'll admit that mplayer has done a lot, but do not give them credit for QuickTime. Apple invented it. The container format is well known and published, and linux supported before mplayer even existed (xanim could parse.mov). Now if you are talking about the source-available decoder for Sorenson, Xine had that first. With that, about 80-85% of the.movs out there became playable under linux (not just x86 linux). I will admit that mplayer seems to be the first to get the QuickTime binary codecs (audio of the 15-20%.movs out there) to work under x86 linux.
They were not the first to use binary video codecs from windows (as some have claimed in this discussion), that honor belongs to either avifile or xmps (I can't remember which or if they were interdependent, but avifile remains alive..).
MPlayer and xine have been pretty competitive in terms of codec support, but only through cooperation. MPlayer brings a lot of good and unique things to the table in terms of an application suite (mplayer and mencoder), but they did not invent everything they use. They *have* done a kick ass job of bringing everything together to have the most capable player (what else can play so many formats to so many output devices?). Technologically speaking, the thing lacking is a clean plugin architecture, and a nice thing would be a clean API capability (ala xine-lib). Legally speaking, I'm quite sure any number of companies (MS, Apple, Sorenson, Realnetworks, others) could give the big smack down to mplayer if they wanted. Then again, they could also smack down avifile, xine, Gentoo, and any number of other projects that do not occur to me right now. They are wishy-washy on the GPL I think, but it seems to be more a matter of support than anything. They will make a best-effort attempt at support, unless you got a binary precompiled, and the GPL states that no support is required at all.
If you poke around you can find slick cases and barebones kits (like the Shuttle systems). I've seen cases that look similar to the KISS case.
The problem with the 'firmware updates' is that it can only do so much. When relying on dedicated chips for decoding, those chips do a damn good job at efficiently playing back what they are designed for. As a general purpose processor, it would suck. It might do well against new, but similar codecs, but if a huge new thought of how to compress video comes along, no firmware update in the world could make those dedicated chips play it.
Yes, a 1.5 GHz system is overkill for movie playback, but it can more easily adapt than a system that requires special hardware to do the hard stuff.
Yes, but I know a lot of sites that wait on the full service packs. Testing every hotfix that comes out of MS is not time effective. The policies I generally see is that companies first wait a month after release to see if anything bad happens with the SP, then take a couple of weeks in a test configuration to make sure nothing site-specific should happen, then install SP if fine. The SP3 was only released recently.
The problem is that with MS, there are two levels of fixes, hotfixes and service packs. hotfixes could be anything from a slight cosmetic bug that isn't worth the time to worry about in a professional environment, to a critical vulnerability. There really isn't a huge sense of urgency at the word 'hotfix'. They really need a separate category of 'critically needed patch' for stuff that can cause problems of this scale if left unpatched.
As exciting as this is, this could mean bad things. Are there GPL violations happening?
I really have to wonder why a company would release a product like this based on Linux rather than a BSD. Either way there is a significant amount of work to create drivers for the device they choose, but with a BSD they never have to worry about the license.
I love Linux, but if I had to make a device like this with hardware not yet supported by either codebase to sell to consumers, I would choose BSD and save a legal headache down the road.
The divx movies you may download can really suck ass. The same is true of MPEG-1 (the tech behind VCDS). If you get MPEG-1 up to VCD bitrates, the quality becomes 'acceptable', but frequently you are left with blocky artifacts (*especially* when there is Text overlayed on the image encoded with the Video as is the case with credits and subtitles).
DIVX encoded at the same bitrate as VCDs are really blow VCD away. Much fewer artifacts, text does not distort background, etc. Try breaking out mencoder (or whatever the tool of the day is in Windows today) and making your own samples from DVDs, using the same bitrate for your MPG and DivX output. The results will be crystal clear.
As an aside, my favorite format is.ogm with MPEG-4 (Whether it be DivX or whatever) video, vorbis audio, and a text stream if subtitles are needed. I really wish this sort of format would become more prominent.
With this review, hard to take them seriously. First they say that it is restricted to PAL or NTSC, and that PAL is 720x576 *dpi*. dpi means dots per inch, drop it because it is wrong, unless you have a 1-cubic-inch pal screen, and the i means 'cubic inch'.....
Then, correctly notes that 1280x720 and 1920x1080 are supported, but the phrasing seems to suggest that it is being scaled to PAL or NTSC, which is wrong. This is a progressive-scan device, and those are HDTV resolutions. They have already on the second page made a *huge* mistake about a fundamental function of the player.
And of course I love that the DVD-ROM is connected via a DIE cable... he he... I know, a simple typo, but one with amusing connotations.
On the subject of the player itself... I'm not so sure it will hit it off with the target audience. Most home users don't care that much about DivX, because making them is very difficult and downloading is hard because it requires too much bandwidth, servers don't give away enough hosting space for movies, and the places where DivX movies can be downloaded are rather intimidating to common users (i.e. IRC). People who do work with such formats frequently are aware of the nature of the media that makes them think twice about dedicated hardware purchases. The formats themselves sometimes change in incompatible ways, and also a format's dominance in tenuous at best. Most are also technical enough to realize that for not much more money they can piece together a decent PC with TV out for not much more that will have faster, general purpose processors that can adapt easy to new formats and new delivery mechanisms. This thing only takes Discs, but many people would prefer to use SMB or NFS... If anything changes, a computer is easy to reconfigure, a set-top box... no....
I wouldn't be too excited about the Helix project. It is still mostly vapor and even if and when it reaches maturity, it will only *possibly* support formats aside from realmedia. Not a good prospect for a framework.
Of the three links you supplied, only one even exemplifies a real 'framework', gstplayer is a gstreamer based player, the rest are standalone. I would say there are three projects out there with the makings of a good framework.
Gstreamer is the project that most directly addresses the need for a true framework, that is a framework that provides encoding, decoding, and playback functionality. The problem is that file format and codec support are dismal compared to the alternatives, and as such it doesn't attract developers. Also, alternatives are 'good enough', so there isn't enough interest in writing the plugins necessary to make gstremer an acceptable framework.
Xine abstracts the media playback functionality into a library, so it still could be considered kind of a framework. Problems are that it lacks the capability to create media and that the codec and format support is only 'pretty good.'
Now mplayer, it can play nearly every codec and format under the sun. It also has the capability to encode, decode, and play media. One problem is that it is very much a standalone application, so it can't be considered a framework, only an application that implements nearly everything a framework should have. If the backend were abstracted from the application and that backend made available through an API (probably only supporting SDL for video and audio output for the most cross-platform framework), then you are starting to get somewhere. Of course, it still lacks a good flexible plugin architecture that allows post-install/compile time drop-in support for new file formats and codecs (though I may be mistaken about this).
So between the three you could have an uber-framework. If I had time or was being paid to architect a framework for linux, I would extend mplayer's code to fit the purpose and provide some glue to SDL for a truly cross-platform framework.
Common codec interface? Well that is a hard thing to really define, any of he systems out there can be considered a 'standard' codec framework. Due to the nature of linux, it would be up to major distros to pick their favorite and run with it.
That said, if mplayer would separate the backend operations into a independent library (like xine does), I have no doubt that it would be rapidly adopted as the 'standard'. Within a week of work being done, I would bet that an application like totem would spring up for mplayer, providing the traditional movie playback application people expect (with a newbie-friendly interface). And mencoder kicks ass. Forget about anything under windows, mencoder does the job and does it damn well. I have *never* had a pleasant experience with video encoding with windows. I've done it, I've done video editing, but I hate it.
In terms of the 'guarantees' that directshow gives about enabling all media players to play all the content you want, what about QuickTime (Sorenson in particular), realmedia, vivo, fli, ogm, etc? Some can be forced to work with work, but mplayer can do all of this out of the box. MPlayer/MEncoder has the capability to be the core of the most robust and capable media framework of any platform, if they would only expose the functionality in a more programmer-friendly way than stdin and specifying window ids... By the same token, xine would take off more if the had mplayer's format and codec support, but I think that would take more work.
Ok, mplayer is best in terms of format support. And it functions perfectly in fullscreen and, by extension, in a set-top box capcity (input.conf is a godsend).
Xine is ok.... But the interface, as he says, is a piece of crap. Now enter totem. Beautiful, standard interface for a pretty decent backend, based on gnome2. Of course, he says gnome2 is a piece of crap, but I have no idea why. I personally use mplay and WindowMaker most of the time, but think Gnome2 is decent. The whole rant about exra verbose stuff being printed to the terminal is stupid. The intent is that 'novice' users have it spawned from a file manager, and the output is therfore never seen. The output is important for debugging. His misunderstanding regarding libdvdcss and xine is also kinda annoying. You need an extra xine plugin to play encrypted dvds because the xine project is scared of legal issues with shipping css code.
As an aside, I *strongly* agree with Makali's included comment regarding audio-cock technology for people who think "Skins!!! kick ass, I'll use them". Ugh. Xmms/Winamp/etc skins arent so bad, they keep the interface consitent in terms of buttons and can provide a pleasing look that is just not possible with the standard toolkit widgets out there (they are designed with larger interface elements in mind than is necessary for such an app). But xine and mplayer, where buttons change position and functionality depending on which you use... That is just annoyin as hell.. I'm there to watch a *movie*, not the interface. MPlayer's gui is a piece of crap, but I use the command line.
Overall, I think he should first take xine and put dvdnav in (which I think picks up on dvdcss automatically, but can't reember for sure), then install totem (once gnome2 bigotry is put aside) and try that.
What I would love is for mplayer's excellent media processing core to be incorporated into a clean, spearate library so developers can more easily write decent, well working frontends. The use of feeding data to mplayer's stdin to control playback and specifying a window id to redirect the display is extremely klunky compared to a nice API, where a great deal more functionality can be exposed.
Whether it is slot or socket is just a matter of how the pins are arranged and designed. It doesn't mean anything fundamental. The PII/III design proves this. It included no more functionality than modern socket processors (some extra wafer, but nothing fundamental). It just gave more room to put the L2 cache in and provided more area for heat dissipation. The way it is packaged means nothing.
In this case, a socket format would only make matters worse. One advantage to being on a card is that both sides of the card have airflow, dissipating heat. For the most part, a video card is a GPU and memory. Other stuff figures in, but the problematic part with the FX is the GPU cooling requirements. The presence of extra memory isn't the problem. The best solution would be a spec that *requires* more space between the AGP slot and nearest PCI slot. The rule of thumb for a long time has been that a PCI card next to the AGP slot is bad, this design simply changes that rule of thumb into a hard requirement. It seems sloppy for external power and a waste of PCI expansion, but a socket format won't fix anything.
Problem is that the orientation of the design forces it to be towards PCI slots on every motherboard out there. It's more like having a thick power brick with an orientation requirement that defies the design of the power strip (which I have seen a few times).
Looks like they've taken damage and are leaking pixie dust. Oh no! Tinkerbell's going down!
Heh, just a memory of MST3K and the cheesy effects of some movie... How can you not laugh your ass off after seeing that 'actual picture'. They should have stuck with weird blurry blobs they could blame on poor atmosphere/camera focus, this is so ridiculous. Why is this not 'it's funny, laugh'?
Well, that wasn't what drove them down. I used altavista up until google came along. Hell, it could be discovered that google does the same thing (which they positively don't), and while we here would complain and be shocked, some going to boycott, it wouldn't kill googl. Not so long as people get what they want, they won't care that much about the ethics. Would a lot of businesses be around today if the public had a zero tolerance for bad behavior?
What killed so many search engines is that you almost never ever got highly relevant links in the first 2, 3, or more pages of results. What I liked about altavista was that while the order was as crappy as other engines, it tended to be more complete set of results. Google did it right, and is truly an example of the best technology winning out.
Re:Easy to use gentoo or Freebsd??
on
Ark Linux
·
· Score: 2
Strange, I have had a great deal of unhindered success with Gentoo. Strange I say about devfs, that has been flawless. Devfs is a damned good and correct idea, only see entries for which there is usable hardware, and don't waste inodes on dev entries. Very cool.
Now/boot, if you will look, by default of noauto in the fstab options. For most efficient use of space,/boot is ext2 (at least for me), and/boot needs to be mounted only at kernel changes, so it makes sense. Sorry if I insult your intelligence, but that is the unique thing about typical/boot in Gentoo.
Re:Four years and half too late.
on
Ark Linux
·
· Score: 5, Insightful
Wow, 'our moderator' singular, fixed position. My how the times change.
Offtopic, but fyi, the phrase 'for all intensive purposes' doesn't make much sense. I believe you should have said 'for all intents and purposes', which is the common phrase which sounds most like what you said. Though redundant, it at least makes sense.
Someone even has a web page dedicated to this very type of error: http://www.wsu.edu:8080/~brians/errors/int ensive.h tml
As much as I loved OrborOSX, I have to say this was very much needed. One, the integration is even smoother with Apple's X11, and secondly, acceleration for 2D and 3D operations was very needed.
Is the answer. I don't even use it under windows (Zoomplayer is better). Outside of Windows, WMP becomes completely worthless.
Have you ever tried WMP on OSX? Pathetic codec support. It is clearly packaged to provide the least MS can get away with in supporting their server side products. I have a handful of ASFs and WMVs it can play, but not a single avi (even the common, non-divx codecs). It only supports codecs endorsed by MS to run from MS streaming servers.
Apart from codec support, the UI is crap compared to other programs for my use. I have set up mplayer to do seek, volume control (2 wheel mouse), pause, and play all without the keyboard or need to have the mouse on any surface while playing back in fullscreen mode. The GUI part of mplayer isn't that good, but I never use those if I can avoid it anyway, too inefficient. I don't have to deal with a klunky keyboard on my set-top box. I don't have to fork over cash for a remote control setup. Sure, it would beat Realplayer, but pretty much anything would. I'm still not happy about realplayer sucking so much. If only mplayer could seek in realmedia streams...
Well, there *is* support for anything WMP9 would play and more in mplayer. Which brings me to the next point, Realmedia (and now even most all Quicktime) is also supported (though Realmedia lacks seek in mplayer).
If you absolutely need seek, and want a realplayer that supports xv and fullscreen, there is a realone 'alpha' for linux that is pretty stable. The UI still sucks ass (no keyboard shortcut for ff/rw, dammit), but the video performance is good.
Personally I love mplayer as I have mapped all the play control functions to mouse functions that don't require the mouse to be moved, only that I can spin the wheels (2, one for seek, one for volume), and click a mouse button for pause. Don't want to mess with a keyboard while watching things through TV-out, and don't want to fork over the cash for a remote that would just be redundant.
Xine is cool, and was the first to have open source sorenson decoding, but on average mplayer gets the features faster. The gui is crap for those who care, but for full-screen operation with highly customizable controls (a must for set-top operation), mplayer can't be beat. Of course only through totem does xine have a decent interface. If only mplayer would provide an api for frontend writers, the biggest complaint about mplayer could be solved without the main development team worrying about it. Control through a pipe is good and all, but to be able to harness the decoding capabilities however we see fit would be fantastic.
Slashdot Mirror
You can't say boradband via cable companies has a doomed future based on your singular personal experience, it just seemed ludicrous.
Ultimately, I think both technologies have about equal potential, with one beating the other depending on where you are.
DSL is offered by companies that typically have more experience in offering high-bandiwdth internet connections, so service and reliability I think is indeed, mostly better with DSL on average. However, as Cable companies have learned their lessons, it becomes harder and harder to distinguish the two. DSL still seems to typically offer better latency (around my area, at least), but cable services offer better throughput.
To home consumers, the fine details don't make much of a difference. Availability makes all the difference. I can't get DSL at any decent rate. None of my family can get it at all. I do, and my family could, all have cable modem at 2 megabit downstream, 768k up. In addition to that, a sort of unintended benefit of cable modem service is that there is a good chance the installer won't bother with a video filter and you get free cable with the net connection. I know, not a fair comparison because cable companies hate this, but realistically speaking, it must be considered.
No, 386 was the first '32 bit' chip of Intel's line. The pentium marked the first processor which had a name that could be copyrighted, so Cryix and AMD couldn't produce clones under the name name (as they had done with earlier processors (my 286 was actually an AMD processor).
Don't know if it is rot, but a disc of mine in an expensive box set is delaminating or something around the outer edge. It's really annoying. Since replacement means about a hundred dollar investment, I decided to contact the manufacturer to see if I could do an exchange (no warranty, beyond the retailers money-back guarantee) and the answer was of course, no, not so long as there is no mass reported defect, they will not do replacements.
Now I think movie studios shouldn't be able to keep things going as they are. If we are truly being sold the right to view the contents, and not the disc and its contents themselves and are denied a sufficient legal backup mechanism, we should be able to trade in bad discs for good discs, especially if they are still being actively pressed.
I truly understand they have no obligation, but it makes me mad that they fight against us being able to back up the media, yet provide no alternative when a disc goes bad. It would be one thing if available as a 10 dollar disc, but these $100+ DVD Box Sets are really annoying when one disc goes wacked..
I had an AI class with him. In one of those classes, he demoed this stuff. It was using the Unreal Tournament engine. Two demos he gave. One, two characters were put in a maze, without scripted moves and only knowledge of their immediate surroundings, and the knowledge of where they want to be and how to open doors (seemed like they had to go press and hold triggers or something, it's been awhile. Wasn't too terribly exciting by itself. This is along the lines I think when I think about traditional AI research, but doesn't strike me as very useful to a game..
The other was the user walked around an aquarium, and fish swam however they saw fit. The interesting part was the plaques that gave information about the animals. There was a database of factoids, and some rules about grammar and various languages, but no pre-written plaques. When viewed, the plaques contained a generated paragraph which presented some of the facts. The paragraph was always different every time you looked, and it could do it in several languages. This demonstrated how it could be used in an educational application, but also how it could be used to make NPC dialog more dynamic and realistic ('Times are Tough...').
The ultimate goal was to have a few stated conditions, and maybe end conditions, and allow the gamer full control over the environment, and have the story adapt to the conditions the player causes, if the story as planned to that point becomes impossible due to a players actions (say player is on an island with only one boat around, and he is expected to go to another island, but destroys the boat instead), a new story is generated on the fly. The computer adlibs. Also, if the game absolutely, positively requires that the player go to another island, some mechanisms can be put in, such as if the boat is not there, helicopter or another boat comes in and the occupants conveniently walk away from it.
He described the goal to be a fully interactive story, that is never the same twice through. A very interesting boon to RPGs as we know it. The aquarium demo at least showed promise for better NPC dialog. I don't know if they have anything to show the evolving story yet though...
Ugh.... I'll admit that mplayer has done a lot, but do not give them credit for QuickTime. Apple invented it. The container format is well known and published, and linux supported before mplayer even existed (xanim could parse .mov). Now if you are talking about the source-available decoder for Sorenson, Xine had that first. With that, about 80-85% of the .movs out there became playable under linux (not just x86 linux). I will admit that mplayer seems to be the first to get the QuickTime binary codecs (audio of the 15-20% .movs out there) to work under x86 linux.
They were not the first to use binary video codecs from windows (as some have claimed in this discussion), that honor belongs to either avifile or xmps (I can't remember which or if they were interdependent, but avifile remains alive..).
MPlayer and xine have been pretty competitive in terms of codec support, but only through cooperation. MPlayer brings a lot of good and unique things to the table in terms of an application suite (mplayer and mencoder), but they did not invent everything they use. They *have* done a kick ass job of bringing everything together to have the most capable player (what else can play so many formats to so many output devices?). Technologically speaking, the thing lacking is a clean plugin architecture, and a nice thing would be a clean API capability (ala xine-lib). Legally speaking, I'm quite sure any number of companies (MS, Apple, Sorenson, Realnetworks, others) could give the big smack down to mplayer if they wanted. Then again, they could also smack down avifile, xine, Gentoo, and any number of other projects that do not occur to me right now. They are wishy-washy on the GPL I think, but it seems to be more a matter of support than anything. They will make a best-effort attempt at support, unless you got a binary precompiled, and the GPL states that no support is required at all.
If you poke around you can find slick cases and barebones kits (like the Shuttle systems). I've seen cases that look similar to the KISS case.
The problem with the 'firmware updates' is that it can only do so much. When relying on dedicated chips for decoding, those chips do a damn good job at efficiently playing back what they are designed for. As a general purpose processor, it would suck. It might do well against new, but similar codecs, but if a huge new thought of how to compress video comes along, no firmware update in the world could make those dedicated chips play it.
Yes, a 1.5 GHz system is overkill for movie playback, but it can more easily adapt than a system that requires special hardware to do the hard stuff.
Yes, but I know a lot of sites that wait on the full service packs. Testing every hotfix that comes out of MS is not time effective. The policies I generally see is that companies first wait a month after release to see if anything bad happens with the SP, then take a couple of weeks in a test configuration to make sure nothing site-specific should happen, then install SP if fine. The SP3 was only released recently.
The problem is that with MS, there are two levels of fixes, hotfixes and service packs. hotfixes could be anything from a slight cosmetic bug that isn't worth the time to worry about in a professional environment, to a critical vulnerability. There really isn't a huge sense of urgency at the word 'hotfix'. They really need a separate category of 'critically needed patch' for stuff that can cause problems of this scale if left unpatched.
But they said only 'supports' PAL or NTSC... not that it was tested with PAL and NTSC, that is the part that is incorrect and misleading.
As exciting as this is, this could mean bad things. Are there GPL violations happening?
I really have to wonder why a company would release a product like this based on Linux rather than a BSD. Either way there is a significant amount of work to create drivers for the device they choose, but with a BSD they never have to worry about the license.
I love Linux, but if I had to make a device like this with hardware not yet supported by either codebase to sell to consumers, I would choose BSD and save a legal headache down the road.
No, this is simply wrong.
.ogm with MPEG-4 (Whether it be DivX or whatever) video, vorbis audio, and a text stream if subtitles are needed. I really wish this sort of format would become more prominent.
The divx movies you may download can really suck ass. The same is true of MPEG-1 (the tech behind VCDS). If you get MPEG-1 up to VCD bitrates, the quality becomes 'acceptable', but frequently you are left with blocky artifacts (*especially* when there is Text overlayed on the image encoded with the Video as is the case with credits and subtitles).
DIVX encoded at the same bitrate as VCDs are really blow VCD away. Much fewer artifacts, text does not distort background, etc. Try breaking out mencoder (or whatever the tool of the day is in Windows today) and making your own samples from DVDs, using the same bitrate for your MPG and DivX output. The results will be crystal clear.
As an aside, my favorite format is
With this review, hard to take them seriously. First they say that it is restricted to PAL or NTSC, and that PAL is 720x576 *dpi*. dpi means dots per inch, drop it because it is wrong, unless you have a 1-cubic-inch pal screen, and the i means 'cubic inch'.....
Then, correctly notes that 1280x720 and 1920x1080 are supported, but the phrasing seems to suggest that it is being scaled to PAL or NTSC, which is wrong. This is a progressive-scan device, and those are HDTV resolutions. They have already on the second page made a *huge* mistake about a fundamental function of the player.
And of course I love that the DVD-ROM is connected via a DIE cable... he he... I know, a simple typo, but one with amusing connotations.
On the subject of the player itself... I'm not so sure it will hit it off with the target audience. Most home users don't care that much about DivX, because making them is very difficult and downloading is hard because it requires too much bandwidth, servers don't give away enough hosting space for movies, and the places where DivX movies can be downloaded are rather intimidating to common users (i.e. IRC). People who do work with such formats frequently are aware of the nature of the media that makes them think twice about dedicated hardware purchases. The formats themselves sometimes change in incompatible ways, and also a format's dominance in tenuous at best. Most are also technical enough to realize that for not much more money they can piece together a decent PC with TV out for not much more that will have faster, general purpose processors that can adapt easy to new formats and new delivery mechanisms. This thing only takes Discs, but many people would prefer to use SMB or NFS... If anything changes, a computer is easy to reconfigure, a set-top box... no....
I wouldn't be too excited about the Helix project. It is still mostly vapor and even if and when it reaches maturity, it will only *possibly* support formats aside from realmedia. Not a good prospect for a framework.
Of the three links you supplied, only one even exemplifies a real 'framework', gstplayer is a gstreamer based player, the rest are standalone. I would say there are three projects out there with the makings of a good framework.
Gstreamer is the project that most directly addresses the need for a true framework, that is a framework that provides encoding, decoding, and playback functionality. The problem is that file format and codec support are dismal compared to the alternatives, and as such it doesn't attract developers. Also, alternatives are 'good enough', so there isn't enough interest in writing the plugins necessary to make gstremer an acceptable framework.
Xine abstracts the media playback functionality into a library, so it still could be considered kind of a framework. Problems are that it lacks the capability to create media and that the codec and format support is only 'pretty good.'
Now mplayer, it can play nearly every codec and format under the sun. It also has the capability to encode, decode, and play media. One problem is that it is very much a standalone application, so it can't be considered a framework, only an application that implements nearly everything a framework should have. If the backend were abstracted from the application and that backend made available through an API (probably only supporting SDL for video and audio output for the most cross-platform framework), then you are starting to get somewhere. Of course, it still lacks a good flexible plugin architecture that allows post-install/compile time drop-in support for new file formats and codecs (though I may be mistaken about this).
So between the three you could have an uber-framework. If I had time or was being paid to architect a framework for linux, I would extend mplayer's code to fit the purpose and provide some glue to SDL for a truly cross-platform framework.
Common codec interface? Well that is a hard thing to really define, any of he systems out there can be considered a 'standard' codec framework. Due to the nature of linux, it would be up to major distros to pick their favorite and run with it.
That said, if mplayer would separate the backend operations into a independent library (like xine does), I have no doubt that it would be rapidly adopted as the 'standard'. Within a week of work being done, I would bet that an application like totem would spring up for mplayer, providing the traditional movie playback application people expect (with a newbie-friendly interface). And mencoder kicks ass. Forget about anything under windows, mencoder does the job and does it damn well. I have *never* had a pleasant experience with video encoding with windows. I've done it, I've done video editing, but I hate it.
In terms of the 'guarantees' that directshow gives about enabling all media players to play all the content you want, what about QuickTime (Sorenson in particular), realmedia, vivo, fli, ogm, etc? Some can be forced to work with work, but mplayer can do all of this out of the box. MPlayer/MEncoder has the capability to be the core of the most robust and capable media framework of any platform, if they would only expose the functionality in a more programmer-friendly way than stdin and specifying window ids... By the same token, xine would take off more if the had mplayer's format and codec support, but I think that would take more work.
Ok, mplayer is best in terms of format support. And it functions perfectly in fullscreen and, by extension, in a set-top box capcity (input.conf is a godsend).
Xine is ok.... But the interface, as he says, is a piece of crap. Now enter totem. Beautiful, standard interface for a pretty decent backend, based on gnome2. Of course, he says gnome2 is a piece of crap, but I have no idea why. I personally use mplay and WindowMaker most of the time, but think Gnome2 is decent. The whole rant about exra verbose stuff being printed to the terminal is stupid. The intent is that 'novice' users have it spawned from a file manager, and the output is therfore never seen. The output is important for debugging. His misunderstanding regarding libdvdcss and xine is also kinda annoying. You need an extra xine plugin to play encrypted dvds because the xine project is scared of legal issues with shipping css code.
As an aside, I *strongly* agree with Makali's included comment regarding audio-cock technology for people who think "Skins!!! kick ass, I'll use them". Ugh. Xmms/Winamp/etc skins arent so bad, they keep the interface consitent in terms of buttons and can provide a pleasing look that is just not possible with the standard toolkit widgets out there (they are designed with larger interface elements in mind than is necessary for such an app). But xine and mplayer, where buttons change position and functionality depending on which you use... That is just annoyin as hell.. I'm there to watch a *movie*, not the interface. MPlayer's gui is a piece of crap, but I use the command line.
Overall, I think he should first take xine and put dvdnav in (which I think picks up on dvdcss automatically, but can't reember for sure), then install totem (once gnome2 bigotry is put aside) and try that.
What I would love is for mplayer's excellent media processing core to be incorporated into a clean, spearate library so developers can more easily write decent, well working frontends. The use of feeding data to mplayer's stdin to control playback and specifying a window id to redirect the display is extremely klunky compared to a nice API, where a great deal more functionality can be exposed.
Whether it is slot or socket is just a matter of how the pins are arranged and designed. It doesn't mean anything fundamental. The PII/III design proves this. It included no more functionality than modern socket processors (some extra wafer, but nothing fundamental). It just gave more room to put the L2 cache in and provided more area for heat dissipation. The way it is packaged means nothing.
In this case, a socket format would only make matters worse. One advantage to being on a card is that both sides of the card have airflow, dissipating heat. For the most part, a video card is a GPU and memory. Other stuff figures in, but the problematic part with the FX is the GPU cooling requirements. The presence of extra memory isn't the problem. The best solution would be a spec that *requires* more space between the AGP slot and nearest PCI slot. The rule of thumb for a long time has been that a PCI card next to the AGP slot is bad, this design simply changes that rule of thumb into a hard requirement. It seems sloppy for external power and a waste of PCI expansion, but a socket format won't fix anything.
Problem is that the orientation of the design forces it to be towards PCI slots on every motherboard out there. It's more like having a thick power brick with an orientation requirement that defies the design of the power strip (which I have seen a few times).
Looks like they've taken damage and are leaking pixie dust.
Oh no! Tinkerbell's going down!
Heh, just a memory of MST3K and the cheesy effects of some movie... How can you not laugh your ass off after seeing that 'actual picture'. They should have stuck with weird blurry blobs they could blame on poor atmosphere/camera focus, this is so ridiculous.
Why is this not 'it's funny, laugh'?
'warning, your computer is broadcasting an IP address right now!' hehehe.
Well, that wasn't what drove them down. I used altavista up until google came along. Hell, it could be discovered that google does the same thing (which they positively don't), and while we here would complain and be shocked, some going to boycott, it wouldn't kill googl. Not so long as people get what they want, they won't care that much about the ethics. Would a lot of businesses be around today if the public had a zero tolerance for bad behavior?
What killed so many search engines is that you almost never ever got highly relevant links in the first 2, 3, or more pages of results. What I liked about altavista was that while the order was as crappy as other engines, it tended to be more complete set of results. Google did it right, and is truly an example of the best technology winning out.
Strange, I have had a great deal of unhindered success with Gentoo. Strange I say about devfs, that has been flawless. Devfs is a damned good and correct idea, only see entries for which there is usable hardware, and don't waste inodes on dev entries. Very cool.
/boot, if you will look, by default of noauto in the fstab options. For most efficient use of space, /boot is ext2 (at least for me), and /boot needs to be mounted only at kernel changes, so it makes sense. Sorry if I insult your intelligence, but that is the unique thing about typical /boot in Gentoo.
Now
Wow, 'our moderator' singular, fixed position. My how the times change.
Offtopic, but fyi, the phrase 'for all intensive purposes' doesn't make much sense. I believe you should have said 'for all intents and purposes', which is the common phrase which sounds most like what you said. Though redundant, it at least makes sense.
t ensive.h tml
Someone even has a web page dedicated to this very type of error:
http://www.wsu.edu:8080/~brians/errors/in
As much as I loved OrborOSX, I have to say this was very much needed. One, the integration is even smoother with Apple's X11, and secondly, acceleration for 2D and 3D operations was very needed.
Is the answer. I don't even use it under windows (Zoomplayer is better). Outside of Windows, WMP becomes completely worthless.
Have you ever tried WMP on OSX? Pathetic codec support. It is clearly packaged to provide the least MS can get away with in supporting their server side products. I have a handful of ASFs and WMVs it can play, but not a single avi (even the common, non-divx codecs). It only supports codecs endorsed by MS to run from MS streaming servers.
Apart from codec support, the UI is crap compared to other programs for my use. I have set up mplayer to do seek, volume control (2 wheel mouse), pause, and play all without the keyboard or need to have the mouse on any surface while playing back in fullscreen mode. The GUI part of mplayer isn't that good, but I never use those if I can avoid it anyway, too inefficient. I don't have to deal with a klunky keyboard on my set-top box. I don't have to fork over cash for a remote control setup. Sure, it would beat Realplayer, but pretty much anything would. I'm still not happy about realplayer sucking so much. If only mplayer could seek in realmedia streams...
Well, there *is* support for anything WMP9 would play and more in mplayer. Which brings me to the next point, Realmedia (and now even most all Quicktime) is also supported (though Realmedia lacks seek in mplayer).
If you absolutely need seek, and want a realplayer that supports xv and fullscreen, there is a realone 'alpha' for linux that is pretty stable. The UI still sucks ass (no keyboard shortcut for ff/rw, dammit), but the video performance is good.
Personally I love mplayer as I have mapped all the play control functions to mouse functions that don't require the mouse to be moved, only that I can spin the wheels (2, one for seek, one for volume), and click a mouse button for pause. Don't want to mess with a keyboard while watching things through TV-out, and don't want to fork over the cash for a remote that would just be redundant.
Xine is cool, and was the first to have open source sorenson decoding, but on average mplayer gets the features faster. The gui is crap for those who care, but for full-screen operation with highly customizable controls (a must for set-top operation), mplayer can't be beat. Of course only through totem does xine have a decent interface. If only mplayer would provide an api for frontend writers, the biggest complaint about mplayer could be solved without the main development team worrying about it. Control through a pipe is good and all, but to be able to harness the decoding capabilities however we see fit would be fantastic.