Please give me clarification on the below for my web cam capture and send over internet application?
1. I read that the UMC's H264 encoder needs YUV input buffer in the GetFrame method. What kind of YUV is needed out of the commonly known formats such as I420, YV12, UYVY, YVYU etc?
2. I referred the EncodeStream method towards the end of IPP UMC reference manual. It seems to encode a number of frames given as a parameter from the input YUV buffer. Is this always the correct approach? Can we encode each buffer by buffer as captured by the Webcam?
In other words, is it advantageous to construct an big chunk of input buffer and encode in one shot instead of encoding each frame by frame and send over internet?
3. There is one bit rate parameter to be given in the H264EncoderParams.info.bitrate variable. What is the value that need to be filled in here? I have a guess - Is it calculated as the frame size * bits per pixel*frame rate? Please confirm.
1) It is I420. Check the article here (YUV(I420) and Y, U, V separate plane part ) on other format. http://software.intel.com/en-us/articles/getting-started-with-intel-ipp-unified-media-classes-sample...
2) The application need to use GetFrame() method to encode one frame data. If you have a buffer data, it needs to encode frame by frames.
3) The bit rate parameter is to suggest the encoder the targeted encoded video size. It is bits per seconds.
For the first question: In I420/YV12 format, the U,V plan order is different. I420 takes Y/U/V order, and YV12 takes Y/V/U order. The input format for media Data is decided by your input YUV data. If your input YUV data is YV12, it can set as YV12 format ( Many YUV files are stored at that format, so that simple sample code takes YV12 as the format), or the video is I420, it needs to set it as UMC::YUV420. The codec internally will convert it into UMC::YUV420 format to encode.
As to the bitrate, this is decided by your application, the encoder will use the rate control method to match the encoded video to that bitrate. Of course, the higher bit rate can achieve higher video quality, but the encoded file size (or required network bandwidth if transferred in network) will increase. You can did some test to find what is best for your application.
Thank you! I have a few more queries.
1. Can you please let me know if there is any format other than I420 and YV12 ? If there are more, please direct me to the the complete list of input formats supported by H264 encoder?
2. In the example program given, we have a line like
Params.key_frame_controls.method=1; What is this meant for? What are the possible values for method field? Is it a compulsory field?
3.In the reference PDF document, we have a huge list of parameters for the UMC::H264EncoderParams such as coding_type, B_frame_rate, treat_B_as_reference, num_ref_frames, num_ref_to_start_code_B_slice etc etc.Are these meant to be filled in by the application program? Could you please let me know the set of parameters that need to be set by the program?
4. My starting point in the application is the Webcam captured data. Is it feasible from my part to devise a solution which sends Key Frame, followed by difference frames, followed by Key Frame followed by difference frames etc? This I know, doesn't relate to IPP as such, but please help if you can.
Thanks in advance,
1> You can check the following format at umc_structors.h.
Most of them can be used as the input video data. Note, if it is not the YUV420, the codec will convert the color first.
2). This value can be 0 or 1. If is 0, the codec will set the key frame interval. If it is 1, you can specify the interval. For example, every 10 frames have 1 I frame. You can does not set it, and let the encoder choose the value.
3) If you are not familiar with them, you can only set some required values, and use default value for others.
Params.info.bitrate = ??;
Check the following two examples, if you want to set them to control encoder behavior.
4)I am not sure if I fully understand your question. The encoder will create some key frames (I frames), and P/B frames. I think your application need to implement how to sends/ receives these frame data.
The Unified Media Classes are intended for use with various decoding, encoding, and
transcoding applications, as well as media plug-ins and filters, for example, Microsoft
DirectShow* filters. "
My question is, if there is any special support in IPP for using with the DirectShow applications?
You just need to implement your DirectShow transform filter, and call the UMC processing within your filter. Not that you will have to perform some additional work on the output pin of your filter to supply a compatible media type with the downstream filter. For example, the VMR render filter accepts an RGB media type, not YUV.
If you need a ready DirectShow filter, take a look at the Intel Media SDK.
I downloaded the Intel media SDK and browsed through the specification PDFs. As you said,I could see the H.264 Encoder DirectShow Filter. Could you please elaborate on thebelow?
1. The Licensingfee and other terms/conditions
2. Is there any hardware compatibility issues with other x86 hardwares where Windows OS ( XP, Vista, Windows 7 etc) will be running?
3. Any exceptional case / known issues in case of non-Intel platforms in the software side? ( We may not be able to enforce the userto use intel hardware only forrunning our software)
4. In our programs, we make use of MEDIATYPE_Video as major type for query/set methods. Could you please let us know what is FORMAT_VideoInfo2 ?