GNOME Bugzilla – Bug 736829
gst-omx: rpi encoder don't pass IDR as one buffer
Last modified: 2018-11-03 13:00:12 UTC
rpi encoder don't pass IDR frame as one buffer sometimes so we have situations like SPS, PPS, IDR(some data), IDR(rest of data), SLICEs problem is that first IDR is flagged as OMX_BUFFERFLAG_SYNCFRAME second part of IDR is flagged as full OMX_BUFFERFLAG_SYNCFRAME + OMX_BUFFERFLAG_ENDOFFRAME
Created attachment 286419 [details] [review] keep unfinished buffers
I observe 2 problems in my pipeline on rpi omxh264enc ! h264parse SPS, PPS, IDR(1. part), IDR(2. part SLICE IDR),... SLICEs 1. SPS, PPS as headers, IDR was pass with gst_video_encoder_finish_frame but SLICE IDR is pass with gst_pad_push so h264parse output was SLICE IDR, SPS,PPS, IDR 2. SPS, PPS as headers IDR processed with gst_video_encoder_finish_frame slice IDR with next gst_video_encoder_finish_frame so we consume 2 frames for one IDR so my patch collect buffers until it revived OMX_BUFFERFLAG_ENDOFFRAME But I don't know if other OMX encoders generate OMX_BUFFERFLAG_ENDOFFRAME
Created attachment 286421 [details] [review] keep unfinished buffers
Comment on attachment 286421 [details] [review] keep unfinished buffers Other OMX implementations don't reliably generate the ENDOFFRAME flag, no. Maybe instead of this we need to use the codecparsers from gst-plugins-bad and just parse the h264 content in gstomxh264enc.c to make sure it's properly framed.
I hope that identification of NAL UNITs will be lighting fast. no plan B?
Fast enough at least, it's just looking at the first few bytes. What would you propose as plan B instead? We could have a fast-path using ENDOFFRAME for the RPi here I guess, but the generic implementation should be there too.
But I would expext something, this flag working everywhere
That's what you would expect but all of the OpenMAX IL implementations are broken in one way or another...
Are you planning to work on this?
sorry I can't right now I'm on holiday.
Do you still plan to work on this ?
I did prototype that work on Raspberry Pi https://bitbucket.org/xlazom00/gst/src/096fda1174ee27d00d75df43543f69827faeefdd/patch/gst-omx/debian/patches/0001-omxvideoenc-NAL.patch?at=master I didn't check for memory leaks! I switch on one feature on RPI encoder that generate 2 NAL units per 1 frame (top and bottom part of frame) So I think that we can add this feature to omxh264encde But As I wrote in prev. comment parsing NAL units isn't just some eazy header parser and memcpy :(
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-omx/issues/4.