Linked by Thom Holwerda on Mon 17th Jan 2011 21:29 UTC
Multimedia, AV "Even if you don't believe all the hype about HTML5, sooner or later, you'll need to start encoding some video to WebM format. Maybe for internal experimentation, for a pay-per-view or subscription project (where H.264 may incur royalties), because you've decided to jump into HTML5 video with both feet, or because Google announced yesterday that it's going to stop supporting H.264 in Chrome. Whatever the reason, you'll be sitting at your desk or poolside one day, and you'll be thinking 'I've got to encode some video to WebM format'. If and when that day comes, set a bookmark in your memory banks for this article, because it's all about encoding to WebM. I'll start by looking at how WebM compares to H.264 in terms of quality, just to set expectations, and then briefly review the quality and performance of several free and for-fee encoding tools."
Order by: Score:
thank you
by dominik.holler on Mon 17th Jan 2011 21:53 UTC
dominik.holler
Member since:
2007-05-24

thank you, I looked some time for a text like this one

Reply Score: 1

RE: thank you
by Doc Pain on Mon 17th Jan 2011 23:08 UTC in reply to "thank you"
Doc Pain Member since:
2006-10-08

I'm just missing a mencoder command line example. :-)

Reply Score: 4

RE[2]: thank you
by _txf_ on Tue 18th Jan 2011 10:28 UTC in reply to "RE: thank you"
_txf_ Member since:
2008-03-17

I was under the impression that mencoder was not being actively developed or even being maintained...

Reply Score: 2

Encode quality and speed
by lemur2 on Mon 17th Jan 2011 22:43 UTC
lemur2
Member since:
2007-02-17

When you talk about the encoding quality and speed of WebM, it is important to clarify what release you are talking about. The initial version of WebM released by Google when WebM was first announced circa May 2010 is still being optimised in an ongoing process.

In October 2010 Google rleased the VP8 Codec SDK "Aylesbury" Release:
http://blog.webmproject.org/2010/10/vp8-codec-sdk-aylesbury-release...

Aylesbury includes the following encoding improvements:
"Over 7% overall PSNR improvement (6.3% SSIM) in VP8 "best" quality encoding mode, and up to 60% improvement on very noisy, still or slow moving source video."

It will make a big difference to the quality of the results obtained depending if one is using the "Aylesbury" release or not.

From the same blog article linked above, Google also mentions the upcoming "Bali" release, which is due in Q1 2011.

"We're targeting Q1 2011 for the next named libvpx release, which we're calling Bali. The theme for that release will be faster encoder. We are constantly working on improvements to video quality in the encoder, so after Aylesbury we won't tie that work to specific named releases."


It would appear that the Bali release is intended to have an impact on encoding speed.

Reply Score: 2

v RE: Encode quality and speed
by manjabes on Tue 18th Jan 2011 06:56 UTC in reply to "Encode quality and speed"
RE[2]: Encode quality and speed
by Neolander on Tue 18th Jan 2011 08:05 UTC in reply to "RE: Encode quality and speed"
Neolander Member since:
2010-03-08

Ah, when will you both understand that video has to be re-encoded many times for the web anyway ?

Reply Score: 4

RE[3]: Encode quality and speed
by manjabes on Tue 18th Jan 2011 10:45 UTC in reply to "RE[2]: Encode quality and speed"
manjabes Member since:
2005-08-27

Yes, but in one case there's just the matter of exporting a project (from Premiere) to a render queue with different settings, then running the queue and in the other case, exporting a project to an intermediate and then re-encoding, using another program, to whatever the current ideologically-purest-format is.

Reply Score: 1

RE[2]: Encode quality and speed
by anda_skoa on Tue 18th Jan 2011 08:07 UTC in reply to "RE: Encode quality and speed"
anda_skoa Member since:
2005-07-07

These external tools can only be sufficient for small-scale usage.


Small scale as in transcoding several thousand new videos every day (vimeo, blip.tv, youtube)?

Reply Score: 5

RE[2]: Encode quality and speed
by lemur2 on Tue 18th Jan 2011 09:44 UTC in reply to "RE: Encode quality and speed"
lemur2 Member since:
2007-02-17

"When you talk about the encoding quality and speed of WebM, it is important to clarify what release you are talking about. The initial version of WebM released by Google when WebM was first announced circa May 2010 is still being optimised in an ongoing process.

It will make a big difference to the quality of the results obtained depending if one is using the "Aylesbury" release or not.

From the same blog article linked above, Google also mentions the upcoming "Bali" release, which is due in Q1 2011.

It would appear that the Bali release is intended to have an impact on encoding speed.


Please, get over yourself already!

When sugardaddy hadn't bought VP8 for his young and Theora was still all the rage, you were advocating that soon-soon-any-day-now, the newest bleeding edge Theora release (ptlasagasdiogasdg or whatever it was called) was going to blow everything away.

