[Bug 725860] v4l2src: Fix using v4l2src with Hauppauge HDPVR video capture device

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=725860
  GStreamer | gst-plugins-good | 1.2.3

--- Comment #13 from Nicolas Dufresne <nicolas.dufresne at collabora.co.uk> 2014-03-07 16:48:54 UTC ---
(In reply to comment #11)
> (In reply to comment #9)
> > Review of attachment 271165 [details] [details]:
> > 
> > That seems fair, though is this how MPEG support is defined in V4L2 or is this
> > only this way for this driver ?
> 
> The v4l2 documentation[1] says:
> 
> > Identifier           Code      Details
> >
> > V4L2_PIX_FMT_MPEG    'MPEG'    MPEG stream. The actual format is determined by
> >                                extended control V4L2_CID_MPEG_STREAM_TYPE, see
> >                                Table 1.2, “MPEG Control IDs”.
> 
> Table 1.2 in turn says:
> 
> > V4L2_CID_MPEG_STREAM_TYPE    enum v4l2_mpeg_stream_type	 
> >    The MPEG-1, -2 or -4 output stream type. One cannot assume anything here.
> >    Each hardware MPEG encoder tends to support different subsets of the
> >    available MPEG stream types. The currently defined stream types are:
> >
> >    V4L2_MPEG_STREAM_TYPE_MPEG2_PS     MPEG-2 program stream
> >    V4L2_MPEG_STREAM_TYPE_MPEG2_TS     MPEG-2 transport stream
> >    V4L2_MPEG_STREAM_TYPE_MPEG1_SS     MPEG-1 system stream
> >    V4L2_MPEG_STREAM_TYPE_MPEG2_DVD    MPEG-2 DVD-compatible stream
> >    V4L2_MPEG_STREAM_TYPE_MPEG1_VCD    MPEG-1 VCD-compatible stream
> >    V4L2_MPEG_STREAM_TYPE_MPEG2_SVCD   MPEG-2 SVCD-compatible stream
> 
> So currently GStreamer doesn't check V4L2_CID_MPEG_STREAM_TYPE and just assumes
> V4L2_MPEG_STREAM_TYPE_MPEG2_TS.
> 
> As far as I can see "video/mpegts,systemstream=true" is how mpegts is
> represented in terms of GStreamer caps.  I do find this confusing as
> systemstream=true doesn't seem to confer any additional information.  I would
> happy to be corrected by someone who knows better though.  This systemstream
> thing has been puzzling me.
> 
> IOW the v4l2 spec doesn't specify any way of having
> "video/mpegts,systemstream=false" because the concept only seems to exist in
> GStreamer AFAICS and doesn't correspond to any real video or container format. 
> Therefore it has to be systemstream=true.
> 
> [1]:
> http://www.linuxtv.org/downloads/legacy/video4linux/API/V4L2_API/spec-single/v4l2.html#id2809728

Indeed, all agreed, thanks for taking time to explain.

(In reply to comment #12)
> (In reply to comment #8)
> > Review of attachment 271151 [details] [details]:
> > 
> > This is a bit obfuscated. Basically you have an encoded format, or in this case
> > a container. What I'd prefer is to see a special case for that, rather then
> > checking for value set to zero. In GstVideoFormatInfo you get a format type
> > ENCODED when this is the case.
> 
> from gst_v4l2_object_probe_caps_for_format might be better.  What would you
> suggest?

Sorry, I should have proposed a check if it's a container indeed. Encoded
format don't indeed comes with widht/height. We have a list of formats, with a
type, currently RAW and ECNODED. We should mark container as well and skip some
part base on that. This all need a lot of cleanup, there use to be hacks here
and there for mpegts, I think it's time to unhack this a bit. Except that for
1.2 branch, a smaller patch like you proposed might be adequate. I'll need to
think about it a bit, will come back on that soon.

-- 
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.