Wednesday, December 26, 2012

Battle of the Titans (for this quarter anyway)

Android vs. iOS. Apple vs. Google. Bringing either up will rile up rabid fanboys (and fangirls) as faster than you can yell "Incoming!" and have a chance to dive for cover. Some of the arguments make some sense but more often than not, it turns into irrational gibberish for the most part.

I've been following iOS since the first iPhone and have tried Android since Gingerbread with the Motorola Droid. After flip flopping back and forth trying both platforms one at a time, I'm finally test drove both for several weeks and I'm writing up my opinions on both in this post. This is just my two cents so that I don't have to constantly repeat it to friends, coworkers or strangers on this particular subject.

Apple iPhone 5 (Verizon) and LG Nexus 4 (T-mobile)

The latest iPhone is pretty much worth every praise that has been thrown at it so far. Everything from build quality, hardware selection and how it operates is a step up from the previous generation 4/4S. It's also finally has LTE which makes it on par with all the Android phones out there. Once you've tried LTE, there really is no substitute. In a non oversold/saturated area, I'd take LTE over some random WiFi connection. So yes, it's that good.

With all of this comes the ecosystem backing iOS and it's still the best out there. This is just my personal opinion but third party offerings still looks better or is only available on iOS for the most part. This gap is narrowing somewhat but there is still a noticeable difference.

Sadly, it's not all positives and good feels. The first party offerings are slipping. Apple Maps works and hasn't navigated me into a lake (yet) but the POI and overall polish feels more like a beta product than Siri is. The emphasis on skeuomorphic design really isn't my thing nor is the lack of consistency in presentation. An example of this is how the top bar goes "blue" in certain apps/menus (Calendars and Settings) whereas it stays black for the most part in everything else. That and ... iOS really feels dated. There, I said it.

That whole disconnect between hardware and software will hopefully be resolved with the change up in management but I don't believe it's going to make much of a difference till iOS 8.

And here is the latest Nexus device. After having had a chance to try out a Nexus S and having owned a Galaxy Nexus, build quality wise, this is the best so far. It feels solid even if I'm not a huge fan of the glass back. I would've thought manufacturers learned from Apple's mistake with glass backs on the 4/4S but it does add a quality feel.

Hardware wise, it's also not left wanting. I personally thought the Galaxy Nexus felt very part bin-ish and that Samsung cheaped out to make sure it didn't compete with it's other devices. This time around, it has a great processor, up to date camera sensor and a great screen. The colors doesn't pop like it does on an AMOLED screen but it's definitely seems sharper and cleaner overall.

Where it truly shines is under the hood and all of the first party/Google applications. Between Gmail which FINALLY has pinch to zoom to Google Now which feels more fluid to use than Siri, Android has finally matured with Jelly Bean 4.2 (IMHO). Plus, it's pushing the boundaries with Photo Sphere and other add-ons which is sure to come as a part of the Nexus program.

Now, the one huge omission is the lack of LTE. Yes, you can enable LTE via a test menu but it really doesn't apply to me since I don't live in an AWS LTE area (yet). Admittely, HSPA+ isn't as bad as I thought it would be. I've seen speeds up to 20mbps down and 2mbps up on T-mobile. Still no where near the 30/15+ on Verizon LTE but for the most part, it's usable. If anything, the truly noticeable difference is the latency especially if you're not stationary. During my testing, Verizon LTE seems to be less affected by movement/travel unlike HSPA+. YMMV but HSPA+ feels like "stop, stop, stop, burst" and LTE is more akin to "blam - no wait (unless you swing back to 3G)". So if anything, this hurts my overall opinion of the Nexus.

So the big question is ... which one did I choose?

Right now, I prefer the Nexus 4.

Even with the lack of LTE, I seem to grab the Nexus 4 more than the iPhone 5 and here are my reasons why.

