LIFE IN A RICE BOWL

How to choose an ABR/CBR bitrate

2011-10-16T17:10:00.000-07:00

What bitrate should I choose for my content? a hard question to which experts agree there is no "right" answer, because "it depends".

But let's face it, sometimes, you need to encode your content to an average bitrate, in order to fit on a DVD, or even to a constant bitrate in order to facilitate realtime streaming, additionally, you may need to do so automatically, without a video-quaity engineer tinkering with various encoding options and experimenting with different bitrates and resolutions.

sometimes, you need presets that just work.

The aim of this humble blog post is to convince you that the well known metric bits-per-pixel or bpp makes sense in the context of roughly estimating the quality of encoding of most contents.

As we know fidelity of still pictures can be measured in bpp where 24bpp is widespread for uncompressed images, this notion can be extended to compressed images such as JPG by dividing the size of the file after compression by the number of pixels [and multiplyiong by 8].

As an example, Chrysantemum.jpg [a sample jpg file shipped with windows7] takes up 879,394 bytes and decompresses to 1024x768 pixels, Thus it may be said to have 8 * 879,394 / (1024 *768) = 8.94 bpp, or about one third of the uncompressed image.

With moving video, much better compression can be achieved, therefore I find it useful to use milli-bits-per-pixel or mbpp instead of bpp:

The estimated quality Q in mbpp units.
X, Y are the frame width and height respectively.

or in words, the estimated quality Q in mbpp units equals 1/1000 times the bitrate [in kbps] divided by the frame size [resolution] and the frame rate [FPS].

how can one use this metric? the mbpp defined in this way describes a linear ratio between bitrate, resolution and framerate, which can be used as quality estimation index. My experience shows that when encoding using x264 with the default settings, the following observations usually hold, across many frame rates and resolutions:

Content consisting of talking heads against a non-complex background can be convincingly encoded using an mbpp index of 100, these usually include talk shows, panels, speeches etc.
Scenes with good lighting, Indoor scenes, closeups, usually found in dramas or comedies, can usually be convingly encoded with an mbpp index of 150.
Fast moving scenes; Scenes with poor lighting, or scenes with lots of movement against a complex backdrop (such as soccer players running on highly textured grass) require a higher mbpp index of 200 to include the finer details
Scenes with complicated movement such as snow, water ripples, smoke or explosions are not very amenable for block-based motion compensation and will require a higher bpp index, perhaps up to 300 or so

to put things in perspective:

Cable companies often encode their 1080i HD channels [59.97 fields per second] in anything between 3000kbps to 10000kbps, with an mbpp index of 48 to 161, respectively.
Blu-ray discs have a maximum bitrate of 40 Mbit/s.corresponding to an mbpp index of 804 for 24fps 1080p content. respect!

Some criticisms of this foolishly naive metric

To use mbpp as a quality index, one has to calibrate it based on some encoder implementation and parameters, change anything, and the numbers become much less meaningful.
Some people argue that while the number of pixels grows quadratically with the vertical resolution, that bitrate should not grow quadratically too and should according to the square root of the number of pixles , because some information is redundant. while I think this claim has some merit, I find that this makes the resulting metric less intuitive, and the numbers it predicts just don't feel right for me.
I've personally found that doubling the FPS from 30 to 60 does not necessitate a similar doubling of the bitrate to maintain quality, and that often a 50% increase in bitrate will suffice. this suggests that a better index than mbpp might not depend linearly on FPS, and ideas on how to achieve this are welcome.

Remember, this is just a rule of thumb, but I believe it can help tremendously to find a good starting point for experimentation.

Lastly, I've written a javascript-based mbpp quality calculator, which you can find at the bottom of this page.

How to [not] choose bitrate - using constant quality where applicable

2011-05-05T16:41:00.000-07:00

What bitrate should I choose for my content? This tricky question is best avoided in certain situations. instead sometimes one can employ constant quality rate controls like CRF or CQP

When someone use CRF or CQP it's like ordering "use whatever bitrate is necessary to preserve this much detail".

Constant Quantization Parameter is an easy to understand rate control method: it discards the same amount of detail from every frame. x264's Constant Rate Factor [CRF] oneups CQP as it considers how human perceive video quality:

The eye perceives more detail in still objects than when they're in motion. Because of this, a video compressor can apply more compression (drop more detail) when things are moving, and apply less compression (retain more detail) when things are still. Subjectively, the video will seem to have higher quality.

so what it does is that it

[CRF] varies the QP slightly. When a scene has a lot of action and motion, it will raise the quantization parameter (compressing more). This is because your eye will be distracted by everything going on, and won't have the image on screen for enough time to see the heavier compression. When a frame doesn't have a lot of motion, it will lower the QP, compressing it less. This is because your eye will have more time to look at the image, so you want it to be as much like the source as possible.

This works fantastically if you are "archiving" your blue-ray collection, and want to use the minimum amount of disk space for the quality you care about. or in other words:

"use whatever bitrate is necessary to preserve this much detail".

Here's a the simple algorithm for choosing the right CRF for your needs:

Encode some clips with a given CRF
[lower is better, 20 is a reasonable starting place]
Find the highest CRF that still looks good to you
Go ahead and encode your movie with said CRF

Using CRF completely bypasses the need to choose bitrate, and dealing with the nasty effects of constant bitrate modes. If you can't tell the difference between encoding with CRF 15 and encoding with CRF 12 then you can go right ahead and encode with CRF 15 - after all, you can't tell the difference.

