For a free system does not seem good thing to embed youtube videos and not free to embed video formats, now that we think good idea implemetarlo html5 video and audio.
In this way we could play videos hosted on our own servers or some mediaglobin server.
We need this output:
Your browser does not implement html5 video.Could a markdown used like this?
!!! [Alt text] (http://myvideo.webm)
Note: This discussion was imported from Loomio. Click here to view the original discussion.
I like your idea. You are right, it would be wrong to support YouTube flash (!) videos, but not html5 video.
Who manages the markdown standard? Are there drafts concerning html5 video, yet?
It is fairly difficult to extend the syntax supported by redcarpet (the markdown library used by Diaspora). This is why for Libertree we use rpeg-markdown, which provides ruby bindings to peg-markdown, a markdown implementation using an extensible grammar (PEG).
I forked the unmaintained rpeg-markdown and forked peg-markdown to implement non-standard syntax for embedding videos and audio files.
The syntax we use for video files is this:
%[caption](URLs to video files)
This is the syntax for audio files:
~[title](URLs to audio files)
The percentage sign looks a little like the progress indicator on a video player; the tilde looks a bit like a waveform.
Here’s the code of the ruby library:
https://github.com/rekado/rpeg-markdown
This is the code of the forked C library with the extended grammar:
https://github.com/rekado/peg-markdown
You are welcome to use this library in Diaspora. peg-markdown is really fast, but it consumes a bit more memory while rendering (freed after completion).
Thank you @rekado for this information, but why Diaspora uses redcarpet instead of rpeg-markdown? I think that if this m↓ is so good, we should promote it and implement it on Diaspora.
Maybe you should make another Loomio discussion talking about it.
Great discussion and work. Ruby is kind of what I learn’t on codecademy so that’s cool I could work with it supposedly.
I also believe that html 5 supports browser data so perhaps a option that when a user uploads a video they can have the option to host on pod database or through their own database. a icon could show to other’s which option the poster chose and then a notification for when the poster is offline saying the media will be available again when there online?
@albertoaru The reason is likely that redcarpet is by far the most popular implementation for ruby. Initially, Libertree used redcarpet, but I decided to switch to peg-markdown when we extended the set of supported syntax. Redcarpet’s parser is a fairly confusing tangle of code; it’s no fun to extend, whereas peg-markdown only requires changes to the formal grammar. The parser code is generated from the grammar.
@williammouck This discussion is about a markdown extension, not about video upload.
Are you sure redcarpet is not extensible? I had a quick glance at the readme and it seems to be.
We only use redcarpet for rendering emails and the mobile site, the desktop version is rendered client side through pagedown.
If we implement this, we need to make sure to make them click to load, to save bandwidth and to not dramatically increase stream render time.
Jonne Haß:
All resources saving ideas seem good, but remember we are talking about external files, not video stay in pods (each pod can make this decision depends resources)
Your say do not load previews? Or are you talking about not autoplay? The autoplay is a bad practice, must be banished
I’m saying to not load the files in the background to save the users resources.
@jonnehass Ah, I did forget about the move to client-side template rendering (I last looked at the code when rendering was still done on the server).
Preloading can be disabled with the attribute preload=none (though the actual behaviour depends on the UA).
And disabling preloading might not be enough, rendering a dozen audio/video players might already quite increase the load on the client.
@jonnehass what makes you think rendering these minimalist players would increase load any more than rendering embedded YouTube video or SoundCloud audio players (or even regular image tags)?
Personal experience, I had it quite a few time that page became sluggish with many video players on them. It’s one of the main reasons we have click to play for Youtube videos already.
To avoid these problems (that I have not experienced myself) you could extend your markdown renderer to only create a dummy UI element which, on click, would be replaced with the appropriate HTML5 snippet.
Either way: the JS renderer would have to be extended.
What is used to create the preview of youtube/vimeo videos? If it’s possible to extend it, it would give us a unified way of presenting videos which would be good out of a design perspective. Moreover, all video previews could then be changed more easily as the diaspora design grows and changes.
oEmbed and a hook whether a video is embedded: https://github.com/diaspora/diaspora/blob/develop/app/assets/templates/oembed_tpl.jst.hbs#L2
I,m think to show youtube video diaspora using oEmbed . Is that so?
In that case I do not think it’s the right choice, to implement previously we need know domains where files host and more data.
The idea is to take advantage of new HTML5 tags and to play media without depending on any platform,
The business able to upload webm or ogg file to any server and display them in diaspora, take advantage of html5 to not need youtube and other corporations. I think we should do it the most simple way possible.
There’s an effort going on about standardizing Markdown, called CommonMark (because Jon Gruber complained about them using his name “Markdown”).
If we extend the MarkDown standard we should stay close to CommonMark which has some chances to become the dominant MarkDown standard. There’s already a discussion about extensions for audio and video going on: http://talk.commonmark.org/t/embedded-audio-and-video/441/4
About the problem with changing the complex parser: Let’s hope Common Mark succeeds, maybe then anybody will write some new parsers for Ruby and Javascript Diaspora* could just adopt.