[FFmpeg-cvslog] r12758 - in?trunk/libavcodec:?aac_ac3_parser.c?aac_ac3_parser.h aac_parser.c?ac3_parser.c

[Bartlomiej Wolowiec]

On poniedzia?ek, 7 kwietnia 2008, Michael Niedermayer wrote:
> On Mon, Apr 07, 2008 at 07:55:44PM +0200, Bartlomiej Wolowiec wrote:
> > On poniedzia?ek, 7 kwietnia 2008, Michael Niedermayer wrote:
> > > On Mon, Apr 07, 2008 at 02:52:39PM +0200, Bartlomiej Wolowiec wrote:
> > > > On poniedzia?ek, 7 kwietnia 2008, Michael Niedermayer wrote:
> > > > > Explain what exactly your patch corrects.
> > > > > One bug i see is that your sync functions are off by one byte,
> > > > > loosing 1 bytes and thus returing 1 byte to late. (that is
> > > > > header_size+1)
> > > >
> > > > ok, first patch corrects a situation when in buffer there is no data,
> > > > data is not send.
> > >
> > > I dont understand you, your patch just looks wrong. What is it that the
> > > parser is feeded with as input that causes a problem?
> > > It cant send "no data".
> >
> > Maybe I'm wrong but I mean a situation when after seek parser gets frame,
> > but with 4 bytes shift. Then it sends this 4 bytes as a first frame and
> > correct frame as a second frame.
>
> That explanation makes more sense, the parser gets as input 4 bytes "junk"
> and then a valid frame, it returns these 4 bytes and then seperately the
> frame. No bug here, this behavior is correct.
> What is (possibly) buggy is
> 1. the rm demuxer for having 4 bytes junk there
> 2. the old ac3 parser for randomly discarding these 4 bytes
> 3. see below
>
>  ret: 0 st: 1 ts:1.566000 flags:1
>  ret:-5
>  ret: 0 st:-1 ts:0.460008 flags:0
> -ret: 0 st: 1 dts:0.487000 pts:0.487000 pos:191482 size:278 flags:1
> +ret: 0 st: 0 dts:0.520000 pts:0.520000 pos:191779 size:12635 flags:0
>                                                       ^^^^^^^
>
> That does not look like a incomplete previous frame.

Patch applied.
When it comes to frame size, I don't know why decoding in stream #0 is also 
disturbed.

-- 
Bartlomiej Wolowiec