Reply to thread

Message

<blockquote data-quote="nevcairiel" data-source="post: 751095" data-attributes="member: 111604">AW: Advanced Stream Switching / Graph RebuildingThats all up the splitter, of course. The interface only allows to delegate the rebuilding to the application. The splitter decides when to rebuild, and if to always stop or pause the graph, or let the player handle that as well.LAV Splitter for example will always stop the graph, because that automatically clears the buffers, and makes the switch &quot;instant&quot;, and the playback glitch is very minor.The player shoud not make any assumptions on the state of the graph when it gets the callback, and always ensure its stopped when doing graph changes.One thing i'm undecided about however. If the player gets a callback for video, and the graph is still running, then the player should stop the graph. But should it start it as well again? This could potentially cause the issue you descriped. I would rather see the splitter taking care of that, returning the graph to the playing state when its done calling all rebuild callbacks.I'll properly formulate that in the interface description.One pin can have many media types, IMHO its easier to just let the application probe pPin-&gt;GetMediaType, thats the same logic it used initially when creating the graph.I have been thinking about adding a enum value to the call though, which specifiys the type of the pin, &quot;video&quot;, &quot;audio&quot;, &quot;subtitle&quot;, &quot;unknown&quot;. That way the player can directly go into the proper routine to figure out what filters are relevant.</blockquote>

[QUOTE="nevcairiel, post: 751095, member: 111604"] [b]AW: Advanced Stream Switching / Graph Rebuilding[/b] Thats all up the splitter, of course. The interface only allows to delegate the rebuilding to the application. The splitter decides when to rebuild, and if to always stop or pause the graph, or let the player handle that as well. LAV Splitter for example will always stop the graph, because that automatically clears the buffers, and makes the switch "instant", and the playback glitch is very minor. The player shoud not make any assumptions on the state of the graph when it gets the callback, and always ensure its stopped when doing graph changes. One thing i'm undecided about however. If the player gets a callback for video, and the graph is still running, then the player should stop the graph. But should it start it as well again? This could potentially cause the issue you descriped. I would rather see the splitter taking care of that, returning the graph to the playing state when its done calling all rebuild callbacks. I'll properly formulate that in the interface description. One pin can have many media types, IMHO its easier to just let the application probe pPin->GetMediaType, thats the same logic it used initially when creating the graph. I have been thinking about adding a enum value to the call though, which specifiys the type of the pin, "video", "audio", "subtitle", "unknown". That way the player can directly go into the proper routine to figure out what filters are relevant. [/QUOTE]

Verification