MP Refusing to use ffdshow for TV (1 Viewer)

[tourettes]

Tried tourette's patched tsreader.ax and it doesn't atleast work for mpeg2 -> mpeg4 avc switches. After channel change you just get black picture. And following loglines:
2008-07-29 17:27:31.296875 [Debug][MPMain]: TSReaderPlayer: waiting for vmr9 connection
2008-07-29 17:27:31.500000 [Debug][MPMain]: TSReaderPlayer: no vmr9 connection. Maybe we have a radio recording but expect video too so we suppose it's ok.

With same tsreader.ax the ATI MPEG Decoder works (from ATI AVIVO package).

From IRC "[17:26] <@tontsa> but it shows for mpeg4 video mpeg2"

So most likely the TsReader bug that causes mpeg4 to be reported as mpeg2 needs to be solved before we can remove the ffdshow from blacklisted codecs.

 

[pvkleeff]

Tried tourette's patched tsreader.ax and it doesn't atleast work for mpeg2 -> mpeg4 avc switches. After channel change you just get black picture. And following loglines:
2008-07-29 17:27:31.296875 [Debug][MPMain]: TSReaderPlayer: waiting for vmr9 connection
2008-07-29 17:27:31.500000 [Debug][MPMain]: TSReaderPlayer: no vmr9 connection. Maybe we have a radio recording but expect video too so we suppose it's ok.

With same tsreader.ax the ATI MPEG Decoder works (from ATI AVIVO package).

From IRC "[17:26] <@tontsa> but it shows for mpeg4 video mpeg2"

So most likely the TsReader bug that causes mpeg4 to be reported as mpeg2 needs to be solved before we can remove the ffdshow from blacklisted codecs.

The same issue is there with the MPC-HC (standalone) codec as well for MPEG4. Despite the change in the dynamic video pin-out this codec refuses to play H264 ts files.

 

[xvffx]

If someone has the HD & SD channels (both in MPEG2 format) it would be nice to see if we still need that ffdshow blacklisting in TsReader as the dynamic output pin change has been introduced. It could fix the issue we had previously with ffdshow. Maybe its not as robust as for example Cyberlink when it comes to the stream analysis (or maybe its not even doing it at all and relies completely on the source filters information).

Im not sure if its related

but I have do have ffdshow (libmepg2) with HD (mpeg2) TS in streaming with no issues.. heck its the best codec Im using with vista (business) so no MS Codec

is this a old issue and have been fixed ?

thanks

Vff

 

[tourettes]

If someone has the HD & SD channels (both in MPEG2 format) it would be nice to see if we still need that ffdshow blacklisting in TsReader as the dynamic output pin change has been introduced. It could fix the issue we had previously with ffdshow. Maybe its not as robust as for example Cyberlink when it comes to the stream analysis (or maybe its not even doing it at all and relies completely on the source filters information).

Im not sure if its related

but I have do have ffdshow (libmepg2) with HD (mpeg2) TS in streaming with no issues.. heck its the best codec Im using with vista (business) so no MS Codec

is this a old issue and have been fixed ?

If you look the graph more closely you see that Core CC filter is between ffdshow and TsReader. Thats why the ffdshow is not blacklisted as TsReader is only checking the next filter its connected and usualy the TsReader is connected directly to the video decoder.

 

[xvffx]

heres a new graph without anything between ts and ffdshow

btw.. using the ffdshow tryout june 22 2008. maybe things are fixed ?

thanks

Vff

 

[tourettes]

heres a new graph without anything between ts and ffdshow

btw.. using the ffdshow tryout june 22 2008. maybe things are fixed ?

No changes are done to TsReader, so the blocking code is still there. I think is connecting to ffdshow as your ffdshow filter's name is ending with the "0001". So the basic string comparision is just failing and allowing the ffdshow to be used.