Page MenuHomePhabricator

TMH player defaults to very small .ogv even when it has native webm playback
Closed, ResolvedPublic

Description

We recently experimentally turned on low-res 360p and 160p .ogv transcodes (bug 61690) but discovered that the TMH player widget was aggressively picking the 160p size when it should be playing back nice big native webm.

As a result we're temporarily going to revert the enabling of the small sixes.

We have to investigate to see how the selection is being done in the player and make sure we only dig out small .ogvs when we need them.


Version: unspecified
Severity: normal

Details

Reference
bz61760

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 3:01 AM
bzimport set Reference to bz61760.

mdale wrote:

That sounds very odd. Not only picking off over webm but also the small size? Was this playback without any cookie that would have saved a user preference ?

Yes, there are no size-preference cookies that I can find present.

Created attachment 14656
Screenshot of tiny player on non-tiny video

Attached:

Screen_Shot_2014-02-21_at_2.08.54_PM.png (1×1 px, 641 KB)

Oh nice, Bugzilla ate my comment.

https://commons.wikimedia.org/wiki/File%3AJarry_-_M%C3%A9tro_de_Montr%C3%A9al_%28640%C3%97360%29.ogv <- shows me a player sized to 284x160px, but if I actually right-click and 'view video' it's pulling up the 360p webm.

I can't find any cookies that appear to have size preference information, either, but really the player shouldn't be sized to source video, it should be sized for comfortable fit in the window anyway...

Change 114918 had a related patch set uploaded by Mdale:
bug 61760 get the largest size ( not just the last transcode in the list )

https://gerrit.wikimedia.org/r/114918

mdale wrote:

getMaxSizeWebStream appears to be dependent on sizes being listed small to large:
https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FTimedMediaHandler/ed8e92e7f72f788575baf6fff767dfc0ec74c81f/WebVideoTranscode%2FWebVideoTranscode.php#L317

to fix we should put > max size check before assignment:
https://gerrit.wikimedia.org/r/#/c/114918/

and or we can put the new transcodes in "order" just to be on the safe side ;)

Change 115094 had a related patch set uploaded by Brion VIBBER:
Fix popup video size by ordering transcode settings properly

https://gerrit.wikimedia.org/r/115094

Change 115094 merged by jenkins-bot:
Fix popup video size by ordering transcode settings properly

https://gerrit.wikimedia.org/r/115094

(In reply to Gerrit Notification Bot from comment #8)

Change 115094 merged by jenkins-bot:
Fix popup video size by ordering transcode settings properly

https://gerrit.wikimedia.org/r/115094

This config change is now deployed, but I guess gerrit 114918 means this should remain as PTR…

Yeah I'll merge that once I've tested it on my setup with the unsorted array. It's just waaaay easier to deploy the config change than deal with backporting the actual fix to live branches so I did that first. :)

Change 114918 merged by jenkins-bot:
bug 61760 get the largest size ( not just the last transcode in the list )

https://gerrit.wikimedia.org/r/114918

All patches mentioned in this report are merged - is there more work left to do here (if yes: please reset the bug report status to NEW or ASSIGNED), or can you close this ticket as RESOLVED FIXED?

No reply to comment 13.
All patches mentioned in this report were merged or abandoned - assuming this bug is FIXED. If that is not the case: Please reopen and elaborate what is left to do here to get this report fixed.