Fast-forward into today and now we all should still wait for some bleeding edge developers release of VP8 so that we could see for ourselves that it's the best thing since sliced bread (and free(tm), unlike sliced bread).

And comparing this to a industry-agree-upon standard having several implementations and relatively wide usage...It seems like the ONLY thing that matters is that VP8 is royalty-free (pending possible submarine patent royalties). Gotten used to getting things for free?
"

You might be surprised to find that "free" (as in zero cost) is nowhere near as important as "unencumbered" (as in anyone may implement it without restriction). Freedom, not zero cost.

WebM is freedom like Theora, but it is also quite a bit better in performance. It might have been possible with effort and persistence to squeeze acceptable performance out of Theora, but WebM is there already.

I agree with Eugenia that none of these external encoders matter. The only things that matter are the plugins for widely-used video editing software such as Premiere or Final Cut Pro. These external tools can only be sufficient for small-scale usage.


I disagree. Software such as Premiere or Final Cut Pro is rip-off, pure and simple. It is pay-through-the-nose "branding", like Gucci or Ferrari, as opposed to super-value-for-money, like encoding to WebM using a command line program in conjunction with a simple GUI frontend or a couple of convenience scripts.

I tell you what ... you and I both go into business converting raw video working files to final output files sourced by someone else ... you can use a hyper-expensive $3 grand "brand" royalties paid product with a flash GUI like Final Cut Pro, and I will use a command line and a couple of handmade scripts. We will each charge the same money per file to our clients.

Lets see who makes the most money.

Edited 2011-01-18 09:51 UTC

Reply Score: 3

RE[3]: Encode quality and speed
by manjabes on Tue 18th Jan 2011 10:47 UTC in reply to "RE[2]: Encode quality and speed"
manjabes Member since:
2005-08-27

I disagree. Software such as Premiere or Final Cut Pro is rip-off, pure and simple. It is pay-through-the-nose "branding", like Gucci or Ferrari, as opposed to super-value-for-money, like encoding to WebM using a command line program in conjunction with a simple GUI frontend or a couple of convenience scripts.


Why is it then that virtually nobodys workflow consists of Kdenlive+multiple command-line encoders, whereas them Premiere, FCP et al. have so many users that they run a business catering to them?

Reply Score: 1

RE[4]: Encode quality and speed
by lemur2 on Tue 18th Jan 2011 11:07 UTC in reply to "RE[3]: Encode quality and speed"
lemur2 Member since:
2007-02-17

"I disagree. Software such as Premiere or Final Cut Pro is rip-off, pure and simple. It is pay-through-the-nose "branding", like Gucci or Ferrari, as opposed to super-value-for-money, like encoding to WebM using a command line program in conjunction with a simple GUI frontend or a couple of convenience scripts.


Why is it then that virtually nobodys workflow consists of Kdenlive+multiple command-line encoders, whereas them Premiere, FCP et al. have so many users that they run a business catering to them?
"

Same reason why Gucci make bucketloads of money ...

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

... selling cured animal skins.

Reply Score: 3

RE[4]: Encode quality and speed
by ichi on Tue 18th Jan 2011 11:08 UTC in reply to "RE[3]: Encode quality and speed"
ichi Member since:
2007-03-06

They are each talking about different things: NLE vs batch encoding/transcoding.

If you are editing video then obviously out of convenience you will use some format out of the list of supported output formats in FCP.

On the other hand, as soon as you upload your video to vimeo, youtube or whatever it'll be transcoded, so the point is the huge majority of videos being streamed don't retain the encoding format from the NLE as they have been transcoded later.
Whether you use h264 or WebM on FCP is hence largely irrelevant when it comes to web video.

Reply Score: 3

Up-to-the-minute comparison
by lemur2 on Mon 17th Jan 2011 23:24 UTC
lemur2
Member since:
2007-02-17

FTA:

"To be fair, WebM does have several significant disadvantages compared to H.264, including slower encoding times, higher CPU decode requirements, and limited browser and device support."


Hmmm, that comparison doesn't sound quite fair. It sounds a bit outdated.

Firstly, webM has significantly lower CPU decode requirements than H.264 CPU decode requirements, unless H.264 is hardware-accelerated. In the absence of hardware acceleration, WebM decode is significantly less demanding of CPU grunt that H.264 for the same video resolution, quality and frame rate.

As for browser support ... H.264 is well supported only via Flash. Flash doesn't work on iDevices. It would be fair to say that even H.264 doesn't have wide "browser and device support" together ... one or the other, perhaps, but not both.

Finally, WebM decoding for devices is just becoming available now.
http://blog.webmproject.org/2011/01/availability-of-webm-vp8-video-...

http://blog.webmproject.org/2010/12/chips-delivers-vp8-hd-video-har...

http://www.shenit.com/blog/2011/01/08/remarkable-android-internet-t...

