Issue: google/ExoPlayer#9697
Before, the `MAX_SEQUENCE_NUMBER` is 65535, such that the logic to get the next
sequence number:
`previousSeqNumber + 1 % MAX_SEQUENCE_NUMBER`
yields 0 when `previousSeqNumber` is 65534. However, the next sequence number
should be 65535.
PiperOrigin-RevId: 410530098
*** Original commit ***
Migrate callers of ExoPlayer.Builder#build() to buildExoPlayer()
An upcoming change will update build() to return Player.
PiperOrigin-RevId: 401468532
Issue: #9430
The current supported SDP (RFC2327) spec only allows for alpha-numeric
characters in the attribute-field. RFC4566 (section 9, token type) allowed
extra characters, and this CL adds the support.
PiperOrigin-RevId: 397301173
Some server will send partial URIs in the RTP-Info header, while the RTSP spec
requires absolute URLs.
Issue: #9346
#exofixit
PiperOrigin-RevId: 395452741
Issue: #9254
#minor-release
We used to allow only alphanumerical characters in session id. The spec also
allows "$", "-", "_", ".", "+" (RFC2326 Sections 3.4 and 15.1).
PiperOrigin-RevId: 388873742
The dokka javadoc generation tool complains when parameter names don't match between a method and its override. This change updates occurrences where there is currently a mismatch.
Notable renamings that might be controversial:
- `onPlaybackStateChanged(int state)` to `onPlaybackStateChanged(int playbackState)` affected a lot of lines but seems more consistent with other '-Changed' methods.
- `handleMessage(int messageType, Object payload)` to `handleMessage(int messageType, Object message)`
- `ExtractorInput` and `DataSource` inherit `DataReader` which had `read(byte[] target, ...`, while data sources normally called the first parameter `buffer`. I have standardized these all to use `buffer` even though it looks out of place in the `ExtractorInput` interface (which has more `read` methods with `target`).
PiperOrigin-RevId: 387290360
Using all lower case RTSP headers is perfectly valid, as the spec mandates case
insensitively. However, some RTSP servers do not implement the RTSP spec
closely and does not recognize the lower case headers. This change aims
at using the header names as defined in the RTSP spec to maximize compatibility.
Issue: #9182
PiperOrigin-RevId: 386224566
Issue: #9183
RFC2326 Section C.1.1 specifies that the URI to identify a track can be either
absolute (like rtsp://example.com/path) or relative (like "path"). Currently
we don't handle absolute URI, and this CL is to add the support.
Note though, we don't currently use the Content-Base or Content-Location
headers for the session URI.
PiperOrigin-RevId: 384649818
Previously, a SocketTimeourException is used to signal the end of the stream
that is caused by "no RTP packets received for a while". However, such
signaling is inappropriate under TransferRtpDataChannel, or FakeRtpDataChannel
in RtspPlaybackTests.
Hence, the signaling of end of stream is changed to use RESULT_END_OF_INPUT.
The RtpDataChannel implementations will Still block until a set timeout, but
will return a C.RESULT_END_OF_INPUT should a timeout occur, instead of
throwing a nested SocketTimeoutException.
This also allowed customization of the timeout amount, in
RtspMediaSource.Factory
PiperOrigin-RevId: 380981534
Some server will wrongly insert duplicated attributes. We used to treat this as
a unrecoverable error, but it is better to treat the duplicated attributes in
an "over-writable" fashion like HashMaps.
Issue: #9080,
Issue: #9014
PiperOrigin-RevId: 380547079
The test prepare_withSupportedTrack_playsTrackUntilEnded
- sets up the supported AAC track with the RTSP server;
- uses RtpPacketTransmitter to send RTP packets from the server to the client;
- runs the player until the playback has ended, and
- asserts on the data RTSP has received and queued to the SampleQueue.
In the test, it was necessary to create a FakeUdpDataSourceRtpDataChannel. The
reason we cannot reuse TransferRtpDataChannel is, we rely on BlockingQueue.poll
timeout to identify the end of an RTSP stream, but the time out mechanism is
unstable in Robolectric. For example, when the timeout is set to 8,000 ms, the
actual timeout occasionally happens after 2,000,000 ms (in FakeClock).
PiperOrigin-RevId: 380528710
In prepare_withSupportedTrack_sendsPlayRequest(), the DESCRIBE includes two
tracks, one AAC and one MP4A-LATM. The test is run until a PLAY is sent, and
asserts on only one SETUP is sent (for AAC).
In prepare_noSupportedTrack_throwsPreparationError(), the DESCRIBE includes one
track: one MP4A-LATM. This format is not supported at the moment, so the player
will throw out an error, on which we assert.
PiperOrigin-RevId: 380131458
The current code does not catch the IAE thrown when building a MediaDescription
or SessionDescription. This CL catches the IAE and propagates it as a
ParserException.
Issue: #9014.
#minor-release
PiperOrigin-RevId: 377544439
Related to Issue: #8941.
RTSP message body's format is not regulated by the RTSP spec, meaning it can
use either CRLF or LF as its line terminator. The old code assumes every line
ends with CRLF (RTSP message and the message body); the new code will rely on
the Content-Length information to receive the bytes for the message body.
#minor-release
PiperOrigin-RevId: 377475565
Related to: Issue: #9010
Profile-level-id (Format.codecs) can be generated from SPS if SDP does not
include it.
#minor-release
PiperOrigin-RevId: 377251211
Authentication sequence in RTSP:
- Server replies "Unauthorized" to our DESCRIBE request, and includes the
necessary information (i.e. realm, digest nonce, etc) in WWW-Authenticate
header
- After `RtspClient` receives the response, we
- Parse the WWW-Authenticate header, stores the auth info. The info is saved
for all further RTSP requests (that all need to carry authorization headers)
- send the second DESCRIBE request with the Authorization header.
#minor-release
PiperOrigin-RevId: 376116302
The method openSocket in RtspMessageChannel does not actually open a socket.
The 'open' term refers more to opening the message channel.
#minor-release
PiperOrigin-RevId: 375908999
Previously, RTSP interleaved binary data is posted onto the playback thread
for handling, the playback thread then adds the received data to a queue.
A loader thread will later dequeue the data and process it.
In this CL, the binary data is sent through a separate listener, on
RtspMessageChannel's RTSP receiving thread.
#minor-release
PiperOrigin-RevId: 375907609
NAT will block off incoming UDP connection because the router has no knowledge
of the necessary port mapping (the mapping is never set up because UDP is
connectionless).
The end result is, the UDP socket to receive RTP data will timeout. After the
`SocketTimeoutException` is caught, the following takes place to try streaming
with TCP (or, RTP over RTSP).
- `RtspClient` sends TEARDOWN to tear down the current session.
- `RtspClient` re-connect to the RTSP server.
- `RtspMediaPeriod` cancels all loading `RtpDataLoadables` (that are using UDP)
- `RtspMediaPeriod` constructs new `RtpDataLoadables` that use
`TransferRtpDataChannel`, and starts loading.
- Once the `RtpDataLoadables` are up and running, we are ready to receive.
`RtspClient` sends the SETUP requests.
- The rest of the flow is unchanged.
#minor-release
PiperOrigin-RevId: 373310774
RTSP interleaving enables RTP packets to be sent using RTSP's TCP connection.
The interleaving RTSP messages contain binary data only and always start with a
'$'. Normal RTSP messages contain line breaks (CRLFs) that indicate complete
lines.
#minor-release
PiperOrigin-RevId: 372990181
