[gst-devel] Timestamping problem with gdppay element

[4ernov]

I seem to find and fix a bug in gdpdepay element's code which caused
such a behavior in configuration with gdppay/gdpdepay. It was
timestamping problem in depaying process - timestamps on input depayed
buffers stay "as is" i.e. they are correct in the primary pipeline and
not in the secondary. Some more details and patch I wrote in comment
to this bug report:

https://bugzilla.gnome.org/show_bug.cgi?id=635226

Hope it would be accepted to the main tree.
Big thanks to everyone for help with this problem!

2010/11/24 Alexey Chernov <4ernov at gmail.com>:
> 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
>