Thursday, September 22. 2005
How "HD ready" is Linux?
Recently I've been playing around with testing HD videos based on the H264-codec. For those who don't know, HD videos are video files with very high quality and resolution. The upcoming HDTV television standard is based on that (which is quite problematic due to the HDCP copy protection, but that's not the topic of this article).
Apple recently released Quicktime 7 to play HD mov files, Microsoft supports WMV HD videos in it's Media Player. HD videos are available in three qualities, 420p, 720p and 1080p.
For the system requirements of 720p-videos in Quicktime, Apple says:
2.8 GHz Pentium 4 or faster processor, At least 512MB of RAM, 64MB or greater video card
And even more for 1080p:
3.0 Ghz Intel Pentium D (dual-core) or faster processor, At least 1GB of RAM, 64MB or greater video card
As my system doesn't really fit these requirements (1,5 GHz Pentium M, 512MB RAM, 128 MB video card), I was quite impressed that I could run a bunch of videos in quite reasonable speed and quality with linux software.
Trying out various players the cvs-version of mplayer did it best for me. Pretty much every player available on linux uses ffmpeg for H264-decoding, so they should do all, but there have been a bunch of important fixes in ffmpeg recently and this is quite the easiest way to get a recent ffmpeg-version running.
Running mplayer with these options gave me the best results:
mplayer -lavdopts skiploopfilter=all -framedrop -fs [videofile]
-fs is for playing the video in fullscreen (you don't want to play HD videos in a window), -framedrop let's mplayer skip frames when your system is too slow (else it will be out of sync very fast, some framedrops don't really hurt). About the -lavdopts skiploopfilter=all, I don't really know the details of video codecs, as far as I understood, this disables some steps in the decoding that shouldn't be needed on most videos, but can result in wrong decoding. I couldn't see any differences, it improves the speed quite a lot.
Now I could play all 420p and 720p videos at pretty reasonable speed. I especially liked this BBC one showing african animals and landscape. For the 1080p ones, it differs. This Trailer for "The Island" runs pretty well, others don't.
Bugs: Some videos cause mplayer to crash. On my radeon, the mplayer xv output has a problem with the large videos (width of 1900) displaying a pink block on the right side. I've written bug-reports and hope those things get resolved soon.
To sum it, I'd call linux pretty much "HD ready", beside some small issues it plays the HD stuff very well and with impressive performance.
Places to get HD videos:
Microsoft WMV HD Content Showcase
Apple HD Gallery
Apple recently released Quicktime 7 to play HD mov files, Microsoft supports WMV HD videos in it's Media Player. HD videos are available in three qualities, 420p, 720p and 1080p.
For the system requirements of 720p-videos in Quicktime, Apple says:
2.8 GHz Pentium 4 or faster processor, At least 512MB of RAM, 64MB or greater video card
And even more for 1080p:
3.0 Ghz Intel Pentium D (dual-core) or faster processor, At least 1GB of RAM, 64MB or greater video card
As my system doesn't really fit these requirements (1,5 GHz Pentium M, 512MB RAM, 128 MB video card), I was quite impressed that I could run a bunch of videos in quite reasonable speed and quality with linux software.
Trying out various players the cvs-version of mplayer did it best for me. Pretty much every player available on linux uses ffmpeg for H264-decoding, so they should do all, but there have been a bunch of important fixes in ffmpeg recently and this is quite the easiest way to get a recent ffmpeg-version running.
Running mplayer with these options gave me the best results:
mplayer -lavdopts skiploopfilter=all -framedrop -fs [videofile]
-fs is for playing the video in fullscreen (you don't want to play HD videos in a window), -framedrop let's mplayer skip frames when your system is too slow (else it will be out of sync very fast, some framedrops don't really hurt). About the -lavdopts skiploopfilter=all, I don't really know the details of video codecs, as far as I understood, this disables some steps in the decoding that shouldn't be needed on most videos, but can result in wrong decoding. I couldn't see any differences, it improves the speed quite a lot.
Now I could play all 420p and 720p videos at pretty reasonable speed. I especially liked this BBC one showing african animals and landscape. For the 1080p ones, it differs. This Trailer for "The Island" runs pretty well, others don't.
Bugs: Some videos cause mplayer to crash. On my radeon, the mplayer xv output has a problem with the large videos (width of 1900) displaying a pink block on the right side. I've written bug-reports and hope those things get resolved soon.
To sum it, I'd call linux pretty much "HD ready", beside some small issues it plays the HD stuff very well and with impressive performance.
Places to get HD videos:
Microsoft WMV HD Content Showcase
Apple HD Gallery
Tuesday, September 13. 2005
KDE 3.5, acid2, pmount

Probably more interesting for reality usage is that kde 3.5 finally supports automounting based on pmount with the new hal/dbus-API. I also happily noticed they fixed an annoying bug in konquerors ssl-handling when trying to permanently accept certificates that were issued for wrong hostnames.
Gentoo users can try it out by copying the kde 3.5 section from the package.mask-file to /etc/portage/package.unmask.
Monday, September 5. 2005
Firefox drops SSLv2 support
As the German News-page Golem writes, Firefox is going to drop obsolete SSLv2 support in it's next version, because it has known vulnerabilities by design.
While this is in general a very good idea to make things "secure by default", it will probably lead to people crying "Firefox can't open URL xy any more". We have a vast number of deprecated servers, applications etc. that just don't support up-to-date security standards and weren't updated for ages.
Even SSLv3 supports a lot of weak ciphers, like Single-DES, RC4 etc., that are known to be broken for ages. Not to talk about things like RSA 1024 or SHA1, that are not yet broken in reality, but probably will be at some time in the future.
The implementation of secure standards in todays software is far away from what's neccessary for high security applications.
We need to get rid of all that old cruft. High security is possible with today's cryptography, but we have to use it and we have to design applications that use secure technology by default.
While this is in general a very good idea to make things "secure by default", it will probably lead to people crying "Firefox can't open URL xy any more". We have a vast number of deprecated servers, applications etc. that just don't support up-to-date security standards and weren't updated for ages.
Even SSLv3 supports a lot of weak ciphers, like Single-DES, RC4 etc., that are known to be broken for ages. Not to talk about things like RSA 1024 or SHA1, that are not yet broken in reality, but probably will be at some time in the future.
The implementation of secure standards in todays software is far away from what's neccessary for high security applications.
We need to get rid of all that old cruft. High security is possible with today's cryptography, but we have to use it and we have to design applications that use secure technology by default.
Posted by Hanno Böck
in Cryptography, English, Gentoo, Linux
at
14:41
| Comments (0)
| Trackbacks (0)
(Page 1 of 1, totaling 3 entries)