-
Notifications
You must be signed in to change notification settings - Fork 6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added RTP DataSource supporting Fast Multicast Acquisition and RTP pa… #3244
base: dev-v2
Are you sure you want to change the base?
Conversation
…cket retransmission, only ALU/Nokia implementation is included but is extensible to other standards as the architecture is modelled following the RFC6285. In order to use this Datasource for unicast streams you will need an RTSP datasource not yet included in this pull request.
This pull request tries to solve the issue #2707 |
The ALU/Nokia Fast Multicast Acquisition and their RTP header extensions are not documented and have been implemented by reversing engineering our service streams and could be incomplete or buggy in other ALU/Nokia IPTV based services. |
Was this issue solved?? |
I don´t know if this patch has been revised by anyone at google for our part we are finishing the RTSP datasource that will make this path truly useful, right know his main use is for multicast RTP streams, needing the RTSP patch for the unicast streams
From: justinboch1986 <[email protected]>
Reply-To: google/ExoPlayer <[email protected]>
Date: Sunday, 29 October 2017 at 06:40
To: google/ExoPlayer <[email protected]>
Cc: "[email protected]" <[email protected]>, Author <[email protected]>
Subject: Re: [google/ExoPlayer] Added RTP DataSource supporting Fast Multicast Acquisition and RTP pa… (#3244)
Was this issue solved??
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
Ok You shared code for to fix Multicast and are still working on Unicast? |
yep, the original issue (#2707) is fully solved with this pull request and goes beyond that implementing an architecture for supporting RTP stream multiplexing allowing advanced features like Fast Multicast Acquisition and RTP retransmission. |
Is it compatible with the newest version? |
So what is the current state of this ? Why has it never been merged in? |
@LRTNZ This PR was never merged. It was created so that Exoplayer supports the audio and video playback from a single RTP stream multiplexing, for services based on IPTV, that is, MPEG-TS over RTP with fast channel change (FCC) and lost packet recovery (LPR), based on the RFC 6280, 6284, 6285, 7509, 5760, 4585 and 1889. I am working to create a PR for RTP support (over UDP), but this will not include FCC and LPR. I hope to have it very soon. |
@portizb sounds like that pull request does exactly what I need - would you possibly be able to have it as an option to enable FCC and LPR in your PR, using the code that does that from this PR? It would be amazing if you could, as it may very well solve the big issue for the program I am currently working on. |
@LRTNZ It is possible, because I designed the code of this PR, but unfortunately, for more than a year I am no longer working on IPTV-based software solutions. The idea of the new PR, is to add the RTP support in ExoPlayer for a simple unicast/multicast stream, and that later, it can be reused by the RTSP library. |
What server are you using for rfc6285/rfc5760/rfc7509 support? It is my understating that all commercial FCC implementations use some form of proprietary protocol(or proprietary extensions if based on those rfcs) |
@joaoserra In general, most of the commercial solutions based on these RFCs, are designed following this scheme:
Typically, the proprietary extension is based on the RTP extension header, which includes information for multicast join signaling, as well as information about the primary and backup servers for burst and retransmission. Similarly, the application-dependent data field given in the RTCP APP packet also depend on the commercial solution. That is the reason why this PR provides a generic scheme so that you can implement your own FCC and FCR based on a commercial solution, which somehow follow the proposals of the RFCs (rfc6285 / rfc5760 / rfc7509). |
…cket retransmission, only ALU/Nokia implementation is included but is extensible to other standards as the architecture is modelled following the RFC6285. In order to use this Datasource for unicast streams you will need an RTSP datasource not yet included in this pull request.