I'm researching on adaptive streaming platform, I would like to ask if there is the possibility to use the subtitle (caption) channel to displays with video.js formatted(CSS) information about the current video-clip.
For example: in my case i use to transmit a musical video-clip playlist and i would like to present the current artist with a css-box with infos about.
I currently use GPAC stuff to send adaptive mpeg-dash videos, i would like to know if there is a way to send through caption channel the infos i need to display for each video inside a css-box instead the standard format for caption.
provisory link www.allibrante.com
Thanks a lot!
MPEG DASH supports subtitle information, either as a separate file or in the mp4 container.
There are different formats defined for subtitles but from the description of your needs, it sounds like W3C TTML would be a good match.
This supports CSS for styling the text - the specification includes examples like this:
<region xml:id="r1">
<style tts:extent="306px 114px"/>
<style tts:backgroundColor="red"/>
<style tts:color="white"/>
<style tts:displayAlign="after"/>
<style tts:padding="3px 30px"/>
</region>
...
<p region="r1" tts:backgroundColor="purple" tts:textAlign="center">
Twinkle, twinkle, little bat!<br/>
How <span tts:backgroundColor="green">I wonder</span> where you're at!
</p>
The full spec is available here (at the time of writing): https://www.w3.org/TR/2018/CR-ttml2-20180313/ and you can see some discussion and examples here: https://github.com/rbouqueau/TTML_in_MP4_DASH_statement
Here's my prototype of such an approach:
https://weasel.firmfriends.us/DualSubs/
(It does have the VTT-limitation of not working in Firefox and Edge, but
it works fine in Chrome and Opera. Personally, I can live with that, so I'm planning to integrate it into my multi-video-viewing production pages.)
See the similar thread discussion here:
Videojs displaying a custom message without using any plugin
EDIT: Today (11-JUL-2018), I filed a bug report to Mozilla, here: https://bugzilla.mozilla.org/show_bug.cgi?id=1474975
(I didn't bother filing a bug against Edge...imho, they don't complete in the same league with Opera and Chrome, and probably never will.)
Related
Some glyphs that are shown on the Google Fonts specimen sheet are not available once the font is implemented on a site.
For example, look at this preview for Piazzolla:
https://fonts.google.com/specimen/Piazzolla?preview.text=piazzolla%20%E2%84%A6%E2%86%92%E2%86%92%E2%86%97%E2%86%97&preview.text_type=custom&query=piazzolla#standard-styles
Notice how the arrows are using the custom glyph provided by the font.
Then, compare that to this codepen that uses the same font, but the arrows are not using the same glyph.
<div></div>
(random code block to appease stackoverflow because there is no code that needs to be embedded in the question.)
This leads me to believe that Google is not serving up the entire font, and there might be a way to have access to more characters.
Any help would be greatly appreciated. Thanks!
The GF API has an advanced feature for this, but you have to closely read the manual (https://developers.google.com/fonts/docs/getting_started) and know how to use the API to do what you want.
Here's a working demo using the arrows in IBM Plex:
https://jsbin.com/neheyuxira/2/edit?html,output
And a fork of your page with the same technique applied
https://codepen.io/davelab6/pen/bGRpJQP
The trick is to add a API URL first that uses the text API feature to specify the unicodes you want (URL encoded, eg with https://r12a.github.io/app-encodings), and then the regular API URL.
<link href="https://fonts.googleapis.com/css?family=IBM+Plex+Mono|IBM+Plex+Sans|IBM+Plex+Sans+Condensed|IBM+Plex+Serif&text=%E2%86%B3" rel="stylesheet">
<link href="https://fonts.googleapis.com/css?family=IBM+Plex+Mono|IBM+Plex+Sans|IBM+Plex+Sans+Condensed|IBM+Plex+Serif" rel="stylesheet">
Context
I usually set up quick GitHub pages to document a few developments I do. They are usually very simple pages, which I generate from the repo settings using the Page Generator. I want to continue using this method, as moving to proper gh-pages with jekyll is too much of an overhead for something so simple.
Recently I came across a use case, where adding a simple 2 min video to the first section made a lot of sense. Not knowing any native markdown for HTML video I've decided to add the HTML code directly as I do in a lot of other situations:
<video width="640" height="400" controls preload>
<source src="https://github.my.company.com/Org/sample/blob/master/intro.mp4?raw=true"></source>
</video>
Problem
When I generate the page the tag is not there, which normally happens when the video tag is not supported. If I open the chrome console and edit the HTML directly, as expected, the video shows fine and I can play it, etc.
I can only assume that GitHub markdown engine, is removing the video tag because the context in which is running does not support video (headless, non-compatible agent, whatnot).
Since GitHub says it supports native HTML into page rendering, there's no specific markdown to say "DO NOT PARSE THIS AT ALL COSTS", leaving me without many options left.
Question
Has anyone come across this issue, and do you know if it's possible to have a video tag in a generated page without moving on to Jekyll?
As a quick solution to encounter this issue: you can convert your video into gif using any converter then insert it in your markdown ex:
## Website Overview
You can delegate all the heavy job to a video hosting service.
Advantages are :
they do all the html video / flash fallback for you
they can serve proper encoding / bandwith depending on device / network
they have specialized CDN that ensure good delivery (? depends on carrier but
you cannot know)
Everybody in the industry delegates the pain of video management.
And the only code you have to add is something like this :
<iframe width="420" height="315" src="//www.youtube.com/embed/KgLfpnPdqZw" frameborder="0" allowfullscreen></iframe>
I am trying to figure out if there is a way to use LESS or SCSS without having to save the document or refresh the browser. At the moment I use CSS Edit which is great for live previews but I cant find a way to get the live previewing to work with LESS or SCSS. My ideal situation would be to get a truely live (or as close to) setup working with Textmate and my broswer. I have looked at a few options, WebPutty is great but it's in Beta and web based so I'd love a solution that could fit into my existing workflow.
Many thanks
This might be what you're looking for: livereload.com
I only just found this myself while Googling for the same problem, Haa!
It's currently only for 64-bit Macs. Its also in beta..
Windows version under dev.
Can't seem to find a link to the v1 that is mentioned on the site?
If you're using static files you can use this code taken from http://f.cl.ly/items/0y2G351r3O3T3j1b401u/Live-LESS-previewing-in-Espresso.html
<!-- Link directly to LESS stylesheet first -->
<link rel="stylesheet/less" href="style.less" type="text/css" media="screen" />
<!-- Then link to LESS, and enable development watch mode -->
<script src="less-1.2.1.min.js" type="text/javascript"></script>
<script type="text/javascript" charset="utf-8">
less.env = "development";
less.watch();
</script>
<!-- Voilà! Instant LESS previews in Espresso -->
However, if you are using localhost, I've not figured out how to get this to work yet.
Check out EDGE. http://getedge.io - it let's you live edit Sass and LESS files from Sublime Text or Textmate. No need to save the file - it updates as you type. You can sign up for the private beta right now.
There is no complete solution for what you are looking.
Chrome dev tools (with sass source maps enabled) is your best bet but I don't think you can do mixins
http://livestyle.emmet.io/ is another option you might want to try
Brackets works well with live changes but applies only for chrome
Here's what I do and it serves the purpose and works like a charm in mac/pc and linux
Have one terminal open that does sass --watch
Have another terminal/app that lets you run live-reload
Your sass will compile and as soon as your stylesheet changes all your browsers get refreshed
But you can't do style injection with this, meaning the page WILL refresh (if you want to theme dialogs, you will have to open them again) But there are other tools available for style injection as well
Hope this helps!
live.js is your solution :)
It doesn't not only work with html, js, css but also less.
You have to trick it with filetype of css:
<link rel="stylesheet/less" type="text/css" href="stylesheets/main.less.css">
Tried the bookmark version on rails local server. Works a breeze!
CssRefresh
My co-worker and I whipped up http://less2css.org the other day. Allows you to choose the version and see your less converted in realtime.
Hope it helps someone.
I think there is no such add-on right now, but I'm also a fan of Live CSS Editor (if that's what you meant by CSS Edit).
I think it would be useful to have something similar with SASS or LESS support, so I made a quick prototype for such Chrome add-on (analogue to Live CSS Editor). It includes syntax highlighting and LESS support with use of client-side LESS library. It's not user-friendly yet so not a candidate to the Chrome Store, but here is it's Google Code Project where it can be downloaded and loaded into Chrome as unpacked extension. I'll try to improve it over time, but anyone else can try too ;)
Screenshots and a bit more are in this blog post.
How does the Reader function of Mobile Safari in iOS 5 work? How do I enable it on my site. How do I tell it what content on my page is an article to trigger this function?
A lot of the answers posted here contain false information. Here are some corrections/clarifications:
The <article> element works fine as a wrapper; Safari Reader recognizes it. My site is an example. It doesn’t matter which wrapper element you choose, as long as there is one, other than <body> or <p>. You can use <article>, <div>, <section>; or elements that are semantically incorrect for this purpose, like <nav>, <aside>, <footer>, <header>; or even inline elements like <span> (!).
No headings are required for Reader to work. Here’s an example of a document without any <h*> elements on which Reader works fine: http://mathiasbynens.be/demo/safari-reader-test-3
I posted some more details regarding my findings here: http://mathiasbynens.be/notes/safari-reader
I've tested 100 or so variations of this on my iPhone in order to figure out what triggers this elusive Reader state. My conclusions are as follows:
Here is what I found had an impact:
Having around 200 or more words (or 1000 characters including whitespace) in the article you want to trigger the "Reader" seems necessary
The reader was NEVER triggered when I had less than 170 words; although it was sometimes triggered when I had 180 or 190 words.
Text inside certain elements such as <ol> or <ul> (that are not typically used to contain a story) will not count towards the 200 words (they will however be displayed in the reader if the reader is triggered for other reasons)
Wrapping the 200 words in a block element such as a <div> or <article> seems necessary (that said, I'd be surprised if there were any websites where that was not already the case)
For full disclosure, here is what I found did NOT have an impact:
Whether using a header or not
Whether wrapping the text in a <p> or letting it flow freely
Punctuations (ie removing all periods, commas, etc, did not have an impact)
It seems the algorithm it is based on is looking for p-Tags and it counts delimiters like "." in the innerText. The section (div) with the most points gets the focus.
see:
http://lab.arc90.com/experiments/readability/
Seems to be the base for the Reader-mode, at least Safari attributes it in the Acknowledgements, see:
file:///C:/Program%20Files/Safari/Safari.resources/Help/Acknowledgments.html
Arc90 ( Readability )
Copyright © Arc90 Inc.
Readability is licensed under the Apache License, Version 2.0.
This question (How to disable Safari Reader in a web page) has more details. Copied here:
I'm curious to know more about what triggers the Reader option in Safari and what does not. I wouldn't plan to implement anything that would disable it, but curious as a technical exercise.
Here is what I've learned so far with some basic playing around:
You need at least one H tag
It does not go by character count alone but by the number of P tags and length
Probably looks for sentence breaks '.' and other criteria
Safari will provide the 'Reader' if, with a H tag, and the following:
1 P tag, 2417 chars
4 P tags, 1527 chars
5 P tags, 1150 chars
6 P tags, 862 chars
If you subtract 1 character from any of the above, the 'Reader' option is not available.
I should note that the character count of the H tag plays a part but sadly did not realize this when I determined the results above. Assume 20+ characters for H tag and fixed throughout the results above.
Some other interesting things:
Setting for P tags removes them from the count
Setting display to none, and then showing them 230ms later with Javascript avoided the Reader option too
I'd be interested if anyone can determine this in full.
Both Firefox and Chrome have the similar plugin named iReader. Here is its project with source code.
http://code.google.com/p/ireader-extension/
Read the code to get more.
I was struggling with this. I finally took out the <ul> markings in my story, and viola! it started working.
I didn't put any wrapper around the body, but may have done it by accident.
HTML5 article tag doesn't trigger it on my tests. It also doesn't seem to work on offline content (i.e. pages saved on your local machine).
What does seem to trigger it is a div block with a lot of p's with a lot of text.
The p tag theory sounds good. I think it also detects other elements as well. One of our pages with 6 paragraphs didn't trigger the Reader, but one with 4 paragraphs and an img tag did.
It's also smart enough to detect multi-page articles. Try it out on a multi-page article on nytimes.com or nymag.com. Would be interested to know how it detects that as well.
Surprising though it may be, it indeed does not pay any attention to the HTML5 article tag, particularly disappointing given that Safari 5 has complete support for article, section, nav, etc in CSS--they can be styled just like a div now, and behave the same as any block level element.
I had specifically set up a site with an article tag and several inner section tags, in prep for semantic HTML5 labeling for exactly such a purpose, so I was really hoping that Safari 5 would use that for Reader. No such luck--probably should file a bug on this, as it would make a great deal of sense. It in fact completely ignores most of the h2 level subheads on the page, each marked as a section, only displaying the single div that adheres to the criteria mentioned previously.
Ironically, the old version of the same site, which has neither article, section, nor separating div tags, recognizes the whole body for display in Reader.
See Article Publishing Guidelines.
Here are APIs about how to read and parse: Readability Developer APIs. There's already a project you can refer: ruby-readability.
A brief history:
The Safari Reader feature since Apple's Safari 5 browser embeded a codebase named Readability, and Readability started off as a simple, Javascript-based reading tool that turned any web page into a customizable reading view. It was released by Arc90 (as an Arc90 Lab experiment), a New York City-based design and technology shop, back in early 2009. It's also embeded in Amazon Kindle and popular iPad applications like Flipboard and Reeder.
I am working on algorithms for cleaning web-sites from information "waste" similar to Safari Reader feature. It's not so good as readability but has some cool stuff.
You can learn more at smartbrowser.codeplex.com project page.
Update: Please disregard, my problem was caused by an advertisement bar being inserted by the vendor who provides my workplace wireless service.
I was building a mobile friendly website and wanted to use HTML 5. However when I specify the doctype as <!DOCTYPE HTML> , I get a gap at the top of the page on safari on the iphone.
I notice that other sites have the same problem such as nextstop.com and nike.com
I guess safari does not fully support HTML 5 yet. Anybody know of a workaround?
HTML 5 is still in a very unstable state. Don't use it in a production environment.
Edit Just so you guys know what it's about, HTML 5 is currently an Editor's Draft, and the document clearly states (in the Status of This Document section) that this specification is not stable, and that a consensus may not have been reached on any of the proposed sections. I think it should be clear enough that it means it's a bit early to start using it.
All browsers correctly interpret the HTML doctype. Putting it in sets your browser into Standards Compliant mode, that is the only difference with or without the doctype.
You can use a CSS reset tool like http://meyerweb.com/eric/tools/css/reset/ to get rid of default margins and padding on all elements.