[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xine-devel
Subject:    Re: [xine-devel] Re: [xine-cvs] CVS: xine-lib/src/liba52 xine_decoder.c,1.61,1.62
From:       James Courtier-Dutton <James () superbug ! demon ! co ! uk>
Date:       2003-11-17 15:16:42
[Download RAW message or body]

Michael Roitzsch wrote:
> Hi Miguel, Hi James,
> 
> 
>>>Although the DVD A52 header contains number of A52 frames, and also
>>>frame number within this PACK that the PTS applies to, we only need
>>>the frame number within this PACK info to do our job, so we ignore
>>>the number of A52 frames.
>>
>>if that was your intention i guess you mixed both variables and used
>>the wrong one (iirc).

If you think about this more, you will see that one can use either 
variable. I just choose the first one. decoder_info[1]
If info[1]=1, PTS =  PTS for the a52 frame that starts in this fifo 
block. (aka.this a52 frame)
If info[2]=2, PTS = PTS for this a52 frame, and PTS=0 for next a52 frame.

Alternatively, I could have stored the PTS value, and just applied it to 
the a52_frame when the sync code reached offset decoder_info[2].

> 
> 
> I think so too. If the comment in demux_mpeg_block.c is correct, we are 
> currently using the number of frames. Problem is, when I looked at the 
> other number, it seemed to be some kind of offset into the packet 
> rather than a simple index.
> 
> Next problem is that not all demuxers that can emit BUF_AUDIO_A52 set 
> the decoder_info to something A52 decoder expects.
> 
> Michael
> 

I have recently checked in a new explanation of what the values do into 
demux_mpeg_block.c

I think it is a more accurate explanation.

I have been thinking about the possiblility of moving liba52 sync code 
into the demuxer. Just forcing the demuxer to always output complete A52 
frames and deal with the PTS value in the demuxer instead.
One reason for this is that the demux_ts.c would benefit from this 
approach because most DVB streams with A52 audio in them will need to 
have more detection code in them, and this detection code would be very 
similar to the re-sync code in liba52, so to save on duplicated code, I 
would think that moving liba52 re-sync code into the demuxers might help.

Cheers
James





-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
_______________________________________________
xine-devel mailing list
xine-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xine-devel
[prev in list] [next in list] [prev in thread] [next in thread]