So why doesn't everybody use this magical rate control method that saves you so much headache? well if you're doing live video streaming, then very often you want to make sure you never exceed the maximum network bandwidth, or otherwise the receiving party will often see a buffering icon instead of video, and on the other hand, you want to maximize the video quality at any given moment, so it makes no sense to save on bits when the network is not completely saturated - that's the dreaded CBR or constant bitrate mode.

What about VOD?

if you are downloading a file with torrent or emule, we're talking about an offline download - you've set the file to download, and you're going to check up on it in a couple of hours or days and watch it then, when its already completely available on your disk. in this case, use CRF to get the lowest filesize for your requested quality.
If you're trying to watch a video from Hulu or some other online video site, what you are interested is to start viewing immediately, and not require buffering while watching. in this case CRF is not your friend as you don't want bitrate to increase beyond your download capacity in some fast-paced action sequence, as that will likely require you to wait.

Another way to say this is that CRF can be used where the concern is more about total file size, and less about peak momentary bandwidth - such as when playing from a file on a local disk.
CBR, on the other hand, might be more appropriate in scenarios where peak momentary bandwidth is limited (such as internet download speed) but total "file" size is less of a concern (continuous streaming).

Now, should files on a VOD site be encoded in CRF or CBR?

Some might say that since the video is acquired with a progressive HTTP download instead of old-fashion live video streaming, then CRF should be used.

I believe that distribution method is less important, instead the crucial question is whether the user wants to see the video immediately [in which case CBR will prevent annoying buffering periods], or at some later time [in which case CRF is appropriate and will deliver better quality for same download size].

A Reader asks

2011-05-05T01:45:00.000-07:00

Live streaming capture card checklist

under this post you dismissed korean and chinese capture cards.
I was looking for some low end decent card for myself, could only go upto Hauppauge colosasus for $170 and Avermedia Darkcrystal capture sdk for $250
Do you have any opinion on this or any other similar korean/chinese card around this budget.

I am more familiar with high-end broadcast quality capture cards, mainly those with SDI interface, and my post relates to that class of cards. as far as I know Hauppauge has a good reputation in the consumer market.

The media processing pipeline

under this post you mentioned "... circumventing digital copy protections schemes such as HDCP" Is this really possible, Avermedia guys were saying there should be some way to get "HDCP 3" to capture content using HDMI or to go with component output

HDCP basically requires all receiving hardware to be "certified" in order to be able to get the key to decrypt the HDCP protection. Only devices such as TVs and monitors, which will not allow redistribution of the protected content can be certified. in order to create a capture card that will accept HDMI with HDCP protection one has to go the non-legitimate path and obtain a pirated HDCP key. I can only assume that there are probably some Chinese cards out there with cracked HDCP protection, but I am not aware of any specifics.

The facts are that most HD content is HDCP protected on the HDMI output of the set-top box, and that all well-known and legitimate capture cards respect this HDCP protection.

The way to circumvent this protection is to capture in HD from the component output of the set-top box. in fact if you look at the popular Slingbox that are used to capture content from set-top box and stream over the net, they have excluded HDMI altogether because of this very problem.

so bottom line: get a decent capture card with component input, and forget about HDMI. lastly, for your encoding and archiving needs, don't forget to checkout open source software such as as MediaPortal and MythTV, these might save you the 250USD for avermedia sdk.

Live streaming capture card checklist

2011-04-25T16:24:00.000-07:00

Capture cards are a tricky business.

I've personally reviewed at least 10 different capture card models, from at least 5 different vendors. there's only so much information you can glean from the online technical specification and user manual, eventually one has to write a big fat 1000$ check and get his hands on an actual card to test it. test it for what? you may ask. there are many pitfalls, most of them are not advertised in the marketing materials or even in the technical specs:

will the card work and support all it's features in 3rd party software?
does it work on a windows server 2003/2008 platform? on a dual socket system?
does it support input format detection?
does it support multiple capture sessions?
can two or more cards be installed on a single machine?
can it continue capturing if the input format changes?
can it capture on a 24x7 basis for weeks on end without freezes, hangups or memory leaks?
what is the full range of its processing abilities, including scaling, deinterlacing, cropping, subtitles?
if the card has multiple inputs, how many can it realistically process independently at the same time?

Now, a lot of vendors taut their card's SDK and say that it can support many of these features, however, for some reason they have not themselves produced software that actually provide said features. Have they not considered the fact that a potential client might wish to evaluate the quality of their product before galloping off to write a driver for it using their [expensive] SDK?

Listen up capture card vendors: there are a lot of people doing live streaming, and many of them are ill prepared to pay 5000$ - 20000$ for hardware appliances when same or better can be had using a 3000$ server and a capture card. Right now the only vendor I know to come even close to filling these demands is Viewcast's Osprey 700e, at a costly 2000$ per card, which support only a single video input.

Sure, the competition does seem to try to put their foot in the door, but not very succesfully: Blackmagic's cards don't even work on server platforms, AJA's Kona doesn't work on 3rd party encoders, and don't even get me started on the cheap Korean and Chinese clones.

I'd appreciate your comments regarding any other vendor I might have missed, we want to buy a lot of capture cards, people!

Review - Decklink capture card by Blackmagic design

2011-04-23T16:17:00.000-07:00

Decklink HD Extreme

Generally, Blackmagic design offer products with superb quality, thoughtful design and a reasonable price. On paper, the Decklink capture card family seems no exception: offering flexible analog and digital capturing, HDMI connectivity, HD-SDI and multiple channel capture, all at reasonable sub 1000$ prices.

