[vlc-devel] Chromecast design

[Steve Lhomme]

On Tue, Oct 27, 2015 at 7:18 PM, Rémi Denis-Courmont <remi at remlab.net> wrote:
> Le 2015-10-27 14:00, Steve Lhomme a écrit :
>>
>> I am currently working on the Chromecast plugin(s) for VLC. There's
>> currently a plugin that is a sout wrapper but it assumes the
>> Chromecast is "playback slave" and VLC is the master. In reality this
>> is not how the Chromecast works. The Chromecast is the player with its
>> own buffering, timing and multiple controllers possible
>> (play/pause/exit).
>
>
> You can disable VLC pacing when using the stream output (as the conversion
> wizard does). You would "only" need a new HTTP server. If you do that, then
> pause/resume should work just fine. However you can fundamentally not
> disable input pacing anyway, so you cannot rely on the remote receiver being
> able to control the pace.

I already did the HTTP server that's blocking, contrary to the
broadcasting one. Pause/Play is working well with the Chromecast. I
haven't gotten to the point of seeking yet.

The Chromecast does a range request on the first query, so it may do
that when told to seek. This is not going to work well when we mux on
the fly. So I might have to close and open the file again, knowing it
will not start from the beginning. At least when loading a file we can
tell at what time the playback is, so hopefully that will be enough to
mimick regular seeking:
https://developers.google.com/cast/docs/reference/messages#Load

> You can also not assume that the track formats will stay constant, thus
> limiting your choice of muxer, or imposing transcoding almost always. Not to
> mention the rat hole with multiple tracks of the same category.

A good amount of work is going to be put into analyzing the source to
decide the optimal way to send data to the Chromecast. For example I
know in Matroska it's not possible that the video/audio characteristic
change mid-stream. So in that case we know that muxing might be
enough, provided the Chromecast can handle the codecs.

If we have a solution that doesn't work 100% of the time it should be
OK. We can improved it little by little. The one thing I don't want
though is wasting resources on a mobile device. Transcoding video may
not even be possible on most mobiles too. So what we really need at
first is H264/VP8 and AAC/MP3/Vorbis working. I'm not sure VP9 or Opus
are supported. AC3 doesn't seem to be supported either or maybe
through the TV decoder.

> You can not assume that stream output will handle seeking correctly, and
> even if it did, it would not work with plain HTTP nor with segmented HTTP
> streaming. Both of those would require prior off-line conversion.

Seeking may not be such a big issue after all. In the case we're
sending data through VLC transmux/transcode we could use the trick
described above (unload/load starting from elsewhere).

> Overall, it seems that you painted yourself into a corner already. You need
> to be a bit realistic about what the VLC stream output can do, what else VLM
> and/or VoD could do, and what is either out-of-scope (e.g. general purpose
> HTTP server) or not possible at all (seeking or buffering live content).

I think I'm halfway there. I think I found a solution for the EOF
issue by using a sout wrapper that will talk with the Chromecast
controller. This way the sout can tell when it's done sending all the
data (and we can hack this to report it's sent only when the
Chromecast is done playing it). All it needs from the core is
additions in input_DecoderIsEmpty(). A call similar to vout_IsEmpty()
but for sout. That doesn't seem too far fetched.

> --
> Rémi Denis-Courmont
> http://www.remlab.net/
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel