- #ANDROID VIDEO PLAYER WITH CHROMECAST SUPPORT FOR FREE#
- #ANDROID VIDEO PLAYER WITH CHROMECAST SUPPORT MP4#
It seems to me to be a much cleaner design if you make an application that makes use of libmpv, but has its own chromecast-specific logic to run outside of mpv's playback logic, only using mpv as a player for local playback but hiding this from the user. This does not seem to make this a "special output device", but something that is so far removed from mpv's core playback purpose it's difficult to imagine how this can be fit into mpv. actually starts feeding the video stream into its own core playback loop seeking to the playback position.makes the remote control behave like a media player again.stops remuxing, transcoding, shuts down the HTTP server.keeping track of what playback position the chromecast was at before its casting was tragically cut so short.Resumes behaving like a media player when the button is pressed again.it then acts as a remote control for this completely separate media player that is the chromecast device.it tells the Chromecast device what URL to fetch this from.it exposes this output through a locally started HTTP server as HLS/DASH.it begins either transcoding or remuxing the video stream from the current playback position on.Behaves like a media player except for when a special button is pressed, in which case.whether the output device supports the subtitle format of the input file.bandwidth of the wifi connection to the dongle.available hardware encoders in case we have bad CPU perf but good wifi.CPU performance of the device running mpv.chromecast device supported playback formats.Automatically figures out when to transcode, based on.Let's restrict it to only things youtube generates then, which then leads us to the next question: why use mpv for this? You're streaming video from a Google service to a Google device through mpv for what reason? It seems like what you actually want is something that remuxes the DASH stuff from youtube-dl and then sends it into castnow, without any reencoding. Not to mention how any subtitles will probably be lost too. 422? 444? Hi10? Predictive? Yep this won't work. Level > 4.2? This is getting a lot less likely. H.264 main? Probably also very widely supported now. This depends entirely on the used level and profile of AVC. The latter format does not need to be re-encoded to cast it to chromecast devices.
#ANDROID VIDEO PLAYER WITH CHROMECAST SUPPORT MP4#
mp4 contains only AVC with AAC, it gets a bit hairier because there is a lot to AVC It does not automatically imply AVC+AAC, but AVC+AAC is a popular choice for it. I'm assuming by putting avc+aac in parenthesis, you mean to say that this implies those codecs. The MPEG-4 you're referring to is a container. If you're going to lecture multimedia developers about multimedia you should probably not do it like this. There is also a desktop emulator called leapcast, which may be useful too.
#ANDROID VIDEO PLAYER WITH CHROMECAST SUPPORT FOR FREE#
If you have an Android phone or tablet, you can turn it into a Chromecast for free with an app called CheapCast without the need of any whitelisting. The official Chromecast SDK is still in Developer Preview and to use a custom Sender App you need to whitelist your device. Quick digression about requirement of having dedicated device, if someone wants to play with it anyway:
Perhaps we should just go with a separate tool such as Fling and drop the idea of supporting DIAL inside of mpv? I wonder how complex would it be to implement all these moving parts inside of mpv and to be as easy to use as selecting just another video output driver: -vo dial:cast-device-name For example Fling project provides a way of casting local (optionally transcoded) video to a DIAL device with a help of. To make it work Sender needs to act as a HTTP server (and optionally a transcoder, if Receiver does not support codec etc). plays it on its own from URL via simple HTTP GET. My high-level/simplified understanding of what happens after DIAL discovery is that Sender (mpv) posts URL to Receiver (cast-enabled device) via RAMP. Projects at github more or less reverse-engineered it, as people were too anxious to wait for official documentation, which I hope will be published after Developer Preview period. I did some research and there is an additional layer called RAMP, which is not documented well.
0 kommentar(er)
