Video file size

[fh1805]

I've treated myself to a Samsung LE32C650 TV set for Christmas. It has a built-in USB port that supports H.264 codec MP4 files. So I'm experimenting with PTE's "Create HD Video for PC and Mac". The playback quality is stunning. It's going to be much easier to bore my friends with my slide shows now!

However, there doesn't seem to be any obvious logic behind the final video file size. Let me use two sequences as examples:

Rubik's Cube - all images are 1920x1080, the duration is 143 seconds, the soundtrack is MP3 encoded at 256kbps (These values are taken from the PTE project file and the MP3 file's Properties tab)

Rievaulx Abbey - all images are 1920x1080, the duration is 133 seconds, the soundtrack is MP3 encoded at 128Kbps (These values also taken as above)

When both sequences are rendered using Presets of: HD (1920x1080),Medium Quality, Pan & Scan Enabled, the sizes are:

Rubik's Cube video file = 38752KB

Rievaulx Abbey video file = 75352KB

The shorter sequence, which uses a lower grade MP3 file is almost twice the size of the longer one! What's going on?

My limited understanding of video files is that a frame of 1920x1080 pixels should require the same number of bytes irrespective of its content. Am I wrong in this?

The calculation of video file size should then be: (no. of bytes per frame x frames per second x seconds duration) + size of MP3 file. Is this right? Or have I over-simplified things?

I'd welcome some words of wisdom.

regards,

Peter

[davegee]

Peter,

As you know I have been using this method (USB) for some time now and whilst I can't offer any words of wisdom I can give an example of one of the shows on my 16Gb USB Memory Key.

Time = 10m 35s

Resolution = 1920x1080

MP3 file = 9.7Mb at 128kbps

Video details:

1920x1080 / 24fps / 2 Passes Bitrate / Bitrate = 10000

Final MPEG4 size = 769Mb

Quality = SUPERB.

I have also been using my Sony TV's Media Centre for playback of MP3s and JPEGs. The slideshow function is basic compared to PTE but allows for reviewing of images for family consumption.

B+W JPEGs just JUMP out at you!

DG

[Guest Yachtsman1]

Peter

From my expeience of your two shows, Rubic has one piece of music, not sure about the other.

Regards Eric

Yachtsman1

[fh1805]

Dave,

Thanks - but I'm not sure that adding a further example helps me to understand what is going on here.

Eric,

