Archive for September 12th, 2007

Beta testers or Final testers?

I am a beta tester for a number of apps out there, but also for a specific, expensive, software application that shall remain nameless. For 2 months now I am busting my ass to provide bug reports and provide reproducible cases. I think I have reported about 25 bugs in that short time.

The app’s mailing list that I am also part of was largely low volume. Bug reports from others except myself was at the range of once every 5 days.

Fast forward to today, which is when the application’s final version got released. Suddenly, the mailing list is full of bug reports. Complaints left and right! Crybabies!

So basically, these lazy sloths got the program for free, and never bothered to properly test it. And when they got the final release and used it for real, suddenly they have complaints.

Developers should remove beta testers who don’t report back with some sort of feedback, even if that feedback is not a bug report. These previously valued users, will have to actually buy the app after they are kicked out — as they became beta testers exactly because they were experienced users of the app in the first place. If they don’t like it and go with another product, well, the developer lost nothing anyway.

Moral of the story: if you are honored by a developer to use his creation for free, at least report back with some feedback, as this is the only thing the developer asks of you.

Fair Use Worth More to Economy Than Copyright, CCIA Says

At last, some freaking common sense in this country:

“Fair use exceptions to U.S. copyright laws account for more than $4.5 trillion in annual revenue for the United States, according to the Computer and Communications Industry Association.”

I didn’t need the actual numbers to decide for myself that further expanding fair use (including it becoming a consumer right) is a good thing. As the article states, some balance must be found where the copyright holder doesn’t have such a big grip on the consumer’s basic rights regarding personal usage. But not everyone agrees.

Regarding ad blocking

Recently two pieces of news surfaced on the net about the morality of ad blocking (1, 2). I do not personally use an ad-blocking add-on on my Firefox but I do use NoScript. This disallows any JavaScript code to be executed by the browser unless you mark a web site as “safe”. I will not remove NoScript because it indeed provides an amazing sense of security, as we live in days where naively clicking to a link can result in the exploitation of your Windows PC.

Unfortunately, by blocking scripts, it means that it also blocks ads — because these days ads come with script from a remote server. And many of these ads are known to contain tracking code, and so I will simply not allow them to run.

Back when I got involved with OSNews in Aug 2001, we had no ad provider yet, and so the OSNews owner and I would ask companies one by one to support us. I would specifically ask their marketing dpt for a no-js version of their ad to run on OSNews, and for that gif/jpeg ad image to not be bigger than 15-20 KBs. Eventually, OSNews got a contract with major ad companies a few months later and so the JavaScript hell started running in for us too. Which is why I created the no-ads version of OSNews — originally was only meant for me and my friends, but then it became a product.

I got to say this to all the crybabies at DailyKos and News.com: if you don’t want ME to block your ads, then strip out JS. Simply use an ad image at the right size with a link to your advertiser’s web site, and this will automatically display on my browser. How difficult is this to do? Even with the simple image you can track quite a few things (e.g. geographical details of the user who loaded the ad), why do you need all the extra detail, tracking and headaches (and often, broken JS code) that JS/flash ads bring?

In conclusion: go back to basics, as JavaScript ads are not welcome in this house. At least not for sites or remote servers that aren’t marked as “safe”.

From DV/HDV/AVCHD to Flash Video

UPDATE July 2009, NEW Method: There’s now an easier way.
1. Export using this guide for your editor of your choice in the MP4 h.264/AAC format (no other format will work).
2. However, do TWO changes to the suggestions of these guides:
– Resolution: 640×360 (instead of the suggested 1280×720)
– Bitrate: 1 mbps
If you prefer HD quality, then use the suggested 1280×720 resolution, but don’t use more than 2 mbps bitrate (if your encoder supports VBR, do an average of 2 mbps, and a maximum of 4 mbps).
3. When the MP4 file is done exporting, then use this guide to make it streamable, and then download the JWFLV media player to embed your video on your site.

OLD METHOD:

Introduction

Here is how you can export your home-made camcorder widescreen NTSC videos from your (preferably Sony Vegas) NLE to your web site in Flash format. Please note, this tutorial is not about creating & adding videos to video sharing sites, but for hosting a video in Flash format on your own server.

The Method

1. Follow the first 5 steps from my previous tutorial.

2. Download the new Flash templates I have made ready for you and unzip them on the same folder as the “Untitled.avi” intermediate video and FFmpeg application (as explained in the link above). Use the 128×80 template version if your viewers are on dial-up or GPRS, use the 320×176 version for DSL and EDGE connections, and use the 640×360 version for cable and 3G connections. Finally, I also have a high-quality 480p template there. Double click the template you want your video encoded as and encoding will begin to create a new file called “VideoSharing-XXX.flv”.

3. In the meantime, download and unzip in a new folder the JW FLV Player. The only files you are interested from in there are the “swfobject.js” and the “flvplayer.swf”. Copy these two away, and delete the rest.

4. Modify or use the HTML file found in the flash.zip file you downloaded above in order to test your video code. Do not use visual HTML tools, you must learn to use a text editor to do this job right. Here’s how that code looks like:

<html>
<head>
<title>My home videos</title>
<script type="text/javascript" src="swfobject.js"></script>
</head>
<body bgcolor="#333333">
<center><font face="Arial, Verdana" size="2">
<p id="container">Get the Flash Player to see this video.
<script type="text/javascript">
var s1 = new SWFObject("mediaplayer.swf","mpl","256","180","7");
s1.addParam("allowscriptaccess","always");
s1.addParam("allowfullscreen","true");
s1.addParam("flashvars","&file=VideoSharing-128.flv&image=preview.jpg&volume=100&fullscreen=true");
s1.write("container");
</script></p>
</font></center>
</body>
</html>

As long as the HTML, the .flv video, the preview image, the “swfobject.js” and the “flvplayer.swf” files are all in the same folder on your server, it should all work fine. Now, if you want a second video on the same page, you must change all the parameter names from s1 to s2 etc, the player1 IDs to player2, the .flv filename and the preview image filename.

5. On the above HTML sample file I used a display area of 256×180, which is the better size for the 128×80 template:
var s1 = new SWFObject(“flvplayer.swf”,”mpl”,”256″,”180″,”7″);
I did this because the original 128×80 video is too small and difficult to see, and so I simply resized the display area. You don’t need to do this for the other templates, because the other ones are visible enough. The only thing to remember is that you always have to reserve an additional 20 vertical pixels to the template’s vertical resolution, because these accommodate the Flash Player’s controls. So, here is the code with all the correct display sizes for each template:
128×80: var s1 = new SWFObject(“flvplayer.swf”,”mpl”,”256″,”180″,”7″);
320×176: var s1 = new SWFObject(“flvplayer.swf”,”mpl”,”320″,”196″,”7″);
640×360: var s1 = new SWFObject(“flvplayer.swf”,”mpl”,”640″,”380″,”7″);
848×480: var s1 = new SWFObject(“flvplayer.swf”,”mpl”,”848″,”500″,”7″);

6. Regarding the preview image. If you don’t want to, you don’t have to create a preview image, the display area will just stay black until the user presses “play”. Although for aesthetic reasons, it’s nice to have one. You have to take a framegrab from your video and then save it exactly at the template’s video size you are using. For example, if you are using the 640×360 template, that’s how big the JPEG image must be. Make sure you save by optimizing the JPEG image so it’s not more than 5-15 KBs each (also be careful, Mac OS X has the bad habit of creating thumbnails inside your JPEG image and hence creating unnecessarily big filesizes).

7. That’s it, you are now ready to publish to your site! Who needs YouTube! Here’s my implementation below showing some of my own footage captured by the HDV camcorder Canon HV20.


An Alternative Method

Alternatively, you can use one of the h.264/MP4 templates (as shown in my previous tutorial linked above) and instead of using Flash, you can use Quicktime to present your videos on a web page. After you encode your .mp4 video using one of these other templates, you can use an HTML code that looks like this:

<center><embed src=”FILENAME.mp4″ width=”320″ height=”192″ autoplay=”false”></embed></center>

The Quicktime player requires 16 additional vertical pixels, so if for example you exported to 320×176, that would be 320×192, or if you exported in 480×270, that it would be 480×286 in the code above. The only two problems with the Quicktime method (instead of Flash), is that it is not as widespread as the Flash Player among users, and that it starts downloading the video even if you haven’t told it to playback, and so this will be bad news for your bandwidth allowance.