[mythtv] [patch] AC3 patches
Tim Davies
tim at opensystems.net.au
Thu Jan 27 20:25:16 EST 2005
Isaac Richards wrote:
>On Thursday 27 January 2005 07:18 pm, Tim Davies wrote:
>
>
>>>Doesn't handle ignoring the stream later on properly.
>>>
>>>
>>This is a lot better than a guaranteed segfault. It does ignore the
>>stream, but there is no need to abort everything if it can't find a
>>decoder for *one* audio track. If no audio streams are present (or
>>capable of being decoded) then subsequent code *should* deal with this.
>>A suggestion or some comments as to why it doesn't handle the streams
>>properly might help.
>>
>>
>
>Who's saying that this is limited to audio streams?
>
>
Not me, but maybe the checks (and the aborting) should be done after the
loop. Have a check that ensures that you found a (decodable) video and
audio stream, if that is what is needed. Borking if it can't deal with
one stream is silly.
Is that a better idea?
>
>
>>>>ac3-4.1 - deal with audio codec changes in avformatdecoder
>>>>
>>>>
>>>The audio codec _can't_ change for a given streamtype. The startcode of a
>>>stream in a mpeg file is different based on what codec it is. Streams
>>>returned from libavformat are enumerated by the startcode. A new codec
>>>will be given a new logical stream. If this is necessary, something's
>>>badly wrong in the ts2ps junk the dvb code is using.
>>>
>>>
>>As far as I can see, mpeg.c is not that clever. Yes, it will try and
>>put a stream with the same startcode into the same index in nb_streams.
>>It comes a little unstuck when streams disappear on a channel change,
>>and then it leaves an "empty" entry in nb_streams (but that is another
>>issue).
>>
>>
>
>Another issue completely.
>
>
>
>>The avformatdecoder.cpp code is not checking for a codec change *within*
>>a stream anyway. It is checking for a codec change when it selects a
>>different stream, and that certainly does happen. A lot!
>>
>>
>
>That patch certainly is checking for a codec change within a stream, which as
>stated, cannot happen unless the stream was badly muxed.
>
>
From autoSelectAudioTrack:
if (e->channels > minChannels)
{
currentAudioTrack = track;
wantedAudioStream = tempStream;
VERBOSE(VB_AUDIO,
QString("Auto-selecting audio track #%1 (stream
#%2).")
.arg(track + 1).arg(tempStream));
VERBOSE(VB_AUDIO,
QString("It has %1 channels and we needed at
least %2")
.arg(e->channels).arg(minChannels + 1));
AVCodecContext *e = &ic->streams[wantedAudioStream]->codec;
CheckAudioParams(e->sample_rate, e->channels, true);
return true;
}
Isn't CheckAudioParams running on what could possibly be a new stream?
Which means the codec could change, and therefore avcodec_find_decoder
and avcodec_open need to be called in CheckAudioParams? It actually has
to verify that the codec has changed, and not rely on a sample_rate or
channels change. We mostly have Dolby 2.0 which has the same channels
and sample_rate as MPEG2 audio.
>
>
>>>>ac3-4.2 - setup GUI for ac3wanted option
>>>>ac3-4.3 - make avformatdecoder auto-select AC3 (if "ac3wanted")
>>>>
>>>>
>>>Won't be applying these, I don't see a need for this option.
>>>
>>>
>>There are situations when you won't want the AC3 stream, if it is
>>available. Of the top of my head, you might have two frontends; one AC3
>>capable, and one not.
>>
>>
>
>You can't have a non-ac3 capable frontend.
>
>
>
Well some doofus might not have software AC3 enabled. Or might not want
to use it. I don't really care myself.
>>And surely if you *can* decode AC3 tracks, you want avformatdecoder to
>>select that track: otherwise what is the point? Are you suggesting that
>>it randomly selects a track, or uses the first one it finds, or what?
>>
>>
>
>It should present a list to the user, which it happens to do right now.
>
>
>
Does it? If I don't use the patch, it just uses the first track it
finds (in reverse order).
Besides, I don't want a list every time I change channels. The tracks
would change on about half the channel changes here. Surely it should
choose a preferred track, which can then be overridden (with a list or
whatever) later. This is what the set top boxes do.
Tim.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mythtv.org/pipermail/mythtv-dev/attachments/20050128/3852fbe2/attachment.htm
More information about the mythtv-dev
mailing list