[mythtv] [PATCH] Big DVB Patch V3.5 - MPEG TS

Jesper Sörensen jesper at datapartner.se
Tue Jan 11 10:38:04 EST 2005


Taylor Jacob wrote:

>>-          siparser.cpp and dvbrecorder.cpp now insert *all* descriptors
>>from the PMT, not just the first
>>    
>>
>
>I agree this needs to be done at some point.
>  
>

Yeah, the current descriptor handling is kinda quick and dirty. I 
haven't analyzed the patch that deeply, but I don't think it is safe. I 
tried using dynamically allocated memory at first too, but since we are 
storing it inside a QT object which gets passed around and copied and 
what not, we end up with several copies of the object which all point to 
the same memory. When the destructors are called, the first one will 
destroy the data and the other objects are left with undefined data at 
best and probably a segfault.

I think we should create a new "Descriptor" object which can be stored 
in a QValueList DescriptorList or something. That object then needs to 
ensure that if the object is cloned, the data is cloned as well. Opinions?

>>-          mpegts.c looks for AC3 data in the private stream, and then
>>treats it as AC3 data
>>    
>>
>
>OK.. After staring at your patch I finally understand what is going on here.. I
>am not going to apply this because it hacks up the ffmpeg code and that would
>probbably make it harder for Issac to merge in.. The problem is that your AC3
>data comes as PrivateData type 0x06 in the PMT with an AC3 descriptor.. This is
>getting re-written just the same in the stripped TS that we save.. What needs to
>happen is that anything AC3 needs to be written as stream type 0x81 in the PMT..
>This is of course a private stream type, but FFMPeg only expects AC3 there.. All
>of the DVB-S services in North America use 0x81 for AC3, as as as ATSC.. Hence
>me never seeing a problem here..
>  
>

As you might know the only AC3 I've got is also on stream type = 6 
[private data] with an AC3 descriptor. 0x81 doesn't seem to be used for 
AC3 in this part of the world. I'm a bit scared of the day when I'll 
accidentally be "listening" to an EPG or some other non-AC3 data through 
the surround system. The speakers might even take some punishment if you 
have it on loud are are not quick enough to turn it off, and the drivers 
are not cheap so it would suck big time if that happened. :-)

So, if ffmpeg assumes everything on 0x81 is AC3, we should probably 
rewrite that type to something safer (unless it really is AC3), or at 
least drop the stream. Maybe this too could somehow be solved with the 
dtv_privatetypes mapping table?

>You can look at the CreatePMT() in dvbrecorder.cpp code and its possible
>changing the one line where (*es).Orig_Type is written to the PMT to something
>like this.
>
>if ((*es).Type == ES_TYPE_AUDIO_AC3)
>    pmt[p++] = 0x81;
>else
>    pmt[p++] = (*es).Orig_Type;
>
>Give this a shot and let me know if this solves your issues..
>
>I personally don't like always using the 0x81 descriptor for AC3 audio since its
>a private type, but it seems to be pretty standardly accepted.  Mplayer and Xine
>are ok with it, as well as ffmpeg, plus this doesn't change ffmpeg which is
>probbably a plus.
>
>I am not going to put this snippet into my codebase unless Jesper wants it in,
>and you let me know it works..
>  
>

I think I would prefer:

    pmt[p++] = (*es).Type == ES_TYPE_AUDIO_AC3 ? 0x81 : (*es).Orig_Type;

but maybe that's just me... :)



More information about the mythtv-dev mailing list