Improve quality of TS files produced wrt timeline (not quality of recording itself)

[jksmurf]

Thanks what I'd like is the output from the -a option, it creates a file called analyze.out or something like that.

Martin

Sorry Martin, I'm going to need some guidance on Syntax?

k.

[mvallevand]

Close, filenames with spaces need to be in quotes

-a "file name"

Martin

[jksmurf]

Close, filenames with spaces need to be in quotes

-a "file name"

Martin

aha .... it's 28M btw ... 8.5MB Zipped.

http://www.fileconvoy.com/dfl.php?id=gb5...38af4eb62a

k.

[mvallevand]

Thanks that explains it. The NMT couldn't skip once you tried to go 3278 seconds in. Just a tiny bit earlier at 3273 seconds, 23.8 GB in

Code:

Timing 3273013,2377257180
pcr 18446744073706892001 88372309432 12645108 3273048
PID Reset 349 12645161 pts 81213 0 294570000 3273048
PID 349 12645208 pts 84813 81213 3273048
pcr 18446744073707849476 88373266907 12645232 3273083
pcr 18446744073708014974 88373432405 12645253 3273090
pcr 18446744073708788280 88374205711 12645357 3273118
pcr 177263 88375146310 12645474 3273153

the very large pcr value (there are 90000 of these a second) was reset to zero. This is the value the NMT uses to determine it's timeline. If you skip there is nothing in the NMT demux mvpmcx2 can use to tell me where it is. If you play the file without skipping like a satellite viewer would, you shouldn't have any trouble. A few PVR backend rewrite these as they record, but not NextPVR.

tsMuXer should be able to rewrite these values in the timeline.

The good news is that you were concerned about the quality of the ts that NextPVR recorded and you shouldn't be

"Closing file. Processing 142.00 seconds Errors found 0"

Perfect! Not bad for a 2hr 42 minute recording.

Martin

[jksmurf]

A few PVR backend rewrite these as they record, but not NextPVR.

tsMuXer should be able to rewrite these values in the timeline.

The good news is that you were concerned about the quality of the ts that NextPVR recorded and you shouldn't be

"Closing file. Processing 142.00 seconds Errors found 0"

Perfect! Not bad for a 2hr 42 minute recording.

Martin

I'm not sure what to take out of this. Show is perfect, but don't try to skip?

Do you think that comskip replicates the skip errors?

I'll see if I can find a show where the timeline jumps to all green for you !!

[mvallevand]

I'm not sure what to take out of this. Show is perfect, but don't try to skip?

Pretty much, broadcast streams are not meant to be navigated so their timeline is not a real concern to quality.

Do you think that comskip replicates the skip errors?

When the file is demuxed with ffmpeg like comskip does it is completely different processing. writeTime can find the correct time too because it knows exactly when the timeline changes. With skipping a point of reference is required.

I'll see if I can find a show where the timeline jumps to all green for you !!

It does sounds directly related to the timeline being set to zero. mvpmcx2 could probably do a better job reporting glitches but I don't have proper samples. My hdpvr is analog so it has a good timeline based on a zero based h/w clock not what is broadcast. You'd probably get better SD with an analog component svideo capturing (pvr 150 driver and quartz.dll issues aside)

Martin

[jksmurf]

When the file is demuxed with ffmpeg like comskip does it is completely different processing. Martin

I didn't really follow a lot of that sorry, but the suggestion here is comskip is the culprit (as is manual skipping) for broadcast ts streams losing their way on the timeline?
Oddly SHORT (1/2hr, 1 hr) shows don't suffer from this, nor do ones with only 1~2 cuts.

Could sub fix the tsMuxer a bit to rewrite the the "values in the timeline"?

k.

Could I get you proper samples? Obviously if that show was perfect, no sample to be had - yet it throws an error still.

[mvallevand]

No comskip isn't the issue, the issue in that one file anyway was the timeline. Perhaps the way commercials are injected add a problem?

I'd expect short files would seem safer simply because there is less chance of encountering a reset


If you can figure out how to use this program to cut files http://www.pjdaniel.org.uk/mpeg/ I'd be able to give you the start/end packet numbers to enter. I'd like 200MB or so to do some good jumping.

Martin

[jksmurf]

If you can figure out how to use this program to cut files http://www.pjdaniel.org.uk/mpeg/ I'd be able to give you the start/end packet numbers to enter. I'd like 200MB or so to do some good jumping. Martin

Ill figure it out .... fire away with the numbers ....

[mvallevand]

Ill figure it out .... fire away with the numbers ....

Let's start small with 20MB frames 12355471 12461854

Martin