Playback controls for transcoded files

[parshap]

This issue is about playback controls (play/pause, seeking) for files that are transcoded "on the fly" with ffmpeg. Currently playback controls do not work due to technical limitations. This continues the conversation from xat/chromecast-scanner#2 and #45.

[parshap]

I'm not sure using ffmpeg's -ss option will work. When Chromecast sends an range request it's asking for a specific byte range of the original file. Using the -ss option doesn't output byte range of the original file, it creates a new file with a different byte stream entirely. It may be possible to get it to work by fudging the bytes somehow (e.g., skipping forward some bytes to skip the headers/metadata of the ffmpeg -ss output), but if my understanding is correct it will be brittle.

Another thought I've had is to write the output of ffmpeg to a temp file and then serve range requests against that temp file. The problem here is that you can only seek forward as far as ffmpeg has already decoded.

That said, the -ss option should work well for the castnow --seek option.

[xat]

Tempfile also was my initial thought on this topic. Although it's not so "cool" like an on-the-fly thing, but if it does the job, why not :)
I think nowadays most videos are either .mkv or .mp4. And I guess that in most cases only the audio stream needs to be converted... which means that the whole tempfile will get created really fast.

[xat]

I just did some testing with a temp-file. To stream from that temp-file (while it is getting created) to the HTTP response I used this module: https://github.com/jasontbradshaw/tailing-stream
The problem is that you cannot resume playback anymore as soon you hit "pause" once. So it's the same problem like with the live transcoding we have at the moment.

[xat]

Just noticed that the play/pause problem also occurs after the file is fully transcoded.

[xat]

Interesting, setting output FPS to 25 will make play/pause work the first 10 seconds.

    ffmpeg(input)
      .videoCodec('libx264')
      .format('mp4')
      .fps(25)
      .outputOptions([
        '-movflags frag_keyframe+faststart',
        '-strict experimental'
      ])
      .pipe(output);

[xat]

I got it to work using HLS (HTTP Live Streaming). Created a proof of concept demo repo over here: https://github.com/xat/hls-chromecast-demo

[parshap]

That's awesome! Are there any drawbacks to using HLS?

I've been trying to experiment with the temp file approach, but haven't had much luck or time. I had an issue getting Chromecast to send range requests in response to my ff/rw commands. I disabled options.disableSeek = true, but it seems like Chromecast just ignores the commands and doesn't send a new http range request at all. This was only happening when using plugins/transcode.js to serve the file - plugins/localfile.js received new http range requests in response to ff/rw commands just fine. I thought it may have to do with the headers sent by serve-mp4.js, but I replicated those in plugins/transcode.js and still no luck. Any ideas?

[xat]

Sometimes the video lagged/stocked while transcoding it with HLS. I think I have to play around with the ffmpeg parameters. But that was the only drawback I experienced until now using HLS.

options.disableSeek is a pure castnow internal option. Chromecast does not process that option. I think that we won't get seeking to work without an other approach like HLS. I also ran some tests last sunday where I just displayed the output of ffmpeg in an video-tag on my local machine. But even in that simplified case seek/pause/play didn't work properly.