Zapping, RTSP improvements ( test plz ). (1 Viewer)

[Owlsroost]

I have also been fighting with a/v sync problems in MP (only TV) for a very long time, but the other way round (sound haste on some channels esp. with AC3 track). Today I just gave ReClock as audio device in TV-Setup a chance again (in the past this did not work very well on zapping) and now this works very smooth and it seems the A/V sync problems with MP TV are gone. Not sure if you are on XP but if so worth a try.

In my case, using ReClock for TV makes the channel-change issue worse - presumably because ReClock has a high latency (it uses a sound buffer of up to 500mS on the standard settings). If I skip back in the timeshift buffer, ReClock works very well, and improves the overall viewing experience by removing most of the periodic frame skips/repeats.

I'm running Vista32 with EVR renderer - current ReClock versions (i.e. 1.8.3.4) work fine with EVR & DXVA etc

Tony

 

[sdf]

Ambass
for the analog problem,
here are my logs and a .ts recording from analog source
thank you, sdf

 

[Lbr_Lion]

After some period of time channel switching gets very slow

Hi Ambass,

After a certain period of time (approx. 30 minutes) watching a channel with the improved files, zapping gets very slow (few minutes, or even no video or audio at all). With SVN 21720 this does not occur.

I looked in the log files and see that in the evr.log a lot of lines occur with "dangerous and unlikely time to schedule" at the moment I changed from channel.

21-02-2009 15:11:58.650 [a50]OnClockPause
21-02-2009 15:11:58.662 [910]Should not be processing data in pause mode
21-02-2009 15:11:59.799 [988]Flushing: size=0
21-02-2009 15:11:59.806 [a50]OnClockRestart
21-02-2009 15:12:00.655 [7d4]dangerous and unlikely time to schedule [0B534A68]: 1490252208. scheduled time: 1498653264, now: 8401056
21-02-2009 15:12:00.656 [988]dangerous and unlikely time to schedule [0B534A68]: 1490251728. scheduled time: 1498653264, now: 8401536
21-02-2009 15:12:00.658 [7d4]dangerous and unlikely time to schedule [0B534B10]: 1490622769. scheduled time: 1499053264, now: 8430495
21-02-2009 15:12:00.659 [988]dangerous and unlikely time to schedule [0B534A68]: 1490222229. scheduled time: 1498653264, now: 8431035

Log files attached are with and without the improved files.

 

[tourettes]

I can give you tip how to produce this error.

Use FFDShow as MPEG2-decoder and Cyberlink as H264-decoder.

Start a HDTV-channel first, switch to a SD-channel after that. You'll get a black screen, only audio runs.

If you start a SD-channel first and than switch to a HD-channel and again switch back to a SD-channel, everything works fine.

If FFDShow is started first, channel switching works fine between SD and HD. If a HD channel is selected on the first start, SD-channels won't be displayed (combination FFDShow and Cyberlink).

FFDShow is my first choice for MPEG2 because you can force NV12-output and this activates the best hardware deinterlacing available on my Radeon 3200 without any flicker.

Currently TsReader blocks ffdshow usage as MPEG2 decoder, so no wonder it gives a black screen I would assume that it works if either:

1) directshow builds the graph with different MPEG2 codec in the graph
2) ffdshow filter name changes (ffdshow sometimes seems to use 001 as the end)

...so, this is not a right way to reproduce the issue (TsReader needs to be fixed in order to allow ffdshow used as MPEG2 codec and thats why it is blacklisted).

 

[Ambass]

Hi Ambass,

After a certain period of time (approx. 30 minutes) watching a channel with the improved files, zapping gets very slow (few minutes, or even no video or audio at all). With SVN 21720 this does not occur.

I looked in the log files and see that in the evr.log a lot of lines occur with "dangerous and unlikely time to schedule" at the moment I changed from channel.

21-02-2009 15:11:58.650 [a50]OnClockPause
21-02-2009 15:11:58.662 [910]Should not be processing data in pause mode
21-02-2009 15:11:59.799 [988]Flushing: size=0
21-02-2009 15:11:59.806 [a50]OnClockRestart
21-02-2009 15:12:00.655 [7d4]dangerous and unlikely time to schedule [0B534A68]: 1490252208. scheduled time: 1498653264, now: 8401056
21-02-2009 15:12:00.656 [988]dangerous and unlikely time to schedule [0B534A68]: 1490251728. scheduled time: 1498653264, now: 8401536
21-02-2009 15:12:00.658 [7d4]dangerous and unlikely time to schedule [0B534B10]: 1490622769. scheduled time: 1499053264, now: 8430495
21-02-2009 15:12:00.659 [988]dangerous and unlikely time to schedule [0B534A68]: 1490222229. scheduled time: 1498653264, now: 8431035

Log files attached are with and without the improved files.

There is effectively a problem when compensation takes abnormal big negative value ( ie -19 secs ).
I've also seen you probably run the original TvPlugin. (plz check)

