gst_app_src_push_buffer ownership bug?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

gst_app_src_push_buffer ownership bug?

pderocco
I have a pipeline that sends audio through an appsrc and over a network via RTP and UDP. It is set up with gst_parse_launch and the following string:
appsrc name=appsrc
! audio/x-raw,format=S16LE,layout=interleaved,channels=2,depth=16,rate=16000
! audioconvert
! rtpL16pay pt=96
! rtpjitterbuffer latency=10
! udpsink host=10.90.90.100 port=4000
It works. However, I decided that I didn't need an rtpjitterbuffer, since the data aren't coming from an unreliable source, so I took it out. Now the pipeline still "works", but it leaks memory, apparently never freeing the buffers. I'm using gst_app_src_push_buffer, which is documented as taking ownership of the buffer, meaning that the appsrc or something downstream of it is expected to unreference it. But it's hard to see how removing something several elements down the pipeline could cause it not to free the buffer.

So what should I do? I really don't want the overhead of rtpjitterbuffer (which I assume contains another thread), so should I just call gst_object_unref even though I shouldn't have to? Or is there something I'm missing?
Reply | Threaded
Open this post in threaded view
|

Re: gst_app_src_push_buffer ownership bug?

pderocco
Actually, I tried unreffing the object after pushing it, but it complained that it wasn't an object any more. So what's leaking doesn't appear to be my buffers. For now, I'll leave the rtpjitterbuffer in, but I'd really like to unburden my program of that, if anyone knows how.

By the way, it doesn't appear that the data are piling up inside the UDP socket because they are actually being sent over the network.