On niedziela, 30 marca 2008, Michael Niedermayer wrote: > 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() > > [...]
Ok, now I understand... I was just thinking how to make solution similar to other solutions.. I'll try in short time to write this parser with ff_combine_frame(), but now I'll try to finish my GSoC application, because the deadline is near... -- Bartlomiej Wolowiec _______________________________________________ FFmpeg-soc mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
