On Sun, Mar 30, 2008 at 01:53:18PM +0200, Michael Niedermayer wrote: > On Sun, Mar 30, 2008 at 12:36:30PM +0100, Bartlomiej Wolowiec wrote: > > On niedziela, 30 marca 2008, Michael Niedermayer wrote: > > > On Sun, Mar 30, 2008 at 03:16:03AM +0200, Michael Niedermayer wrote: > [...] > > > Also what was the exact reason that ff_combine_frame() wasnt used? > > > > > > > > > [...] > > > > Perfect, it's better that there are no timestamps in dependant frames... > > > I don't know abilities of ff_combine_frame so good, so I don't know if > > there > > is a simple method to read the whole header of the next frame. > > The header should just be there in the buffer with ff_combine_frame(). > Anyway what i meant was that i _think_ the current aac/ac3 parser could be > simplified by using ff_combine_frame(). > The advanatges of ff_combine_frame() being that it takes care of the too much > read header and doesnt by itself force a unneeded copy.
Note, to add the header into the buffer calling ff_combine_frame() with END_NOT_FOUND and a smaller buffer size should work. After its in the buffer you just run the header decoder thing over the header and when you know the final frame size you call ff_combine_frame with appropriate next value. Anyway iam not insisting on you changing the current aac/ac3 parser to use ff_combine_frame() But what you will end up implementing will be quite similar in functionality to ff_combine_frame() [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If a bugfix only changes things apparently unrelated to the bug with no further explanation, that is a good sign that the bugfix is wrong.
signature.asc
Description: Digital signature
_______________________________________________ FFmpeg-soc mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
