In keeping with the general trend of posting updates once a year, I've decided to make a little utility that might be useful to some people.
HTTP Live Streaming is a protocol developed by Apple and released as an IETF draft for the purpose of streaming multimedia (video and/or audio) over HTTP. The protocol is very simple, and relies on a constantly-changing .m3u playlist to control the playback.
Surprisingly, I didn't find any existing client software on the Web; the only extant clients seem to be iOS devices (iPhone, iPod touch, iPad) and Safari on Mac OS X (via QuickTime X).
So, I've hacked up a really simple Python client which calls up VLC and feeds it the stream. The client supports encryption (well, it does in theory; I have yet to find an in-the-wild stream to test this on), and should provide decent performance.
If you have any issues or feedback, please do reply in the comments!
Download the source code or a precompiled Windows executable (may require MSVCR71.dll).
The Windows executable assumes you have VLC installed to C:\Program Files\VideoLAN\VLC. If you have it installed elsewhere, you will need to edit the source code.
UPDATE [07/22/2012]: The source code has been updated to support HLS v3. Since I no longer own a Windows box, I cannot update the Windows exe. Therefore, if you run into issues with the Windows exe, I suggest you try the source code version.
Updated 05/25/2011: fixed links.
Updated 09/24/2011: fixed links.
Updated 07/22/2012: update to support HLS v3 playlists.
8.31.2010
10.15.2009
iPhone/iPod touch calculator bug
I generally expect my computing devices to give me correct answers, or at least close answers to arithmetic questions. However, the calculator on the iPhone/iPod touch has a serious bug which renders it mostly useless for calculations involving large numbers.
Recently, I attempted to do some calculations on my iPod touch (specifically, calculating "100 choose 50" to test a combinatorial identity), when I ran across this strange bug.
If you have an iPhone or iPod touch, you can play along. Square brackets [] denote keys on the iPhone's Calculator app. Let me know if the bug shows up on your device.
Fire up the Calculator app, which comes with all of the recent iPhone OS versions. Put the device in landscape view to activate the scientific calculator, then punch in [1][EE][6][0][+/-][=][1/x]. This calculates the reciprocal of 10-60, which ought to be 1060. However, Calculator says that the answer is "1e+22", or about 38 orders of magnitude off! If you press [1/x] a few more times, you'll see that it gives the correct answer.
The strange behaviour doesn't stop there. Calculating the reciprocal of 10-38 gives 1 ([1][EE][3][8][+/-][=][1/x]) instead of 1038, and the reciprocal of 10-32 ([1][EE][3][2][+/-][=][1/x]) is "1.1111...e+32", which, while not off by orders of magnitude, is still grossly incorrect.
But it's not just the reciprocal key that is broken. Calculating, for example, 1080 divided by 1020 gives 1060 as expected ([1][EE][8][0][=][÷][1][EE][2][0][=]), but 1090 divided by 1030 gives 1022 ([1][EE][9][0][=][÷][1][EE][3][0][=]).
There's even more strangeness with large numbers. If you try to enter 10120 ([1][EE][1][2][0][=]), it works fine (though certain divisions involving this number may fail badly). However, you can't enter 10150 ([1][EE][1][5][0][=]); you'll get an error.
Here's the odd part: type in [1][0][0][x!], and the number that comes up is 9.33262...e+157, which is rather larger than 10150, and yet the calculator seems to have no trouble with it (the answer is correct, as Google Calculator tells me).
As of yet, I still haven't figured out what sort of strange coding was required to make this fail. Judging from the fact that 38 seems to play a fairly central role in the division bug (since results that should ordinarily come out to a large power of 10 will come out 38 or 76 orders of magnitude short), I'd say that the problem lies in the division algorithm that is being employed. Nevertheless, I'm having trouble believing that this sort of bug managed to slip past Apple's radar into a shipping product.
I've tested this on my iPod touch 1st Gen, a few iPod touch 2nd Gen and 3rd Gen devices, and a few iPhones (both 3G and original), and it doesn't appear in third-party calculators like Gabor Nagy's excellent Graphing Calculator, so it is likely a software glitch rather than a hardware problem.
Comments? Questions? Post away! I'd especially like to hear from people who are using older versions of the iPhone OS, to see if this is a recent bug or one which has been present for a while.
Recently, I attempted to do some calculations on my iPod touch (specifically, calculating "100 choose 50" to test a combinatorial identity), when I ran across this strange bug.
If you have an iPhone or iPod touch, you can play along. Square brackets [] denote keys on the iPhone's Calculator app. Let me know if the bug shows up on your device.
Fire up the Calculator app, which comes with all of the recent iPhone OS versions. Put the device in landscape view to activate the scientific calculator, then punch in [1][EE][6][0][+/-][=][1/x]. This calculates the reciprocal of 10-60, which ought to be 1060. However, Calculator says that the answer is "1e+22", or about 38 orders of magnitude off! If you press [1/x] a few more times, you'll see that it gives the correct answer.
The strange behaviour doesn't stop there. Calculating the reciprocal of 10-38 gives 1 ([1][EE][3][8][+/-][=][1/x]) instead of 1038, and the reciprocal of 10-32 ([1][EE][3][2][+/-][=][1/x]) is "1.1111...e+32", which, while not off by orders of magnitude, is still grossly incorrect.
But it's not just the reciprocal key that is broken. Calculating, for example, 1080 divided by 1020 gives 1060 as expected ([1][EE][8][0][=][÷][1][EE][2][0][=]), but 1090 divided by 1030 gives 1022 ([1][EE][9][0][=][÷][1][EE][3][0][=]).
There's even more strangeness with large numbers. If you try to enter 10120 ([1][EE][1][2][0][=]), it works fine (though certain divisions involving this number may fail badly). However, you can't enter 10150 ([1][EE][1][5][0][=]); you'll get an error.
Here's the odd part: type in [1][0][0][x!], and the number that comes up is 9.33262...e+157, which is rather larger than 10150, and yet the calculator seems to have no trouble with it (the answer is correct, as Google Calculator tells me).
As of yet, I still haven't figured out what sort of strange coding was required to make this fail. Judging from the fact that 38 seems to play a fairly central role in the division bug (since results that should ordinarily come out to a large power of 10 will come out 38 or 76 orders of magnitude short), I'd say that the problem lies in the division algorithm that is being employed. Nevertheless, I'm having trouble believing that this sort of bug managed to slip past Apple's radar into a shipping product.
I've tested this on my iPod touch 1st Gen, a few iPod touch 2nd Gen and 3rd Gen devices, and a few iPhones (both 3G and original), and it doesn't appear in third-party calculators like Gabor Nagy's excellent Graphing Calculator, so it is likely a software glitch rather than a hardware problem.
Comments? Questions? Post away! I'd especially like to hear from people who are using older versions of the iPhone OS, to see if this is a recent bug or one which has been present for a while.
9.07.2008
Web Browser Speed Comparison
Recently, Google announced their new Chrome browser, along with a lightning-fast V8 Javascript engine. Mozilla also announced a new Javascript engine, named TraceMonkey, and some benchmarks done by Brendan Eich suggest that it is able to compete with V8 in terms of speed, and it isn't even done yet.
I decided to grab eight browsers, representing Firefox, Opera, Safari, Chrome and IE, with the most recent builds of Firefox, Chrome and Safari (WebKit) and stable versions of each, and took them for a spin on five benchmarks, ranging from the simple JS Time Test to the complex (and relatively new) Dromaeo test. The eight browsers are Firefox 3.0.1, Firefox 3.1b1pre with TraceMonkey (built Sept. 7), Opera 9.52, Google Chrome 0.2.149.29, Chromium 0.2.152.0 (build 1827), Safari 3.1.2, WebKit r36254 and IE8 beta 2.
Three of the tests, JS Time Test, SunSpider and the V8 Benchmark, are JS-only, meaning that they do not test how scripts interact with the displayed content. These are tests of JavaScript as a regular programming language, i.e. the ability for a browser to quickly interpret and execute code.
The other two, Celtic Kane and Dromaeo, contain DOM (Document Object Model) tests, which interact with the page and test the speed with which the browser can programmatically modify the page. In my opinion, these tests are more important for real-world use, as modern AJAX appplications can perform literally hundreds of additions and deletions to the document tree a second. The fastest pure-JS engine in the world is no use without fast DOM manipulation for modern websites.
Testing methodology was relatively simple. My system is a Core 2 Duo (laptop) clocked at 2 GHz. For each test, the same quiet background processes were running -- CPU usage between tests did not exceed 5%. It runs Windows XP SP3.
For each browser, the testing harness I wrote starts the program with the specified test page. The test is then started if necessary, and the result is recorded. For the JS Time Test and Celtic Kane's test, the test was run five times at five-second intervals (approximately), and the best time taken is recorded. For these two tests, differences of less than 10% are likely irrelevant and due to statistical uncertainty. For the other three tests, the value as quoted by the test is used (except Dromaeo, where I visited the results page to get the value as the main test page quoted an incorrect total time).
Each benchmark was normalized to have Firefox 3.0.1 be "100" with higher scores meaning better performance. This is done in the interest of comparison, and the raw data is available here.
For the JS Time Test and V8 Benchmark tests, the Chromium nightly build was the fastest, followed closely by the "released-to-the-public" version of Chrome. This is not surprising, given that V8 is optimized for its own benchmarks, and the JS Time Test contains relatively simple JS that should be easy to compile for V8. For SunSpider, the WebKit nightly takes top spot (again not surprising, given that SunSpider is Apple's benchmark). However, Firefox with TraceMonkey takes second, which is a bit surprising (I had expected the Chromium nightly to do better).
For the mixed DOM/JS tests, though, it is a completely different story. On Celtic Kane, Chrome actually takes second-last place, while WebKit Nightly and Safari end up at first and second place, respectively. On Dromaeo, Firefox with Tracemonkey takes first, with Safari in second (WebKit nightly actually crashes, which I've logged as a bug with the WebKit bug tracker).
In every test, you'll see that Internet Explorer 8 comes in dead-last, sometimes by a huge margin, which might not be surprising to people familiar with Internet Explorer. Even though it is a beta, it is highly unlikely that Microsoft will improve their JS engine substantially between now and release, as it takes a large investment of work, and it is something that I do not think is really on Microsoft's agenda right now. Nevertheless, I think it will hinder the advancement of rich web applications, at least until the alternative browsers gain majority share on the Web.
There you have it; the benchmarks for eight modern browsers across five different benchmarks. The raw data is available if you'd like to make your own conclusions or repeat/expand the test.
I decided to grab eight browsers, representing Firefox, Opera, Safari, Chrome and IE, with the most recent builds of Firefox, Chrome and Safari (WebKit) and stable versions of each, and took them for a spin on five benchmarks, ranging from the simple JS Time Test to the complex (and relatively new) Dromaeo test. The eight browsers are Firefox 3.0.1, Firefox 3.1b1pre with TraceMonkey (built Sept. 7), Opera 9.52, Google Chrome 0.2.149.29, Chromium 0.2.152.0 (build 1827), Safari 3.1.2, WebKit r36254 and IE8 beta 2.
Three of the tests, JS Time Test, SunSpider and the V8 Benchmark, are JS-only, meaning that they do not test how scripts interact with the displayed content. These are tests of JavaScript as a regular programming language, i.e. the ability for a browser to quickly interpret and execute code.
The other two, Celtic Kane and Dromaeo, contain DOM (Document Object Model) tests, which interact with the page and test the speed with which the browser can programmatically modify the page. In my opinion, these tests are more important for real-world use, as modern AJAX appplications can perform literally hundreds of additions and deletions to the document tree a second. The fastest pure-JS engine in the world is no use without fast DOM manipulation for modern websites.
Testing methodology was relatively simple. My system is a Core 2 Duo (laptop) clocked at 2 GHz. For each test, the same quiet background processes were running -- CPU usage between tests did not exceed 5%. It runs Windows XP SP3.
For each browser, the testing harness I wrote starts the program with the specified test page. The test is then started if necessary, and the result is recorded. For the JS Time Test and Celtic Kane's test, the test was run five times at five-second intervals (approximately), and the best time taken is recorded. For these two tests, differences of less than 10% are likely irrelevant and due to statistical uncertainty. For the other three tests, the value as quoted by the test is used (except Dromaeo, where I visited the results page to get the value as the main test page quoted an incorrect total time).
Each benchmark was normalized to have Firefox 3.0.1 be "100" with higher scores meaning better performance. This is done in the interest of comparison, and the raw data is available here.
For the JS Time Test and V8 Benchmark tests, the Chromium nightly build was the fastest, followed closely by the "released-to-the-public" version of Chrome. This is not surprising, given that V8 is optimized for its own benchmarks, and the JS Time Test contains relatively simple JS that should be easy to compile for V8. For SunSpider, the WebKit nightly takes top spot (again not surprising, given that SunSpider is Apple's benchmark). However, Firefox with TraceMonkey takes second, which is a bit surprising (I had expected the Chromium nightly to do better).
For the mixed DOM/JS tests, though, it is a completely different story. On Celtic Kane, Chrome actually takes second-last place, while WebKit Nightly and Safari end up at first and second place, respectively. On Dromaeo, Firefox with Tracemonkey takes first, with Safari in second (WebKit nightly actually crashes, which I've logged as a bug with the WebKit bug tracker).
In every test, you'll see that Internet Explorer 8 comes in dead-last, sometimes by a huge margin, which might not be surprising to people familiar with Internet Explorer. Even though it is a beta, it is highly unlikely that Microsoft will improve their JS engine substantially between now and release, as it takes a large investment of work, and it is something that I do not think is really on Microsoft's agenda right now. Nevertheless, I think it will hinder the advancement of rich web applications, at least until the alternative browsers gain majority share on the Web.There you have it; the benchmarks for eight modern browsers across five different benchmarks. The raw data is available if you'd like to make your own conclusions or repeat/expand the test.
2.06.2006
Sysinternals Freeware - File and Disk Utilities
Useful tools for school computers...
Read more at www.sysinternals.com/Fi...
Subscribe to:
Posts (Atom)