The spec [1] defines what's the media segment, and the parser would return error
if the format is not correct.
[1] https://w3c.github.io/media-source/webm-byte-stream-format.html
MozReview-Commit-ID: 4hq59Pywz2t
--HG--
extra : rebase_source : 1136d2a673f11d612e0eb711db6affdce42bb525
The spec [1] defines that
"Timecode (e7) MUST appear before Block (a1) or SimpleBlock (a3)".
[1] https://www.matroska.org/technical/specs/index.html
MozReview-Commit-ID: 7g8lgckuNif
--HG--
extra : rebase_source : 4945dc4b0ab4b7480bf9c6416f9776fd6313c1e1
CacheClientSeek() will call Seek() asynchronously and should be used by MediaCache only.
ChannelMediaResource::Resume() runs on the main thread and can call Seek() directly.
Note this is a missing change from bug 1411504 P3.
MozReview-Commit-ID: I2X1Rk5HoDV
--HG--
extra : rebase_source : 66dce75aefc4bfebecf69ebe107e9b4c9286f3a5
extra : source : 20e5463e15049095a941f501acd3fa7dd4e9b1db
Bug 1386489 means that ended is not reliably set in relation to the test
seeking machinery. This results in the following behaviour being possible:
- seekToNextFrame seeks to last frame
- the seek promise resolves and invokes check to see if video has ended
- ended is not yet set (race), so another seekToNextFrame is setup
- onended handler is invoked at some point (1st time)
- seekToNextFrame seeks again, remains at last frame
- oneended handler is invoked again due to the seek (2nd time)
- finish() has been called twice
This changeset should bandaid the above being possible.
MozReview-Commit-ID: BkskWUnaJQ9
--HG--
extra : rebase_source : 0108cf82a805136a87752d0128c1c0f2e7997ff6
Otherwise Seek() will continue to call OpenChannel() and hit null-deref for
mChannel is null.
MozReview-Commit-ID: 4nhbF9lUOSR
--HG--
extra : rebase_source : cb58448ddd9e68314b07e6160354d7be9ea2809a
extra : source : 4d50e2d60a4f9a5ababaaa5100b170dd64c73dbc
This is a fix to P3.
Since seek is performed asynchronously by CacheClientSeek(), it is possible
for OnStopRequest() to come before Seek(). Changing mChannelOffset will
cause MediaCacheStream::NotifyDataEnded() to update mStreamLength incorrectly.
mChannelOffset should only be changed in response to channel activities such
as NotifyDataStarted() and NotifyDataReceived().
However, if MediaCache::Update() calls CacheClientSeek() without updating
mChannelOffset, next Update() might make a wrong decision and call CacheClientSeek()
again which is bad. So we add a member mSeekTarget to track if there is a pending
seek on which the stream reading decisions will be made.
MozReview-Commit-ID: VWP0vdlEYM
--HG--
extra : rebase_source : ea0d85bcbcc5d14f1554ebff3d10981a5b17e18a
extra : source : 339b9323b583849ac88e39da19670f6b26772877
For it is not safe to access mStreams without the lock off the main thread.
MozReview-Commit-ID: DjVlhxgjVj5
--HG--
extra : rebase_source : b584fe59712430acd4528e6b6cd01ae86dc5761f
extra : source : d7fd550934bfe6967638e42acb076882611792dd
SetTransportSeekable() is always called after NotifyDataStarted().
This is slightly more efficient for we don't acquire the lock twice.
MozReview-Commit-ID: 9myolomriIQ
--HG--
extra : rebase_source : f33c3be978edacf45d8144af43f45c8ad5e7b53e
extra : source : 2cefaeb1adae7238b77d5e2d1287ae0d96d9f671
Capturing |this| only if |self| needs to appear more than twice in a lambda.
MozReview-Commit-ID: 38iYDznjgBH
--HG--
extra : rebase_source : 9471fd4519c5c5be6e6e10eb11db8eeb041327d1
According to FFmpeg documentation, the out parameter is "set to size of parsed buffer or zero if not yet finished. " however this is only the case if no error occurred; otherwise it is left untouched.
We want the invalid content to generate a decoding error, so we set size to inputSize to ensure decoding failed later.
MozReview-Commit-ID: FZeiZUdUtLG
--HG--
extra : rebase_source : 2e81d730bacaea5bb968f704a36b403117dafcba
We queried 'loadingprincipal' attribute on the common call path, however
this should be queried if it's loaded by System Principal.
Also rename loadingprincipal to triggeringprincipal
This also brings in and convert some utilities we have in Gecko, that will ease
porting more tests.
MozReview-Commit-ID: 2yPZQO504kH
--HG--
rename : dom/media/webaudio/test/test_analyserNodeOutput.html => testing/web-platform/tests/webaudio/the-audio-api/the-analysernode-interface/test-analyser-output.html
extra : rebase_source : 0a9c9c336b1b53120010a081da131c76f103a838
The delegate property of NSSpeechSynthesizer doesn't seem to add refcount from 10.13, so we have to keep SpeechDelegate object until speech is finished.
MozReview-Commit-ID: EVtMOPytkjR
--HG--
extra : rebase_source : f2a6d97942c19990a16dd68555328ed36280eb4a
The reverts to accepting ownership of the monitor regardless of the thread, as
accepted prior to
https://hg.mozilla.org/mozilla-central/rev/e3f39de40209#l1.25
As indicated in the SetCurrentDriver() documentation, it can be called on the
main thread during Revive() before another graph thread is started.
At that point mLifecycleState = LIFECYCLE_RUNNING, and so it is not easy to
adjust AssertOnGraphThreadOrNotRunning() to accept this situation without
making it much more liberal.
An alternative would be to change the Revive() methods to set mDriver
directly, but that would differ from the usual driver-switching pattern.
MozReview-Commit-ID: 9O5qakPVML9
--HG--
extra : rebase_source : 82115938ccd164863ddf6f983e7900705844d0ed
For webrtc, the most important part of the code had already been removed in bug 1355048 and could no longer be called
MozReview-Commit-ID: Fx9XI0zR1gn
--HG--
extra : rebase_source : 360996760abab650684440fbeea258b43dccfd83
This was used to support cross-architecture NPAPI plugins on OS X, but
we stopped supporting that in 54 (bug 1339182).
MozReview-Commit-ID: 2BcWYD6mguY
--HG--
extra : rebase_source : 6e509a3cc1f356ccd24f1459c43bc8fb66d7b0f4
mManager would be accessed in both main thread and task queue, and be set on task
queue, so we need to make sure it's thread-safe.
MozReview-Commit-ID: m76KeEsDgB
It would only be accessed on task queue now, so we don't need to lock it.
MozReview-Commit-ID: 6jd36TQW4aA
--HG--
extra : rebase_source : e8bb53a226154312496149ab8f6b00dead49a3b6
Now DecoderTraits doesn't need to depend on ChannelMediaDecoder.
MozReview-Commit-ID: D4AUiV2eGWy
--HG--
extra : rebase_source : 38e6c4cdd0f7e32473c6945550bca6fd0cc72bf2
CreateDecoder is the only caller of InstantiateDecoder, and all CreateDecoder
does is call InstantiateDecoder.
MozReview-Commit-ID: KwwL2el8L4x
--HG--
extra : rebase_source : bff225558fd2de535c2cb010eb35b95c6d9469e5
Replace with conditional compilation enabled for Linux targets.
MozReview-Commit-ID: GjD0Ix8aeJW
--HG--
extra : rebase_source : 18dd93eda0a9ebc1846a876caa4f5d27d8b75909
Adding partial support for 10/12-bit video images seems to have
broken the native pixel-stride support we were using to pass
8-bit AV1 frame data formatted in 16-bit pixel values, resulting
in vertical green lines.
Revert to the earlier behaviour of always downsampling to 8 bit data.
This is slower for the demo stream, but at least displays correctly.
MozReview-Commit-ID: 8kSd9kph9DE
--HG--
extra : rebase_source : 040795b4d99a2001397c0021f34d39535aa4aa2d
The value by which we pre-roll is inconsequential, so long as we seek to the previous packet than the one we want. So 80ms will do.
MozReview-Commit-ID: 8iPOtjReZnb
--HG--
extra : rebase_source : 42908c6afc84cf783356fb7311ffe99b4ec76d96
mTaskQueue is only read on the main thread, but read and written on the demuxer's taskqueue. We need to ensure that accesses are synchronised.
MozReview-Commit-ID: Gbc15iYgZOe
--HG--
extra : rebase_source : 006ff3f73c9895fa2f29e56123e690cdf66fe2c5
Removed non-eager DDLogValue() functions, too confusing for not much value;
users should use macros first anyway.
Changed `EagerLogValue(..., const char (&aLiteral)[N])` to take `const char*`,
it's cleaner and simpler.
MozReview-Commit-ID: J7xcoPkp6Nf
--HG--
extra : rebase_source : 41040c98b89c3035c823a4a9775e727038c07590
The use of the TrackBuffersManager once detached is explictly forbidden, as such
OnTaskQueue() can only be used before the DetachTask ran: we now strongly assert
as such.
MozReview-Commit-ID: ycOI4QRElb
--HG--
extra : rebase_source : ecce8ac75587470c15268ab729b068f049702a8a
Ensure the TBM would always be detached from demuxers, before calling
TBM::detach().
MozReview-Commit-ID: DLWZHB3M3GG
--HG--
extra : rebase_source : 9e455022ba9360fb549222e9ad1238a3ae9d88ad
From [1], the task was executed after finished detach task. It would be caused
by queuing two detach tasks in the task queue.
If the previous detach task is still waiting in the task queue when we're calling
the second detach(), then we might have two detach tasks in the queue.
[1] https://treeherder.mozilla.org/logviewer.html#?job_id=134315866&repo=try&lineNumber=2540
MozReview-Commit-ID: HohgKqeZy0s
--HG--
extra : rebase_source : 0d20f1b8648acaf2ed8e75b2631e905629c2abaf
Should never access the TrackBuffersManager once the SourceBuffer has been detached.
MozReview-Commit-ID: EgVINj9B1vZ
--HG--
extra : rebase_source : 4b4dc3e5c4b507fe4cc40e80f507b575a8b87eb3
After detaching TBM, we should not access it anymore. So we should finish all
other related detaching process, before detaching TBM.
MozReview-Commit-ID: 8bNzqXVHVyy
--HG--
extra : rebase_source : e135eb3d0fd4e5c41bbac4ebfc8d6fcbd1b32d5b
The use of the TrackBuffersManager once detached is explictly forbidden, as such
OnTaskQueue() can only be used before the DetachTask ran: we now strongly assert
as such.
MozReview-Commit-ID: ycOI4QRElb
--HG--
extra : rebase_source : 44ea3d0eb292e5c285d0aa4e10eefa41f20beed7
Ensure the TBM would always be detached from demuxers, before calling
TBM::detach().
MozReview-Commit-ID: DLWZHB3M3GG
--HG--
extra : rebase_source : 0334b71534cfaccaf1d8985d827fe4e5d5bf0e9f
From [1], the task was executed after finished detach task. It would be caused
by queuing two detach tasks in the task queue.
If the previous detach task is still waiting in the task queue when we're calling
the second detach(), then we might have two detach tasks in the queue.
[1] https://treeherder.mozilla.org/logviewer.html#?job_id=134315866&repo=try&lineNumber=2540
MozReview-Commit-ID: HohgKqeZy0s
--HG--
extra : rebase_source : b1dc3193d839ef3776195901339fae24f328207b
Should never access the TrackBuffersManager once the SourceBuffer has been detached.
MozReview-Commit-ID: EgVINj9B1vZ
--HG--
extra : rebase_source : 4b4dc3e5c4b507fe4cc40e80f507b575a8b87eb3
After detaching TBM, we should not access it anymore. So we should finish all
other related detaching process, before detaching TBM.
MozReview-Commit-ID: 8bNzqXVHVyy
--HG--
extra : rebase_source : e135eb3d0fd4e5c41bbac4ebfc8d6fcbd1b32d5b
This is unnecessary work but simpler than adding a path to, or refactoring, AudioCallbackDriver::DataCallback.
MozReview-Commit-ID: GLNoBqxEuwz
--HG--
extra : rebase_source : b5ef6b2e1506e68d41b22ad557968d70214fbd9f
Owning the monitor is not sufficient for consistent state if state can be
accessed without the monitor.
The requirements for SetCurrentDriver() are tighted to require both the
monitor and correct thread, as CurrentDriver() can be called either with the
monitor or on the graph thread.
MozReview-Commit-ID: 90q7Pfa8jxn
--HG--
extra : rebase_source : 6cbcc334dc2bd355d2e9afdebda45a9624edda4b
This also permits setting mDriver to null after mDetectedNotRunning, which is
useful for fixing bug 1406830.
MozReview-Commit-ID: EEgAxqPQPRI
--HG--
extra : rebase_source : 56e1583a0090e683e92463536637d0f1460cb727
mLifecycleState is always > LIFECYCLE_RUNNING when mDetectedNotRunning
MozReview-Commit-ID: Ds6ybTv4miA
--HG--
extra : rebase_source : 71aea6693026dc919ea6d2096f55152ae12bc58e
Accessing the graphic device driver from the parent process, should the drivers crash have serious consequences (the whole browser dies).
MozReview-Commit-ID: EXXRBnDobQw
--HG--
extra : rebase_source : d5609f1e088c7bbe92d6e46e66e1fb5538d5caac
I don't know whether or not another zero initial AudioChunk member value
makes initialization more efficient, but zero for silence is more intuitive
for humans.
MozReview-Commit-ID: JEYv65btMul
--HG--
extra : rebase_source : 3089362ce4773da91c7139a3127e1491cbcf1dc5
This avoids any risk of undefined behavior when evaluating uninitialized
members, during copies for example, and makes it safe to test mBufferFormat
when null.
MozReview-Commit-ID: IMAyZ1CSHbk
--HG--
extra : rebase_source : b02431634732cf63d6fe9ede5eb1400a2baa6308
Currently the Gecko Profiler defines a moderate amount of stuff when
MOZ_GECKO_PROFILER is undefined. It also #includes various headers, including
JS ones. This is making it difficult to separate Gecko's media stack for
inclusion in Servo.
This patch greatly simplifies how things are exposed. The starting point is:
- GeckoProfiler.h can be #included unconditionally;
- everything else from the profiler must be guarded by MOZ_GECKO_PROFILER.
In practice this introduces way too many #ifdefs, so the patch loosens it by
adding no-op macros for a number of the most common operations.
The net result is that #ifdefs and macros are used a bit more, but almost
nothing is exposed in non-MOZ_GECKO_PROFILER builds (including
ProfilerMarkerPayload.h and GeckoProfiler.h), and understanding what is exposed
is much simpler than before.
Note also that in BHR, ThreadStackHelper is now entirely absent in
non-MOZ_GECKO_PROFILER builds.
Alastor Wu
Alfredo.Yang
JW Wang
Bryce Van Dyk
Nathan Froyd
Sebastian Hengst
Nils Ohlmeier [:drno]
James Cheng
Jean-Yves Avenard
Yoshi Huang
Paul Adenot
Makoto Kato
Karl Tomlinson
Jed Davis
Andreas Pehrson
bechen@mozilla.com
Masatoshi Kimura
Tyson Smith
Matthew Gregan
Dan Glastonbury
Ryan VanderMeulen
Alex Gaynor
Bob Clary
Jesse Ruderman
Phil Ringnalda
Randell Jesup
Boris Zbarsky
Dan Minor
Ethan Lin
Chris Pearce
Kris Maglione
Ralph Giles
Dan Banner
Chung-Sheng Fu
Kilik Kuo
Gerald Squelart
Tom Ritter
Jan-Ivar Bruaroey
Joel Maher
Nicholas Nethercote