Sunday, December 22, 2013

Site Streamer // Sometimes, you just want to stream!

Site Streamer

Sometimes...you just want to stream

The other day, I wanted to listen to the songs available for download from a band's site but downloading them, then adding to my media player seemed like to much work. Strange, because I usually prefer to download -- eventually the tracks end up on my phone and I listen to them in my car. Today, I wanted to listen to them now and the process of downloading each, naming appropriately, then listening to all seemed daunting.

I should develop a website to do this for me!

Instead of spending a few minutes to work this out myself, I decided the more time-effective solution was to spend hours developing a website to do it for me. Of course!

Luckily, I already had the building blocks: 1) [bandcamp downloader] a site that parsed bandcamp pages and made the songs available for download, naming them appropriately and 2) [jPlaylister] a site that creates jPlayer playlists from a local folder's contents.

It wasn't that bad, but spending the time to polish up the site enough for public use added another month of wait due to my busy schedule and recently rekindled gaming habit (a night or two a week for a couple of hours -- nothing serious).

Hello, World!

Meet Site Streamer. A site you can use to stream content from a place which normally just allows standard linked downloads.

You visit the site, paste in a website which has plainly linked downloadable (mp3, currently) audio content, and enjoy the stream. Hope this is convenient for someone!

Monday, December 2, 2013

Intel Compiler Degrades Performance for Non-Intel CPUs

how am i just hearing about this? this is old news, but worth a read if you don't know what i'm talking about.

why so late? why haven't others written about this?

i haven't searched thoroughly, but, reportedly, intel's ties (big advertiser) with tech blogs and publications has kept this from seeing as much exposure as it deserves.

intel does what?

i'll horribly summarize: intel makes some of the best and most widely used compiler and libraries that exist. they are used in tons of compiled installers. the catch: they unfairly optimize for genuine intel products.

they finally have a notice on their website, but it isn't incredibly obvious and isn't the fix the settlement after the court case with AMD demanded.

but they are intel!

the obvious issue is that processor shouldn't matter -- instruction set should:

if (this.processor supports SSE){use sse code} else {use non sse methods}

instead, the code looks like this:

if(this.processor is genuine intel){use best instruction set method} else {use the least optimized code}

in 2012, they did comply with some court order and offer refunds to those interested (misinformed purchasers who expected an impartial compiler/libraries). not enough.

still, this would be acceptable if the product was billed as an intel exclusive or they were making use of things competitors couldn't offer. it isn't (in this case).

Agner (see source link), who has done MUCH research on the topic, claims that we need to get glibc (a rival compiler) and it's libraries properly optimized. Since that is above my head, I thought getting this dirty practice exposed a few people at a time (the extent of my reach) would have to be my contribution.

*chuckles* ...and...you are surprised?

back when AMD took the performance crown (what, 10 years ago?), no. i've been an AMD supporter for a while since they price their products competitively. but since Intel has been the obvious performance leader for a while now...at least in per-clock work and power efficiency, i thought they'd let their products based on superior manufacturing process speak for their-selves. no, gotta pull (or, not rectify) some underhanded stuff like this? and here i was pulling for them to be competitive with ARM.

source

http://www.agner.org/optimize/blog/read.php?i=49

Thursday, November 7, 2013

Steam OS and AMD's Mantle API: Almost star-crossed

I feel like this should have been written elsewhere by someone more knowledgeable than myself, but it hasn't.

And if ya don't know, now ya know

Steam OS is Valve's GNU/Linux-based OS which is supposed to be optimized for games and will likely offer/feature the "Big Picture" experience which has gotten some attention recently. Presumably, OpenGL-based engines/games will play with ease on the system, but engines/games which lean on Direct3D (Microsoft's heavily used graphics API) games will almost certainly not be available. The idea is that, since GNU/Linux has the potential to be very lean, or resource-lite, performance gains could be realized while gaming as the underlying system (as compared to Windows 8/7/Vista) would need far less resources and, arguably, be more stable.

