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

Michael Niedermayer michaelni
Mon Apr 7 19:59:31 CEST 2008


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.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Old school: Use the lowest level language in which you can solve the problem
            conveniently.
New school: Use the highest level language in which the latest supercomputer
            can solve the problem without the user falling asleep waiting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/attachments/20080407/3ab48180/attachment.pgp>



More information about the ffmpeg-cvslog mailing list