How to realize seamless replay of iOS short videos across pages?

Today, when everything can be video-enabled, short video content, as a new promotion point for mobile products, has received more and more attention and investment. In addition to basic optimizations such as second-broadcasting, freeze rate, and playback success rate, Hema introduces seamless playback capabilities in the user experience to improve the continuity of users watching video content. This article will share Hema’s practices in iOS short videos.

Author｜God catch
Review｜Taiyi

Cross-page resuming is another ability that can increase the user experience from the somatosensory in addition to the second broadcast. Since some business scenarios need to play the same video content scenes on different pages, and the page switching of these scenes is often continuous, this requires that the playback of short videos is also continuous. Only in this way can there be continuity in the experience, so that when the user enters the immersive page, the user can smoothly transition and continue playing without any perception, thereby producing a continuous and uninterrupted feeling. Below we begin to introduce the ability of cross-page replay of Hema short video and the fluency of smooth animation switching effects.

https://www.youku.com/video/XNTgwNTk4NzQ4MA==
As shown in the video above, after the video is previewed and watched on the list page, the user is likely to continue to click to jump to the next full-screen page and enter the immersive experience. During this process, the video window smoothly enlarged to full screen, the video progress continued, and there was no pause in the video or audio. After the page returns, the video window also has a corresponding restoration effect.

Target

Access is simple, only need to care about and add a parameter, other logic cohesion.
It has good adaptability and supports switching of cropping mode.
Video and audio are seamlessly connected without any pause.
The playback status between pages is isolated and does not interfere with each other.

Implementation plan

In the selection of the scheme, the following three are mainly considered:

At present, Hema uses the third-playerView multiplexing method. Specifically, the realization of seamless replay requires at least the following steps:

1. The user clicks and jumps from page A to page B, such as: domain/path?reusedPlayerView=0xyyyyyy, on the basis of the original business parameters, add a reusedPlayerView parameter, and pass the playerView to the next page.
2. Instantiation of HMTBPlayerView on page B: internally instantiate one or reuse the reusedPlayerView of page A.
3. The size and position of playerView are converted to realize switching animation.
4. When returning to A from page B, exit the animation and return to playerView.

The above steps are not many, but the specific implementation is more complicated. Below we will focus on the process of solving the four main problems to illustrate the specific implementation methods.

Animation of size change

Normally, as long as the original Rect of the playerView and the final Rect are calculated, the frame animation based on the UIView can simply achieve the effect of window enlargement. But when it was implemented, it was found that the setFrame method was rewritten internally in the hand-tao player. As long as the frame is modified, the playerView will directly display the final state, and the animation has no effect.

Therefore, the scale implementation of CGAffineTransform is used here: first set the playerView's frame to the final state, calculate the size ratio before and after the change, set playerView.transform = CGAffineTransformMakeScale (ratio, ratio) , and reduce the size to the initial position size, and then you can execute the transform animation Realize the transformation from the start point to the end point.

It should be noted that the calculation method of ratio here is calculated based on the size of the real rendered video in the playerView, not the size of the playerView itself.

Switching of rendering mode

The video rendering itself can be set to ScaleAspectFit or ScaleAspectFill. At present, in the Hema scene, there is a player of page A that is in fill mode, and the playerView is fixed in square, but when jumping to page B, it becomes fit mode. There has been a problem of mode switching when the size change animation is in progress.

The above method of setFrame and modifying transform can be achieved to transform the playerView size to be consistent with the initial size before the animation. However, if there is a mode switching requirement at this time, the calculated size may be inconsistent, such as from a 9:16 rectangle The playerview becomes a 1:1 square playerView with a mode of fill. At this time, the width is the same, but the height is obviously higher. Direct animation will cause the initial state to flicker.

The solution here, we use maskView for mode switching transition: first, calculate the scale of maskView in width and height, and then set playerView.maskView.transform . The calculation method is as follows:

CGAffineTransformMakeScale(originalRect.size.width/(destRect.size.width*ratio), originalRect.size.height/(destRect.size.height*ratio))

In this way, the maskView is used to display the 9:16 rectangle as a 1:1 visible area, and the starting position of the animation is overlapped. Finally, combine the above playerView.transform animation, and then add a maskView.transform animation, the two work together to simulate the animation transition effect in the scene with mode switching.

Active recycling and active return strategy

After implementing the approach animation, the most important thing is to consider the playerView reuse logic. One of the more important points is when the playerView will be returned to page A.

At present, we are adopting the idea of renting:

1. If you can borrow playerView, borrow it;
2. When the reused playerview is no longer in use, return it promptly;
3. When the lessor wants to use it, it is found that the lessor has not returned it, so take the initiative to recycle it at this time.

For specific scenarios: when entering the venue, it is judged that there is reusePlayerView, then multiplexing; when the immersive video (page B, similar to Douyin) is turned to the next video, the previous video is actively returned, and if the user goes back again When it comes to the first video, it is the new playerView; in addition, when the user clicks the page to close, it will actively return it (if it has not been returned yet); in particular, an active recycling mechanism has been added here, such as The user returns to page A through some unknown means. At this time, reusePlayerView is not actively returned, but page A itself needs to play. At this time, the active recycling mechanism is triggered to ensure that the current page is available.

One thing that needs to be mentioned is that there is animation when the page returns. The implementation is similar to the above. The only difference is that the page may be dealloc when returning, and the animation will be problematic, so we first add the playerView from page B to window, complete the zoom animation, and then actively return it to page A after the end.

State isolation

When using player multiplexing, an important issue needs to be considered, that is, the isolation of player status and settings after multiplexing. For example, after page A enters page B, the player will continue playing without trace, but the state of the player is paused for A and must be playing for B, although the two use the same playerView.

This kind of isolation is necessary. For example, if a business wants to guide the user into the business on page A, points can be earned by watching the video here, so when he enters page B, he should not continue to settle the points (the business depends on the playback status notification ). In addition, the playback settings of pages A and B may be different, A may be muted, and B may have sound. The settings are different and need to be isolated. We do this, as shown in the figure below (view hierarchy):

In the picture, the outermost view is the player HMTBPlayerView encapsulated by Hema itself, and there is a hand-made TBMPBPlayerView inside, the size of which is the same. What we use for reuse is actually the layer of TBMPBPlayerView, and put all the settings of the business layer in HMTBPlayerView. In this case, when TBMPBPlayerView is removed, set it again according to the new HMTBPlayerView and make the association, while the old HMTBPlayerView Settings are not affected, including player callbacks.

Summarize

In summary, we have implemented a player multiplexing method, and implemented logic such as window switching and state isolation inside the player, which is almost insensible to the App user. This solution can be used not only in the seamless replay scenario, but also in the reuse optimization direction of the global player instance in the App in the future.

"Video Cloud Technology" Your most noteworthy audio and video technology public account, pushes practical technical articles from the front line of Alibaba Cloud every week, and exchanges and exchanges with first-class engineers in the audio and video field. The official account backstage reply [Technology] You can join the Alibaba Cloud Video Cloud Product Technology Exchange Group, discuss audio and video technologies with industry leaders, and get more industry latest information.