No audio for AC3 codec

[auchenberg]

Chromium doesn't support AC3, which means that MP4/MKV files with AC3 codec will be played with no audio. This can be solved by piping the file through ffmpeg using the acodec libmp3lame param, as Chrome supports MP3.

Suggestion:
Detect audio codec in local file, and start the local file using --tomp4 --ffmpeg-acodec libmp3lame

[xat]

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?

[auchenberg]

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

[xat]

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.

[parshap]

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.

[xat]

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.

[parshap]

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.

[xat]

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

[parshap]

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.

[vekin]

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.