- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have an encoder that provides an H.265 stream using intra refresh (VPS, SPS, PPS and SEI Restore Points) rather than sending periodic IDR frames.
I am using GStreamer v1.24 and the new 'qsv' ('qsvh265dec') element on an Intel UHD 770 GPU.
That was one of the suggestions in this article:
Transition from Intel® Media SDK to Media Frameworks and oneVPL...
I have confirmed via Process Explorer that my GStreamer pipeline and the 'qsvh265dec' element are loading the lib64mfx-gen.dll (for using oneVPL) rather than the libmfxhw64.dll (Intel Media SDK). I should therefore be using the latest (ish!) technologies.
The debug trace from the GStreamer 'qsvh265dec' element suggests that the hardware decoder is not able to start decoding the stream and is continually asking for more data (DecodeFrameAsync returns -10 - MFX_ERR_MORE_DATA).
If I stop my encoder and restart it my GStreamer pipeline wakes up as it sees VPS, SPS, PPS, IDR (NAL type 19 or 20). My encoder only sends this sequence when starting the stream and periodically sends VPS, SPS, PPS and SEI Restore and as above is using intra refresh to avoid sending full I-frames.
Is decoding this type of stream supported either by the software layers or by the hardware itself? If so, how do I get it to work.
I can setup my encoder to not use intra refresh and send a more traditional stream of periodic VPS, SPS, PPS and IDR and I can connect to my stream when it is already running.
I can also setup the same encoder to output an intra refresh H.264 stream and when using the GStreamer v1.24 'qsvh264dec' decode element I can decode the stream from any point (after receiving the following sequence of NALs SPS, PPS, SEI Restore).
Link Copied

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page