VC-1 and H264

[zambelli]

Disney use H264 solution from CinemaCraft because it is easy and quick to use it.
The speed encoding of this solution is fast (much faster than PEP/CineVision PSE:
@ Sagitaire, CC-HDe use all processor core not like PEP).
You do know that most pro places are running PEP (PSE) on 16- and 32-blade servers, and not on a single machine, right?

[Golgot13]

You do know that most pro places are running PEP (PSE) on 16- and 32-blade servers, and not on a single machine, right?

Yes, you're right. PEP is the best VC1 tool and most companies use it because they received for free.
PEP can use network encoding process, disadvantage for CC-HDe (use by Disney).

But CC-HDe need only 2 or 3 time viideo process (1hour of video need no more than 3hours).
And about network encoding process, Sony BAE-VA700 H.264/AVC Encoder can do it:
http://www.sonycreativesoftware.com/products/bluprint.asp?page=otherencoders
Some US house studios, which work with you (MS), will receive soon Sony AVC encoder.

[Sagittaire]

You do know that most pro places are running PEP (PSE) on 16- and 32-blade servers, and not on a single machine, right?

Well I think that for encoding at 1080p and 30 Mbps with H264 for BD, simple core 2 Q at 3.0 Ghz can make real time encoding. Use best search setting (insane RDO, insane ME) is useless in this case. Moreover massive paralleling encoding is not a really good way to obtain an optimal rate control quality.

[Sharktooth]

Yes that seems to be real grain from the kodak print indeed but its very faint compared to other transfers another screen please :D can't wait for the Blu-Ray :P that face how many details
how does this (http://www.webalice.it/f.corriga/temp/grain/index.htm) look to you?

[cannuck]

Probably not for this forum, but feel free to propose a better format for maintaining full backwards compatibility with a couple decades of .doc files within XML

I brought up M$'s ethics; because, it seems that folks in this forum are very, very, very supportive of Open Source software (and maybe Linux OS as well). And would be very very upset if Open Source software was killed off and/or Linux was killed off!

And if one spends some time reading the various articles on Groklaw about M$ and Open Source software - one can get a good picture of what M$ is doing. Today's entry is a good one about M$ and XML.

Official objections regarding the way matters were handled in Switzerland at the recent vote over whether or not to approve MS-OOXML as an ISO standard have just been filed [PDF] by Free Software Foundation Europe. FSFE is asking that the outcome be declared invalid, and if not, it threatens legal action. There is also now an official appeal by the Swiss Internet User Group (SIUG).

http://www.groklaw.net/

[benwaggoner]

I brought up M$'s ethics; because, it seems that folks in this forum are very, very, very supportive of Open Source software (and maybe Linux OS as well). And would be very very upset if Open Source software was killed off and/or Linux was killed off!
In the context of this forum, we'd welcome your efforts on an open-source implementatio of VC-1 playback or encoding.

It's not a codec we control in any meaningful way - licensing is handled by MPEG-LA like MPEG-2 and H.264, and the standard is controlled by SMPTE.

If you think open source is a better way to develop video codecs, go for it!

[cannuck]

In the context of this forum,

I am sure that part of the context of this forum (and any other forum) is a concerned about the ethics of any corporation involved with products that in some way touch the forum.

Groklaw brings up, on a regular basis, serious question abouts M$'s behaviour; with people alleging that M$'s behaviour amounts to a orchestrated effort to weaken and/or to wipe M$'s Open Source competitors (all Open Source?) off the planet.

[benwaggoner]

I am sure that part of the context of this forum (and any other forum) is a concerned about the ethics of any corporation involved with products that in some way touch the forum.

Groklaw brings up, on a regular basis, serious question abouts M$'s behaviour; with people alleging that M$'s behaviour amounts to a orchestrated effort to weaken and/or to wipe M$'s Open Source competitors (all Open Source?) off the planet.
Well, how about you call my bluff and contribute to or support an open-source VC-1 implementation :). That'd sure show us!

Really, VC-1 is a technology we created, but don't control. You don't hear Google complaining about having to use AJAX, do you?

[virus]

It's not a codec we control in any meaningful way - licensing is handled by MPEG-LA like MPEG-2 and H.264, and the standard is controlled by SMPTE.

And the related patents are owned by...? the Tooth Fairy?

If you think open source is a better way to develop video codecs, go for it!

LOL.

So you're saying that FOSS developers should support VC-1, a format where Microsoft has an huge competitive advantage over the rest of the industry (you had the codec ready - or almost ready - before even submitting the standard, so the rest of the competiton had still to start from scratch while you were ready to market) and thus help Microsoft make more and more money (by bolstering a market segment where they're already leaders)?

Money which your executives will in turn spend to fund horrors like SCO or Mindcraft or that Alexis de Tocqueville Institution, or putting up some "Get The Facts" FUD campaign, or even that ridiculous "Linux breaks 235 of our patents, but we won't tell you which ones" crap?

Man, you must be kidding. FOSS developers should cooperate with a company which aims at hurting FOSS in every possible way, up to and including straight lies? Let me LOL.
Maybe you really believed at your CEO's keynotes about "Microsoft's vision for interoperability" like if it was actually true, but I guess FOSS people are smarter than that, and won't buy it.

