It has all the features of VLC, but is missing quite a bit more.
VLC and any non-DirectShow players on Windows are missing many features - MPC-HC only targets Windows, so it supports Windows-only hardware acceleration, renderers, DirectShow filters, etc.
I don't think MPC-HC has all of the encoding/streaming features VLC does.
No use CCCP like GGP said, Media Player Classic is what CCCP uses to actually play the files, but the CCCP comes with codices to play anything
MPC-HC has built-in decoders for the most important formats (including hardware-accelerated DXVA decoders), does not require installation, and does not install system-wide codecs.
I am definitely not a Linux guy. I primary use OS X and also Windows. I only use Linux (and only RHEL and derivatives) on servers.
Apple products make use of H.264 extensively, and they manage to have avoided issues by specifying the supported video types in the documentation and providing content specifically labelled as compatible with certain devices.
x264 is not a tool that ignorant users can use directly: it is a library or command line encoder.
In any case, one cannot expect out-of-spec video to play on a hardware decoder. DVD players can't decode high definition ATSC-specification video, for example.
Given that AVI is still the most widely used video container
Bullshit. The most widely used video containers are the MPEG-2 containers: transport stream, used by DVB and ATSC (accounting for most digital TV broadcasts), and program stream, used by DVD.
AVI is infrequently used in other situations. Some cameras still create AVI files, and AVI is commonly used for low-quality pirated video. But more and more pirates are choosing modern containers like MKV. AVI is not used for video streaming (WMV, FLV are), and WMV and MP4 account for non-pirate video downloads.
you don't understand the meaning of the word obsolete
AVI is clearly obsolete. It is missing many important features required and implemented by modern video containers. Further development been more or less abandoned by its creator (Microsoft) in favor of newer containers like WMV.
XviD is an MPEG-4 Part 2 implementation; it is one of many.
X264 is a terrible standard
x264 is not a standard at all; it is an encoder for the H.264/MPEG-4 Part 10 standard, which is just as open as MPEG-4 Part 2.
with various files and options breaking support on some devices and programs
This is a necessity; H.264 is suitable for encoding low-bitrate, low-resolution video or high-bitrate, high-resolution video. It is useful for 20 mbit/sec high definition streams, or 256 kbit/sec videoconferencing. The standard defines various levels that various hardware decoders implement.
Other files just won't play at all.
Possibly because they were out-of-spec, or not in a container the player supports. x264 isn't responsible for the user's ignorance.
Hardware DivX support is still more widespread than h.264, although h.264 is finally starting to gain some traction in some hardware, particularly phones and PMP devices.
H.264 support is much more widespread - it's in every Blu-ray player, every recent HD satellite receiver, every recent nVidia and ATI GPU and some recent Intel GPUs.
They go on to explain that DivX quality isn't as good either. I am not sure if that is true or not
The program never supported DivX to begin with; it used XviD. And MPEG-4 Part 2 (the standard XviD implements) is known to be inferior to H.264/MPEG-4 Part 10. H.264 is much more widely used than MPEG-4 Part 2 - in satellite TV, videoconferencing, Blu-ray, etc.
VLC is a poor choice. Media Player Classic Home Cinema supports Windows's DirectShow media playback system, and supports hardware accelerated decoding, hardware accelerated rendering, codecs other than those included with MPC-HC, etc.
Dropping all formats that Windows play by default is IMO a bad decision.
Only Windows 7 will decode XviD or H.264 without extra software. With AVI it would be possible to use this tool to create videos only Windows 7 could play without extra software. But AVI is an obsolete container (which is why Microsoft stopped using it).
HandBrake is the de-facto standard for creating h.264 files on Mac, Linux and Windows systems. You should get to know it; you won't miss that crappy, proprietary DivX.
It's hardly a de-facto standard; it's just another utility using ffmpeg and x264.
It was a private BitTorrent tracker. The torrent files (containing the hashes) were generated by users and uploaded to the site. OiNK tracked the torrents and provided search for its torrents.
What do you mean component just doesn't cut it? I watch HDTV perfectly fine with component cables on my HDTV. In fact, I'm not using HDMI anywhere.
Only HDMI has built-in digital audio, and it's the only way to get digital multichannel audio that isn't encoded as Dolby Digital, DTS, or WMA Pro (in home theater systems). With HDMI, source devices can be connected to a home theater receiver or HDMI switch and a single cable can be connected to the display.
I actually have HDMI audio capable equipment, but use 6 channel analog instead (for my PC).
The Wii is a potential annoyance for those with home theater setups. The only audio output is two-channel analog and it's through the video port. Unless the HT receiver supports pass-through for the kind of video being used, special cabling is required to hook up the Wii to a TV and to a home theater system.
But at least it's digital right, and thus retains it's crisp color no matter what?
Wii output is analog. 480p is not interlaced, and at 60 Hz, this means there are 60 full frames per second.
And higher definition than, say, normal TV broadcasts?
480p is potentially higher definition than 480i broadcasts, and possibly more efficient for transmitting 24 fps content. But since lots of TV content is progressive 24 fps, progressive 30 fps, or interlaced 60 fps, there isn't much difference between 480p and 480i (at least when video is processed correctly).
I've stopped caring about advances in graphics since about the time of the PS2.
I found PS2 graphics in some games underwhelming, primarily because many of them seemed to disable anti-aliasing/image quality enhancements for higher frame rates. AA made graphics look better on the Dreamcast, which was actually released before the PS2.
but if you look fundamentally at the games, I don't think the improved graphics make them any more fun
There is one important exception you might consider: frame rate. Games that can't keep the frame rate around 30 fps are rather annoying to me, especially when the frame rate drops during action.
I think having a high frame rate is important in racing games - it makes games like Burnout series, which aims to render at a constant 60 fps, much more enjoyable.
For typical modern hard disk and CPU speeds, it takes about a single whole core to encrypt/decrypt the data at full bandwidth. That's definitely not a negligible loss. Business users may be not trying to run make -j like we do, but they'll still suffer significantly decreased battery life.
I've used full disk encryption for the past four years. Overall, the loss in performance is negligible unless performing I/O heavy tasks such as running virtual machines or loading a full-sized hibernation image. Running VMs was an annoyance on the 945[GP]M and Core Duo laptops I used, which were limited to 2 or 3 GB of RAM and only ran 32-bit software. The decrease in battery life is minimal, especially with lots of RAM. I do build software with make -j on a laptop with full disk encryption and performance is just fine.
Wait a minute, does that mean Facebook groups like "I just study before the exam day.." are not meant as a joke?
It is quite easy for intelligent students to excel in many US undergraduate programs with minimal effort. Many students can succeed without lots of studying.
The problem is, because of currency manipulations, that foreign governments are essentially subsidizing their car companies so that they can export to the USA. Guys in Japan are living literally in shoebox sized cubbyholes with -nothing-, so they can send us made in Japan stuff.
Just how many Toyota/Nissan/Honda vehicles sold in North America are made in Japan?
I don't think I've driven a Japanese car that wasn't made in the United States or Canada.
I know of no one outside of a Google employee that runs Linux on any device they own.
None of the non-tech savvy have a Linux based router, and the tech-savvy people I know that use something custom use a BSD.
I've yet to come across a Linux based WAP or router in the real world.
Many consumer network appliances do run Linux, but don't advertise it. What operating system a device uses is meaningless to most end users, and many devices don't have a published method of changing the software running on the device and don't expose any Linux-specific functionality. Some effort is required to find out if the device even runs Linux.
To the creators of these devices, Linux is often just the best choice given current open source and proprietary software: it ends up being cheaper than licensing a proprietary operating system and cheaper than developing a custom one. Some treat GPL compliance as an annoyance, and do little more than uploading the GPL code used in the device to a web server. They might not provide any meaningful way of modifying and using that code on the device.
The first few years of production of the popular Linksys WRT45G used Linux, but later revisions switched to VxWorks. This was a very popular router.
Open-source code (possibly including Linux) is used in other consumer electronic devices too. Open-source licenses are sometimes printed in the manuals of TVs, digital cameras/camcorders, etc.
There are more than 2 billion Linux machines out there and pretty much every Windows home user has a dinky little Linux based modem and firewall thingy for his desktop to hide behind.
Many might run Linux, but many use closed source embedded operating systems. The vendors would easily switch to something else. For example, I believe Linksys switched from Linux to VxWorks in one model because they could get away with including use less memory.
To most end users, the fact that the device uses Linux simply doesn't matter. They wouldn't notice if the device used some other operating system that had the same functionality.
But this doesn't solve the problem of knowing a binary you download was created using the published source code - unless the binary was compiled by someone you trust.
MD5 hash for the win! If your hash doesn't match the published hash, something's up.
MD5 hash of what? The software author's published binary?
In order to verify that the published source code is the same as the published binary, the compilation environment would always need to produce the same binary given the same input.
Already happening on several platforms. MS Office VBA, MacOS, etc. Unsigned code is allowed, but requires a user's approval to a warning that the publisher is unknown.
Certificate signing already works. But this doesn't solve the problem of knowing a binary you download was created using the published source code - unless the binary was compiled by someone you trust. In the case of all software being compiled and signed by the same organization (as is the case for the applications in a typical Linux distribution), this isn't an issue.
Would require an app that asks for rights to contact the network
Many applications have legitimate reasons to access the network. And if one day the server responds with something triggering a backdoor...
and network traffic can be monitored. Somebody will notice.
Network traffic can be monitored, but is it? How many people actually pay attention, if the application has a legitimate reason to connect to the network? How many people go through the effort of intercepting encrypted traffic?
Open source is another way to stop malware... not every user looks at the source, but enough curious ones will put out the warning should anything not be as its marked.
How do you know the binary you install is the same as the source? Unless you propose that all software be compiled and signed by a trusted authority or be compiled on the end user's device...
And if someone introduces the ability to download and execute arbitrary code, perhaps via a clever and well-hidden exploit?
Slashdot Mirror
VLC and any non-DirectShow players on Windows are missing many features - MPC-HC only targets Windows, so it supports Windows-only hardware acceleration, renderers, DirectShow filters, etc.
I don't think MPC-HC has all of the encoding/streaming features VLC does.
MPC-HC has built-in decoders for the most important formats (including hardware-accelerated DXVA decoders), does not require installation, and does not install system-wide codecs.
I am definitely not a Linux guy. I primary use OS X and also Windows. I only use Linux (and only RHEL and derivatives) on servers.
Apple products make use of H.264 extensively, and they manage to have avoided issues by specifying the supported video types in the documentation and providing content specifically labelled as compatible with certain devices.
x264 is not a tool that ignorant users can use directly: it is a library or command line encoder.
In any case, one cannot expect out-of-spec video to play on a hardware decoder. DVD players can't decode high definition ATSC-specification video, for example.
Bullshit. The most widely used video containers are the MPEG-2 containers: transport stream, used by DVB and ATSC (accounting for most digital TV broadcasts), and program stream, used by DVD.
AVI is infrequently used in other situations. Some cameras still create AVI files, and AVI is commonly used for low-quality pirated video. But more and more pirates are choosing modern containers like MKV. AVI is not used for video streaming (WMV, FLV are), and WMV and MP4 account for non-pirate video downloads.
AVI is clearly obsolete. It is missing many important features required and implemented by modern video containers. Further development been more or less abandoned by its creator (Microsoft) in favor of newer containers like WMV.
This is not informative.
XviD is an MPEG-4 Part 2 implementation; it is one of many.
x264 is not a standard at all; it is an encoder for the H.264/MPEG-4 Part 10 standard, which is just as open as MPEG-4 Part 2.
This is a necessity; H.264 is suitable for encoding low-bitrate, low-resolution video or high-bitrate, high-resolution video. It is useful for 20 mbit/sec high definition streams, or 256 kbit/sec videoconferencing.
The standard defines various levels that various hardware decoders implement.
Possibly because they were out-of-spec, or not in a container the player supports. x264 isn't responsible for the user's ignorance.
Hasn't happened to me; but I occasionally find myself using MPC-HC in VMware because I can't get VLC or any other Mac player to play a file.
H.264 support is much more widespread - it's in every Blu-ray player, every recent HD satellite receiver, every recent nVidia and ATI GPU and some recent Intel GPUs.
AVI is obsolete; Microsoft uses the WMV container now, and has for about a decade now... DOCX is not obsolete.
The program never supported DivX to begin with; it used XviD. And MPEG-4 Part 2 (the standard XviD implements) is known to be inferior to H.264/MPEG-4 Part 10. H.264 is much more widely used than MPEG-4 Part 2 - in satellite TV, videoconferencing, Blu-ray, etc.
VLC is a poor choice. Media Player Classic Home Cinema supports Windows's DirectShow media playback system, and supports hardware accelerated decoding, hardware accelerated rendering, codecs other than those included with MPC-HC, etc.
Only Windows 7 will decode XviD or H.264 without extra software. With AVI it would be possible to use this tool to create videos only Windows 7 could play without extra software. But AVI is an obsolete container (which is why Microsoft stopped using it).
It's hardly a de-facto standard; it's just another utility using ffmpeg and x264.
It was a private BitTorrent tracker. The torrent files (containing the hashes) were generated by users and uploaded to the site. OiNK tracked the torrents and provided search for its torrents.
Hardware costs were probably minimal compared to bandwidth & hosting expenses...
Only HDMI has built-in digital audio, and it's the only way to get digital multichannel audio that isn't encoded as Dolby Digital, DTS, or WMA Pro (in home theater systems).
With HDMI, source devices can be connected to a home theater receiver or HDMI switch and a single cable can be connected to the display.
I actually have HDMI audio capable equipment, but use 6 channel analog instead (for my PC).
The Wii is a potential annoyance for those with home theater setups. The only audio output is two-channel analog and it's through the video port. Unless the HT receiver supports pass-through for the kind of video being used, special cabling is required to hook up the Wii to a TV and to a home theater system.
Wii output is analog. 480p is not interlaced, and at 60 Hz, this means there are 60 full frames per second.
480p is potentially higher definition than 480i broadcasts, and possibly more efficient for transmitting 24 fps content. But since lots of TV content is progressive 24 fps, progressive 30 fps, or interlaced 60 fps, there isn't much difference between 480p and 480i (at least when video is processed correctly).
I found PS2 graphics in some games underwhelming, primarily because many of them seemed to disable anti-aliasing/image quality enhancements for higher frame rates. AA made graphics look better on the Dreamcast, which was actually released before the PS2.
There is one important exception you might consider: frame rate. Games that can't keep the frame rate around 30 fps are rather annoying to me, especially when the frame rate drops during action.
I think having a high frame rate is important in racing games - it makes games like Burnout series, which aims to render at a constant 60 fps, much more enjoyable.
I've used full disk encryption for the past four years. Overall, the loss in performance is negligible unless performing I/O heavy tasks such as running virtual machines or loading a full-sized hibernation image. Running VMs was an annoyance on the 945[GP]M and Core Duo laptops I used, which were limited to 2 or 3 GB of RAM and only ran 32-bit software. The decrease in battery life is minimal, especially with lots of RAM. I do build software with make -j on a laptop with full disk encryption and performance is just fine.
It is quite easy for intelligent students to excel in many US undergraduate programs with minimal effort. Many students can succeed without lots of studying.
Just how many Toyota/Nissan/Honda vehicles sold in North America are made in Japan?
I don't think I've driven a Japanese car that wasn't made in the United States or Canada.
Many consumer network appliances do run Linux, but don't advertise it. What operating system a device uses is meaningless to most end users, and many devices don't have a published method of changing the software running on the device and don't expose any Linux-specific functionality. Some effort is required to find out if the device even runs Linux.
To the creators of these devices, Linux is often just the best choice given current open source and proprietary software: it ends up being cheaper than licensing a proprietary operating system and cheaper than developing a custom one. Some treat GPL compliance as an annoyance, and do little more than uploading the GPL code used in the device to a web server. They might not provide any meaningful way of modifying and using that code on the device.
The first few years of production of the popular Linksys WRT45G used Linux, but later revisions switched to VxWorks. This was a very popular router.
Open-source code (possibly including Linux) is used in other consumer electronic devices too. Open-source licenses are sometimes printed in the manuals of TVs, digital cameras/camcorders, etc.
Many might run Linux, but many use closed source embedded operating systems. The vendors would easily switch to something else. For example, I believe Linksys switched from Linux to VxWorks in one model because they could get away with including use less memory.
To most end users, the fact that the device uses Linux simply doesn't matter. They wouldn't notice if the device used some other operating system that had the same functionality.
I addressed this:
MD5 hash of what? The software author's published binary?
In order to verify that the published source code is the same as the published binary, the compilation environment would always need to produce the same binary given the same input.
Certificate signing already works. But this doesn't solve the problem of knowing a binary you download was created using the published source code - unless the binary was compiled by someone you trust. In the case of all software being compiled and signed by the same organization (as is the case for the applications in a typical Linux distribution), this isn't an issue.
Many applications have legitimate reasons to access the network. And if one day the server responds with something triggering a backdoor...
Network traffic can be monitored, but is it? How many people actually pay attention, if the application has a legitimate reason to connect to the network? How many people go through the effort of intercepting encrypted traffic?
How do you know the binary you install is the same as the source? Unless you propose that all software be compiled and signed by a trusted authority or be compiled on the end user's device...
And if someone introduces the ability to download and execute arbitrary code, perhaps via a clever and well-hidden exploit?