check my calculation to encode video please

[vhelp]

system: amd 64 x2 dual, 2g ram, xp home

on my system, sometimes videos encode 9 seconds and other times 10 seconds. both sources are 24 fps.

yesterdays video encode 1797 frames / 9 seconds / 60 to be 3hr 32m, but it took 4 1/2 hours.

now, am encoding 1436 frames. i timed how long it takes to encode 1 frame to be 10 seconds.

(1436/10)/60 should give me 2hr 39m ?

[DB83]

You are not making a great deal of sense. Are you saying that you encode at 9 frames a second or sometimes at 10 frames a second ?

If this is the case then your maths is way out. The first result is NOT 3 hr 32 mins it is 3.33 minutes.

[aedipuss]

unless you sampled more than just the opening few frames it is hard to judge. if perhaps your sample was more than 1% of the video somewhere in the middle it might be accurate. not all frames take the same amount of time unless you are encoding uncompressed. i,p,b and other types take different amounts of time to encode. high motion video will also take longer to encode than low motion.

[aedipuss]

You are not making a great deal of sense. Are you saying that you encode at 9 frames a second or sometimes at 10 frames a second ?

If this is the case then your maths is way out. The first result is NOT 3 hr 32 mins it is 3.33 minutes.

i'm guessing 9 or 10 seconds per frame. 1797x10 = 17970seconds. /60=299.5min /60=4.99hours

[aedipuss]

or if 9 seconds 1797x9=16173sec /60=269min. /60=4.49hours

[poisondeathray]

9 seconds per frame, just cancel the units

For the 1st one:

(9 sec / frame ) * 1797 frames = 16173 sec

16173 sec * (1 min / 60 sec) = 269.55 min

269.55 min * (1 hr / 60 min) = 4.4925 hr or 4h 29min 33sec





1) your assumption is that fps is constant, but it's not always the case. Speed might change up or down when encoders look ahead, or have frames cached in memory

2) measuring time to completion for a single frame only will have a large +/- margin of error



Shit aedipuss beat me

[DB83]

@pdr & aedipuss

Your math makes more sense. Of course you are substituting a * for the first /

Maybe I have lived in a cave these past years but isn't 1 frame per 9 (or 10) seconds a tad slow ?. This example does not have much running time yet an horrendous time to encode. Something still does not fit methinks.

[poisondeathray]

I think he's testing HEVC encoding . That's fast LOL. Or maybe tiny frame dimensions

[aedipuss]

i think he mentioned elsewhere it's hevc but 320x240

[DB83]

Ah. That's what you get when you read books only with pictures

[vhelp]

appoligies, i stepped out.

yes, i am encoding hevc videos. still the only one doing so, boring and hot today here in ny..cooking burgers/dogs. anyway.

I think he's testing HEVC encoding . That's fast LOL. Or maybe tiny frame dimensions

i'm encoding 720x480 dimensions, 24 fps video. i know the fps doesn't matter in this case, i just threw that in just in case someone asked. were you kidding about the speed for that ? lol. i read somewhere where people talk about 1920x1080 in realtime, unless they mean playback. has others tested the speed with system specs ? i3 ? i7 ? etc ?

1) your assumption is that fps is constant, but it's not always the case. Speed might change up or down when encoders look ahead, or have frames cached in memory

2) measuring time to completion for a single frame only will have a large +/- margin of error

also, so how do virtualdub and other encoding front-end apps calculate the estimated encoding times ? they seem to get it on the mark, everytime. maybe i can include the necessary code ?

anyway, all this because i was trying to get the calc correct so i can add to my gui so i wouldn't have to guess. i'm trying different things. i've done similar calculations before but i don't retain these things permanently. sorry for the confusion.

[poisondeathray]

The scary thing is I was only half joking. It's friggen slow

I havent really charted out speeds precisely, because this encoder won't be the one that is actually used (retail or real use encoders will have optimizations and be many times faster) . So far I've only been looking at quality aspects

I don't know how other apps estimate encoding times / completion times, but for something like x264 it's usually way off at the beginning as it starts it's look ahead threads . You can ask one of the gui developers. There are some x264 builds that have this information ETA and so forth..., so it might be right in x264's code (some of the gui's just print that info out in realtime)

[jagabo]

so how do virtualdub and other encoding front-end apps calculate the estimated encoding times ? they seem to get it on the mark, everytime. maybe i can include the necessary code ?

VirtualDub keeps a running tab of how may frames have been encoded and how long it's been since encoding started. From that it calculates how many frames per second it's achieved so far. Since it knows how many more frames remain it's simply a matter of multiplying fps by number of remaining frames. It does not get it "on the mark, everytime". In the early parts of an encoding it's often off by a large amount.

[vhelp]

thanks guys. so far, i started an encode at 5:35pm, as of now, the frame count encoding is 1220 of 1436, and it is 8:57pm

edit1: cpu is ~50% for TAppEncoder, 41.8k
edit2: just completed, 5:35pm - 9:35pm for 1436 frames, 720x480 dimensions
edit3: ratz. i ran out of hdd space, the encode got corrupted. what a waste..oh well.