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 688091 - tsdemux: multiple seeking-related fixes
tsdemux: multiple seeking-related fixes
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
1.x
Other Linux
: Normal normal
: 1.0.3
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2012-11-11 13:11 UTC by Josep Torra Valles
Modified: 2012-11-15 12:20 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Josep Torra Valles 2012-11-11 13:11:23 UTC
At [1] I've uploaded multiple fixes for tsdemux in order to be able to handle upstream seeks.

There's still a missing piece about how to forward upstream segment event that I don't know how to address it.

Please could you provide some advice?

[1] http://cgit.freedesktop.org/~adn770/gst-plugins-bad/log/?h=tsdemux
Comment 1 Edward Hervey 2012-11-12 10:32:57 UTC
The two first (chronological) commits could do with a couple more lines in the commit messages.

Otherwise : yes to push the 4 commits.
Comment 2 Josep Torra Valles 2012-11-12 22:24:53 UTC
I've pushed the reviewed four patches but I will keep the bug open until I will be able to address the issues in forwarding the segment event.

As far I understood unref the segment_event in tsdemux won't be enough as the new segment data is in base->segment and it's only copied into tsdemux->segment when the program is started or the program changes.

So something more needs to be done in order to push the upstream segment in time after a seek in calculate_and_push_newsegment.

Please could you provide some guidance on how to handle it?
Comment 3 Josep Torra Valles 2012-11-13 21:58:08 UTC
I've pushed another change to be reviewed in my branch.

It fixes seeking in the timeshift scenario but I'm not sure if this is the right change.
Comment 4 Josep Torra Valles 2012-11-15 09:59:30 UTC
Last change already pushed after reviewing it at #gstreamer,

The bug can be closed now.
Comment 5 Edward Hervey 2012-11-15 10:03:09 UTC
commit 3d012665f06797cd2cd3c7c2f4df7144319b44ce
Author: Josep Torra <n770galaxy@gmail.com>
Date:   Tue Nov 13 22:40:25 2012 +0100

    tsdemux: forward upstream time segments after flushes
    
    Also reset segment info and drop the segment event when demuxer is
    flushed.
    Restore demuxer segment with the info stored in base when demuxer is
    going to push data again if needed.
    Drop code to recover the segment info from base in the initial program
    becauses it's superseded by the new code.

commit 0b3e0ed080fabe87ead446609bc688f5279437ee
Author: Josep Torra <n770galaxy@gmail.com>
Date:   Sun Nov 11 12:46:43 2012 +0100

    tsdemux: reset the stream some more in the flushes
    
    Now that we handle flushing in the FLUSH_STOP event we need to make
    the streams ready if they were flushing.

commit 150376efe476f4b9ea6c6cef54af1399cf6f478e
Author: Josep Torra <n770galaxy@gmail.com>
Date:   Sun Nov 11 12:45:03 2012 +0100

    mpegtspacketizer: flush observations too
    
    Flush the previous observations when the packetizer is flushed.
    Also don't leak them in the dispose.

commit 1fc5fffe088ffdd838b0f36b19e5741c32a5240a
Author: Josep Torra <n770galaxy@gmail.com>
Date:   Sat Nov 10 20:44:44 2012 +0100

    mpegtsbase: fix double unref of seek event

commit cc40d49beda0eaf0b8acd64fb16342c2832ce453
Author: Josep Torra <n770galaxy@gmail.com>
Date:   Sat Nov 10 20:30:13 2012 +0100

    mpegtsbase: flush in FLUSH_STOP to avoid race conditions
    
    Ensure the chain is not running before reset the state to avoid race
    conditions and random corruptions downstream.
    Also fixes segfaults in the packetizer due wrong available values that
    causes gst_adapter_map to return a NULL pointer.