GNOME Bugzilla – Bug 688043
videodecoder: no timestamps for multifilesrc ! jpegdec ! ...
Last modified: 2013-09-19 07:53:24 UTC
The multifilesrc example in http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-good-plugins/html/gst-plugins-good-plugins-multifilesrc.html is broken. The example command: gst-launch-1.0 multifilesrc location="img.%04d.png" index=0 caps="image/png,framerate=\(fraction\)12/1" ! \ pngdec ! videoconvert ! videorate ! theoraenc ! oggmux ! \ filesink location="images.ogg" makes gstreamer stuck on preroll. (after interrupting with Ctrl-C: ERROR: pipeline doesn't want to preroll.) The command works using earlier version 0.10 when replacing "videoconvert" with "ffmpegcolorspace": gst-launch-0.10 multifilesrc location="img.%04d.png" index=0 caps="image/png,framerate=\(fraction\)12/1" ! \ pngdec ! ffmpegcolorspace ! videorate ! theoraenc ! oggmux ! \ filesink location="images.ogg" I am using Arch Linux, and have installed the following packages: gstreamer 1.0.2-1 gst-plugins-bad 1.0.2-1 gst-plugins-base 1.0.2-1 gst-plugins-base-libs 1.0.2-1 gst-plugins-good 1.0.2-1 gst-plugins-ugly 1.0.2-1 gstreamer0.10 0.10.36-1 gstreamer0.10-bad 0.10.23-3 gstreamer0.10-bad-plugins 0.10.23-3 gstreamer0.10-base 0.10.36-1 gstreamer0.10-base-plugins 0.10.36-1 gstreamer0.10-ffmpeg 0.10.13-1 gstreamer0.10-good 0.10.31-1 gstreamer0.10-good-plugins 0.10.31-1 gstreamer0.10-ugly 0.10.19-2 gstreamer0.10-ugly-plugins 0.10.19-2
Bumping priority, because it's quite a common use case and it doesn't work right now.
Works for me with: gst-launch-1.0 videotestsrc num-buffers=500 ! pngenc ! multifilesink and then gst-launch-1.0 multifilesrc caps="image/png,framerate=\(fraction\)12/1" ! pngdec ! videoconvert ! videorate ! theoraenc ! oggmux ! filesink location="images.ogg" and then gst-launch-1.0 playbin uri=file:///path/to/my/images.ogg What's failing?
Hrm, true, that works just fine. What doesn't actually work is if you do the same thing with jpeg instead of png. Someone mentioned this on IRC, and I assumed it was the same issue. Retitling bug for jpeg issue. What happens in the jpegdec case looks like a videodecoder bug. It never passes on the 0 input timestamp for the first buffer, and hence can't base further timestamps on top of that plus duration, so outputs everything without timestamps. Possibly related to the parsing/packetised mode.
This fixes it: commit 0b411e1a09f26a53117a8f549c58bea81e0157a3 Author: Tim-Philipp Müller <tim@centricular.net> Date: Wed Dec 12 00:54:40 2012 +0000 jpegdec: really treat input as packetised if framerate in caps != 1/1 Fix logic error - it's enough for one of fps_d or fps_n to be != 1 for the framerate to be != 1/1 (assuming it's been simplified). This puts timestamps on the output of multifilesrc caps="image/jpeg,framerate=12/1" ! jpegdec ! .. We still need to fix this properly though and add a flag to GstVideoInfo to signal that there was no framerate argument in the input caps and that fps_n/fps_d represent the default. https://bugzilla.gnome.org/show_bug.cgi?id=688043 but exposes another issues (parsing jpeg with preview image causes error about two SOI markers)
pasting from #gstreamer channel.. <sree_> wtay: does the second pipeline you mentioned in comment2 of https://bugzilla.gnome.org/show_bug.cgi?id=688043 is working for you? <sree_> wtay: it seems the videorate element is discarding the buffers because of GST_CLOCK_TIME_NONE timestamp (at least for me). <wtay> let me try <wtay> sree_, it doesn't, seems like missing timestamps somewhere <wtay> sree_, multifilesrc is ok, pngdec doesn't place timestamps on output buffers <sree_> wtay: aha, okay,,seems like it is working fine with 1.0 and not with git head.. <sree_> wtay: but same result for jpegdec also <wtay> something is broken then
So it's a regression that must be fixed before 1.2.0
One solution could be to add an incremental PTS value to the decoded frames (based on framerate if upstream provides a fps > 1) to jpegdec and pngdec.
So what to do here, what doesn't work yet?
I don't know whether it is working now :) (comment 5) If not, We might need to do something like, https://bug706285.bugzilla-attachments.gnome.org/attachment.cgi?id=252985
I think it already does something like that in gst_video_decoder_prepare_finish_frame
Okay, So, if the pipeline in comment2 is working for you with git master then this is already fixed :)
It doesn't, the encoding fails... probably because none of the pngdec output buffers has a PTS. They all have a duration though. Maybe if no PTS is given the videodecoder base class should assume that the first PTS is equal to the segment start?
Created attachment 255266 [details] [review] videodecoder: If there is no PTS at all, assume it starts from the segment start Here is a possible patch for this
commit c10311ba70459baa6f299b8206ee183480074814 Author: Olivier Crête <olivier.crete@collabora.com> Date: Wed Sep 18 20:42:55 2013 -0400 videodecoder: If there is no PTS at all, assume it starts from the segment start This is to make the multifilesrc ! pngdec case work https://bugzilla.gnome.org/show_bug.cgi?id=688043