It could be as simple as the run time of each pass/queued item multiplying by the fps of the source, adding all of the total frames to be encoded from all queued items. Once the encoding starts divide by the encoding fps to get total ETA. There could be a boxcar average in this part but not necessarily.
I know that to get it really right the resolution and all would have to be accounted for etc. but accuracy is not paramount, just an estimate anyway.
In a queued situation the ETA of the queued item isn't very relevant and it is hard to calcualte on your own when dealing with extras etc.
Just an idea for a relativley easy improvement. Feel free to dismiss it. I don't feel strongly about it other than that it is a good idea.
P.S. I agree very much with the required reading on feature requests, but would add that in open source projects the developers need to be careful to parse demanding end users that are abusing the system/developers and those who are trying to be helpful/give ideas to the developers. Although much of what the developers want to do is a specific intellectual pursuit it is also important for the developers to learn from the process about good software and GUI design, just as they learn to create code understandable by others from the collaborative nature. End users can be helpful to take a project from an esoteric exercise to a beautiful piece of software. In other words it can help the developers create better software especially when working at their real jobs where it makes or breaks a project and your career. This is not something that HB is particularly lacking, just be careful to keep an open mind.
