Linked by Thom Holwerda on Mon 17th Jan 2011 21:29 UTC

Thread beginning with comment 458807
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: Encode quality and speed
by Neolander on Tue 18th Jan 2011 08:05
in reply to "RE: Encode quality and speed"
RE[3]: Encode quality and speed
by manjabes on Tue 18th Jan 2011 10:45
in reply to "RE[2]: Encode quality and speed"
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.
RE[2]: Encode quality and speed
by anda_skoa on Tue 18th Jan 2011 08:07
in reply to "RE: Encode quality and speed"
RE[2]: Encode quality and speed
by lemur2 on Tue 18th Jan 2011 09:44
in reply to "RE: Encode quality and speed"
"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.
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
RE[3]: Encode quality and speed
by manjabes on Tue 18th Jan 2011 10:47
in reply to "RE[2]: Encode quality and speed"
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?
Member since:
2005-08-27
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?
</offtopic>
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.
Edited 2011-01-18 06:57 UTC