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 331802 - OSSSink Functional Issues on Embedded Platforms
OSSSink Functional Issues on Embedded Platforms
Status: RESOLVED INCOMPLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
0.10.1
Other All
: Normal critical
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2006-02-19 19:05 UTC by John Doe
Modified: 2006-05-17 15:01 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description John Doe 2006-02-19 19:05:45 UTC
Please describe the problem:
Having trouble using osssink on an embedded platform.  Audio stops playback
completely during the middle of the stream, and AV sync is slightly off (~1 sec). 

Using custom demux, video decoder, and videosinks along w/ mad and osssink
plugins.   Have written a custom audiosink which doesn't inherit the
GstAudioBaseSink and GstAudioSink classes, and the audio output is present
throughout the entire playback.    However, AV sync is off in this case as well.  



Steps to reproduce:
1. Run pipeline w/ the following:

gst-launch-0.10 filesrc location=/media/file ! demux name=demux ! queue ! mad !
osssink demux. ! queue ! videodec ! videosink

Actual results:
Video and Audio playback fine (w/ slight AV sync issue mentioned above) for a ~2
minutes, but then audio playback stops completely and there is no audio output.  

Expected results:
Audio and Video to playback in perfect synchronization for the entire duration
of the file.  

Does this happen every time?
Yes.

Other information:
Please download the debug output (ran with GST_DEBUG=*sink:5 to get osssink,
basesink and baseaudiosink debug categories) from here:

http://www2.uploadready.com/v/540624/1output_bug.tar.bz2.html
Comment 1 Jan Schmidt 2006-03-03 18:39:27 UTC
I can't reproduce the problem here, but I'm not on an 'embedded platform'. It sounds most like your demuxer might not be outputting the right newsegment information, such as issuing different segments to different streams.

What format are you decoding?

Does this thread on the mailing list help you at all?

http://thread.gmane.org/gmane.comp.video.gstreamer.devel/14859

Comment 2 Tim-Philipp Müller 2006-03-25 12:46:39 UTC
Are you sure your decoders/demuxers set correct timestamps (and correct offsets if offsets are set at all) on the outgoing buffers?

This doesn't really look right to me:

DEBUG (0x8b710 - 0:00:02.470616000)             basesink( 2342) gstbasesink.c(621):gst_base_sink_handle_object:<osssink0> received NEWSE
GMENT 0:00:00.180000000 -- 5124095:34:33.709551615, time 0:00:00.180000000, accum 0:00:00.000000000

DEBUG (0x8b710 - 0:01:58.544665000)             basesink( 2342) gstbasesink.c(651):gst_base_sink_handle_object:<osssink0> got times star
t: 0:00:51.396000000, end: 0:00:51.420000000

After ~1:56 real time the stream time has only advanced ~51 seconds. My first guess would be that either your timestamps are wrong or the CPU can't keep up and the buffers arrive too late at some point.
Comment 3 Tim-Philipp Müller 2006-05-17 15:01:57 UTC
Assuming this was an bug in the custom demuxer/decoder.

Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for.
Thanks!