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 342592 - dvdemux doesn't post segment-done right
dvdemux doesn't post segment-done right
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
0.10.3
Other Linux
: Normal normal
: 0.10.4
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2006-05-22 17:05 UTC by Michael Dominic K.
Modified: 2006-06-14 15:08 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch to implement eos correctly (3.11 KB, patch)
2006-05-24 08:51 UTC, Wim Taymans
committed Details | Review

Description Michael Dominic K. 2006-05-22 17:05:24 UTC
The dvdemux in 0.10.3 (good) doesn't post segment-done messages. Things used to work fine in 0.10.2 though.

That's against: 
gstreamer 0.10.6
gst-plugins-base 0.10.7
gst-plugins-good 0.10.3
Comment 1 Michael Dominic K. 2006-05-22 19:25:51 UTC
It happens only when the demuxer is operating in pull mode. When forced to push mode, it works fine. 
Comment 2 Wim Taymans 2006-05-24 08:51:16 UTC
Created attachment 66112 [details] [review]
patch to implement eos correctly
Comment 3 Edward Hervey 2006-05-24 09:14:23 UTC
seems correct to me. MDK can you test it and confirm ?
Comment 4 Wim Taymans 2006-05-24 16:04:08 UTC
        * ext/dv/gstdvdemux.c: (gst_dvdemux_loop):
        Implement EOS correctly by either posting
        SEGMENT_DONE or pushing an EOS message depending
        on the seek type. Fixes #342592
Comment 5 Michael Dominic K. 2006-05-27 15:30:22 UTC
I think it's still not right. 

Now it posts the segment-done with a huge delay. It looks like if the file is still "streaming" in the background somewhere (after the segment has been completed), and it posts the segment-done when the EOS has been reached. 

In other words -- the shorter the segment is, the longer the delay will be. For example, a 10s DV file:

Seeking 0s-9s segment will post the segment-done almost instantly.
Seeking 0s-1s will cause a long "wait" for the segment-done, when the actual streaming has been long stopped. 

In any case, the behaviour is very much different from the push-mode. 

Comment 6 Wim Taymans 2006-06-14 14:44:11 UTC
it actually just ignores the stop position and continues to demux/decode stuff till EOS, at which point is posts the segment done. It just needs to go EOS when the configured stop position is reached... fixing...
Comment 7 Wim Taymans 2006-06-14 15:08:19 UTC
This should fix it. There is something else wrong with the first timestamp produced after a seek in READY which I'm fixing next.

        * ext/dv/gstdvdemux.c: (gst_dvdemux_demux_frame):
        Respect segment.stop. Fixes #342592.