Sat 12 Feb 2011 08:57:49 PM UTC, comment #11:
swfdec testsuite completes successfully on all buildbot slaves.
|
Thu 12 Mar 2009 11:03:16 PM UTC, comment #10:
late, but...
Yes, the parser thread must set _audioInfo and _videoInfo.
There is no mutex currently, there should be one.
Indeed there's a pending race condition in FLVParser
where a thread might be using _audioInfo while being constructed.
|
Sat 28 Feb 2009 12:53:41 PM UTC, comment #9:
Sandro, you said the probe is not required anymore, although it looks to me like the ffmpeg handler still does. At any rate, if we do skip the probe in the constructor, then the parser thread must set _audioInfo and _videoInfo. Is there a mutex available for setting / reading those?
|
Mon 09 Feb 2009 02:07:34 PM UTC, comment #8:
Can't test atm, but it was thread-related so won't be easy
to reproduce. Read Bastiaan explanation of the reasons
why that assertion could fail, might give you ideas on how
to produce a simplified testcase (not automatable unfortunately
as long as we use threads).
|
Mon 09 Feb 2009 01:42:09 PM UTC, comment #7:
Is this still a problem? I can't reproduce it, but I don't know if any code has changed since the bug was reported.
|
Fri 28 Nov 2008 12:33:34 AM UTC, comment #6:
Oh, the probe is not required anymore.
Still, the thread starts...
|
Fri 28 Nov 2008 12:30:13 AM UTC, comment #5:
Within the context of MediaParserGst it would be a hack.
I think instead we should stop probing in the MediaParserGst constructor so we won't end up with orphaned frames (i.e., the assertion).
|
Thu 27 Nov 2008 10:05:33 PM UTC, comment #4:
I don't see how that's an hack really.
Is it disallowed to create a MediaParser and destroy before
data gets loaded ? Seem perfectly legal to me (fully AS-driven)
|
Thu 27 Nov 2008 07:58:51 PM UTC, comment #3:
The potential culprit here is a case where the media parser gets destroyed immediately after it is created. That means that parseNextChunk will never be called and thus we end up with audio frames that were never transferred to the base class.
The easy way to fix this bug is to remove the assertions and delete the contents of the audio and video deques. But that would be a hack.
|
Wed 26 Nov 2008 09:24:08 AM UTC, comment #2:
To be clearer, the thread involved does both loading and parsing.
The assertion failing is tagged as being a sanity check:
// Sanity check for threading bug...
assert(_enc_video_frames.empty());
assert(_enc_audio_frames.empty());
|
Wed 26 Nov 2008 09:22:30 AM UTC, comment #1:
Oh... it's not always reproducible.
Only thread involved is loading of an external mp3 file.
|
Wed 26 Nov 2008 09:21:23 AM UTC, original submission:
This I get in make check while running an swfdec set of tests:
lt-gprocessor: /usr/src/gnash/gnash-head/libmedia/gst/MediaParserGst.cpp:125: virtual gnash::media::gst::MediaParserGst::~MediaParserGst(): Assertion `_enc_audio_frames.empty()' failed.
The tests are loadSound-matrix-repeat-#.swf.
|