Viewcast Osprey 700e

In comparison, Viewcast's Osprey 700e card offers a single channel HD-SDI capture without any analog or HDMI options, while costing twice as much at 1995$ a piece.

So how come Viewcast are still in the market with such fierce competition from Blackmagic? you won't find the answer in technical specs or in data sheets, but in the actual use of the platform.

first off the bat, the Decklink card is certified only for desktop versions of windows such as vista or windows 7. installing the decklink on a dual-socket windows 2008 server results in an immediate blue-screen-of-death, so forget about using it in your high-powered transcoding server.
It doesn't have an input format detection logic. is the incoming video in 720p30? or is it 720p60? or maybe it was PAL? decklink won't tell you. instead you have to manually try to specify the right format from a drop-down-list of 30 formats. oh, and are you sure the video is coming in at all? because decklink won't even tell you if there's a signal on the cable or not.
Multiple captures not supported. so, if you are interested in encoding your captured video into multiple resolutions, you might be have some trouble as the capture driver has a single instance which can't be shared.

bottom line: for editing with a single predetermined format, this card might be an affordable and flexible solution. if you're looking for a card for a transcoding server, look elsewhere.

The media processing pipeline

2011-04-23T15:42:00.000-07:00

In the world of media, either you get it, or you don't, and by that I mean that there's a lot of stuff that is painfully obvious to experts and those in the know, while the same stuff is painfully obtuse and hard to understand for those who don't already know. the experts find it both hard and redundant to explain the basics of their field, while the newbies are overwhelmed by the breadth of the subject and don't even know what to ask.

yes, I was that newbie, and in many ways I still am. what little knowledge I have gleaned in this subject I will gladly share in the hopes it will help others who are eager to step inside this exciting field.

Today, I'd like to touch on a subject I like to call the media processing pipeline.

have you noticed how different systems that process media, often refer to internal components with words such as, graphs, filters, sinks, sources, flows, pins, pipes and generally use a lot of plumbing analogies? that's because media processing has always been and still is today a very complex task, which is broken into many smaller stages, performed in certain predefined sequences, each concerning itself with very different problems. Engineers [who are often glorified plumbers of electronics and software] refer to this kind of situation as a flow and the rest of the analogy follows naturally.

What are the usual tasks handled in such a workflow:

I/O - Storage, transmission, retrieval, Archive. basically reading, writing or transferring the data for the media
Muxing/Demuxing - The task Correlating or de-correlating multiple media streams [video and audio] so that they may be read/written/transferred together as a single stream of information, and assign presentation timestamps on a common scale to all samples [such that voice matches lip movements]
Processing - The task of changing the media, such as rescaling, frame rate conversions, color corrections, deinterlacing, cropping, padding, sharpening, blurring etc.
Compression/Decompression - The task of converting media from a format that is easy to process or display, to a format that is economical to store and distribute, and vice versa.

and here is how a full workflow looks like:

The above workflow is a very common one, in fact this is what happens to your file when you upload a video file to youtube:

for instance, suppose you upload a file in .avi format, with video compressed with DIVX codec and audio in MP3. your uploaded file [in AVI format] is being read, its bytes analyzed by a [AVI] demuxer who seperates the data stream into chunks representing [MPEG4] video frames and chunks representing [MP3] audio frames. these frames are each passed to an appropriate decoder that decompresses them into a raw form suitable for processing. then processing [scaling video to 240p, resampling audio to 48khz] is performed on each decoded sample. then the samples are compressed by an encoder [VP8 for video, AAC for audio] and muxed into a single [Webm] stream of bytes, stored locally as a [.webm] file.

Sometimes, it makes sense not to use each and every possible component, instead skipping a few stages in order to save processing time, or to avoid losing quality or fidelity. for instance, a web media server often just streams a file in .flv format via RTMP protocol, without doing decoding or encoding.

In digital media processing, the lossy part of the workflow is limited to the processing and encoding stages. that means that you can read the media, demux from file format XXX to file format YYY without any loss of quality. as long you don't do any processing or encoding, you're completely safe from any degradation in fidelity. loss of quality or fidelity is also known a generation loss.

Encoding is the task of representing media using less bits. The achieved reduction in size [compression] is pretty astounding - compressing to 1% of original bitrate: uncompressed 720p requires too much bandwidth to be stored or distributed without compression to a consumer: at 1280 pixels wide, 720 lines, 2 bytes color information per pixel, 30 frames per second, 8 bits per pixel we get 1280 x 720 * 2 * 30 * 8 = 442,368,000 bits per second or ~442mbps, whereas blu-ray video bitrate is capped at less than 10% of that at ~40mbps, while still delivering superb, almost lossless quality. HD TV broadcasts are often compressed much more aggressively, to ~4mbps, while still delivering high-fidelity. while lossless video compression can sometimes achieve a 50% reduction in size, this is often not enough and the video is further compressed by discarding details. thus compression is almost always a lossy process.

while our technology is becoming more and more digital, there is often a need to interface analog equipment, either when capturing from an analog media source, storing or transmitting through analog channels, or when circumventing digital copy protections schemes such as HDCP. using analog equipment and analog-to-digital and digital-to-analog will always lead to generation loss, although with high-grade analog equipment, this loss can be minimized.

One often finds that hardware appliances concern themselves with a single processing tasks, and complex pipelines are achieved by chaining these appliances. one can find boxes for audio/video decoders, video scalers, audio/video encoders, and modulators/demodulators for transmission over physical channels.

win32 builds for libav

2011-04-18T04:22:00.000-07:00

