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

Created a detailed documentation for SRT API functions #540

Merged
merged 4 commits into from
Feb 14, 2019

Conversation

ethouris
Copy link
Collaborator

This completes the API description with all required details concerning API functions.

A controversial thing here can be an inevitable statement used sometimes that there are still bugs or design flaws in the area of error types returned; it would be desired that these bugs are fixed ASAP, but if they are not, and not mentioned here, they might be quickly forgotten.

@maxsharabayko maxsharabayko added this to the v.1.3.2 milestone Jan 23, 2019
@maxsharabayko maxsharabayko added the [docs] Area: Improvements or additions to documentation label Jan 30, 2019
* `SRT_EINVALBUFFERAPI`: Incorrect API usage in stream mode:
* Currently not in use. The FileSmoother used as the only for stream
mode does not restrict the parameters.
* `SRT_ELARGEMSG`: Message to be sent can't fit in the sending buffer (that is,
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Wrong, this is an error that describes the sendmsg call. Something wrong here.

const char* srt_getlasterror_str(void);
```

Get the text message for the last error.
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Needed information that the error is stored in a thread-local storage, so it is valid until calling the next function that might affect it.

the packet sequence number that was last reported by ACK message and the
sequence number of the packet just sent. Note that ACK gets received
periodically, so this value is most accurate just after receiving ACK and
becomes a little exaggerated in time until the next ACK comes.
Copy link
Collaborator Author

@ethouris ethouris Feb 1, 2019

Choose a reason for hiding this comment

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

Research may be necessary to find out if this value shouldn't be (or even isn't) calculated as the distance between the packet that was last ACK-ed and the packet that was the last sent sequence at the same time when receiving the ACK (not at the time when the query was made).

data scheduled for sending by the application and increases with every ACK
received from the receiver, after the packets are sent over the UDP link.

* ` byteAvailRcvBuf`: Bytes available in the receiver buffer.
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

space

docs/API-functions.md Outdated Show resolved Hide resolved
docs/API-functions.md Outdated Show resolved Hide resolved
docs/API-functions.md Outdated Show resolved Hide resolved
docs/API-functions.md Outdated Show resolved Hide resolved
// perfmon with Byte counters for better bitrate estimation.
int srt_bstats(SRTSOCKET u, SRT_TRACEBSTATS * perf, int clear);

// permon with Byte counters and instantaneous stats instead of moving averages for Snd/Rcvbuffer sizes.
Copy link
Collaborator

Choose a reason for hiding this comment

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

"permon" or "perfmon"?

@rndi rndi merged commit e46f114 into Haivision:master Feb 14, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[docs] Area: Improvements or additions to documentation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants