Skip to content

VPAAMP-785: Fix pre-tune (and post-tune) seek failures with mp4demux + PTS restamp#1752

Open
pstroffolino wants to merge 2 commits into
dev_sprint_25_2from
feature/VPAAMP-785
Open

VPAAMP-785: Fix pre-tune (and post-tune) seek failures with mp4demux + PTS restamp#1752
pstroffolino wants to merge 2 commits into
dev_sprint_25_2from
feature/VPAAMP-785

Conversation

@pstroffolino

Copy link
Copy Markdown
Contributor

Skip appsrc-level seek when using mp4demux with PTS restamp enabled. Segments already have correct PTS via fragmentPTSoffset, so the gst_element_seek_simple() on appsrc is unnecessary and causes pipeline preroll failure when seeking to non-zero positions.

Root Cause:

  • Pre-tune seek to non-zero position (e.g., 20s) with mp4demux + PTS restamp
  • DoEarlyStreamSinkFlush sets pendingSeek=true on READY pipeline
  • SendGstEvents() performs gst_element_seek_simple() on appsrc to 20s
  • Segments arrive with PTS=20s (via mp4demux fragmentPTSoffset)
  • Mismatch between seek position and segment PTS prevents preroll
  • Pipeline stuck in READY state, never reaches PAUSED
  • appsrc reports "not-linked" error, tune stalls

Fix:

  • Skip appsrc seek in SendGstEvents() when isMp4DemuxPlayback && enablePTSReStamp
  • Segments already have correct PTS, no seek needed for preroll
  • Post-tune seeks unaffected (use pipeline-level seek in Flush())

Benefits:

  • Fixes pre-tune seek to non-zero position
  • Fixes multi-period seeks requiring pipeline reconfiguration
  • Fixes period transitions with PTS discontinuities
  • No impact on post-tune seeks or other configurations

Testing:

  • Pre-tune seek to 20s: PASS (was failing)
  • Multi-period seeks: PASS (was failing in some cases)
  • Post-tune seeks: PASS (unchanged)
  • Playing from start: PASS (unchanged)

Skip appsrc-level seek when using mp4demux with PTS restamp enabled.
Segments already have correct PTS via fragmentPTSoffset, so the
gst_element_seek_simple() on appsrc is unnecessary and causes
pipeline preroll failure when seeking to non-zero positions.

Root Cause:
- Pre-tune seek to non-zero position (e.g., 20s) with mp4demux + PTS restamp
- DoEarlyStreamSinkFlush sets pendingSeek=true on READY pipeline
- SendGstEvents() performs gst_element_seek_simple() on appsrc to 20s
- Segments arrive with PTS=20s (via mp4demux fragmentPTSoffset)
- Mismatch between seek position and segment PTS prevents preroll
- Pipeline stuck in READY state, never reaches PAUSED
- appsrc reports "not-linked" error, tune stalls

Fix:
- Skip appsrc seek in SendGstEvents() when isMp4DemuxPlayback && enablePTSReStamp
- Segments already have correct PTS, no seek needed for preroll
- Post-tune seeks unaffected (use pipeline-level seek in Flush())

Benefits:
- Fixes pre-tune seek to non-zero position
- Fixes multi-period seeks requiring pipeline reconfiguration
- Fixes period transitions with PTS discontinuities
- No impact on post-tune seeks or other configurations

Testing:
- Pre-tune seek to 20s: PASS (was failing)
- Multi-period seeks: PASS (was failing in some cases)
- Post-tune seeks: PASS (unchanged)
- Playing from start: PASS (unchanged)

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Fixes a GStreamer preroll failure during pre-tune seeks to non-zero positions when using the mp4demux playback path with PTS re-stamping enabled, by avoiding an appsrc-level seek that can conflict with already-restamped segment timestamps.

Changes:

  • Skip gst_element_seek_simple() on appsrc when isMp4DemuxPlayback && enablePTSReStamp and seekPosition > 0.
  • Add an informational log when the appsrc-level seek is intentionally skipped.

Comment on lines +2453 to +2454
if(gstPrivateContext->seekPosition > 0 &&
!(gstPrivateContext->isMp4DemuxPlayback && enablePTSReStamp))
Comment on lines +2451 to 2455
// Skip appsrc seek when using mp4demux with PTS restamp - segments already have correct PTS
// Post-tune seeks use pipeline-level seek in Flush() which works correctly
if(gstPrivateContext->seekPosition > 0 &&
!(gstPrivateContext->isMp4DemuxPlayback && enablePTSReStamp))
{
… restamp

Initialize mPTSOffset to -seekPosition instead of 0 to shift media PTS
down to start from 0 for playback. This fixes the delay issue where
seeking to position N caused an N-second delay before video appeared.

Root Cause:
- Pre-tune seek to 20s with mp4demux + PTS restamp enabled
- mPTSOffset initialized to 0.0
- Media segments arrive with PTS starting at 20s (raw media PTS)
- GStreamer waits 20 seconds of clock time before rendering
- User sees black screen for 20 seconds, then video starts at 20s

Fix:
- Initialize mPTSOffset = -seekPosition (e.g., -20.0 for seek to 20s)
- fragmentPTSoffset passed to mp4demux = -20.0
- Segments with raw PTS=20s get offset: 20 + (-20) = 0
- GStreamer renders immediately, video starts playing right away

Benefits:
- Fixes pre-tune seek delays (seek to 20s no longer has 20s delay)
- Fixes seek to any position (5s, 10s, 20s, etc.)
- Single-period DASH streams work correctly
- Multi-period pre-tune seeks work correctly

Testing:
- Pre-tune seek to 20s: PASS (was 20s delay, now immediate)
- Pre-tune seek to 5s: PASS (was 5s delay, now immediate)
- Playing from start (seek 0): PASS (unchanged)

Note: Post-tune multi-period seeks may still need additional fixes
in DoEarlyStreamSinkFlush/Flush logic (separate issue).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants