GNOME Bugzilla – Bug 778749
Using vaapih265enc without h265parse causes assert
Last modified: 2017-03-14 16:26:30 UTC
When executing the example command from here: https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer-vaapi-plugins/html/gstreamer-vaapi-plugins-vaapih265enc.html gst-launch-1.0 -ev videotestsrc num-buffers=60 ! vaapih265enc ! matroskamux ! filesink location=test.mkv This will cause an assert in the “gst-libs/gst/vaapi/gstvaapiencoder_h265.c” in the function “GstVaapiEncoderStatus”. There are a couple of asserts added and the first one always triggers since the bitsize count at that place is 154 and all the nbits inputs to the WRITE_UINT32 function are hardcoded values. When adding a h265parse to the command, the encoding succeeds. gst-launch-1.0 -e videotestsrc num-buffers=60 ! vaapih265enc ! h265parse ! matroskamux ! filesink location=test.mkv
https://bugzilla.gnome.org/show_bug.cgi?id=778750#c1
Created attachment 347802 [details] [review] libs: encoder: h265: fix reserved length of bits Fix reserved length of bits for bit_depth_luma_minus8 and bit_depth_chroma_minus8 ----- Reference: http://fushizen.eu/random/W13478_1_pt15-3rd_FDIS_clean.pdf http://labs.divx.com/book/export/html/127907
@Soren Friis, could you confirm this patch?
Thanks. This fixes the assert. I guess you could change the 0x3f part to 0x1f as well, since only 5 bits are being written. Having 0x3f there probably won't break anything though. Could you get the example on the wiki page updated? Sreerenj told me that you are actually not supposed to ever run the H.265 encoding without the h265parse element, which mean that the example is now misleading.
(In reply to Soren Friis from comment #4) > Thanks. This fixes the assert. > > I guess you could change the 0x3f part to 0x1f as well, since only 5 bits > are being written. Having 0x3f there probably won't break anything though. > Ah, you're right. > Could you get the example on the wiki page updated? Sreerenj told me that > you are actually not supposed to ever run the H.265 encoding without the > h265parse element, which mean that the example is now misleading. Okay. Apparently, using h264parse is recommendable.
Created attachment 347807 [details] [review] libs: encoder: h265: fix reserved length of bits Fix reserved length of bits for bit_depth_luma_minus8 and bit_depth_chroma_minus8
Created attachment 347808 [details] [review] docs: h264/h265: put parser to the example pipeline
Attachment 347807 [details] pushed as 7f38b3b - libs: encoder: h265: fix reserved length of bits Attachment 347808 [details] pushed as e65d916 - docs: h264/h265: put parser to the example pipeline
branch 1.10 * 01bf6574 docs: h264/h265: put parser to the example pipeline * f266250e libs: encoder: h265: fix reserved length of bits