This patch does the following:
- Introduces an owned_critical_section object to be able to assert that a
current thread owns a critical section
- Change the auto_lock to use the above, add auto_unlock (basically like the
Gecko AutoEnter/AutoExit things)
- Fix an issue during audio output device switch where the clock would use the
old sample rate. Apparently I did not notice this because my headset and the
sound card on this laptop have the same rate
- Check that we could acquire a device_enumerator in the ctor before
deallocating in the dtor, as that can happen if a ton of streams are running at
once (I had this issue running the full mochitest suite)
- Stop getting another device_enumator in unregister_notification_client, fixing a leak
- Assert that setup_wasapi_stream and close_wasapi_stream are called with the lock held, this was the cause of the crash for this bug
- Make close_wasapi_stream clear out its state to make sure setup_wasapi_stream
and close_wasapi_stream are called in the right order (especially, not two
setup_wasapi_stream without close in between, since that would leak stuff)
- In wasapi_stream_destroy, unregister the notification client before destroying
the CRITICAL_SECTION (this was the cause of a crash I duped against this bug)
This patch does the following:
- Introduces an owned_critical_section object to be able to assert that a
current thread owns a critical section
- Change the auto_lock to use the above, add auto_unlock (basically like the
Gecko AutoEnter/AutoExit things)
- Fix an issue during audio output device switch where the clock would use the
old sample rate. Apparently I did not notice this because my headset and the
sound card on this laptop have the same rate
- Check that we could acquire a device_enumerator in the ctor before
deallocating in the dtor, as that can happen if a ton of streams are running at
once (I had this issue running the full mochitest suite)
- Stop getting another device_enumator in unregister_notification_client, fixing a leak
- Assert that setup_wasapi_stream and close_wasapi_stream are called with the lock held, this was the cause of the crash for this bug
- Make close_wasapi_stream clear out its state to make sure setup_wasapi_stream
and close_wasapi_stream are called in the right order (especially, not two
setup_wasapi_stream without close in between, since that would leak stuff)
- In wasapi_stream_destroy, unregister the notification client before destroying
the CRITICAL_SECTION (this was the cause of a crash I duped against this bug)
Timestamp Offset calculations are now done exclusively by the Media Source
components which allow to recalculate them on the fly. By abstracting those
offsets it remove the need for the sub-decoders to handle them (which allows
to add WebM support).
This buffer is unsused for fragmented MP4. So we don't need to unecessarily
allocate it and block a chunk of 3MB data. Also, this removes the restriction
of playing YouTube video > 1080p
