Hello, there is now a working patch that solves the broken playback issue when using an Android source: https://bugzilla.gnome.org/show_bug.cgi?id=743363#c7 I would also like to propose to gstreamer developers (on their mailing list) that we write and submit upstream an element that serves as the gstreamer source element on the miracast sink side (it's a terminology clash, I know). Then anyone who wants to have a Miracast sink can simply use: gst-launch-1.0 playbin uri=miracast://source_ip:port and the element will handle RTSP negotiation and RTP streaming. The application using this will have all the benefits of gstreamer's playbin. Currently we have to create a pipeline by hand: gst-launch-1.0 udpsrc ! rtpjitterbuffer ! ... etc which is not optimal because it has a non-standard interface for the applications (as opposed to playbin's) and it doesn't dynamically reconfigure itself (like playbin does) according to what the incoming stream contains. So it's much better to use playbin, but that requires a custom source element - see above. Another benefit is that we get our sink 'for free' into all the distributions through gstreamer's upstream releases :) So here's what I would like to write: ========================================= Hello, we (Intel's Open Source Technology Center, http://01.org) are working on an open source implementation of Miracast technology (which basically replaces an HDMI cable with a wireless peer-to-peer link). Miracast is supported by Android and Windows, and other display devices, but there is no Linux stack yet. Here's the code, it's work in progress, but we have a working demo for both sides, and we're now doing interoperability testing with other Miracast stacks: https://github.com/01org/wysiwidi As part of the project, we would like to implement a gstreamer source element that will allow easy playback of miracast streams on the display side: gst-launch-1.0 playbin uri=miracast://source_ip:port Establishing a media stream using Miracast consists of the following steps: 1) Scanning for available devices and establishing a peer-to-peer link using Wi-Fi P2P mechanisms (there is no 'access point' involved; devices discover and connect to each other directly). The element will not handle this part; it's assumed that the application will do it using available network management facilities on the system (such as connman, wpa_supplicant, etc.). Connman already has support for this. 2) Negotiating the streaming parameters using RTSP with miracast-specific extensions. The element will do this. 3) Accepting incoming stream using MPEGTS over RTP over UDP. The element will do this too. Is this ok? Would you be interested in carrying this element upstream in gstreamer plugins? Regards, Alexander ===================================== Regards, Alexander