After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 736829 - gst-omx: rpi encoder don't pass IDR as one buffer
gst-omx: rpi encoder don't pass IDR as one buffer
Product: GStreamer
Classification: Platform
Component: gst-omx
git master
Other Linux
: Normal major
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2014-09-17 19:30 UTC by m][sko
Modified: 2018-11-03 13:00 UTC
See Also:
GNOME target: ---
GNOME version: ---

keep unfinished buffers (3.77 KB, patch)
2014-09-17 19:31 UTC, m][sko
none Details | Review
keep unfinished buffers (5.58 KB, patch)
2014-09-17 21:10 UTC, m][sko
needs-work Details | Review

Description m][sko 2014-09-17 19:30:30 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 
Comment 1 m][sko 2014-09-17 19:31:26 UTC
Created attachment 286419 [details] [review]
keep unfinished buffers
Comment 2 m][sko 2014-09-17 20:56:58 UTC
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
   but SLICE IDR is pass with gst_pad_push 
 so h264parse output was

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 
But I don't know if other OMX encoders generate OMX_BUFFERFLAG_ENDOFFRAME
Comment 3 m][sko 2014-09-17 21:10:02 UTC
Created attachment 286421 [details] [review]
keep unfinished buffers
Comment 4 Sebastian Dröge (slomo) 2014-09-18 10:00:24 UTC
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.
Comment 5 m][sko 2014-09-18 14:06:13 UTC
I hope that identification of NAL UNITs will be lighting fast.

no plan B?
Comment 6 Sebastian Dröge (slomo) 2014-09-23 20:24:34 UTC
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.
Comment 7 m][sko 2014-09-23 20:56:09 UTC
But I would expext something, this flag working everywhere
Comment 8 Sebastian Dröge (slomo) 2014-09-23 21:17:31 UTC
That's what you would expect but all of the OpenMAX IL implementations are broken in one way or another...
Comment 9 Sebastian Dröge (slomo) 2014-10-05 19:24:18 UTC
Are you planning to work on this?
Comment 10 m][sko 2014-10-05 21:18:04 UTC
sorry I can't right now
I'm on holiday.
Comment 11 Julien Isorce 2015-03-24 13:17:48 UTC
Do you still plan to work on this ?
Comment 12 m][sko 2015-03-24 13:44:06 UTC
I did prototype that work on Raspberry Pi

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 :(
Comment 13 GStreamer system administrator 2018-11-03 13:00:12 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to'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: