[Bug 692045] Port uvch264src to gstreamer 1.0

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=692045
  GStreamer | gst-plugins-bad | git

--- Comment #8 from Youness Alaoui <youness.alaoui at collabora.co.uk> 2013-02-05 23:46:10 UTC ---
(In reply to comment #7)
> > - In gst_uvc_h264_src_fixate_caps, why did you remove the gst_caps_unref(tcaps)
> > ?
> 
> gst_caps_normalize takes ownership in 1.0
> 
oh ok, a change in behavior. Thanks.

> > - Same comment as Olivier about the gst_pad_fixate_caps
> 
> See my reply there :)
I'm not exactly sure what it does differntly. It's probably just more optimized
or something, but it should still work the same in the end. Would need testing.

> 
> > - The custom_upstream "renegotiate" event handling should be removed and
> > replaced with handling the reconfigure event (or is that automatic?).
> 
> Removed that code (nothing send the event atm). Making sure uvch264
> renegotiates correctly is something todo, but given v4l2src can't renegotiate
> properly atm it's a tad moot
Ah, I didn't notice it being removed from the diff, maybe I just missed it.
As for renegotiation, although there is a RESET ioctl for the h264 encoder, it
doesn't seem to work for the C920, so either way, renegotiation forces me to
put v4l2src to state READY and back to PLAYING, this means that even if v4l2src
can't renegotiate at the moment, uvch264_src should still be able to achieve
it.

> 
> > 
> > There is also a couple of bugfixes I've done recently on the 0.10 branch :
> > http://cgit.collabora.com/git/user/kakaroto/gst-plugins-bad.git/log/?h=0.10
> > You can ignore the PropertyProbe patch (until we have an equivalent for 1.0),
> > but there were a couple of bugs in transform_caps and handling of the caps ref
> > that might need porting to the 1.0 code.
> 
> From just a quick skim it looks like it's only the refcounting bug that isn't
> pulled in yet (which changed in 1.0, but i should doublecheck if it's correct
> there).  or did i miss something?
Yes, there was a refcounting issue in the case an error occurs, but also, I had
to add a fakesink to that transform_caps otherwise basetransform returns the
pad templates if it sees there's nothing linked on the other side of the
colorspace. I don't know how that works in 1.0 though.


> I'm not entirely sure about the segment handling, so i left it as is.. Youness
> might be able to clarify what it's necessary in 0.10
The reason for segment handling is that when we renegotiate, we drop the EOS
that's being sent when we pull v4l2src to state READY, and we put it back to
PLAYING, it sends another new-segment which needs to be dropped (otherwise you
get accumulation and whatever, and it screws everything up). I believe there's
no more accumulation of segments in 1.0, in that case, that code might not be
needed anymore, but again without testing we can't know for sure.
I don't have the hardware anymore (sent for a demo to the CES conference), so I
can't test this myself now. I might request new cameras so I can keep
maintaining the element.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.