splitmuxsink passing buffers in bursts
Locked
 
|
I have a pipeline which uses splitmuxsink to write to a file. I noticed
immediately that, as opposed to filesink, the file only gets updated in (relatively) infrequent bursts, rather than regularly if using a regular filesink. This is not due to filesink's buffering mode: I tried them all and it had no effect. Just to be sure, I switched splitmuxsink to use an appsink instead of a filesink and, indeed, the appsink's new_sample callback is called in bursts, instead of being called regularly if we use a straight appsink without splitmuxsink. In case you were wondering I set the appsink's sync property to FALSE. Indeed, with all settings in the pipeline identical, except for the existence of splitmuxsink, I see that with splitmuxsink buffers arrive at the final sink in bursts, whereas they arrive regularly otherwise. Any ideas what causes this and if there is a setting that can fix it? Getting the buffers in a timely manner is important in my case... Thank you! -- Sent from: http://gstreamer-devel.966125.n4.nabble.com/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
AW: splitmuxsink passing buffers in bursts
|
|
Hi,
In order to split properly I think you'll find that splitmuxsink needs to write complete GOPs. So it needs to collect gops before writing them out. Gruesse -----Ursprüngliche Nachricht----- Von: gstreamer-devel <[hidden email]> Im Auftrag von logidelic Gesendet: Dienstag, 1. Oktober 2019 22:28 An: [hidden email] Betreff: splitmuxsink passing buffers in bursts I have a pipeline which uses splitmuxsink to write to a file. I noticed immediately that, as opposed to filesink, the file only gets updated in (relatively) infrequent bursts, rather than regularly if using a regular filesink. This is not due to filesink's buffering mode: I tried them all and it had no effect. Just to be sure, I switched splitmuxsink to use an appsink instead of a filesink and, indeed, the appsink's new_sample callback is called in bursts, instead of being called regularly if we use a straight appsink without splitmuxsink. In case you were wondering I set the appsink's sync property to FALSE. Indeed, with all settings in the pipeline identical, except for the existence of splitmuxsink, I see that with splitmuxsink buffers arrive at the final sink in bursts, whereas they arrive regularly otherwise. Any ideas what causes this and if there is a setting that can fix it? Getting the buffers in a timely manner is important in my case... Thank you! -- Sent from: https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgstreamer-devel.966125.n4.nabble.com%2F&data=02%7C01%7C%7C2f0d7ef9342c4353f7de08d746ddb547%7C28042244bb514cd680347776fa3703e8%7C1%7C0%7C637055790350906128&sdata=sFHiIRnyGFAf%2F2cA7f61hhQAgEai4fTIRhWHqM06kEc%3D&reserved=0 _______________________________________________ gstreamer-devel mailing list [hidden email] https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fgstreamer-devel&data=02%7C01%7C%7C2f0d7ef9342c4353f7de08d746ddb547%7C28042244bb514cd680347776fa3703e8%7C1%7C0%7C637055790350916131&sdata=2O6SzAzBNFrFBxoXaRlC1R4jkc8clRnqfk%2BLE6L29jk%3D&reserved=0 _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
Hi Gruesse,
Thank you for the response. I will investigate this, but it doesn't quite make sense to me. I can certainly understand that the split can't happen except at the end of a GOP, but aside from that why would splitmuxsink be any different from any other mux/sink in its requirement to wait for a complete GOP before passing to the muxer (in my case matroskamux) sink? Thanks! Bill Thornton, Keith wrote > Hi, > In order to split properly I think you'll find that splitmuxsink needs to > write complete GOPs. So it needs to collect gops before writing them out. > Gruesse > > -----Ursprüngliche Nachricht----- > Von: gstreamer-devel < > gstreamer-devel-bounces@.freedesktop > > Im Auftrag von logidelic > Gesendet: Dienstag, 1. Oktober 2019 22:28 > An: > gstreamer-devel@.freedesktop > Betreff: splitmuxsink passing buffers in bursts > > I have a pipeline which uses splitmuxsink to write to a file. I noticed > immediately that, as opposed to filesink, the file only gets updated in > (relatively) infrequent bursts, rather than regularly if using a regular > filesink. > > This is not due to filesink's buffering mode: I tried them all and it had > no effect. > > Just to be sure, I switched splitmuxsink to use an appsink instead of a > filesink and, indeed, the appsink's new_sample callback is called in > bursts, instead of being called regularly if we use a straight appsink > without splitmuxsink. > > In case you were wondering I set the appsink's sync property to FALSE. > Indeed, with all settings in the pipeline identical, except for the > existence of splitmuxsink, I see that with splitmuxsink buffers arrive at > the final sink in bursts, whereas they arrive regularly otherwise. > > Any ideas what causes this and if there is a setting that can fix it? > Getting the buffers in a timely manner is important in my case... > > Thank you! > > > > -- > Sent from: > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgstreamer-devel.966125.n4.nabble.com%2F&data=02%7C01%7C%7C2f0d7ef9342c4353f7de08d746ddb547%7C28042244bb514cd680347776fa3703e8%7C1%7C0%7C637055790350906128&sdata=sFHiIRnyGFAf%2F2cA7f61hhQAgEai4fTIRhWHqM06kEc%3D&reserved=0 > _______________________________________________ > gstreamer-devel mailing list > gstreamer-devel@.freedesktop > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fgstreamer-devel&data=02%7C01%7C%7C2f0d7ef9342c4353f7de08d746ddb547%7C28042244bb514cd680347776fa3703e8%7C1%7C0%7C637055790350916131&sdata=2O6SzAzBNFrFBxoXaRlC1R4jkc8clRnqfk%2BLE6L29jk%3D&reserved=0 > _______________________________________________ > gstreamer-devel mailing list > gstreamer-devel@.freedesktop > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel -- Sent from: http://gstreamer-devel.966125.n4.nabble.com/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: splitmuxsink passing buffers in bursts
|
|
Le mer. 2 oct. 2019 09 h 55, logidelic <[hidden email]> a écrit : Hi Gruesse, I believe the speed at which data is mixed is not controlled, it should pretty much reflect the source behavior.
_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
Nicolas wrote:
> I believe the speed at which data is mixed is not controlled, it should > pretty much reflect the source behavior. That is what I would have expected, but my tests suggest otherwise. I will start playing with the splitmuxsink sources to try to figure it out. Thanks much. - Bill Nicolas Dufresne-5 wrote > Le mer. 2 oct. 2019 09 h 55, logidelic < > bill@ > > a écrit : > >> Hi Gruesse, >> >> Thank you for the response. I will investigate this, but it doesn't quite >> make sense to me. I can certainly understand that the split can't happen >> except at the end of a GOP, but aside from that why would splitmuxsink be >> any different from any other mux/sink in its requirement to wait for a >> complete GOP before passing to the muxer (in my case matroskamux) sink? >> > > I believe the speed at which data is mixed is not controlled, it should > pretty much reflect the source behavior. > > >> Thanks! >> >> Bill >> >> >> >> Thornton, Keith wrote >> > Hi, >> > In order to split properly I think you'll find that splitmuxsink needs >> to >> > write complete GOPs. So it needs to collect gops before writing them >> out. >> > Gruesse >> > >> > -----Ursprüngliche Nachricht----- >> > Von: gstreamer-devel < >> >> > gstreamer-devel-bounces@.freedesktop >> >> > > Im Auftrag von logidelic >> > Gesendet: Dienstag, 1. Oktober 2019 22:28 >> > An: >> >> > gstreamer-devel@.freedesktop >> >> > Betreff: splitmuxsink passing buffers in bursts >> > >> > I have a pipeline which uses splitmuxsink to write to a file. I noticed >> > immediately that, as opposed to filesink, the file only gets updated in >> > (relatively) infrequent bursts, rather than regularly if using a >> regular >> > filesink. >> > >> > This is not due to filesink's buffering mode: I tried them all and it >> had >> > no effect. >> > >> > Just to be sure, I switched splitmuxsink to use an appsink instead of a >> > filesink and, indeed, the appsink's new_sample callback is called in >> > bursts, instead of being called regularly if we use a straight appsink >> > without splitmuxsink. >> > >> > In case you were wondering I set the appsink's sync property to FALSE. >> > Indeed, with all settings in the pipeline identical, except for the >> > existence of splitmuxsink, I see that with splitmuxsink buffers arrive >> at >> > the final sink in bursts, whereas they arrive regularly otherwise. >> > >> > Any ideas what causes this and if there is a setting that can fix it? >> > Getting the buffers in a timely manner is important in my case... >> > >> > Thank you! >> > >> > >> > >> > -- >> > Sent from: >> > >> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgstreamer-devel.966125.n4.nabble.com%2F&data=02%7C01%7C%7C2f0d7ef9342c4353f7de08d746ddb547%7C28042244bb514cd680347776fa3703e8%7C1%7C0%7C637055790350906128&sdata=sFHiIRnyGFAf%2F2cA7f61hhQAgEai4fTIRhWHqM06kEc%3D&reserved=0 >> > _______________________________________________ >> > gstreamer-devel mailing list >> >> > gstreamer-devel@.freedesktop >> >> > >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fgstreamer-devel&data=02%7C01%7C%7C2f0d7ef9342c4353f7de08d746ddb547%7C28042244bb514cd680347776fa3703e8%7C1%7C0%7C637055790350916131&sdata=2O6SzAzBNFrFBxoXaRlC1R4jkc8clRnqfk%2BLE6L29jk%3D&reserved=0 >> > _______________________________________________ >> > gstreamer-devel mailing list >> >> > gstreamer-devel@.freedesktop >> >> > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel >> >> >> >> >> >> -- >> Sent from: http://gstreamer-devel.966125.n4.nabble.com/ >> _______________________________________________ >> gstreamer-devel mailing list >> > gstreamer-devel@.freedesktop >> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel > > _______________________________________________ > gstreamer-devel mailing list > gstreamer-devel@.freedesktop > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel -- Sent from: http://gstreamer-devel.966125.n4.nabble.com/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: splitmuxsink passing buffers in bursts
|
|
In reply to this post by logidelic
Hi,
On 2/10/19 11:34 pm, logidelic wrote: > Hi Gruesse, > > Thank you for the response. I will investigate this, but it doesn't quite > make sense to me. I can certainly understand that the split can't happen > except at the end of a GOP, but aside from that why would splitmuxsink be > any different from any other mux/sink in its requirement to wait for a > complete GOP before passing to the muxer (in my case matroskamux) sink? Splitmuxsink needs to collect an entire GOP before releasing it to the muxer so that it knows whether it will fit in the current file fragment. If it will overflow either the time or bytes limit, it needs to start a new file for that data. - Jan. > > Thanks! > > Bill > > > > Thornton, Keith wrote >> Hi, >> In order to split properly I think you'll find that splitmuxsink needs to >> write complete GOPs. So it needs to collect gops before writing them out. >> Gruesse >> >> -----Ursprüngliche Nachricht----- >> Von: gstreamer-devel < >> gstreamer-devel-bounces@.freedesktop >> > Im Auftrag von logidelic >> Gesendet: Dienstag, 1. Oktober 2019 22:28 >> An: >> gstreamer-devel@.freedesktop >> Betreff: splitmuxsink passing buffers in bursts >> >> I have a pipeline which uses splitmuxsink to write to a file. I noticed >> immediately that, as opposed to filesink, the file only gets updated in >> (relatively) infrequent bursts, rather than regularly if using a regular >> filesink. >> >> This is not due to filesink's buffering mode: I tried them all and it had >> no effect. >> >> Just to be sure, I switched splitmuxsink to use an appsink instead of a >> filesink and, indeed, the appsink's new_sample callback is called in >> bursts, instead of being called regularly if we use a straight appsink >> without splitmuxsink. >> >> In case you were wondering I set the appsink's sync property to FALSE. >> Indeed, with all settings in the pipeline identical, except for the >> existence of splitmuxsink, I see that with splitmuxsink buffers arrive at >> the final sink in bursts, whereas they arrive regularly otherwise. >> >> Any ideas what causes this and if there is a setting that can fix it? >> Getting the buffers in a timely manner is important in my case... >> >> Thank you! >> >> >> >> -- >> Sent from: >> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgstreamer-devel.966125.n4.nabble.com%2F&data=02%7C01%7C%7C2f0d7ef9342c4353f7de08d746ddb547%7C28042244bb514cd680347776fa3703e8%7C1%7C0%7C637055790350906128&sdata=sFHiIRnyGFAf%2F2cA7f61hhQAgEai4fTIRhWHqM06kEc%3D&reserved=0 >> _______________________________________________ >> gstreamer-devel mailing list >> gstreamer-devel@.freedesktop >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fgstreamer-devel&data=02%7C01%7C%7C2f0d7ef9342c4353f7de08d746ddb547%7C28042244bb514cd680347776fa3703e8%7C1%7C0%7C637055790350916131&sdata=2O6SzAzBNFrFBxoXaRlC1R4jkc8clRnqfk%2BLE6L29jk%3D&reserved=0 >> _______________________________________________ >> gstreamer-devel mailing list >> gstreamer-devel@.freedesktop >> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel > > > > > -- > Sent from: http://gstreamer-devel.966125.n4.nabble.com/ > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
Hi Jan, First of all, thank you for the work on splitmuxsink! Truly useful/essential stuff. Just before I got your message I was looking through the source and saw what you said: It waits in order to avoid busting the segment size. This seems like a reasonable default, but it's a pity that it's not optional: I'm sure many people would prefer the tradeoff of busting the segment size slightly (i.e. by < 1GOP) with the benefit of not having to delay buffers getting to the sink. - Bill On Wed, Oct 2, 2019 at 11:23 AM Jan Schmidt <[hidden email]> wrote: Hi, _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: splitmuxsink passing buffers in bursts
|
|
Hi, On 3/10/19 1:29 am, Bill Klein wrote:
Cheers! I'm always happy to hear about new use cases. It sounds
like you're doing something a bit different here?
That sounds like a useful low-latency mode. I'm not sure how difficult it would be to implement without trying it. The assumption about releasing 1 GOP at a time was baked in pretty early and may be implicit in a bunch of annoying places. - Jan.
_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
I don't think my use-case is particularly special, I just need low latency access to the real-time stream being output... Actually, I know that hlssink2 makes use of splitmuxsink, so I assume it's subject to the same problem/limitation: An unnecessary latency is introduced. If people are trying to use hlssink2 for real-time live broadcast (for example), they are getting handicapped... - Bill On Wed, Oct 2, 2019 at 11:45 AM Jan Schmidt <[hidden email]> wrote:
_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: splitmuxsink passing buffers in bursts
|
|
On 4/10/19 4:04 am, Bill Klein wrote:
Does that have to be from the fragments being written to disk?
You could insert a tee and stream a parallel feed using a
lower-latency method like RTSP.
HLS is one of the cases where you aren't allowed to overrun the fragment time listed in the manifest, so you'd have to control the GOP size and factor that in to the reported fragment size to make the whole thing work without the additional latency. HLS isn't designed for such low-latency access in any case - fragments are typically ~10 seconds and not published to the manifest until you finish writing them out, at least that way GStreamer does it. - Jan.
_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
«
Return to GStreamer-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |