http://developer.android.com/guide/appendix/media-formats.html says that RTSP is supported but when trying to access an RTSP stream the MediaExtractor fails.
kjeremy
All 98 comments
MediaExtractor doesn't support RTSP.
You have to make a rtsp-renderer by yourself.
Ood-Tsen
on 25 Sep 2014
Can you elaborate?
kjeremy
on 25 Sep 2014
+1, Any advancement on this?
chrisjenx
on 15 May 2015
Actually, RTSP is not so popular unlike HLS or Progressive download.
Only some video conference (e.g. SIP) or surveillance use RTSP.
It's not worthy to put resource on this.
Ood-Tsen
on 21 May 2015
Yeah we were looking at talking to ipcams most of which use rtsp.
On Thu, 21 May 2015 07:52 Ood Tseng [email protected] wrote:
Actually, RTSP is not so popular unlike HLS or Progressive download.
Only some video conference (e.g. SIP) or surveillance use RTSP.It's not worthy to put resource on this.
—
Reply to this email directly or view it on GitHub
https://github.com/google/ExoPlayer/issues/55#issuecomment-104157870.
chrisjenx
on 21 May 2015
There are few open source projects are for rtsp,
and some of them are not update for many years.
Need RTSP , SDP , RTP/RTCP parser
- nist-sip , can use it for SDP parsing.
- fyhertz/libstreaming is for server side, not match the need,
But it can be a reference.
Ood-Tsen
on 21 May 2015
Right. We have no plans to commit resources to this in the near future. If someone wanted to add a high quality, relatively self contained component that adds support, then we'd happily take that as a pull request.
ojw28
on 21 May 2015
Need RTSP , SDP , RTP/RTCP parser
I would rather suggest wrapping a well-tested and actively maintained library such as live555 (under LGPL) for this purpose?
It includes RTSP, SDP, RTP, RTCP functionality, relevant payload formats as well as support for RTP over RTSP (TCP streaming).
Or is there a preference to write all the code in JAVA/are there any other reasons to not go this route?
miseri
on 3 Jul 2015
Right. We have no plans to commit resources to this in the near future. If someone wanted to add a high quality, relatively self contained component that adds support, then we'd happily take that as a pull request.
We currently also do not have the resources for this, but if we were to undertake the task of wrapping live555 in a JNI layer, would you be willing to support us in integrating the component into exoplayer?
miseri
on 3 Jul 2015
We would be interested in supporting it if the work was done.
On Fri, 3 Jul 2015 09:31 miseri [email protected] wrote:
Right. We have no plans to commit resources to this in the near future. If
someone wanted to add a high quality, relatively self contained component
that adds support, then we'd happily take that as a pull request.We currently also do not have the resources for this, but if we were to
undertake the task of wrapping live555 in a JNI layer, would you be willing
to support us in integrating the component into exoplayer?—
Reply to this email directly or view it on GitHub
https://github.com/google/ExoPlayer/issues/55#issuecomment-118274854.
chrisjenx
on 3 Jul 2015
A couple of things to keep in mind:
- We wouldn't want an RTSP library as a dependency on the core ExoPlayer library, so if anyone does work on this then please try to implement it as an extension, similar to the VP9 and Opus extensions currently in the dev branch here. That way an application that needs it can proactively include the extension, and everyone else can ignore it :).
- It would be preferable to implement it in Java. If there is a native dependency, bear in mind that you'll need to support multiple architectures (arm, x86, mips + 64bit variants) if you want it to work across all devices.
ojw28
on 3 Jul 2015
Hello i want to do live stream from one external camera. Camera is providing only RTSP stream. I was try to use "ExoPlayer" but its getting failed. Can you please help me out.
Anshumansharma12
on 11 Feb 2016
Rtsp doesn't work with exoplayer.
On Thu, 11 Feb 2016, 09:30 Anshumansharma12 [email protected]
wrote:
Hello i want to do live stream from one external camera. Camera is
providing only RTSP stream. I was try to use "ExoPlayer" but its getting
failed. Can you please help me out.—
Reply to this email directly or view it on GitHub
https://github.com/google/ExoPlayer/issues/55#issuecomment-182780620.
chrisjenx
on 11 Feb 2016
I have a project @ http://net7mma.codeplex.com/ which can provide a solution for Rtp and Rtsp playback.
The project is Mono / Android compatible and is very CPU and Memory Efficient.
There is a RtspServer as well as RtspClient and RtpClient implementations.
You can integrate any supported codec which is accessible through MediaCodec or you can implement your own.
juliusfriedman
on 24 Jun 2016
Dear @ojw28, may I ask for your advise on the following: I'm trying to integrate live555 with Exoplayer2 & would like to get the architecture sorted out. Here's the rough structure:
- Exo determines an rtsp:// URL belongs to a RtspDataSource & creates it. (via DefaultDataSource)
- RtspDataSource opens the URL using live555 and waits for the subsessions (audio,video,text) to be negotiated and created. Once they are, RtspDataSource contains the information about those sessions & only this can be read. The underlying live555 system will NOT start the playback automatically (after the subsessions are known). However, RtspDataSource is now in state “ready”.
- RtspExtractor#init is called, but only stores the ExtractorOutput (extractorOutput) in a member variable. It will be needed in step 5
- RtspExtractor#sniff is called next and sniffs for information from step 2 (Perhaps indicated using a dedicated (‘R’, ’T’, ’S’, ’P’, ‘I’) header. It only uses “peek” to get the data.
- As step 4 succeeded, RtspExtractor#read is now called. It calls readFully() on the ExtractorInput and reads 2048/as much as possible bytes to learn about the subsessions.
- RtspExtractor now creates the tracks and stores them in extractorOutput. If anything fails or a codec is not supported, RtspExtractor throws an IOException
- With the tracks now in place, RtspExtractor sets a member variable tracksCompleted to true
- RtspExtractor requests more data from the ExtractorInput
- RtspDataSource#read is called again. Because RtspDataSource is in state “ready”, it will initiate the live555 PLAY command, which will start transfer of the audio/video frames. How RtspDataSource could read the tracks from RTSP:
- There will be maximum 3 sinks (for audio, video, text).
- Each sink remembers the last byte buffer it received
- RtspDataSource has a combined buffer of all sinks and returns that. The Audio, Video or Text buffers have special headers (‘R’,’T’,’S’,’P’,(’V’ or ‘A’ or ’T’)) which help the Extractor to map the information back to extractorOutput track later. The header also contains a size for each video/audio/text frame and meta info like presentation time. If the combined buffer is drained, then RtspDataSource will fetch the buffers of all sinks into a new combined buffer. Not all sinks have new data all the time, so we wait until at least one of them has data).
- RtspExtractor#read is called multiple times to work through the stream. Because tracksCompleted is set, it will process the track data as it arrives. It remembers the currently processed track too, in case a frame size is bigger than its internal buffer. Once all data of a track is read, it calls the sampleData & sampleMetadata functions on the TrackOutput, so that the decoder can start to work.
My questions:
- Is the above approach feasible? Am I on the right track to use RtspDataSource + RtspExtractor?
- Double/Triple buffer performance (first from sink to source, then source to extractor) needs to be evaluated, but because of ExoPlayers architecture it might be unavoidable.
- Is it best practice to re-pack the “structured” information from live555 into one generic byte[] stream again? Live555 has everything ready: The NAL units for SPS/PPS, the H.264 frame, presentationTime -> it should simply be put into the decoder. It would be beneficial to access the DataSource from the Extractor.
- All of above is done using a extension/live555/ module just like flac/opus/ffmpeg.
ened
on 5 Aug 2016
I'm trying to implement RTSP playback in Exoplayer, using live555.
But when I pass audio/video frames from my Extractor to TrackOutput's, Exoplayer sometime freezes:
1) don't read frames from Extractor;
or 2) frames read but video freezes on screen and no sound.
Video/audio stream grabbed from IP camera. Sorry, I can't place stream URL here.
Video is H264 720x576 50fps ~1280 Kbps. Audio is AAC LC 128 Kbps.
In attempting to solve this issue I add debug output to file into Extractor. H264 frames written to file as 'bytestream' (with 0,0,0,1 byte prefix); AAC written as ADTS frames.
I combine this tracks into .MP4 file without reencoding (with help of FFMPEG - options like '-vcodec copy', '-c copy') and put resulting file back to device.
Exoplayer plays this test file successfully!
I'm completely stuck. By what reason Exoplayer doesn't like live stream, but successfully plays same video/audio frames from file?
dzualeks
on 7 Oct 2016
Are you sending the periodic rtsp keepalives? if not, the server will
teardown the session.
El 7 oct. 2016 9:48 p. m., "dzualeks" [email protected] escribió:
I'm trying to implement RTSP playback in Exoplayer, using live555.
But when I pass audio/video frames from my Extractor to TrackOutput's,
Exoplayer sometime freezes:
1) don't read frames from Extractor;
or 2) frames read but video freezes on screen and no sound.
Video/audio stream grabbed from IP camera. Sorry, I can't place stream URL
here.
Video is H264 720x576 50fps ~1280 Kbps. Audio is AAC LC 128 Kbps.
In attempting to solve this issue I add debug output to file into
Extractor. H264 frames written to file as 'bytestream' (with 0,0,0,1 byte
prefix); AAC written as ADTS frames.
I combine this tracks into .MP4 file without reencoding (with help of
FFMPEG - options like '-vcodec copy', '-c copy') and put resulting file
back to device.
Exoplayer plays this test file successfully!
I'm completely stuck. By what reason Exoplayer doesn't like live stream,
but successfully plays same video/audio frames from file?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/google/ExoPlayer/issues/55#issuecomment-252344805, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AJ99v7MckXB6u0dlT8kMdueEFVv6Dixyks5qxqIMgaJpZM4CmVbp
.
tresvecesseis
on 7 Oct 2016
tresvecesseis, thank you for reply.
No, problem not on RTSP server side. It works until 'local server' buffer queue overflows and live555 send TEARDOWN by self.
Two words about my app architecture:
- 'Clients' (RTSPDataSource class for Exoplayer and MP4 file writer class) starts live555 RTSP 'wrapper' (or connects to existing: app must write video/audio to MP4 file and play simultaneosly).
- live555 'wrapper' connects to RTSP server and receive RTSP responses and video/audio stream via callbacks. Also, ServerSocket opened and checked regularly for incoming connections.
- 'Clients' (RTSPDataSource or MP4 writer) connects to this socket and feed RTSP command responses and stream data in my own binary format.
- When last 'client' disconnected from 'wrapper' local server - 'wrapper' send TEARDOWN to RTSP server and finishes work.
To avoid situation when 'client' connected to 'wrapper' but freezed by some reason, I'm limit length of buffer queue in wrapper.
But I must return to your queston: my live555 wrapper stops working by buffer queue overflow. When >128 buffers with stream data waits in client's queue - wrapper close connection by self. This is what happens when Exoplayer stops receive data from RTSPDataSource.
Also, when I dug into ExoPlayer sources, I see that "freeze" occured in ExtractorMediaPeriod class, subclass ExtractingLoadable, load() method. This line of code:
loadCondition.block();
When Exoplayer plays MP4 file from disk or from network source - no problem, no freezes 8-O
dzualeks
on 8 Oct 2016
I have my own rtsp data source that connect directly to the RTSP server and
it works properly with exoplayer v1, we are in the porting process to
exoplayer v2 but I'm afraid it will not work for your use case.
El 8 oct. 2016 8:42 a. m., "dzualeks" [email protected] escribió:
tresvecesseis https://github.com/tresvecesseis, thank you for reply.
No, problem not on RTSP server side. It works until 'local server' buffer
queue overflows and live555 send TEARDOWN by self.
Two words about my app architecture:
- 'Clients' (RTSPDataSource class for Exoplayer and MP4 file writer
class) starts live555 RTSP 'wrapper' (or connects to existing: app must
write video/audio to MP4 file and play simultaneosly).- live555 'wrapper' connects to RTSP server and receive RTSP responses
and video/audio stream via callbacks. Also, ServerSocket opened and checked
regularly for incoming connections.- 'Clients' (RTSPDataSource or MP4 writer) connects to this socket and
feed RTSP command responses and stream data in my own binary format.- When last 'client' disconnected from 'wrapper' local server -
'wrapper' send TEARDOWN to RTSP server and finishes work. To avoid
situation when 'client' connected to 'wrapper' but freezed by some reason,
I'm limit length of buffer queue in wrapper. But I must return to your
queston: my live555 wrapper stops working by buffer queue overflow. When128 buffers with stream data waits in client's queue - wrapper close
connection by self. This is what happens when Exoplayer stops receive data
from RTSPDataSource. Also, when I dug into ExoPlayer sources, I see that
"freeze" occured in ExtractorMediaPeriod class, subclass
ExtractingLoadable, load() method. This line of code:
loadCondition.block(); When Exoplayer plays MP4 file from disk or from
network source - no problem, no freezes 8-O—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/google/ExoPlayer/issues/55#issuecomment-252407164,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJ99v-feJbH8xSYiCdF5nH2dIMYSth3Gks5qxztvgaJpZM4CmVbp
.
tresvecesseis
on 8 Oct 2016
tresvecesseis, thank you again.
Hmmm... I'm use Exoplayer v2 from project's start. Will try to check v1 with my RTSPExtractor/RTSPDataSource.
Also, can I see your Extractor/Datasource classes? (may be I miss something in my code...) Or you use different way of integrating your components into Exoplayer?
dzualeks
on 8 Oct 2016
Yep, we plan to contribute the RTSP extractor but it´s no generic enough to be useful to others in its current form (we have hardcoded some weird behaviours of our RTSP servers) so we are trying to make the datasource standards compliant before submission. In any case, I will try to strip the propietary bits and have something to show you in the next few days.
From: dzualeks [email protected]
Reply-To: google/ExoPlayer [email protected]
Date: Saturday, 8 October 2016 at 17:22
To: google/ExoPlayer [email protected]
Cc: "[email protected]" [email protected], Comment [email protected]
Subject: Re: [google/ExoPlayer] RTSP support (#55)
tresvecesseis, thank you again.
Hmmm... I'm use Exoplayer v2 from project's start. Will try to check v1 with my RTSPExtractor/RTSPDataSource.
Also, can I see your Extractor/Datasource classes? (may be I miss something in my code...)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
tresvecesseis
on 8 Oct 2016
Would love to help in making the RTSP Extractor more generic. If you have
an open source repos we can contribute to let me know.
On Sat, 8 Oct 2016 at 18:56 tresvecesseis [email protected] wrote:
Yep, we plan to contribute the RTSP extractor but it´s no generic enough
to be useful to others in its current form (we have hardcoded some weird
behaviours of our RTSP servers) so we are trying to make the datasource
standards compliant before submission. In any case, I will try to strip the
propietary bits and have something to show you in the next few days.From: dzualeks [email protected]
Reply-To: google/ExoPlayer [email protected]
Date: Saturday, 8 October 2016 at 17:22
To: google/ExoPlayer [email protected]
Cc: "[email protected]" [email protected], Comment <
[email protected]>
Subject: Re: [google/ExoPlayer] RTSP support (#55)tresvecesseis, thank you again.
Hmmm... I'm use Exoplayer v2 from project's start. Will try to check v1
with my RTSPExtractor/RTSPDataSource.
Also, can I see your Extractor/Datasource classes? (may be I miss
something in my code...)—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/google/ExoPlayer/issues/55#issuecomment-252438821,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABHRsYjWu8jEmtidLaWc9lQUA_4G3dPtks5qx9lLgaJpZM4CmVbp
.
chrisjenx
on 9 Oct 2016
Sorry for silence. I'm stupid.
My issue been in frame timestamps which my code pass to Exoplayer (trackOutput.sampleMetadata(timeStampUs,...).
Camera's RTSP server returns _absolute_ timestamps, but Exoplayer requires _relative_ ones (0 for 1st frame).
Now Exoplayer v2 succesfully works for me.
dzualeks
on 12 Oct 2016
Would love to see this impl!
On Wed, 12 Oct 2016, 14:23 dzualeks, [email protected] wrote:
Sorry for silence. I'm stupid.
My issue been in frame timestamps which my code pass to Exoplayer
(trackOutput.sampleMetadata(timeStampUs,...).
Camera's RTSP server returns _absolute_ timestamps, but Exoplayer
requires _relative_ ones (0 for 1st frame).
Now Exoplayer v2 succesfully works for me.—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/google/ExoPlayer/issues/55#issuecomment-253209862,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABHRsb07T7REpt9-RbhITOvbjpYlpPi-ks5qzN1fgaJpZM4CmVbp
.
chrisjenx
on 12 Oct 2016
Want to leave here my request for RTSP too! Its a standard that is used by a HUGE amount of cameras on the market.
shinayser
on 18 Oct 2016
would love to know if any progress too! I'm working on a impl of RTSP streaming player with scale/direction control by using Android's Media Player with TextureView, but it just not good enough.
iamcxa
on 18 Oct 2016
As I said, I want to contribute our RTSP implementation but we have a tight schedule and we can not divert resources to this port right now, in a few days I expect to be able to continue with the v2 port.
tresvecesseis
on 19 Oct 2016
i can't implement live555 with exoplayer. have you please any tutorial that explain how to use it. thanks
marva2013
on 26 Oct 2016
Is anyone using ExoPlayer with rtsp streams?
With millions of cameras using rtsp I think it would be very useful for ExoPlayer.
pieman64
on 7 Jan 2017
We have a rtsp, rtcp and rtp implementations for exoplayer but I don´t know if there is any interest from the maintainers in this code, we will only clean and submit the code if there is a request for them as we are a little overloaded right now
From: theCHARioT notifications@github.com
Reply-To: google/ExoPlayer reply@reply.github.com
Date: Saturday, 7 January 2017 at 12:33
To: google/ExoPlayer ExoPlayer@noreply.github.com
Cc: "[email protected]" tresvecesseis@gmail.com, Comment comment@noreply.github.com
Subject: Re: [google/ExoPlayer] RTSP support (#55)
Is anyone using ExoPlayer with rtsp streams?
With millions of cameras using rtsp I think it would be very useful for ExoPlayer.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
tresvecesseis
on 7 Jan 2017
There is definitely interest.
On Jan 7, 2017 6:50 AM, "tresvecesseis" notifications@github.com wrote:
We have a rtsp, rtcp and rtp implementations for exoplayer but I don´t
know if there is any interest from the maintainers in this code, we will
only clean and submit the code if there is a request for them as we are a
little overloaded right nowFrom: theCHARioT notifications@github.com
Reply-To: google/ExoPlayer reply@reply.github.com
Date: Saturday, 7 January 2017 at 12:33
To: google/ExoPlayer ExoPlayer@noreply.github.com
Cc: "[email protected]" tresvecesseis@gmail.com, Comment <
[email protected]>
Subject: Re: [google/ExoPlayer] RTSP support (#55)Is anyone using ExoPlayer with rtsp streams?
With millions of cameras using rtsp I think it would be very useful for
ExoPlayer.—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/google/ExoPlayer/issues/55#issuecomment-271079123,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEIBREANgSibpcbbhRnkzBBC21bezHCtks5rP3v8gaJpZM4CmVbp
.
kjeremy
on 7 Jan 2017
A good solution would be great.
FabianTerhorst
on 7 Jan 2017
@ojw28 would you be interested in the implementations of rtsp, rtcp and rtp that @tresvecesseis has available? Perhaps with rtsp, probably being the most popular, being considered first.
pieman64
on 7 Jan 2017
@tresvecesseis you could also open source it as an module to use with exoplayer.
FabianTerhorst
on 7 Jan 2017
Our rtsp implementation could be submitted without much additional work (is just another datasource) but is focused on rtp streams, and rtp support is more problematic as it is a layered extractor that instantiate the extractor of the undelaying protocol and we will need to discuss if our approach is the optimal one, so to submit our rtsp datasource we need to know what transport protocols it will need to support (being ts over udp the most simple case)
From: theCHARioT notifications@github.com
Reply-To: google/ExoPlayer reply@reply.github.com
Date: Saturday, 7 January 2017 at 14:37
To: google/ExoPlayer ExoPlayer@noreply.github.com
Cc: "[email protected]" tresvecesseis@gmail.com, Mention mention@noreply.github.com
Subject: Re: [google/ExoPlayer] RTSP support (#55)
@ojw28 would you be interested in the implementations of rtsp, rtcp and rtp that @tresvecesseis has available? Perhaps with rtsp, probably being the most popular, being considered first.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
tresvecesseis
on 7 Jan 2017
@tresvecesseis I think in the first case, making it available would be great first step, then we can work on making it support more protocols, RTSP is the wrapper around RTP, that's the easy part. (It's actually very similar to HTTP commands).
chrisjenx
on 7 Jan 2017
I think there is a misunderstanding in what is RTSP and RTP, RTP is only one of the transport protocols that can be signalled by RTSP, and the problem with RTP is that it normally wraps another video container so we need to chain 2 extractors (there is no standard way to do this in ExoPlayer), and while we have posted patches in this github implementing RTP in the past, they were a quick hack provided on request, our current code have a lot of proprietary features (FCC, RTP retry, custom extension headers, …) that are of no interest to ExoPlayer.
We could provide an RSTP datasource with support fo TS streams, and if there is demand, an RTP extractor hardcoded for muxed TS streams.
tresvecesseis
on 9 Jan 2017
We would consider taking something if it were implemented as an extension that doesn't require invasive changes to the core library. Structuring it as an extension would also allow you to depend on external libraries (that may have non-AOSP licenses attached to them). Note that all contributed source code would need to satisfy the CLA (i.e. you need to own copyright/IP), so dependencies on external libraries need to be dependencies, rather than copy/pasting code from them.
It's somewhat unclear where the boundary would sit between any such extension and the rest of ExoPlayer. Is it possible to provide a DataSource without needing any other changes elsewhere?
ojw28
on 9 Jan 2017
Yes, we have implemented RTSP support as a datasource, it is done inside our player not in the library so reimplementing as an extension is trivial, the problem resides in the RTP support, we could provide the RTSP datasource with TS transport support and later discuss the RTP extractor implementation. Are you ok with that?
tresvecesseis
on 9 Jan 2017
A self-contained DataSource extension sounds like the best thing to do initially, yes.
ojw28
on 11 Jan 2017
@tresvecesseis can you share the rtsp datasource code?
AhmedNTS
on 18 Mar 2017
@AhmedHashemNTS i think its this one: https://github.com/tresvecesseis/ExoPlayer/tree/dev-v2-dvbsubs . but its not supporting the latest exoplayer version
FabianTerhorst
on 18 Mar 2017
@FabianTerhorst I took a quick look and i couldnt find any RTSP related code. i will build it and give it another shot. Thanks a lot(Y)
AhmedNTS
on 18 Mar 2017
Could also be the Dev branch.
FabianTerhorst
on 18 Mar 2017
No Dev is v1
AhmedNTS
on 18 Mar 2017
@AhmedHashemNTS , sorry but we are porting all our code base to v2, our current v1 implementation is specific to our service and not useful to anyone, our v2 implementation is standards compliant albeit only for TS streams for UDP (it will be trivial to add RTP support). But before we submit this code I must finish the remaining problems with the DVB subtitles pull request.
tresvecesseis
on 18 Mar 2017
@tresvecesseis FCC? Fast Channel Change? Can you disclose what FCC are you using with Exoplayer? Your own implementation or some commercial one? (i.e. ALU, Ericsson, Cisco VQE, Edgeware, etc) Is the FCC impl. self-contained in Exoplayer/Java? FCC clients usually require native user-space libs and even kernel drivers in some implementations, so i'm a bit curious.
joaoserra
on 24 Mar 2017
@joaoserra , We had implemented the ALU one but most of the code is reusable, the differences are in the signalling of the acquisition phase and in some vendor specific RTP extension headers, It´s fully implemented in Java and made by us, some problems in the Android Java Api forced us to implement some socket management parts with the NDK because the needed Java implementation were only available in API 24 and our boxes were API 19.
Basically a FCC consist in a fast multicast acquisition phase done with a unicast flow signalled with RTCP and a synchronisation phase with the multicast flow using the RTP headers, in our case we also have RTP lost packet retransmission for the multicast flow (also implemented with RTCP, NACK Feedback) to recover from errors in the multicast flow, this forced us to use three asynchronous nonblocking sockets attached to a listener to merge the incoming packets from the various sockets (FCC unicast, multicast video flow, unicast RTP retry flow), the problem was that multicast sockets were not working in listeners until API 24 so we needed to implement the missing parts.
Our current implementation was a quick hack that is in a non-mergeable state (to ugly to look at) for Exoplayer v1 and we are reimplementing with a new architecture in Exoplayer v2.
tresvecesseis
on 24 Mar 2017
@joaoserra , our implementation is a not completed (but is fully functional), was done reverse engineering our service. There are some RTCP vendor specific parameters that are unknown and the RTP extension headers were also undocumented until recently so we had to implement the acquisition and synchronisation phase with the standard RTP header and inspection of the contained MP2T transport stream, this could be greatly simplified now with the info about the ALU RTP extension headers.
tresvecesseis
on 24 Mar 2017
Seriously? Almost 3 years of this issue has been opened and it still open with no prevision of implementation?
shinayser
on 29 Jun 2017
Rtsp isn't a modern protocol. There won't be an official implementation without an pr
FabianTerhorst
on 29 Jun 2017
Android 4.0 also is not a modern Operational System and Google still supports it.... This is no excuse. A huge amount of devices around the world supports only RTSP and ExoPlayer simply can't support them.
shinayser
on 29 Jun 2017
Eh? All modern IP cameras use rtsp.
On Thu, Jun 29, 2017 at 10:05 AM, shinayser notifications@github.com
wrote:
Android 4.0 also is not a modern Operational System and Google still
supports it.... This is no excuse.—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/google/ExoPlayer/issues/55#issuecomment-311976741,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEIBRDwz3xXnZeJmjkwAuvJ23mpQ_01mks5sI68ygaJpZM4CmVbp
.
kjeremy
on 29 Jun 2017
we plan to contribute our RTSP implementation after the RTP/RTCP one so no ETA yet
tresvecesseis
on 29 Jun 2017
@shinayser - It's not our goal to implement everything that anyone asks for, for free, just because they ask for it. As has been noted already on this issue, we're open to accepting a well written and self-contained pull request that provides this functionality, from @tresvecesseis or anyone else who wants to provide one. You're welcome to contribute this functionality yourself!
@kjeremy - Whilst we'd obviously like to support IP cameras, realistically it's just not one of the primary use cases we're targeting, which is why we haven't devoted resources to this. This makes sense if you think about the hours-per-day a typical smartphone user spends consuming OTT video vs watching IP camera streams.
So in summary: Once we get a high quality pull request, we'll look at accepting it! Thanks.
ojw28
on 29 Jun 2017
+1 need rtsp support
erlangp
on 7 Nov 2017
Only to give an update, we want to contribute our RTSP datasource but in order to have an extensible and minimally useful RTSP implementation we had to re-do our datasource, now we are in a point when it can play our unicast M2TS sources but we are including support for multistream sources, RTP streams, ...
The first version will only be tested multiplexed M2TS sources and a Samsung IP camera, in order to provide support for other media transport formats more patches will be needed.
I expect to make a pull request in a couple of weeks but we can provide our code to anyone that want to contribute support for additional devices.
tresvecesseis
on 7 Nov 2017
@tresvecesseis I'm interested in testing. Can you share with me the code? Thanks.
SVPA-MaxWu
on 7 Nov 2017
Yes, we are in the middle of a code refactoring to add Elementary Streams supports to the RTSP datasource (The Samsung camera sends 3 individual streams; video, audio and data), I expect to have it working again next week.
Sergio
From: SVPA-MaxWu notifications@github.com
Reply-To: google/ExoPlayer reply@reply.github.com
Date: Tuesday, 7 November 2017 at 21:50
To: google/ExoPlayer ExoPlayer@noreply.github.com
Cc: "[email protected]" tresvecesseis@gmail.com, Mention mention@noreply.github.com
Subject: Re: [google/ExoPlayer] RTSP support (#55)
@tresvecesseis I'm interested in testing. Can you share with me the code? Thanks.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
tresvecesseis
on 9 Nov 2017
+1 for support rtsp
iceteahh
on 11 Nov 2017
@iceteahh @erlangp if you are interested in RTSP support please check out our GitHub. You can view apps using our software by searching VXG RTSP in Google Play or the App Store.
RMAC3
on 11 Dec 2017
Does we have any update on this thread? Is RTSP support in the roadmap?
_The VGX library is a good library, it samples work fine. But the has a terrible license price ($5000). No way for most developers to go for it..._
shinayser
on 5 Feb 2018
Yes, we are at the end of the coding and debugging and in a very short time, it will be available so that it can be tested. I am working with Sergio @tresvecesseis in this solution.
This version includes support for H264 over RTP as well as audio codecs G711.x, and AC3. We are also currently working to support AAC over RTP. For the decoding of RAW/UDP audio and video formats, existing extractors and readers will be used.
TCP connections and multicast mode are not supported at the moment. Only unicast mode is supported in UDP including hole punching for Full-cone to allow UDP packets to arrive from the server to the client.
Basic and digest authentication is also supported.
The solution is not based on an RTSP DataSource as previously mentioned. We can say that it is based on an architecture similar to HLS, DASH, etc., using an RTSP MediaSource, MediaPeriod and SampleStreamWrapper, as well as a factory to create RTSP clients that can be personalized.
We feel the delay but we have had problems that have made it impossible to finish it before.
Pablo
portizb
on 5 Feb 2018
Our original implementation was only useful for our use cases, now we have
an RTP datasource for unicast and multicast streams, with fast multicast
acquisition, packet loss recovery, playback can be initiated from an SDP
file served by HTTP o RTSP, or manually configured, with support for trick
modes, muxed or elementary streams payloads...
It's now working with IP cameras, public internet streams and our IPTV
service.
We had to rewrite the elements several times to make it more generic and
useful but now we are happy with the result and we will make a final pull
request very soon.
Sergio
El 5 feb. 2018 10:14 p. m., "Pablo Ortiz" notifications@github.com
escribió:
Yes, we are at the end of the coding and debugging and in a very short
time, it will be available so that it can be tested. I am working with
Sergio @tresvecesseis https://github.com/tresvecesseis in this solutionThis version includes support for H264 over RTP as well as audio codecs
G711.x, and AC3. We are also currently working to support AAC over RTP.TCP connections and multicast mode are not supported at the moment. Only
unicast mode is supported in UDP including hole punching for Full-cone to
allow UDP packets to arrive from the server to the client.Basic and digest authentication is also supported.
The solution is not based on an RTSP DataSource as previously mentioned.
We can say that it is based on an architecture similar to HLS, DASH, etc.,
using an RTSP MediaSource, MediaPeriod and SampleStreamWrapper, as well as
a factory to create RTSP clients that can be personalized.We feel the delay but we have had problems that have made it impossible to
finish it before.[image: captura de pantalla 2018-02-05 a las 22 12 33]
https://user-images.githubusercontent.com/22323068/35829000-c1a3ab5c-0ac1-11e8-91a2-b81d8b5b6cf6.pngPablo
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/google/ExoPlayer/issues/55#issuecomment-363223200,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJ99vwKrCFCeW507SHgC0Fi0v0-nrsNsks5tR28YgaJpZM4CmVbp
.
tresvecesseis
on 6 Feb 2018
Let me show you several demo videos of ExoPlayer-2 running on several Android devices connecting to different RTSP Streams (Samsung SmartCam, Samsung Galaxy S7, Public internet cameras and catch up channel on IPTV).
ExoPlayer running on a Lyca TV Box device and a Samsung TV as the output device:
https://photos.app.goo.gl/lnF5ogJZDHzH6Y3x1ExoPlayer running on an Nvidia Shield tablet:
https://photos.app.goo.gl/OnUipQiyRd4N6wO42ExoPlayer running on Lyca TV Box and Nvidia Shield connecting to Samsung Galaxy S7 as IP Camera (using Android RTSP Camera Server app):
https://photos.app.goo.gl/4v65Ra6Odyvlt9K03
I hope you enjoyed the demos.
portizb
on 6 Feb 2018
This is awesome!! When you guys will available this ?
shinayser
on 6 Feb 2018
@shinayser As @tresvecesseis said, we will make a final pull request very soon.
portizb
on 6 Feb 2018
if there are no regressions with the latest changes we will try to push the
changes to our github repository as soon as the next week
On Tue, Feb 6, 2018 at 3:50 PM, Pablo Ortiz notifications@github.com
wrote:
@shinayser https://github.com/shinayser As @tresvecesseis
https://github.com/tresvecesseis said, we will make a final pull
request very soon.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/google/ExoPlayer/issues/55#issuecomment-363444983,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJ99v_qiDocrgGshxtuMvzA6-cd3UHteks5tSGaZgaJpZM4CmVbp
.
tresvecesseis
on 7 Feb 2018
we have just make a pull request (#3854) for the inclusion of our RTSP implementation, please test it with your own RTSP sources
tresvecesseis
on 15 Feb 2018
@tresvecesseis thank you for the PR! What is the preferred way to send you device compatibility feedback (perhaps by email)?
ened
on 17 Feb 2018
@ened an email will be ok, if there are problems, please attach the messages interchanged with the RTSP server, this patch will do the job:
```diff --git a/library/core/src/main/java/com/google/android/exoplayer2/util/rtsp/api/Receiver.java b/library/core/src/main/java/com/google/android/exoplayer2/util/rtsp/api/Receiver.java
index 6971a5e94..77d62580f 100644
--- a/library/core/src/main/java/com/google/android/exoplayer2/util/rtsp/api/Receiver.java
+++ b/library/core/src/main/java/com/google/android/exoplayer2/util/rtsp/api/Receiver.java
@@ -117,6 +117,8 @@ final class Receiver {
}
private void handleMessage(Message message) {
- Log.v("Receiver", message.toString());
+
switch (message.getType()) {
case Message.REQUEST:
eventListener.onReceiveSuccess((Request)message);
diff --git a/library/core/src/main/java/com/google/android/exoplayer2/util/rtsp/api/Sender.java b/library/core/src/main/java/com/google/android/exoplayer2/util/rtsp/api/Sender.java
index 8387e056c..25db60ec1 100644
--- a/library/core/src/main/java/com/google/android/exoplayer2/util/rtsp/api/Sender.java
+++ b/library/core/src/main/java/com/google/android/exoplayer2/util/rtsp/api/Sender.java
@@ -15,6 +15,8 @@
*/
package com.google.android.exoplayer2.util.rtsp.api;
+import android.util.Log;
+
import com.google.android.exoplayer2.util.rtsp.core.Message;
import java.io.IOException;
@@ -66,6 +68,8 @@ final class Sender {
try {
if (message != null) {
- Log.v("Sender", message.toString());
+
byte[] bytes = message.toString().getBytes();
outputStream.write(bytes, 0, bytes.length);
```
tresvecesseis
on 17 Feb 2018
@tresvecesseis
I tried RTSP from the "tresvecesseis:dev-v2-rtsp" branch. It works but I'm experiencing a 2-3 second delay. Is this normal or is there a way to eliminate this? Thanks.
FYI, using VXG only has about 1 second delay or less for the same IP cameras. Is this possible? We have issues with VXG and want to move to Exoplayer.
mvescovo
on 12 Apr 2018
It could be the buffer size, exoplayer uses a 2500ms buffer by default that
in case of isochronous live sources makes the video not start until 2500 ms
has passed but you could adjust this buffer to your liking
On Thu, Apr 12, 2018 at 6:53 AM, Michael Vescovo notifications@github.com
wrote:
I tried RTSP from the "tresvecesseis:dev-v2-rtsp" branch but I'm
experiencing a 2-3 second delay. Is this normal or is there a way to
eliminate this? Thanks.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/google/ExoPlayer/issues/55#issuecomment-380677538,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJ99v-8dUxJwGf__0kaRPYzubh2-sOMmks5tnt3BgaJpZM4CmVbp
.
tresvecesseis
on 12 Apr 2018
Great thanks! Hopefully I'll get a chance to try this tomorrow.
mvescovo
on 12 Apr 2018
It works! only ~2ms difference between VXG which is negligible. As far as I can tell looking at it it's the same. For anyone else new to Exoplayer I had to create a LoadControl and pass it in when the "SimpleExoPlayer" is created. I set all the values to 0.
mvescovo
on 13 Apr 2018
@tresvecesseis one other quick one. If I run the demo app and leave it running the feed eventually freezes. It seems like it's paused but I can't press play. Only pressing back and going into the activity again will make it work. To give an estimate of how long I'm running it, I just did it twice and the first time it took around 8 minutes to freeze and the second time around 12 minutes. Is this a result of settings in the demo app or something else to do with the demo? Or a possible bug? I'm running the same camera side by side with another tablet that's using VXG and it doesn't freeze.
Edit: I think this may not be related to exoplayer. I've realised that our VXG implementation is doing restarts and things when it detects it's not working. So it could be the camera or something else. I just wanted to know at a high level if this was likely related to the demo app or not.
mvescovo
on 13 Apr 2018
@tresvecesseis Does the code support "TCP interleaved playback" I tries using the your dev branch to play rtsp I had to modify some code to make it work, but was getting socket timeout exception.
My setup call looked something like this:
SETUP rtsp://example.com/media.mp4 RTSP/1.0
CSeq: 3
Transport: RTP/AVP/TCP;interleaved=0-1
guptamitesh
on 13 Apr 2018
@mvescovo At the moment the rtsp library does not support retries when it detects failure in the communication.
portizb
on 13 Apr 2018
@guptamitesh "TCP interleaved playback" is not supported. The current design only supports TCP for the control channel and UDP for each data channel. In RTSP interleaved mode the control and data channel is the same. So the RTSP client is waiting to receive the data through the UDP channel and for this reason the timeout exception occurs.
portizb
on 13 Apr 2018
Hi @portizb
Just looking through the code and just want to confirm that RTCP is not implemented?
miseri
on 13 Apr 2018
@portizb as long as I can detect a failure and restart myself that's fine (I haven't tried yet but I'm assuming I can). That's what we're doing with our current implementation. Thanks. By the way great job guys. It seems to work well for what I've tested so far. I'm so appreciative that you have made this contribution. A lot of people will benefit now.
mvescovo
on 13 Apr 2018
@miseri It is true. RTCP isn't implemented but the RTP module that we have created could have RTCP in the future and in that way, RTSP could support it.
portizb
on 13 Apr 2018
@mvescovo In principle, your application or activity can be notified through the Player.EventListener interface when an playback error occurs. Thanks for your feedback, we are happy to have been able to contribute with our grain of sand. ;)
portizb
on 13 Apr 2018
We have a very good news to announce. In a very short time we will support RTSP interleaved. ;)
portizb
on 18 Apr 2018
@portizb That's great news, just to confirm the interleaving will be without RTCP?
If I can find the time, I might be able to contribute towards it (I've implemented RTP/RTCP/RTSP in a c++ library before but I am unfamiliar with your/exoplayer architecture...)
miseri
on 18 Apr 2018
@miseri I can confirm that we already support RTP (in alpha phase) in interleaving but our goal is also to support RTCP because we had detected that a large number of RTSP servers that support interleaving close the connection because they do not receive RTCP packets.
portizb
on 18 Apr 2018
Ok, sounds good. FYI, you probably know about it already, but the live555 RTSP server (http://www.live555.com/) implements the interleaved mode and has been tested and debugged over many years. It is really solid. I found it to be really useful to test my RTP over RTSP implementation against it.
miseri
on 18 Apr 2018
@portizb don't sure where to ask. So ask here.
Have you started working on download service for RTSP?
ioKun
on 15 Aug 2018
I saw 2.9.0 was released today, but no mention of RTSP support. Reading through the entire issue exchange here it sounds like there has been some significant progress on its development, though still missing a bit or two. @tresvecesseis or @portizb Would you mind providing any kind of status on this? I'm mid-way through my third project needing low-latency (<300ms) playback, with this latest needing multicast support. The previous ones I've been able to painfully hobble along with GStreamer, but its just not worth the effort on Android and the NDK. I've found a couple of "pure java" alternatives, but I'd love to use my limited, but reliable exoplayer experience here. Likewise, if I can contribute to its maintenance/development, I'm happy to.
kylemallory
on 4 Oct 2018
Are there any updates?
floschu
on 4 Mar 2019
Are there any updates?
@floschu We are very busy working on other video projects. I hope that soon I can come back here. Thank you all!
portizb
on 13 Mar 2019
Hi, is ExoPlayer296 support RTSP?
I've got error
E/ExoPlayerImplInternal: Source error.
com.google.android.exoplayer2.upstream.HttpDataSource$HttpDataSourceException: Unable to connect to rtsp://wowzaec2demo.streamlock.net/vod/mp4:BigBuckBunny_115k.mov
at com.google.android.exoplayer2.upstream.DefaultHttpDataSource.open(DefaultHttpDataSource.java:281)
at com.google.android.exoplayer2.upstream.DefaultDataSource.open(DefaultDataSource.java:250)
at com.google.android.exoplayer2.upstream.StatsDataSource.open(StatsDataSource.java:83)
at com.google.android.exoplayer2.source.ExtractorMediaPeriod$ExtractingLoadable.load(ExtractorMediaPeriod.java:885)
at com.google.android.exoplayer2.upstream.Loader$LoadTask.run(Loader.java:381)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
at java.lang.Thread.run(Thread.java:764)
Caused by: java.net.MalformedURLException: unknown protocol: rtsp
at java.net.URL.<init>(URL.java:608)
at java.net.URL.<init>(URL.java:498)
at java.net.URL.<init>(URL.java:447)
at com.google.android.exoplayer2.upstream.DefaultHttpDataSource.makeConnection(DefaultHttpDataSource.java:426)
at com.google.android.exoplayer2.upstream.DefaultHttpDataSource.open(DefaultHttpDataSource.java:279)
at com.google.android.exoplayer2.upstream.DefaultDataSource.open(DefaultDataSource.java:250)
at com.google.android.exoplayer2.upstream.StatsDataSource.open(StatsDataSource.java:83)
at com.google.android.exoplayer2.source.ExtractorMediaPeriod$ExtractingLoadable.load(ExtractorMediaPeriod.java:885)
at com.google.android.exoplayer2.upstream.Loader$LoadTask.run(Loader.java:381)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
at java.lang.Thread.run(Thread.java:764)
on it
SimpleExoPlayer player = ExoPlayerFactory.newSimpleInstance(MainActivity.this);
player.setPlayWhenReady(true);
playerView.setPlayer(player);
DataSource.Factory dataSourceFactory = new DefaultDataSourceFactory(
MainActivity.this,
Util.getUserAgent(MainActivity.this, MainActivity.this.getString(R.string.app_name)));
MediaSource videoSource = new ExtractorMediaSource.Factory(dataSourceFactory).createMediaSource(uri);
IgorMan2
on 4 Apr 2019
Thank you for this great addition to ExoPlayer. Tried it and it works great!
my use case requires ultra-low latency (~200ms) and I was wondering what are the necessary tweaks required to make it happen.
I tried reducing the buffers in DefaultLoadControl.java but this didn't seem to have much effect.
What eventually worked for me was defining a playback speed greater than 1. this results in an almost real-time video stream - amazing! Is this is the correct approach for achieving this result?
My biggest problem so far is that the player occasionally freezes for quite a long time (even up to a minute), then the stream continues with a very long delay, which is weird because the buffers were set very low (much lower than the observed delay). How can that be?
How can I eliminate these freezes, where should I look?
Thanks!
jonspieg
on 17 Apr 2019
Thank you for this great addition to ExoPlayer. Tried it and it works great!
my use case requires ultra-low latency (~200ms) and I was wondering what are the necessary tweaks required to make it happen.
I tried reducing the buffers in DefaultLoadControl.java but this didn't seem to have much effect.What eventually worked for me was defining a playback speed greater than 1. this results in an almost real-time video stream - amazing! Is this is the correct approach for achieving this result?
My biggest problem so far is that the player occasionally freezes for quite a long time (even up to a minute), then the stream continues with a very long delay, which is weird because the buffers were set very low (much lower than the observed delay). How can that be?
How can I eliminate these freezes, where should I look?Thanks!
Please, can you help to me with example of playing rtsp sream via exoplayer? Just simple example.
IgorMan2
on 18 Apr 2019
Thank you for this great addition to ExoPlayer. Tried it and it works great!
my use case requires ultra-low latency (~200ms) and I was wondering what are the necessary tweaks required to make it happen.
I tried reducing the buffers in DefaultLoadControl.java but this didn't seem to have much effect.
What eventually worked for me was defining a playback speed greater than 1. this results in an almost real-time video stream - amazing! Is this is the correct approach for achieving this result?
My biggest problem so far is that the player occasionally freezes for quite a long time (even up to a minute), then the stream continues with a very long delay, which is weird because the buffers were set very low (much lower than the observed delay). How can that be?
How can I eliminate these freezes, where should I look?
Thanks!Please, can you help to me with example of playing rtsp sream via exoplayer? Just simple example.
@IgorMan2 ExoPlayer sort of has support for RTSP in the pull request #3854. To playback a rtsp media follow the steps below:
Clone the rtsp dev branch:
git clone -b dev-v2-rtsp https://github.com/tresvecesseis/ExoPlayer.git.
Open Android Studio and open the RTSP ExoPlayer2 project from your local git (dev-v2-rtsp).
Add your rtsp stream in the media.exolist.json file on RTSP Streams section.
Run demo app included.
Hope you enjoy.
portizb
on 22 Apr 2019
@portizb please, can you provide any hints on the low latency issue? .. I'm also working to reduce the latency as much as I can. Currently I'm getting values around 1sec and below (I have to do some measurements to get the exact value). First I tried using a default allocator with minimum values such as following:
DefaultAllocator allocator = new DefaultAllocator(true, C.DEFAULT_BUFFER_SEGMENT_SIZE);
DefaultLoadControl loadControl = new DefaultLoadControl.Builder()
.setAllocator(allocator)
.setBufferDurationsMs(40, 60, 30, 30)
.setTargetBufferBytes(C.LENGTH_UNSET)
.setPrioritizeTimeOverSizeThresholds(true)
.createDefaultLoadControl();
but I couldn't get times below 1sec with this approach. Now I'm trying to use my own loadControl class. I was wondering if you are using any kind of buffering at RTP level. Reading the code I can see that you use the following to read from the socket:
@Override
public int read(byte[] buffer, int offset, int readLength) throws IOException {
int bytesRead = super.read(packetBuffer, 0, RtpPacket.MAX_PACKET_SIZE);
if (bytesRead > 0) {
....
The MAX_PACKET_SIZE is 65507, so you are reading at most this value. In my case this is more or less the size of a frame. After this you use the RtpSamplesQueue to enqueue the RTP packets, but this queue doesn't seem to have a predefined value. Could this lead to some buffering that could be increasing the streaming latency?
This is from one side, on the other side I was reading this article about startup latency in ExoPlayer. It seems that if nothing is done the startup could consume a good amount of time (130 milliseconds as explained by the article author when decoders are reused). In this particular case I understand that the decoder must be prepared during RTSP session negotiation, is this correct?
Thank you very much for this great contribution and for your help.
rkachach
on 29 May 2019
@portizb please, can you provide any hints on the low latency issue? .. I'm also working to reduce the latency as much as I can. Currently I'm getting values around 1sec and below (I have to do some measurements to get the exact value). First I tried using a default allocator with minimum values such as following:
DefaultAllocator allocator = new DefaultAllocator(true, C.DEFAULT_BUFFER_SEGMENT_SIZE); DefaultLoadControl loadControl = new DefaultLoadControl.Builder() .setAllocator(allocator) .setBufferDurationsMs(40, 60, 30, 30) .setTargetBufferBytes(C.LENGTH_UNSET) .setPrioritizeTimeOverSizeThresholds(true) .createDefaultLoadControl();but I couldn't get times below 1sec with this approach. Now I'm trying to use my own loadControl class. I was wondering if you are using any kind of buffering at RTP level. Reading the code I can see that you use the following to read from the socket:
@Override public int read(byte[] buffer, int offset, int readLength) throws IOException { int bytesRead = super.read(packetBuffer, 0, RtpPacket.MAX_PACKET_SIZE); if (bytesRead > 0) { ....The MAX_PACKET_SIZE is 65507, so you are reading at most this value. In my case this is more or less the size of a frame. After this you use the RtpSamplesQueue to enqueue the RTP packets, but this queue doesn't seem to have a predefined value. Could this lead to some buffering that could be increasing the streaming latency?
This is from one side, on the other side I was reading this article about startup latency in ExoPlayer. It seems that if nothing is done the startup could consume a good amount of time (130 milliseconds as explained by the article author when decoders are reused). In this particular case I understand that the decoder must be prepared during RTSP session negotiation, is this correct?
Thank you very much for this great contribution and for your help.
@rkachach Are you testing with the latest changes on the dev-v2-rtsp branch? Please, you keep follow the pull request #3854
Your doubts are answered on:
https://github.com/google/ExoPlayer/pull/3854#issuecomment-485966021
https://github.com/google/ExoPlayer/pull/3854#issuecomment-487037671
portizb
on 30 May 2019
Does anyone know if widevine DRM works with the current implementation of this RTSP support ?
BogdanLivadariu
on 15 Sep 2020
Related issues
ojw28
·
3Comments
arjun-redspace
·
3Comments
TakuSemba
·
3Comments
KenendZ
·
3Comments
makazemi
·
3Comments
Most helpful comment
We have a rtsp, rtcp and rtp implementations for exoplayer but I don´t know if there is any interest from the maintainers in this code, we will only clean and submit the code if there is a request for them as we are a little overloaded right now
From: theCHARioT notifications@github.com
Reply-To: google/ExoPlayer reply@reply.github.com
Date: Saturday, 7 January 2017 at 12:33
To: google/ExoPlayer ExoPlayer@noreply.github.com
Cc: "[email protected]" tresvecesseis@gmail.com, Comment comment@noreply.github.com
Subject: Re: [google/ExoPlayer] RTSP support (#55)
Is anyone using ExoPlayer with rtsp streams?
With millions of cameras using rtsp I think it would be very useful for ExoPlayer.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.