On Thursday 21 December 2000 07:07, you wrote: > Andrew> [...] > Andrew> better MPEG-1 encoding with support for creating VCD compatible > Andrew> streams > > SVCD soon? In my-programming-time basic support should be very soon (all the pieces are now there). In real-time perhaps a little longer - I'm about to go on holiday for 3 weeks and then I'm changing job and moving from Oxford to Munich. This may distract me a little ;-) If I'm very lucky I might find time end of january (as long as I don't get buried in niggly take-ages-to-ping-down MPEG-2 encoding bugs like I did two weeks ago). Needless to say I have *no* objections whatsoever to anyone who wants to try to create the appropriate pre-sets for mpeg2enc and mplex while I'm diddling around trying to find someplace to live. It should mostly be a question of setting the right internal flags to the encoder and multplexer. The results might be a bit sub-optimal if there are still bugs in field-based motion compensation but it should work. I'll even email them the details I have of the format and answer the odd question by email. Aside: IMHO based on experiments with SVCD-like MPEG formats if you're encoding from broadcast sources the SVCD format is pretty marginal unless you're willing to use non-standard higher data-rates. Its just that little bit tighter than VCD and for noisy source material VCD is already rather too tight and the sub-sampling that occurs when you create VCD also helps reduce noise. Of course if you're transcoding DVD's then all is fine and dandy - if you're willing to accept the vastly increased encoding times (*lots* more motion compensation search :-() Creating index files for SVCD will take a little longer but (according to the vcdimager people) you can simply create a dummy empty one and SVCD will still play fine. > I found no info in the home page. Unwilling to toot my horn before the car is running ;-) Andrew PS If anyone out there has a bona-fide coppermine cored PIII CPU and/or PIII katmai I'd be very interested in knowing what encoding rates they achieve. (Ideally: 352x288, -r 16 -b 1550 -4 1 -2 1 -o /dev/null encoding 200 or so frames from a file containing the output of lav2yuv). I've found that the results obtained with my PIII's are embarassingly far behind my Duron. All attempts at optimisation (fiddling with loop unrollings, alignment hacks, prefetches etc) have failed since the relevant computations appear compute-bound in almost every respect. However, since my PIII's are gamma silicon (stepping 02) I'm not sure how representative the results are...