Mantle is AMD's recently released API that seems to be in direct competition with Direct3D and OpenGL. It bears some resemblances (in performance vs peers) to a long defunct API called Glide. A new API wouldn't normally be very noteworthy or welcome if performance was supposed to only be similar to existing APIs. However, Mantle claims advantages of "9 times more draw calls per second than comparable APIs" and is said to enable "Console-like" hardware access. Don't let that scare off you PC gamers. Console-like just means lower-level access (more efficient use of hardware), not last-gen/outdated performance on release. Oh, analogy time:

  • [Programmer] It's like having something coded in C instead of Java. Sure, Java may be easier and more portable, but C gets far more work done per CPU cycle. (Mantle API is C and OpenGL/Direct3D are Java in this very rough analogy)
  • [Communication] I tell my kid to tell my wife that I'm sorry I crashed her car instead of telling her myself. (Mantle API is me telling her, OpenGL/Direct3D is me telling my kid to tell her -- slower and less effective assuming he tells her at all. my apologies for this analogy)

The problems

For now, Mantle only works with CGN (newer) AMD Graphics Cards. This makes sense as you can't very well back-port a low level API you've just created, realistically. Notably absent from this list is newer Nvidia cards.

Mantle is a recently developed API about which AMD has made statements implying a "open nature." Currently, it isn't known if Nvidia could eventually allow Mantle API hardware access. Unless that occurs, Mantle can only EVER be a parallel/alternative API, as opposed to the exclusive API of choice by a Game/Engine/Developer for PC since Nvidia has such high market share.

Steam OS and the pending Steam Box machines seem to be Intel/Nvidia based. Valve has said the AMD hardware will certainly be supported, but since Nvidia was pretty heavily involved in Steam OS, it may have notable advantages.

Interesting note

Both the XBox One (xbone, xb1) and PS4 are built custom developed AMD APUs (CPU and GPU in one), which feature CGN technology (potentially Mantle API compatible). It seems that neither Sony nor Microsoft plan on allowing Mantle-developed games on their machines. This is notable because, IF Mantle API worked on "Next Gen" consoles and it was used by game developers, "porting" from Console to Mantle-capable PCs (or PC to console) would be drastically less work and much faster and more seamless.

So, what you're saying is...if your lips left you...

My Wife, and 8th Grade ELA Teacher, would probably tell me I need a "Call to action" statement if this were a persuasive essay. It isn't, but one or both of the following really should be done:

  1. AMD needs to release drivers or lend support or whatever is necessary to enable Mantle to work with Steam OS once it comes out. While there don't seem to be any numbers that show expected performance gains of OpenGL games on Windows 8 vs Steam OS, the intention is that it will run faster. If nothing else, Linux is more malware resistant (possibly due, in part, to security by obscurity) and resource-lite, so OS resource utilization should be minimal. With wider GNU/Linux usage, AMD may be encouraged to beef up driver support. Next, they(/we?) need to get Nvidia on board. Obviously, they are rivals, but share the common goal of preserving interest in PC gaming. If Mantle has half the performance impact is seems capable of, it'll be a HUGE deal, and Nvidia will want to jump on board or (a horrible alternative) develop their own API.
  2. [more of a footnote, really] Console makers should lean on Mantle API. It'll make porting between XB1, PS4, and PC much more straightforward and, unless the performance is worse than the custom APIs used by each, shouldn't hurt anything. The exception would be Windows OS sales since many gamers claim that playing is the only thing that keeps them on Windows. Likewise, if everyone else worked well with Mantle, Nvidia would be encouraged to adopt support to stay relevant.

Sources

My sources are a few articles I've read about each (Toms Hardware, probably), a few wikipedia articles I used for general summary information, and the Steam OS website.

Read More

I have come across these resources that may be of interest.

  • http://www.extremetech.com/gaming/168671-xbox-one-will-not-support-amds-mantle-and-ps4-is-also-unlikely-is-mantle-doa
  • http://www.anandtech.com/show/7371/understanding-amds-mantle-a-lowlevel-graphics-api-for-gcn

Friday, August 9, 2013

Google Ignores Image Extensions

Or

Google Plays Image Extensions

Or

Google! It's a PNG, not a JPG

