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 682211 - gst_element_query_duration returns incorrect duration on mpeg2ts file
gst_element_query_duration returns incorrect duration on mpeg2ts file
Status: RESOLVED INCOMPLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
0.10.22
Other Linux
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2012-08-19 22:34 UTC by lips.john
Modified: 2012-10-18 10:49 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description lips.john 2012-08-19 22:34:14 UTC
Here is the output from ffmpeg -i filename.mpg:

Input #0, mpegts, from
  Duration: 03:59:59.65, start: 50177.007422, bitrate: 14276 kb/s

Stream #0:0[0x31]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002),
        yuv420p, 1280x720 [SAR 1:1 DAR 16:9], 14950 kb/s, 64.96 fps, 59.94
        tbr, 90k tbn, 119.88 tbc
    
Stream #0:1[0x34](eng): Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz,
            5.1(side), s16, 448 kb/s
                
Stream #0:2[0x35](spa): Audio: ac3 (AC-3 / 0x332D4341), 48000
                Hz, stereo, s16, 192 kb/s (visual impaired)

Here is the output from gst_element_query_duration:

3:37:14.178723991

As you can see there a difference of more than 20 minutes.  I looked for any
existing bugs, but did not find anything.  Here is how it is implemented:

        case GDK_k:
        {

                gint64 dur_ns;
                GstFormat format;
                
                format = GST_FORMAT_TIME;

                gst_element_query_duration(pipeline,&format,&dur_ns);
                g_print ("%" GST_TIME_FORMAT "\n", GST_TIME_ARGS (dur_ns));

                return TRUE;
        

        }
        break;
        
Am I missing something?  I can't attach the file as it is ~25 GB.  Is there a simple way to trim off a couple minutes of the file without changing the encoding?

Here are my gst related packages:


dev-python/gst-python-0.10.21
media-libs/gst-plugins-bad-0.10.22
media-libs/gst-plugins-base-0.10.35
media-libs/gst-plugins-good-0.10.30
media-libs/gst-plugins-ugly-0.10.18
media-libs/gstreamer-0.10.35
media-plugins/gst-plugins-a52dec-0.10.18
media-plugins/gst-plugins-alsa-0.10.35
media-plugins/gst-plugins-ffmpeg-0.10.13-r2
media-plugins/gst-plugins-gconf-0.10.30
media-plugins/gst-plugins-gl-0.10.2
media-plugins/gst-plugins-jack-0.10.30
media-plugins/gst-plugins-meta-0.10-r7
media-plugins/gst-plugins-mpeg2dec-0.10.18
media-plugins/gst-plugins-ogg-0.10.35
media-plugins/gst-plugins-vorbis-0.10.35
media-plugins/gst-plugins-x-0.10.35
media-plugins/gst-plugins-x264-0.10.18
media-plugins/gst-plugins-xvideo-0.10.35

This is a gentoo amd64 system.
Comment 1 Tim-Philipp Müller 2012-09-29 12:29:55 UTC
Quite a bit of work has been done on the MPEG-TS demuxers recently, so it would be good if you could test this again with GStreamer 1.0.0 (or a newer GStreamer 0.10.x, but the problem is that we are using a new MPEG-TS demuxer now which wasn't plugged by default in 0.10 yet, so any testing with 0.10.x is less useful).

So could you re-test with 1.0? (gst-discoverer-1.0 /path/to/foo.ts would do for testing too, you don't have to port your code)

Alternatively, if the file is available somewhere I could take a look as well, feel free to e-mail me a link. But I understand it's big so it might not be possible.
Comment 2 Tim-Philipp Müller 2012-10-18 10:49:01 UTC
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for.
Thanks!