Comments (9)
I think what would be nice is a separated NPM module for this that would be named
something like chromecast-compatible
. And it would work somehow like this:
var ccCompatible = require('chromecast-compatible');
ccCompatible('http://foo/bar.mkv', function(err, video, audio, meta) {
if (video && audio) // the file can be played on chromecast
if (!video) // the video codec is incompatible and must be transcoded
if (!audio) // the audio codec is incompatible and must be transcoded
console.log(meta); // some meta information about the file (see codec-sniffer)
});
Internally the chromecast-compatible
module would rely on another
module which we would also need to build (if we don't find something
existing). That module could have a name like codec-sniffer
:
var sniffer = require('codec-sniffer');
sniffer('http://foo/bar.mkv', function(err, meta) {
console.log(meta); // some meta information about the file
});
This module could maybe use ffmpeg -i
and parse the output or something.
I guess the main question is if we need to fully download the video first
before we are able todo the codec sniffing (which would be a dealbreaker) or
if it is enough to download the first few kilobytes.
I know that .flv files store the metadata of a video at the
end of the file but I'm not sure how other formats do this.
Any Suggestions?
from castnow.
I totally like this approach by separating the concerns into multiple node modules. I don't have enough insights into how we would be able to detect each codec, but using ffmpeg -i/ffprobe
for local files would probably be a start. There's a node wrapper available too, https://github.com/ListenerApproved/node-ffprobe
from castnow.
yep, ffprobe seems to be the better solution than ffmpeg -i. I already started writing a kind-of chromecast-compatible
module which relies on fluent-ffmpeg
( see https://github.com/fluent-ffmpeg/node-fluent-ffmpeg#reading-video-metadata ).
A problem I faced was that ffprobe returns this as format for mp4 files and mov files: "mov,mp4,m4a,3gp,3g2,mj2". So I'm not quite sure howto differentiate between an mp4 and an mov file with that information. I guess I have to check the file extension... or does anyone have a better idea?
Using ffprobe on files hosted on webservers doesn't seem to work indeed. If the meta-data of the video is stored at the end of the file the webserver would need to be capable of range requests (if we don't want to download the whole file). Which I guess most webservers won't be.
So I agree that we should stick with local files for now.
from castnow.
I've been thinking along these lines too. It'd be great to auto-detect if transcoding the video/audio codecs or changing the container format is necessary instead of relying on the user using --transcode
.
In my testing ffmpeg needs to read entire file to print out information about the container and codecs. It should be possible get this information by partially reading the file, but the details will depend on the container format and codecs. Maybe there's another project out there that does this.
from castnow.
Just created a github repo and dumped in some code => https://github.com/xat/chromecast-can-play
However, still need to figure out a better way than file extension checking.
from castnow.
Awesome! Looks like I was previously wrong and ffprobe/ffmpeg read only some bits of the file to guess the metadata (this is controlled by the -probesize
and -analyzeduration
options). While only some bits of the file is read, the whole file needs to be available as ffmpeg will seek around. In my testing I was doing something like head -c 500000 input.mp4 | ffmpeg -i pipe:0
and that didn't work because it couldn't seek to the end of the file.
If given an HTTP url ffmpeg makes smart http range requests to seek around to the bits it needs. You can see this in action using the -debug
option.
I'm sure you've already discovered all this but I figured I'd document my findings for others.
from castnow.
@parshap Really nice research!
No, I didn't know all of that :-)
Some limitation I found is that HTTPS URLs will only work with some special compile-time-configuration ("https protocol not found, recompile with openssl or gnutls enabled.").
So I guess the conclusion is that ffprobe will work for most users on URLs if the webserver supports Range-Requests and it's not an HTTPS URL. We could just pass in all URLs and localfiles into ffprobe and if ffprobe returns with meta information about that URL/file we are able to make a decision how and if it needs to be transcoded. If ffprobe returns with an error we would just send that file to chromecast and the user will see by himself if it can be played or not.
from castnow.
I think it's reasonable to expect ffmpeg to have been built with certain options. Maybe we should add a section to the readme about ffmpeg requirements and suggested build flags.
If it ends up being an issue for too many people we can always proxy the https resource through a local http server for ffprobe.
from castnow.
I thought it was worth mentioning that you can leave a video paused for a few minutes and it will finish playing successfully, unlike with castnow.
from castnow.
Related Issues (20)
- How to properly pass ffmpeg options? HOT 3
- Youtube Live Stream m3u8 Support HOT 2
- Ogg Vorbis streams @ kohina.com (web radio) skipping
- "Playlist" support
- Mirror screen HOT 1
- Load failed on fedora linux HOT 1
- Homebrew support HOT 3
- local mp3 file "Error: Load failed" HOT 2
- Stream to multiple devices
- Screen command examples utilizing arrow-keys work from command-line but not via KDEconnect
- Connection issues when not explicitely stating the IPs. HOT 2
- Playback is stuttering HOT 2
- Does not show subtitles in container.
- [Question] What are the tcp/ip and/or udp/ip ports opened on the chromecast server ? HOT 1
- Programmatic usage
- Device Not found HOT 2
- Failure to start casting part.end error.
- error trying to install it
- Specify subtitle position HOT 1
- Make '--ffmpeg-ss' much quicker.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from castnow.