https://msdn.microsoft.com/en-us/library/windows/desktop/dd797815(v=vs.85).aspx
Relax the resolution limitation from "width <= 4096 and height <= 2304" to "any width and height combination as long as the total pixel count is under 4096x2304".
MozReview-Commit-ID: 5wHiJfLaJkp
--HG--
extra : rebase_source : 11bf99d0eb3b50ea0199a7f65e0491e43318d29c
Otherwise we will seek to a position beyond the duration when exiting dormant
which will fail an assertion in OggDemuxer.
MozReview-Commit-ID: FPWKyd8APrj
--HG--
extra : rebase_source : 89b8cbcfbf9a63d428b9d2a513b2656fc241892f
extra : source : d6a0a81abc7781b6620777ab4cf44222942d78bd
webrtc.org only supports one-byte rtp header extensions which means
we can only support 16 character mids for now.
MozReview-Commit-ID: C7aTeB5Bi2M
--HG--
extra : rebase_source : e25518d02fb056f82d298f000e37cfe059099a38
It is not needed since we are already in the right context.
MozReview-Commit-ID: 6QXxLMQHavv
--HG--
extra : rebase_source : d7a80d3e3d6583bd1732a4048f40576603e83872
extra : source : d700cc52ce2a50a784601f7cff7f63eaff3efced
We also need to call GetOwner()->UpdateReadyState() since mCanPlayThrough might
have changed.
MozReview-Commit-ID: C5djzu1sXqV
--HG--
extra : rebase_source : 1037cb7e1bf3a32fa60451e9a2a64ce63d06b8c2
extra : intermediate-source : 373c47f094dfb85ca2576d18a302d9ceb4e82ed5
extra : source : b710ff5026c18ac851be56ac9a369fe69b1d5b5d
See comment 20 for the root cause.
We wait for both 'seeked' and 'ended' events to fire to make sure playback
has reached the end before calling play().
MozReview-Commit-ID: 55NEmqyDuSI
--HG--
extra : rebase_source : 3e1eda99e7fee247ea18c4fd4420f00338710b09
SetState() will delete the current state object and UAF will happen if members
are accessed after this call. However, sometimes it is not obvious if SetState()
is called indirectly as we do in MaybeFinishSeek().
To make it less error-prone, we will keep the old state object alive for a bit
longer and set mMaster to null to catch potential UAF.
MozReview-Commit-ID: Aqxj92ETjti
--HG--
extra : rebase_source : 21b4a0b6df2b1723eed01b6c9d58b33b8dcc6405
mOffset is important for MediaCache to evaluate the playback rate in bytes for
a live stream. Failing to set this field (initially 0) will cause MediaCache to
assume very low playback rate (in bytes) and not to download enough bytes for
decoder to consume without underflow.
This issue is manifested by bug 1427527 where a live ogg stream is played.
MozReview-Commit-ID: JiaXtpWCl09
--HG--
extra : rebase_source : af5928fd616058d4cbe1679e4ed2149641795b89
extra : intermediate-source : e31743f828f783845ad13fbbb23fb0b6af8ccb45
extra : source : 4ea2a67444f783724d9151be4f08878b50895a54
Note we add mClient->CacheClientSuspend() so the network state of the element
is changed to IDLE because we have no channel to fetch data initially.
MozReview-Commit-ID: DgJbMxvJBzH
--HG--
extra : rebase_source : 69a3ef35d4b5faaaa645fabe02246d49aebce22e
extra : source : 61ec40ce378a444ec0f74d474c28b6a9db3aa830
This is required by P2 where we want to notify the 'suspend' event for a cloned
resource whose mChannel is initially null.
MozReview-Commit-ID: 3znDl2TqlqK
--HG--
extra : rebase_source : 71c3d6dc2052566b6bfb0879ce56b804312c5a37
extra : source : e6b7cb7937c80420ad2725c5a77143c7a071150f
It is bad to modify the array while iterating it.
MozReview-Commit-ID: JbpoRmM7GqP
--HG--
extra : rebase_source : 92523a0741aa6014808b182954f653fce54161fd
Since we now never take the lock on the main thread, we can safely do file IO
while holding the lock without blocking the main thread.
This reverts the change of Bug 1354389 P1.
MozReview-Commit-ID: EhEwTjINQIT
--HG--
extra : rebase_source : 7eca1226d53a26025188e01837de645a1c879d7b
PinForSeek() is called only when playback reaches the end. In other words,
it is not called for most cases of seeking. It should be OK not to call it at
all during seeking.
MozReview-Commit-ID: 1xXX1321bO7
--HG--
extra : rebase_source : c362d0ac18f44862da9b0593ad85ebfc56416325
extra : intermediate-source : 0a70419f9ce639ac0784a0632db4598d6be511f8
extra : source : bfddad9b922386c91fcfa7657a7ac274991d15f4
v.ended is set to true before the 'ended' event is fired. Then we can simplify
the code by asserting seekToNextFrame() should never be rejected.
MozReview-Commit-ID: 5fB2QuboU0I
--HG--
extra : rebase_source : f9d423919e3fe6e34eaff1b4603398e66eaa594e
PinForSeek() is called only when playback reaches the end. In other words,
it is not called for most cases of seeking. It should be OK not to call it at
all during seeking.
MozReview-Commit-ID: 1xXX1321bO7
--HG--
extra : rebase_source : df8ba3f59da2a337b456546af4b54abaddfe38a9
extra : intermediate-source : 0a70419f9ce639ac0784a0632db4598d6be511f8
extra : source : bfddad9b922386c91fcfa7657a7ac274991d15f4
v.ended is set to true before the 'ended' event is fired. Then we can simplify
the code by asserting seekToNextFrame() should never be rejected.
MozReview-Commit-ID: 5fB2QuboU0I
--HG--
extra : rebase_source : b8662773ec6bd0c9292666d1aa29a48cb860b22b
So we won't need to take the cache monitor on the main thread.
MozReview-Commit-ID: FavZKcfaHn8
--HG--
extra : rebase_source : 8a0483a5db9db3d39dccf110ba363144f5e9b6dd
extra : intermediate-source : 214edc1ef96cc2f8b60a86ce068cb8b0593cb1f7
extra : source : ce13b43e884185a988205d0f3e860cf823458b37
We should call ChannelMediaResource::CacheClientNotifyDataReceived() no matter
new data is coming from the channel or copied from the original cache stream
so the decoder has a chance to compute 'canplaythrough' and buffer ranges.
MozReview-Commit-ID: I4cLow2VzJg
--HG--
extra : rebase_source : ede936c94a6d728cf6c596863e45aa45d2617d45