Experimental TsReader development (3 Viewers)

[Owlsroost]

Re: AW: Re: Experimental TsReader development

Does it happen if you play a .ts file locally (not via RTSP) ?

Hi,

I encouter the same probleme here on a UNC setup. As mentioned by olavm no problem with the regular TSReader.ax.

Greeting,
Zoid

Can you do a quick test using QuickSync decoder with noStopMod41 and noStopMod43 please ?

Tony

 

[Zoidberg77]

AW: Experimental TsReader development

I tried both and it's not working either, sorry.

 

[Owlsroost]

Re: AW: Experimental TsReader development

I tried both and it's not working either, sorry.

Have you tried the FFDShow versions with QuickSync decoder - Intel QuickSync Decoder - Browse /ffdshow_builds at SourceForge.net - just in case the problem is specific to the LAV implementation ?

Tony

 

[Zoidberg77]

AW: Experimental TsReader development

No, I haven't. And I'm not very eager to try, as only my productive system supports QuickSync and it's running very well right now with PDVD11 and your noStopMod44. I'm sorry, but maybe someone else will try.

Greetings

 

[olavm]

Small update: LAV QS only a problem with H264. Mpeg2 seems to work fine. Also tried ffdshow qs and got picture on h264 video and the tsreader mod. Don't know how stable ffdshow is with live tv so i'm using MS decoder on tv for now.

As Zoidberg77 said: my only QS system is the living room working system which means no friday night debugging

 

[doveman]

Just had a major TV freeze (around 20:54) which I got out of by skipping back/forward a bit and eventually it sorted itself out. Using nostopmodv44.

It's still having problems (going jerky/stuttery) now actually.

EDIT: Had to close and restart MP to fix this. Even stopping TV and restarting the channel didn't help. Actually, only seems to be an issue when something else has focus, when the render time shoots up, so probably a dshowhelper issue, not a TSreader one after all.

 

[Owlsroost]

Actually, only seems to be an issue when something else has focus, when the render time shoots up, so probably a dshowhelper issue, not a TSreader one after all.

It's not a dshowhelper issue either - when you push something into the background, you are effectively telling the windows process/thread scheduler that it's not as high a priority i.e. the process which has the focus is automatically assumed to be the one you're interested in, so it gets a priority boost etc.

I've said this before - if you want smooth, glitch-free video playback, optimise the system for that and don't use the PC for anything else when it's playing video. If you are not prepared to do that then stop complaining about performance issues....

Tony

 

[FreakyJ]

AW: Re: AW: Experimental TsReader development

hey,

some bad news The problem with the live-recording is still present... Error was ~19:57 (just have a look at the end, didn't start watching again after the stop)
but the black screen problem seems to be gone
logs attached

It's not the same problem as last time - it's just got to 'end-of-file', possibly because handling the continuity errors has used up the 'buffer' time (end of file 'time' - current 'time').

Not much can be done about that (other than blocking seeks too close to EOF) - when playing a recording, reaching EOF means it will stop, but when timeshifting it will ignore EOF (timeshifting files are assumed to be endless).

Tony

Thanks for the info
Does TsReader know when it is a live recording? If yes, it could behave like during live Tv, but I guess that is not possible, because at some point the recording will stop and TsReader has to get informed... way to much effort for such a little problem oO

But I have another question:
I have the option marked that TSReader doesn't drop discontinues but I have still little jumps in there if there is a corruption.
My question is now how does this option behave? What does the filter if it gets packets from TsReader with nonsense?!
Sure I know that the filter can't display/decode nonsense packets but maybe you have some interesting informations what the main difference is if I check this option (okay the option says it pretty much: Don't drop dicontinues, but maybe there is something more to know )

 

[Owlsroost]

Re: AW: Re: AW: Experimental TsReader development

Thanks for the info
Does TsReader know when it is a live recording? If yes, it could behave like during live Tv, but I guess that is not possible, because at some point the recording will stop and TsReader has to get informed... way to much effort for such a little problem oO

Exactly (it does know it's a live recording, but it can't assume it's endless, so it has to respond to end-of-file as normal)

But I have another question:
I have the option marked that TSReader doesn't drop discontinues but I have still little jumps in there if there is a corruption.
My question is now how does this option behave? What does the filter if it gets packets from TsReader with nonsense?!
Sure I know that the filter can't display/decode nonsense packets but maybe you have some interesting informations what the main difference is if I check this option (okay the option says it pretty much: Don't drop dicontinues, but maybe there is something more to know )

By default (option not ticked) it drops video & audio 'samples' (PES packets) which are not complete because some decoders can hang or crash if feed with corrupted data - even though all MPEG decoders are supposed to handle corrupted data properly....

If the option is ticked then everything is passed to the downstream filters - what happens then is up to how the decode filters handle corruptions.....

Tony

 

[olavm]

Did some more testing: Installed a debug version of LAV 0.44 which saves a log after each use. When trying a h264 tv stream I got a error message and MP crashed saving logs. Not sure if something can be read from this though, but here it is.

This is h264 TV with LAV 0.44 Quicksync and TSreader_nostop44