Problem in varying bit rate in Simple player

[suchethanswaroop]

Hi all,

I encoded a YUV sequence using the " simple_player.exe " at a low bit rate (2,04,800 bits/sec) and decoded it too. I measured the quality ( PSNR and MSE) of the output sequence wrt the input sequence.

I repeated the same by encoding the seq at a high bit rate ( 12,28,800 bits/sec) and measured the PSNR and MSE of the output seq . It never changed. It was the same as the first one. ( Quality of the video increases with increase in bit rate )

I used vc1 codec to do this. ( changed the bit rate in vc1.par)

i think the code is not accepting the given bit rate at all. Could some one please enlighten me regarding this ?

Regards,

Suchethan

[Tamer_Assad]

Hi,

The UMC simple_player.exe performs decoding and rendering features, you may choose to render to a yuv file. However it doesn't perform encoding, you may use the "umc_video_enc_con" sample for this purpose.

There is no absolute high/low birate value, consider the resolution of your media (widthXheight) and the frame rate (Fps). A high bit rate at a certain reolution h*w and frame rate Fps, still can be measured as a low bit rate at a higher h*w and Fps.

Also, you must consider the utilized codec standard, for example MPEG has profile calssification, each profile has limitations for the bit rate @ (w*h*Fbs).

Regards,
Tamer

[suchethanswaroop]

Quoting - Tamer Assad

Hi,

Sorry for miscommunicating ... I used " umc_video_enc_con" for encoding a yuv sequence using vc1 codec and simple_player.exe to decode the .vc1 file . The decoded sequence was not even close to the original sequence interms of quality. ( lots of blocking artifects) . Hence , i increased the bit rate in the par file. It gave me the same quality as before ( not even a .01 increase in psnr and mse).

I had done a similar test on H.264 and the video quality improved a lot with increase in bit rate...

bit rate by definition isthe amount of Bits allowed to be used for compressing audio or video every second ryt ?Please correct me if I am missing something about this..

If i consider W*h*fps ( 176*144*30 = 760320 in my case), den will this no be my ideal bit rate ?

Regards,

Suchethan

Hi,

The UMC simple_player.exe performs decoding and rendering features, you may choose to render to a yuv file. However it doesn't perform encoding, you may use the "umc_video_enc_con" sample for this purpose.

There is no absolute high/low birate value, consider the resolution of your media (widthXheight) and the frame rate (Fps). A high bit rate at a certain reolution h*w and frame rate Fps, still can be measured as a low bit rate at a higher h*w and Fps.

Also, you must consider the utilized codec standard, for example MPEG has profile calssification, each profile has limitations for the bit rate @ (w*h*Fbs).

Regards,
Tamer

[Tamer_Assad]

Suchethan,

It is true, media bit rate is its number of bits per second.

Well, UMC in general works with YUV 4:2:0 PLANAR color format, so in your case, your YUV bit-rate is calculated as:

w * h * (Y + UV) * frame rate (fps)
176 * 144 * 1.5 * 30 = 1140480 (this is your YUV bitrate)


This means, if your YUV file is exactly 2 seconds long, its size MUST be 285120 bytes (1140480 * 2 = 2280960 bits).


Now, Your desired bit-rates passed to encoder are:
a) 204800
b)1228800

rate a is fine, a simple compression would give you that ( compress 1140480 to 204800)
rate b is larger than your original YUV bitrate!!

Are you trying to up-sample your media? If so, you need to process in a different approach.

Does this make sense? Please let me know.

Regards,
Tamer

[suchethanswaroop]

Quoting - Tamer Assad

Hi,

This is awesome relevation... I didnt know that I was trying to upsample it. Thanks a lot :).

I tried 2 bit rates

a. 25 KB/sec

b. 75 KB/sec or 6,14,400 bits/sec.

This means that for a 2 sec video using a. , we get a file of size 4,09,600 bits. ( original size is 2280960 bits)

using b. , we get a file size of 12,28,800 bits.

This means that the video quality of B. must be better than A. ryt ? as we are using more number of bits to encode. But this is not happening. I got exactly the same video quality using both A and B and their file sizes also were same. ( The output file formed were of the same size and quality, I made sure that I was not using the same file twice to measure quality) .

Is this because the code is unable to distinguish the change in bit rate ?

May I know why did u take the value " y + uv " = 1.5 ?

Thanks and Regards,

Suchethan

Suchethan,

It is true, media bit rate is its number of bits per second.

Well, UMC in general works with YUV 4:2:0 PLANAR color format, so in your case, your YUV bit-rate is calculated as:

w * h * (Y + UV) * frame rate (fps)
176 * 144 * 1.5 * 30 = 1140480 (this is your YUV bitrate)


This means, if your YUV file is exactly 2 seconds long, its size MUST be 285120 bytes (1140480 * 2 = 2280960 bits).


Now, Your desired bit-rates passed to encoder are:
a) 204800
b)1228800

rate a is fine, a simple compression would give you that ( compress 1140480 to 204800)
rate b is larger than your original YUV bitrate!!

Are you trying to up-sample your media? If so, you need to process in a different approach.

Does this make sense? Please let me know.

Regards,
Tamer

[Tamer_Assad]

Suchethan,

I'll test the vc1 encoding to answer your first question, will get back to you soon.

regarding your second question "May I know why did u take the value " y + uv " = 1.5 ?"

1.5 because of the YUV format used by the "umc_video_enc_con", it is YV12 and iYUV(I420) planar format.


Here is a quick overview about it:

every (4) pixels withing an iYUV image has: (see YUV 4:2:0 pixle mapping view)
4 byte for the 'Y' (luma) component
2 byte for the 'U' and 'V' (chroma) components

