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...
_______________________________________________
Video4linux-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/video4linux-list
