RTSP support

[kjeremy]

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.

[Ood-Tsen]

MediaExtractor doesn't support RTSP.

You have to make a rtsp-renderer by yourself.

[kjeremy]

Can you elaborate?

[chrisjenx]

+1, Any advancement on this?

[Ood-Tsen]

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.

[chrisjenx]

Yeah we were looking at talking to ipcams most of which use rtsp.

On Thu, 21 May 2015 07:52 Ood Tseng notifications@github.com 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
#55 (comment).

[Ood-Tsen]

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.

[ojw28]

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.

[miseri]

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]

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?

[chrisjenx]

We would be interested in supporting it if the work was done.

On Fri, 3 Jul 2015 09:31 miseri notifications@github.com 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
#55 (comment).

[ojw28]

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.

[Anshumansharma12]

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.

[chrisjenx]

Rtsp doesn't work with exoplayer.

On Thu, 11 Feb 2016, 09:30 Anshumansharma12 notifications@github.com
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
#55 (comment).

[juliusfriedman]

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.

[ened]

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:

1. Exo determines an rtsp:// URL belongs to a RtspDataSource & creates it. (via DefaultDataSource)
2. 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”.
3. RtspExtractor#init is called, but only stores the ExtractorOutput (extractorOutput) in a member variable. It will be needed in step 5
4. 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.
5. 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.
   1. RtspExtractor now creates the tracks and stores them in extractorOutput. If anything fails or a codec is not supported, RtspExtractor throws an IOException
   2. With the tracks now in place, RtspExtractor sets a member variable tracksCompleted to true
   3. RtspExtractor requests more data from the ExtractorInput
6. 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:
   1. There will be maximum 3 sinks (for audio, video, text).
   2. Each sink remembers the last byte buffer it received
   3. 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).
7. 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.

[dzualeks]

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?

[tresvecesseis]

Are you sending the periodic rtsp keepalives? if not, the server will
teardown the session.

El 7 oct. 2016 9:48 p. m., "dzualeks" notifications@github.com 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
#55 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AJ99v7MckXB6u0dlT8kMdueEFVv6Dixyks5qxqIMgaJpZM4CmVbp
.

[dzualeks]

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

[tresvecesseis]

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" notifications@github.com 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. 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

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#55 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJ99v-feJbH8xSYiCdF5nH2dIMYSth3Gks5qxztvgaJpZM4CmVbp
.

[dzualeks]

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?

[tresvecesseis]

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 notifications@github.com
Reply-To: google/ExoPlayer reply@reply.github.com
Date: Saturday, 8 October 2016 at 17:22
To: google/ExoPlayer ExoPlayer@noreply.github.com
Cc: "tresvecesseis@gmail.com" tresvecesseis@gmail.com, Comment comment@noreply.github.com
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.

[chrisjenx]

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 notifications@github.com 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 notifications@github.com
Reply-To: google/ExoPlayer reply@reply.github.com
Date: Saturday, 8 October 2016 at 17:22
To: google/ExoPlayer ExoPlayer@noreply.github.com
Cc: "tresvecesseis@gmail.com" tresvecesseis@gmail.com, Comment <
comment@noreply.github.com>
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
#55 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABHRsYjWu8jEmtidLaWc9lQUA_4G3dPtks5qx9lLgaJpZM4CmVbp
.

[dzualeks]

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.

[chrisjenx]

Would love to see this impl!

On Wed, 12 Oct 2016, 14:23 dzualeks, notifications@github.com 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
#55 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABHRsb07T7REpt9-RbhITOvbjpYlpPi-ks5qzN1fgaJpZM4CmVbp
.

[shinayser]

Want to leave here my request for RTSP too! Its a standard that is used by a HUGE amount of cameras on the market.

[iamcxa]

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.

[miseri]

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.

[ioKun]

@portizb don't sure where to ask. So ask here.
Have you started working on download service for RTSP?

[kylemallory]

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.

[floschu]

Are there any updates?

[portizb]

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!

[IgorMan2]

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

[jonspieg]

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!

[IgorMan2]

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.

[portizb]

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.

[rkachach]

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

[portizb]

@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:
#3854 (comment)
#3854 (comment)

[BogdanLivadariu]

Does anyone know if widevine DRM works with the current implementation of this RTSP support ?