Let's leave VC-1 at those who are content to hear the "we have no intentions to sue, for now" mantra, and maybe support ISO standards developed by a large group of companies of various size, and thus where competition (real competition, I mean) existed from day one.

[Sharktooth]

M$ is looking for someone wich produces an OS VC-1 encoder for free so companies can develop VC-1 encoders easily. In other words they're trying to take advantage of the OSS community to earn more money thru patents.
I dont think it will happen though... ;)

[CruNcher]

@all
some updates on my grain preservation testing im @ qp 24 now and still grain is their in H.264 (Main Profile) :) (Blu-Ray Mpeg-2 as source) gonna post screens as soon as i found the end seems near the 30 grain preservation isn't possible anymore (test ongoing, changed some standard X.264 RC settings also, later more :) ) my target is DVD5 (but i doub't i gonna reach that seeing the current results hmmm (no resize no nothing yet, even no cropping plain input, so still some bits to save somewhere if necessary also high profile still available as option ;) ), not without post processing tough, but hey im since the beginning a low bitrate encoder so let's try to reach it somehow ;) ).
I hope VC-1 can do even better @ ben and zambelli some settings for maximum grain preservation from a (Max: 27 mbit AVG: 20 mbit) source for the consumer encoder would be fine, thx :D

PS: Processing speed @ the moment is roughly @ 5 fps (1080p) on my 2.4 Ghz Singlecore system now :)

[Sagittaire]

@all
some updates on my grain preservation testing im @ qp 24 now and still grain is their in H.264 (Main Profile) :) (Blu-Ray Mpeg-2 as source) gonna post screens as soon as i found the end seems near the 30 grain preservation isn't possible anymore.
I hope VC-1 can do even better @ ben and zambelli some settings for maximum grain preservation from a (Max: 27 mbit AVG: 20 mbit) source for the consumer encoder would be fine, thx :D

Try with Elecard/Mainconcept implementation ... you have a very good optimisation for grain preservation. If you want grain preservation with x264 you must use particular profil and use particular filtering (fine grain filtering, dark noise filtering).

@REM >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
@REM >> HDDVD 1080p
@REM >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

x264.exe --threads 1 --thread-input --keyint 14 --min-keyint 2 --vbv-maxrate 21000 --vbv-init 1.0 --vbv-bufsize 14745 --mvrange 511 --level 4.1 --bframe 1 --bime --weightb --ref 1 --mixed-refs --direct auto --deblock -2:-2 --bitrate 8500 --pass 1 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.10 --partitions "all" --8x8dct --me "hex" --subme 5 --aud --nal-hrd --pulldown 32 --sar 1:1 --cqmfile Sagittaire.cfg --deadzone-intra 6 --deadzone-inter 6 --aq-strength 0.25 --aq-sensitivity 5 --progress -o 1080p_1.264 xxx.avs

x264.exe --threads 1 --thread-input --keyint 14 --min-keyint 2 --vbv-maxrate 21000 --vbv-init 1.0 --vbv-bufsize 14745 --mvrange 511 --level 4.1 --bframe 1 --bime --weightb --ref 3 --mixed-refs --direct auto --deblock -2:-2 --bitrate 8500 --pass 3 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.10 --partitions "all" --8x8dct --me "hex" --subme 6 --no-fast-pskip --no-dct-decimate --trellis 0 --aud --nal-hrd --pulldown 32 --sar 1:1 --cqmfile Sagittaire.cfg --deadzone-intra 6 --deadzone-inter 6 --aq-strength 0.25 --aq-sensitivity 5 --progress -o 1080p_2.264 xxx.avs

x264.exe --threads 1 --thread-input --keyint 14 --min-keyint 2 --vbv-maxrate 21000 --vbv-init 1.0 --vbv-bufsize 14745 --mvrange 511 --level 4.1 --bframe 1 --bime --weightb --ref 3 --mixed-refs --direct auto --deblock -2:-2 --bitrate 8500 --pass 3 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.10 --partitions "all" --8x8dct --me "umh" --subme 7 --no-fast-pskip --no-dct-decimate --trellis 0 --aud --nal-hrd --pulldown 32 --sar 1:1 --cqmfile Sagittaire.cfg --deadzone-intra 6 --deadzone-inter 6 --aq-strength 0.25 --aq-sensitivity 5 --progress -o 1080p_3.264 xxx.avs

[CruNcher]

@Sagittaire
this is for now unconstrained gonna post HD-DVD results in the HD-DVD thread tough ;) i now hit the 8 mbit mark PQ is still clear but slowly motion coused interferences are visible (grain is still preserved enough) :)

[Inventive Software]

Regarding the tit-for-tat discussion about MS' so-called "tactics" with releasing WMV9 then submitting a standard that then subsequently got accepted by both the MPEG-LA and SMPTE (I LOL BTW at the idea that MS would wait for an FOSS implementation so that they could make more money from the people who generate deviants from it, because the FOSS codec is crappier than MS' codec), just bear in mind that it's a new standard, still being fully understood, and that MS may have the best codec implementation for now, but give it time and libavcodec will have a better decoder for ya. For free. ;)

Their H.264 decoder is a good example, piss-poor in the early stages, as you'd expect with a theoretical piece of code, but once it garnered attention, it gained speed (and quality) like a freight train and is one of the best implementations of an H.264 decoder, only really lacking multi-threading. Only took, what, 3 years? ;)

[virus]

just bear in mind that it's a new standard, still being fully understood, and that MS may have the best codec implementation for now, but give it time and libavcodec will have a better decoder for ya. For free. ;)

And your point is?
I'm getting a hard time figuring out what a decoder in libavcodec has to do with a call to develop a FOSS encoder. And the fact that it'd be free, what does it have to do with concern about patent-related litigations as well as the nonsense of supporting one's own worst enemy? By the way, the price tag for having such code (a VC-1 encoder) in a free system might be much higher than "free" for those who distribute it.

You just seem to pile up arguments unrelated to the point.

[Sagittaire]

@Sagittaire
this is for now unconstrained gonna post HD-DVD results in the HD-DVD thread tough ;) i now hit the 8 mbit mark PQ is still clear but slowly motion coused interferences are visible (grain is still preserved enough) :)

dont change anything for search setting:

x264.exe --threads 1 --thread-input --bframe 1 --bime --weightb --ref 5 --mixed-refs --direct auto --deblock -2:-2 --bitrate 8500 --pass 3 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.10 --partitions "all" --8x8dct --me "hex" --subme 6 --no-fast-pskip --no-dct-decimate --trellis 0 --cqmfile Sagittaire.cfg --deadzone-intra 6 --deadzone-inter 6 --aq-strength 0.25 --aq-sensitivity 5 --progress -o yyy.264 xxx.avs

Use CQM
Don't use brdo
Use lower deadzone
Use lower inloop strength
Don't use trellis

And use filtering in dark zone and for really fine grain. Anyway Mainconcept/Elecard with grain optimisation will be always better than x264 (with all possible optimized setting) for grain preservation.

[CruNcher]

yeah but it won't help anyways my target was 3 mbit :P but without post processing it's undoable even with the highest compression factor that takes 12x the runtime to encode (but even if it would give good results it would be still unaceptable as it would be totaly out of balance then) it won't work out :P
So with up to 6 mbit with 3x the runtime for encoding, i could preserve the grain without useing rdo settings, but very low settings actually still Main Profile, everything under that is dreaming (with allready lossy compressed grainy source as base) ;), now that will be the mark for VC-1 to conquer 1080p 6 Mbit + grain preservation for 3h runtime, my target is also not 3 passes but 1 ;)

[Sagittaire]

yeah but it won't help anyways my target was 3 mbit :P but without post processing it's undoable even with the highest compression factor that takes 12x the runtime to encode it won't work out :P but impressive up to 6 mbit with 3x the runtime for encoding, i could preserve the grain without really useing rdo settings but very low settings actually still Main Profile, everything under that is dreaming (with compressed grainy source as base) ;), now that will be the mark for VC-1 to conquer 1080p 6 Mbit + grain preservation for 3h runtime, my target is also not 3 passes but 1 ;)

1) Grain is a killer for entropy and for bitrate. You can't preserve grain with very low bitrate (high quantizer). RDO is not really usefull for grain preservation.

2) Replace simply --bitrate 8500 --pass 3 by crf mode if you want 1 pass ... lol

3) VC1 and XviD produce similar result for grain preservation. Try with XviD at your bitrate level. VC1 can't preserve grain in general case at 6 Mbps for 1080p encoding.

In fact grain/noise is very difficult for all the codec and the structural advantage for H264 can't really help in this case. If you want preserve grain at very low bitrate the only way is H264 implementation with FGM.

[CruNcher]

ehh the complete grain doesn't need to be preserved @ all only a small amount is enough to belive it is grain (don't forget we doing lossy stuff here) and it's not added @ the decoding level but some leftofs of the original lossy Film Grain Layer so it looks more natural to the viewer (motion and apearance) (im a full HVS guy with lossy codecs and very low bitrate achivements i make trades there, else i would encode lossless but as you maybe allready heared 1000 times from me those tradeoffs have to be balanced based on multiple factors :P and 1 of them is definetly the encoding time for me, even if for most people it isn't)

here a compare screen of the 6 Mbit result (i frame) (@ 8.5 mbit it should be preserved almost transparently) (compression factor 3x) (but don't forget my target was 3 mbit) ;)
i took a scene where you can see splotches and problems from the transfer itself, also those are preserved (the Layer above the Film Grain Layer and as i said a small amount of the original lossy Film Grain Layer under it)

http://s2.directupload.net/images/070819/U546J34C.png

VC-1 has to top this result

as you can see the Film Grain Layer is still pretty good preserved (not fully intact tough, in motion it looks pretty good)


In fact grain/noise is very difficult for all the codec and the structural advantage for H264 can't really help in this case. If you want preserve grain at very low bitrate the only way is H264 implementation with FGM.
Also this takes some time at least Atemes version needs more encoding time (denoise and then renoise) for 1080p it takes long and would hurt the balance again badly, but sure @ the moment the most efficient, but i doesn't search for the most efficient but most balanced way :P, and i know what im doing Sagittaire i asked for VC-1 settings not H.264 ;)

[Sharktooth]

what's the quantizer value of the encoded frame?

[CruNcher]

it's 28 higher is problematic as then the grain gets destroyed even HVS wise for the motion and 12x encoding is a no go for me (It doesn't help that much anyways) :P
for the 3 mbit DVD5 target i know i will endup @ 1440x1080p or even 720p for sure allready

[Sagittaire]

it's 28 higher is problematic as then the grain gets destroyed even HVS wise for the motion and 12x encoding is a no go for me (It doesn't help that much anyways) :P
for the 3 mbit DVD5 target i know i will endup @ 1440x1080p or even 720p for sure allready

Well I can certainely produce really better result with H264. You have a small sample (30 sec)? The most important for noisy source is not the codec itself but certainely more the pre-process. Moreover x264 is not the best implementation for grain preservation. If you want grain preservation with high speed Mainconcept/Elecard implementation is definitively a better way. VC1 use for exemple internal pre-process filter (dark noise filter, denoising) for better grain preservation.

[CruNcher]

btw be carefull with deadzones in x264 it can destroy (deconverts) the Motion blur of the Film camera (oversharping) ass seen above or on the other side blur your results --deadzone-intra 6 blurs to much (less filesize sure but suboptimal with the standard flat matrix) :( we need an adaptive deadzones like VC-1 has it great advantage HVS wise for High Motion to blur everything out *g* (extreme example) (only very fast action scenes) and to save bits for (longer more important) low motion scenes (notes that for his ongoing (HVS) HD encoder tweaking) :) another not so extreme option adaptive it on the qp range ofcourse :P, both for sure could also be done segmentatialy in our world called "zones" (actually alot of new stuff to test and balance out for x264) :)

[akupenguin]

btw be carefull with deadzones in x264 it can destroy (deconverts) the Motion blur of the Film camera (oversharping) ass seen above or on the other side blur your results --deadzone-intra 6 blurs to much (less filesize sure but suboptimal with the standard flat matrix)
Compared to what? --deadzone-intra 6 is higher bitrate and less blurry per qp than the default 11.

[CruNcher]

Compared to what? --deadzone-intra 6 is higher bitrate and less blurry per qp than the default 11.

Yep sorry blur was wrong strange might be that i was in the wrong position to the LCD when looking @ it :d but clearly it can be seen that --deadzone-intra 0 allready oversharpens or might this be QPEL ?

cmdline = x264 --qp 28 --qpmin 28 --qpmax 28 --ipratio 1 --pbratio 1 --min-keyint 1 --keyint 1 --no-fast-pskip --no-dct-decimate --bframes 0 --no-deblock --subme 2 --me dia --partitions "i4x4" --deadzone-intra x <- btw try this without --no-deblock ;) funny thing CoreAVC plays this back without problems most of the other decoder show strange blocks and luma changes in the black area with inloop on :P

Source
http://s3.directupload.net/images/070820/MUek8U5p.png

--deadzone-intra 0
http://s1.directupload.net/images/070820/tPc67O7n.png

--deadzone-intra 1
http://s2.directupload.net/images/070820/PkQCxbF2.png

--deadzone-intra 2
http://s1.directupload.net/images/070820/9OU7y7CH.png

--deadzone-intra 3
http://s1.directupload.net/images/070820/ATuUWzzk.png

--deadzone-intra 4
http://s3.directupload.net/images/070820/pf4wE4XA.png

--deadzone-intra 5
http://s2.directupload.net/images/070820/y4lg9dPV.png

--deadzone-intra 6
http://s2.directupload.net/images/070820/sM62rjj9.png

--deadzone-intra 11
http://s1.directupload.net/images/070820/k59J4JSn.png

[Sharktooth]

the pic encoded with deadzone-intra 0 looks best to my eyes even if the bitrate is clearly too low
however there are artifacts on the source too... so it's definatly a bad source :)

[zambelli]

And the related patents are owned by...? the Tooth Fairy?
Check your facts before you go accusing others of FUD. There are 16 companies in the VC-1 patent pool which covers 125 different patents. 2 of these are owned by Microsoft.

On the flipside, Microsoft also owns patents in H.264: http://www.mpegla.com/news/n_03-11-17_avc.html

Maybe you should read this article by The Register (http://www.theregister.co.uk/2007/04/14/microsoft_vc-1_codec_analysis/) to gain a better understanding of how much exactly Microsoft is expected to "profit" from VC-1 patents and licensing. Note that the article isn't particularly favorable towards VC-1 either.

"The license may in fact only be a license by which Microsoft can pay everyone else fees. There are no less than 16 separate companies that are deemed to have patents that are essential for VC-1 to work, the latest addition to the 15 company list that was first issued last August, being Korean number three handset maker, Pantech Curitel.

Between them they speak for 125 separate patents that are listed in the license, and a total of two of these are allocated to Microsoft. Every other supplier of essential technology including Daewoo, France Telecom, société anonyme (which presumably includes patents from close associates of France Telecom also) Fujitsu, Philips, LG, Matsushita, Mitsubishi, NTT Pantech Curitel, Samsung, Sharp, Sony, Telenor, Toshiba JVC, have more patents at stake that Microsoft (except for two of the above) and many of them have many more."

So you're saying that FOSS developers should support VC-1, a format where Microsoft has an huge competitive advantage over the rest of the industry (you had the codec ready - or almost ready - before even submitting the standard, so the rest of the competiton had still to start from scratch while you were ready to market) and thus help Microsoft make more and more money (by bolstering a market segment where they're already leaders)?
If Microsoft had kept WMV9 proprietary and never opened it up for standardization, would that have made you happier? I sincerely doubt it. Microsoft took a huge financial hit by standardizing WMV9, from letting other companies claim patents in its codec, to making its own released codec subject to a 3rd party's licensing demands. That doesn't exactly sound like a "huge competetive advantage".

Let's leave VC-1 at those who are content to hear the "we have no intentions to sue, for now" mantra, and maybe support ISO standards developed by a large group of companies of various size, and thus where competition (real competition, I mean) existed from day one.
I think your view of the world is a bit naive. Do you think those companies in the ISO and ITU standardization committees are there for fun? Software is a business. ALL those companies are looking to make money. So if you think you're "sticking it to The Man" by boycotting VC-1 or Microsoft, I would like to thank you for your continued support of H.264 on behalf of Fujitsu, LG, Matsushita, Mitsubishi, Motorola, Nokia, Philips, Samsung, Sony, Toshiba, JVC - and last but certainly not least, Microsoft. I'm sure the proceeds of H.264 licensing are all going towards finding a cure for AIDS and building shelters for puppies.

[CruNcher]

@Sharktooth
then look @ this same settings --deadzone-intra 0 difference is just prestige matrix and qp 34

http://s1.directupload.net/images/070820/smimDD4A.png

is it my lcd position again or do you also see a chroma difference
here ?

Sharktooth EQM AVC-HR qp 32
http://s1.directupload.net/images/070820/C23ywXvT.png

hmm the prestige seems to suck up green right ?

Maximum SSIM
Prestige Matrix = 0.9999871
Flat Matrix = 0.9999856
EQM AVC-HR = 0.9992338

[Sharktooth]

There's indeed a chroma difference in some areas.
ill try to improve EQM AVC-HR coz it looks better and less blocky to my eyes even if the SSIM is lower.

[virus]

Check your facts before you go accusing others of FUD. There are 16 companies in the VC-1 patent pool which covers 125 different patents. 2 of these are owned by Microsoft.

Been there, done that. All of that has been known for ages. The point is that Microsoft owns patents in VC-1, not that it owns them all. That's enough to trigger litigation based on those patents.


On the flipside, Microsoft also owns patents in H.264

Indeed, and that's already a risk for FOSS-based systems. And one of the main reasons for not adding further risk to an already risky situation. Especially since VC-1 is not a breakthrough advancement over H.264 by any means.



Maybe you should read

Been there, done that. I've read that well before you gracefully pointed me to it, thanks for your assistance.



If Microsoft had kept WMV9 proprietary and never opened it up for standardization, would that have made you happier? I sincerely doubt it.


Nobody is taking issue with opening up the standard here.
Again, you're making points unrelated to the issues.



Microsoft took a huge financial hit by standardizing WMV9, from letting other companies claim patents in its codec, to making its own released codec subject to a 3rd party's licensing demands.


"Its" codec? You mean Microsoft's codec?
You've just pointed me to articles to show that Microsoft owns just a fraction of the technology they've always claimed as their own... what "hit" are you talking about? Unless by "hit" you mean "dividing the license fees with those who own the technology".

In other words: doing it the right way is a financial hit? So you're saying Microsoft should have kept it secret and keep the other owners' money for themselves? That's a curious stance to say the least.



That doesn't exactly sound like a "huge competetive advantage".


However, my point about the competitive advantage was about the number of existing implementations, as well as the process of development of the standard itself. The difference between MPEG standards and VC-1 in both those areas is staggering, expecially in the latter.



Software is a business. ALL those companies are looking to make money.


Agreed, the world is a bitch, isn't it?

However, I'd like to point out one of the main differences between Microsoft and other patent holders, including the likes of IBM, Motorola, Nokia, Philips and other giants which are "there for the money" exactly as Microsoft. And that difference has to do with FOSS, which is what is discussed here (I remember someone calling for a free software implementation of a VC-1 encoder, and that wasn't me).

