Publishing Video and Video Size Estimate

  • 2
  • Idea
  • Updated 1 month ago
When publishing the video, it would be great if I could see what the final video size would be so that I can import the highest quality video to my LMS. I use Cornerstone and I'm allowed up to 500 MB, but my video just published as 220 so now I am rendering it again at a higher quality and hoping it is under 500. It would be nice (and time saving) to have an estimate earlier in the process.
Photo of joseph.robinson

joseph.robinson

  • 3 Posts
  • 1 Reply Like

Posted 1 month ago

  • 2
Photo of reiddg

reiddg

  • 35 Posts
  • 4 Reply Likes

Rendering is a compression technique that eliminates redundant data. How much redundant data do you have? It depends largely on the number of color changes you have frame to frame in your video. There is no way to know until you render it which is the process of determining that. It’s like measuring the distance between two points by stepping it off and when you start, you can’t see the destination. Is it up and down hill or flat? Increasing the quality is like taking smaller steps which changes the number of color transitions. This is a long way of saying that you will have to render it to determine the size. Sorry, no shortcuts. Incidentally, you generally can't compress a rendered file. It's already compressed.






Photo of Ed Covney

Ed Covney

  • 81 Posts
  • 41 Reply Likes
Why not render at the highest quality, then if you must, use an appropriate compression using "Handbrake"?
Photo of Joe Morgan

Joe Morgan

  • 5652 Posts
  • 2929 Reply Likes
You got my vote,

Premier Pro gives you the estimate file size before rendering. Its a great feature.

If it's higher than desired, you  lower the compression settings in Premier Pro. No need for a third party software to do it for you.


Regards,Joe
Photo of reiddg

reiddg

  • 35 Posts
  • 4 Reply Likes
It is certainly possible to use heuristics to estimate final file size, but it is just an estimate. If the actual rendering is over your size limit, c'est la vie. Last I checked, Premiere Pro was a third party software package, and not a cheap one. Furthermore, their estimates are based on how they render versus how CS renders. Theirs may be better or worse assuming they can accept CS files.
If I were having a render time issue, I would buy a faster computer or dedicate one to rendering.
Photo of Joe Morgan

Joe Morgan

  • 5652 Posts
  • 2929 Reply Likes
I was simply pointing out the fact that Premier Pro estimates file sizes.  It's a Premier Pro feature.

If Adobe can do it, why can't TechSmith? That's all I was trying to say.

 
Photo of reiddg

reiddg

  • 35 Posts
  • 4 Reply Likes
Sorry. Not being combative here. PPro may do an excellent job. They certainly have the raw material to work with for experimentation, but there are many, many variables and settings involved. It's a little bit like climate predictions. People make those too. :-)
Photo of Joe Morgan

Joe Morgan

  • 5652 Posts
  • 2929 Reply Likes
So reiddg,

I've always known Premiere Pros estimates for file output size were reasonably accurate. I never payed extreme close attention to see just how accurate.
Over time, I just took it for granted I could trust the numbers.

Tonight, I thought I would try and trick  the numbers. Throw a couple of cure balls, see what happens.
I mixed B&W 480p footage with 4K color footage, along with some 1080p and 720p.
Just to make predicting file sizes a real crap shoot.

This video was 12:36 in duration.

The estimated file size was           1832mb
The rendered video was                 1824mb    So, off  by only 8 mb.



Example 2.

Video is  35:42 in Duration

The estimated file size is             5188mb
The rendered video was              5187.47mb         So, off by .5 something mb.



This is a Vimeo video I rendered yesterday. I didn't re-render it. I just checked the estimated file size against the actual file size.

This video is 3:02 in Duration.

The estimated file size is         354mb
The rendered video is               348mb         So,  off by 6 mb.



I'm glad I did this test.

Now I know how accurate these estimates actually are. Deadly Accurate if you ask me.

This is no weather forecast.No shot in the dark.It just affirmed what I already believed.

Now you should believe as well.
 
Regards,Joe
Photo of Ed Covney

Ed Covney

  • 81 Posts
  • 41 Reply Likes
Joe - A compression algorithms CANNOT estimate at least in one pass.  A video of grass growing or paint drying is extremely compressable. An auto race, not so much. Handbreak is "a 2 pass" system and can get very close whether its paint drying or an auto race. Some 2 hour MP4 movies are excellent quality at 1 GB, some grainy at 2 GB. I assume you know your videos and how fast pixels change, you can likely (educated) guess an appropriate compression better than Cmtasia or Premier.
Photo of Joe Morgan

Joe Morgan

  • 5652 Posts
  • 2929 Reply Likes
Well Ed,
I'm talking about the ability of a program "Camtasia" to estimate file size before rendering.

Premier Pro can do that.

With Deadly Accuracy as I have demonstrated. 2 of those videos are are rendered as High Quality 1080p videos.  They weren't rendered for file size, and they were one pass renders.
The other was rendered for Vimeo, as per Vimeo standards.

 Handbrake has absolutely nothing to do with adding a file size estimator to Camtasia's production wizard.I understand where you're going with this.But it's not the actual topic.Not the way I see it.

joseph.robinson,s  Idea is.............my video just published as 220 so now I am rendering it again at a higher quality and hoping it is under 500. It would be nice (and time saving) to have an estimate earlier in the process.
Photo of reiddg

reiddg

  • 35 Posts
  • 4 Reply Likes
I have worked on compression algorithms, and the only way I know for an estimate to be so close to the actual results is that the actual processing does little more than the estimating methodology.
We have beaten this topic to death. I have fast hardware and short video segments. Rendering is not a problem for me.