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 688043 - videodecoder: no timestamps for multifilesrc ! jpegdec ! ...
videodecoder: no timestamps for multifilesrc ! jpegdec ! ...
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal blocker
: 1.1.90
Assigned To: GStreamer Maintainers
GStreamer Maintainers
playback
Depends on:
Blocks:
 
 
Reported: 2012-11-10 16:07 UTC by Shlomo D
Modified: 2013-09-19 07:53 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
videodecoder: If there is no PTS at all, assume it starts from the segment start (1.52 KB, patch)
2013-09-19 00:44 UTC, Olivier Crête
committed Details | Review

Description Shlomo D 2012-11-10 16:07:29 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
Comment 1 Tim-Philipp Müller 2012-11-14 16:14:46 UTC
Bumping priority, because it's quite a common use case and it doesn't work right now.
Comment 2 Wim Taymans 2012-12-11 15:03:35 UTC
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?
Comment 3 Tim-Philipp Müller 2012-12-11 23:53:18 UTC
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.
Comment 4 Tim-Philipp Müller 2012-12-12 01:04:35 UTC
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)
Comment 5 sreerenj 2013-08-14 09:58:55 UTC
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
Comment 6 Sebastian Dröge (slomo) 2013-08-14 12:21:57 UTC
So it's a regression that must be fixed before 1.2.0
Comment 7 sreerenj 2013-08-16 14:43:35 UTC
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.
Comment 8 Sebastian Dröge (slomo) 2013-09-12 11:38:49 UTC
So what to do here, what doesn't work yet?
Comment 9 sreerenj 2013-09-12 11:49:24 UTC
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
Comment 10 Sebastian Dröge (slomo) 2013-09-12 12:11:01 UTC
I think it already does something like that in gst_video_decoder_prepare_finish_frame
Comment 11 sreerenj 2013-09-12 12:15:30 UTC
Okay,
So, if the pipeline in comment2 is working for you with git master then this is already fixed :)
Comment 12 Sebastian Dröge (slomo) 2013-09-12 12:31:39 UTC
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?
Comment 13 Olivier Crête 2013-09-19 00:44:34 UTC
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
Comment 14 Sebastian Dröge (slomo) 2013-09-19 07:53:19 UTC
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