Also, document that we tone map when no HDR features are explicitly set
PiperOrigin-RevId: 487310971
(cherry picked from commit 2ff5dab0039c44d767dc831fec92724254e5e0aa)
Not setting the color info results in a missing "colr" box in the produced
container, under file/moov/trak/mdia/minf/stbl/stsd/hvc1. This means extractors
will not be able to find out the transcoded file is HDR.
In `Transformer`, this means it can't transcode this transcoded file, because
it currently relies on the container bearing HDR info to construct the
transcoding sample pipeline.
PiperOrigin-RevId: 487276712
(cherry picked from commit 3c74e076fef6ef9ae892dcfda9026ae1be83c1b0)
In startTransformation method we were throwing UnsupportedEncodingException (IOException) when mediaItem with unsupported arguments is passed.
Changed this to IllegalArgumentException which seems more logical here.
PiperOrigin-RevId: 487259296
(cherry picked from commit 818bf4a20a4bb55d57e26b6c200c9857d4caf659)
Just move some code around for now, to start setting up the overall
structure.
PiperOrigin-RevId: 487229329
(cherry picked from commit 95f37b4df8475e5eaf09da0a5d4dee04a81646a0)
This is to avoid having this logic in TransformerInternal once it is
added.
PiperOrigin-RevId: 487159941
(cherry picked from commit 714e5565053ad48ec23b1f1640851a1e784a6726)
This logic is currently in the player renderers. With multi-asset, the
renderers will go into the AssetLoader, which shouldn't be responsible
for muxing.
PiperOrigin-RevId: 486860502
(cherry picked from commit 61471474c7441d60a5d452d9acd8a1a2a1c88ca6)
Problem: We are initialising muxer as soon as we start the transformation. Now the startTransformation() method can be called from main thread, but muxer creation is an I/O operation and should be not be done on main thread.
Solution: Added lazy initialisation of muxer object. The actual transformation happens on background thread so the muxer will be initialised lazily from background thread only.
Another way was to provide an initialize() method on MuxerWrapper which will explicitly initialise muxer object but with this approach the caller need to call the initialise method before calling anything else. With current implementation the renderers are calling MuxerWrapper methods on various callbacks (Not sequentially) and also we are sharing same muxer with multiple renderers so It might become confusing for the caller on when to call the initialise() method. Also there are few methods on MuxerWrapper which dont really need muxer object. So in short it might make MuxerWrapper APIs more confusing.
Validation: Verified the transformation from demo app.
PiperOrigin-RevId: 486735787
(cherry picked from commit eb357654bbd11f6304a6f5495bb209e59307dfcb)
This should be necessary to ensure decoders see fewer errors.
Setting this resulted in removing native_dequeueOutputBuffer errors on OMX.MTK decoders for in-app tone mapping prototyping.
PiperOrigin-RevId: 486715941
(cherry picked from commit e510d9903ff30c4ec308bdcfba114e8889aad20c)
Not sure what BUILD.ID the fix will first be applied on though.
PiperOrigin-RevId: 485389618
(cherry picked from commit 91b286c4f813cdecf3999319c3b2c73fbee3c00a)
This allows to throw when the Transformer is stuck or is too slow.
PiperOrigin-RevId: 484179037
(cherry picked from commit 16cb5cbc1f6f729d39bf8747e7c0a0f7aea7326d)
Although it can be useful to check the output format, it's not required or needed.
For some AudioProcessor implementations, it is stated/obvious that
the output format will match the input, in which case there is no
a need to check the return value.
#cleanup
PiperOrigin-RevId: 483403679
(cherry picked from commit 8723e74b1f48377ea8962247e10ee54252dd2de3)
This listener will need to be passed to the MuxerWrapper to throw when
the Transformer is stuck.
PiperOrigin-RevId: 482433552
(cherry picked from commit e6d5595545ac4e0715b8b914a9a4b4a2757911d7)
The reason for making the Muxer public is that we want to add an option
to disable or configure the timer that will throw when the muxer doesn't
receive any data for a given period of time.
PiperOrigin-RevId: 482199360
(cherry picked from commit cf14d0687db5b8c0ea9edeae67a0b91affacbcd8)
- The naming DefaultMuxer is more consistent with the rest of
Transformer codebase (e.g. DefaultEncoderFactory).
- By hiding the implementation details of DefaultMuxer, the transition
to in-app Muxer will be seamless for apps using DefaultMuxer.
- The current plan is that DefaultMuxer will become the in-app muxer.
PiperOrigin-RevId: 481838790
(cherry picked from commit 3399f4ecdfd0354f49a8599d04e4cc68295f2af5)
- This method is redundant with getSupportedSampleMimeTypes().
- This is to prepare the Muxer class to become public.
PiperOrigin-RevId: 480840902
(cherry picked from commit 2786db9e73505a8d6d4c4f2c284aacb605006ab8)
Also, update tests to allow AnyOf error codes, and no longer check exception messages, which caused quite a bit of churn.
PiperOrigin-RevId: 479570861
(cherry picked from commit 8548e3519e3d6ef214d5c18d640a8bf6efe19c83)
Assert that tone mapping is applied when an HDR edit cannot be HDR, but is successfully tone mapped. Meanwhile, assert that fallback, which is applied after codec configuration (which throws the "Tone-mapping requested but not supported by the decoder" error) is not applied when that error is called.
PiperOrigin-RevId: 478762951
(cherry picked from commit 253486d4af057776da0eb5926e31190f43dbe3b3)
Rename test files to avoid substrings that can be implied by the directory name,
like "Transformation" and "Test"
No functional changes. Renaming-only.
PiperOrigin-RevId: 477724724
(cherry picked from commit 62b95a71902349e95693174f83bb48e6927d5249)
* Transform the intermediate color space to linear SDR by applying the SMPTE 170M EOTF and OETF.
* Use linear colors for the color filter pixel tests and update all golden bitmaps.
PiperOrigin-RevId: 476124592
(cherry picked from commit 3433758c3b1f02c0ec28b86a8c3b659171f6f92b)
Tested:
* Manually using both path and file descriptor.
PiperOrigin-RevId: 475860978
(cherry picked from commit 9ec4e1340a97472c63e9f017f95f2b1a38f88588)
By skipping every other row and column, SSIM calculation time reduces by 10-30%.
PiperOrigin-RevId: 474286702
(cherry picked from commit 314b312af18c568c5353b661b31ebc60a0736678)
As part of this change, MssimCalculator is moved from androidTest/ to main/
PiperOrigin-RevId: 473771344
(cherry picked from commit 8ce42f0670504a89c5c3e546f8be3d849be36195)
*** Original commit ***
Handle int instead of byte in SSIM.
The value of pixels are converted to integers at the point of use,
move this logic to the initialisation step.
This is a prerequisite step for testing SSIM calculation, which
will lead on to some SSIM improvements being verifiable.
Tested manually and SSIM values match for the same video
before and after this change.
***
PiperOrigin-RevId: 473259446
(cherry picked from commit d188babd2daea5b737ef43604aa00baf157a2df5)
The value of pixels are converted to integers at the point of use,
move this logic to the initialisation step.
This is a prerequisite step for testing SSIM calculation, which
will lead on to some SSIM improvements being verifiable.
Tested manually and SSIM values match for the same video
before and after this change.
PiperOrigin-RevId: 473231779
(cherry picked from commit 3d5ddf0c42f1d2b91d4ef33c75f59656c6e566bc)
Test that HDR editing succeeds on devices supporting HDR editing, tone maps on
devices supporting tone mapping, and throws exceptions on all other devices.
Also, only restrict HDR editing and tone mapping support to API 31+ only when
transcoding, not for all transformations.
PiperOrigin-RevId: 472958965
(cherry picked from commit 0d8fd3d4fc1da31c05fa82bb5e815332a6c7fa12)
shouldPassthrough's internal checks seem to be check whether we should *not*
pass through, which seemed a bit like a confusing double-negative to me.
shouldTranscode is slightly more clear, by instead returning true when we do
want to transcode.
No functional changes intended.
PiperOrigin-RevId: 471753771
(cherry picked from commit 7085c2fa6e90834b7ace3b22b16d9f14f5e9eb66)
3b0d2c1586 made `shouldPassthrough` always return false for `enableHdrVideoEditing`:
>We force using `FrameEditor` (no passthrough) to avoid the need to select another edit operation, and use the new shaders. The `EGLContext` and `EGLSurface` also need to be set up differently for this path.
However, this was introduced before the `videoNeedsEncoding` setting was introduced in 3f615040c0. That setting should apply to HDR videos as much as SDR videos.
PiperOrigin-RevId: 471569853
(cherry picked from commit bc88f8be54b5c666d9ad591c04ac9faa4457454a)
Upstream timestamps from the decoder are also in microseconds,
so using microseconds here is consistent with that.
PiperOrigin-RevId: 468659099
(cherry picked from commit 0b1c540ff96b4f4f4ff7cff16a2e51674a42a0c2)
Adds a method to FrameProcessor.Listener to be called when an
output frame is available and a method releaseOutputFrame in
FrameProcessor allowing the caller to trigger release of the
oldest available output frame at a given timestamp. Late frames
or frames with unset release times are dropped in the
FinalMatrixTransformationProcessorWrapper.
More than one output frame can become available before they are
released if the penultimate GlTextureProcessor is capable of producing
multiple output frames. Processing continues while waiting for
releaseOutputFrame to be called. Frame release tasks are prioritized
over other tasks.
PiperOrigin-RevId: 468473072
(cherry picked from commit a5d7fdcab52ea6c12fa35efc348b69eccb53f715)
createSupportedTransformationRequest is more accurate than
createFallbackTransformationRequest, as a TransformationRequest will be returned
regardless of whether any fallback is applied.
PiperOrigin-RevId: 466641277
(cherry picked from commit c5a5364673749cb737be3df92c9521fc15207658)