Both sequences have an MP3 soundtrack ("Windmills of my mind" for Rubik and Allegri's "Miserere" for Rievaulx). But the actual MP3 content is irrelevant; the only point of relevance is, I believe, the fact that the MP3 files are encoded at different bitrates - as I have indicated in my initial post. This difference will have an effect on the file size - but the perceived effect is the reverse of that expected. The sequence with the larger MP3 file comes out as a smaller video file. The sequence with the shorter duration comes out as a larger video file. As our trans-Atlantic members would say: Go figure!

regards,

Peter

[fh1805]

Further to my reply above to Eric,

I would expect the impact of the soundtrack on the video file (*.mp4) to be lower compared to the impact of the image frame data. This is the exact opposite of the impact of the soundtrack on the size of the executable (*.exe) file, where it can be a very significant element of the final value.

regards,

Peter

[Ken Cox]

Peter

maybe some theory here

http://www.afterdawn.com/

or

http://www.videohelp.com/

ken

[davegee]

OK, then I'll offer you a suggestion.

Instead of using a "preset" why not use the CUSTOM setting and make sure that everything is IDENTICAL in both of the shows that you are converting?

Also, why not try creating the MP3 files at the same Bit Rate - get rid of any anomalies and then compare the two versions?

DG

[Lin Evans]

My limited understanding of video files is that a frame of 1920x1080 pixels should require the same number of bytes irrespective of its content. Am I wrong in this?

Hi Peter,

Perhaps this is where your error is in thinking about this. Once a file is expanded in memory (assuming a compressed format such as jpg) then the number of pixels does indeed determine the file size in bytes, however, the frames vary in byte size greatly depending on content where compression is considered.

For example, frames with lots of detail (such as a detailed landscape) and compressed to the same numeric value as a frame with minimal content variation (such as a solid color) will vary greatly in compressed size. So it's entirely possible that this may account for the greatly different file sizes you encounter. When you multiply even moderate differences in file size of individual frames times 29.97 for each second of display time, the differences can be dramatic. Remember, the video is also compressed so individual frame sizes (in terms of compressed bytes) greatly affects the overall file size.

Best regards,

Lin

[fh1805]

Lin,

That provides a plausible explanation. Rubik's Cube has large areas of plain grey background and a (relatively) small area occupied by the animated cube. Rievaulx has "edge to edge" detailed picture content. So the compression of each video frame, when applied to the Rubik's Cube sequence, would be able to produce smaller "files"; thus giving the perceived end-result.

Once again, I've learnt that nothing is ever as straightforward as it first might seem. Thanks for the enlightenment. And thanks to everyone else who has responded.

regards,

Peter

[xahu34]

Peter,

Congratulations to you new TV. I have a Samsung LE40B650, and I must say that I am not that happy with MP4-videos created with the PTE VideoBuilder. My problem has been described here. Would it be possible for you to run a test: Create a short MP4-video using the image attached to my former post and see if you can notice any shadow clipping, as I did.

Regards,

Xaver

[davegee]

Xaver,

Interesting test!!

I tried it on my Sony and found that whilst the Zero and 8 readings were very close there was a clear difference between all of the patches.

I also included the opposite end of the scale i.e. 100 downwards and the differences between all patches were VERY clearly seen.

I deduce from this that H.264 is adequate (for me) and that you might possibly look at the settings of your TV?

DG

[fh1805]

Dave/Xaver,

Forgive me for being incredibly stupid today, but I cannot find a route by which I can save the image file in any format except a webpage. Also, I do not understand how to create my own grey shade images to match your specifications as I do not understand what the values 0, 8, etc. signify. (I know how to create a uniformly coloured slide in Photoshop Elements but cannot find any reference to these specifc values. The only way I can set the colour value is via separate R, G and B values).

If I knew how to create my own "grey slides" to the same specification as yours, I'd happily run the test and post the results.

regards,

Peter

[davegee]

Peter,

I have e-mailed you and attached my JPEG.

I couldn't find a way of doing it via the forum.

DG

[potwnc]

Here's a lengthy article with more information than probably anyone needs: http://www.digital-digest.com/articles/x264_options_page1.html.

The explanation, as Lin said, lies in the compression "smarts" of the H.264 encoder. "The calculation of video file size should then be: (no. of bytes per frame x frames per second x seconds duration)" is only true of raw, uncompressed video, which produces file sizes so large it is effectively impractical except for very short durations. One reason why H.264 is so popular is because it is very "smart" when calculating how to encode/compress and store the information required to move from one frame to the next. Generally, the greater the actual pixel difference between the two frames the larger the data required to encode/compress that information.

[xahu34]

Peter, Dave,

What I did is creating squares in my image with RGB-values (0, 0, 0), (8, 8, 8), (16, 16, 16), etc.

If you look at http://en.wikipedia.org/wiki/Rec._601 , you will read: In each 8 bit luminance sample, the value 16 is used for black and 235 for white, to allow for overshoot and undershoot. The values 0 and 255 are used for sync encoding. The Cb and Cr samples use the value 128 to encode a zero value, as used when encoding a white, grey or black area.

Remember that videos normally do not have RGB color spaces, but chroma-luminance spaces, where the luminance part of 8-bit-videos has a restricted range, as said above. You can see that, when running a WMV-video in the Windows media player: Total black shows up as dark grey. When encoding MP4/H.264 videos using MeGUI/x.264 you can choose (via the matrix parameter in the ConvertToYV12 command of AviSynth) either to have a video according to the normal video standards (with 220 steps for luminance), or a PC version having full range (256 steps) what PTE seems to produce.

My Samsung TV seems to like standard videos (with 220 luminance steps) rather than videos having the PC range. This is the reason why I create my MP4-videos using MeGUI via the virtual AVI of PTE.

Regards,

Xaver

[Guest Yachtsman1]

Dave/Xaver,

Forgive me for being incredibly stupid today, but I cannot find a route by which I can save the image file in any format except a webpage. Also, I do not understand how to create my own grey shade images to match your specifications as I do not understand what the values 0, 8, etc. signify. (I know how to create a uniformly coloured slide in Photoshop Elements but cannot find any reference to these specifc values. The only way I can set the colour value is via separate R, G and B values).

If I knew how to create my own "grey slides" to the same specification as yours, I'd happily run the test and post the results.

regards,

Peter

Hi again Peter

Re your comments about grey slides in Elements, are you referring to the function listed under IMAGE, scroll down to MODE?

See pic

Regards Eric

[goddi]

Peter, Dave,

What I did is creating squares in my image with RGB-values (0, 0, 0), (8, 8, 8), (16, 16, 16), etc.

If you look at http://en.wikipedia.org/wiki/Rec._601 , you will read: In each 8 bit luminance sample, the value 16 is used for black and 235 for white, to allow for overshoot and undershoot. The values 0 and 255 are used for sync encoding. The Cb and Cr samples use the value 128 to encode a zero value, as used when encoding a white, grey or black area.

Remember that videos normally do not have RGB color spaces, but chroma-luminance spaces, where the luminance part of 8-bit-videos has a restricted range, as said above. You can see that, when running a WMV-video in the Windows media player: Total black shows up as dark grey. When encoding MP4/H.264 videos using MeGUI/x.264 you can choose (via the matrix parameter in the ConvertToYV12 command of AviSynth) either to have a video according to the normal video standards (with 220 steps for luminance), or a PC version having full range (256 steps) what PTE seems to produce.

My Samsung TV seems to like standard videos (with 220 luminance steps) rather than videos having the PC range. This is the reason why I create my MP4-videos using MeGUI via the virtual AVI of PTE.

Regards,

Xaver

================

Xaver,

I have the same Samsung TV as you have. I created an MP4 with your sample image you mentioned above that shows the 'shadow clipping' (using the WD Media Player). I now see what you were talking about that 0, 8 and 16 are all the same shade of black when viewed on the Samsung TV. I never noticed any detrimental effects in my MP4s when played on the Samsung, but I apparently do not have such a critical eye as you. However, I am curious what you mean by "This is the reason why I create my MP4-videos using MeGUI via the virtual AVI of PTE"? I see I can download an MeGUI file from SoundForge. But I'm not sure what I would do with it in PTE. Can you explain a bit more about using this MeGui?

Gary

PS When I play the same test MP4 I made with your sample image in Windows Media Player on the PC, all of the black squares are the same 'blackness' except for 32. (Playing it on a Samsung 23" LED monitor).

[xahu34]

Gary,

I don't know if it it is a good decision to follow my way of creating MP4-videos using MeGUI. First, you must install MeGUI, and AviSynth, as well. MeGUI uses AviSynth for converting video frames from RGB to YV12. You can open a PTE project and create a virtual AVI (an AVI with the Video-Codec option "PictureToExe Video Codec"). This video has the quality of an uncompressed video without filling heaps of disk space, but it only lives while the PTE program is running. You can use MeGUI in order to transcode this AVI to an MP4/H.264 video. MeGUI is a user interface for the H.264 encoder x.264, an open source encoder which is also used by PTE. On the way to go it is helpful to have some rudimentary knowledge of the AviSynth script language, and of course you must learn how to configure x.264. Although I do not consider myself as totally unskilled it took me hours to work through this task. This method obviously provides a way around the VideoBuilder, but surely it is not to everyone's taste. On the other hand, MeGUI offers the possibility to create videos for the PC, as well as videos with restricted luminance range for media players. I have made appropriate proposals for the PTE VideoBuilder, not only in this forum. I'm still waiting for an answer from the VideoBuilder's programmer at WnSoft.

Best regards,

Xaver

[xahu34]

... PS When I play the same test MP4 I made with your sample image in Windows Media Player on the PC, all of the black squares are the same 'blackness' except for 32. (Playing it on a Samsung 23" LED monitor).

This should not happen. On a PC you should be able to distinguish the dark squares (0, 8, 16, 24, 32), if your display setting are correct.

Regards,

Xaver

[goddi]

This should not happen. On a PC you should be able to distinguish the dark squares (0, 8, 16, 24, 32), if your display setting are correct.

Regards,

Xaver

==================

Xaver,

When I play your image as a PTE exe, I can definitely see a difference on my monitor between each black square (maybe not so much between 0 and 8). When I play the same file as an MP4 with Windows Media Player, the 32 black square is the only one that I can tell is different (a less-dark black). Both are played on the same Samsung 23" LED monitor. So it is perhaps not the display causing the difference but the way Windows Media Player is showing the image.(?)

Gary

[xahu34]

==================

... So it is perhaps not the display causing the difference but the way Windows Media Player is showing the image ...

This may be true. My Windows Media Player shows a different behaviour, but I am running Windows XP, and my Media Player does not have its own codec for MP4 videos but uses ffdshow (installed with the K-Lite codec pack). Did you watch the video with VLC (VideoLAN)?

Regards,

Xaver

[goddi]

This may be true. My Windows Media Player shows a different behaviour, but I am running Windows XP, and my Media Player does not have its own codec for MP4 videos but uses ffdshow (installed with the K-Lite codec pack). Did you watch the video with VLC (VideoLAN)?

Regards,

Xaver

===================

Xaver,

I just tried it with VLC and it showed just like what PTE exe showed. All the black boxes were distinguishable...(but again, 8 and 16, not so much). I also tried it with DivX and Media Player Classic and they showed the black boxes in a similar manner as Windows Media Player...only box 32 was distinguishable (lighter black). I am using Windows7.

Gary

[fh1805]

Re your comments about grey slides in Elements, are you referring to the function listed under IMAGE, scroll down to MODE?

Eric,

No, it wasn't that. I knew how to convert to greyscale and how to create a new greyscale image. It was the significance of the numeric values 0, 8, 16, etc. Xaver explained what he'd done in the post prior to yours. Now that I understand what those values mean, I can have a go myself.

regards,

Peter

[davegee]

Gentlemen,

If you were viewing your JPEG in CS4 (on your computer monitor) and you were not able to distinguish between the various shades of Gray, what would you do?

You would calibrate your monitor and not complain to Adobe.

Each of the inputs on your TVs will (should) have independent Picture Controls.

I have different controls for Mode (Standard), Backlight, Brightness, Contrast and Colour for each of the inputs on my TV.

So, therefore I can have different settings for viewing Satelite TV via HDMI and Terrestrial TV via normal Aerial input and also for the USB input.

Getting the picture to your satisfaction on one of the inputs does not necessarily mean that all inputs will give the same satisfactory picture.

I spent some time on my TV when it was new setting up these different inputs to give a satisfactory picture on each of the different inputs and found that for viewing pictures (JPEGs) and MPEG4 video required slightly different Picture Settings to the other inputs - just as the HDMI input needed different settings to the Terrestrial input.

The test that you suggested was a good way of proving that clipping was not occuring at either end of the scale and I can see the difference between zero and 8 just as I can see the difference between pure white and the next step down WITH MY SETTINGS in place.

Another comparison which I have done is to play the same PTE show into the TV firstly as an EXE from my Laptop via HDMI and then from the USB key as an MPEG4 and I can see no difference whatsoever in the shadows or highlights. I intend to try your gray patches test at the first possible opportunity.

DG

[Ken Cox]

project this on your monitor and your tv

http://www.eye4u.com/home/

compare - adjust your colours via the graphic card - - contrast, brightness --

view another known value ie the MacBeth colour checker

compare

print a known value picture

fine tune your monitor with its control

your tv should be close with factory defaults -- view a newscaster -- he likely has a white shirt - shadows should be neutal gray -- vuew the sun page 3 girls their flash tones have always been dead on -- that is their business - to make things look perfect

dont make a big deal out of it

ken