I really thought that a 4" screen smartphone would be the best compromise size between usability and battery life. But I'm going to admit, besides the battery life (which the iPhone is amazing with in a good signal area), pushing it to 4" made it more than a handful. I personally can't one hand operate the device with ease like I did the iPhone 4/4S. So if I need to use two hands, I might as well pick the device with the larger screen since it's easier on the eyes.

Google Now is also a feature that I'm beginning to use and rely on more. Plus, I find myself navigating through Android faster than I do with iOS now. I can turn off/turn on features with less steps than iOS.

Carrier choice also plays a factor into all of this. I realize that it's a combination of device and network but you can enable WiFi tethering on the Nexus 4 without any additional fees on T-mobile. It's not a feature I use often but it's convenient to have regardless. That and the fact that I don't believe I should be charged for said feature.

With all that said, I don't believe you can go wrong with an iPhone. It's available via LTE on almost every carrier besides T-mobile right now and it's a great device. It's not like you can pick up a Nexus 4 with any amount of ease right now since it's sold out everywhere unless you want to spend a premium and get it through auction sites.

But if you're in an area that T-mobile HSPA+ is actually decent, it is a great alternative. Especially if you're not a heavy voice user since I'm on the 100 minute/unlimited text/5GB of "Faux G/HSPA+" data for $33 after tax. That is kind of hard to beat.

Wednesday, December 12, 2012

It's been awhile

I probably can blame my laziness and procrastination on this but I haven't updated my blog in awhile. I guess my desire to make game play videos waned quite a bit since I began to realize how crappy MW3 was. I quit well before I got my monies worth of Elite/DLCs. Sadly, I had a lot of hope in BO2 and bought the Season Pass only to figure out that the same crappy netcode has made it's way to Treyarch's game ...

What I am going to do is take a suggestion from a friend and make it reality - to start blogging about tech.

I admit that I spend quite a bit of my own money on gadgets just because of personal interest. Between that and my friends stating that I have no true allegiance to any camp (I hate fanboys/girls), there is no real reason why I shouldn't throw out my two cents to the world. So here goes nothing!

My first real post will be about the two "biggest" devices out right now - Nexus 4 vs iPhone 5. Still need to take pictures of said devices and finalize on what I'm going to compare (probably everything) but when it's done, I think I'll offer an impartial view on both.

Tuesday, February 7, 2012

I'm not too bright ...

Yep. Exactly what the title states. Sometimes, I brain fart and make things a lot more difficult that I have to.

Lo and behold, EyeTV has an option to output directly to QuickTime .mov files in either h.264 or "MPEG-4". I'm opting for MPEG-4 at the moment since my previous experience with h.264 taxed and put additional load on iMovie. Even when I was only doing voice overs for commentary.

And that sad truth? EyeTV outputs to QuickTime a lot faster than dumping it to h.264 native and running that file through MPEG Streamclip. So I think I found my work flow till I upgrade to FCPX.

EyeTV -> QuickTime -> iMovie -> turbo.264 HD to .mp4 for upload to YouTube.

Yep. This works for me. For now.

Saturday, February 4, 2012

Visual Evidence - A picture is worth a thousand words ...

So here is the visual proof that I mentioned in a previous post. All the video clips were played in VLC and the screenshots were taken within the application.

Here is the original, h.264 "native" output from EyeTV that was recording the footage a 13.5mbps.

The image quality and clarity is what I expected when I maxed out the settings for capture.

Now, here is the turbo.264 HD export. It's cropped and the image is jaggy. Kind of confused as to why it would look like this, especially considering that it's all made by the same maker.

Clearly, there is something going under the hood that is making the output from the turbo.264 all screwy.

And here is the samples from h.264 native to MPEG Streamclip outputting to QuickTime @ 10240kbps.

Now this what I was expecting, even when compressed or at least changed into a format where iMovie could edit the file or at least manage simple edits without falling over itself. And in QuickTime, the file size may have grown a bit over what turbo.264 offered but it's still less than AIC.

This learning experience is becoming a real chore.

Thursday, February 2, 2012

