No subject

[bogus at does.not.exist.com]

from the rest of lavseq, and can be tested with a lavfi mixer filter,
so it somehow provides some functionality which can be tested without
the rest of lavseq, that's why I pushed for it. Still we're waiting
for a new patch from Sebastian, but again it's his work and it looks
like he's focusing on the TuComposer/FFmpeg testing comparison stuff
(which is also a requirement for the following work).

> >> As said, I want to use that as a base of a automatic regression test only.
> >>     
> >
> > You can run tests on your own copy.
> >   
> 
> First I have to write the tests, though. ;-)
> 
> My plan to implement the tests is, that I write, while playback &
> mixing, to a text file containing the internal dump of the player / BSS
> / mixer structures. This has to be done twice, one for original
> TuComposer, and one for AVSequencer.
> 
> Then after testing, I just compare the text files with a simple diff, I
> don't only see if it passed the tests (diff empty) but also if there's a
> regression, where it occured and what's changed.
> 
> I yesterday was busy getting the AVSequencer to pass other tests, after
> having finished the deallocation stuff, though:
> All tests with valgrind, i.e. allocation / deallocation of complete BSS,
> basic avsequencer, mixer and player does not cause a single hit anymore
> in valgrind strictest memcheck / memleak mode.
> 
> There are, however, some show-stopper bugs in the playback engine, which
> causes some TCM-files to crash and valgrind also has some minor
> complains there.
> 
> >   
> >>>> Anyway, why do you think that I'm against reviewing it? After all, the
> >>>> review process makes a) code quality better b) improves readibility
> >>>> (documentation and code) and c) fixes bugs. So again, why do you think I
> >>>> try to avoid this?
> >>>>         
> >>> How else should I interpret your refusal to send reviewable patches?
> >>>   
> >>>       
> >> Some files still change too frequently and too much in a short period,
> >> i.e. sending patches has for some parts a pretty high probability that
> >> once review is done (which can quite a bit of time) the code does not
> >> match the current progress anymore.
> >>     
> >
> > Then clearly, the code is not yet ready for review.

I see two possible threads of work which can be done regarding FFmpeg
review: the BSS definition and the mixer stuff, which are pretty
independent. And since they're big and complex I suppose they will
require a good amount of review to make them "get in shape" and make
them "committable".
   
> I expect it at least be one more month before it's ready for a
> full-featured review.
> But this shows another issue, though, I should generally be more
> communicative on that to avoid wild speculations. So thank you very much
> for addressing this issue and solving that finally. ;-)

Regards.
-- 
FFmpeg = Fantastic and Forgiving Moronic Power Extended Geek