Or

Google Plus Summarizes Backed-Up Videos as Animated GIF

I noticed the other day while working on my Photo Feed Display project that PNG files in my Picasa Web Albums RSS Feed were not being processed correctly. I had JUST added PNG support, so I thought the error was probably in my code. As I dug deeper, I noticed that the images referenced in the RSS Feed had .jpg extensions, not .png extension. I thought this was probably intentional since .jpg (for photo) often provide better results for a given file size. I thought that Google was doing me a favor, making .jpg thumbnails of my .png files for ease of use. I'll take it. But, I was mistaken. Even though the RSS Feed explicitely listed the media with a .jpg extention, they were still PNG files.

Here's what I've found -- Google ignores image extensions. Presumably, they do this because web browsers also ignore image extensions (for widely supported image formats)*. For example, my Picasa Web Album RSS Feed lists the following image source:

http://lh6.ggpht.com/-zpdlmQRS-70/TroOQRNyGdI/AAAAAAAALuQ/qX2mkctpr40/s288/tourniquet%252520news%252520page.jpg

But wait! I get the same image in my browser if I remove the file at all:

http://lh6.ggpht.com/-zpdlmQRS-70/TroOQRNyGdI/AAAAAAAALuQ/qX2mkctpr40/s288/

Or, I can see a larger variant by removing the last bit:

http://lh6.ggpht.com/-zpdlmQRS-70/TroOQRNyGdI/AAAAAAAALuQ/qX2mkctpr40/

...it must default to the original size or a larger variant or something.

It is Still a PNG

This is all good and dandy, but, while not stated (or incorrectly stated), the file is still a PNG. My Photo Feed Display generates thumbs of photos using a PHP function imagecreatefromjpeg() and fails when referencing any of the links above as the source image. Further, it works when I use the (similar) function, imagecreatefrompng().

Why This Matters

If you are just viewing files in a browser, it shouldn't (since the extensions are ignored -- see my proof below, by the asterisk -- by web browsers). If you are processing the files, it very well may.

I Thought this post Concerned GIF files, Too...

Oh yeah! It does. A week after discovering the previous information, I was viewing my Google Automatic Backup files on Google Plus and noticed it had converted a video into (what I assumed was) an animated GIF file. Awesome! I love those. This time, when I right-clicked to copy the image URL, I noticed that it didn't have an extension. I thought it may be some fancy code that uses multiple JPG files, changing the displayed JPG a few times per second using javascript, which would be fine but wouldn't allow me to link to a summary of the video as an animated GIF would. Nope, true animated GIF file, despite the lack of extension. The same logic as above, as far as a scaled down version, applies. For example:

https://lh3.googleusercontent.com/krJiBTc-61AznapjS1u4nON7BC6crcwtStAHTYYE7_8=w369-h207-p-no

...shows a animated GIF summarizing the video clip. Similarly, but somewhat less intuitively, removing the "=w369-h207-p-no" (width, height, progressive[?], interlaced[?]) shows a larger version:

https://lh3.googleusercontent.com/krJiBTc-61AznapjS1u4nON7BC6crcwtStAHTYYE7_8

Lastly, when I 'inspect element' for a (presumed) animated GIF on my Google Plus page, I get the following source image:

https://lh4.googleusercontent.com/-xS4TzDbCnIU/UgPbWW5PUpI/AAAAAAAAEcE/iUV1gyNyJlY/s122-c/VID_20130806_174425.m4v

...but, it is clearly not a .m4v (even though it probably links to one). When I remove the last part, I still get the animated GIF (this time, with 'play' overlay):

https://lh4.googleusercontent.com/-xS4TzDbCnIU/UgPbWW5PUpI/AAAAAAAAEcE/iUV1gyNyJlY/s122-c/

Or, I can take more off the end to get a larger version:

https://lh4.googleusercontent.com/-xS4TzDbCnIU/UgPbWW5PUpI/AAAAAAAAEcE/iUV1gyNyJlY/

In Conclusion

Hope this helps someone!

-

References

* I haven't researched this, but I'm pretty sure it is true.