Hi, On Sun, Aug 28, 2016 at 7:24 AM, Carl Eugen Hoyos <ceho...@ag.or.at> wrote:
> Hi! > > Currently, FFmpeg reports "1920x1080" for > fate-suite/vp8/frame_size_change.webm although the first > frame is 160x90. > This is different for "--enable-libvpx --disable-decoder=vp8" > and would be different if the sample used vp9 or h264 or hevc. > I believe this will be different once the native vp8 decoder > supports transparency. > So I think attached patch is not unreasonable. > Strong objections? > > The sample from #5803 is broken and should not be used in the > reasoning. > > Please comment, Carl Eugen This is (IMO) mostly a terminology issue, no? From what I recall (you didn't mention), the issue in the size-change sample is that the demuxer reads size (AVCodecContext->width/height) from container (which is 1920x1080), and if decoders sets (AVCodecContext->)pix_fmt, this satisfies avformat_find_stream_info to not decode a frame before returning. With your change, AVCodecContext->pix_fmt is missing and thus the size (along with pix_fmt) is read from the first frame (160x90). This size is then used by ffmpeg.c to set (default) output size. Which of these two situations is better? I don't know. It's a terminology issue. I don't know if there is a correct answer. Answer me this question (without caring for what libvpx or h264 or vp8 does right now): if a container says size=AxB for a C-frame sample with first frame size=DxE and unknown size for any subsequent frame, and A-E are all integers > 0 (and C > 1, and A!=D||B!=E), what should the (default) output size be? Why? (The patch itself is probably fine.) Ronald _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
