Pure Javascript mDNS implementation

thibauts commented 9 years ago

Just to let you know, in case you haven't seen it. https://github.com/mafintosh/multicast-dns

Anyway, I didn't have the chance to say it before, so big congrats for castnow ! I wanted something like that from the beggining but was too lazy to do it, and you executed it perfectly as usual !

xat commented 9 years ago

Yep, I have seen that mafintosh has created a mdns module :-) However, the MDNS module chromecast-scanner uses ( https://github.com/kmpm/node-mdns-js ) is also pure JS. So I think I'll stick with that since it does it's job well.

Yeah, castnow is getting more hyped than I expected :) Currently thinking of rewriting it though, since the current architecture has some limitations.

thibauts commented 9 years ago

Is it ? https://github.com/xat/chromecast-scanner/blob/master/package.json#L15

xat commented 9 years ago

yes: https://github.com/xat/chromecast-scanner/blob/master/package.json#L21

thibauts commented 9 years ago

Haha, I guess I haven't totally woken up ...

xat commented 9 years ago

:D

thibauts commented 9 years ago

What are the limitations of the current architecture ?

xat commented 9 years ago

The Plugin system is too over simplified at the moment and only supports core-plugins. Plugins only can hook into the boot process of the player at the moment. My plan is to make this more flexbile and also support non-core plugins. Therefor I created a new module called hoook ( https://github.com/xat/hoook ) which will allow plugins to hook themselves into all kinds of execution stages.

Next thing is that I want to make a Playlist the center of the architecture. The Playlist gets some sort of Chromecast-Engine thing passed in. The Chromecast-Engine is then responsible for the communication with Chromecast (with the help of your libs). The main requirements for the Chromecast-Engine are to be robust (for example to be able to deal with reconnects) and to be able to swap Media Receivers on the fly. The second is needed if the Playlist contains items of different types. For example, if you have a YouTube item and one which requires the DefaultMediaReceiver then the Chromecast-Engine should be able to switch from one to the other. The Playlist thing will also be nice for Audio-only streaming (Google Cast for Audio).

The Transcode Plugin also needs some love. It would be nice if it supports stuff like seeking or at least play and pause. And I want it to automaticly detect if a file needs transcoding or not (instead of the --tomp4 parameter). Also, some files only would need the transcoding of the Audio stream to work on Chromecast. At the moment always video and audio get transcoded.

Another thing is a simplified Web Interface with an REST API which could get activated if castnow gets started with an parameter like --listen.

thibauts commented 9 years ago

Seeking looks quite difficult since ffmpeg can't know in advance the byte size of its output file, something you certainly already thought about. I wonder if it would be possible to convert range requests to fake/virtual seeking times internally. It's probably possible as the player will play whatever data you give it on request response but it may involve patching timestamps in the mp4 atoms on the fly and probably generating a fake moov atom to give the player good starting values, too.

I don't know if the embedded audio / video streams provide timestamps and if it could confuse the player.

Anyway having this kind a seekable transcoded stream would be useful in many setups.

xat commented 9 years ago

Quit funny that your exactly mentioning the ffmpeg problem I'm researching the last few hours :)

My findings on this topic so far are:

Chromecast does indeed only send byte Range-Requests to the backend. There is no query-parameter like start= or t=.
FFMpeg has a parameter --ss which defines the starting time from where to transcode.
The W3C mentions a time unit for Range-Requests ( http://www.w3.org/2008/WebVideo/Fragments/wiki/Time_Range_units ). However, Chromecast does not seem to support this.
So the resulting posibilities seem to be: Creating a Custom Chromecast App with some custom video player which supports handing a start= parameter to the backend. But this is way too time consuming to develop
Or: Find a way to somehow calculate the time from the given bytes. There seem to be ways ( http://superuser.com/questions/349590/how-can-i-find-out-how-big-my-encoded-file-will-be ), but they don't seem (don't can be) 100% accurate.

Guess I'll just try to prototype the last one :)

thibauts commented 9 years ago

Let me know if you need help or want to discuss things :)

xat commented 9 years ago

I gladly will :)

parshap commented 9 years ago

I've created a new issue to discuss playback control of transcoded files: xat/castnow#58.

xat commented 9 years ago

Switched to multicast-dns now

thibauts commented 9 years ago

Does multicast-dns solve the discovery problems we've had lately ? If so I'll rewrite my example code and update the various issues ...

xat commented 9 years ago

It discovers Chromecast devices on firmware v26653 for me. I'm not able to test if it also works on other versions.

thibauts commented 9 years ago

Is v26653 the one that had problems ? Or is it the "old" one ? I have no clue where to find the firmware version

xat commented 9 years ago

You can see the version within the chromecast android app. v25525 was a firmware version which caused trouble. And in some cases people also hat problems with v26653 ( see https://github.com/xat/castnow/issues/61 )

xat commented 9 years ago

oh, wait a second.. just noticing that it does not find any device within node v0.12.0

xat / chromecast-scanner

Pure Javascript mDNS implementation #2