___________
Y | Y| Y | Y
U |- | V | -
----------------
figure 1.(4 pixels image) YUV 4:2:0 ... pixle mapping view


this means 6 bytes for every 4 pixels ... 6/4 = 1.5 ;)

further more, iYUV is a planar format, this means the image data is formated on 3 plans, Y->U->V (exact sequence). (see YUV 4:2:0 byte mapping view)

Y plan size = w*h (exact number of pixels)
U plan size = (w/4)*h
V plan size = (w/4)*h

-----------------
YYYYYYYYUUVV
-----------------
figure 2.(8 pixels image) YUV 4:2:0 planar... data mapping view

one final point: YV12 is just the same as iYUV, except for the 'U' and 'V' plans they are reversed = Y->V->U (exact sequence)

regards,
Tamer

[suchethanswaroop]

Quoting - Tamer Assad

Smart thinking abt the 1.5 , I must say :).

Awaiting your reply,

Suchethan

Suchethan,

I'll test the vc1 encoding to answer your first question, will get back to you soon.

regarding your second question "May I know why did u take the value " y + uv " = 1.5 ?"

1.5 because of the YUV format used by the "umc_video_enc_con", it is YV12 and iYUV(I420) planar format.


Here is a quick overview about it:

every (4) pixels withing an iYVU image has: (see YVU 4:2:0 pixle mapping view)
4 byte for the 'Y' (luma) component
2 byte for the 'U' and 'V' (chroma) components

___________
Y | Y| Y | Y
U |- | V | -
----------------
figure 1.(4 pixels image) YUV 4:2:0 ... pixle mapping view


this means 6 bytes for every 4 pixels ... 6/4 = 1.5 ;)

further more, iYUV is a planar format, this means the image data is formated on 3 plans, Y->U->V (exact sequence). (see YVU 4:2:0 byte mapping view)

Y plan size = w*h (exact number of pixels)
U plan size = (w/4)*h
V plan size = (w/4)*h

-----------------
YYYYYYYYUUVV
-----------------
figure 2.(8 pixels image) YUV 4:2:0 planar... data mapping view

one final point: YV12 is just the same as iYVU, except for the 'U' and 'V' plans they are reversed = Y->V->U (exact sequence)

regards,
Tamer

[Tamer_Assad]

Suchethan,

I have tested the VC-1 encoding with UMC, and there seems to be number of issues:


1- according to the Microsoft article (http://www.microsoft.com/windows/windowsmedia/howto/articles/vc1techoverview.aspx)

VC1 simple profile (low level) max bit rate is 96 Kbps, with resolution 176 144 @ 15 Hz

Apparently you are limited by the standard boundaries.




2- for Intel's experts: I have tested VC1 and H.264 encoded with "umc_video_enc_con", played back with "simple_player", and got the following results:

a) iYUV streams VC1 encoded, plays back at (2) fps ONLY, without a regard to the (-f ) value passed to encoder.(tested on 176X144)

b) iYUV streams h264 encoded, plays back at (15) fps ONLY, without a regard to the (-f ) value passed to encoder.(tested on 176X144 & 160X120)


regards,
Tamer

[Tamer_Assad]

Update:

for Intel's experts:

1- VC1 & h264 results are the same at (320X240) "VC-1 plays (2) fps, h264 plays (15)fps"



2- MP4 encoder response to the passed frame rate (-f) is just reasonable. (tested on 320X240 @15 & 30 fps)



Here I must repeat a question I posted few days a go (not answered yet), which part of MPEG-4 is used for IPP MPEG-4 coding? (http://software.intel.com/en-us/forums/showthread.php?t=71002)





regards,

Tamer

[suchethanswaroop]

Quoting - Tamer Assad

Hi Tamer,

I tried bit rates 9000 bits/sec, 50000, 95000, 96000 and all of them gave me exactly the same video quality. ( I tested for PSNR, MSE). I feel that the bit rate is not being accepted by the code at all. This parameter is being unused. What do you think Tamer ?

Regards,

Suchethan

Suchethan,

I have tested the VC-1 encoding with UMC, and there seems to be number of issues:


1- according to the Microsoft article (http://www.microsoft.com/windows/windowsmedia/howto/articles/vc1techoverview.aspx)

VC1 simple profile (low level) max bit rate is 96 Kbps, with resolution 176 144 @ 15 Hz

Apparently you are limited by the standard boundaries.




2- for Intel's experts: I have tested VC1 and H.264 encoded with "umc_video_enc_con", played back with "simple_player", and got the following results:

a) iYUV streams VC1 encoded, plays back at (2) fps ONLY, without a regard to the (-f ) value passed to encoder.(tested on 176X144)

b) iYUV streams h264 encoded, plays back at (15) fps ONLY, without a regard to the (-f ) value passed to encoder.(tested on 176X144 & 160X120)


regards,
Tamer

[suchethanswaroop]

Quoting - Tamer Assad

For Intel IPP experts :

I tried bit rates 9000 bits/sec, 50000, 95000, 96000 and all of them gave me exactly the same video quality. ( I tested for PSNR, MSE). I feel that the bit rate is not being accepted by the code at all. This parameter is being unused. Please look into it.

Regards,

Suchethan

Update:

for Intel's experts:

1- VC1 & h264 results are the same at (320X240) "VC-1 plays (2) fps, h264 plays (15)fps"



2- MP4 encoder response to the passed frame rate (-f) is just reasonable. (tested on 320X240 @15 & 30 fps)



Here I must repeat a question I posted few days a go (not answered yet), which part of MPEG-4 is used for IPP MPEG-4 coding? (http://software.intel.com/en-us/forums/showthread.php?t=71002)





regards,

Tamer