Archive

Archive for the ‘Uncategorized’ Category

The best source on HighScalability challenges

18 March 2010 Leave a comment

Do you want or need to build an high traffic web site ? The traffic is exploding and you need a complete re-design of your architecture ? Or simply just curious about how high traffic sites work ?
The right place is high scalability
A very inspiring site where you can learn how famous sites like Google, Amazon, ebay, Youtube are able to handle incredible amount of web traffic.

Categories: Uncategorized

A great MAX EUROPE 2008 experience

4 December 2008 Leave a comment

I had a great time at MAX 2008 in Milan. It has been very interesting to meet Flash experts and evangelists and being able to elaborate a more clear vision of where the technology is heading for the future.

I attended very inspiring sessions by Stefan Richter, Marco Casario, David Hassoun, Michael Thornburgh and others, acquired new skill in Pixel Bender, Flex, FMS, and kept in touch with old and new friends like Dario De Agostini, Andrea Amadeo and Tim Siglin.

The experience as a speaker has been very good too.

Flash Open Screen Project is really exciting, and so the new protocol RTMFP and the new path of development for Flash Media Server.

Another very impressive technologies is Alchemy, a C/C++ to AS3 converter which allows us for a fast and efficient access to billions of line codes written in C/C++.

But the most important “eritage” of the event is the born of new ideas in my mind about Encoding, FMS, streaming enhancement, Pixel Bender, new business opportunity and so on.

Now that I’m returned at home, it’s only a matter of starting to work to these ideas, and I’m happy because from a such high number of istirations, someone will be surely good.

Categories: Uncategorized

I’ll Speak about H.264 at Max Europe 2008

7 November 2008 Leave a comment

I’m very proud to join the Max Europe 2008 crew this year, expecially because we will be in Italy, my country.
At Max I’ll speak about H.264 and encoding best practices.
This is the abstract of my session (December 2):

Encoding Video for the Highest Quality and Performance

“Make video look the best it can. Get a deep understanding of optimizing H.264 and VP6-S for the highest quality and smoothest delivery experience. Learn how to tweak the encoder for maximum quality in Flash Player and Adobe AIR. The session will focus on understanding the H.264 codec and how you can deploy a larger frame size using new multibitrate technology. This is a great companion to the session on multibitrate video.”

If you like to know more about the H.264 video encoding, FMS and Flash Video Technology, join us at Max Europe and register to my session. The session will cover the encoding technologies implemented in H.264, the best settings for optimizing the final video quality and best practices to get the maximum performance in the Flash Player.

Categories: Uncategorized

I’m a father

18 October 2008 Leave a comment

Indeed I’m a lot of thing, but now I’m also (and above all) a father. My first son (Alessandro) is born Sunday 12 October in the morning. As you can well understand my life is changing completely not only from a practical point of view but most of all from an emotional point of view. Paternity (or parently) is such a powerful and depth link between two souls that can reveal, sometimes, the most true roots of our beeing.

Categories: Uncategorized

Adobe in the encoding industry

12 September 2008 Leave a comment

During IBC, Adobe announced the Flash Media Encoding Server a new scalable, high-performance server application for encoding generic videos to Flash video files. The solution, derived from Rozhet, is a robust encoding technology and support H.264, Vp6, AAC, MP3 as output for the Flash Player. FMES is expected to be available by the end of 2008 with a price of 6000$ US.

Categories: Uncategorized

A couple projects for the next year

31 December 2007 Leave a comment

2007 is ending, and as usual I’m preparing new projects for the next year. A couple of them involve the blogging. First of all, in 2008 I will launch a new Blog in Italian language. This blog will be less technical and more devoted to inform and support Italian executives’ decisions involving the use of Adobe Flash Video Ecosystem. The second project is a new showcase of the real potentiality of H.264 technology. In the last two months I played with my new Core 2 Quad @ 3GHz processor testing new H.264 encoders. Believe me, H.264 potentialities are really astounishing and for the most part underused today. What do you think about encoding HD content (1280x720p@25) in 1000-1200Kbit/s ? Last but not least, I’ll publish a AAC analysis as the conclusive step of our ‘excursus’ in the H.264 + AAC technology before releasing the “Flash Video Technology – White Paper – 2008”. Best Wishes.

Categories: Uncategorized

My Article on DevNet: Dual Threshold Buffering Strategy

14 July 2006 1 comment

A short post to mention my first article on Adobe’s Developer Center.
Implementing a dual-threshold buffering strategy in Flash Media Server

The works derives from my two previews Proof -of- Concept
I hope you enjoy the reading.

Categories: Uncategorized

Dynamic Buffering revamping

10 April 2006 Leave a comment

In a past and well appreciated TechNote, I explained a dynamic buffering technique which is able to take advantage of all the available bandwidth and, at the same time, is able to reduce, to the minimun, the pre-buffering time.

Recently I have improved the technique with a rate control code. This is the principle:

Use the prebuffering as rate control

A main advantage of the Dynamic buffering is the strong reduction of prebuffering time. This is obviously a great feature by itself, but we can find addictional value in it. We can use the prebuffering phase to measure the available bandwidth between client and server and therefore change accordingly the effective buffering depth or, if necessary, change the stream rate (between prerecorded ones).

The bandwidth measurement is indeed very simple. If we have set a prebuffer time of BT seconds, we can monitor the BufferLenght property measuring the time needed to fill the buffer to the i.e 80%. Let’s call this time T80.
We calculate an available/required bandwidth ratio: R=(BT*0.8)/T80
If R>1, the available bandwidth is higher than the required. i.e: 1.2 means +20%.
If R<1, the available bandwidth is lower than the required. i.e: 0.7 means -30%.

Depending by the R ratio, we can change the preloading behaviour before the preload ends (this is why we measure the bandwidth over the 80% of buffer filling).
If R is consistently higher than 1, the behaviour remains unchanged and the prebuffering time remains very short.
If R is only a little higher than 1, it’s better to enlarge the prebuffer depth. The prebuffering time becames longer but the playback more solid.
If R is lower than 1, we need to change the Stream with a scaled one. In this case, we have the great advantage of a short total buffering time, because, thanks to the Dynamic buffering, both the first (used to measure and then dropped) and the second (scaled stream) prebuffering times are inherently short.

A note to conclude:

I have created this Dynamic buffering scheme remembering of a key feature of Windows Media Player 9: Microsoft calls it “Fast-Streaming”. Now, it is available also for our beloved FMS2.


FIG 1 . Standard Buffering: Bandwidth fluctuations vs Buffer time


FIG 2 . Dynamic Buffering: Bandwidth fluctuations vs Buffer time

Categories: Uncategorized

Why I love FFMPEG: Flexibility, interoperability, encoding options.

30 December 2005 Leave a comment

Why I love FFMPEG ? The first reason is the flexibility, interoperability and the rich set of encoding options. FFMPEG is an open source project, it’s free and works well both on Windows and Linux. I can use this tool to create FLV files starting from a wide range of video and audio source files. I can use it to convert one shot or in batch both on desktop and server environment (exist also a PHP extension to handle this last possibility). FFMPEG supports: AVI, WMV9, DIVX, MP3, MPEG1-2-4, DV, MJPEG, H.263, H.264, 3GPP, AMR, FLV and many others.

