/start-pulseaudio-x113) Install extensions. Installation order sometimes matters. ffmpeg, gst-ffmpeg, and the gstreamer plugins need to be in place at the time firefox is started. Perhaps not necessary to on-boot, but this is what I do:

firefox-get is outdated, instead use the updated firefox-latest extension (based on firefox-get) which will auto-detect and create a firefox-official extension based on the latest version of firefox, or a version of your choice if specified for both tc5.x & tc6.x in x86 & x86_64 repo's

The thought now crossed my mind to rename the firefox-latest to firefox-get and continue with updates to that extension ??

If anyone has luck without pulseaudio (ALSA only) or just has a faster/slimmer way, I'll be interested to hear.

[...]

In my case, failed video was due to missing extensions: gst-plugins-ugly with x264 provides mp4 playback. Failed audio was due to an incorrect system audio setup: ALSA alone fails; gst-plugins-good gives firefox access to pulseaudio.

Unfortunately the Firefox extensions in the Tiny Core Linux repos are not built with --enable-gstreamer=1.0 and therefore Firefox can only use the old and outdated GStreamer 0.10 instead of the new GStreamer 1.0 (1.x).

I've asked coreplayer2 to build the Firefox extensions with --enable-gstreamer=1.0 in the respective thread:

http://forum.tinycorelinux.net/index.php/topic,18943.0.html

On Ubuntu 15.10 for example, Firefox is built with --enable-gstreamer=1.0 and then gst-plugins-ugly does not seem to be needed. gst-plugins-base and gst-plugins-good seem to suffice when using GStreamer 1.0 (1.x), at least on Ubuntu.

So, it would be really nice if coreplayer2 would build the Firefox extensions with --enable-gstreamer=1.0.

Ah - of course. I think coreplayer2 has focused on wrapping pre-built binaries

The official Linux binaries from Mozilla are not built with --enable-gstreamer=1.0 yet, see:

https://bugzilla.mozilla.org/show_bug.cgi?id=947287

As you can read over there, currently it's still up to the distro maintainers to decide whether or not they build Firefox with --enable-gstreamer=1.0, since apparently some distros still are relying on the old and outdated GStreamer 0.10 and do not have the new GStreamer 1.x in their repos yet.

Ubuntu for example has GStreamer 1.x and it has Firefox built with --enable-gstreamer=1.0.

Since Tiny Core Linux also has GStreamer 1.x in it's repos already, it should also have it's Firefox extensions built with --enable-gstreamer=1.0 IMHO.

On Ubuntu for example, Firefox is built with --enable-gstreamer=1.0, so that it uses the new GStreamer 1.x.

So, it would be nice if firefox-ESR.tcz and firefox-getLatest.tcz would also be built with --enable-gstreamer=1.0, so that Firefox on Tiny Core Linux would also use the new GStreamer 1.x.

For the 5.x x86_64/6.x x86_64 repos this would even be mandatory for MP4 playback in Firefox, because the 5.x x86_64/6.x x86_64 repos do not have gst-ffmpeg.tcz (which would be for GStreamer 0.10). They only have gst-libav.tcz, which is for GStreamer 1.x.

By the way:

Starting with Firefox 43 or 44, Mozilla seems plan to do MP4 (H.264/AAC) HTML5 video on Linux directly via FFmpeg/Libav instead of GStreamer, so that GStreamer will no longer be needed, see:

https://bugzilla.mozilla.org/show_bug.cgi?id=1207429

Actually I have just tested the latest Firefox Nightly 44.0a1 on Ubuntu and set media.gstreamer.enabled to false in about:config and completely uninstalled GStreamer and Firefox Nightly 44.0a1 could still play MP4 (H.264/AAC) via HTML5 and all the boxes on youtube.com/html5 were still checked :) :D.

So, GStreamer indeed is no longer required with Firefox 44 to be able to play MP4 via HTML5 :). The only thing that needs to be installed is FFmpeg/Libav and then Firefox 44 can play MP4 via HTML5 :). From reading https://bugzilla.mozilla.org/show_bug.cgi?id=1207429 and all the associated bugs, it seems like this might actually even work on Firefox 43 already, but not sure, I've only tested Firefox 44.

Anyway:

Since it will take quite a few more weeks for firefox-getLatest.tcz to reach version 43 or 44 and even months for firefox-ESR.tcz to reach version 45 (the next ESR version (https://wiki.mozilla.org/Enterprise/Firefox/ExtendedSupport:Proposal#Version_Numbers)), it would still be nice if firefox-ESR.tcz and firefox-getLatest.tcz would be built with --enable-gstreamer=1.0 until then.

If that would be easy, then it would be nice if you could do it.

But if it would involve a lot of extra work, then I'd say it might probably be better to simply leave it as is and simply wait for Firefox to reach version 43 or 44 and for Firefox ESR to reach version 45, since it will no longer need GStreamer then ;).

1: provide an effective means to install the latest firefox release from scratch2. provide ability to update a previous installed firefox version to the latest release3. minimize the confusion from having various firefox versions in the repo

We accomplish this with a script "firefox-getLatest.sh" which downloads the latest stable prebuilt Firefox binary release (and if specified in a users language) direct from Mozilla. Then package the extension per tinycore's specifications for immediate use.

To cut a long story short; While Mozilla continue to provide prebuilt stripped and stable firefox binaries, we have no requirement to compile our own binaries. therefore compiling with the --enable-gstreamer=1.0 option is a request for upstream Mozilla.

I'm working on a build script that works with gstreamer-1.0. x86_64 repo doesn't currently have all the 0.10 plugins, and, though I've packaged all those already, I'm not sure it's worthwhile putting up the older plugins when the 1.0 stream may be more valuable long-term.

At the very least, this will remind me of why building firefox is not ... desirable. (big/time-consuming build)

Is there something that can use vaapi?Or even better a button like in the fifth browser which just starts mplayer for video and sounds?Or perhaps best a conversion of video and audio objects into simple <a href> links...

Sorry if it sounded like a complaint. be sure i'm trying to just cooperate efficiently.

So far i've been using opera. in there when i right-click->n->enter it pushes the current page's url to xdg-open.

quvi and mplayer would be run automatically from xdg-open (in my case it's just a 10 lines shell-script).But quvi broke regularly and required a lot of updating so far, it is site-specific and i hope in the time of html5 video there's a chance it will become unnecessary to use programs like quvi and youtube-dl, which would spare me from having to update them all the time.

my last workaround was running fifth from xdg-open instead which then shows me a nice "stream" button in html5 video objects that would then give on the url to mplayer. But even that was broken by youtube.

my last workaround was running fifth from xdg-open instead which then shows me a nice "stream" button in html5 video objects that would then give on the url to mplayer. But even that was broken by youtube.

It was? I last downloaded a video from there two days ago, though I can't use the stream function on Youtube (mplayer doesn't support https). It's just a pain that Google changes their SSL certs several times a week.

You're right, sadly it doesn't work with mplayer directly. I used to run wget -O - | mplayer -but now that also broke because of some seek issues. It should be trivial though to change it towget -q -O /tmp/yt & (sleep 3; mplayer /tmp/yt)

I'll give you an example of my issue with youtube though: I get a rendering that looks like CSS is disabled and the message "This video is unavailable."

This now triggered deeper investigation. It might be related to the SSL problem you mentioned. I removed the whole .fifth folder and youtube started working again (perhaps cause the javascripts and css files come with a different certificate?).

Now with new SSL providers giving out certificates that are good for only few weeks certificate pinning sadly got less useful for the general internet :(

One issue I have on youtube still is that clicking the "Stream" button is kind of difficult cause there's that defunct play button from youtube blocking most of it ;)

Some sub-sub-resources don't trigger the SSL error screen for some reason. Youtube serves CSS and images via two subdomains, s.ytimg.com and i.ytimg.com. So, as a temp workaround, you could change the fifth startup script to delete ~/.fifth/certs/{*google*,*ytimg.com} before starting it.

Adding an insecure mode, even in the form of site/domain exceptions, would be bad security design, easily hijackable by malware or misclicks.

edit: Creating an insecure minitube-like app using webkitfltk would be easy though, only for youtube use. Might I interest you in webkit app making? ;) See the testapp in webkitfltk sources, it's a single-window browser sample, with the same video functionality, but without a SSL callback it will accept all certs.https://github.com/clbr/webkitfltk/blob/fltk/Source/WebKit/fltk/testapp/testapp.cpp

Tweaking the style's z-order so the buttons are always on top is a TODO, in the long long TODO list...