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 707646 - matroskamux: Internal data flow error when linking rtph264depay with matroskamux
matroskamux: Internal data flow error when linking rtph264depay with matroskamux
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
1.0.10
Other Windows
: Normal normal
: 1.0.11
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-09-06 17:24 UTC by Jake Foytik
Modified: 2013-09-12 09:23 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Logging for the previously mentioned pipeline. (238.05 KB, text/plain)
2013-09-09 10:59 UTC, Jake Foytik
Details
Linux master branch debug output (645.55 KB, application/x-zip-compressed)
2013-09-10 10:44 UTC, Jake Foytik
Details

Description Jake Foytik 2013-09-06 17:24:39 UTC
Pipeline fails when trying to stream H264 from an Axis camera, mux, and save to file.

The problem can be created using gst-launch and the pipeline:
  rtspsrc location="rtsp://192...." ! rtph264depay ! h264parse ! matroskamux ! fakesink
  
It appears the h264parse element is unable to fully link with matroskamux. After the caps have successfully negotiated, the pipeline stops with the error : 'Internal data flow error. Reason not-negotiated (-4).' 

It is noted that the pipeline:
 uridecodebin ! x264enc ! h264parse ! matroskamux ! fakesink
functions properly. This led me to believe that this problem may be be related to the following reported bug:
 - https://bugzilla.gnome.org/show_bug.cgi?id=646327

However, the latest code for h264parse (which includes the patch for the reported bug) was compiled and tested, but the issue is still present.
Comment 1 Tim-Philipp Müller 2013-09-07 14:47:47 UTC
You mean you have tested this with the git master version of h264parse? I'm asking because that bug was only fixed in the master branch not in 1.0.x.
Comment 2 Jake Foytik 2013-09-07 14:58:28 UTC
Yes, I tested the git master version of h264parse. All other components were 1.0.10.
Comment 3 Tim-Philipp Müller 2013-09-08 18:08:02 UTC
Could you attach a GST_DEBUG=*:6 log of the failure then please?

It could actually be related to matroskamux requiring a framerate in the caps, which is something fixed in git master, but maybe not in 1.0.10
Comment 4 Jake Foytik 2013-09-09 10:59:03 UTC
Created attachment 254467 [details]
Logging for the previously mentioned pipeline.

I removed the plugin registry logs and the denitializing to reduced file size.
Comment 5 Jake Foytik 2013-09-09 11:00:32 UTC
Tim-Philipp, I think you may be right. It looks like matroskamux rejected the caps from h264parse.
Comment 6 Sebastian Dröge (slomo) 2013-09-09 12:56:38 UTC
Can you also update gstreamer core to git master and then get new debug logs? That will contain more information then.
Comment 7 Jake Foytik 2013-09-10 10:44:59 UTC
Created attachment 254581 [details]
Linux master branch debug output

Tested the pipeline on Linux with all components built from git master. The pipeline functioned properly.
Comment 8 Sebastian Dröge (slomo) 2013-09-10 11:05:36 UTC
Hrm, ok so it is definitely fixed now. The question is what exactly fixed it :)
Comment 9 Jake Foytik 2013-09-10 11:21:27 UTC
Sebastian, I just tested a build with all components from git master, except plugins-good which was compiled from 1.0.10. The pipeline failed, so I'm thinking there must be some changes in matroskamux.
Comment 10 Sebastian Dröge (slomo) 2013-09-12 07:01:08 UTC
Thanks! It's this commit here:
commit 2a8566ddec7cdacec68413ebd81fbe5c4182bbdc
Author: Wim Taymans <wim.taymans@collabora.co.uk>
Date:   Tue Aug 27 15:25:16 2013 +0200

    matroska-mux: remove framerate restriction
    
    Remove the framerate restriction on the caps.


Backported to the 1.0 branch and will be included in 1.0.11.