Libav is releasing official windows builds, in both 32bit and 64bit flavors, that's great news to all you windows hackers, users, rippers, and personal DVD backup freaks out there.

even better, they come with the best features already built-in, such as networking, threading, x264 encoding and RTMP support.

Starting from the next build, it will be easier to use x264 presets as they only need to be copied to the same directory as ffmpeg.exe to be immediately usable, no need to set any weird environment variable in order to find them.

Kudos, Libav!

Encoding more pixles, using less bits with cheaper hardware

2011-04-17T14:02:00.000-07:00

The company I work for, does live video streaming, with an emphasis on the streaming part.
Therefore, some people ask why bother building our own video encoding platforms, when so many encoding platforms already exist? in fact the web seems awash with adverts touting the latest in encoding technology.

The answer is simple: price and quality.

The prices for HD video encoders borders on the ridiculously high: with anything between $5000 used Tandberg and a $19,000 Viewcast Niagara per channel being the norm. Alternatively, one could use commodity servers and open source software, and encode the same number of streams for much less: between $3000 to $4000 USD per 12-core intel server.

But what about quality?

First, if you're using a software encoder which isn't x264, you're not getting your money's worth, as x264 repeatedly beats the crap out of every other software encoder in the world in the yearly Moscow U codec contests.

Secondly, hardware encoders and DSPs don't even stand a chance, because hardware is (duh) harder to program and to tweak than software. x264 trumps all other encoders because it uses specialized and adaptive algorithms with lots of lookahead, trees and whatnots. conversely DSP encoders are more like big pipelines that can do many similar operations at once, but they are not very good when the calculations require branching and conditionals, therefore they often opt for algorithms that work well on average instead of adaptively switching between specialized algorithms or parameter sets for different scenarios. so off the bat DSP encoders are crippled algorithmically relative to software encoders, and their supposed increased performance relative to general purpose CPUs is immediately offset by their unreasonable pricing relative to ever decreasing prices of commodity CPUs.

That leaves only GPGPU aka encoding on commodity super-computers - emphatically known as graphic cards. Right now there aren't any good GPU encoders; the contenders, nVidia's badaboom and intel's Quick Sync are fast, but still give a less than desirable bitrate/quality ratio. I hope to see them in the 2011 MSU codec comparison, but I don't have my hopes up on seeing anything other than raw speed. IMHO GPUs are important for the future for encoding because they are commodity hardware[which means they are going to be better and cheaper every year], they are incredibly powerful, and many [but probably not all!] encoding operations [such as the decoding and motion estimation phases] can be efficiently performed on them.

I had high hopes for an x264/intel collaboration that will result in an improved x264 capable of using Sandy Bridge's promising new technology, but it seems it fell through:

Work is planned to integrate x264 with the Sandy Bridge's encoding ASIC for improved encoding performance. Current status is: waiting on Intel (these guys move at the speed of an obese one-legged paraplegic three-toed sloth swimming down a stagnant river of -- ah, fuck it, Intel has never cared about open source anyways. Last week we caught them trying to promote their terrible proprietary encoders as a replacement for open source software -- nice try, backstabbing fucks.

sad state of affairs really, especially since it would have made the case of intel+x264 even more obvious, which would be a big win for intel IMHO.

but if open-source is so great, why bother writing your own encoder instead of using open-source directly? Well, open-source needs to be tamed before it is used. it needs some pushing and prodding to work on windows, it neglects networking support in favor of files, it employs a "crash and burn on error" mentality, it has crude and ineffectual logging capabilities, the most useful functionality is often scattered between several small tools and utilities that are not easy to integrate together and above all it has a terrible UI.

To wrap it all together: don't buy a crappy hardware encoder, use open source on intel instead. you'll thank me when you will be able to realtime encode 720p content using only 2100kbps while getting great quality. or you can do one better and buy an encoder from the company I work for - same great quality, easier to use and server-side-oriented, plus you get unbeatable cloud-based streaming, which is what we're famous for.

פיירו סהרורי - תרגומים

2011-04-08T16:55:00.000-07:00

Pierrot Lunaire - Albert Giraud

Pierrot lunaire: rondels bergamasques (Moonstruck Pierrot: bergamask rondels) is a collection of fifty poems published in 1884 by the Belgian poet Albert Giraud (born Emile Albert Kayenburgh), who is usually associated with the Symbolist Movement. The protagonist of the cycle is Pierrot, the comic servant of the French Commedia dell'Arte and, later, of Parisian boulevard pantomime.^[1] The early 19th-century Romantics, Théophile Gautier most notably, had been drawn to the figure by his Chaplinesque pluckiness and pathos,^[2] and by the end of the century, especially in the hands of the Symbolists and Decadents, Pierrot had evolved into an alter-ego of the artist, particularly of the so-called poète maudit.^[3] He became the subject of numerous compositions, theatrical, literary, musical, and graphic.

Translations to hebrew follow:

direct link

שיר פוליטי - ספר השירים

2011-04-08T16:10:00.001-07:00

direct link

כמעט אהבה - ספר השירים

2011-04-08T15:38:00.000-07:00

direct link

עיר לילה - ספר השירים

2011-04-08T15:29:00.000-07:00

direct link

רגשות רציניים - ספר השירים

2011-04-08T15:06:00.000-07:00

direct link

The ffmpeg fork

2011-04-05T09:46:00.000-07:00

This post relates to my own personal choice and opinions about the ffmpeg fork.

if you aren't familiar with ffmpeg or libav, this post isn't for you.

Over the years I have watched ffmpeg closely and used it often, reading the source code carefully, and sometimes tweaking this bit or the other. sometimes I had tried to post patches but the barrier to get them accepted was too high for me. additionally I saw on many occasions how conversations in the ffmpeg mailing list could get rather rude, especially toward people who are new or aren't already respected commiters.

Since getting even small or minute patches into ffmpeg was exceedingly hard, you can imagine that making bigger changes was even harder... this explains to me how it took so much time to integrate ffmpeg-mt into mainline.

To me, Michael did not lead the community into worthy goals such as multi-threading, hardware acceleration, windows support, high bitrate UDP and other lofty endeavors. These important issues lay dormant, while the community seemed to improve ffmpeg in seemingly random directions. often, when a non-commiter suggested patches towards a worthy goal, the community as a whole fought, bickered over, bike-sheded and tore down the attempt.

to me, this means that Michael failed as a leader. I expect the leader of an important and even extraordinary project like ffmpeg to have a vision matching in depth, much like the leaders of python, perl and indeed the linux kernel

Leaving aside personal wars, agendas, who did what to whom and why, and who wrote which module, I simply appreciate the mission statement of libav and think they are doing their best to have calmer discussions,

to accept feedback from users, to help patches be accepted instead of just rejecting them.

basically, I find it easier to work with the libav people, and that's enough for me to choose to spend my time over there.

VBV for dummies?!?

2010-12-19T09:05:00.001-08:00

Following the success of the H.264 extradata for dummies article, I would have liked to write a followup article on another subject that seems to confound a whole bunch of people including myself. unfortunately, this was not to be as I don't seem to be able to understand it completely ... :-(

so instead, I', going to write everything I know about VBV / HRD and hope that someone smarter will figure out the answer and share it with the rest of us.

The question is:

what is VBV?

how does it work?

how do I apply it in the context of real-time streaming [not progressive download]?

what happens if the bitrate stays low for a long time [encoding a frozen image]?

This is what I know so far:

VBV or Video Buffer Verifier, sometimes known also as HRD [Hypothetical Reference Decoder] Buffer model

