Marcus Metzler wrote:
So the AC3 problem should be fixed in CorrectStreamNumber, which it isFor my case its not. Something is still wrong somewhere, I don't know what yet. The patch I did to mpeg.c allows me to use the software ac3 decoder. This patch may very well be an introduced bug to cancel out a bug which I can't find yet.
by the latest patch and nowhere else.
I am in Australia, where broadcasts are transmitted in the DVB format. For my case ip->cid is already 0xbd for AC3, 0xc0 for MPEG2 audio, and 0xe0 for video when CorrectStreamNumber is called (I only run it for a short while so I may very well be wrong here)..
The original function replaces all audio with 0xc0 (hence everything calls the software mpeg decoder), but the patch in DVB v3.2 just sets ip->cid to the same original value (which is better as even if/when the original value is wrong, the new CorrectStreamNumber will hopefully set it correctly).
AC3 passthru to an external AV receiver may work just by fixing up CorrectStreamNumber (I don't know as I don't have a AV receiver), but software decoding doesn't work, mythfrontend crashes on my machine at ScanStreams.
Just found out that in ScanStreams, the line:
AVCodec *codec = avcodec_find_decoder(enc->codec_id);
evals to nothing as enc->codec_id = 86021 which is 0x15005 which is CODEC_ID_DTS. (incidently I couldn't register the DTS codec). I am tempted to just swap the order of CODEC_ID_DTS and CODEC_ID_AC3 in avcodec.h and see if it works. At the moment trying to find out where 0x15005 comes from.
My apologies for the misconceptions in the A52/AC3 specs... :(
Regards.
_______________________________________________ mythtv-dev mailing list [EMAIL PROTECTED] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
