Created attachment 194367 [details] [review]
JPEG RTP Payloader Change to support FaceVsion Webcams

Created attachment 194474 [details] [review]
Previous patch is incorrect...

Created attachment 194495 [details] [review]
Obsolete Prior Patch...

I suppose technically a JPEG image with no actual data would be valid, but that doesn't seem very useful.

What happens when you use jpegparse before the payloader?  (Without the patch, obviously.)

(In reply to comment #4)
> I suppose technically a JPEG image with no actual data would be valid, but that
> doesn't seem very useful.
> 
> What happens when you use jpegparse before the payloader?  (Without the patch,
> obviously.)

Hi David,

I tried placing jpegparse before the payloader without the patch and it really had no affect.  This occurs with the Logitech B990 and the FaceVsion E1 webcams.  There are SOI without EOI and then and EOI every nth SOI.  I am a MPEG2 transport/MPEG4 container guy, I don't have a lot of experience with Motion JPEG.  However, with this change I do not see the payloader throwing an error any more and halting the pipeline.  This also occurred with a beta version of a Creative webcam that I was testing as well.  All three cameras also support H.264 but not multiplexed with Motion JPEG as proposed in the specification that Logitech co-authored and presented to USB-IF.

Best Regards,

Rob

Could you make a capture available? 

something ... ! gdppay ! filesink location="..."

Hi Wim,

I will capture some MJPEG from the camera and upload it today.  I will also post my hack-around.

Best Regards,

Rob

Created attachment 234620 [details]
MJPEG from Creative Optia AF Webcam

MJPEG from Creative Optia AF Webcam that cannot be RTP encapsulated without "hack" to gstrtpjpegpay.c.

Created attachment 234621 [details]
gstrtpjpegpay.c containing "hack" to allow RTP encapsulation of Optia AF MJPEG

gstrtpjpegpay.c containing "hack" to allow RTP encapsulation of Optia AF MJPEG...

Hi Wim,

Let me know if you need anything else...there is one Logitech webcam, one FaceVsion webcam and one Creative webcam from which I have seen MJPEG such as this.  If I use qtmux to encapsulate it, then it plays fine under QuickTime on a Mac or a PC.

Best Regards,

Rob Krakora

Using GStreamer RTSP server I pass in this pipeline:

v4l2src device=/dev/video0 ! queue ! image/jpeg,width=640,height=480,framerate=(fraction)30/1 ! queue ! rtpjpegpay pt=26 name=pay0

Using GStreamer RTSP Source I use this pipeline:

gst-launch -e rtspsrc location=rtsp://<server IP>:<server Port>/<filename>.sdp ! rtpjpegdepay ! qtmux ! filesink location=<some path to file>.mov

The result plays fine on QuickTime on Mac or PC...as well as on Totem on Linux...

Let me know if you need more information...

There is just an incomplete jpeg frame at the end and the payloader doesn't like it but surely that's not the problem you are seeing..

What I want to know is what data you feed into the jpeg payloader. The payloader can only handle one jpeg frame per input buffer. Are you feeding a payloader from an http src?

I would like a capture of the stream like you would put it in the payloader so:

httpsrc location="..." ! gdppay ! filesink location="..."

so,

v4l2src device=/dev/video0 ! image/jpeg,width=640,height=480,framerate=(fraction)30/1 ! gdppay ! filesink location="..."

would be interesting

Created attachment 234629 [details]
gdppay results

JPEG frames are quite large and Bugzilla limits the size to 10 Meg...may I share a larger capture with you via my YouSendIt account?

If you look at "MY HACK" below, you will see what I had to do...maybe this will also provide some clues...

      case JPEG_MARKER_EOI:
        GST_WARNING_OBJECT (pay, "EOI reached before SOS!");
	gst_buffer_unref (buffer); // <-- MY HACK
	return GST_FLOW_OK; // <---MY HACK
        break;

Maybe the first frame is always incomplete but subsequent frames are O.K.?

At least for the logitech C920, you want to discard the empty JPEG frames, there is uvch264mjpgdemux for that.

Understood.  However, most other webcams don't adhere to the UVC JPEG container multiplexing scheme proposed in the spec authored by Logitech and cannot make use of uvch264_src (0.10) or uvch264src (1.xx).  That would mean other JPEG related plugins would have to be modified/fixed.  Creative and FaceVsion cameras for example.  There is also a Skype spec which I believe some of the cameras firmware is coded to...

I'm not sure how different the others are, if they're not too different, I guess we could extend uvch264src. Otherwise, another custom source is needed, and at least a custom mjpeg demultiplexer if they multiplex other things in their jpeg files.

Created attachment 245455 [details]
Skype Specification

Skype specification on MJPEG multiplexing...

Created attachment 245456 [details]
Skype Library

Skype Library...

I just uploaded the Skype Webcam specification on MJPEG multiplexing and such as well as their supporting library.  If anything, uvch264_src (0.10) and uvch264src (1.xx) are unique to (currently) only the C920 webcam (Logitech).  It should probably be left alone.  Another source plugin could be developed to support webcams that adhere to the attached Skype specification using the attached library.

That specification seems pretty close to the UVC H.264 spec actually. And the attached library seems to be not so useful, as we already have v4l2src and a way to inject extra XU into there.

Yes, it is close to the UVC H.264 spec.  The driver included for v4l2 with the library seems useful.  I am worried that subtle differences between the UVC H264 and Skype specifications may make an all-in-one uvch264/Skype plugin overly complicated.  I really have not compared the two specs in detail but it seems that at some point Skype and Logitech diverged.  Although, I don't know for sure.

Also Olivier, I submitted a bug report recently against 1.xx v4l2src as it seems to break 1.xx uvch264src after 30 seconds of playback.  I compared the 1.xx uvch264src with 0.10 uvch264_src source and per the porting guidelines and it appears that all of the functionality has been ported without degradation.  So, I suspect 1.xx v4l2src...sorry for getting off-topic.  I just wanted you to know that if you are thinking of utilizing 1.xx uvch264src to investigate the current topic of this bug report.

I think this will do as well, keep the warnings but don't error out.

commit 4258ddcc36a182c230a6a145b4e410cb6cc7b9f6
Author: Wim Taymans <wim.taymans@collabora.co.uk>
Date:   Wed Jun 26 20:49:41 2013 +0200

    jpegpay: turn some errors into warnings
    
    Turn some errors into warnings, we can continue processing so this should
    not be fatal.
    
    Fixes https://bugzilla.gnome.org/show_bug.cgi?id=657079

Sounds good.