GNOME Bugzilla – Bug 715166
pngparse: Don't set a framerate from uninitialized variables
Last modified: 2013-12-12 23:42:04 UTC
Created attachment 261446 [details] Minimal test that causes the error sometimes pngparse causes following error in 1/3 cases ERROR from element pngparse1: GStreamer encountered a general stream error. Debugging info: gstbaseparse.c(3188): gst_base_parse_loop (): /GESPipeline:gespipeline0/GESTimeline:gestimeline0/GESVideoTrack:gesvideotrack0/GnlComposition:gnlcomposition0/GnlSource:gnlsource0/GstBin:videosrcbin/GstBin:still-image-bin/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin3/GstPngParse:pngparse1: streaming stopped, reason not-linked Using GStreamer 1.2.1, gnonlin, gst-editing-services from git
Created attachment 261447 [details] Graph of the pipeline before the main loop is run
Created attachment 261448 [details] Graph of the pipeline when the error occurs
Created attachment 261449 [details] Graph of the pipeline at EOS when it was successful
The error may occur because GstDecodeBin sets a negative framerate. The framerate is only negative when it fails. Otherwise its also bogus, but it works. Setting framerate with restriction caps does not work, because its only on the track.
A negative framerate should never happen at all, please try to find the element that sets it first and then let's fix that one :)
$ gst-discoverer-1.0 -v data/image/vieh.png | grep framerate video(image): image/png, width=(int)512, height=(int)512, framerate=(fraction)-509212673/5 image/png, width=(int)512, height=(int)512, framerate=(fraction)-509212673/5 $ gst-discoverer-1.0 -v data/image/vieh.png | grep framerate video(image): image/png, width=(int)512, height=(int)512, framerate=(fraction)-206556775/3 image/png, width=(int)512, height=(int)512, framerate=(fraction)-206556775/3 $ gst-discoverer-1.0 -v data/image/vieh.png | grep framerate video(image): image/png, width=(int)512, height=(int)512, framerate=(fraction)24356861/15 image/png, width=(int)512, height=(int)512, framerate=(fraction)24356861/15 $ gst-discoverer-1.0 -v data/image/vieh.png | grep framerate video(image): image/png, width=(int)512, height=(int)512, framerate=(fraction)-2001127427/15 image/png, width=(int)512, height=(int)512, framerate=(fraction)-2001127427/15 the framerate is negative sometimes. this is when the problem occurs.
Is this really a different, negative framerate on the *same* file? :) Could you attach that file here, and/or try to find who randomly miscalculates the framerate?
this is caused by following patch: commit da506f4a0a86cf2a7b35233289e670710b00adcb Author: Thibault Saunier <thibault.saunier@collabora.com> Date: Wed Nov 13 17:16:04 2013 -0300 pngparse: Proxy upstream framerate on srcpad if avalaible If the user sets it himself with capsfilter, the information should be kept and transmitted downstream.
Created attachment 261467 [details] [review] Patch on bad plugins that fixes the issue This patch fixes the error. It was caused by uninitialized ints. sink_caps was returning NULL, but the code did not mind. I am setting a default 1/1 framerate now.
Shouldn't a png have the same framerate everytime?
png don't have a framerate, so I modified your patch a little to not set the framerate if upstream doesn't provide one. commit ef9d363dfefc9d7bd343cd2b2562104116b5b14d Author: Lubosz Sarnecki <lubosz@gmail.com> Date: Mon Nov 25 16:57:00 2013 +0000 pngparse: Don't try to set framerate if not from upstream https://bugzilla.gnome.org/show_bug.cgi?id=715166
Please reassign and retitle bugs properly when closing them
Picked into 1.2 since the above commit that broke things is also in 1.2