Post processing filters depending on codec type (Especially TV Plugin) (1 Viewer)

[CCob]

Hi Guys,

I have been looking at adding separate post processing filters depending on the source media type. The reason I would like to do this is simple. I want to use ffdshow tryouts for Live TV SD content as it has very good deinterlace/sharpening filters (among other things).

Now I would have liked to have used ffdshow for the MPEG 2 codec, but for some reason it will not work, so I set the normal MPV Video codec and use the ffdshow raw filter within post processing filters. Now the problem with this is that I use PowerDVD 8 for H264 content so that I can utilize DXVA, but with post processing filters in place, DXVA is no longer possible.

I was looking at the source for TSReaderPlayer.cs and was thinking of adding conditions in there (or somewhere similar) on adding the post processing filters depending on if the source is MPEG 2 or H264. I am unfamiliar with DirectX programming, but from the looks of things is doesn't look like you can tell what the source video is before the graph is started. Is this assumption correct, and if so what do you think the best way would be to achieve this.

Once I have a general idea, I will get stuck in with the dirty work as supply a patch hopefully.

Thanks

 

[tourettes]

It won't be easy as you tought Currently we aren't 100% responsible the graph building (directshow is used for it). So we cannot 100% sure say how the filters should be connected.

If you want to check the issue, then BaseTSReaderPlayer.cs and TSReaderPlayer.cs are the good starting points.

So, it would require much work on MP1 and most likely wont happen for 1.0.x release. Maybe with MPII we build much more flexible graph building architechture that allows MPII / user to control the graph building more strictly.

 

[CCob]

Just detecting the source video codec type before building the graph should be sufficient I'm sure. For TS files/movies that shouldn't be to difficult since we could use something like mediainfo on the file to get the video codec then build the graph afterwards, it's the RTSP streams I think would be more of a problem (and this is the one I would really need it on) as we would need to read the stream first before building the graph.

Do you know why ffdshow doesn't work when using it as a decoder instead of a raw post processing filter? If I could get that working for MPEG2 I wouldn't need to worry about any of this then.

 

[tourettes]

Just detecting the source video codec type before building the graph should be sufficient I'm sure. For TS files/movies that shouldn't be to difficult since we could use something like mediainfo on the file to get the video codec then build the graph afterwards, it's the RTSP streams I think would be more of a problem (and this is the one I would really need it on) as we would need to read the stream first before building the graph.

That would completely change the graph building behaviour. Currently we are loading all the filters to the graph and let directshow to connect the pins. So, filter loading takes place only on startup (as it would slow down the zapping when graph is always rebuild).

Feel free to experiment with different things, but getting the graph building to work more intelligent way is not a small task at all.

Do you know why ffdshow doesn't work when using it as a decoder instead of a raw post processing filter? If I could get that working for MPEG2 I wouldn't need to worry about any of this then.

It's disabled on purpose as it had big issues earlier when zapping between MPEG4 and MPEG2 channels (could have been TsReader issue also, but no sollution was found...).

 

[tourettes]

btw. Eabin knows the most when it comes to graph building etc. Unfortunately he has been really busy for few months.

 

[CCob]

Ah I see, so the graph is built on start up and is just used over and over when playing different content. If so, then yes that is going to be much more of a headache.

 

[tourettes]

Ah I see, so the graph is built on start up and is just used over and over when playing different content. If so, then yes that is going to be much more of a headache.

And TsReader is notifying us for changes in PMT (most likely channel has been changed) and the MP is analyzing if the graph needs to rebuild (checking if audio / video formats have changed).

public void DoGraphRebuild()
private bool GraphNeedsRebuild()

 

[CCob]

So does the graph get rebuilt if say I switch from BBC One (SD MPEG2) to BBC HD (H264)?