bug(YouTube - Spoof video streams): Android VR client side effects (Livestreams start from beginning, Videos end 1 second early)

[MarcaDian]

Bug description

If the Spoof video streams and Android VR client is enabled, livestreams start from the beginning and videos end 1 second earlier.
(Maybe other iOS side effects as well.)
ReVanced patches v5.3.0

Screenrecorder-2024-12-09-14-45-40-517.mp4

Error logs

Solution

No response

Additional context

No response

Acknowledgements

• I have checked all open and closed bug reports and this is not a duplicate.
• I have chosen an appropriate title.
• All requested information has been provided properly.

[LisoUseInAIKyrios]

Both of these are known iOS issues. Is this now happening with Android VR?

The one second early issue affects Shorts the most.

[MarcaDian]

Is this now happening with Android VR?

Yes, Added a screenshot and video.

[LisoUseInAIKyrios]

I can reproduce the 1 second issue.

Setting the app language for the Android VR request is what changed.
Reverting that change (or only applying the change to iOS), the 1 second problem is gone.

[LisoUseInAIKyrios]

I tried changing to Android Unplugged instead of VR and it has the same issues when the language code is set (plus the video initially stutters when playing a new video).

A solution is to modify the client logic that picks which audio stream to use and set the preferred language there. Then Android VR could skip setting the language code in the request.

If that cannot be figured out then a temporary fix could be to add a 'Default' language type where no language code is set. That would cause the audio track menu to always show English text for iOS, and for users without the a/b localized audio it would force the original language for all videos. But for users who have the a/b localized language change (which seems likely it will come to all users soon), they will still have whatever audio language the app chooses.

[0xrxL]

@LisoUseInAIKyrios I recently tried to fix this lack by searching a way to restore the original flyout button, and I found a class where the visibility of this button change to true or false, if the size of a list field (that contains all the available audio) tracks is greater than 1.

Maybe you know a way to add more languages to that list, and restore the button visibility. 🤷‍♂️

[LisoUseInAIKyrios]

Does Android VR return more than one audio stream? If the menu entries are missing maybe it can be added as you said.

[0xrxL]

Does Android VR return more than one audio stream? If the menu entries are missing maybe it can be added as you said.

Nope, just return the system language. In fact, once I set the button visibility to true, I was only able to see my region language inside tracks flyout.

More languages can be added...maybe.

[LisoUseInAIKyrios]

The audio tracks menu is now visible and working for Android VR in the player🤔

Yup it sure is. Setting the language (in all uppercase) fixed that.

[LisoUseInAIKyrios]

Yup that too.

[LisoUseInAIKyrios]

Livestreams in progress start from the beginning. Past livestreams and some 24/7 live streams don't show the issue.

Videos ending 1 second early is only noticable on Shorts that run up to the very end. (Video for reference. The joke "soon...with me" is cutoff https://youtube.com/shorts/MH4TCnitr-Q)

[LisoUseInAIKyrios]

Are these completely fixable?

If someone can figure out a fix.

[0xrxL]

Are these completely fixable?

If someone can figure out a fix.

Thanks to a not-merged solution founded by @YT-Advanced, I added an improved version of it on my integrations, to detect if a video is live stream or not.

https://github.com/0xrxL/uDrop/blob/4935f75e5cb18be7b31128586b291d4d0b8a1794/Code/java/uTools/StreamSpoofing/uStreamingDataRequest.java#L112

If you know a way to automatically seek a video to a precise time, you can combine the two things to fix the "live stream start from beginning" issue.

[LisoUseInAIKyrios]

Video information can seek to the end of the video on video start, if it's known to be a livestream.

Sending a language parameter for VR will cause livestreams to start from the beginning, but not sending language causes it to start at the live time. It might be as simple as sending language code but changing some of the returned data to be the same as when no language parameter is included.

The ending 1 second early might be the video length is rounded down from a float to an int, and only affects videos that dont end on exact whole second boundaries. Maybe adding +1 second to the video length could fix it (or maybe break something), not sure.

[oSumAtrIX]

The reason playback starts at the beginning is because in the DASH manifest a parameter is different. It is assumed by others to be a bug in ExoPlayer.

[LisoUseInAIKyrios]

I just noticed the Android VR request is failing, but due to an issue with how it's logged it falls over to iOS without showing any errors when debug is enabled. 🤦

So, this is actually an issue caused by Android VR failing and it falling over to iOS.

Will revert this in a PR soon.

[LisoUseInAIKyrios]

Side effects will be the same as before.

No audio track menu, no stable volume. But no other side effects.

[MarcaDian]

Tried the last PR, selecting the preferred audio track language doesn't work for Android VR, but now livestreams starts correctly.

[LisoUseInAIKyrios]

With Android VR the only way to get the 'original' audio track seems to be if no audio language is specified.

But I don't know if that works for users with the A/B auto selection of localized languages (I don't have that feature). If a user always get the original language when using Android VR then great, but if they still get the localized language then the default audio track option will have to be an iOS spoofing option.

[LisoUseInAIKyrios]

It seems there is no obvious way to force Android VR to use a specific language.

Will refactor the change audio track patch so it only turns off the automatic selection of tracks for iOS and when spoofing is off.

And a default audio track can be selected for iOS spoofing.

[inotia00]

One of the side effects of iOS client - Livestream starts from the beginning - seems to have been fixed in inotia00/revanced-patches@d1b2fe1.

I already checked all experimental flags a few months ago, and didn't find this flag then.

It seems to be an experimental flag that became available after the change to no longer set the Authorization header on iOS client a month ago: #4000

[LisoUseInAIKyrios]

Ending 1 second early is caused by the video length rounded down. Not sure if the rounding is already present when coming across the wire, or if the client is rounding down (it happening on the backend seems more likely).

Maybe could fix by adding 0.95 seconds to each video length (only if the length is already a whole second), but maybe that could cause it's own issues.

iOS:

VideoInformation: New video id: MH4TCnitr-Q
VideoInformation: Current video length: 27000

Android VR:

VideoInformation: New video id: MH4TCnitr-Q
VideoInformation: Current video length: 27477

[LisoUseInAIKyrios]

iOS ending early is fixed by adding just 1ms to the time.

It's probably a difference of YouTube for IOS using < while YouTube for Android using <=

VideoInformation: New video id: MH4TCnitr-Q
VideoInformation: Current video length: 27001
(playback does not end early)

[LisoUseInAIKyrios]

Manually padding out the video time fixes iOS...but only if the video was recently opened with spoofing off or was spoofing with Android VR.

I assume it's caching the video data from the prior request, or the video length isn't being modified in quite the right place.

Not as simple as it first appeared and needs more inspection.

[MarcaDian]

@LisoUseInAIKyrios inotia00/revanced-patches@e0b6d33

[YT-Advanced]

For more information, the videoLength is extracted from approxDurationMs (appear in format and adaptiveFormats). By default, the videoLength will extract from format first, then fallback to adaptiveFormats. However, in IOS Client, streamingData don't have format in its response, so the videoLength is extracted incorrectly.