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 736211 - gst-omx: rpi don't inline NAL AU delimiter
gst-omx: rpi don't inline NAL AU delimiter
Status: RESOLVED WONTFIX
Product: GStreamer
Classification: Platform
Component: gst-omx
1.4.0
Other Linux
: Normal enhancement
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-09-06 23:08 UTC by m][sko
Modified: 2015-07-31 20:38 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
generate NAL AU delimiter for every frame (6.47 KB, patch)
2014-09-06 23:08 UTC, m][sko
needs-work Details | Review

Description m][sko 2014-09-06 23:08:59 UTC
Created attachment 285596 [details] [review]
generate NAL AU delimiter for every frame

rpi don't inline AU delimiter so we can't generate valid hls stream for iDevices.
this patch add this extension
Comment 1 m][sko 2014-09-06 23:35:33 UTC
and this patch will help to
https://bugzilla.gnome.org/show_bug.cgi?id=736213
Comment 2 Olivier Crête 2014-09-09 14:59:58 UTC
Review of attachment 285596 [details] [review]:

Imho, this should always be there, not as a property. And as I mentionned in #736213 and #696037, they should always be there, so no need for the property.
Comment 3 m][sko 2014-09-12 13:11:12 UTC
It has default value TRUE

If you really want it as default
so we should do same for inline SPS/PPS as it is important too
Comment 4 Sebastian Dröge (slomo) 2014-09-12 13:31:42 UTC
Or maybe we should just outsource this to h264parse? And let the decoder output whatever they like the output (instead of adding the same code everywhere)?
Comment 6 Sebastian Dröge (slomo) 2014-09-12 13:40:32 UTC
Yeah, my point is that we would have to add it to every encoder then :) So why not just keep it in a single place in the parser instead?
Comment 7 m][sko 2014-09-12 14:03:49 UTC
so we will dump all AUs on h264parse sink and generate new  
pretty much as 
https://bugzilla.gnome.org/show_bug.cgi?id=696037

I have only one problem (hls mux)

Every file that came out of h264enc ! h264parse ! tsmux ! multifilesink 
must start AU SPS PPS IDR 

so we will need to flag AU somehow
Comment 8 Sebastian Dröge (slomo) 2014-09-12 14:09:24 UTC
Alright, let's go with that then.
Comment 9 minfrin 2015-07-31 20:38:48 UTC
I would rather this was fixed directly in omxh264enc.

First, it would make omxh264enc work out the box, and not rely on another module to "fix" the stream somehow.

Second, no modifications to h264parse seem to have been made to resolve this issue, so we're talking about a fix that doesn't exist.

There is a further behaviour I have found where the addition of h264parse to the pipeline breaks hlssink - only one ts fragment is created which grows without bound.

There are a significant amount of duplicates of bugs that say "HLS to Safari/iOS doesn't work", this patch will fix all of them.