On 03/29/2015 08:16 PM, Harald Alvestrand wrote: > I know I'm being contrarian.... > > what's the model you are trying to construct, that we perform > comparisions on? > > Is it one where you generate a PSNR/rate graph for each codec, you need > one parameter to vary to make a plot, and you want to have a parameter > that has roughly the same influence on all codecs?
Yes, that's the model I was trying to construct. Don't worry about being contrarian, I don't have any strong opinions about this. > In the compare-codecs tool, see the codecs "vp8-mpeg" and "vp8-mpeg-1d" > for examples - one uses three constant quantizers, the other one wraps > the three into one parameter and a formula. Thanks - I looked in compare-codecs before posting, but didn't realize what those were for until now. > What's the value of this comparision, given that there's no uniformity > among the codecs on what the "cq-level" / "crf" means? > > It might work well if we only use it to generate a spread of encoding > results that can be plotted on a bitrate/quality graph, but will not > work at all if we start saying "for x from 15 to 35, do this" - since > there's no uniformity in the range or scaling form for the "quality" > parameter. Right, I was planning to crop the graphs to a certain bitrate range afterwards. This would be less important if the rate control was always precise in hitting the specified file size, which I imagine it is for 2 pass. Am I correct in assuming that the vp9 cq-level command will give identical quality to target-bitrate in 2 pass mode? > This is the default mode (ie the one I've been spending the most time > with) on compare-codecs. I'd argue that we should be setting some kind > of constraint on what we're doing (such as "encoding process uses no > more than X MB of RAM), but otherwise leave each codec to optimize > within those constraints - for my tests, I've not put any controls on > buffering strategies so far. Right, I looked at compare-codecs, but you also allow 2 pass. This is essentially having an unlimited buffer, and as far as I am aware, is equivalent to "constant quality". I guess what I was going for in this section was for realtime streaming where you have to hit a bitrate target in a very short window with little or no lookahead. > The argument I'd make here is that setting a rate should produce at most > (roughly) that rate - that is, we need to have some means of removing > configurations where the bitrate grows beyond reasonable. Youtube seems to use libvpx's cq mode, which is constant quality, but enforces a maximum bitrate over some window. Is that what you're thinking of? It seems the most reasonable for a DASH-like scenario. _______________________________________________ video-codec mailing list [email protected] https://www.ietf.org/mailman/listinfo/video-codec
