zyfert wrote:
.. I beg to differ.
excuse my impudence, but - German saying: - you +compare apples with pears+ .. 🙂
• the 'share/Mediabrowser' command creates within the project.rcproject-package a h264.mov with 9-10Mbit/sec (=the Project.file-size is NOT the exported .mov size...)
• a 'share/QT/h264' command would allow a manual setting of bit-rate.. 'automatic' uses a much higher value, ~ 13Mbit/s => so, no wonder, this way creates bigger file..
• a 'share/QT/mpeg4' command creates all kind of sizes, using the _same bit-rates_ as the files mentioned above (9/13Mbit) creates - surprise! 😉 - _same file-size_.
now, judging these three files on my Mac
does show notable differences .. IF the original video had a high quality (e.g. AVCHD/1080i/>17Mbit/s, or AVCHD/720p/>10Mbit), or less compressed stills, I
do notice in my mpeg4 artifacts, esp. in 'plain' colored/non structured areas .. plus the 'contrast on borders' (still don't know the correct english term for
Kantenschärfe .. 😉 ) is for h264 higher.. more annoying: h264 looks less saturated here ..
so, as long as we don't know your settings, esp. the bit-rates in use, the file-sizes have no validity.
but it gets worse... :
you compare picture-quality _after an additional process_ of re-sizing, re-compressing and re-converting (=YT uses its own codecs/-settings, a DVD is 720x560 + mp2 .. ) - that is, not meant as a personal offense!, ... mostly useless. .. like, judging pic quality of a 12 Mpixel digital-still in a print or after upload to flickr etc..... .
summary:
• bit-rate defines quality AND size - the higher, the better and bigger
• newer codecs usually are 'better', in terms of size/quality-ratio, are more 'effective' ..
• if you found YOUR compromise of speed-of-process, file-size and quality - use it! .. don't listen to me ..
but mpeg4
are bigger or worse, compared correctly with h264 (aside colors/saturation/That nasty Gamma-problem, described on my
site ...