[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:       Miguel Freitas <miguel () cetuc ! puc-rio ! br>
Date:       2003-11-17 17:35:07
[Download RAW message or body]

>>>>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.

(i guess you meant to write info[1] above, since info[2] was never used)

info[2] = 2 means that we have two a52 frames, right? i must be missing
something pretty stupid but... how do you know that the PTS belong to the
first and not to the second frame?

if the rule is "PTS is always assigned to the first header in this pack"
we don't need to inspect any info[] at all.


> 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].

that would make much more sense imho.


> 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.

i disagree, i think moving decoder specific code into demuxers is wrong.

for example, i might create a very simple container for A52 with just the
raw stream. the A52 decoder should be smart enough to do the re-sync by
itself. forcing every demuxer to do that just adds code duplication.

> 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

why?

regards,

Miguel





-------------------------------------------------------
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]