Could you try the attached TsReader.

Edit :

Could you also send a small ts recording of the channels that shows only "I" frames in TsReader and set the same timestamp for all the frames !!!!! There is a frame info decoding problem.

( Ex : Video Samples : 7, First : 31.002, Last : 31.002 GOP start : 31.002 )

 

[Owlsroost]

@Owlsroost

Probably due to filter latency. Have you tried with other audio decoder ?

Attach logs plz.

Logs attached of a few minutes of channel zapping (FFDshow audio decoder, default DirectShow audio renderer)

There were a few instances of small A/V sync errors, but nothing major so the logs might not be that useful. If I get a major error happen in the future I'll try and log it.

If I use ReClock, I can easily get major sync errors after channel changes, but since ReClock isn't really meant to be used in this situation I'm not that surprised or concerned

Tony

 

[Lbr_Lion]

Hi Ambass,

After a certain period of time (approx. 30 minutes) watching a channel with the improved files, zapping gets very slow (few minutes, or even no video or audio at all). With SVN 21720 this does not occur.

I looked in the log files and see that in the evr.log a lot of lines occur with "dangerous and unlikely time to schedule" at the moment I changed from channel.

21-02-2009 15:11:58.650 [a50]OnClockPause
21-02-2009 15:11:58.662 [910]Should not be processing data in pause mode
21-02-2009 15:11:59.799 [988]Flushing: size=0
21-02-2009 15:11:59.806 [a50]OnClockRestart
21-02-2009 15:12:00.655 [7d4]dangerous and unlikely time to schedule [0B534A68]: 1490252208. scheduled time: 1498653264, now: 8401056
21-02-2009 15:12:00.656 [988]dangerous and unlikely time to schedule [0B534A68]: 1490251728. scheduled time: 1498653264, now: 8401536
21-02-2009 15:12:00.658 [7d4]dangerous and unlikely time to schedule [0B534B10]: 1490622769. scheduled time: 1499053264, now: 8430495
21-02-2009 15:12:00.659 [988]dangerous and unlikely time to schedule [0B534A68]: 1490222229. scheduled time: 1498653264, now: 8431035

Log files attached are with and without the improved files.

There is effectively a problem when compensation takes abnormal big negative value ( ie -19 secs ).
I've also seen you probably run the original TvPlugin. (plz check)

Could you try the attached TsReader.

Edit :

Could you also send a small ts recording of the channels that shows only "I" frames in TsReader and set the same timestamp for all the frames !!!!! There is a frame info decoding problem.

( Ex : Video Samples : 7, First : 31.002, Last : 31.002 GOP start : 31.002 )

Hi Ambass,

I checked the usage of the TVServer.dll and the improved version is used.

I tested the latest TSreader and it looks like that the compensation error is resolved. (No lines related to that anymore in the evr.log. (Did watch Live.TV for around 1 hour (log-files attached)

Please find attached also the requested .ts samples.

Regards

 

[mironicus]

Currently TsReader blocks ffdshow usage as MPEG2 decoder, so no wonder it gives a black screen I would assume that it works if either:

1) directshow builds the graph with different MPEG2 codec in the graph
2) ffdshow filter name changes (ffdshow sometimes seems to use 001 as the end)

...so, this is not a right way to reproduce the issue (TsReader needs to be fixed in order to allow ffdshow used as MPEG2 codec and thats why it is blacklisted).

Mediaportal uses FFDShow as MPEG2 Decoder on my system (and no other) - Graphedit proves it.

 

[tourettes]

Currently TsReader blocks ffdshow usage as MPEG2 decoder, so no wonder it gives a black screen I would assume that it works if either:

1) directshow builds the graph with different MPEG2 codec in the graph
2) ffdshow filter name changes (ffdshow sometimes seems to use 001 as the end)

...so, this is not a right way to reproduce the issue (TsReader needs to be fixed in order to allow ffdshow used as MPEG2 codec and thats why it is blacklisted).

Mediaportal uses FFDShow as MPEG2 Decoder on my system (and no other) - Graphedit proves it.

Please post a screen shot (most likely ffdshow is using a "different" name) as the TsReader black listing code is pretty straight forward (i.e. when format is MPEG2 and filter name is ffdshow then the pin connection is not allowed).

 

[mironicus]

There you have it. And yes, FFDShow tries to reconnect under a different name (FFDShow Video Decoder 0001) because the first one (FFDShow Video Decoder) won't work.

But you should not blacklist FFDShow in Mediaportal. Maybe this is causing the problem while switching from HD (Cyberlink) to SD (FFDhow). The connection fails in this case (tries to connect to "FFDShow Video Decoder") and then there is only a black screen.

FFDShow runs without errors and without flicker on my computer setup.

Can you give me a modified TSReader.ax without the blacklist code? Perhaps the black screen will be gone with this modification?