Can't play MPEG TS file recorded in Argus (1 Viewer)

[meesham]

MediaPortal Version: 1.2 Beta
MediaPortal Skin: StreamedMP
Windows Version: Windows 7 Pro x64
CPU Type: AMD Athlon64 X2 4850e
HDD: Samsung 1TB
Memory: 4GB PC6400 DDR2
Motherboard: Gigabyte GA-MA78GM-S2H
Video Card: Saphire ATI Radeon HD 4550 (Passive)
Video Card Driver: Catalyst 9.4
Sound Card:
Sound Card AC3:
Sound Card Driver:
1. TV Card: Hauppauge WinTV-HVR-2200
1. TV Card Type: DVB-T, DVB-C
1. TV Card Driver:
2. TV Card: Hauppauge TD500
2. TV Card Type: DVB-T
2. TV Card Driver:
3. TV Card: Technotrend Budget C-1501
3. TV Card Type: DVB-C (with CI)
3. TV Card Driver:
4. TV Card:
4. TV Card Type:
4. TV Card Driver:
MPEG2 Video Codec: MPC - MPEG-2 Video Decoder (Gabest)
MPEG2 Audio Codec: MPC - MPA Decoder Filter
h.264 Video Codec: PowerDVD8
Satelite/CableTV Provider:
HTPC Case: Antec NSK2480B
Cooling: Scyth Mini Ninja
Power Supply: EarthWatts 380W
Remote: Philips SRM5100
TV: Sony Bravia 46"
TV - HTPC Connection: HDMI

NB: I've done some testing and this is also an issue in 1.1.3

I've been using 4therecord and Argus as a TV Server replacement for a couple of months now with my DVB-T cards and it has been working perfectly, I can view live TV streams and recorded TS files without a problem (x264 video). In the past couple of days I've added a DVB-C card with a CI & CAM to view content off my cable TV subscription, which is MPEG2 video. I can record TV fine and view it in VLC and MPC-HC, but when I try to view the TS file in MediaPortal I just get a black screen. I've viewed the graph and it doesn't seem to load a video decoder, but I can't figure out why. I've checked the graph when playing a TS file in MPC-HC and it's using the exact codecs that I've set under TV Codecs in the Codecs and Renderer in the MP Config. I've tried to see if the MediaPortal TV Server has better luck but unfortunately I couldn't get my CAM working properly with it. The exact same problem happens if I browse to the TS file using "Videos", but if I rename the file extension to mkv it works correctly with the Haali splitter.

I've attached some logs of trying to view a video, as well as a graph taken when viewing the video in MPC-HC. I can't quite figure out what's going wrong, in the logs it seems like TSReader is detecting all the streams correctly but can't find the correct start point in the file. EDIT: If you'd like to see the sample I tested with please send me a PM, I've removed the link so that it doesn't use up my webhosting quota.

Any help or pointers in the right direction would be greatly appreciated.

 

[mm1352000]

Hi meesham

In the past couple of days I've added a DVB-C card with a CI & CAM to view content off my cable TV subscription, which is MPEG2 video. I can record TV fine and view it in VLC and MPC-HC, but when I try to view the TS file in MediaPortal I just get a black screen. I've viewed the graph and it doesn't seem to load a video decoder, but I can't figure out why. I've checked the graph when playing a TS file in MPC-HC and it's using the exact codecs that I've set under TV Codecs in the Codecs and Renderer in the MP Config.

I have downloaded the sample and I'm also unable to play it. According to the code, the video is not valid. I'm still trying to figure out exactly why that is. I'll try and get back to you within the next hour, but no guarantees...

I've tried to see if the MediaPortal TV Server has better luck but unfortunately I couldn't get my CAM working properly with it.

What was wrong?

mm

 

[Paranoid Delusion]

This file plays fine in WMP11, looks like tsreader is having a problem reading it

 

[mm1352000]

Right, found the problem. The issue is that the PCR packets are all marked as scrambled. PCR stands for Programme Clock Reference - PCR packets hold information that is absolutely critical for decoding the stream. TsReader ignores any scrambled packets, which results in the PCR packets in your sample being thrown away ==> stream can't be viewed. Was the recording taken from an encrypted channel?

 

[Owlsroost]

I assume the other splitters play it OK because they ignore the PCR (you only really need the PTS/DTS to decode and A/V sync the streams - the PCR is basically there to allow the receiver to sync it's local clock to the broadcasters version, but TsReader - quite reasonably - uses it as a reference timebase, as far as I remember).

I wonder if the PCR packets are really still scrambled or just flagged as such ?

I'm doing some mods to TsReader at the moment (to fix FFDShow sync problems, so I've been doing a bit of delving into the timestamp handling) - I could try and see if it's possible to get TsReader play the stream with a bit of hacking, if it would help ?

Tony

 

[mm1352000]

Hi Tony

Thanks for the insight!
MP plays the sample absolutely perfectly if you force TsReader to ignore the fact that the scrambled bits are set on all the PCR packet headers (so that they're not thrown away) - it is a one line hack. So to be very clear, the PCR packets themselves don't seem to be scrambled, but the header says they are. As you say, TsReader can't (or maybe doesn't???) demux the stream without having a valid unscrambled reference from the PCR to start with. I was wondering whether it is actually legal (according to MPEG standards) to scramble the PCR info. I know it is illegal to scramble the PSI (PMT, PAT etc.), but the PCR is a grey territory for me - I don't know enough about anything more "granular" than services...

mm

 

[Owlsroost]

I don't know if it is 'legal' to scramble the PCR data (but since there is flag to tell you, I guess it's a possibility - and cable systems are usually 'closed' so I guess they can do what they like ?).

Maybe the TsReader fix/solution is to try and sanity check the PCR data to work out if it really is scrambled ? - if the PCR values increase by roughly the same amount each packet and they roughly match 'real' time (ignoring the PCR rollover problem), then assume they are probably OK to use ?

Tony

 

[mm1352000]

That solution sounds okay to me from what little I know about this stuff. I would be out of my depth when trying to implement such a solution though. Ignoring that for the moment, is it possible that the problem is a CAM firmware or even tuner driver issue. I'm thinking of a situation where the CAM does actually descramble the PCR as it descrambles the rest of "the stream" - it just "forgets" to unset the scrambled bits on the PCR packet headers. Perhaps unlikely? As I say, I'm on the edge of territory where I can say anything with any sort of confidence.

mm

 

[Owlsroost]

It's quite possible the CAM isn't doing exactly what it's supposed to do, but trying to get the supplier to fix it might be hard.....

I'm willing to have a go at the fix I suggested (probably sometime next week) if you think it's worth it ?

Tony

 

[mm1352000]

It's quite possible the CAM isn't doing exactly what it's supposed to do, but trying to get the supplier to fix it might be hard.....

If the OP is using the latest firmware then I fully agree.

I'm willing to have a go at the fix I suggested (probably sometime next week) if you think it's worth it ?

I've never seen an issue quite like this before, but if you have time and the fix makes TsReader more robust then I can't see any reason not to do it. A cursory glance through the code suggests PCR is only really needed in relation to subtitles, but I could be completely wrong. Tourettes might be able to say more than me.

I'm off to bed now - 3:30am - but one more quick FYI: my hack-fix was to comment out line 805 of DeMultiplexer.cpp (in OnTsPacket()).

Best regards,
mm