[Bug 758169] New: rtph264depay should translate "a-framerate (string)" attribute to "framerate (fraction)" on certain cameras
GStreamer (GNOME Bugzilla)
bugzilla at gnome.org
Mon Nov 16 03:32:02 PST 2015
https://bugzilla.gnome.org/show_bug.cgi?id=758169
Bug ID: 758169
Summary: rtph264depay should translate "a-framerate (string)"
attribute to "framerate (fraction)" on certain cameras
Classification: Platform
Product: GStreamer
Version: 1.4.4
OS: Linux
Status: NEW
Severity: normal
Priority: Normal
Component: gst-plugins-good
Assignee: gstreamer-bugs at lists.freedesktop.org
Reporter: jspurny at seznam.cz
QA Contact: gstreamer-bugs at lists.freedesktop.org
GNOME version: ---
When playing h264 streams from Sony SNC-VB600 and FLIR FC-690-PAL cameras, the
rtph264depay will receive caps containing "a-framerate" attribute, which
contains string value, for example "12.0", but rtph264depay does not recognize
it and reports "framerate=(fraction)0/1" on src pad, so the whole pipeline
downstream has "0/1" framerate, which means "variable bitrate" according to
documentation.
I believe that rtph264depay could translate the nonstandard "a-framerate" to
"framerate", so the caps downstream would report correct framerate when it is
in fact known, instead of reporting a variable framerate (0/1), which is not
true.
If someone has access to cameras mentioned above (and I think it's safe to
assume that probably all contemporary Sony and FLIR cameras will exhibit the
same behaviour), you can check using simple pipeline:
gst-launch-1.0 rtspsrc location=rtsp://<addr> ! decodebin ! xvimagesink
This is the log record where "a-framerate" is first mentioned:
DEBUG rtspsrc gstrtspsrc.c:1892:gst_rtspsrc_sdp_attributes_to_caps: adding
caps: a-framerate=12.0
and from there, every other element has "framerate=0/1" in caps.
For additional info, see bug 758023
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
More information about the gstreamer-bugs
mailing list