GNOME Bugzilla – Bug 750747
splitmuxtest sometimes fails
Last modified: 2015-06-23 02:05:28 UTC
make elements/splitmux.forever And after some iterations: elements/splitmux.c:190:F:general:test_splitmuxsink:0: Expected 3 output files, got 2
Any chance you could try and get a debug log as well? :) (I've been running .forever for half an hour here, and it's still going)
Created attachment 305040 [details] log with GST_DEBUG=*split*:9 From a quick look at the log, it looks like the sink failed to create the files correctly.. I had another failure where the test_playback after at the end of the sink test failed to open the files. I included two runs in log, the first is successful, the second isn't
For the failed runs, the tmp dir only contains two files instead of 3, so it's definitely a bug in the sink.
Created attachment 305042 [details] [review] splitmuxsink: Take released-but-not-yet-output bytes into account When deciding whether it's time to switch to a new file, take into account data that's been released for pushing, but hasn't yet been pushed - because downstream is slow or the threads haven't been scheduled. Fixes a race in the unit test and probably in practice - sometimes failing to switch when it should for an extra GOP or two.
Classic - make elements/splitmux.forever ran for 10 minutes and then failed the exact moment the 'git bz attach' command finished. 50%: Checks: 2, Failures: 1, Errors: 0 elements/splitmux.c:190:F:general:test_splitmuxsink:0: Expected 3 output files, got 2 I'll try again.
Created attachment 305071 [details] [review] splitmuxsink: Take released-but-not-yet-output bytes into account When deciding whether it's time to switch to a new file, take into account data that's been released for pushing, but hasn't yet been pushed - because downstream is slow or the threads haven't been scheduled. Fixes a race in the unit test and probably in practice - sometimes failing to switch when it should for an extra GOP or two. Also fix a problem in splitmuxsrc where playback sometimes stalls at startup if types are found too quickly.
This seems to make things better, but I sometimes get a stall inside playbin when playing back the files, so I can't be completely sure. Not sure what the playback stall is yet.
Comment on attachment 305071 [details] [review] splitmuxsink: Take released-but-not-yet-output bytes into account Pushed this one, as it seems to address the bug, even if there's something else lurking in splitmuxsrc somewhere. Please check and report back if things seem better for you?
Created attachment 305883 [details] [review] splitmuxsink: Mask async-start/done while switching files. Sometimes, extra async-start/done from the internal sink while the element is still starting up can cause splitmuxsink to stall in PAUSED state when it has been set to PLAYING by the app. Drop the child's async-start/done messages while switching, so they don't cause state changes at the splitmuxsink level.
Created attachment 305884 [details] [review] splitmuxsrc: Fix startup and shutdown races. Fix 2 startup races when things happen too quickly, and 1 at shutdown by holding a ref to the pads in use until the loop functions exit. Handle errors activating file parts and publish them on the bus.
With these 2 patches, I ran 168000 iterations of the unit test without failure.