On Fri, 28 Nov 2008 12:34:07 +0100 Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
On 28.11.2008 12:21, Morfsta wrote:
On Fri, Nov 28, 2008 at 11:02 AM, Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
I haven't followed this lately, but if the broadcast stream contains AC3 data in PES packets with ID 0xC0, then the problem needs to be fixed at the broadcaster - VDR merely follows the standard. Unless, of course, a bug in VDR can be pointed out...
The trouble is the broadcasters won't care about "true" standards if they're doing something that works for them and STBs. I appreciate your view, but if VDR refuses to accommodate these deviations, the big beaureaucratic broadcasters won't care and it spoils VDR for the users.
Hi Klaus,
Perhaps you are right, but the bizarre thing is that I don't see any evidence on the Internet of other set top boxes suffering from this problem. But 0xC0 is normally reserved for MPA audio right? Surely this would cause problems with other STBs? I also don't see users of other software (e.g. MythTV) having this problem, which seems a bit suspicious.
I have uploaded a VDR recording of BBC HD to megaupload if you (or anyone else) is interested in looking at it? Appreciate you might be busy with other things right now though. Otherwise, I had a look in device.c around
case 0xC0 ... 0xDF: // audio ... case 0xBD: { // private stream 1 ... case 0x80: // AC3 & DTSbut if 0xC0 is being used for audio I can't understand how this can be adjusted to permit checking for the content of AC3 data too.
I really hope someone can work this out and devise a patch even if it never becomes official.
I haven't done anything in the direction of replaying HD content so far, and I won't get myself involved in replaying PES HD material. My guess would be that as soon as VDR is completely switched to TS recording, this problem should just go away, because VDR then no longer looks at these IDs at all.
Will that mean it won't be a problem for live playback with xineliboutput either?