In AudioData, we use `mOriginalTime` to store the original start time before trimming, which should keep sync to `mTime` if data hasn't been trimmed before. Otherwise, if they are not equal, it would cause a problem when handling trimming.
For example.
If audio data's time is X, original time is X-1 and duration is T. When MDSM performs seeking, it would use (X + T) as trimming window's end time. However, in `AudioData::SetTrimWindow()`, original time + duration (X - 1 + T) would be less than the trimming end time, which causes an error.
Differential Revision: https://phabricator.services.mozilla.com/D100825
`AdjustForStartTime()` is only used for decoded data type in order to adjust their start time to zero, such as `VideoData` and `AudioData`.
However, some other types inherited from `MediaData` don't need that function. Eg. `MediaRawData`, so it's not necessary to put it on the `MediaData`, we should move that function to `VideoData` and `AudioData` separately.
Differential Revision: https://phabricator.services.mozilla.com/D100846
This patch implements the transparency support for AVIF image files.
To convert the decoded YCbCr and Alpha data to RGBA, a function named
`ConvertYCbCrAToARGB` is created to do this job in the following
procedure:
ConvertYCbCrAToARGB:
If the layout of the YCbCr is I420
Calling libyuv::I420AlphaToARGB
Else
Fill RGB data converted by ConvertYCbCrToRGB in ARGB buffer first
Insert the alpha data to ARGB buffer
On the other hand, this patch refactors the nsAVIFDecoder a bit to make
the lifetime of the parsed data and decoded image data clearer. They
won't live longer than Parser object and {Dav1d, AOM}Decoder object.
This should improve the code readability.
This patch also adds a transparent image test (TransparentAVIFTestCase)
to check the FLAG_HAS_TRANSPARENCY is posted or not. The test image file
`transparent.avif` is from Bug 1654462.
Differential Revision: https://phabricator.services.mozilla.com/D98951
We can't handle this at the decoder level, because the decoder doesn't know that
a particular packet it's seeing is the second to last packet and it should start
trimming the end of this packet because the encoder padding spans multiple
packet.
Differential Revision: https://phabricator.services.mozilla.com/D92645
This interface is never used directly, and the only consumers of the virtual functions are by the derived classes themselves.
Differential Revision: https://phabricator.services.mozilla.com/D93180
Those two objects can be used to pack multiple array of objects into a minimal amount of shmem.
An ArrayOfRemoteByteBuffer will take at most a single shmem and perform a single memory allocation..
Similarly, an ArrayOfMediaRawData will pack multiple MediaRawData in at most 3 shmems (one for each array of bytes a MediaRawData contains).
They are designed to work in combination with a ShmemPool which will own each of the allocated Shmem and so can be re-used over and over.
Differential Revision: https://phabricator.services.mozilla.com/D91537
Because we store each plane's data pointer we don't need to store a separate
offset, we can just roll that offset into the pointer for that plane.
This helps remove a lot of code where we're not using the offset anyway, and in
the Chromium CDM case we simply roll the offset into our data pointer.
Differential Revision: https://phabricator.services.mozilla.com/D78320
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
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
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
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
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
There is no need to cast to `TimeUnit` to `int64` and then cast to `TimeUnit` again.
Differential Revision: https://phabricator.services.mozilla.com/D26758
--HG--
extra : moz-landing-system : lando
Now the caller of `AdjustForStartTime()` should check the return value to know whether the adjustment is succeeded.
If the error happens the caller should handle it and return an error.
Differential Revision: https://phabricator.services.mozilla.com/D26756
--HG--
extra : moz-landing-system : lando
Warn instead of asserting since it's possible for decoders to give us 0 by 0
frames here.
Differential Revision: https://phabricator.services.mozilla.com/D26612
--HG--
extra : moz-landing-system : lando
There's two cases to handle.
1- A Frame isn't entirely contained between appendWindowStart and appendWindowEnd
2- A new frame is appended which overlaps partially an existing frame.
To achieve this we tweak the start time and duration of the sample added (case 1), or the frame about to be partially covered (case 2). We then set a flag that will indicate to the decoder that the decompressed frame will have to be truncated.
Differential Revision: https://phabricator.services.mozilla.com/D20172
--HG--
extra : moz-landing-system : lando
It can be determined from the size of the buffer and the number of audio frames. Additionally, it ensures that the duration of the frame is always exactly what the AudioData contains.
Differential Revision: https://phabricator.services.mozilla.com/D20170
--HG--
extra : moz-landing-system : lando
Don't re-create a new trimmed AudioData when we want to remove some content. This remove the need for some copies.
Differential Revision: https://phabricator.services.mozilla.com/D20168
--HG--
extra : moz-landing-system : lando
The number of frames is only meaningful with audio as a VideoData always contain a single frame.
So we only have this member in AudioData, which will simplify the logic in a future commit where the number of frames present depends on the trimming filter applied.
Differential Revision: https://phabricator.services.mozilla.com/D20164
--HG--
extra : moz-landing-system : lando
Jeff Gilbert
Csoregi Natalia
alwu
Chun-Min Chang
Razvan Maries
Jean-Yves Avenard
Bryce Seager van Dyk
Matt Woodrow
Paul Adenot
Cristina Coroiu
Lee Salzman
Mihai Alexandru Michis
Simon Giesecke
Boris Zbarsky
John Lin
Dorel Luca
Narcis Beleuzu
Cosmin Sabou
sotaro
Markus Stange
Ryan Hunt