VideoChooserBlock

[corysutyak]

HeroBlock would really benefit from having the ability to have full width background videos. For this we would need a VideoChooserBlock that mimics the functionality of ImageChooserBlock, but with video. This would probably require the implementation of our own Video model to house/validate/compress the uploaded files.

[vsalvino]

I'm torn on this idea. As we tried with an earlier version, the CMS is really not suited to compress or process videos as-is without making exec/system calls. I would also not want to encourage the CMS to be used for video management by calling out a "Videos" library similar to "Images" and "Documents".

But I also realize that video backgrounds are not entirely uncommon and a bit clunky to implement as-is. Perhaps we offer the ability to upload a video background, limit the size to like 2MB by default to force the user to compress before uploading. But the video background would be managed directly as a file field in the block and not through a library style interface. Thoughts?

[vsalvino]

Found this which might solve some of these problems: https://github.com/torchbox/wagtailmedia

[thenewguy]

I would be interested in helping to add support around wagtailmedia. Is this still of interest to the project?

This is really the only thing missing from being able to embed any html5 video: torchbox/wagtailmedia#65

And it is a simple problem to fix

[thenewguy]

torchbox/wagtailmedia#65 was fixed by merged pr torchbox/wagtailmedia#67 so now there is an "official" way to output html5 audio/video sources.

There is no longer a need to consider specialized logic around html5 audio/video element source ordering and creation here - it is handled by wagtailmedia and the project's media model.

I would mention that wagtailmedia supports both audio and video, so perhaps use a more indicative block name. Or either provide two blocks - one for audio and one for video - but the overlap in features between audio and video probably only warrants one block which also simplifies the chooser.

Consider https://github.com/videojs/video.js for the playback layer. It offers a sleek look which is customizable and works for audio or video elements plus also supports adaptive streaming (hls and dash) - https://github.com/videojs/http-streaming

If you would like to assign the issue to me, I will complete it with an assurance that you will accept and merge a satisfactory PR

[vsalvino]

Thanks for the info @thenewguy. It would be great to have your contribution if we can iron out the requirements first. Since you seem to know more about wagtailmedia, maybe you could answer a few questions before we decide what to do:

1. Does wagtailmedia provide the ability to transcode/render audio and video? If so how (i.e. ffmpeg subprocess, native python library, etc.)?

2. Would there be some way to limit upload file size of audio/video? Transcoding on the server is fine if we are talking about going from 5 MB of mp4 to webm for compatibility purposes. But large transcoding and compression should definitely be performed by the user before uploading, otherwise it will most likely kill the web server and create massive storage costs if we are storing high-res/uncompressed video plus multiple renditions. That is too far outside the purpose of coderedcms (a platform for marketing sites, versus a platform for video/media library).

Having a media block as you describe which provides a native HTML5 video/audio tag would be a nice addition (similar to our document block which provides a button/download). I don't know if video.js is needed in coderedcms, as the developer could choose to handle the front-end themselves via a custom template - as long as we provided an HTML5-compliant rendering that worked cross-browser. My thought being that 9 out of 10 times the HTML5 player is more than sufficient, especially since it supports a cover image / fallback image (which the media chooser block should provide via a user selection from the image library). I would like to avoid javascript when possible, as it chips away at page load speed and adds more maintenance overhead to the project.

Thanks again for your willingness to undertake this feature!

[thenewguy]

1a)

Wagtailmedia leaves this up to the site implementation. The default case returns the url of the uploaded file and it's mimetype for rendering the html5 element.

The default case assumes the uploaded media is pre-processed for direct ingestion. For example, an mp4 containing h264 baseline video and stereo audio using the aac-lc codec.

The templating is very easy and supports all cases using something like:

<{{ media.type }}>
	{% for source in media.sources %}
		<source src="{{ source.src }}" type="{{ source.type }}" />
	{% endfor %}
	Your browser does not support {{ media.type }} playback: <a href="{{ media.file.url }}">download it instead</a>.
</{{ media.type }}>

giving you something like:

<video>
	<source src="/path/to/94acbdf7a671398263a680d19492a5f5fc05d175.webm" type="video/webm" />
	
	Your browser does not support video playback: <a href="/path/to/94acbdf7a671398263a680d19492a5f5fc05d175.webm">download it instead</a>.
</video>

or

<audio>
	<source src="/path/to/foo.m4a" type="audio/mp4" />
	
	Your browser does not support audio playback: <a href="/path/to/foo.m4a">download it instead</a>.
</audio>

1b)
However, there is a simple interface to hook into for transcoding/rendering the media if a site wishes to do so. It is fairly straightfoward to support local transcoding or use an external service. Wagtailmedia imposes no restrictions here.

To handle unprocessed video from arbitratry user uploads you just add your 'transcoder' app to installed apps and tell wagtail media to use the swappable media model from the transcoder. It should override the "sources" property to return the transcoded sources instead of the uploaded media.

2 ) Short answer: yes. There are a few ways to limit the upload size depending on the site needs. Can you share more details about the problem scenarios you are trying to overcome with this?

[vsalvino]

Closing this issue as I think we will not be implementing video features directly in coderedcms. This would be a great opportunity for a 3rd party package as necessary, which could be hooked in via features described in #305