On Sat, 19 Mar 2005, Steven M. Schultz wrote:


On Sat, 19 Mar 2005, Dik Takken wrote:

I don't know y4mdenoise yet, but is it as non-destructive as 'yuvdenoise
-f' is?

"non-destructive"? All filtering is destructive - it changes the original data. By non-destructive do you mean "not visibly undesireable"? That can be subjective - a matter of personal taste.

I meant hardly visible. Since I am looking for general processing methods that do not assume anything about the video stream (noise levels and such). Most of the time, video processing changes the way the video looks, which is undesireable when the video is already visually 'perfect'. The stream may be altered numerically, but not visibly. At least not in a way that could affect clean, high quality streams.


This makes me wonder: There is a difference between a clean, high quality stream from a human perspective and from the perspective of an encoder (in the sense that is is 'easy' to encode), is there? If there is no difference, then there is no point in talking about video processing that improves video streams numerically (for encoding), but not visibly.

This leads me to the idea to have mpeg2enc perform this sort of numerical
conditioning automatically on any input video. Maybe the default output

I don't see filtering as being the encoder's job. Keeping the encoder "simple(r)" and putting the "conditioning" into a pipeline would seem to be a better approach.

I also like it the way it is, but it has one major disadvantage: Many users lack the knowledge to process their video material in a way that allows mpeg2enc to get the most out of it. If there are general processing methods that are beneficial for *any* video stream that needs to be reduced to MPEG, it is desireable to perform such processing by default. Perhaps a section in the mpeg2enc manpage about stream conditioning would help. I think many people don't realise that MPEG encoders have a 'taste' of their own and that video streams are often better served with some pepper and sault.


        I'm not quite sure though what is meant by "numerical conditioning".
        All processing on a computer is "numerical", isn't it? :-)

Any processing that has no visible effect, only numerical.

quality of mpeg2enc could improve quite a bit. I read a comparison of
mpeg2enc, ffmpeg and the tmpgenc encoder the other day and they found the
default output quality of mpeg2enc to be a lot worse than the tmpgemc

All too often those tests are not objective. They're run by folks who have an agenda to prove _their_ encoder is better. So they know all the options to make _their_ encoder perform well, they don't know the others so they take the generic/defaults and then manage to prove their point that _their_ favorite encoder is better.

        Ah, I see you mentioned "default".  A better comparison would be to
        have each "encoder" ("encoder" being the complete processing pipeline)
        set up optimally.

They chose default, because that's how most people use complex things like MPEG encoders. They assume that the encoder will yield the best results with it's default settings, unless they are throwing weird stuff at it and need expert advise to tweak the settings.


        mpeg2enc's defaults probably should be revised/updated but there's
        no one setting that will work equally well in all cases.

        You can use the TMPGENC quantization matrice with mpeg2enc if you like,
        which should give similar output quality.

Hmmm.. Any reason why that one is not default if it yields better results?

output. I agree that the default output quality of mpeg2enc isn't exactly
phenominal,

Not sure what you mean "isn't exactly phenomenal" - if the data is not good going in then of course the output is going to reflect that.

That's exactly what I mean. mpeg2enc assumes that the input is sane, which it almost never is. I think the problem is also that people see mpeg2enc as a stand-alone utility, while it really *needs* the other MJPEG Tools to generate high quality output. That's also why comparing mpeg2enc with tmpgenc is like comparing apples and oranges.


        I've used Apple's "commercial" encoder - it's good (can't be put in a
        bash script, doesn't do dual-prime, allow alternate matrices, and I
        haven't found the equivalent of "-D") but I can't say it's greatly
        better than mpeg2enc.  Haven't tried Discrete's "Cleaner" though, but
        I've heard it does a good job.

I didn't say that I was unsatisfied with the quality of mpeg2enc. If you know how to use it, it is a very good encoder (Heard that CVS version is ever better... ). I also like the UNIX way of how the MJPEG Tools work, and how they can be used in scripts. That's exactly why I use the MJPEG Tools.


I'm working on a bash script (and a Wizard style Kommander GUI to control it) for using mpeg2enc, which features 'source profiles' like 'consumer DV camera', 'Computer Generated' or 'VHS Tape'. Each profile is associated with a custom MJPEG Tools processing chain that attempts to generate an acceptable video stream for mpeg2enc. Hopefully it will help non-technical users generate better looking MPEG streams. The loads of useful info on this list helps a lot to create useful profiles.

Thanks for your eleborate answers, they are most useful.

Cheers!

Dik



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Reply via email to