Wednesday, August 27, 2014

C++ Abstract and Interface fundamentals

Virtual Function A function preceded by virtual keyword. Intention is that this function would be overloaded in some derived classes. All virtual functions need not be overridden in some derived classes. They can remain in base class as it is.
            virtual void VirtualFunction();
Pure Virtual Function A virtual function with no implementation which is set equal to zero.
            virtual void PureVirtualFunction() = 0;
This can have an implementation in base class. You cannot instantiate a class having a pure virtual function. If you create a pointer of base class pointing to the derived class, it would call the function of the derived class. So, how do you use it?
            DerivedClass myDerivedClass;
            BaseClass* myBaseClass;
            myBaseClass = &myDerivedClass;      // In one line BaseClass* myBaseClass = &myDerivedClass;
            myBaseClass->PureVirtualFunction(); // This would call implementation of the pure virtual
                                                // function in derived class
You have to BOTH override AND implement a Pure Virtual Function in the class that derived from the class that had the pure virtual function. If no class derived from it, then it's not required.
Abstract Function Synonym for Pure Virtual Function. A function that is pure virtual.
            void AbstractFunction() = 0;
Abstract Class Class that has at least one Pure Virtual Function
Interface Class Class that has all functions Pure Virtual. And it has no member variables. This is not a rule per se. Intention is that the interface class will not have any implementation of its own. All required concrete class that derive from it must implement/override the functions in the interface. Note that there is a great temptation to add concrete member functions and data to iterface classes. This must be resisted, in general it is a sign that the interface is not well factored. Data and concrete member functions tend to imply a particular implementation and as such can inherit from the interface but should not be in that interface. A general test is the "is a" vs "has a", as in a Square is a Rectangle, but a Square has a set of sides. In other words, "is a" would use Abstract class and "has a" would use Interface.

Note: The ISO C++ Standard specifies that all virtual methods of a class that are not pure-virtual must be defined. Note that a destructor must be defined even if it is declared pure-virtual. Ref:

Base Class/Super Class/Parent Class
Derived Class/Inherited Class/Sub Class
Abstract Function/Pure Virtual Function

Sunday, August 24, 2014

Convert FLV to MP4 or MKV without any loss

1. Demux the FLV using FLV Extract or
   FLVExtractCL -v -a INPUT.flv

2. Remux the video.264 and audio.aac to MP4 or MKV
   MP4Box -add videoFile.h264 -add audioFile.aac OUTPUT.mp4
   mkvmerge -o OUTPUT.mkv videoFile.264 audioFile.aac
   ffmpeg -i INPUT.flv -vcodec copy -acodec copy OUTPUT.mp4

Remember you need to set the correct framerate when muxing h264 video.
You can load the mp4 from ffmpeg directly into mkvmerge but I had a few issues so I just demux and then mux into mkv 
and I don't have any problems

Use MP4Box to extract raw streams from mp4 files
MP4Box -raw 1 -raw 2 INPUT.mp4
MP4Box -raw 1:output=filename INPUT.mp4
MP4Box -raw * INPUT.mp4

for users who dont like to code or type, a simple GUI for lossless packaging of RAW audio data (or RAW video data) is yamb.
I even prefer that to fixing FLV's with FLV Fix tools.

For example, when you (losslessly) extract *.264 and *.aac with FLVExtract and you then try to package them as *.mp4 with yamb,
then use the "Avg Frame Rate" (and not the "True Frame Rate") displayed by FLVExtract. yamb sometimes ask you to enter "frame
rate", sometimes it doesn't.

If the MP4 is still out of sync (audio vs. video), then use as "frame rate" the "videoframerate" as seen by "FLV Fix" (Replay
Media Catcher 4) after you have fixed the FLV with "Fix Duration".

Tuesday, August 12, 2014

Function: Parameter as Reference or Pointer

void funcParameterAsReference(int& inputOrOutput)
    inputOutputVal = 5;

int myInt = 0;
void funcParameterAsPointer(int* inputOrOutput)
    *inputOutputVal = 5;

int myInt = 0;
My rule of thumb is:
Use pointers if you want to do arithmetic with them or if you ever have to pass a NULL-pointer. Use references otherwise. So for input parameter use const reference and for output parameter use plain reference.
As input parameter :
void func(const int& input);
As output parameter :
void func(int& Output);
Why should pass-by-reference be used instead of pass-by-pointer? The most obvious reason is that a reference cannot be null. In a function that takes a pointer, you have to check that the pointer is not null before you use it, at least with a debug assertion. During a proper code review you have to analyze more code to be sure that you don't accidentally pass a null pointer to a function that doesn't expect one. I've found that it takes much longer to review functions that take pointer arguments for this very reason; it's so much easier to get it wrong when using pointers.
One advantage of using pointer as a parameter is when you have to add a new parameter to an existing function (for whatever reason). This way you can pass NULL to it, if it doesn't use the parameter in the implementation (definition)
void myFunc1(int* inp);
void myFunc2(int* inp);

int main()
    int inp = 0;
    myFunc1(&inp); // You can't pass NULL to myFunc1 because it uses inp in the implementation. If NULL is passed, 
                   // it will crash. 
                   // e.g. 
                   // int* inp = NULL;
                   // myFunc1(inp);
                   // OR
                   // myFunc1(NULL);

    cout << "inp = " << inp << endl;
    myFunc2(NULL); // You can pass NULL to myFunc2 because it doesn't use inp in the implementation

    return 0;

void myFunc1(int* inp)
    *inp = 99;
    cout << "I am in myFunc1" << endl;

void myFunc2(int* inp)  
    cout << "I am in myFunc2" << endl;