[Bug 700505] Video corruption when dashdemux changes bitrate

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Fri Jun 14 15:48:43 PDT 2013


https://bugzilla.gnome.org/show_bug.cgi?id=700505
  GStreamer | gst-plugins-bad | git

--- Comment #18 from Greg Rutz <greg at gsr-tek.com> 2013-06-14 22:48:37 UTC ---
Using A Ashley's patch, I was able to make one additional change to get
improved performance.  The problem you are seeing is that the qtdemux sends a
stream-start event for all streams after it parses the new MOOV.  I am not a
complete expert on clocks and timestamping in GStreamer, so I will probably
fumble this explanation a little bit.

The stream-start event causes the pipeline clock to reset.  However, the buffer
timestamps continue on from where they left off.  I see the following message
in the log from base_sink shortly after it receives the stream-start event:

0:00:14.543808931 12759 0xac7f6320 DEBUG               basesink
gstbasesink.c:3261:gst_base_sink_chain_unlocked:<xvimagesink0> got times start:
0:00:07.770433333, end: 0:00:07.803800000
0:00:14.543822958 12759 0xac7f6320 DEBUG               basesink
gstbasesink.c:1877:gst_base_sink_get_sync_times:<xvimagesink0> got times start:
0:00:07.770433333, stop: 0:00:07.803800000, do_sync 1
0:00:14.543836497 12759 0xac7f6320 DEBUG               basesink
gstbasesink.c:2450:gst_base_sink_do_sync:<xvimagesink0> reset rc_time to time
0:00:15.540866666
0:00:14.543845940 12759 0xac7f6320 DEBUG               basesink
gstbasesink.c:2462:gst_base_sink_do_sync:<xvimagesink0> possibly waiting for
clock to reach 0:00:15.540866666, adjusted 0:00:15.540866666
0

I am attaching a patch that is a TOTAL HACK.  But I think it at least proves
where the problem is.  I'll probably need some guidance from some of you out
there about where to go from here.  I'm not sure if the stream-start event is
really the problem, or if the buffer timestamps are the ones that need
altering.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.


More information about the gstreamer-bugs mailing list