GNOME Bugzilla – Bug 793913
avdec_h264: Fails to pick up not-negotiated from downstream with 4:4:4 video
Last modified: 2018-04-02 19:16:58 UTC
The attached MP4 file containing h264 video in Y444 format produces no frames when decoded in GStreamer: $ gst-launch-1.0 -v filesrc location=counter-yuv444p.mp4 ! qtdemux ! avdec_h264 ! identity silent=false ! xvimagesink Setting pipeline to PAUSED ... Pipeline is PREROLLING ... /GstPipeline:pipeline0/GstIdentity:identity0: last-message = event ******* (identity0:sink) E (type: stream-start (10254), GstEventStreamStart, stream-id=(string)a57a06654da080f44f249783661184253c1d794fdf13f4985456272685625a94/001, flags=(GstStreamFlags)GST_STREAM_FLAG_NONE, group-id=(uint)1;) 0x28b4900 Redistribute latency... /GstPipeline:pipeline0/avdec_h264:avdec_h264-0.GstPad:sink: caps = video/x-h264, stream-format=(string)avc, alignment=(string)au, level=(string)1.3, profile=(string)high-4:4:4, codec_data=(buffer)01f4000dffe1001d67f4000d919b28283f602d4180415000000300100000030068f142996001000668ebec448440, width=(int)320, height=(int)240, framerate=(fraction)3/1, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive, colorimetry=(string)bt601 /GstPipeline:pipeline0/avdec_h264:avdec_h264-0.GstPad:src: caps = video/x-raw, format=(string)Y444, width=(int)320, height=(int)240, interlace-mode=(string)progressive, 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)1/1, chroma-site=(string)mpeg2, colorimetry=(string)bt601, framerate=(fraction)3/1 Redistribute latency... /GstPipeline:pipeline0/GstIdentity:identity0: last-message = event ******* (identity0:sink) E (type: eos (28174), ) 0x7f595000a890 Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock Got EOS from element "pipeline0". Execution ended after 0:00:00.000255125 Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... Freeing pipeline ... The file was generated with GStreamer x264 element with default options. $ gst-launch-1.0 multifilesrc location="img/frame_%02d.png" index=1 caps="image/png,framerate=\(fraction\)3/1" ! pngdec ! videoconvert ! videorate ! x264enc ! qtmux ! filesink location=counter-yuv444p.mp4 The file plays flawlessly in both ffplay and mpv.
Created attachment 369099 [details] Test vector (Y444 video)
This works fine for me with gst-play-1.0. It doesn't work with random pipelines of course. You may need a videoconvert before xvimagesink.
(In reply to Tim-Philipp Müller from comment #2) > This works fine for me with gst-play-1.0. > > It doesn't work with random pipelines of course. You may need a videoconvert > before xvimagesink. Indeed it works fine when using `gst-play-1.0 --videosink xvimagesink` or adding a videoconvert before xvimagesink, so it may not be a libav problem at the end. But this bears some questions: 1) If xvimagesink can't handle Y444, why a caps mismatch is not reported? 2) Why are there no frames flowing downstream in the reported case? 3) If xvimagesink does not advertise the actual formats it supports in its caps (as suggested by the problem in question 1), how does videoconvert know what format it should convert to? Furthermore, if xvimagesink does not report any format restriction in its caps, why does videoconvert convert anything at all?
> 1) If xvimagesink can't handle Y444, why a caps mismatch is not reported? That is the question. GST_DEBUG=*:6 gst-launch-1.0 filesrc location= /home/tpm/samples/misc/793913-h264-444.mp4 ! qtdemux ! avdec_h264 ! identity silent=false ! xvimagesink -v 2>&1 | grep flow So there is a not-negotiated in the end. I wonder if we never get an error because by the time we get not-negotiated in the decoder upstream has already sent us EOS, so we can't pass it back the not-negotiated flow return. I would expect the decoder to output a frame on the first input frame, and at that point we should get a flow return already. Perhaps we're missing some flow return handling somewhere in the videodecoder base class or avdec. Should also check allocation query results. Needs more investigation.
With the latest git master, this seems to give not-negotiated as expected. Please re-open if you can still reproduce.