Decorator Pattern


Goal: adding feature to a class, e.g. CPerson.
How: instead of subclassing, we use Person as a data member of the new class, e.g. Son.
By doing so, 1. no change to CPerson, 2. no calling the existing class’s constructor.
In this example below, we decorate CPerson so that it becomes a CSon, and 20 years later, we decorate the same person so that he becomes a CDad. CPerson’s constructor is only called once, at birth.
——————– code ——————–

class IPerson
{
public:
virtual void Talk() = 0;
};
class CPerson
{
public:
void Talk()
{
printf(” Person is constructed\n”);
};
};
class CSon: public IPerson
{
CPerson &mPerson;
public:
CSon(CPerson &person): mPerson(person)
{
};
void Talk()
{
printf(” I am a son\n”);
};
};
class CDad : public IPerson
{
CPerson &mPerson;
public:
CDad(CPerson &person) : mPerson(person)
{
};
void Talk()
{
printf(” I am a dady\n”);
};
};

int main()
{
const char* const msg = “person has been decorated into a”;
CPerson person;
person.Talk();
printf(“%s son\n”, msg);
CSon son(person);
son.Talk();
printf(“%s dady\n”, msg);
CDad dad(person);
dad.Talk();
return 0;
}
/*output
Person is constructed
person has been decorated into a son
I am a son
person has been decorated into a dady
I am a dady
*/

Advertisements

RTP over RTSP


Why: to simply router configuration, so that only one fixed port number, 554, needs to accept connection.
How: Server sends video in the response of PLAY command. For each channel the format is like this:
[ Dolloar sign $, one byte channel ID, two bytes to say length of data, stream data itself ]
Channel ID is defined in SETUP response for that channel, e.g. RTP/AVP/TCP;unicast;interleaved=0-1, where 0 is RTP and 1 is RTCP. The stream data is sent as binary.
Head up: If RTSP wants RTP to be TCP based, RTP must be embedded into PLAY response, and therefore no such thing as RTP TCP port.
Reference: http://www.ietf.org/rfc/rfc2326.txt
https://www.ietf.org/mail-archive/web/mmusic/current/msg02030.html

Server Push


There are two kinds of server pushes, which I call the true and the fake.

The Fake: I see it for Chrome to play MJPEG. It’s more of a browser feature. The server keeps sending jpg pictures and browser play video by replacing it’s picture one after another. It doesn’t need HTTP/2. Keywords: multipart x-mixed-replace boundary

The True: client receives resources without requesting. HTTP/2 required.
for Nginx, it has to be 1.13.9 and up, which was released this year 2018.

Crossdomain Access


The problem: when a web page from site A access files on site B, browser complains such as crossdomain access denied.
What it is really complaining is that browser, or plugin, doesn’t want to load resource fro site B unless B gives explicit permission.
When web based video player and video content are on different servers, this complaint happens.
Tools used for testing: JW Player 7.8.4 premium version, “primary”:”flash” vs “primary”:”html5″
The fix depends on the player mode: HTML5 vs flash.
For Flash, error message is “Cannot load M3U8: crossdomain access denied (2048)” The fix is creating /crossdomain.xml with content like:
<cross-domain-policy>
<site-control permitted-cross-domain-policies=”all”/>
<allow-access-from domain=”*” to-ports=”*”/>
</cross-domain-policy>
For HTML5, error message is “Cannot load M3U8: Crossdomain access denied”. The fix is adding Access-Control-Allow-Origin in the HTML header, e.g by editing nginx.conf.