Sun 20 Apr 2014

markdown to play videos html5

JS Juan Santiago Public Seen by 120

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


[deactivated account] Sun 20 Apr 2014

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?


[deactivated account] Sun 20 Apr 2014

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:


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:

This is the code of the forked C library with the extended grammar:

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).


Alberto Aru Sun 20 Apr 2014

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.


williammouck@hushmail.com Sun 20 Apr 2014

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?


[deactivated account] Mon 21 Apr 2014

@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.


lebarjack Tue 22 Apr 2014

Are you sure redcarpet is not extensible? I had a quick glance at the readme and it seems to be.


Jonne Haß Tue 22 Apr 2014

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.


Juan Santiago Tue 22 Apr 2014

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


Jonne Haß Wed 23 Apr 2014

I'm saying to not load the files in the background to save the users resources.


[deactivated account] Wed 23 Apr 2014

@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).


Jonne Haß Thu 24 Apr 2014

And disabling preloading might not be enough, rendering a dozen audio/video players might already quite increase the load on the client.


[deactivated account] Fri 25 Apr 2014

@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)?


Jonne Haß Fri 25 Apr 2014

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.


[deactivated account] Sat 26 Apr 2014

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.


Ivan Gabriel Morén Sun 27 Apr 2014

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.


Jonne Haß Sun 27 Apr 2014


Juan Santiago Sun 27 Apr 2014

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.


Trolli Schmittlauch Sun 21 Sep 2014

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.