I think, for all video *encoding* testing, we want to assume the input and output resolution will be identical. (One possible exception I can think of is : If we ever support a resolution scalability, then lower resolution video can be additionally decoded from the same coded bitstream.)
Meanwhile, the encoder designers can do whatever they want inside encoder and possibly its paired decoder, for example encode at down sampled resolution then decode, upsample to original input resolution, and add pepper and salt noises on top of it. -yushin On Wed, Feb 25, 2015 at 7:17 AM, Harald Alvestrand <[email protected]> wrote: > Den 25. feb. 2015 15:36, skrev Timothy B. Terriberry: > > Harald Alvestrand wrote: > >> I've come to the conclusion that varying resolution should be considered > >> one tool for achieving lossy compression, and should not be a primary > >> dimension - YMMV. > > > > Can you say a little bit more about how you would go about comparing the > > results of two encoders that chose to encode a sequence (or even > > individual frames within a given sequence) at different resolutions? > > I think comparision tools that care about what the codecs do rather than > what the result is are problematic - so I'm not sure whether this is > different from all the other choices encoders can make. > > The overall process would have to return an image suitable for display - > for simplicity of testing, I would make the output resolution the same > as the input resolution. > > We've experimented with this sort of resolution change in the WebRTC > pipeline - encoding in a lower resolution saves both CPU and bandwidth. > > (Just for fun, I integrated such a rescaling into the compare-codecs > pipeline that encodes using the H.261 encoder, to allow comparing H.261 > with its very limited available resolutions to other codecs on HD-sized > clips - it "works", for some value of "work". > > psnr values of 35 dB where x264 achieves 40 dB - it seems psnr isn't > particularly sensitive to the resulting blurriness). > > > > > > _______________________________________________ > > 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 > -- Thanks, Yushin
_______________________________________________ video-codec mailing list [email protected] https://www.ietf.org/mailman/listinfo/video-codec