EUREKA! (And it didn't cost a cent?!)

The earlier post was written up yesterday but I didn't publish it since I wanted to add a couple of more thoughts, possibly comparison shots to illustrate the difference between output of various methods. But I ended up playing around with exporting different file formats last night and I finally got it "right". It's a nice compromise between file size, video quality and resource utilization when editing the files. So here is the process:

EyeTV export (native h.264/fastest option - I've set it to record at 13.5mbps constant quality) -> MPEG Streamclip export (QuickTime Movie - 10240kbps/10mbps which I'm still playing with this. I think I can lower it to possibly 8192kbps/8mbps stream and have "acceptable" video quality. The rest of the settings are the following - high quality, single pass and uncompressed 48khz stereo audio) -> iMovie.

With this process, I can edit and manage the clips in iMovie. If I want to save specific portions for a montage, I can export it out again to QuickTime to retain the video quality and keep the files in more manageable, smaller clips. If I want to export a project out for upload, I can use turbo.264 which will create the smaller file I'm looking for.

Only negative to this is the process time from MPEG Streamclip since encoding to QuickTime completely bypasses the turbo.264 unit. But I can deal with this. Whatever clips I end up capturing during a session, I can just queue up to convert to QuickTime overnight. Not a huge deal. Especially considering the upgrade in video quality. I think I prefer this compared to going HDV/AIC because from what I can tell, with AIC, I'm going to lose some quality anyway and considering the file sizes it creates, I don't feel that it's worth it at the moment. Now, whenever I get around to upgrading to FCPX and I invest in Compressor, I might try to encode in ProResLT and decide if the video quality is worth the file sizes. But that's in the future ... the question is if it's in the near or distance future.

Next blog post will be screenshots showing the difference in video quality between all the different outputs I was trying/dealing with. Stay tuned!

Shut up and take my money!

So I've been chugging along with the turbo.264 to convert the .m2ts/.ts that the Arcsoft capture software generated. It wasn't a bad system but I still needed to fire up the PC and keep my eye on it while it was capturing the stream. That and the fact that I needed to copy over those files to my Mac to encode.

I'm trying to simplify things and sometimes I forgot to hit capture on the PC and the copying process was slowing things down. An alternative was needed. Something all Mac based. Which costs money. Oh well.

There are a couple of options on using a Hauppauge HD PVR on a Mac but since I purchased this turbo.264 unit, why not get an Elgato product to complement it? So I purchased EyeTV.

Surprisingly, it's really nice compared to the Arcsoft software the came with the HD PVR (which makes sense - free vs pay). But it had features that I didn't know about like time shifting. Since it's supposed to be DVR software, it actually buffers whatever is on screen. I need to double check on how far it goes back but that's just dependent on how much disk space you give the software to buffer said stream. Pretty darn nifty.

Exports were ridiculously quick via it's native h.264 format. It dumps recordings in a mp4 container but it seems to be encoded in the same fashion that Handbrake does. Which means that editing and managing the clips created by EyeTV taxed iMovie quite a bit where as anything re-encoded by turbo.264 seems to be far more resource friendly. So I tried to export via turbo.264 from EyeTV and the results ... not so good.

It seemed to overscan the input and zoom in regardless of what I did to the settings. The exported file looked horrible. More so than the .m2ts/.ts to turbo.264 process that I was using before. I've opened a ticket with Elgato to see if this is a known problem since I couldn't find anything in the Knowledge Base. The odd problem is that if I took the native h.264 dump from EyeTV and used the turbo.264 encoding app seperately, the aspect ratio and overscan issue did not occur.

It's like a never ending struggle ...

Monday, January 23, 2012

Hell, I'll just throw money at the problem and maybe it'll fix it ...

So I've been searching for some kind of "cheap" fix to speed up production. Lead me to a couple of products but I couldn't get myself to pull the trigger. I mean, I was planning on purchasing FCPX eventually so whatever solution I was planning on using would become useless at that time. Till I stumbled upon on this:

The Elgato turbo.264HD.

Interesting device. It works with a program to speed up the encoding process. The output is pretty limited in that it's all h.264 based and I can't speed up conversions to AIC but after reading about it on Engadget, I had to try it out. And, yes, it does work as advertised.

I did a benchmark of how long it took for my PC, which was encoding streams, to reencode it via Handbrake to something that iMovie will read and let me edit (slowly but surely ...). I did the same on my Mac with the same file and Handbrake. Lastly, the turbo.264.

PC (Q6600 overclocked to 3GHz) - 7:26 (minutes:seconds)
Mac (i5 2.4 GHz 2010 MBP) - 12:02
Mac (turbo.264) - Low 7 minute mark (couldn't find a "log" where it recording exactly how long it took)

Right there is an improvement but not a huge one. I could always opt to just let the PC do the Handbrake encode and save some money. But there was more to the turbo.264 from my testing. It seemed that the h.264 mp4s that the turbo.264 created taxed iMovie less than the mp4s from Handbrake. I can't confirm this but just how the application felt was different enough for me. That and the fact that the turbo.264 also sped up the final encode/projects within iMovie too (supposedly will also work with FCPX). File size was a tad bigger than through Handbrake but I think there was only a 10% difference at most so it wasn't a deal breaker.

So this was a worthwhile purchase for me. Just a heads up to everyone that was considering one of these dongles. It really is a cool device. And ignore the negative Amazon reviews. I think those were posted when the turbo.264 first came out and the software caused issues. The latest software outputs more than acceptable quality h.264 mp4s.

Wednesday, January 18, 2012

Why can't this be easier?

So here is my basic workflow. What I would ideally prefer is the red line but right now, I need to process all the captured streams from my HD PVR through Handbrake before I can edit it in iMovie.

Now, I'm using a PC to capture the HD PVR stream because I had a PC lying around with a lot of storage space and it was technically free. If I opted to purchase an additional application for my Mac, it would have driven up start up cost. Plus, the application I tried didn't work quite as advertised which I will explain in a little more detail.

As you can see, I am processing the captured streams in Handbrake so that iMovie can work with the captured content. It seems that the h.264 default encode option for .mp4 ("Xbox" option) in the Arcsoft program doesn't play nicely with iMovie. My guess is that it's because it's encoding in 60fps instead of an iMovie friendly 24/30fps. It's the same with the capture program available for the Mac. Forgot the exact name of it but it exhibits the same stuttering during playback in iMovie and almost all players for whatever reason when it's converted from .m2ts to .mp4. Puzzling to say the least and I will look into this in more detail when I have more time but right now, I'm opting to output the HD PVR stream to a .TS h.264 format and then convert that .TS file to a 29.97fps MP4 h.264 file.

Now, I've learned the hard way that h.264 doesn't actually play all that nice with iMovie. Something about it being a compressed playing format instead of an editing friendly format. iMovie needs to decode on the fly while I'm editing these h.264 clips and it really makes the program feel ... laggy. I am going to try to just convert the clips that I'm going to use in the project to see if that will help but I think it's going to just do what I'm trying to avoid - use AIC and it's HUGE file sizes. After going through capturing, encoding to only reencode again to application friendly format is making me go nuts.

I believe I can skip the whole Handbrake part but that requires additional investment in my part - Final Cut Pro X. I believe it can edit .ts/.m2ts files directly and rendering those h.264 files might be a bit faster in FCPX than iMovie but I have no proof of this. That and well ... it'll cost me money. Ugh. But yeah ... right now, this is where I am now and it's driving me nuts.

Tuesday, January 17, 2012

Blogging? Perhaps.

I decided to start this blog to chronicle my attempts at creating YouTube video and content. It's definitely a learning experience - from workflow for video editing which is a mess in itself to having substance to my uploads.

I'm sure most of the posts will be workflow related so that someone might find the information useful and make their lives easier. Been learning a lot about iMovie and codecs in general because that alone is my greatest headache right now. From converting, rendering and confirming that the output is good before uploading.

Anyway, I'll post something a little more useful by this weekend. I hope. Maybe.