[Bug 611157] [RFC] more buffer flags and caps fields in gst-video for 3d video

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Wed Apr 24 08:31:04 PDT 2013


https://bugzilla.gnome.org/show_bug.cgi?id=611157
  GStreamer | gst-plugins-base | unspecified

--- Comment #64 from sreerenj <bsreerenj at gmail.com> 2013-04-24 15:31:01 UTC ---
I think these cases are handled in the patch sets.

Demuxers will set all the parsed informations in caps. Decoders are setting the
meta based on the caps from demuxer and internally parsed information (if
anything). I did this in BaseDecoder and it provided an API to subclass
implementation. All the video content handling should be the duty of
video3dpostprocessing element + videosink.

The flipping flags are indicating that the content is flipped or not. The
content manipulation is again the duty of video3dpostprocessing element.

Why do we need to accumulate two buffers in decoders??? 

The flags GST_STEREO_VIDEO_FRAME_TYPE_SEQUENTIAL_PROGRESSIVE and
GST_STEREO_VIDEO_FRAME_TYPE_SEQUENTIAL_ROW_INTERLEAVED are indicating that
frames are not packed together. What is the problem here?

There is no GstStereoVideoScheme conversion in the patcehs...is there?? !

The GstStereoVideoScheme is basically just a helper for demuxer. The right
place of this is in pbutils. But i added this to gst-libs/gst/video to avoid
many duplications.

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


More information about the gstreamer-bugs mailing list