The HRD buffer model is defined in H.264 manual on page 308 [if you can read standardese, which I can't]

obviously, VBV conformance is something that is done by the encoder. the player/decoder only has to read the stream and hope for the best.

so if you want to read a highly optimized [read convoluted] implmentation of VBV you can find it in the sourcecode of the x264 project

VBV is a leaky bucket algorithm

http://en.wikipedia.org/wiki/Leaky_bucket

there is some information on it on wikipedia

http://en.wikipedia.org/wiki/Video_buffering_verifier

and also here

http://www.bretl.com/mpeghtml/VBV.HTM

but I don't think they are a very good at explaining it.

dark shikari (x264 main developer) is the best to explain it, and does so here

For streaming, set bufsize equal to (maxrate) * (number of seconds the player is set to buffer).

http://85.230.118.163/showthread.php?p=1338852

and also by LoRd_MuldeR

Basically, it works like that: Bufsize specifies the size of the device's buffer. That buffer is filled with a constant data rate. That "input" rate equals the CD/DVD/BD read speed (or the Network bandwidth). Still the video is allowed to have a variable bitrate. So if the bitrate of the video increases over the input bitrate, then the buffer will slowly run out of data. Hence you can have only short bitrate spikes. If the bitrate of the video falls below the input bitrate, then the buffer will slowly run full. Hence you can have only short "low bitrate" periods. VBV takes care of all this! It makes sure that the buffer will never overflow nor underflow, as that would cause playback errors. Maxrate specifies the maximum bitrate that the video can ever have. I think Maxrate is independent from the current buffer filling level, but I may be wrong...

http://img33.imageshack.us/img33/4306/weg.gif

How do you com up with the correct buffer size? Well, the buffer size is defined by the device's hardware. You need to know the correct size of the individual device ;)

http://forum.doom9.org/archive/index.php/t-147460.html

that's what I have ...

Underused Game

2010-08-05T15:35:00.001-07:00

For the last months I have been following various blogs revolving around rationality, evolutionary psychology, economics and related fields. often this has led on many interesting, bizarre and quite contrarian opinions and world-views, a lot of which I find myself in agreement with.

In particular, I've become acquainted with with the seduction community Whose unorthodox modus operandi and non PC attitude would probably have left them an anomalous curiosity of the blogosphere, were not for two facts:

The community was outed in a book called The Game which became a instant best seller
Their techniques are highly successful

Basically, it comes down to some very basic observations, which are becoming widely accepted in the rationality circles:

People will say or even think they want property X, while they actually want property Y
Evolutionary psychology explains why we are "programmed" to want property Y
Signalling is the process of making someone else think you have property Y, and it can often be spoofed.

in Pick-Up-Artist (PUC) speak these can stated (in the particular context of seducing women) as:

Women may say or think they want a talkative, caring, loving, safe, monogamous partner, who does dishes and laundry, while most women will find themselves sexually attracted to dominant males. The former are known as "beta" males while the latter are known as "alpha" males. The positive traits listed above will often detract from a male's domination factor rather than enhance it, therefore for the purpose of seduction, they are counter-productive.
According to evolutionary psychology, women are programmed to want dominant males, as being dominant correlates with having high-status, being able to provide food and protection, and therefore with the ability to support more children.
There are many techniques to signal your dominance and high-status, or to signal that others are not as high-status as they thought. they are extremely useful in a seduction setting.

Ultimately, this is about communication: understanding what the other party (perhaps unconsciously) needs or desires, and carefully controlling your communications and signals in order to convey your message in the most effective way. ultimately this becomes second nature: the game is its own status

This community is extraordinary in the fact that they are practicing and preaching a theory, that isn't used outside of academia at all, after cracking the greatest male mystery of all time: what do women want.

However, reading through their material, one cannot help but think they may be missing the point here. sure, males have always wanted to know how they can get access to unlimited sex with multiple attractive women. sounds nice, no? yet it seems kinda ... empty.

certain studies into human happiness show that this state can be achieved when proper does of fun and meaning are present in a person's life.

and screwing around as many women as possible does seem fun, but not very meaningful, does it?

Furthermore, one may quickly realizes that many of these observations and techniques can be used for more other endeavors as well, such as maintaining interest and romance in a long-term relationship, building status and prominence with friends and colleagues, or gaining an edge in a negotiations.

In this light, it may be that this gem of knowledge and know-how is being underused or even misused. heck, they could even teach these things in school!

And finally, an apology:

Seduction often goes against that we are taught to believe, it is highly non-PC and may seem derogatory towards women and counter productive to the feminist cause.

I think people are happier when they know their own nature and live by it, then when trying to live out some ideal which isn't really suited for human nature. [did anyone say communism?]

As for me, I'm getting married to Lily, a wonderful person who I love dearly. It is interesting from a scientific point of view to learn what women-nature is, but it is much more important to learn who Lily is, and what she wants and desires. if its the dishes - i'll do the dishes. if it's a badass jerk on a motorcycle... well I can be that too ;-)

מקום 1710 בדירוג נט ניר

2010-07-16T07:11:00.000-07:00

באופן לא ברור, בלוג זה הגיע למקום 1710 מכל האתרים הישראלים ברשת. לדעתי זה די משונה, במיוחד שמילות החיפוש שגורמות לאתר להיות מדורג גבוה הם למשל אי. אם. פי. אם שבחיפוש האתר הזה מגיע למקום רביעי.

VP8 vs H.264

2010-07-14T04:41:00.001-07:00

Dark Shikari [of X264 fame] with another writeup about VP8, concluding several weeks worth of building an indepedent VP8 decoder.

here are some highlights from the article:

x264 is better than VP8 compression wise:

Now that I've written a thousand or two lines of assembly code and optimized a good bit of the C code, I'd like to look back at VP8 and comment on a variety of things — both good and bad — that slipped the net the first time, along with things that have changed since the time of that blog post.

These are less-so issues related to compression — that issue has been beaten to death, particularly in MSU's recent comparison, where x264 beat the crap out of VP8

...

VP8 doesn't have to be the best in the world in order to be useful.

Google admits spec is non-existant, and [one might guess] subject to change:

1. The spec, er, I mean, bitstream guide.

Google has reneged on their claim that a spec existed at all and renamed it a "bitstream guide". This is probably after it was found that — not merely was it incomplete — but at least a dozen places in the spec differed wildly from what was actually in their own encoder and decoder software!

...

many more parts simply disagreed flat-out with the spec.

Fortunately, ... we were able to put together a matching implementation regardless.

the "truth" behind On2's claims to be both higher quality and faster than H.264 is made painfully obvious:

3. Performance and the deblocking filter.

On2 advertised for quite some that VP8′s goal was to be significantly faster to decode than H.264. When I saw the spec, I waited for the punchline, but apparently they were serious. There's nothing wrong with being of similar speed or a bit slower — but I was rather confused as to the fact that their design didn't match their stated goal at all. What apparently happened is they had multiple profiles of VP8 — high and low complexity profiles. They marketed the performance of the low complexity ones while touting the quality of the high complexity ones, a tad dishonest. More importantly though, practically nobody is using the low complexity modes, so anyone writing a decoder has to be prepared to handle the high complexity ones, which are the default.

This IMHO completes his fine essay [which made headlines after steve jobs posted a link to it] on the differences and striking similarities between VP8 and H.264 a few weeks ago.

conclusion for the lazy:

VP8 is very similar to H.264, but it does not have better quality, nor is it faster.
in the face of such striking similarities, the burden of proving VP8 being patent-free is still on Google.
The VP8 spec is not complete or final in any way, so it might take time to integerate this codec into hardware devices.
and lastly, having no hardware-accelerated support in existing smartphones/mobile-devices for decoding VP8 makes it very CPU and battery intensive.

with all these difficulties, I don't think its going to win the HTML5 standoff.

חברת קיי.אס.פי. מחשבים מפטרת את הלקוח

2010-07-04T14:35:00.000-07:00

אני מאמין בלפטר לקוחות. יש לקוחות גרועים, שבמקום לתת להם שירות, עדיף לנו פשוט לפטר אותם ולהפטר מהם

כך אמר לי רן, המנהל האזורי של קיי.אס.פי מחשבים בסניפו הקטנטון שבדיזינגוף סנטר. "הלקוח תמיד צודק" היא אימרה שקיי.אס.פי מאוד לא מאמינים בה.

ומקרה שהיה כך היה:

יצא המקרה, ואשתי (לעתיד) אוהבת לראות סרטים. כבן זוג אחראי ואוהב מייד הצעתי לקנות מערכת מחשב לסלון שתבדר אותנו כראוי. שיניתי מהרגלי ובמקום לקנות באייבורי סרתי אל סניף קי שבדיזנגוף. בקלות רבה בחרנו מחשב, כרטיס האשראי עבר בחריץ, ושמחים וטובי לב הלכנו הביתה להמתין בכליון עינים לבואו של הפלא הטכנולוגי החדש, שהגיע במארז גדול וחדיש.

רצה הגורל, ובאותם ימים ממש, לקוח אחר קנה באותו סניף במיטב כספו, מחשב משוכלל ויקר אף יותר. גם הוא בחר לו את אותו מארז כמוני, לשכן בו את המוח האלקטרוני.

צחוק הגורל, ובמהלך העברת שני המחשבים השונים בעלי הקופסה הזהה מן המחסן אל החנות, התבלבלו או חמדו לצון עובדי החנות והחליפו בין המחשבים. וכך יצא שבמקום לקבל את המחשב ששילמתי עליו במיטב כספי, נתנו לי את המחשב של אותו אלמוני חובב טכנולוגיה.

לאחר התקנה זריזה של מערכת הפעלה על המחשב החדש, נתגלתה הטעות. חישוב מהיר באתר קיי.אס.פי. הראה כי המחשב החדש יקר יותר בכאלפיים שקלים! שוד ושבר ממש. היות שנכנסה לה השבת בינתיים, חיכינו להשתמע עם נציגי קיי.אס.פי. ביום ראשון.

ואכן בבוקרו של אותו ראשון (היום), פנו אלי נציגיהם הזריזים של K.S.P, וביקשו להחליף בחזרה את המחשבים.

עד כאן טוב ויפה, אלא שלאותם נציגים לא היה אכפת מכך שכבר ביקרתי את סניפם די והותר, ולא חשקה נפשי לבקרם שוב, כאשר החניה על חשבוני, בשעות העבודה הנוחות להם ושאינן נוחות לי.

כמו כן, לא דיגדג להם שהמחשב כבד ויש לחזור ולהוריד אותו 4 קומות, לבקר בסניפם הקטון, ואז לשוב ולהעלות את המחשב אותן 4 קומות.

בנוסף, לא עקצץ להם שכבר השקעתי זמן בהתקנת המחשב ומערכת ההפעלה, ובאופו כללי שזמני גם הוא יקר.

ולבסוף, לא כל כך עניין אותם שהתקלה והבלבול באשמתם, אך הלקוח הוא זה שנדרש להתטרטר כדי לסדר את הבלגן שלהם.

הסברתי להם בעדינות את המצב בטלפון, והם אמרו שהם יפצו אותי בהתאם.

ברוב כבוד והדר, הסעתי את המחשב, ארוז מחדש באריזת הקרטון המקורית, לסניפון האמור. ושם, לאחר שהמתנתי והמתנתי, הודיע לי רן, אותו מנהל איזורי, כי לאחר שהתייעץ ארוכות עם מנהל העל של הרשת המצליחה, החליטו להעניק לי, לפנים משורת הדין, זיכוי בסך 100 ש"ח.

100 ש"ח, הם לדעת קיי.אס.פי. פיצוי הולם לטרחה ולעוגמת הנפש שלי. 100 ש"ח, שאין ולא מוצר אחד בסניף במחיר המצחיק הזה. הייתי מצפה שבזמן שהמחשב שלי יושב אצלם, ממתין ומחכה לבעליו האמיתיים, הם יחשבו להוסיף קצת זיכרון, לשדרג איזה כרטיס מסך. בכל זאת הייתי לקוח חביב ומתחשב. הם לא חשבו כך. מנהל העל של רשת הענק קיי.אס.פי. חושב שמאה ש"ח מסכמים די טוב את ערכי השירות והאיכות שלהם. לקוח מרוצה שווה להם בדיוק מאה ש"ח. לקוח שחושב אחרת, הוא לקוח רע, לקוח שצריך לפטר.

דווקא אני פיטרתי אותם, וגם נפטרתי מעונשם. דרשתי וקיבלתי ביטול עסקה מלא. את המחשבים הבאים אמשיך לקנות באייבורי, שם לפחות זול יותר.

K.S.P

You suck.

הבובנית - סקס והעיר הטעימה

2010-07-04T13:42:00.000-07:00

אני מזמן כבר יודע שאם רעבים למשהו טוב, לא כדאי להרחיק מתל-אביב. אבל כאשר דוויט מ"המשרד" אמר ש"מול ים" היא מסעדת הדגים הטובה בעולם, הבנתי שתל אביב היא על המפה הגסטרונומית העולמית.

מה שחסר לנו היא דמות נשית וכריזמטית שתמשיג, תשעשע, תפליג בתשבוחות ובביקורות, ותספק מתכונים שווים. משהו כמו קארי מסקס והעיר הגדולה, אבל על אוכל.

מזל שבדיוק נפתח בלוג חדש בשם הוא מבשל לי שמספק את הסחורה, בצורה משעשעשת, קולחת וטעימה ביותר ...

כדאי לקרוא, לבשל ולאכול.

בתיאבון!

H.264 extradata (partially) explained - for dummies

2010-05-25T13:06:00.000-07:00

While this article will seem obvious and redundant to anyone who is fluent in H.264, i'm hoping it will come in useful for those people who stumble upon this issue.

I'm not going to go into any details about H.264 internals, parameters or anything like that. instead, in this short article i'm going to treat H.264 as a big opaque black box which has to be fed an annoying piece of information known as "extradata".

what's so annoying about extradata?

it comes in two different flavors
you need rudimentary knowledge of H.264 bitstream in order to retrieve it
you need rudimentary knowledge of H.264 bitstream in order to know which flavor you need

but first, we need to learn about two different flavors of H.264 bitstram.

Annex B format

in this format, each NAL is preceeded by a four byte start code: 0x00 0x00 0x00 0x01

thus in order to know where a NAL start and where it stops, you would need to read each byte of the bitstream, looking for these start codes, which can be a pain if you need to convert between this format and the other format.

AVCC format

This "non Annex B" format is known as AVCC format. in this format, each NAL is precedded by a nal_size field. the size of the field in bytes is in many cases 4, but it is not assumed to be 4, and in fact this is part of the reason why a decoder needs any "extra data", in the first place.

So, Why does a decoder need extradata anyway?

it needs to know what flavor of the bitstream to expect
if AVCC format is used, it needs to know what the is the size of the nal_size field, in bytes.
if the parameters for decoding are not repeated every keyframe, but rather specified only once (such as in a file), it needs those parameters (the SPS & PPS in H.264 speak)

How do I get this extradata?

when reading from a file, the extradata is usually part of the headers of the file, and you (or the demuxer) need to extract it from there.

if the extradata is repeated with every key frame, you can try to extract it from the bitstream itself, most of the time it will bundled in the same buffer or packet as the keyframe itself, and preceeding it.

if the bitstream is in annex-b format, you're in luck! you don't really need the extradata, because the codec can figure it out itself from the bitstream, at most, you will need to tell the decoder to treat the bitstream as annex-b, which is often achieved by NOT supplying any extradata to begin with.

on the other hand, if the bitstream is in avcc format, you desperately need this extradata, without it the decoder doesn't know how long the nal_size field is, and thus cannot even parse the bitstream.

suppose I have the SPS and PPS information, how do I create the extradata?

again, for annex-b format, you just use the following pseudo code:

write(0x00)
write(0x00)
write(0x00)
write(0x01)
for each byte b in SPS
  write(b)

for each PPS p in PPS_array
  write(0x00)
  write(0x00)
  write(0x00)
  write(0x01)
  for each byte b in p
    write(b)

On the other hand, AVCC format extradata is more complicated:

write(0x1);  // version
write(sps[0].data[1]); // profile
write(sps[0].data[2]); // compatibility
write(sps[0].data[3]); // level
write(0xFC | 3); // reserved (6 bits), NULA length size - 1 (2 bits)
write(0xE0 | 1); // reserved (3 bits), num of SPS (5 bits)
write_word(sps[0].size); // 2 bytes for length of SPS

for(size_t i=0 ; i < sps[0].size ; ++i)
  write(sps[0].data[i]); // data of SPS

write(&b, pps.size());  // num of PPS
for(size_t i=0 ; i < pps.size() ; ++i) {
  write_word(pps[i].size);  // 2 bytes for length of PPS
  for(size_t j=0 ; j < pps[i].size ; ++j)
    write(pps[i].data[j]);  // data of PPS
}

notice how the first byte of the avcc extradata is 1, which makes it obvious it is not a start of an annex-b extradata (which must begin with 0x00)

Notes about .mov files and Quicktime

internally, (at least with version 7.0) quicktime codecs work only with avcc formats and not with annex b format. that means that if you are unlucky enough to have H.264 in annex b format and need to decode it with quicktime codecs (for instance on an iphone) you would need to:

convert the annex b 0x00 0x00 0x00 0x01 start codes into 4-byte long avcc nal_size fields.
this requires a loop through the entire buffer, searching for these start codes
you would need to extract the SPS and PPS NALs, and create an extradata buffer from them in the special format outlined above.

additionally, since .mov container is basically a quicktime container, it is natural that H.264 is stored on .mov files in AVCC format, and thus .mov muxers will need to know how to convert annex-b formatted H.264 buffers intead AVCC formatted H.264 buffers, and also how to convert the extradata buffer into one usable with AVCC format.

פישי הגדול מארח - דירת פינוקים בת"א לחודש

2010-01-16T02:54:00.000-08:00

שלום, אני פישי הגדול, חתול האופנה מס' 1 בעולם. וזו הדירה שלי, אותה אני חולק עם לילי ואביעד.

לילי ואביעד נוסעים לחו"ל ועלול להיות לי קצת משעמם. לכן אני מחפש אנשים לארח בדירה.

זה הסלון, היכן שקורה כל האקשיין. דרך אגב לדיירים מעל 5 קילו אסור לדרוך על השולחן, הוא מיועד לחתולים בלבד.

זה המטבח, היכן שמכינים לי אוכל ומלטפים אותי.

וזו פינת האוכל והגינה שלי. מקווה שנהניתם מהביקור.
אם אתם רוצים להתארח בדירה, תרימו לי אימייל.

שלכם
פישי הגדול

Frog prince look

2010-01-10T14:10:00.001-08:00

מלי קרני בלוק בהשראת אגדת הנסיכה והצפרדע. שמלת ערב קצרה בגון צהוב אפרוח , בגזרה א-סימטרית בחלק העליון. ניתן להשיג גם בשחור.

עיצוב, סטיילינג, אופנה, אקססוריז: לילי ברושטיין
איפור: אנה קונצמן
צילום: אביעד רוזנהק

5 pictures for you

2010-01-10T14:06:00.001-08:00

מלי קרני בלוק בהשראת מלחים. שמלה באורך 7/8 בכחול ולבן, עם עניבה אדומה.

עיצוב, סטילינג, ביגוד, אקססוריז: לילי ברושטין
איפור: אנה קונצמן
צילום: אביעד רוזנהק

Pictures submitted to RayV picture contest

2010-01-10T13:35:00.001-08:00