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 722677 - Android: h264parse "no SPS/PPS yet..." parsing encoded frames with MediaCodec encoder
Android: h264parse "no SPS/PPS yet..." parsing encoded frames with MediaCodec...
Status: RESOLVED INCOMPLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
1.x
Other other
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-01-21 09:52 UTC by stic
Modified: 2018-05-05 16:09 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
h264parse log file (25.47 KB, text/plain)
2014-01-21 09:52 UTC, stic
Details
stream dump with h264parse config-interval=1 (4.38 KB, application/octet-stream)
2014-01-21 14:18 UTC, stic
Details

Description stic 2014-01-21 09:52:45 UTC
Created attachment 266845 [details]
h264parse log file

Using encoder from androidmedia (tried with avc encoder of different devices) to produce avc h264 encoded video.
With following pipeline:
videotestsrc is-live=true ! video/x-raw,framerate=30/1 ! videoconvert ! video/x-raw,framerate=30/1,format=I420 ! amcvidenc-omxnvidiah264encoder bitrate=2048 i-frame-interval=8 ! video/x-h264,profile=baseline ! mpegtsmux ! tcpserversink host=...

The receiver is able to display something only when it was connected to the stream when first data are sent.
If receiver connects later, it does not receive information allowing it to display something.
It seems there is a problem with SPS/PPS data.
Using h264parse in the pipeline with config-interval parameter gives following logs, see attached log.txt file.
Comment 1 stic 2014-01-21 14:18:10 UTC
Created attachment 266871 [details]
stream dump with h264parse config-interval=1
Comment 2 Sebastian Dröge (slomo) 2014-05-26 12:50:34 UTC
This sounds like the problem is that the codec data is provided out of band, and the encoder element does not include it in the stream or the caps. In theory these would be stored in the output MediaFormat in the cid-X (X = 0, 1, 2, ...) fields if they don't come inband.

Please check if this is the case, also try with the merged amcvidenc element in gst-plugins-bad if that changes anything.
Comment 3 Vivia Nikolaidou 2018-05-05 16:09:30 UTC
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment.
Thanks!