[Bug 709455] dlnasrc: new manager type element used for dlna specific HTTP transfers

Wed Dec 4 06:19:40 PST 2013

https://bugzilla.gnome.org/show_bug.cgi?id=709455
  GStreamer | gst-plugins-bad | 1.x

--- Comment #37 from Lori Anderson <grandocap at gmail.com> 2013-12-04 14:19:33 UTC ---

Here is the xchat discussion about autopluggin:

[landerson] autoplugging question, I have an element which extends from
basetransform I implemented a transformcaps() function because the src caps are
application/x-dtcp1 and sink caps are any the element transitions into the
paused state fine but when playbin tries to go to playing, it gets stuck in a
recursive loop where is creates more and more dtcpip elements.  I think my
transformcaps() is doing the right thing when it's call with direction=sink, it
returns what is desired on the src which is ANY when its called with
direction=src, it returns what is desired on the sink which is
application/x-dtcp1.  What could be causing the recursion?
I also get a "got 'caps' before 'stream-start' warning prior to recursion but
that would mean the your output caps are the same as your input
[stormer]: I didn't intend that - I want my input caps to be x-dtcp1 and output
caps to be ANY.  Did I implement transformcaps() incorrectly?
[stormer]: well, probably not ANY in transform caps, you need fixed caps after
that do you really don't know what is encrypted ?  btw, I'm missing a bit of
context, x-dtcp1 comes out of dlnasrc directly ?
[landerson]: correct - souphttpsrc is doing http transfer, we're decrypting by
stripping off everything and left with the av stream just as if it was not
encrypted
[landerson]: y - application/x-dtcp1 is dlna
[stormer]right, make sense, so are you using gst-launch-1.0 ?
[landerson]: I could use the mime type supplied as the media type in caps but I
rather have the stream "discovered" just like it is for non-encrypted content
[landerson]: using gstreamer-1.0, both gst-launch-1.0, test program and webkit
[stormer]yes, very often the caps will be generic, unless it's HLS, is that
possible to serce HLS from DLNA ?  anyway, what I wanted to say is run with -v,
check for dtcpdec.GstPad:src and check the caps
that's the output caps you have negotiated, if they are application/x-dtcp1 it
means there a bug in your transform caps
[landerson]: ok - thank you very much. I will look to see what they are.
[stormer]: note, you can easily trace caps using GST_DEBUG_OBJECT (obj, "My Cap
are %" GST_PTR_FORMAT, caps)
[landerson]: one last question :) - is it ok for dtcp dec to have input caps of
x-dtcp1 and output caps of ANY? Or does it have to be a media type?
[stormer]: yes, it's ok, normally it will instruct decodebin to go into type
finding mode
[landerson]: I printed out src & sink pad caps and they are null  when
extending from basetransform, where should they be set?  I am trying to mimic
what is done in videoconvert & audioconvert but I am missing something
[stormer]: I might have forgotton the context, what is it about ?
[landerson]: from conversation on Friday - I can paste the content if that is
the proper "etiquette" for xchat, starts with autoplugging question, I have an
element which extends from basetransform
[stormer]:ah right
[landerson]: src & sink pad caps are NULL
[stormer]: did you call gst_element_class_add_pad_template() and stuff, as in
the ends it's a element and need similar setup ? like in
gst_video_convert_class_init()
[landerson]: yes - created pad templates for both with static caps
[stormer]: also note that there is specialized base transform if you doing only
audio or video, GstVideoFilter and GstAudioFilter, I forgot what you where
transforming though ... is you plugin built as a shared object ? if so what do
you see in gst-inspect, does that looks ok ?
[landerson]: Pad Templates:
SRC template: 'src'
Availability: Always
Capabilities:
ANY
SINK template: 'sink'
Availability: Always
Capabilities:
application/x-dtcp1
it looks like what I want - encrypted content coming in any content coming out.
 I'm confused what I need to override from basetransform
looking at the other "normal" transform elements, it looks like they all
override "fixate_caps" 
[stormer]yes, because they often want to influence what caps are preferred
during fixation for example, videoscale elements might want to prefer the
srccaps width&height values.  I think you need only fixate_caps() and
transform(), unless the decryption is in-place ? 
[landerson]no transform_caps()? 
[stormer]And in your case, this influence is easy, you always output ANY as a
fixed caps 
[landerson]: so you're saying fixate_caps() should always return "ANY", right?
Let me check the code 
[stormer]: for fixate I think so yes, dv sound right to you too ? 
[tim]: that doesn't make sense really.  you're doing the opposite of fixating
if you return ANY :) 
[stormer]:well, what shall be used for a stream that need to be typefind ? 
[landerson]: it looks like fixate_caps() takes a direction so for
sink=application/x-dtcp1 and src=ANY 
[tim]: you can't make decodebin plug additional typefinders.  ANY is not a
fixed caps you can set 
[stormer]:how does it work for a source then ? 
[tim]: decodebin will always plug a typefind element after the source.  well,
as input.  so it's hardcoded, whcih mean a decrypting element need to be a bin
to plug typefinders somehow. You don't need a typefind element to do
typefinding but it could be a bin too.
[stormer]landerson is trying to implement a DTCPIP decrypter element, for DLNA,
but the decrypted output is of type ANY (we don't know yet), what would you
propose ? 
[tim]I guess it depends where in the pipeline it goes, but it sounds like you
need to do typefinding unless you get the content type communicated some other
way.  
[stormer]short story, you can't really use Basetransform sorry about it being
miss-leading 
[tim]I think the plan was a dlnasrc (you'll find that in bugzilla for review),
that may produce x-dtcp1 instead of ANY landerson: I think the simpliest would
be to hide the decrypter int he dlnasrc src (whic iirc is a bin), and implement
the decrypter on top of GstElement, as it does not fit a basetransform
baseclass, unless someone has a better idea
[stormer]basically you'd plug the decrypter yourself :-S
[landerson]that was my original approach but i thought it would be better to
have it autoplug rather than having dlnasrc hook it up manually 
[stormer]: it's a bit the limit of my knowledge of it, __tim or slomo might be
better help if it's about auto-pluggin this ... 
[landerson]: thanks for all the help & I will go with my original approach
unless someone suggests something else during the next round of review of the
dlnasrc 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.