GNOME Bugzilla – Bug 763331
rtpjpegpay: gst_rtp_jpeg_pay_read_sof errors because of unclear caps
Last modified: 2018-09-17 12:22:26 UTC
Since the sink caps of rtpjpegpay and the src caps of jpegenc do not provide details about the subsampling used in the image/jpeg file, it is hard for the user to know what is going on. Here are some examples of the problem: ~$ gst-launch-1.0 videotestsrc ! video/x-raw, format=I420 ! jpegenc ! rtpjpegpay ! fakesink ~$ gst-launch-1.0 videotestsrc ! video/x-raw, format=YUY2 ! jpegenc ! rtpjpegpay ! fakesink ~$ gst-launch-1.0 videotestsrc ! video/x-raw, format=RGBx ! jpegenc ! rtpjpegpay ! fakesink The first two lines work just fine whereas the last one throws the following messages: gstrtpjpegpay.c(609): gst_rtp_jpeg_pay_read_sof (): /GstPipeline:pipeline0/GstRtpJPEGPay:rtpjpegpay0 WARNING: from element /GstPipeline:pipeline0/GstRtpJPEGPay:rtpjpegpay0: Invalid component slomo on the irc channel pointed to the RTP Payload Format for JPEG-compressed Video documentation which explains why the RGB/BGR don't work: https://tools.ietf.org/html/rfc2435 It might be useful to expose subsampling information in the jpegenc and rtpjpegpay so it is clearer what the problem is.
Thank you, we already had a bug to track this problem. We need to define caps for the different types of jpeg subsampling to be able to negotiate between the RTP payloader and the encoder so pass the restrictions back to the source! *** This bug has been marked as a duplicate of bug 684502 ***