You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Working on #652 PR, we highlighted that the time scale parameter used in the Mp4Composer, Mp4ComposerEngine and VideoComposer layers are using an integer time scale parameter instead of allowing it to be used as a float like in the original library implementation. The current scenarios we have are basically stories and video compression use cases which (after the above mentioned PR) uses different implementations of those classes like below
The left path is using the classes adapted for the stories use case (Mp4Composer and Mp4ComposerEngine) while the right path is using, a part minor adaptations, the classes from the original lib (Mp4ComposerBasic and Mp4ComposerEngineBasic; note that they can handle also the needed video compression feature)
The right path is also using the time scale parameter as a float. Both paths currently overlap again into the VideoComposer layer that's using the time scale as an int.
We recognized the convenience to bring back the time scale to be managed as a float, but given time scaling is not currently used in our scenarios, we are not going to decouple/change the VideoComposer layer right yet, but creating this issue to track/document this in case we need that functionality at a certain point.
Working on #652 PR, we highlighted that the time scale parameter used in the Mp4Composer, Mp4ComposerEngine and VideoComposer layers are using an integer time scale parameter instead of allowing it to be used as a float like in the original library implementation. The current scenarios we have are basically
stories
andvideo compression
use cases which (after the above mentioned PR) uses different implementations of those classes like belowThe left path is using the classes adapted for the stories use case (Mp4Composer and Mp4ComposerEngine) while the right path is using, a part minor adaptations, the classes from the original lib (Mp4ComposerBasic and Mp4ComposerEngineBasic; note that they can handle also the needed video compression feature)
The right path is also using the time scale parameter as a float. Both paths currently overlap again into the VideoComposer layer that's using the time scale as an int.
We recognized the convenience to bring back the time scale to be managed as a float, but given time scaling is not currently used in our scenarios, we are not going to decouple/change the VideoComposer layer right yet, but creating this issue to track/document this in case we need that functionality at a certain point.
cc @mzorz
The text was updated successfully, but these errors were encountered: