Using various browser extensions allows download of YouTube content as audio M4a format.
However, according to this post
https://superuser.com/questions/837067/convert-youtube-dash-audio-youtube-dl-to-m4a-aac-dl/837076#837076
the M4a codec is DASH, which is not widely recognized / built-in (yet) to players such as VLC.
Reading into the meaning of container, the above post seems to suggest that if one could change bytes 8 to 11 from DASH to MP4 then the file would immediately be playable..?
I tried this with a hex editor, but the file was not rendered playable in VLC.
Am I missing something basic (for example, deleting byte 11 - I made it 00?), or is there a lot more to it?
PS - I was able to convert the file using Foobar2000 1.37beta and the MP3 convert ability, but a hex editor would be faster for my purposes.
Related
Is there any way to stream mkv files on webpage using javascript/html or any other technologies? I found many questions about this, but I really want to know the answer - is this possible in any way? Maybe ajax, javascript, php, html? Maybe some external libraries? Anything?
I was wondering how youtube works. Is there possible to upload mkv file? Is so, how that videos are streaming to end user?
I know that browser doesn't support mkv natively, but maybe is some way to forcing html to do that?
Any help will be appreciated.
YouTube most probably works using the DASH protocol format. On the server side, the source audio and source video are separately divided into segments of different bitrate/quality. A manifest keeps an index of all possible segments values and their location. This allows to switch quality during playback in the player.
On the client side, the DASH (should be the same with the other main technology: HLS) manifest is used by the player to locate the segments to load in order to feed the content in two separate SourceBuffer, one for audio and one for video and both are being played synchronously together in the MediaSource. For an example player that handles this, see the Shaka Player developed by Google.
Conclusion, there is no need to use a container like mkv but each channel (video, audio) needs to point to a browser supported codec encoded segments.
You don't need anything special for streaming pre-recorded media files. A normal HTTP/1.1 or HTTP/2 server will work just fine. The browser is generally capable of seeking into the file using range requests.
Matroska (MKV) is a container format, and it actually is widely supported because it's basically the same as WebM. WebM is a subset of Matroska... the key differences being that there are suggested codecs for use. (Matroska itself supports almost anything.)
Your audio and video tracks in the file can use a variety of codecs... the key is to use codecs compatible with browsers. Opus for audio and VP8 for video will take you far.
From there, simply reference your video file in a <video> tag.
First, I apologize as I'm essentially new to working with audio.
The web application I currently work on, designed using asp.net/vb.net, allows users to record and play back audio using the Nanogong applet (http://nanogong.ust.hk/doc_faq.html). We are shifting over to HTML5 audio as support for the NPAPI plugin has been removed from most browsers (except Firefox until the end of this year).
Nanogong uses 4-bit IMA ADPCM to encode wav files. I'm able to convert the Nanogong wav file into 16-bit PCM using sox, and then using that wav file create an ogg version using oggenc2 and an mp3 version using lame. We need the ogg files for Firefox and Chrome, and the mp3 for Safari.
What I would like to learn is why browsers do not seem to be able to play the 4-bit IMA ADPCM format? Can they only play PCM format in 8-bit or 16-bit? In Firefox, firebug indicates the IMA ADPCM wav file cannot be decoded; Chrome and Opera don't mention anything in the developer console, but I'm guessing it's the same as Firefox since the file won't play in those browsers.
I've tried searching the web but there doesn't seem to be a whole lot about HTML5 audio, or most of it seems to be older information. I also see more articles about converting from PCM to ADPCM.
Any guidance or resources would be greatly appreciated. Thanks!!
Browser vendors are not required to support any particular audio format. There are issues such as licensing, although perhaps not so relevant in this case, which make vendors only support the most basic (such as uncompressed PCM) and common formats (MP3, OGG etc.), and in some cases would rely on the underlying system to decode audio (or video). Size of code base relative to gain could be another factor.
4-bit IMA ADPCM would fall into the category "not so common" as of today which is likely why there is no support to find in the browsers.
It's possible to get around this though by supporting the format manually using Audio API (which eliminates IE) and binary parsing/decoding. I am doing this is my audio-reader-js library but currently I have no support for IMA encoded data. It can be used as a basis though to implement support for this as well.
I am trying to make a simple node-webkit app that lets you play .avi videos (which should work both on windows and mac). Is there a way to do this with node-webkit?
It is unlikely you will be able to just do this with Node-Webkit. Especially since the official webkit does not support AVI. Your best bet is to use an external application like libav (avplay) or use node to serve a webpage that has a player capable of playing the content and just let the users browser do the work. (Flash is likely still the best way to go, video.js is a good choice)
The alternative is to convert the video to one of the supported formats. I would recommend mp4. (Once again libav (avconv) comes in handy here.) This still assumes that Node-Webkit has implemented full HTML5 support. (I am not sure what they have completed but I am guessing it supports the video element)
Is AVI supported in Chrome (not Chromium) ?
If it is you have to change the libffmpegsumo.so in nw for the one in Chrome (try to use the same version).
libffmpegsumo.so is called ffmpegsumo.dll in Windows
The file file is in the same folder of the nw executable
to get the file download google chrome and go to %USER%/Google Chrome/ (or something like that) and you'll find the file in the same folder of the google-chrome executable
You can wcjs-player to play any format video which supported by VLC. It plays any video without any lags as in-built player.
To support my above claim, I have following points:
Building NW (by compiling source code) with various FFMPEG codec flags given at nw github site, doesn't help, in getting ffmpegsumo.dll which can play avi file format.
wcjs-player uses VLC libraries, which support all video played by VLC does.
Its better than using any nw plugin, as internally wcjs-player using VLC does similar job as HTML native video support .
Even if you suceed playing avi files, sometimes supported videos file format may not get played like most ironically mp4 file itself.
Apart from this, Teewe Theatre, Popcorn Time , Butter are among NW based media player using wcjs-player. It hardly increased 30 MB size of overall app size.
I use JWPlayer to play videos from the server. Videos are encoded using h.264 codec. If i open them in browser with h.264 support - video plays nicely and i can seek it, because server returns 206 header browser understands that its partial content. But if i try to play same video on Opera, for example, flash player is being used and it receives 200 OK! 2 problems here:
I can't seek the video, until part of it is downloaded
If the video is not "properly" encoded player can't even start playing it, until file is fully downloaded.
Is there something wrong with flash properly asking/understanding http headers?(i've never worked with flash before, so maybe my question is a bit silly and i just don't know flash's limitations)..
1) You need to have pseudo streaming enabled, for Flash - http://www.longtailvideo.com/support/jw-player/28855/pseudo-streaming-in-flash, if you can provide a link though, I will take a look at exactly what is going on here, I am more or less guessing about this one. HTML5 does not require a pseudo streaming module to be installed on the server side, though. In Flash, the default is progressive download, so you can only seek to downloaded parts, and in html5, this is not the case.
2) Yes, that is because of encoding. If your MP4 files cannot be seeked before they are completely downloaded, you will have to fix the MOOV atom (it contains the seeking information) located at the end of your video. Use this little application to parse your videos and add the necessary cue points - http://renaun.com/blog/2010/06/qtindexswapper-2/
Also, encoding via HandBrake - http://handbrake.fr/, can fix this as well, so the above tool wouldn't be necessary. You can encode using HandBrake, and enable "web optimized", which does the same this as the Index Swapper Tool. HandBrake also has command line encoding options as well.
I am using HTML5 audio tag to link to a WAV file, but it suddenly seems to be failing. Chrome does not seem to be able to play WAV files (MP3 works fine). I get an error message like:
Error loading: "blob:http%3A%2F%...."
Does Chrome's audio tag support WAV? For e.g., try playing this: http://www.nch.com.au/acm/11kulaw.wav
I am on Chrome version 15.0.874
I don't get the error in Chrome, but the file does not play. The control is visible, but is not working.
There is a bug report in Chromium project that seems to talk about the behavior:
http://code.google.com/p/chromium/issues/detail?id=83323
The gist of it is that .wav can mean a bunch of things and have various encodings. The comments recommend using a plugin to handle this or downloading the file.
For the purposes of serving it on the web, I'd recommend compressing it to an MP3 and an OGG format (if you want to be nice to FOSS people) and including multiple source tags.
I had this problem with an mp3 audio file that did not play just in Google Chrome (this problem could be happening with other audio format files too, like wav or ogg).
I opened my mp3 file in an audio editor (Audacity) and saved it again in the desired format (in this case, *.mp3).
It works correctly in Google Chrome.
My conclusion: if the audio file does not play, the problem is in the settings that generated the audio. Use another program, with other settings.