Skip to content
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

Open
wants to merge 1 commit into
base: dev-v2
Choose a base branch
from

Conversation

tresvecesseis
Copy link
Contributor

…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.

…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.
@tresvecesseis
Copy link
Contributor Author

This pull request tries to solve the issue #2707

@tresvecesseis
Copy link
Contributor Author

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.

@justinboch1986
Copy link

Was this issue solved??

@tresvecesseis
Copy link
Contributor Author

tresvecesseis commented Oct 29, 2017 via email

@justinboch1986
Copy link

Ok
Sorry I am only system integrator

You shared code for to fix Multicast and are still working on Unicast?

@tresvecesseis
Copy link
Contributor Author

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.

@mateuszbm
Copy link

mateuszbm commented Jun 25, 2018

Is it compatible with the newest version?
I can't make it to work :/

@LRTNZ
Copy link

LRTNZ commented Apr 2, 2020

So what is the current state of this ? Why has it never been merged in?
RTP stream reading is something I rather need for a project I am working on, and
this being implemented would be very useful indeed.

@portizb
Copy link

portizb commented Apr 13, 2020

So what is the current state of this ? Why has it never been merged in?
RTP stream reading is something I rather need for a project I am working on, and
this being implemented would be very useful indeed.

@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.

@LRTNZ
Copy link

LRTNZ commented Apr 13, 2020

@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.

@portizb
Copy link

portizb commented Apr 13, 2020

@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.

@joaoserra
Copy link

So what is the current state of this ? Why has it never been merged in?
RTP stream reading is something I rather need for a project I am working on, and
this being implemented would be very useful indeed.

@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.

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)

@portizb
Copy link

portizb commented Apr 13, 2020

So what is the current state of this ? Why has it never been merged in?
RTP stream reading is something I rather need for a project I am working on, and
this being implemented would be very useful indeed.

@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.

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:

  • Burst Source: Unicast Audio/Video for FCC
  • Retransmision Source: Multicast for LPR
  • Distribution Source: Multicast Audio/Video
  • Authtoken Source: It is optional and depends on the solution.We have been working with the
    commercial solution of NOKIA-ALU, and it was not supported.

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).

@tonihei tonihei assigned lcf87 and unassigned ojw28 Sep 17, 2020
@icbaker icbaker assigned claincly and unassigned lcf87 Dec 10, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants