gsttextoverlay deadlock or something

[Jérôme Laheurte-3]

So two week-ends later I kind of have a working dev environment and started working on https://bugzilla.gnome.org/show_bug.cgi?id=540131. Unfortunately in the process I noticed that the use case (subtitle buffer arriving while another one hasn’t expired) now result in a kind of deadlock, and I’m not familiar enough with gstreamer to fully understand what is happening here. Some observations:

1. The text_chain method is blocked waiting for the previous buffer to get popped (at gstbasetextoverlay.c:2713)

2. But the video_chain method doesn’t get called any more. Since it’s the one popping old text buffers, everything stops.

3. There is nothing of interest in the debug output

This didn’t happen last time I tested a video with multiple concurrent subtitles, but that was a long time ago. It kind of looks like the text_chain and video_chain functions are now called by the same thread. Does anybody have any light to share on this ?

Thanks in advance

Jérôme Laheurte

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Jérôme Laheurte-3]

> Le 15 oct. 2017 à 14:45, Jérôme Laheurte <[hidden email]> a écrit :
>
> So two week-ends later I kind of have a working dev environment and started working on https://bugzilla.gnome.org/show_bug.cgi?id=540131. Unfortunately in the process I noticed that the use case (subtitle buffer arriving while another one hasn’t expired) now result in a kind of deadlock, and I’m not familiar enough with gstreamer to fully understand what is happening here. Some observations:
>
> 1. The text_chain method is blocked waiting for the previous buffer to get popped (at gstbasetextoverlay.c:2713)
> 2. But the video_chain method doesn’t get called any more. Since it’s the one popping old text buffers, everything stops.
> 3. There is nothing of interest in the debug output
>
> This didn’t happen last time I tested a video with multiple concurrent subtitles, but that was a long time ago. It kind of looks like the text_chain and video_chain functions are now called by the same thread. Does anybody have any light to share on this ?

More information, sorry:

* Video file: https://jeromelaheurte.net/owncloud/s/21E1m14sFOxfAmy
* Pipeline: gst-launch-1.0 -v filesrc location=sub.mkv ! matroskademux name=demux ! queue ! vtdec ! subtitleoverlay name=overlay ! autovideosink demux. ! ssaparse ! overlay.
* Version: git master

Jérôme Laheurte


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Mailing List SVR]

Il 15/10/2017 14:50, Jérôme Laheurte ha scritto:

Le 15 oct. 2017 à 14:45, Jérôme Laheurte [hidden email] a écrit :

So two week-ends later I kind of have a working dev environment and started working on https://bugzilla.gnome.org/show_bug.cgi?id=540131. Unfortunately in the process I noticed that the use case (subtitle buffer arriving while another one hasn’t expired) now result in a kind of deadlock, and I’m not familiar enough with gstreamer to fully understand what is happening here. Some observations:

1. The text_chain method is blocked waiting for the previous buffer to get popped (at gstbasetextoverlay.c:2713)
2. But the video_chain method doesn’t get called any more. Since it’s the one popping old text buffers, everything stops.
3. There is nothing of interest in the debug output

This didn’t happen last time I tested a video with multiple concurrent subtitles, but that was a long time ago. It kind of looks like the text_chain and video_chain functions are now called by the same thread. Does anybody have any light to share on this ?

More information, sorry:

* Video file: https://jeromelaheurte.net/owncloud/s/21E1m14sFOxfAmy
* Pipeline: gst-launch-1.0 -v filesrc location=sub.mkv ! matroskademux name=demux ! queue ! vtdec ! subtitleoverlay name=overlay ! autovideosink demux. ! ssaparse ! overlay.

try to add a queue before ssaparse,

Nicola

* Version: git master

Jérôme Laheurte

_______________________________________________
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

[Jérôme Laheurte-3]

Le 15 oct. 2017 à 17:03, Mailing List SVR <[hidden email]> a écrit :

Il 15/10/2017 14:50, Jérôme Laheurte ha scritto:

Le 15 oct. 2017 à 14:45, Jérôme Laheurte [hidden email] a écrit :

So two week-ends later I kind of have a working dev environment and started working on https://bugzilla.gnome.org/show_bug.cgi?id=540131. Unfortunately in the process I noticed that the use case (subtitle buffer arriving while another one hasn’t expired) now result in a kind of deadlock, and I’m not familiar enough with gstreamer to fully understand what is happening here. Some observations:

1. The text_chain method is blocked waiting for the previous buffer to get popped (at gstbasetextoverlay.c:2713)
2. But the video_chain method doesn’t get called any more. Since it’s the one popping old text buffers, everything stops.
3. There is nothing of interest in the debug output

This didn’t happen last time I tested a video with multiple concurrent subtitles, but that was a long time ago. It kind of looks like the text_chain and video_chain functions are now called by the same thread. Does anybody have any light to share on this ?

More information, sorry:

* Video file: https://jeromelaheurte.net/owncloud/s/21E1m14sFOxfAmy
* Pipeline: gst-launch-1.0 -v filesrc location=sub.mkv ! matroskademux name=demux ! queue ! vtdec ! subtitleoverlay name=overlay ! autovideosink demux. ! ssaparse ! overlay.

