htwdd-rn / rtsp-streaming Goto Github PK

The branches dev/optimization and dev/vlc-compat introduced some new classes which are not explained in the file Projektbeschreibung.md yet.

These classes are:

• AviMetadataParser
• CustomLoggingHandler
• QuickTimeMetadataParser
• VideoMetadata

The class descriptions in Projektbeschreibung.md are not rendered correctly in the Github UI.
This is caused by some missing whitespace characters at the end of the previous lines or missing empty lines.

The API of FecHandler makes it possible to retrieve a FEC packet without checking if one is ready.

I suggest to call isReady() in the getPacket() method to prevent such a behaviour.

Currently the RtpHandler receives an image and processes it to create a RTP packet.
If the error correction via FEC is used, the created packet is given to the FecHandler.
After that, the RTP packet is returned to the Server, which then sends it to the receiver.
If a FEC packet was completed with the last RTP packet, the Server manually retrieves this packet from the RtpHandler and sends it too.

A better design for the interface of this functionality could be to return a list of RTP packets from the RtpHandler when jpegToRtpPacket() is called.
This not only enables the transparent sending of the FEC packet (which is a special RTP packet), so that the Server does not have to know about FEC and has not to process these packets manually.
It also makes the creation of multiple RTP packets from one JPEG image possible.
(The VLC Media Player does that already.)

When executed without starting the client and thus without RTSP connection, the Server throws a NullPointerException when closing the window because the timer was not initialized.

In the RTPpacket constructor with bitstream data as argument most header fields are set with defaut values.

This is incorrect and a lazy implementation, because the header of the packet is accessible and just has to be parsed.
It should be mentioned that the parsing of the header data correlates to the construction of it at the server side, which is a TASK for the assignment.

So the parsing could be implemented but then may also be part of the assignment.

While this is currently not an issue of the functionality of the client, it should be fixed to get more compatible with RFC 3550 (RTP) and RFC 2435 (JPEG over RTP).