Linux's Stateless H.264 Decode Interface Ready To Be Deemed Stable

[phoronix]

Phoronix: Linux's Stateless H.264 Decode Interface Ready To Be Deemed Stable

The Linux kernel's stateless video decoder interface is used for video decoding where no state needs to be kept between processed video frames and allows for independently decoding each video frame. The H.264 stateless decode interface for the Linux kernel has been in the works for a few years and is now deemed ready and stable for dealing with modern stateless codecs...

http://www.phoronix.com/scan.php?page=news_item&px=Stateless-H264-Out-Of-Staging

[Mathias]

no state needs to be kept between processed video frames and allows for independently decoding each video frame

I don't understand... why would I want a single frame from a video or multiple frames but throw away all state inbetween? I think I'm misunderstanding why/how this is usefull.

[Sethox]

I don't understand... why would I want a single frame from a video or multiple frames but throw away all state inbetween? I think I'm misunderstanding why/how this is usefull.

That's the ability, which means any frame that is stateless it will be able to INDEPENDENTLY decode each and every frame that makes up a whole video/clip.

[airminer]

I don't understand... why would I want a single frame from a video or multiple frames but throw away all state inbetween? I think I'm misunderstanding why/how this is usefull.

To quote the official docs:

A stateless decoder is a decoder that works without retaining any kind of state between processed frames. This means that each frame is decoded independently of any previous and future frames, and that the client is responsible for maintaining the decoding state and providing it to the decoder with each decoding request. This is in contrast to the stateful video decoder interface, where the hardware and driver maintain the decoding state and all the client has to do is to provide the raw encoded stream and dequeue decoded frames in display order.

So basically it simplifies the decoder side of the equation by making keeping the state information around a responsibility of the client instead of the decoder.

[Mathias]

Thanks airminer, that explains it.

[eydee]

Why now? H264 was a decade ago. It's dying already.

[V1tol]

Why now? H264 was a decade ago. It's dying already.

Dunno where it is dying, it is still the most popular codec. Starting with H264 was smart decision, porting other codecs will be much easier.

[GruenSein]

Why is this in the kernel?

[rastersoft]

Why is this in the kernel?

Because it is for hardware decoding.

[curfew]

I don't understand... why would I want a single frame from a video or multiple frames but throw away all state inbetween? I think I'm misunderstanding why/how this is usefull.

I am not a developer in this field, so I have really no understanding of related concepts, but from what I could understand by glancing at other resources seems to suggest that the "decoder" means hardware, and by moving state management to the software, it will make the hardware much simpler.

Additionally it allows the software to basically do any kind of magic on its own, whereas the hardware only takes a frame and renders it, and does not have to care about the surrounding circumstances. This essentially allows re-using existing, old hardware decoders for any imaginable scenario, in contrast to earlier when you would be limited by the feature set supported by the individual chips.