Fix crash when using formats with bits per pixel size not divisible by 8

[Wumpf]

Two separate fixes actually:

• get_bytes_per_frame assumed that a bits per pixel size that is not divisible by 8 means that it can't retrieve the frame size because that will yield a frame buffer with a non full-byte size. This is not entirely true since for instance YUV formats typically have size restrictions such that their raw frame buffers don't run into this problem. ➡️ The check got changed to the frame buffer's size
• don't panic when get_bytes_per_frame can't return a size and instead report the error and exit

The former fixes using yuv formats for me, the later is a bit of a general requirement for me since I deal with arbitrary user data: not being able to handle data is sad, but crashing over it goes too far :)

[nathanbabcock]

Nice improvement to support YUV420P and potentially many other pixel formats as well. Also the better error handling is a welcome change.

There's an edge case here that needs to be handled: if the bytes per frame can't be calculated, it allocates a zero-size buffer and then the iterator constantly produces OutputFrame events with zero size and never finishes. That could happen, for example, with an irregularly-sized 321x421 YUV420P output.

I'll merge this as a starting point and follow up with a fallback to "chunked" mode — the same way it would handle encoded video data like H264. Depending on your use case that might be perfectly fine, or you may need to check for either OutputFrame or OutputChunk depending on the situation. We can iterate on this solution if needed.

[Wumpf]

if the bytes per frame can't be calculated, it allocates a zero-size buffer and then the iterator constantly produces OutputFrame events with zero size and never finishes

oops. I didn't notice that I only exit from the lambda that's passed to map and not the entire thread - I still wanted to handle this as a fatal error as before, just more gracefully.
Thank you so much for following up on this!