Video Delay (Async) filter incompatible about obs-gstreamer HOT 9 CLOSED

Do you have sample pipeline you are trying with?

I guess that ticking the Use pipeline timestamps options in the GStreamer source may fix it?
When un-ticked it sends some pseudo timestamps only that may interfere with the Async filter because of that.

It sends pseudo timestamps to force updating the video asap. That reduces latency in some cases (e.g. screen capture) by may be counter productive in other cases. That timestamp handling is always quite delicate and there does not seem a universal solution for all use cases (also - long term clock synchronization is annoying..)

from obs-gstreamer.

What version of the plugin are you using? Starting with 0.2.0 there are separate tick boxes for audio and video.

I tried with the default pipeline as well as with your RTMP url. Both worked for me, no crashes when ticking/un-ticking them. Also adding an async filter was working when when the checkboxes were ticked.

Perhaps it requires a certain order to make it crash? Can you get a stack dump with gdb in case it crashes? May be enough of a hint.

from obs-gstreamer.

Yep generating a crash is actually much easier than I thought. Open OBS, go to properties of the gst source, and just press 'Apply' - no need to change any options!

I'm using a very recent build - I do indeed have different checkboxes for audio + video.

This doesn't look hugely useful - let me know if I need to find some symbols.

Thread 31 "source:src" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fff5a2fb700 (LWP 7964)]
0x00007ffff043da54 in RTMP_ReadPacket () from /lib/x86_64-linux-gnu/librtmp.so.1
(gdb) bt full
#0  0x00007ffff043da54 in RTMP_ReadPacket () at /lib/x86_64-linux-gnu/librtmp.so.1
#1  0x00007ffff0441e67 in RTMP_GetNextMediaPacket () at /lib/x86_64-linux-gnu/librtmp.so.1
#2  0x00007ffff0441f5f in  () at /lib/x86_64-linux-gnu/librtmp.so.1
#3  0x00007ffff0442acf in RTMP_Read () at /lib/x86_64-linux-gnu/librtmp.so.1
#4  0x00007fffa40153f5 in  () at /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstrtmp.so
#5  0x00007fffa6cc54dd in  () at /lib/x86_64-linux-gnu/libgstbase-1.0.so.0
#6  0x00007fffa6cc85bc in  () at /lib/x86_64-linux-gnu/libgstbase-1.0.so.0
#7  0x00007fffa6ef7107 in  () at /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#8  0x00007ffff3bfd1d4 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#9  0x00007ffff3bfc931 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#10 0x00007ffff4f0b609 in start_thread (arg=<optimised out>) at pthread_create.c:477
        ret = <optimised out>
        pd = <optimised out>
        unwind_buf = 
              {cancel_jmp_buf = {{jmp_buf = {140734706464512, 3794252754087864101, 140736439957166, 140736439957167, 140736439957312, 140734706460096, -3793912590313953499, -3794268222755805403}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = 0
#11 0x00007ffff4e32293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

from obs-gstreamer.

I could not reproduce it as the stream seems down.

This trace may actually indicate a bug in GStreamer itself or the underlying RTMP library. There seems to be a rogue thread corrupting memory.

There is a slim chance this plugin missed to close something properly - but my first bet would be on some of the dependencies.

from obs-gstreamer.

Good news - the crashing seems to be limited to my laptop; let's waste no more time on that.

In Video Delay (Async), your suggestion about trying combinations of the four 'sync' checkboxes have allowed the delay feature to work, but at some cost :(

When I apply even a modest delay of 1000ms, the sound continues at a consistent rate (excellent news!) but the video frame-rate appears to compress + rarefact in time

Pipeline hasn't been changed since your interleaved suggestion earlier:

uridecodebin uri=rtmp://127.0.0.1/faraway/xxxxxxx6803e64a2dd915844c7b73020714a name=bin ! queue ! video. bin. ! queue ! audioconvert ! audio/x-raw, layout=interleaved ! audio.

from obs-gstreamer.

Ah, I could not make it it time yesterday.

In theory your use case should be:

• use time stamps ticked
• sync appsink to clock un-ticked

In that case the GStreamer pipeline should just carry original timestamps but not do any jitter correction. If the async filter then does its job right it should work. If the async filter is just "cheap" and fails it may still be worth a try to tick the sync appsink option again.

I wonder if you can replicate the behavior with some offline content or test pipeline..

from obs-gstreamer.

No problem re: times - I really appreciate your effort in creating this software; anything beyond that is an unexpected delight.

I'll try the check-boxes again with the latest build of obs-gstreamer and will try to replicate with an offline test, or at least trying to use the standard Wowza 'Big Buck Bunny' rtsp demo (rather than rtmp)

from obs-gstreamer.

The better it works for everyone the better :)

I tried with the default pipeline and removed the live property, I think that caused some weird behavior too but I haven't investigated it yet.

The BigBuck Bunny sample was down the last time I checked. Maybe they changed host or removed it.

I could also imagine it is related to audio too.. like if the gab between the two gets too big..

The key in the end is to find a good example that can be easily replicated.

from obs-gstreamer.

OK, this problem has 'gone away'.

I'm going to put this down to a combination of my own laptop being cranky and the AWS instance having insufficient CPU. There were more background processes running than I expected. It doesn't really explain why the video was smooth with zero delay, but I'll take it for now.

Oh, in passing, the Wowza demo server now has a fixed hostname :) rtsp://wowzaec2demo.streamlock.net/vod/mp4:BigBuckBunny_175k.mov etc.

from obs-gstreamer.