maybe make formats clearer

[allenling]

apparently, the format YUV420 actually represents YUV420p, because in MemoryInterfaces.hpp, there's comments like

/* 8-bit YUV420P image;
 */
class TC_EXPORT SurfaceYUV420 : public Surface {

and SurfaceYUV420 uses 3 SurfacePlanes to store Ys, Us, Vs.

and that's true for YUV444 as well. the YUV444 surface derives from RGBPlanar surface, and RGBPlanar uses one SurfacePlane to

store RGBs, and that SurfacePlane is going to allocate 3widthheight memory space.

as the term Planar in SurfaceRGBPlanar suggests, each channle will store R, or G, or B, and for YUV444, each channel will store Y, U, V.

so YUV444 actually represents YUV444P.

so why don't just change the format names like YUV420, YUV444 to YUV420P and YUV444P?

that makes them what you see is what you get.

[RomanArzumanyan]

Hi @allenling

That's a good question!

The reason format name is just YUV420 and not YUV420P or YUV420I is simply because "by default" decoders return planar yuv420 unless (for some reason like advanced de-interlace algo development) you want your frame interleaved. Also, some standards like HEVC no longer support interleaved encoding per se and that's the direction industry goes.

that makes them what you see is what you get

As far as I understand, that's exactly how it looks from Python perspective. Unless you want to dig deep into C++ guts it's all nice and clean )

And BTW every GitHub user is free to submit a PR which renames the classes in Python but I'm afraid such PR is going to be quite destructive as it will break the backward compatibility for the sake of syntactic sugar.

[allenling]

in some cases, some not-very-video-process-savvy guy like me would first feel kind of "misleading", since YUV420 is the same as YUV420P.

but because planar YUV is kind of the default format for mainstream decoders/encoders, i guess that naming is acceptable.