The reason it's bigger is because the hardware has alignment constraints, so you end up with padding at the end of every row.
In this case, Pi 5 likes 64-byte alignment which means that, because we want 64-byte alignment in U and V, we end up with 128-byte alignment in Y. So your rows contain 384 bytes, not 288.
There's no easy way to get your buffer "de-padded" before writing it out, so far as I know. I think YUV420 output probably goes through the NullEncoder and then the FileOutput classes, neither of which has any knowledge what format they are dealing with. Obviously you could improve that, but there'd be some extra context to pass around, maybe some new (though simple) classes and extra plumbing.
In this case, Pi 5 likes 64-byte alignment which means that, because we want 64-byte alignment in U and V, we end up with 128-byte alignment in Y. So your rows contain 384 bytes, not 288.
There's no easy way to get your buffer "de-padded" before writing it out, so far as I know. I think YUV420 output probably goes through the NullEncoder and then the FileOutput classes, neither of which has any knowledge what format they are dealing with. Obviously you could improve that, but there'd be some extra context to pass around, maybe some new (though simple) classes and extra plumbing.
Statistics: Posted by therealdavidp — Mon Mar 24, 2025 9:32 am