I'm looking for a way to let mencoder (I use xvid) to automatically select the 2-pass average video bitrate based on the contents. I'm pretty sure that most (if not the all) of the logic to do it is already there, but I can't find the UI to trigger this behaviour. A) For example: suppose I have 100 videos; now a) append them all together; b) do 2-pass encoding of them all with, e.g., 1200kb/sec bitrate; c) split the result into 100 video files. This way, mencoder will automatically assign some "appropriate" average bitrate to each video. B) Now suppose that I have only 1 video, but I have all 100 logs of pass=1 for all 100 videos. Theoretically, this is all which is needed to do an equivalent of a/b/c for this particular video. How to convince mencoder to use these extra log files? C) Now suppose that I have only 1 video, and only 1 log of pass=1 for this video. It is more or less obvious that all I need from the remaining 99 logs is very short "summaries". How to create the summaries, and how to "feed" them to mencoder? D) And now the last logical step: If of these 99 remaining videos 40% is "action-like", 40% is "arthouse-like", and 20% is animation, then law of big numbers starts to be applicable. Essentially, I won't need to have summaries of the particular videos; I could feed in 40 copies of "average action-like summary", 40 copies of "average arthouse-like summary", and 20 copies of "average animation summary". So if I keep these summaries in ~/.mplayer in action.sum arthouse.sum animation.sum, then I could ask mencoder to do bitrate_from=1200,40*action+40*arthouse+20*animation and it could choose the appropriate bitrate. Is it possible to do now (possibly, with some pre-processing)? Any plans to have this? Thanks, Ilya
On Sat, 13 Oct 2007 04:12:45 +0000 (UTC) Ilya Zakharevich <nospam-abuse@ilyaz.org> wrote:
D) And now the last logical step: If of these 99 remaining videos 40% is "action-like", 40% is "arthouse-like", and 20% is animation, then law of big numbers starts to be applicable. Essentially, I won't need to have summaries of the particular videos; I could feed in 40 copies of "average action-like summary", 40 copies of "average arthouse-like summary", and 20 copies of "average animation summary".
This is certainly not workable. There is no average "action" movie. In fact, trying to classify the visual complexity of movies by loosely defined genres is a good sign you don't understand what you're doing. There will be movies that are ridiculously easy to compression, and there will be some that are incredibly difficult to compress. A huge number of factors will determine this, and genre is really the most minor one of them, and won't help you at all. The brand of film, type of camera, etc., will be much greater factors.
RC wrote:
On Sat, 13 Oct 2007 04:12:45 +0000 (UTC) Ilya Zakharevich <nospam-abuse@ilyaz.org> wrote:
D) And now the last logical step: If of these 99 remaining videos 40% is "action-like", 40% is "arthouse-like", and 20% is animation, then law of big numbers starts to be applicable. Essentially, I won't need to have summaries of the particular videos; I could feed in 40 copies of "average action-like summary", 40 copies of "average arthouse-like summary", and 20 copies of "average animation summary".
This is certainly not workable. There is no average "action" movie. In fact, trying to classify the visual complexity of movies by loosely defined genres is a good sign you don't understand what you're doing.
Still, the preceding ideas were interesting. Perhaps a simpler more workable approach for choosing an average bitrate in advance to give each project similar quality would be to attempt to calculate compressibility before the full encode? AutoGK does something along those lines. I think it constructs a sample from the source (around 5% of it), encodes that & uses the result to guess at compressibility (which it uses to choose resolution to give acceptable quality at a specified bitrate, but one could use the info to choose a bitrate). -- Michael Rozdoba
[A complimentary Cc of this posting was NOT [per weedlist] sent to RC <mencoder-users@mplayerhq.hu>], who wrote in article <20071012225616.223c58e1.cooleyr@gmail.com>:
On Sat, 13 Oct 2007 04:12:45 +0000 (UTC) Ilya Zakharevich <nospam-abuse@ilyaz.org> wrote:
D) And now the last logical step: If of these 99 remaining videos 40% is "action-like", 40% is "arthouse-like", and 20% is animation, then law of big numbers starts to be applicable. Essentially, I won't need to have summaries of the particular videos; I could feed in 40 copies of "average action-like summary", 40 copies of "average arthouse-like summary", and 20 copies of "average animation summary".
This is certainly not workable. There is no average "action" movie.
For the purposes at hand, obviously there is. Just catenate 1000 randomly chosen action movies together. ;-)
In fact, trying to classify the visual complexity of movies by loosely defined genres is a good sign you don't understand what you're doing.
Do not feel any need to apologise.
There will be movies that are ridiculously easy to compression, and there will be some that are incredibly difficult to compress.
Irrelevant. These will be averaged together...
A huge number of factors will determine this, and genre is really the most minor one of them, and won't help you at all. The brand of film, type of camera, etc., will be much greater factors.
A reasonally working 35mm photo camera is approximately equivalent to 6..8megapixel digital camera. After removing "dead pixels", the image is good enough to saturate capabilities of about 4MP "presentation image". It is natural to expect that a reasonally working 35mm movie camera would capture enough info to present in 2megapixel frames (probably more, taking into account temporal "noise cancellation") - taking into account the (ridiculously small) frame size. If so, it would largely exceed the capacities of DVD-like media. So, as far as it is 35mm film and a decent cinematographer, I do not think the camera would matter a tiny bit... Thanks, Ilya
On Tue, 16 Oct 2007 07:19:41 +0000 (UTC) Ilya Zakharevich <nospam-abuse@ilyaz.org> wrote:
This is certainly not workable. There is no average "action" movie.
For the purposes at hand, obviously there is. Just catenate 1000 randomly chosen action movies together. ;-)
Certainly. You'll find an average bitrate, and it will look perfect for some movies, and look terrible for others. Whether a certain bitrate will looks fine (average) across 1000 movies depends entirely on the individual movies. One set of 1000 action movies will require a much, much higher average bitrate than another set of 1000.
It is natural to expect that a reasonally working 35mm movie camera would capture enough info to present in 2megapixel frames
This has nothing to do with pixel count. Encoding difficulty is about noise.
I do not think the camera would matter a tiny bit...
As I said, you do not understand video encoding.
[A complimentary Cc of this posting was NOT [per weedlist] sent to RC <mencoder-users@mplayerhq.hu>], who wrote in article <20071016005014.706662b4.cooleyr@gmail.com>:
This is certainly not workable. There is no average "action" movie.
For the purposes at hand, obviously there is. Just catenate 1000 randomly chosen action movies together. ;-)
Certainly. You'll find an average bitrate, and it will look perfect for some movies, and look terrible for others.
Of course. And this is absolutely irrelevant.
Whether a certain bitrate will looks fine (average) across 1000 movies depends entirely on the individual movies.
This does not parse. The average will not depend much on the choice of a (random) collection of 1000 movies. Individual movies in this thousand may be very different - and the algorithm I described will take care of this.
One set of 1000 action movies will require a much, much higher average bitrate than another set of 1000.
Not if they are "random" - as any particular collection is.
It is natural to expect that a reasonally working 35mm movie camera would capture enough info to present in 2megapixel frames
This has nothing to do with pixel count. Encoding difficulty is about noise.
Again, noise depends on the choice of film and of the scene, not on the camera... Thanks, Ilya
Ilya Zakharevich wrote:
[A complimentary Cc of this posting was NOT [per weedlist] sent to RC <mencoder-users@mplayerhq.hu>], who wrote in article <20071016005014.706662b4.cooleyr@gmail.com>:
This is certainly not workable. There is no average "action" movie.
For the purposes at hand, obviously there is. Just catenate 1000 randomly chosen action movies together. ;-)
Certainly. You'll find an average bitrate, and it will look perfect for some movies, and look terrible for others.
Of course. And this is absolutely irrelevant.
Whether a certain bitrate will looks fine (average) across 1000 movies depends entirely on the individual movies.
This does not parse. The average will not depend much on the choice of a (random) collection of 1000 movies. Individual movies in this thousand may be very different - and the algorithm I described will take care of this.
One set of 1000 action movies will require a much, much higher average bitrate than another set of 1000.
Not if they are "random" - as any particular collection is.
It is natural to expect that a reasonally working 35mm movie camera would capture enough info to present in 2megapixel frames
This has nothing to do with pixel count. Encoding difficulty is about noise.
Again, noise depends on the choice of film and of the scene, not on the camera.. Oy. At the risk of wading into this mess, RC is right. Compressability has nothing whatever to do genre, it has to do with the amount of redundant information from frame to frame. This has more to do with - focal depth of the lens used, how steady the camera platform is, how accurate the film gate in the camera is, how much grain is in the film stock, how the scene was lit, etc. This will effect how "hard" the edges in the image are (hard edges take more bits to compress than soft edges), how much random movement there is from frame to frame with stationary objects (more motion vectors from frame to frame requires more bits), and how much noise there is in the frame (fine detail, even if random noise requires more bits).
A better approach than trying to find some arbitrary average value across a number of unrelated movies which all have different compression needs is to "sample" each movie and compress then with a constant quality factor. Encode 5% of a movie by compressing 10 scenes at regular intervals throughout the movie with a constant quality factor, and then use the size of the resulting file x 20 as an estimate of how big that movie will likely be at that quality factor, and then derive your bitrate based on that. Your proposed method is literally a shot in the dark because the choice movies that you choose to average would affect the bitrate value you obtain. You'd get faster results by using a simple "bits per pixel" calculation instead. .25 bits per pixel is a good "average" value for most movies from high quality sources - (width * height * framerate * .25)/1000 will give you a bitrate you can work with. It certainly will be as valid a number you get from any averaging operation, which is to say not very. One size really doesn't fit all. For example, consider two movies from the exact same genre - "Doom" and "28 Days Later". A bitrate derived from that simple calculation above would be way too high for "Doom" because that movie was done on quality film stock, using locked down cameras (because of the special effects work) and mostly takes place in dark environments (large areas of the image are simply black for many scenes). That same bitrate would be way too low for "28 Weeks Later" because high speed film was used in dark scenes (very high film grain) , much of the action is hand-held camera work (tons of motion vectors per frame), and most of the movie is fairly well exposed (lots of detail, foreground and background throughout). I can't see how your average value would fare any better. An average of what each movie "needs" for bitrate would give you the same end result.
[A complimentary Cc of this posting was NOT [per weedlist] sent to James Hastings-Trew <mencoder-users@mplayerhq.hu>], who wrote in article <4714C1BE.8050901@shaw.ca>:
A better approach than trying to find some arbitrary average value across a number of unrelated movies which all have different compression needs is to "sample" each movie and compress then with a constant quality factor. ^^^^^^^^^^^^^^
What's this? Quantizer?
Encode 5% of a movie by compressing 10 scenes at regular intervals throughout the movie with a constant quality factor, and then use the size of the resulting file x 20 as an estimate of how big that movie will likely be at that quality factor, and then derive your bitrate based on that.
Why not do something much more direct? Like a two-pass option - but not with "target bitrate", but with "target average quantizer" (whatever meaning is appropriate)? Or maybe it is possible now? BTW, a much simpler change: could not MEncoder emit such an "achieved average quantizer" after a two-pass run with current semantic (of "target bitrate")? At least, it would help with chosing bitrate when downscaling a lot (such as to a cellphone format).
For example, consider two movies from the exact same genre - "Doom" and "28 Days Later". A bitrate derived from that simple calculation above would be way too high for "Doom" because that movie was done on quality film stock, using locked down cameras (because of the special effects work) and mostly takes place in dark environments (large areas of the image are simply black for many scenes). That same bitrate would be way too low for "28 Weeks Later" because high speed film was used in dark scenes (very high film grain) , much of the action is hand-held camera work (tons of motion vectors per frame), and most of the movie is fairly well exposed (lots of detail, foreground and background throughout). I can't see how your average value would fare any better. An average of what each movie "needs" for bitrate would give you the same end result.
All true, but what is your point? Do you think that using bitrate=800000 is going to be better than the "averaging approach"? One SHOULD have some starting point. Currently MEncoder is silent about which levels are good for what... Thanks, Ilya
Ilya Zakharevich wrote:
A better approach than trying to find some arbitrary average value across a number of unrelated movies which all have different compression needs is to "sample" each movie and compress then with a constant quality factor.
^^^^^^^^^^^^^^
What's this? Quantizer?
Did this just drop out of a way-back machine? This is a fragment of a pretty old discussion. :) If I recall the discussion at the time, someone was proposing some kind of "rule of thumb" to guess at a 1 pass bitrate for a given movie based on it's genre. I gave two examples of genre movies that would invalidate such an approach. Then I suggested a different approach - sampling a portion of the movie and guessing at a good target bitrate based on that.
Why not do something much more direct? Like a two-pass option - but not with "target bitrate", but with "target average quantizer" (whatever meaning is appropriate)? Or maybe it is possible now?
I'm not sure what the point of that would be - you are worrying about bitrate because you care about file size or the bandwidth of the video stream - for whatever technical reasons you need to cram the movie into a given space, or at a given rate. Bitrate gives you that control, and quality is largely irrelevant. Two passes gets you closer to the target file size with the given amout of bits, with those bits spent in the best places the algorithm can work out. You use a constant quality factor if you care about visual quality, and size and bandwidth are not issues.
For example, consider two movies from the exact same genre - "Doom" and "28 Days Later". A bitrate derived from that simple calculation above would be way too high for "Doom" because that movie was done on quality film stock, using locked down cameras (because of the special effects work) and mostly takes place in dark environments (large areas of the image are simply black for many scenes). That same bitrate would be way too low for "28 Weeks Later" because high speed film was used in dark scenes (very high film grain) , much of the action is hand-held camera work (tons of motion vectors per frame), and most of the movie is fairly well exposed (lots of detail, foreground and background throughout). I can't see how your average value would fare any better. An average of what each movie "needs" for bitrate would give you the same end result.
All true, but what is your point? Do you think that using bitrate=800000 is going to be better than the "averaging approach"?
Mmm.. no, I suggested a sub-sample approach, which has worked out very well for me, in practice. It takes about 2 minutes to take several sub-samples of the movie at regular intervals and derive a target bitrate based on the results, followed by a one-pass encode that gives very good results, fairly close to the target file size, in a reasonable amount of time. A second pass would be nice, but we all don't have 8-core Xeon workstations. ;)
----Original Message----- From: James Hastings-Trew <jimht@shaw.ca>
Mmm.. no, I suggested a sub-sample approach, which has worked out very well for me, in practice. It takes about 2 minutes to take several sub-samples of the movie at regular intervals and derive a target bitrate based on the results, followed by a one-pass encode that gives very good results, fairly close to the target file size, in a reasonable amount of time.
The issue I have with that is the time it takes to look at each movie and try to figure out what the best bitrate is and my lack of understanding of how to achive that. I jut re-encode everything to pass xvid at 1536 bitrate. Yes, the file sizes are bigger, but so are the drives now. I've got a 250gig in my laptop, and at an average size of 1-1.5gb, that's till around 150 full movies if I want that many.
A second pass would be nice, but we all don't have 8-core Xeon workstations. ;)
Hmmm, I've always done 2 passes, even when I was jut using an old dual xeon 500Mhz system. I don't do x264 mainly because I've already done so many in xvid and because it takes 2-3 times a long as xvid. I do now have an E1200 overclocked to 3.2Ghz, and average about 110 first pass and 50-55 second pass. But I also don't encode the audio on pass 1 and I output it to /dev/null since I don't need to save that pass anyway.
[A complimentary Cc of this posting was NOT [per weedlist] sent to James Hastings-Trew <mencoder-users@mplayerhq.hu>], who wrote in article <4928DF92.3050701@shaw.ca>:
A better approach than trying to find some arbitrary average value across a number of unrelated movies which all have different compression needs is to "sample" each movie and compress then with a constant quality factor. ^^^^^^^^^^^^^^
What's this? Quantizer?
Did this just drop out of a way-back machine? This is a fragment of a pretty old discussion. :)
No, it is just that GMANE retention is longer than the characteristic time of myself checking the newsgroup. ;-)
If I recall the discussion at the time, someone was proposing some kind of "rule of thumb" to guess at a 1 pass bitrate for a given movie based on it's genre.
No. The target was to give a better guess for a 2-pass bitrate than using a constant.
I gave two examples of genre movies that would invalidate such an approach. Then I suggested a different approach - sampling a portion of the movie and guessing at a good target bitrate based on that.
Correct. But still, what is "quality factor" in context of mencoder?
Why not do something much more direct? Like a two-pass option - but not with "target bitrate", but with "target average quantizer" (whatever meaning is appropriate)? Or maybe it is possible now?
I'm not sure what the point of that would be - you are worrying about bitrate because you care about file size or the bandwidth of the video stream - for whatever technical reasons you need to cram the movie into a given space, or at a given rate.
But *I* do not worry about the rate at all. All I want is to get a comparable quality across a range of input videos. And I want an adaptive bitrate as well. Is it going to be the same as having a constant quantizer, or maybe mencoder can guess better than this (given a result of the 1st-pass)?
You use a constant quality factor if you care about visual quality, and size and bandwidth are not issues.
Size is not an issue AS FAR AS reducing size 30% won't preserve the same visual quality. The idea is to guess at which average bitrate the saturation starts...
All true, but what is your point? Do you think that using bitrate=800000 is going to be better than the "averaging approach"?
Mmm.. no, I suggested a sub-sample approach, which has worked out very well for me, in practice.
When I design what kind of average user intelligence to expect, I try to image how my grandmother (if she were available) would perform the task.
It takes about 2 minutes to take several sub-samples of the movie at regular intervals and derive a target bitrate based on the results, followed by a one-pass encode that gives very good results, fairly close to the target file size, in a reasonable amount of time.
I do not doubt that a video adept with a lot of spare time and a good grasp of technical matters can reach such level of expertise. Now think about unwashed masses of my grandmothers ;-). Could not an automatic scan of the log of the 1st-pass achieve something at least 30% as good as your expert analysis of the actual output images? [I have no idea WHAT is in the log; is it documented anywhere?]
A second pass would be nice, but we all don't have 8-core Xeon workstations. ;)
Why care about speed? I'm encoding on Athlon/850MHz; in a week, a batch is finished ;-). Thanks, Ilya
[A complimentary Cc of this posting was NOT [per weedlist] sent to James Hastings-Trew <mencoder-users@mplayerhq.hu>], who wrote in article <4928DF92.3050701@shaw.ca>:
Mmm.. no, I suggested a sub-sample approach, which has worked out very well for me, in practice. It takes about 2 minutes to take several sub-samples of the movie at regular intervals and derive a target bitrate based on the results, followed by a one-pass encode that gives very good results, fairly close to the target file size, in a reasonable amount of time.
Consider yet another corollary of such a wizardry: to do this, you should be able to easily recognize the encoding defects. However, for most users, such a wizardry carries a very strong NEGATIVE benefit ratio! For example, with my level of audio expertise, I can easily enjoy sound from well-below-$1000 equipment. I do not doubt that even in my age, my hearing is good enough so that I can educate myself to hear defects in my equipment. But what is the value of such an education? The only value is that I will need to spend another $9000 to upgrade my equipment to $10000 one - and I still would get "the same" enjoyment from the new equipment. So consider a user who: a) does not want/can't learn recognition of what is good/bad encoding; b) wants to encode in such a way that his guests won't hurt when they see the image (even if they are more expert-like). How should they choose the bitrate? A way to automatically choose bitrate for different sources basing on some output criteria (like lame --preset options) would be very beneficial. ================================================== All I did in the initial postings was I noticed that mencoder ALREADY has something similar: with 2-pass, it chooses different bitrate for different "segments" of a video. So do the same for different FILMS. Concatenate 50 films, and run 2-pass encoding over the result; then cut the result into individual films. Would not different films be encoded with "similar quality"? Thanks, Ilya
participants (5)
-
Ilya Zakharevich -
James Hastings-Trew -
Larry S. Stotler -
Michael Rozdoba -
RC