From: SourceForge.net <no...@so...> - 2006-09-18 14:28:51
|
Bugs item #1560780, was opened at 2006-09-18 07:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109655&aid=1560780&group_id=9655 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: win32 codecs Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: eventual hang grabbing DMO a/v frames Initial Comment: I wrote a minimal application to grab frames from a WMA stream with component a/v parts, using the xine_get_next_*_frame() functions of xinelib 1.1.2. The application opens and runs the stream, then grabs audio and video frames according to a simple alogrithm, taking a frame from the part with the smallest last timestamp. In this fashion it runs for about ten hours, until a call to either the get_next_audio or get_next_video function hangs, leaving the program waiting indefinately. This happens consistently. I am submitting this as a bug, as the problem seems to reside in the xine library, and I'm wondering if anyone has had similar issues decoding WMA streams. I'm unsure whether this is a win32 codec bug, or an issue with the xine get_next functionality. Please ask for information, or logs or examples of the code I'm using, if anything might help diagnose the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109655&aid=1560780&group_id=9655 |