GNOME Bugzilla – Bug 785211
gst-validate: considers as a failure if decoder changes width, height or framerate.
Last modified: 2018-11-03 11:08:03 UTC
Created attachment 356087 [details] mpeg2 sample Reproduce step: gst-validate-1.0 filesrc location=sony-ct1.mpeg ! mpegvideoparse ! avdec_mpeg2video ! fakesink It results in: === Got criticals. Return value set to 18 ==== Critical error Field width from setcaps caps 'video/x-raw, format=(string)I420, width=(int)352, height=(int)224, interlace-mode=(string)mixed, multiview-mode=(string)mono, multiview-flags=(GstVideoMultiviewFlagsSet)0:ffffffff:/right-view-first/left-flipped/left-flopped/right-flipped/right-flopped/half-aspect/mixed-mono, pixel-aspect-ratio=(fraction)4/3, chroma-site=(string)mpeg2, colorimetry=(string)bt601, framerate=(fraction)30/1' is different from expected value in caps 'pending-fields, width=(int)120, height=(int)120, framerate=(fraction)30/1, pixel-aspect-ratio=(fraction)4/3;' Because decoder changes resolution of src caps with real encoded size and set them to output_state and seems gst-validate considers this as a failure. I got same result with other vp9 files using vp9dec. I'm wondering if this is real failure.
that feels wrong. mpegvideoparse is setting the width/height to the *DISPLAY* width/height (and not the encoded value width/height). This was introduced by bug #704009
Are you saying you feel it's wrong that mpegvideoparse is putting display width/height into the caps? I don't think so, I think that's exactly how it should be.
We keep on hitting this, maybe we should add a "encoded-width / encoded-height" to the various encoded caps?
Created attachment 356249 [details] vp9 sample Note that this is not only about mpeg2 but vp9. I'm attaching sample to reproduce. How about lowering the level of message from critical to warning?
(In reply to Tim-Philipp Müller from comment #2) > Are you saying you feel it's wrong that mpegvideoparse is putting display > width/height into the caps? I don't think so, I think that's exactly how it > should be. In the case of mpeg, that display width/height is used for pan&scan (there is a per-picture display extension specifying the recommended location of that display window). Do we want to force showing 4:3 videos for 16:9 videos with pan/scan information ? Note the decoders will *not* crop it to 4:3. (In reply to Hyunjun Ko from comment #4) > Created attachment 356249 [details] > vp9 sample > > Note that this is not only about mpeg2 but vp9. > I'm attaching sample to reproduce. > > How about lowering the level of message from critical to warning? I would very much prefer we keep this issue critical. IIRC it was one of the reasons validate was started for (3rd party decoder implementations that would return incoherent/invalid width/height/framerate/par).
> (In reply to Hyunjun Ko from comment #4) > > Created attachment 356249 [details] > > vp9 sample > > > > Note that this is not only about mpeg2 but vp9. > > I'm attaching sample to reproduce. > > > > How about lowering the level of message from critical to warning? > > I would very much prefer we keep this issue critical. IIRC it was one of > the reasons validate was started for (3rd party decoder implementations that > would return incoherent/invalid width/height/framerate/par). Ok. Agree. It might be ridiculous to change the level if this was one of starting points of gst-validate. We have to find a way to deal with these non-failure cases if you agree that these are not failures.
(In reply to Hyunjun Ko from comment #6) > We have to find a way to deal with these non-failure cases if you agree that > these are not failures. The problem is that (at least for the first file, didn't check the 2nd one) they *are* failures. Upstream says it's (wrongly) 120x120 and the decoder outputs the proper resolution. So at least on that front validate is *not* wrong :)
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-devtools/issues/26.