I've never heard Motorola's executives say something on the likes of "Get your money and let's go to court!" (Craig Mundie, MS executive, during an Open Source convention).
I've never heard IBM's executives describing Linux as a "cancer that attaches itself in an intellectual property sense to everything it touches" (Steve Ballmer, MS executive).
I've also never heard Nokia's executives claim that FOSS violates 235 of their patents and refraining to rule out the possibility to sue even users for royalties (Ballmer & co., that's from 2007)
And I'm not aware of "LG, Matsushita, Mitsubishi, NTT Pantech Curitel, Samsung, Sharp" and the other lithany of patent holders you've pointed out giving funds to SCO (check [url=http://news.com.com/Fact+and+fiction+in+the+Microsoft-SCO+relationship/2100-7344_3-5450515.html]here (http://www.theregister.co.uk/2007/04/14/microsoft_vc-1_codec_analysis/) for a quite honest analysis of what was true and what was not - there's so much material on that). Nor to explicitly design licenses to prevent implementation by FOSS projects, as happened to CIFS and apparently to .NET too.

And I could go on again and again, embarrassing leaked memos, harsh interviews, implied threats, and a lot of straight FUD (some of it mentioned in my previous post). A partial account of some of that is collected here (http://eupat.ffii.org/players/microsoft).

Nice, heh? Microsoft among all patent holders aggressively portraits itself (yeah, no gun pointed to Steve Ballmer's head, apparently) as FOSS' worst danger and my vision of the world would be naive? LOL. Now it's my time to invite you to check the facts.
Let me repeat it straight: FOSS should stay away from everything that smells Microsoft, and may even remotely help them make money (yes, even if it's 2/125 of the total pie, it's still money, and they're all out for the money, no?).
And no, I don't need the companies to spend them for curing AIDS or whatnot, it'd be enough to avoid funding the possibile annihilation of many FOSS projects and related companies.

Some of that crap is already in - mainly for interoperability purposes, and sadly x264 is part of the risk, but heck, as I pointed out, VC-1 and H.264 are *different* and at least in H.264's case, it's perhaps a worthy risk. Or maybe not.
But man, Microsoft really deserves nothing from FOSS developers. No help, no collaboration, no code, nothing. They're the MPAA/RIAA of software: "you own a computer, so you're (ab)using our IP. Pay up or you're stealing money."

[Sharktooth]

we all know what the $ stands for in Micro$oft... that's why i hope an OS VC-1 codec will never be implemented at least until M$ releases the sources under the GPL (and not the stupid M$-PL M$ is trying to push for OSI approval...) of a reference encoder/decoder.
"Sometimes you should get your hands dirty if no one wants to make the dirty job for you" (a revisited version of "users must pay for what they get":p)...

[akupenguin]

it can be seen that --deadzone-intra 0 allready oversharpens or might this be QPEL ?
Quite possible. Deadzone 0 means that coefficients are equally likely to be rounded up or down. If an AC coefficient is rounded up, you get ringing. With default deadzone, coefficients are usually rounded down.

is it my lcd position again or do you also see a chroma difference here ?
There should be a chroma difference. Prestige doesn't modify the chroma matrices, so prestige@qp34 quantizes chroma more than default@qp28.
--chroma-qp-offset -6 to compensate (for appropriate values of 6).

[CruNcher]

Thx for the usefull info aku hmm would it be possible to only use Hpel instead of Qpel with a lower subme then 1 --subme 0 ist still free could you make it the Hpel only mode :)


cmdline = x264 --qp 28 --qpmin 28 --qpmax 28 --ipratio 1 --pbratio 1 --min-keyint 1 --keyint 1 --no-fast-pskip --no-dct-decimate --bframes 0 --no-deblock --subme 2 --me dia --partitions "i4x4" --deadzone-intra x <- btw try this without --no-deblock funny thing CoreAVC plays this back without problems most of the other decoder show strange blocks and luma changes in the black area with inloop on :P


And wich decoders are correct those who show this strange errors (luma changes, blocks) or those who seem to ignore this ?, libavcodec shows the problems btw, and what about makeing x264 commandline a little more error prone to this i have to agree "crazy settings combinations" so such problems (incompatible bitstreams) can't be created at all by the user, i know you don't wan't to make this a 1 click encoder but some error proness i think sometimes should be in and some crazy stuff the user shouldn't be able todo ;)

[akupenguin]

When submitting bug reports, minimize the complexity of the commandline. In this case, your command is equivalent to "x264 --qp 28 --ipratio 1 --keyint 1".

"error prone" is not the term you're looking for. You mean "error resilient" or "idiot proof".

I can't reproduce any flickering the the black mattes of my clips. Please post your source and encoded video.
I do see flickering in the non-black areas of my clips. That's directly caused by intra-only compression. All intra-only codecs suffer from similar problems, though h264 is slightly worse than most (in perceived flicker per psnr, not necessarily per bitrate) due to the directional intra prediction.

[CruNcher]

hmm it's gone could have been also a problem with fffmpegsource that is now fixed (compiler problem) sorry (but it's funny to know that CoreAVC was not affected by this but all the other decoder :P were going crazy.

[cannuck]

I think your view of the world is a bit naive. @zambelli

Speaking of "world view"; when one decides on whether or not to use/buy a brand product from a corporation; the ethics of a corporation comes into play for most people. "Blood Diamonds" is a good example of the latter.

Microsoft has it's fingers in a number of "pies"; likely hundreds of pies. And the VC-1 it just one of Microsoft's pies.

And if ... if one of Microsoft's pies is to destroy, minimize or control the entire (not just a video codec!!) Open Source, Linux, and FOSS "industries" ; then that would cause anyone to wonder whether or not to use/buy any Microsoft product.

Again, judging by the info on the above, posted about Microsoft on Groklaw; one has to wonder.

[Dark Shikari]

@zambelli

Speaking of "world view"; when one decides on whether or not to use/buy a brand product from a corporation; the ethics of a corporation comes into play for most people. "Blood Diamonds" is a good example of the latter.

Microsoft has it's fingers in a number of "pies"; likely hundreds of pies. And the VC-1 it just one of Microsoft's pies.

And if ... if one of Microsoft's pies is to destroy, minimize or control the entire (not just a video codec!!) Open Source, Linux, and FOSS "industries" ; then that would cause anyone to wonder whether or not to use/buy any Microsoft product.

Again, judging by the info on the above, posted about Microsoft on Groklaw; one has to wonder.http://mshiltonj.com/software_wars/current/current.png

I can't find VC-1 on the map though.

[Sharktooth]

uhm... maybe the map it's not up to date or even "incomplete"... :)

[Dark Shikari]

uhm... maybe the map it's not up to date or even "incomplete"... :)I know it was a joke :p

[Sagittaire]

and HDDVD vs BD, VC1 vs H264, XboX vs PS3 ...

[Sharktooth]

Sincerely, i prefer both HD-DVD and Xbox360 over BD and PS3 but yes, it's another battlefield... :)

[crypto]

and Silverlight vs. Flash...

BTW. Flash 9 will have H.264.

Which brings us back on track: VC-1 vs H.264

[Sharktooth]

SilverCrap(tm) doesnt work on Opera too...

[cannuck]

BTW. Flash 9 will have H.264.

Will?? Flash Does Have H.264!! :)


http://labs.adobe.com/technologies/flashplayer9/

[CruNcher]

Sincerely, i prefer both HD-DVD and Xbox360 over BD and PS3 but yes, it's another battlefield... :)

You really seem to underestimate this, it means for the future who will controll our livingrooms and you can decide now by buying either Sony - Asia / Microsoft - America it's war and you can chose your prefered side you wan't to colaborate with ;)

[cannuck]

who will control

Well that's the 64,000 Question.

Tokyo has 7,000,0000 cell phone users now watching TV on their cell phones (7,000,000 signed up in one year?).

Digital TV stations can now broadcast direct to cell phones (no cell service provider required).

And iTunes has proven that a Disc is redundant when it comes to music.

Plus IBM got a CPU cooking at 500 GHZ and say will be 1000 GHZ soon.

So what's next! "Dinosaurs" will be extinct soon. ;)

[cannuck]

The 7,000,000 in Tokyo might be 700,000 (I'll check)

The Digtal TV station direct to cell phone uses H.264/AAC/DMB ! ;)

[zambelli]

Been there, done that. All of that has been known for ages. The point is that Microsoft owns patents in VC-1, not that it owns them all. That's enough to trigger litigation based on those patents.
Your comment certainly didn't sound like you knew that. Ben pointed out that VC-1 is in the same licensing boat as MPEG-2 and MPEG-4, which you then apparently dismissed and redirected attention to patent ownership. Why? There's no difference there either, as the article shows, so why mention it?
Indeed, and that's already a risk for FOSS-based systems. And one of the main reasons for not adding further risk to an already risky situation. Especially since VC-1 is not a breakthrough advancement over H.264 by any means.
Pretty much every FOSS codec implementation puts FOSS into a risky situation, so why draw the line at VC-1? If you really drew a line at every technology ever touched by Microsoft, you wouldn't get very far in computing.

Nobody is taking issue with opening up the standard here. Again, you're making points unrelated to the issues.
I'm making points unrelated to the issues? Your post contains an entire paragraph about Microsoft corporate ethics that's way beyond scope of this thread. Are you having a discussion with me or Steve Ballmer?
In other words: doing it the right way is a financial hit? So you're saying Microsoft should have kept it secret and keep the other owners' money for themselves? That's a curious stance to say the least.
No, I'm precisely saying the opposite: Microsoft did do the right thing by standardizing the codec, and it did it at a financial loss, not profit.
However, my point about the competitive advantage was about the number of existing implementations, as well as the process of development of the standard itself. The difference between MPEG standards and VC-1 in both those areas is staggering, expecially in the latter.
But doesn't standardizing a proprietary codec in fact take away the competetive advantage in the short term?
And I could go on again and again, embarrassing leaked memos, harsh interviews, implied threats, and a lot of straight FUD (some of it mentioned in my previous post). A partial account of some of that is collected here (http://eupat.ffii.org/players/microsoft).
Not everything that's posted on the Internet is necessarily true. For example, that article contains this statement:

"In 2000, Microsoft forced a free sofware project to abandon support for its patented video streaming format ASF." (Clearly a reference to VirtualDub.)

"Forced"? Microsoft hardly forced Avery Lee to drop ASF support. No lawyers were ever involved, no threats were ever made, and it's doubtful that the patent claim was anything more than a rogue action of an individual. If you don't believe me, ask Avery about how exactly that whole thing went down. I'd take with a huge grain of salt any article that's based on hear-say.
Let me repeat it straight: FOSS should stay away from everything that smells Microsoft, and may even remotely help them make money (yes, even if it's 2/125 of the total pie, it's still money, and they're all out for the money, no?).
If that's not a naive, then it's certainly an impractical attitude.
But man, Microsoft really deserves nothing from FOSS developers. No help, no collaboration, no code, nothing. They're the MPAA/RIAA of software: "you own a computer, so you're (ab)using our IP. Pay up or you're stealing money."
You should probably tell that to the millions of FOSS developers who use and prefer the Windows platform, tools and products. I think you're taking a very hardline stance in a world where extreme points of view don't go very far. I personally don't see FOSS and Microsoft as opposing or mutually exclusive forces because I think both can contribute to the quality and depth of a PC ecosystem, and we've certainly seen many examples of that particularly in the video software niche.

[virus]

Why? There's no difference there either, as the article shows, so why mention it?

No futher comments here, I've already explained this very clearly in my previous post.


Pretty much every FOSS codec implementation puts FOSS into a risky situation, so why draw the line at VC-1?


Already explained that extensively, too.


If you really drew a line at every technology ever touched by Microsoft, you wouldn't get very far in computing.


"Touched" is maybe not the right word. Microsoft has "touched" a lot of stuff, including unpatented (and unpatentable) stuff. They've also touched stuff patented by someone else. It's more about stuff that Microsoft owns, which I think it's much less than everything - especially if parts of it get challenged. The actual borders are kinda unknown.

But when in doubt, I guess a "if possible, keep it out unless it gives a great benefit" policy is reasonable. Bundling a VC-1 encoder IMHO doesn't give "great benefit", but enables Microsoft to say "hey, you're infringing upon 237 patents, not 235!". In other words, risky stuff should be kept to a minimum.

Your post contains an entire paragraph about Microsoft corporate ethics that's way beyond scope of this thread.

So, what you don't like to hear is "beyond the scope of the thread".
This really doesn't deserve any further comments...


No, I'm precisely saying the opposite: Microsoft did do the right thing by standardizing the codec, and it did it at a financial loss, not profit.


And I repeat that you don't normally call it a "loss" when you have to return money you don't own. They had no right to keep all the license fees in the first place, so calling "financial loss" the restoration of legality is arguable at least.


But doesn't standardizing a proprietary codec in fact take away the competetive advantage in the short term?


Maybe it will, but I doubt about the short term. The process will likely take longer time with VC-1, since VC-1 almost popped out of nowhere.
Instead, MPEG standards are the fruit of an open development process which lasted years, involving open academic research, open sessions within the group(s) which develop it, freely-available documents describing the rationale behind the implementation and the choices made.
Had VC-1 been developed in a truly open manner from day one, I'd have had no grounds to speak about "competitive advantage from a single vendor".


Not everything that's posted on the Internet is necessarily true.


True, but pointing out an inaccuracy over dozens of allegations (most of which are straight quotes from public speeches and interviews) doesn't make the rest of the "evidence" less true.
There are hundreds of articles pointing out facts, can you confute them all? Are you really trying to writing them all off as "hear-say"?


If that's not a naive, then it's certainly an impractical attitude.


Yeah, it's difficult to refrain from patented code. Especially since the patent system allows to patent extremely trivial stuff. As well as to patent interfaces, which is another hurdle to overcome.
Again: this a general problem that touches all the industry, however it's mainly Microsoft who likes the "you're stealing our IP" mantra, while other companies don't seem to have this attitude.


You should probably tell that to the millions of FOSS developers who use and prefer the Windows platform, tools and products. I think you're taking a very hardline stance in a world where extreme points of view don't go very far.


I cannot decide for other people and dictate them what they must do. This is corporate behaviour, and contrary to the free software ethics.
What I can do is to make my opinion be heard and some facts been pointed out, even if "outside the scope of the thread".

Just a note: if I look around, I see that a lot of FOSS projects, probably the large majority of them (many thousands), aren't developed using Windows tools nor Windows itself.
Maybe they run under Windows, but that's a different thing. It's the very nature of FOSS that lets people make them run under the platform they want. No barriers. And no stupid patents too.

I personally don't see FOSS and Microsoft as opposing or mutually exclusive forces because I think both can contribute to the quality and depth of a PC ecosystem, and we've certainly seen many examples of that particularly in the video software niche.

Beautiful words. Now, if Microsoft's executives would actually believe in them... but sadly that's not the case. Looks like they prefer patent litigation, vendor lock-in, and other disgusting practices.

I'll repeat my stance again: it's Microsoft who chose this route, not the FOSS community. They chose it many years ago, perhaps when they recognized FOSS as something that could have potentially reduced their annual net worth - refueling a 40-meters yacht is costly, we know.
(and that's a very wrong judgement, btw. Some companies are making a ton of money with FOSS in a perfectly legal and ethically coherent way.)

But now Microsoft comes here talking about FOSS and "encouraging" it. Am I the only one who sees this as total nonsense (or self-contradiction)?

[Dark Shikari]

I think his point is that Microsoft is the only major technology company that, out of the blue, tells FOSS that they're violating hundreds of patents, but then refuses to even show which patents they are. To make it worse, after saying that, they complain that FOSS developers are unfair to them.

Even Sony doesn't do that, and they're the epitome of corporate evil in many ways.