Change 137529 had a related patch set uploaded by Brian Wolff:
Fix ?embedplayer=yes mode, which is currently totally broken

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

Ugh. Really need to figure out how to do automated testing of this (selenium?)

• Bug 66409 has been marked as a duplicate of this bug. ***

Change 137529 merged by jenkins-bot:
Fix ?embedplayer=yes mode, which is currently totally broken

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

This should hopefully start working again come june 24.

This seems to have made things worse, the blog posts are completely unreadable now.

(In reply to Tisza Gergő from comment #6)

This seems to have made things worse, the blog posts are completely
unreadable now.

Oh wow. That's not good.

Hmm, so this doesn't happen to me locally, and I'm not sure what the cause is yet.

However, issue does not happen for videos at beta, possibly due to c469a916dadc82aa which is not on production.

Ok, what's happening is that $wgBreakFrames = true is on production. My last change that used MW's default loader, caused this code to become active for embedplayer=yes

Change 142085 had a related patch set uploaded by Brian Wolff:
Do not break iframes in the iframe output of TMH

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

(In reply to Bawolff (Brian Wolff) from comment #8)

Ok, what's happening is that $wgBreakFrames = true is on production. My last
change that used MW's default loader, caused this code to become active for
embedplayer=yes

However, i should note that on beta wiki, this doesn't seem to happen, and if you use ?debug=true on commons, the frame breaking also doesn't happen (So I guess somehow load order matters?). On my local wiki the frame breaking also doesn't happen (even after setting $wgBreakFrames = true). Which is odd...

Change 142085 merged by jenkins-bot:
Do not break iframes in the iframe output of TMH

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

Change 142132 had a related patch set uploaded by Gergő Tisza:
Do not break iframes in the iframe output of TMH

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

Change 142132 merged by jenkins-bot:
Do not break iframes in the iframe output of TMH

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

Change 142149 had a related patch set uploaded by Gergő Tisza:
Update TimedMediaHandler with embed breakage fixes

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

Change 142149 merged by jenkins-bot:
Update TimedMediaHandler with embed breakage fixes

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

Fix deployed to Commons, seems to work now. Thanks, Bawolff!

(The first video in https://blog.wikimedia.org/2013/11/08/open-letter-free-access-wikipedia-south-africa/ is still messed up, it is probably included in the blog post in a weird way. I suppose that was workaround for the original bug.)

(In reply to Tisza Gergő from comment #16)

Fix deployed to Commons, seems to work now. Thanks, Bawolff!

Great, works for me too now. Thanks a lot everyone, in particular Bawolff!

(The first video in
https://blog.wikimedia.org/2013/11/08/open-letter-free-access-wikipedia-
south-africa/ is still messed up, it is probably included in the blog post
in a weird way. I suppose that was workaround for the original bug.)

Yes, it was changed as a workaround for this bug last week. But that's actually the way we most often use for videos on the blog (e.g. https://blog.wikimedia.org/2014/05/26/happy-birthday-ward-cunningham-inventor-of-the-wiki/ ) - with basically the same HTML as MediaWiki uses on wiki pages, via a conversion script (https://meta.wikimedia.org/wiki/Wikimedia_Blog/Converting_wiki_pages_to_blog_posts ). One advantage is that this allows to select the still image to be displayed, via the thumbtime parameter, which afaik isn't possible with the iframes (is there a bug for that?).

Yes, it was changed as a workaround for this bug last week. But that's
actually the way we most often use for videos on the blog (e.g.
https://blog.wikimedia.org/2014/05/26/happy-birthday-ward-cunningham-
inventor-of-the-wiki/ ) - with basically the same HTML as MediaWiki uses on
wiki pages, via a conversion script
(https://meta.wikimedia.org/wiki/Wikimedia_Blog/
Converting_wiki_pages_to_blog_posts ). One advantage is that this allows to
select the still image to be displayed, via the thumbtime parameter, which
afaik isn't possible with the iframes (is there a bug for that?).

I don't think there's a bug for that, but its been on my mind that there should be a method of specifying the thumbtime via iframe.

Copying the html is fine, however you need to copy it when using a video of size 800px (or full size if the video < 800px). Otherwise you get the html which opens a popup dialog box, which won't work as well when just copying the html.

i.e. If the html looks like <div id="mwe_player_0" style="position:relative;display:inline-block;width:700px;height:394px" videopayload="...

Then copying the html will result in an image with a play button which links to the original file for download.

If the html looks like:

<div class="mediaContainer" style="position:relative;display:block;width:800px"><video...

Then the video will play in browser using native html5 browser support (Assuming you have a browser that supports ogg or webm).

(In reply to Bawolff (Brian Wolff) from comment #18)

I don't think there's a bug for that, but its been on my mind that there
should be a method of specifying the thumbtime via iframe.

There is now: bug 67165

(In reply to Bawolff (Brian Wolff) from comment #18)

Yes, it was changed as a workaround for this bug last week. But that's
actually the way we most often use for videos on the blog (e.g.
https://blog.wikimedia.org/2014/05/26/happy-birthday-ward-cunningham-
inventor-of-the-wiki/ ) - with basically the same HTML as MediaWiki uses on
wiki pages, via a conversion script
(https://meta.wikimedia.org/wiki/Wikimedia_Blog/
Converting_wiki_pages_to_blog_posts ). One advantage is that this allows to
select the still image to be displayed, via the thumbtime parameter, which
afaik isn't possible with the iframes (is there a bug for that?).

I don't think there's a bug for that, but its been on my mind that there
should be a method of specifying the thumbtime via iframe.

Copying the html is fine, however you need to copy it when using a video of
size 800px (or full size if the video < 800px). Otherwise you get the html
which opens a popup dialog box, which won't work as well when just copying
the html.

i.e. If the html looks like <div id="mwe_player_0"
style="position:relative;display:inline-block;width:700px;height:394px"
videopayload="...

Then copying the html will result in an image with a play button which links
to the original file for download.

If the html looks like:

<div class="mediaContainer"
style="position:relative;display:block;width:800px"><video...

Then the video will play in browser using native html5 browser support
(Assuming you have a browser that supports ogg or webm).

Thanks for these very informative comments! I added some of that to https://meta.wikimedia.org/wiki/Wikimedia_Blog/Guidelines/How_to_post#Method_1:_Reusing_the_HTML_that_embeds_a_video_on_wiki_pages .

However, when I tried this out, reusing the <div class="mediaContainer" ... HTML (from this wiki page: https://meta.wikimedia.org/w/index.php?title=Wikimedia_Blog/Drafts/A_Look_Back_at_Wikimania_2013&oldid=9276912 ) in a separate HTML page, it did not work correctly - the box displays nicely and the video starts playing in the browser (Chromium), but only in low quality
(160p, I guess) instead of the highest possible resolution for this div.

This might be more appropriate for a separate bug - in that case, sorry for the offtopic discussion.

However, when I tried this out, reusing the <div class="mediaContainer" ...
HTML (from this wiki page:
https://meta.wikimedia.org/w/index.php?title=Wikimedia_Blog/Drafts/
A_Look_Back_at_Wikimania_2013&oldid=9276912 ) in a separate HTML page, it
did not work correctly - the box displays nicely and the video starts
playing in the browser (Chromium), but only in low quality
(160p, I guess) instead of the highest possible resolution for this div.

This might be more appropriate for a separate bug - in that case, sorry for
the offtopic discussion.

Weird. That appears to be intentional:

// Sort sources by bandwidth least to greatest ( so default selection on resource constrained
// browsers ( without js? ) go with minimal source.
uasort( $mediaSources, 'TimedMediaTransformOutput::sortMediaByBandwidth' );

Seems like a bad design decesion...

This might be more appropriate for a separate bug - in that case, sorry for
the offtopic discussion.

Yeah it is kind of something that should be a separate bug.

I started on I6f3316477175634a to fix the issue. Basically currently we order the versions of the video file smallest bitrate first. My change would be to have it be smallest bitrate first only for versions with a higher resolution than the player size.