Bug 1545108 Comment 3 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

As we've ensured that the samples which are pushed into media queue would always be not a nullptr [1], so I'm looking for if there is any chance the data was freed before popped out.

And I found that the ref-counting for the `MediaData` is kind of tricky. The `AudioQueue` holds a raw point to data [2], not a ref counting. So after pushing data into queue, it seems that the only place inside the media queue keeping data alive is here [3].  

So after `MediaEventListener` notify the event which would hold the reference to data, there seems no any other place to keep this data alive? (if the data was not popped out during the push event)

In `AudioSink` case, it would pop out the data when it received the push event [5], which has kept the reference to data. So the strong reference is always kept between pushing and poping data.

However, in `DecodedStream` case, it won't pop data directly [6], it would pop the data until the `DecodedStream::NotifyOutput` is called [7]. So, who is keeping the reference between pushing and poping data in this case? I couldn't find it, but I'm sure there is one place to keep the reference, otherwise, `DecodedStream` could not be able to work (I just couldn't find it)

[1] https://searchfox.org/mozilla-central/rev/ec489aa170b6486891cf3625717d6fa12bcd11c1/dom/media/MediaQueue.h#45-47
[2] https://searchfox.org/mozilla-central/rev/ec489aa170b6486891cf3625717d6fa12bcd11c1/dom/media/MediaDecoderStateMachine.h#559
[3] https://searchfox.org/mozilla-central/rev/ec489aa170b6486891cf3625717d6fa12bcd11c1/dom/media/MediaQueue.h#49
[4] https://searchfox.org/mozilla-central/rev/ec489aa170b6486891cf3625717d6fa12bcd11c1/dom/media/mediasink/AudioSink.cpp#333
[5] https://searchfox.org/mozilla-central/rev/ec489aa170b6486891cf3625717d6fa12bcd11c1/dom/media/mediasink/AudioSink.cpp#319
[6] https://searchfox.org/mozilla-central/rev/ec489aa170b6486891cf3625717d6fa12bcd11c1/dom/media/mediasink/DecodedStream.cpp#539-583
[7] https://searchfox.org/mozilla-central/rev/ec489aa170b6486891cf3625717d6fa12bcd11c1/dom/media/mediasink/DecodedStream.cpp#809
As we've ensured that the samples which are pushed into media queue would always be not a nullptr [1], so I'm looking for if there is any chance the data was freed before popped out.

And I found that the ref-counting for the `MediaData` is kind of tricky. The `AudioQueue` holds a raw point to data [2], not a ref counting. So after pushing data into queue, it seems that the only place inside the media queue keeping data alive is here [3].  

So after `MediaEventListener` notifies the event, which would hold the reference to data, there seems no any other place to keep this data alive? (if the data was not popped out during the push event)

In `AudioSink` case, it would pop out the data when it received the push event [5], which has kept the reference to data. So the strong reference is always kept between pushing and poping data.

However, in `DecodedStream` case, it won't pop data directly [6], it would pop the data until the `DecodedStream::NotifyOutput` is called [7]. So, who is keeping the reference between pushing and poping data in this case? I couldn't find it, but I'm sure there is one place to keep the reference, otherwise, `DecodedStream` could not be able to work (I just couldn't find it)

[1] https://searchfox.org/mozilla-central/rev/ec489aa170b6486891cf3625717d6fa12bcd11c1/dom/media/MediaQueue.h#45-47
[2] https://searchfox.org/mozilla-central/rev/ec489aa170b6486891cf3625717d6fa12bcd11c1/dom/media/MediaDecoderStateMachine.h#559
[3] https://searchfox.org/mozilla-central/rev/ec489aa170b6486891cf3625717d6fa12bcd11c1/dom/media/MediaQueue.h#49
[4] https://searchfox.org/mozilla-central/rev/ec489aa170b6486891cf3625717d6fa12bcd11c1/dom/media/mediasink/AudioSink.cpp#333
[5] https://searchfox.org/mozilla-central/rev/ec489aa170b6486891cf3625717d6fa12bcd11c1/dom/media/mediasink/AudioSink.cpp#319
[6] https://searchfox.org/mozilla-central/rev/ec489aa170b6486891cf3625717d6fa12bcd11c1/dom/media/mediasink/DecodedStream.cpp#539-583
[7] https://searchfox.org/mozilla-central/rev/ec489aa170b6486891cf3625717d6fa12bcd11c1/dom/media/mediasink/DecodedStream.cpp#809
As we've ensured that the samples which are pushed into media queue would always be not a nullptr [1], so I'm looking for if there is any chance the data was freed before popped out.

And I found that the ref-counting for the `MediaData` is kind of tricky. The `AudioQueue` holds a raw point to data [2], not a ref counting. So after pushing data into queue, it seems that the only place inside the media queue keeping data alive is here [3].  

So after `MediaEventListener` notifies the event, which would hold the reference to data, there seems no any other places to keep this data alive? (if the data was not popped out during the push event)

In `AudioSink` case, it would pop out the data when it received the push event [5], which has kept the reference to data. So the strong reference is always kept between pushing and poping data.

However, in `DecodedStream` case, it won't pop data directly [6], it would pop the data until the `DecodedStream::NotifyOutput` is called [7]. So, who is keeping the reference between pushing and poping data in this case? I couldn't find it, but I'm sure there is one place to keep the reference, otherwise, `DecodedStream` could not be able to work (I just couldn't find it)

[1] https://searchfox.org/mozilla-central/rev/ec489aa170b6486891cf3625717d6fa12bcd11c1/dom/media/MediaQueue.h#45-47
[2] https://searchfox.org/mozilla-central/rev/ec489aa170b6486891cf3625717d6fa12bcd11c1/dom/media/MediaDecoderStateMachine.h#559
[3] https://searchfox.org/mozilla-central/rev/ec489aa170b6486891cf3625717d6fa12bcd11c1/dom/media/MediaQueue.h#49
[4] https://searchfox.org/mozilla-central/rev/ec489aa170b6486891cf3625717d6fa12bcd11c1/dom/media/mediasink/AudioSink.cpp#333
[5] https://searchfox.org/mozilla-central/rev/ec489aa170b6486891cf3625717d6fa12bcd11c1/dom/media/mediasink/AudioSink.cpp#319
[6] https://searchfox.org/mozilla-central/rev/ec489aa170b6486891cf3625717d6fa12bcd11c1/dom/media/mediasink/DecodedStream.cpp#539-583
[7] https://searchfox.org/mozilla-central/rev/ec489aa170b6486891cf3625717d6fa12bcd11c1/dom/media/mediasink/DecodedStream.cpp#809

Back to Bug 1545108 Comment 3