[gst-devel] Timestamping problem with gdppay element

[Alexey Chernov]

On Wednesday 24 November 2010 22:11:42 you wrote:
> Hi,
> 
> On Wed, Nov 24, 2010 at 2:43 PM, 4ernov <4ernov at gmail.com> wrote:
> >> Hi,
> >> 
> >> On Wed, Nov 24, 2010 at 12:58 PM, 4ernov <4ernov at gmail.com> wrote:
> >> 
> >> ..snip..
> >> 
> >> >> have you ruled out the possibility to use native X facilities for
> >> >> this? For instance, you could use the "display" property of the
> >> >> second xvimagesink to perform the rendering on a different server,
> >> >> or the "device" one if you actually are on the same device
> >> >> 
> >> >> note: on some systems it requires to enable tcp connections for the X
> >> >> server.
> >> > 
> >> > Yes, I tried to set "display" property but with no success. Don't
> >> > actually know whether tcp connections are enabled on my X server, will
> >> > try it and "device" property, too, thank you.
> >> 
> >> on Ubuntu, give a look at /etc/gdm/gdm.schemas and set
> >> "security/DisallowTCP" to "false".
> >> 
> >> restart your X server and then write from a terminal where the DISPLAY
> >> variable is properly set:
> >> 
> >> xhost +
> >> 
> >> note that the things of above allow access to your X server from any
> >> devices in the network (an beyond) so it should really be something to
> >> use only for debug purposes. For stricter security, check the
> >> documentation about xhost and gdm.
> > 
> > Yes, thank you for detailed instruction, tcp connections were disabled
> > really (X was started with -nolisten tcp option), I changed kdm
> > settings (I use Kubuntu) and restarted. Everything's right, X without
> > -nolisten tcp, also executed 'xhost +' on each display but still no
> > success in term of GStreamer playing. Here's the pipeline:
> > 
> > gst-launch filesrc location=/home/alex/test.mp4 ! decodebin !
> > ffmpegcolorspace ! tee name=dist ! queue ! xvimagesink display=":1"
> > dist. ! queue ! xvimagesink display=":2"
> > 
> > And the output is:
> > 
> > Setting pipeline to PAUSED ...
> > Pipeline is PREROLLING ...
> > X Error of failed request:  BadShmSeg (invalid shared segment parameter)
> >  Major opcode of failed request:  135 (XVideo)
> >  Minor opcode of failed request:  19 ()
> >  Segment id in failed request:  0x3e
> >  Serial number of failed request:  40
> >  Current serial number in output stream:  41
> 
> Right, the two X servers run as separate processes and it's not
> possible to share the same buffer between the two while in overlay
> (not that I understand very well the inner reason of this :/ ).

me too actually :) but it's our client's idea and so I've got to do it..

> 
> An easy but expensive solution is to copy the buffer before rendering
> it, so your pipe should become something like:
> 
> gst-launch filesrc location=/home/alex/test.mp4 ! decodebin !
> ffmpegcolorspace ! tee name=dist ! queue ! xvimagesink display=":1"
> dist. ! queue ! videomixer ! xvimagesink display=":2"
> 
> we're lucky videomixers always copy the buffers :).

Thank you very much, Marco! I just tried it. It works just fine. Very smooth, I 
hope the performance is enough to copy buffers. Very good. Thank you!

> 
> Regards,
> Marco
> 
> > X error can also be
> > 
> > X Error of failed request:  BadShmSeg (invalid shared segment parameter)
> >  Major opcode of failed request:  130 (MIT-SHM)
> >  Minor opcode of failed request:  3 (X_ShmPutImage)
> >  Segment id in failed request:  0x200003
> >  Serial number of failed request:  29
> >  Current serial number in output stream:  30
> > 
> > if I use ximagesink instead of xvimagesink. I should say, everything
> > plays just fine if I use one xvimagesink element with display set
> > (video is really playing on another server without problems) or if
> > both these elements are with the same display option. But when I set
> > them different displays it goes to error.
> > 
> >> > By the way, setting async option to "true" as you suggested really
> >> > works, but as expected it makes syncronization lost. "max-lateness"
> >> > doesn't make any sense (tried from little intervals e.g. 200 to bigger
> >> > ones (15000000) with no success.
> >> 
> >> the max-lateness option is in ns, so you've basically set the delay to
> >> 200ms. What if you try something more substantial, let's say more than
> >> one second?
> >> 
> >> (not that I'm saying this is the best way to proceed, but I'm just
> >> curious).
> > 
> > No problem) I also tried 2 and 20 secs (2000000000 and 20000000000
> > values) but the result is still the same. I think the problem is with
> > some fluctuations the first moments after connection. Can I avoid
> > these 'bad' buffers somehow? Or the stream is just out of time and
> > already unrecoverable?
> > 
> >> Regards
> >> 
> >> ..snip..
> >> 
> >> 
> >> 
> >> ------------------------------------------------------------------------
> >> ------ Increase Visibility of Your 3D Game App & Earn a Chance To Win
> >> $500! Tap into the largest installed PC base & get more eyes on your
> >> game by optimizing for Intel(R) Graphics Technology. Get started today
> >> with the Intel(R) Software Partner Program. Five $500 cash prizes are
> >> up for grabs. http://p.sf.net/sfu/intelisp-dev2dev
> >> _______________________________________________
> >> gstreamer-devel mailing list
> >> gstreamer-devel at lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
> > 
> > -------------------------------------------------------------------------
> > ----- Increase Visibility of Your 3D Game App & Earn a Chance To Win
> > $500! Tap into the largest installed PC base & get more eyes on your
> > game by optimizing for Intel(R) Graphics Technology. Get started today
> > with the Intel(R) Software Partner Program. Five $500 cash prizes are up
> > for grabs. http://p.sf.net/sfu/intelisp-dev2dev
> > _______________________________________________
> > gstreamer-devel mailing list
> > gstreamer-devel at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel