Hi all,
Andrew here (mpeg2enc author).
> Well, I thought so too at first.
>
> But look at the "q=" lines! If you're seeing "q=18" or so then
> there are still issues to be resolved.
IF Steven and I are currently using the same test sample then the high q
values (and rotten quality) turned out to be 'correct'. The sample is very
noisy and also as some H-sync issues which mean that at the (quite low)
bit-rate specified the quantisation level is reasonable. Some of the
artefacts are in fact already present in the original MJPEG file.
However, if you spot any 'oddities' or unexpectedly bad encoding do drop me a
line! Better still your source material and encoding pipeline commands
someplace I can download them so I can reproduce whats going on. I'm
currently a bit 'handicapped' in that I don't have any working video capture.
LML33 support seems to have died in recent 2.6 kernels and I appear to have
lent someone my old Philips SAA7134 reference board which I used to use for
Software-MJPEG capture (I used to work for Philips).
Anyone got a recommendation for an inexpensive analog capture card that works
well with mjpegtools?
cheers,
Andrew
--
Dr Andrew Stevens
Erdingerstrasse 23
85464 Neufinsing
Germany
Home: +49 8121 883672
Mobile: +49 173 5397553
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users
