[Webkit-unassigned] [Bug 120482] New: [GStreamer] - Playing 2 mpeg2ts videos from Apache Server causes lockup

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=120482

           Summary: [GStreamer] - Playing 2 mpeg2ts videos from Apache
                    Server causes lockup
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: PC
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: Normal
          Priority: P2
         Component: Media Elements
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: lori at rkymtnhi.com
                CC: pnormand at igalia.com


I see playback stall when attempting to playback two videos simultaneously.  I am using GStreamer with SoupHttpSrc rather than WebkitWebSource.  I believe the issue is related to the buffering and state transitions initiated by Queue2 GStreamer element which is added by UriDecodeBin to GStreamer Playbin.  I do not see this issue when using WebKitWebSource because there is no Queue2 element present and hence no buffering and no need to pause/resume. 

It appears from the log messages that the autoaudiosink1-actual-sink-alsa element fails to complete an asynchronous state transition from PLAYING to PAUSED.  Since the state transition never complete, the video stalls because MediaPlayerPrivateGStreamer::updateStates() sees that there is an async state transition in progress.  

I sometimes see this issue when there is only one video element (one MediaPlayerPrivateGStreamer) but it happens every time when there are two players.  It appears related to timing because adjusting log message levels can affect the frequency at which the issue occurs or how soon it happens when playing back.  

I tried to create a simple GStreamer program to try and reproduce the issue. The program created two pipelines and initiated a state change from paused to playing, back and forth, every 5 seconds.  I was unable to reproduce the issue using just GStreamer.  

I have tried this scenario with another WebServer and I do not see the issue.  If I turn on buffering log messages, it appears that Queue2 is being under run, initiating all the state transitions.

I have tweaked log levels in order to produce a somewhat concise log which I think shows the problem.  If you look at fail.log (see attachment), prior to lock up, you will see this message: "child 'autoaudiosink0-actual-sink-alsa' is changing state asynchronously to PAUSED".  From additional runs that I have done and various logging combinations I have tried, I suspect that the alsasink element does not transition state for some reason. 

I will attach the *.png which shows the pipeline elements.

I will also attempt to attach the actual mpeg2 ts file.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.