Hi, i'm sure that the encoder does not support B-frames.
But what about the decoder? Can it handle them?

Thanks,
Alessandro

Umm. I don't know where you got that idea from, but all Pis back to the original B do H.264 high profile encode and decode, which requires B-slice support.

As it is apparently board policy to disallow any criticism of anything, as it appears to criticise something is to criticise all the users of that something, I will no longer be commenting in threads which are not directly relevant to my uses of the Pi.

dickon wrote: Umm. I don't know where you got that idea from, but all Pis back to the original B do H.264 high profile encode and decode, which requires B-slice support.

Read here: viewtopic.php?t=231368#p1417085

Oh. Apologies. I could swear I'd had to disable them in something I wrote. Perhaps I just did it because I knew they'd get in the way.

Either way, yes, the decoder certainly does. You can't play most BluRay or DVB streams without them.

As it is apparently board policy to disallow any criticism of anything, as it appears to criticise something is to criticise all the users of that something, I will no longer be commenting in threads which are not directly relevant to my uses of the Pi.

I'm asking that beacause i need to decode a video streaming from an IOs devices (Ipad pro 2nd gen) and android devices, and the IOs device has much more latency than Android on decoder (It is not a network problem). I see that the decoder must buffer more frames (compared to Android video streaming) before output a decoded one, this leads me to think that IOs uses B-frames.

Encoding B-frames forces higher latency, and is actually quite difficult to do in close to real time of course, depending on how many frames ahead you search. So we don't support that but we do support decoding.

I'm sure there is something out there to analyse a H264 stream and tell you whether it contains B-frames.

Software guy, working in the applications team.