Start and end time -25:-49:-45 on PCH, but looks OK on PC client

[mvallevand]

TSMuXer does fix it, and mpeg2repair certainly sees temporal problems but what I see interesting when I play it is this

Code:

2009-09-08 21:55:36.707    VERBOSE    [7]    First PTS is: 4276800000
2009-09-08 21:55:36.814    VERBOSE    [7]    mvpVideoDuration: -95221.4379444444

Clearly the duration should not be a negative number.

Martin

[sub]

Yeah, the TS duration logic for the MVP server isnt very sophisticated, and isnt liking the last timestamp being greater than the first time stamp, which results in a negative duration. I know how to cope with this, and do it for PC playback, but need to add similar (more complex) logic to the MVP server.

I've been busy with work stuff today, so havnt had a chance to test this file yet.

[steveum]

I see this problem too occasionally on HD QAM recordings. I usually use videoredo to fix it when it occurs.

[mvallevand]

Yeah, the TS duration logic for the MVP server isnt very sophisticated, and isnt liking the last timestamp being greater than the first time stamp, which results in a negative duration. I know how to cope with this, and do it for PC playback, but need to add similar (more complex) logic to the MVP server.

I've been busy with work stuff today, so havnt had a chance to test this file yet.

If you ever have time to look at it, this one reports a bad one second length on the PCH and it is fine on the PC. It's from a Topfield receiver, which I always wondered if it was supported by GBPVR.

http://www.toppy.org.uk/~bellissimo/Test.ts

Martin

[sub]

Attached is an updated PVRX2.exe that has better handling of discontinuous PCR clocks in the transport stream, and reports the correct duration in Sheik's sample file.

[sub]

If you ever have time to look at it, this one reports a bad one second length on the PCH and it is fine on the PC. It's from a Topfield receiver, which I always wondered if it was supported by GBPVR.

http://www.toppy.org.uk/~bellissimo/Test.ts

Martin

This file will still not report the correct duration though, because it is not 188 byte packet aligned, like you'd get from GB-PVR recordings. (ie, it doesnt start with 0x47 as the first byte)

[mvallevand]

Thanks, four of five of my pending "problem" files are okay now. Sorry the file that played on the PC was test.ts which was my tsMuxer'd copy of the Topfield.ts. There is some crap meta data at the beginning of the file which explains some of the issues with these Topfield files. Cutting off the meta data does fix it.

I didn't know about the 0x47 logic, I will watch for this now too.

Martin

[Sheik Yerbouti]

Attached is an updated PVRX2.exe that has better handling of discontinuous PCR clocks in the transport stream, and reports the correct duration in Sheik's sample file.

Great, seems to work perfectly here. Thanks!

[Sheik Yerbouti]

Hmmm, I found out that some files still give problems. This time the end time is right, but when I skip gbpvr goes to the right place but the timeline suggests it's at the end of the file. When I do the same skipping with gbpvr on my PC it works fine. The logs show the start of a file, skipping 18 minutes (which currupts the time line, but goes to the right spot) and skipping 1 minute (which ends the playback).

Chris

[mvallevand]

Because of the huge change in the PTS after the first jump I would guess the file has a "bad" timeline. My guess is TsMuxeR might fix it.

I think I have posted before that broadcaster can just append TS streams because their broadcast only go in one direction. For these, files applications will either need fixed streams or to create an index. I prefer indexing myself. I offered a wishlist for sub to create partial streams when the pts changes, but if I remember he said that wasn't possible.

Martin