For people buying a new Android device later this year (even an Android 3.0 tablet perhaps), none of the "disadvantages" of WebM mentioned in the original article are likely to be a concern any longer.

Reply Score: 5

Command line.
by _xmv on Tue 18th Jan 2011 00:48 UTC
_xmv
Member since:
2008-12-09

summary:

use the command line encoder, others are ugly-expensive for nearly as good as command line result, or just plain suck

Reply Score: 4

RE: Command line.
by lemur2 on Tue 18th Jan 2011 01:01 UTC in reply to "Command line."
lemur2 Member since:
2007-02-17

summary: use the command line encoder, others are ugly-expensive for nearly as good as command line result, or just plain suck


Opportunity: write a quick GUI frontend, say using Qtqucik/Qtcreator and perhaps Python, to call the command line encoder. Perhaps offer optimal default parameters depending on the source file selected, and/or offer a selection of pre-sets as "templates", as defined under the heading "Sample Command Lines" here:

http://www.webmproject.org/tools/encoder-parameters/

2-Pass Best Quality VBR Encoding
2-Pass Faster VBR Encoding
2-Pass VBR Encoding for Smooth Playback on Low-end Hardware
2-Pass CBR Encoding for Limited-bandwidth Streaming
2-Pass VBR Encoding for Noisy / Low-quality Input Source
1-Pass Good Quality VBR Encoding
1-Pass Fast VBR Encoding

With such a frontend in conjunction with the command line backend, one could probably come up with a product that was better than the commercial offerings for which hundreds of dollars are being charged.

Reply Score: 2

RE[2]: Command line.
by _xmv on Tue 18th Jan 2011 12:47 UTC in reply to "RE: Command line."
_xmv Member since:
2008-12-09

Opportunity: write a quick GUI frontend


that's the problem with guys like me - i like the command line, its fast concise and just works.
so i'd code a GUI for others and have no use for it - no motivation and therefore not happening

That's probably why GUIs for command line stuff are usually not very well done and/or don't exist.

Even on Windows without cygwin etc, PowerShell is pretty neat for a shell now.

I'm sure however that SUPER(R) and such "GUIs for command line" will pick it up quickly.

ps: OSNews quote-in-quote doesnt display properly. I had to cut the inner quote.

Edited 2011-01-18 12:48 UTC

Reply Score: 2

ffmpeg
by stabbyjones on Tue 18th Jan 2011 03:18 UTC
stabbyjones
Member since:
2008-04-15

It says on the project site that there's support for webm in ffmpeg >=0.6. Why would you even read about pay programs when you type a single line in the command line?

"One cool feature allows you to click a button (hidden by the preset drop-down list in Figure 1) to see the FFMPEG command-line argument used for the encode and the real-time log file."

Play around with the commands borrow from other encoders and find something that looks good to you and then you don't have to pay $800 to encode video.

Reply Score: 8

RE: ffmpeg
by lemur2 on Tue 18th Jan 2011 03:56 UTC in reply to "ffmpeg"
lemur2 Member since:
2007-02-17

It says on the project site that there's support for webm in ffmpeg >=0.6. Why would you even read about pay programs when you type a single line in the command line? "One cool feature allows you to click a button (hidden by the preset drop-down list in Figure 1) to see the FFMPEG command-line argument used for the encode and the real-time log file." Play around with the commands borrow from other encoders and find something that looks good to you and then you don't have to pay $800 to encode video.


Indeed. If one had a need, one could easily take the examples from this page:
http://www.webmproject.org/tools/encoder-parameters/

replace a few of the constants and filenames found there with $n parameters, and create a set of bash scripts or even aliases so that one did not have to remember the laborious details.

A few minutes copying a command into an editor, modifying it slightly, and saving it to a personal script file or as an alias in .bashrc, and one has saved oneself $800 (and probably ended up with a more flexible solution tailored to one's specific needs as well).

Reply Score: 3

RE: ffmpeg
by _QJ_ on Tue 18th Jan 2011 09:08 UTC in reply to "ffmpeg"
_QJ_ Member since:
2009-03-12

Yes, I totally agree.

And for common people who don't have too high expectations on their videos unlike some professionals may have:

Support of VP8 with tools like http://avidemux.berlios.de/news.html is coming. In example the release note of version 2.5.4 says:
* Added support for compressed headers, MPEG-2 audio and VP8 video in MKV container
* Added support for VP8 video decoding

GPL tools like Avidemux have the feature to save pre-sets.

So yes, needless to spend a lot of money to meet expectations of "average Joe" (You know, the vast majority of end users...).

... Just use your brain ! :-)

Reply Score: 2

RE[2]: ffmpeg
by vodoomoth on Tue 18th Jan 2011 12:46 UTC in reply to "RE: ffmpeg"
vodoomoth Member since:
2010-03-30

Maybe that the real thing is that the average Joe doesn't know much about command line. What is needed here is a simple GUI frontend.

Reply Score: 2