It’s not surprising to know that Google Video (http://video.google.it) uses FFMPEG extensively to convert any sort of video sources to FLV. The cost (0), the options and the performances offered by this free tool have definitely convinced Google’s developer.
The lack of support for the last flash video codec (VP6) its the only negative spot. Unfortunately, being the VP6 a proprietary format, I think we will never see such a support in FFMPEG. On the other hand, at this moment it’s impossible to do more of what FFMPEG can do with other solutions and at a better price/performance ratio. Using server side On2’s solution or batch Sorenson conversion to produce VP6 videos is possible but not always convenient. Infact FFMPEG is much more fast, it’s free and, at the moment, it’s the only solution to re-compress a FMS (FCS) recorded FLV.

Let’s take a look at FFMPEG command line:

FFMPEG.exe -i inputfile.xxx [parameters] outputfile.flv

To convert video files to FLV, the most important parameters are:

-b, it’s the average bitrate. see also -maxrate -bufsize.
-r, frame rate. use -re to read input at native frame rate.
-s, frame size. ie: -s 320×200.
-maxrate, use this instead of -b for low bit rate video.
-minrate, set the minimum bitrate. Set maxrate=minrate=b to have a costant bitrate.
-bufsize, set (in KByte/s) the size of the buffer used to control the average bandwidth.
-sameq, convert video using the same per macroblock quantization of source.
-pass n, to launch the first pass setting use -pass 1, and for the second -pass2.
-g, distance beetween keyframes.
-i_qfactor, use it to set a difference in quantization beetween p frame and keyframe
-qscale, to set a fixed macrobloc quantization (range:0-32, 0 better quality, 32 worst)
-qmin, minimum quantization (max MB quality), try a value higher than 3-4 for low bitrate
-qmax, maximum quantization (min MB quality), default 32.
-me, motion extimation. Default is “epzs”, try the “full” value for a little more quality.
-deinterlace, deinterlace the source probably using Bob technique.

-ar, audio frequency (5500, 11000, 22000, 44000 samples/s)
-ab, audio bitrate in kbit (160, 128, 96, 80, 64, 48, 32, 24, 16)
-ac, number of channels (1-2)
-acodec copy, leave the audio tags untouched.

Depending by the setting, it’s possible to encode in variable and costant bandwidth, it’s possible to control max and min quality level, it’s possible to encode with a specific prebuffer in mind. It’s possible to deinterlace (standard Flash8’s encoder completely lacks this feature).

Spark encoded FLV are still good for hi bitrate (600-700Kbit/s depending by the contents of the video source). While are clearly inferior to VP6 for low-med bitrate (expecially under 350Kbit/s). To better encode at low bitrate I suggest to cut frame-rate, limit -qmin (try use 5-6 or higher instead of the default 2), set -maxrate istead of -b, or use a wide prebuffer (-bufsize). Try also double pass encoding (which offers alternate results) and an i_qfactor of 2-4.

Categories: Uncategorized

A Dynamic Buffering strategy

3 December 2005 Leave a comment

In this TechNote I’m going to talk about the buffering of a FMS (or FCS) stream and about the implementation of a dynamic buffering scheme for recorded streams.

How FMS buffering works

Subscribing a pre-recorded FMS stream, it’s possible to define a subscribing buffer with the method netStream.setBufferTime(N). The buffer behaviour is indeed very simple and similar to that of other media streaming servers. The FlashPlayer receives the stream and archives it until the buffer is full, at that moment, the stream starts to play and the Flash Player tries to keep the buffer full to its nominal lenght. If the bandwidth is insufficient, the buffer slowly decreses; when the buffer is empty, the playing is stopped until the buffer reaches again the desired lenght. The picture below illustratse the buffer behaviour related to an ipotetic profile of available client-server bandwidth.


The first profile illustrates an ipotetic client-server bandwidth normalized on the required stream bandwidth. The second profile reports the buffering lenght normalized to a required value (es: 4 sec). At the beginning, the buffer starts to fill linearly because the playing is not yet started and the bandwidth is constant. In time T1 the buffer is full, the stream start to play and the buffer is keeped full by a bandwidth greater than the required (Available bandwidth > 100% of the required by stream). In T2 the available bandwidth becames insufficient and the buffer starts to empty. In T3 the buffer is definitely empty, the stream is paused and therefore the buffer restart to fill almost linearly because of the almost costant bandwidth (notice that the refill time is more than doubled because of the halved bandwidth). Reached the full state, the stream exits from pause and the buffer lenght is the result of the buffer flushing (dued to the playing) and the buffer filling (dued to the available bandwidth). In time T5 the available bandwidth reach the 100% minimum required value and the buffer becames to fill again up to the full status (T6).

We have seen that with this standard, static buffering method, if bandwidth decreases under the required value, the buffer may be insufficient to compensate the bandwidth void and one or more rebuffering may be necessary to get over. Obviously with a bigger and deeper buffer, this could not happen.

We must indeed choose a buffer depth thinking that:

1. to prevent rebuffering, the buffer must be deep. A deeper buffer can compensate a longer time lapse with insufficient bandwidth.

2. a buffer to much deep means an higher buffering time and probably a worst viewer experience.

Why then not to use a dynamic buffer instead of a static one ?

The rise of the dynamic buffering

Using the onStatus event of our netStream object, we are able to recognise when the buffer is full or empty. So, we can set a starting buffer lenght and then, reached the buffer full status, we can set it to an higher value to exploit the bandwidth eventually in excess. If the buffer goes empty, we can lower the buffer lenght again to the starting value. The code is quite simple:

// Init

startBL=2; mainBL=15;
in_ns.setBufferTime(startBL);
in_ns.onStatus = Status;

function Status(infoObject:Object) {
if (infoObject[“code”]==”NetStream.Buffer.Full”){in_ns.setBufferTime(mainBL);};
if (infoObject[“code”]==”NetStream.Buffer.Empty”){in_ns.setBufferTime(startBL);};
};Let’s take a look at the dynamic buffer behaviour:

Compared to the previous behaviour, when the Starting Buffer (SB) is full, the buffer lenght is enlarged to exploit the amount of bandwidth beyond the required. Until the time T2, when available bandwidth decreases under the 100%, the buffer continues to fill. With this “supply” of video, the lack of bandwidth between time T2 and T3 is handled without video interruptions. At time T3 bandwidth returns over the 100% and the buffer grows again.

The dynamic buffer can guarantee short starting time (using a low startBL) and at the same time an arbritarily high resilience to bandwidth fluctuation. Dynamic buffering is more usefull when average bandwidth is higher than the required (a very common scenario). When average bandwidth is equal to the required, it is still usefull but starting buffer must be deep since the beginning with less advantages.

If the video is often seeked, may be usefull to set a mainBL not too high.

Dynamic buffering in progressive downloaded video is useless, because the download is inherently dynamic, infact while the buffer fills, the whole flv is cached by the player, even beyond the buffer.

Categories: Uncategorized