Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for RTSP H263 #63

Merged
merged 7 commits into from
Jun 16, 2022
Merged

Conversation

rakeshnitb
Copy link
Contributor

Added H263 RTP Packet reader and added support for H263 playback through
RTSP.

Change-Id: I348cc4d8e974b5275409b816a9d52aa29f593233

Added H263 RTP Packet reader and added support for H263 playback through
RTSP.

Change-Id: I348cc4d8e974b5275409b816a9d52aa29f593233
Copy link
Contributor

@claincly claincly left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please make sure you sync to the newest head in main.

P.S. Take a look at the style guide for future reference.

rakeshnitb and others added 3 commits May 5, 2022 14:36
Change-Id: I987baf379ecf3ba3f387cb38f22646023739addb
Change-Id: If1f80a369b47319251e262c8f171091bb37e90c5

if (pBitIsSet == true) {
int startCodePayload = data.peekUnsignedByte() & 0xfc;
// Packets that begin with a Picture Start Code(100000). Refer RFC4629 Section 6.1.1.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i have difficulty understanding here: if picture start code is 0b100000 which is 64, then it'll always fail the check startCodePayload < PICTURE_START_CODE. Maybe you quoted a wrong RFC section?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Picture start code is "100000" from msb, so it is 128. If startCodePayload is less than 128 then packet is follow-On.

@@ -168,7 +170,7 @@ public void seek(long nextRtpTimestamp, long timeUs) {
private void getBufferFlagsAndResolutionFromVop(ParsableByteArray data, boolean gotResolution) {
// Picture Segment Packets (RFC4629 Section 6.1).
// Search for SHORT_VIDEO_START_MARKER (0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0).
int currPosition = data.getPosition();
int currDataOffset = data.getPosition();
long shortHeader = data.readUnsignedInt();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what is the reason to name this shortHeader? It's not of type short and I can't find reference to any 'short' in the RFC

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Its taken from h263 decoder. Added link for the same in javaDoc.

@@ -190,11 +192,11 @@ private void getBufferFlagsAndResolutionFromVop(ParsableByteArray data, boolean
height = (short) (144 << (sourceFormat - 2));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you explain a bit here? I'm particularly lost why the shift bits are derived from a sourceFormat. Is the related logic in the H263 spec? I can't find it in RFC4629.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://cs.android.com/android/platform/superproject/+/master:frameworks/av/media/codecs/m4v_h263/dec/src/vop.cpp;l=1128. According to this logic :
sourceFormat 2 is 176x144, sourceFormat 3 is 1762x1442, sourceFormat 4 is 17622x14422 and so on.

}

if (fragmentedSampleSizeBytes == 0) {
getBufferFlagsAndResolutionFromVop(data, isOutputFormatSet);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again, if the method does not return anything, can you rename it to parseVopHeader and specify it sets width/height/flags in the javadoc.

Change-Id: I0d728c695c9e11c5a50ef6f211bde614df4bbe71
Change-Id: I6ae45dc710245769f36130ead4077d8e9980bf54
@claincly
Copy link
Contributor

claincly commented Jun 9, 2022

Can you do a merge with head? I can't merge the PR internally until then.

@marcbaechinger marcbaechinger merged commit dc0e5c4 into androidx:main Jun 16, 2022
marcbaechinger added a commit that referenced this pull request Jun 16, 2022
PiperOrigin-RevId: 455347182
(cherry picked from commit dc0e5c4)
marcbaechinger added a commit that referenced this pull request Sep 30, 2022
marcbaechinger added a commit that referenced this pull request Sep 30, 2022
PiperOrigin-RevId: 455347182
(cherry picked from commit e220f53)
@androidx androidx locked and limited conversation to collaborators Mar 4, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants