Internal Planar YUY2/4:2:2 Format

[Si]

After following the YV12 thread and following Tom's link to here (http://forum.doom9.org/showthread.php?s=&threadid=36942&perpage=20&highlight=yv12%20chroma&pagenumber=10) and reading SansGrips comments

...It's a question of speed of execution/speed of development. YV12 is undeniably faster at runtime, but I find it to be at least twice as much typing, which means twice as many typo bugs. It also means three times the pointers and at least two times the constants, three times the "helper variables" to hold results of calculations etc..

I'd like to ask/suggest/plead for a planar 4:2:2 format in order to reduce the overheads in maintaining/producing separate YUY2 and YV12 filters.

Of course if its a lot of trouble ... but if you don't ask - you don't get ... :D

regards
Simon

[sh0dan]

A planar 4:4:4 would make much more sense. There is nothing much holding it back anymore - except someone has to write the conversion filters. ;)

Besides after writing many filters for YV12, I certianly disagree with Sansgrip. You have to think slightly different, but it is so much easier having the components separate.

[trbarry]

If you follow Marc FD's and my own replies to Sansgrip in that thread and his subsequent coding I think it shows we pretty much convinced him of the benefits of both 4:2:0 and assembler language for video coding. ;)

- Tom

[MfA]

planar 4:4:4 would be nice ... as would be 16 bit integer and 32 bit FP per component spaces for it and RGB.

[Si]

My bid is purely on the basis of maintaining/producing two code paths for every filter.

So a planar YUY2 format is all I seek as I believe it would have a small speed penalty but ease the maintenance. (And it might have a neutral/positive speed difference in some cases where planar processing is much better to do)

regards
Simon

[sh0dan]

Planar 4:4:4 8bpc is much easier, as at least half the filters already support this (if they use PVideoFrame->GetRowSize(PLANAR_U) and PVideoFrame->GetHeight(PLANAR_U) instead of vi.width/2 and vi.height/2);

A 16 bpc 4:4:4 would probably have the most justification, but it would take much longer to implement, as it would require rewrite of most of the filters.

I'll put up a vote in the Usage section, on the "most important feature", when I get some time.

Right now I'd like to have the lastest CVS code tested, tested and tested, and make a stable 2.5.2 release (hopefully alongside with an optimized decomb package).

[mf]

Originally posted by MfA
planar 4:4:4 would be nice ... as would be 16 bit integer and 32 bit FP per component spaces for it and RGB.
Yeah.. That'd be teh r0x. Would that minimize roundoff errors, eliminate them, or am I not making any sense?

[Guest]

Originally posted by sh0dan
Right now I'd like to have the lastest CVS code tested, tested and tested, and make a stable 2.5.2 release (hopefully alongside with an optimized decomb package). I am still actively modifying the functionality of Decomb, so low-level YV12 modification is not yet appropriate. Anyway, I prefer to do these changes myself. Don't you have enough work of your own? :)

[sh0dan]

Didn't say who had to do them :)

Anyway - the reason I'm pushing for an optimized decomb is because a lot of people use this package, and therefore judges 2.5 on the speed of decomb.

I have been holding off the first non-beta for an optimized decomb, but since you're still working on algorithms, I'll probably have to release it anyway.
It has crossed my mind to release a "4.07 boost" version of decomb, but I assumed you would oppose that, so I didn't.

[MfA]

BTW, if it ever happens (say in Avisynth 3) the 16 bit format should of course be fixed or block floating point (in the second case each frame has a number which says where the binary point is located exactly, this can sometimes allow you to avoid some unnecessary renormalizations).

[Bidoche]

I have never thought about 16bit or even 32 FP color space, but it shouldn't be a problem for the 3.0 architecture.

@MfA
block floating point (in the second case each frame has a number which says where the binary point is located exactlyCan you explain ?

[MfA]

Its very simple, the fixed point 16 bit representation would probably be something like 8.8 or 10.6 (to give you some headroom). With fixed point you want to standardize this, because it shouldnt be of concern to the script writer.

With a block floating point presentation you give a number with each frame which we will call y, this is invisible to the script writer, the filter then knows the 16 bits have a x.y representation (x+y=16, y gives the number of fractional bits).

Say we have a 2x2 box filter and we start with y=0 ... the filter can simply sum the 4 pixels and set y=2 for the next filter in the chain. It doesnt need to do the division/normalization, because it can be done simply by shifting the point.