The coming updated libsoundtouch will use ST_THROW_RT_ERROR in several
places built without setting ST_NO_EXCEPTION_HANDLING.
ST_NO_EXCEPTION_HANDLING is only set in libsoundtouch/src/moz.build. To
avoid using `throw`, we should `#define` ST_NO_EXCEPTION_HANDLING before
`#include` soundtouch headers.
Differential Revision: https://phabricator.services.mozilla.com/D52932
--HG--
extra : moz-landing-system : lando
In order to use the batch decoding abilities added in Bug 1590475,
we need to also add batch decoding to MediaDataDecoder. For now
only RemoteMediaDataDecoder (and AudioTrimmer as a wrapper) know
how to do batch, but this could be implemented more generically
later in MediaDataDecoder.
Differential Revision: https://phabricator.services.mozilla.com/D51452
--HG--
extra : moz-landing-system : lando
On Android, decoded buffers need to be send back to MediaCodec in order to be
rendered and/or recycled. The current mechanism introduced in bug 1299068 only
works for playback(VideoData/VideoSink) but not WebRTC(VideoFrame/VideoOutput).
Move the callback to SurfaceTextureImage because VideoData and VideoFrame both
own that when using MediaCodec, and move the notification to VideoFrameContainer
for both VideoSink and VideoOutput pass frames there for compositing.
Differential Revision: https://phabricator.services.mozilla.com/D45771
--HG--
extra : moz-landing-system : lando
This does many things:
1) stops producing (and consuming) `FennecJNI*` JNI wrappers
2) removes the :app and :thirdparty Gradle projects
3) removes relevant pieces of the Gradle target configuration
4) updates lints
5) purges old configurations
After this commit, the `mobile/android` project/application builds
only GeckoView.
Differential Revision: https://phabricator.services.mozilla.com/D46536
--HG--
extra : moz-landing-system : lando
On Android, decoded buffers need to be send back to MediaCodec in order to be
rendered and/or recycled. The current mechanism introduced in bug 1299068 only
works for playback(VideoData/VideoSink) but not WebRTC(VideoFrame/VideoOutput).
Move the callback to SurfaceTextureImage because VideoData and VideoFrame both
own that when using MediaCodec, and move the notification to VideoFrameContainer
for both VideoSink and VideoOutput pass frames there for compositing.
Differential Revision: https://phabricator.services.mozilla.com/D45771
--HG--
extra : moz-landing-system : lando
Both of these files obviously use things from the newly-included
headers, but they were not including them prior to this point.
Differential Revision: https://phabricator.services.mozilla.com/D46632
--HG--
extra : moz-landing-system : lando
Set a trivial duration (1us) on 0 duration samples before feeding them to the
WMF MFT decoder to prevent it from estimating the duration for such samples.
Differential Revision: https://phabricator.services.mozilla.com/D46516
--HG--
extra : moz-landing-system : lando
This is a back out of changeset c52127007a01, i.e. reverts bug 1560440. That bug
was itself reverting a prior bug where we started setting the duration.
There are two scenarios involved, each with their own issues:
- We don't set the duration when feeding the decoder (what we're doing prior to
this change). In this case the decoder will estimate durations for all
samples. This works in many cases, but leads to issues with files that have
non-uniform durations - as seen in bug 1576990 (this bug).
- We do set the duration when feeding the decoder (what will happen after this
change). In this case the decoder will not estimate durations, except it still
seems to do so when fed 0 duration samples. Since our demuxing pipeline can
create 0 duration samples, this leads to issues with such files (as seen in
bug 1560440).
This patch fixes the former of the above, and the next patch in the chain will
address the latter.
Differential Revision: https://phabricator.services.mozilla.com/D46515
--HG--
extra : moz-landing-system : lando
Also remove the definition of unused struct for tracking of input timestamp.
Depends on D45774
Differential Revision: https://phabricator.services.mozilla.com/D45775
--HG--
extra : moz-landing-system : lando
Some existing functions that manipulates H.264 bitstream already cover
most of the efforts for converting Android encoder output. With some minor
changes, they can be called by the encoder to avoid code duplications.
Differential Revision: https://phabricator.services.mozilla.com/D43686
--HG--
extra : moz-landing-system : lando
Some existing functions that manipulates H.264 bitstream already cover
most of the efforts for converting Android encoder output. With some minor
changes, they can be called by the encoder to avoid code duplications.
Differential Revision: https://phabricator.services.mozilla.com/D43686
--HG--
extra : moz-landing-system : lando
Dealing with a case where `DecodeNALUnit()` returns nullptr which we should not try to create bit reader and decode anything.
In addition, wrap these logic to `DecodedISlice()` in order to keep consistent with a case where we decode SEI.
Differential Revision: https://phabricator.services.mozilla.com/D44875
--HG--
extra : moz-landing-system : lando
Some existing functions that manipulates H.264 bitstream already cover
most of the efforts for converting Android encoder output. With some minor
changes, they can be called by the encoder to avoid code duplications.
Differential Revision: https://phabricator.services.mozilla.com/D43686
--HG--
extra : moz-landing-system : lando
Sometime we would encouter a file putting all its samples on the type1 NAL, so we have to check its slice type in order to know if it's a keyframe or not.
The slice type is defined in the ITU-T Rec H.264 table 7.3, and it could be found in the slice_header in table 7.3.3.
Differential Revision: https://phabricator.services.mozilla.com/D35572
--HG--
extra : moz-landing-system : lando
In order to encode video frame, we have to convert `webrtc::VideoFrame` to gecko's video data, and then send this YUV-based video data to the encoder.
The encoder won't return an encoded frame everytime when we call its `encode()`, so we have to wait until there are valid samples added to `mEncodedFrames`.
Then, convert the `MediaRawData` to `webrtc::EncodedImage` and provide an NAL entries list to indicate where the NALs are in the encoded bytes stream and how large they are. We would send those data back
to the consumer of the encoder via calling a callback function `OnEncodedImage()`.
Differential Revision: https://phabricator.services.mozilla.com/D40532
--HG--
extra : moz-landing-system : lando
These functions were made public in 10.6. The oldest version we support is 10.9.
Differential Revision: https://phabricator.services.mozilla.com/D41813
--HG--
extra : moz-landing-system : lando
Bug 1540748/D28167 checks the output sample timestamp against the
time parsed by demuxer to determine the validness. However, unlike
Android builtin MP3 decoder which sets EOS flag in the final valid
output, the Samsung MP3 decoder always emit additional EOS sample
with invalid timestamp. To address this, the timestamp check should
be ignore for EOS samples.
Differential Revision: https://phabricator.services.mozilla.com/D41872
--HG--
extra : moz-landing-system : lando
If the encoded frame is a keyframe, we should also mark the MediaRawData which would contain the data from this encoded frame as a keyframe.
Differential Revision: https://phabricator.services.mozilla.com/D40465
--HG--
extra : moz-landing-system : lando
As we are not going to modify the CodecSpecific, it should keep const when we forward it.
Differential Revision: https://phabricator.services.mozilla.com/D40464
--HG--
extra : moz-landing-system : lando
We don't have a contraint for using PlatformEncoderModule in the specific thread only, so we should use thread-safe refcounting for it, like PlatformDecoderModule.
Differential Revision: https://phabricator.services.mozilla.com/D40463
--HG--
extra : moz-landing-system : lando
Chun-Min Chang
Michael Froman
John Lin
Nick Alexander
Dorel Luca
Nathan Froyd
Bryce Seager van Dyk
Narcis Beleuzu
alwu
Noemi Erli
Sylvestre Ledru
Markus Stange