[gst-devel] Timestamping problem with gdppay element

[Marco Ballesio]

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 :/ ).

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

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
>