try to add a queue before ssaparse,

Nope, still deadlocking. Same place. If I’m not mistaken the queue ensures that the text_chain function is called in the queue’s thread, am I wrong ? So the problem is not as simple as I supposed.

Jérôme Laheurte

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Mailing List SVR]

Il 15/10/2017 17:32, Jérôme Laheurte ha scritto:

Le 15 oct. 2017 à 17:03, Mailing List SVR <[hidden email]> a écrit :

Il 15/10/2017 14:50, Jérôme Laheurte ha scritto:

Le 15 oct. 2017 à 14:45, Jérôme Laheurte [hidden email] a écrit :

So two week-ends later I kind of have a working dev environment and started working on https://bugzilla.gnome.org/show_bug.cgi?id=540131. Unfortunately in the process I noticed that the use case (subtitle buffer arriving while another one hasn’t expired) now result in a kind of deadlock, and I’m not familiar enough with gstreamer to fully understand what is happening here. Some observations:

1. The text_chain method is blocked waiting for the previous buffer to get popped (at gstbasetextoverlay.c:2713)
2. But the video_chain method doesn’t get called any more. Since it’s the one popping old text buffers, everything stops.
3. There is nothing of interest in the debug output

This didn’t happen last time I tested a video with multiple concurrent subtitles, but that was a long time ago. It kind of looks like the text_chain and video_chain functions are now called by the same thread. Does anybody have any light to share on this ?

More information, sorry:

* Video file: https://jeromelaheurte.net/owncloud/s/21E1m14sFOxfAmy
* Pipeline: gst-launch-1.0 -v filesrc location=sub.mkv ! matroskademux name=demux ! queue ! vtdec ! subtitleoverlay name=overlay ! autovideosink demux. ! ssaparse ! overlay.

try to add a queue before ssaparse,

Nope, still deadlocking. Same place. If I’m not mistaken the queue ensures that the text_chain function is called in the queue’s thread, am I wrong ? So the problem is not as simple as I supposed.

adding the queue and replacing vtdec with avdec_h264 works for me on linux, so the problem seems related to vtdec, I don't have a mac available to test with vtdec now,

Nicola

Jérôme Laheurte

_______________________________________________
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

[Jérôme Laheurte-3]

Le 15 oct. 2017 à 19:07, Mailing List SVR <[hidden email]> a écrit :

adding the queue and replacing vtdec with avdec_h264 works for me on linux, so the problem seems related to vtdec, I don't have a mac available to test with vtdec now,

Indeed, same behavior on mac OS. Removing the queue blocks the pipeline before it can even start though, which doesn’t seem normal. On to bugzilla… Do you think I should create two separate bug reports?

Best regards

Jérôme Laheurte

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Mailing List SVR]

Il 16/10/2017 19:41, Jérôme Laheurte ha scritto:

Le 15 oct. 2017 à 19:07, Mailing List SVR <[hidden email]> a écrit :

adding the queue and replacing vtdec with avdec_h264 works for me on linux, so the problem seems related to vtdec, I don't have a mac available to test with vtdec now,

Indeed, same behavior on mac OS. Removing the queue blocks the pipeline before it can even start though, which doesn’t seem normal.

this is a normal behaviour, a queue is needed after each demux branch,

To learn why the queues are necessary  please read this:

https://gstreamer.freedesktop.org/documentation/tutorials/basic/multithreading-and-pad-availability.html

Nicola

On to bugzilla… Do you think I should create two separate bug reports?

Best regards

Jérôme Laheurte

_______________________________________________
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

[Jérôme Laheurte-3]

Le 16 oct. 2017 à 22:50, Mailing List SVR <[hidden email]> a écrit :

Il 16/10/2017 19:41, Jérôme Laheurte ha scritto:

Le 15 oct. 2017 à 19:07, Mailing List SVR <[hidden email]> a écrit :

adding the queue and replacing vtdec with avdec_h264 works for me on linux, so the problem seems related to vtdec, I don't have a mac available to test with vtdec now,

Indeed, same behavior on mac OS. Removing the queue blocks the pipeline before it can even start though, which doesn’t seem normal. 

this is a normal behaviour, a queue is needed after each demux branch,

To learn why the queues are necessary  please read this:

https://gstreamer.freedesktop.org/documentation/tutorials/basic/multithreading-and-pad-availability.html

Understood, thanks.

Best regards

Jérôme Laheurte

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Mailing List SVR]

Il 16/10/2017 19:41, Jérôme Laheurte ha scritto:

Le 15 oct. 2017 à 19:07, Mailing List SVR <[hidden email]> a écrit :

adding the queue and replacing vtdec with avdec_h264 works for me on linux, so the problem seems related to vtdec, I don't have a mac available to test with vtdec now,

Indeed, same behavior on mac OS. Removing the queue blocks the pipeline before it can even start though, which doesn’t seem normal. On to bugzilla… Do you think I should create two separate bug reports?

I tested your file on osx and it works for me using vtdec too,

tested with gstreamer 1.12 compiled from source,

