Bridgy Publish to Flickr: detect u-video and post video

[tantek]

Similar to Bridgy Publish to Flickr u-photo support, Bridgy Publish to Flickr should (before photos) try to detect u-video and if found, post a video to Flickr.

E.g.
http://tantek.com/2015/346/t3/world-of-laughter-tears-hopes-fears

Many more indieweb video posts now at:
https://indiewebcamp.com/video#IndieWeb_Examples

Related: #572 #573

[snarfed]

👍

the catch is that it looks like the flickr video API requires you to upload the video, ie it can't fetch the video from a URL. this is tricky because videos tend to be big, which means:

• the publish request would block while we download the video from your site and upload it to flickr. this could take a little while.
• alternatively, we could use the task queue to upload the video in the background. that would be noticeably more development work.
• our frontends are both memory constrained and don't have access to a filesystem. we'd need to either stream the download directly into the upload or stage the video in cloud storage (like S3).

[snarfed]

huh, actually, streaming upload evidently isn't so hard after all. @kylewm makes it look pretty damn effortless in our current flickr photo upload. here are the read and write parts. it's just:

requests.post(upload_url, data=data, files={'photo': urllib2.urlopen(video_url)})

the key point is that requests.post supports streaming via file objects. thanks @kylewm!

[snarfed]

done!

[tantek]

Very nice! Thank you!
Minor nit, not sure of the best way to fix this:
This POSSE copy: https://www.flickr.com/photos/tantek/24235088549/
starts with the text "a video", which is from inside the <video> tag with u-video.
According to HTML5, if a user agent (browser, crawler - Bridgy's HTML parsing code in this case) supports the video tag, then it must ignore the content inside, since that's only for browsers / UAs that don't support the video tag.
Alternatively you could pushback and say Bridgy requires no text content inside video tags, which is a bit limiting for publishers, but may actually be the 90%+ case (no idea, just guessing).
Will open a separate issue to track.
Update: Issue #612