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 626637 - gnlcomposition hangs while merging two fragments of MPEG2 file
gnlcomposition hangs while merging two fragments of MPEG2 file
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gnonlin
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
Edward Hervey
Depends on:
Blocks:
 
 
Reported: 2010-08-11 15:30 UTC by Vladimir Eremeev
Modified: 2014-12-15 16:18 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
code (7.66 KB, application/octet-stream)
2010-08-11 15:30 UTC, Vladimir Eremeev
Details
Log of the program run with --gst-debug=gnl*:5 (10.36 KB, application/x-gzip)
2010-08-11 15:32 UTC, Vladimir Eremeev
Details
Messages from the program's stdout (produced with g_print) (15.25 KB, text/plain)
2010-08-11 15:38 UTC, Vladimir Eremeev
Details
zipfile with 2 c programs, performing the segment seeks, as described in the previous comment (3.77 KB, application/zip)
2010-08-12 11:06 UTC, Vladimir Eremeev
Details

Description Vladimir Eremeev 2010-08-11 15:30:46 UTC
Created attachment 167612 [details]
code

Trying to cut two fragments of the mpeg2 PS file and merge them together in the mpeg2PS file.
The first fragment is from 5th to 10th second, and the second one is from 120 to 125 second.

So, the resulting file should be 10 seconds long.

The first fragment is saved, the second is not, and the program never ends.

If I comment out the lines, dealing with the second fragment, I get a valid file of 5 seconds.

The attached code runs g_main_loop in a separate thread, this is done by intent. Nothing changes if I simply put g_main_loop_run into the main()
Comment 1 Vladimir Eremeev 2010-08-11 15:32:38 UTC
Created attachment 167613 [details]
Log of the program run with --gst-debug=gnl*:5
Comment 2 Vladimir Eremeev 2010-08-11 15:38:19 UTC
Created attachment 167615 [details]
Messages from the program's stdout (produced with g_print)
Comment 3 Vladimir Eremeev 2010-08-11 15:39:36 UTC
The last line (position: [0:00:04.991988889/0:00:10.000000000]) seems to repeat forever.
Comment 4 Vladimir Eremeev 2010-08-11 15:44:23 UTC
Full debug log (--gst-debug=5) was 22.5Mb, even when bzip2-ed, and bugzilla didn't accept it.
Comment 5 Vladimir Eremeev 2010-08-12 11:04:58 UTC
Also tried creating simple pipelines and perform segment seeks.

1. filesource -> mpegpsdemux -> multiqueue -> mpegpsmux -> filesink
2. uridecodebin -> multiqueue -> twolame  ->
                              -> mpeg2enc -> mpegpsmux -> filesink

Segment seeks were the following

rs=gst_element_seek(pipeline,
   1.0,
   GST_FORMAT_TIME,
   GST_SEEK_FLAG_FLUSH|GST_SEEK_FLAG_ACCURATE|GST_SEEK_FLAG_SEGMENT,
   GST_SEEK_TYPE_SET,
   5LL*GST_SECOND,
   GST_SEEK_TYPE_SET,
   15LL*GST_SECOND
);

In both cases the resulting file was 10 second long and contained 5th though 15th seconds of the source clip.
Comment 6 Vladimir Eremeev 2010-08-12 11:06:52 UTC
Created attachment 167717 [details]
zipfile with 2 c programs, performing the segment seeks, as described in the previous comment
Comment 7 Thibault Saunier 2014-12-15 16:18:18 UTC
Tried to do that with NLE/ges-launch and it works no, closing as obselete.