Nicola

Best regards

Jérôme Laheurte

_______________________________________________
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

[Jérôme Laheurte-3]

Le 19 oct. 2017 à 09:39, Mailing List SVR <[hidden email]> a écrit :

Il 16/10/2017 19:41, Jérôme Laheurte ha scritto:

Le 15 oct. 2017 à 19:07, Mailing List SVR <[hidden email]> a écrit :

adding the queue and replacing vtdec with avdec_h264 works for me on linux, so the problem seems related to vtdec, I don't have a mac available to test with vtdec now,

Indeed, same behavior on mac OS. Removing the queue blocks the pipeline before it can even start though, which doesn’t seem normal. On to bugzilla… Do you think I should create two separate bug reports?

I tested your file on osx and it works for me using vtdec too, 

tested with gstreamer 1.12 compiled from source,

Interesting. I’ll tro to build 1.12 (the version I tested was git master).

Best regards

Jérôme Laheurte

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Mailing List SVR]

Il 19/10/2017 10:41, Jérôme Laheurte ha scritto:

Le 19 oct. 2017 à 09:39, Mailing List SVR <[hidden email]> a écrit :

Il 16/10/2017 19:41, Jérôme Laheurte ha scritto:

Le 15 oct. 2017 à 19:07, Mailing List SVR <[hidden email]> a écrit :

adding the queue and replacing vtdec with avdec_h264 works for me on linux, so the problem seems related to vtdec, I don't have a mac available to test with vtdec now,

Indeed, same behavior on mac OS. Removing the queue blocks the pipeline before it can even start though, which doesn’t seem normal. On to bugzilla… Do you think I should create two separate bug reports?

I tested your file on osx and it works for me using vtdec too, 

tested with gstreamer 1.12 compiled from source,

Interesting. I’ll tro to build 1.12 (the version I tested was git master).

I applyed the patches here in my build:

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

but I don't think they could make any difference,

I think you can use the official binaries

Nicola

Best regards

Jérôme Laheurte

_______________________________________________
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

[Jérôme Laheurte-3]

Le 19 oct. 2017 à 10:41, Jérôme Laheurte <[hidden email]> a écrit :

Le 19 oct. 2017 à 09:39, Mailing List SVR <[hidden email]> a écrit :

Il 16/10/2017 19:41, Jérôme Laheurte ha scritto:

Le 15 oct. 2017 à 19:07, Mailing List SVR <[hidden email]> a écrit :

adding the queue and replacing vtdec with avdec_h264 works for me on linux, so the problem seems related to vtdec, I don't have a mac available to test with vtdec now,

Indeed, same behavior on mac OS. Removing the queue blocks the pipeline before it can even start though, which doesn’t seem normal. On to bugzilla… Do you think I should create two separate bug reports?

I tested your file on osx and it works for me using vtdec too, 

tested with gstreamer 1.12 compiled from source,

Interesting. I’ll tro to build 1.12 (the version I tested was git master).

Nope. I tried both 1.12.0 and master on three different Macs, running macOS 10.12.6 and 10.11.6. The only combination that doesn’t hang is 10.11.6 with avdec_h264 (both master and 1.12.0). What version of macOS did you test this on ?

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Mailing List SVR]

Il 29/10/2017 16:26, Jérôme Laheurte ha scritto:

Le 19 oct. 2017 à 10:41, Jérôme Laheurte <[hidden email]> a écrit :

Le 19 oct. 2017 à 09:39, Mailing List SVR <[hidden email]> a écrit :

Il 16/10/2017 19:41, Jérôme Laheurte ha scritto:

Le 15 oct. 2017 à 19:07, Mailing List SVR <[hidden email]> a écrit :

adding the queue and replacing vtdec with avdec_h264 works for me on linux, so the problem seems related to vtdec, I don't have a mac available to test with vtdec now,

Indeed, same behavior on mac OS. Removing the queue blocks the pipeline before it can even start though, which doesn’t seem normal. On to bugzilla… Do you think I should create two separate bug reports?

I tested your file on osx and it works for me using vtdec too, 

tested with gstreamer 1.12 compiled from source,

Interesting. I’ll tro to build 1.12 (the version I tested was git master).

Nope. I tried both 1.12.0 and master on three different Macs, running macOS 10.12.6 and 10.11.6. The only combination that doesn’t hang is 10.11.6 with avdec_h264 (both master and 1.12.0). What version of macOS did you test this on ?

the screen capture here

http://94.177.162.225/temp/screen_capture.mkv

should answer to your questions,

Nicola

_______________________________________________
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

[Jérôme Laheurte-3]

Le 3 nov. 2017 à 22:22, Mailing List SVR <[hidden email]> a écrit :

the screen capture here 

http://94.177.162.225/temp/screen_capture.mkv

should answer to your questions,

OK Sierra on recent hardware then. I’m reluctant to open a bug report for something I’m the only one reproducing, although on different hardware and OS, and I don’t even really know which component is responsible… I think I’ll go on working on multiple subtext support using the one combination that works for me and hope it will magically fix my issues. Thanks.

Jérôme Laheurte

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel