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
This removes all telemetry which expired in Firefox 69 or earlier, with the
exceptions of the following, which we plan to renew:
* AUDIO_TRACK_SILENCE_PROPORTION
* MEDIA_AUTOPLAY_WOULD_BE_ALLOWED_COUNT
* MEDIA_AUTOPLAY_WOULD_NOT_BE_ALLOWED_COUNT
* MEDIACACHESTREAM_LENGTH_KB
* MEDIA_MKV_CANPLAY_REQUESTED
* MEDIA_PAGE_COUNT
* MEDIA_PAGE_HAD_MEDIA_COUNT
* VIDEO_DROPPED_FRAMES_PROPORTION
* VIDEO_PLAY_TIME
* VIDEO_HIDDEN_PLAY_TIME
* VIDEO_HIDDEN_PLAY_TIME_PERCENTAGE
* VIDEO_INFERRED_DECODE_SUSPEND_PERCENTAGE
* VIDEO_INTER_KEYFRAME_AVERAGE_MS
* VIDEO_INTER_KEYFRAME_MAX_MS
* VIDEO_SUSPEND_RECOVERY_TIME_MS
* VIDEO_VP9_BENCHMARK_FPS
* WEB_AUDIO_BECOMES_AUDIBLE_TIME
* WEBVTT_TRACK_KINDS
Differential Revision: https://phabricator.services.mozilla.com/D37313
--HG--
extra : moz-landing-system : lando
This removes all telemetry which expired in Firefox 69 or earlier, with the
exceptions of the following, which we plan to renew:
* AUDIO_TRACK_SILENCE_PROPORTION
* MEDIA_AUTOPLAY_WOULD_BE_ALLOWED_COUNT
* MEDIA_AUTOPLAY_WOULD_NOT_BE_ALLOWED_COUNT
* MEDIACACHESTREAM_LENGTH_KB
* MEDIA_MKV_CANPLAY_REQUESTED
* MEDIA_PAGE_COUNT
* MEDIA_PAGE_HAD_MEDIA_COUNT
* VIDEO_DROPPED_FRAMES_PROPORTION
* VIDEO_PLAY_TIME
* VIDEO_HIDDEN_PLAY_TIME
* VIDEO_HIDDEN_PLAY_TIME_PERCENTAGE
* VIDEO_INFERRED_DECODE_SUSPEND_PERCENTAGE
* VIDEO_INTER_KEYFRAME_AVERAGE_MS
* VIDEO_INTER_KEYFRAME_MAX_MS
* VIDEO_SUSPEND_RECOVERY_TIME_MS
* VIDEO_VP9_BENCHMARK_FPS
* WEB_AUDIO_BECOMES_AUDIBLE_TIME
* WEBVTT_TRACK_KINDS
Differential Revision: https://phabricator.services.mozilla.com/D37313
--HG--
extra : moz-landing-system : lando
When unknown, we rely on the picture height and assume that anything less than 720p is 601 and 709 otherwise. It's not perfect but it's the best we can do.
Differential Revision: https://phabricator.services.mozilla.com/D39275
--HG--
extra : moz-landing-system : lando
