It's interesting that you mention a DASH environment at the end - shouldn't this use case form the basis of a test scenario?
On Mon, Mar 30, 2015 at 6:16 AM, Harald Alvestrand <[email protected]> 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? > > Den 26. mars 2015 00:19, skrev Thomas Daede: > > I am updating the scripts that AreWeCompressedYet uses. I would like to > > select what rate control options are used in the comparison. This is for > > purposes of absolute comparison between different codecs, and to > > indicate when a particular performance point is reached. This is not for > > adding tools to an existing codec. There are a couple of different rate > > control modes that we can use to compare: > > > > Constant Quantizer: > > This is not as simple as it might sound. Should referenced frames still > > be allowed a boost in this mode? Should adaptive quantization be > > allowed? Can quantization matrices be switched? I tried to come up with > > a sane way to compare different codecs with a constant quantizer and was > > not successful. > > While I believe that constant quantizer is useless, I don't see a > problem here. If you need a single set of points, ask that there be a > rule for deriving all the q values from other q values, and model each > rule as a different codec; keep the one that performs best. > > 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. > > > Constant Quality: > > Here the codecs are set to use all features available within temporal > > constraints. For stored video, this means full lookahead (or two pass, > > if that's what the codec uses). For realtime, this means no lookahead, > > but otherwise all quality-oriented rate control is allowed. Example rate > > control parameters: > > > > VP9 parameters: > > vpxenc --codec=vp9 --cq-level=$x --end-usage=q > > > > x264 parameters: > > x264 --crf=$x > > > > x265 parameters: > > x265 --crf=$x > > 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. > > > > > Constant Bitrate: > > This is the hardest category to compare, as it means that all of the CBR > > implementations need to be set to have the same buffer constraints. It > > is an important use case, so I think we will need to figure out a way to > > test it. I'd be okay with adding this one later, though. > > 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. > > 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. > > Most codecs (especially in 1-pass) have problems hitting their bitrate > targets on the short test clips; production usage usually assumes that > bitrate can be averaged over longer periods. (Note: I'm not sure this is > actually a reasonable assumption for a DASH environment.) > > > > > _______________________________________________ > > video-codec mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/video-codec > > > > _______________________________________________ > video-codec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/video-codec > -- Mohammed Raad, PhD. Partner RAADTECH CONSULTING P.O. Box 113 Warrawong NSW 2502 Australia Phone: +61 414451478 Email: [email protected]
_______________________________________________ video-codec mailing list [email protected] https://www.ietf.org/mailman/listinfo/video-codec
