[MPlayer-dev-eng] Recommend error for bad dimensions

D Richard Felker III dalias at aerifal.cx
Wed Mar 3 01:58:08 CET 2004


On Tue, Mar 02, 2004 at 11:41:20PM +0000, Adam Rice wrote:
> Quoting D Richard Felker III (dalias at aerifal.cx):
> > No, this is completely idiotic. Normally you should SCALE after crop,
> > in which case any even dimensions are valid for crop. On the other
> > hand, it should also be an error if you _scale_ to invalid dimensions.
> 
> But if you round the dimensions you scale to to multiples of 16, you're liable
> to screw up the aspect ratio. Maybe you don't care about aspect ratio, but
> I've seen quite enough Paula Abdul videos for one lifetime.

Let's see. If you round to nearest multiple of 16, you'll change the
dimensions by at most 8. Out of 640, or even 720. Yeah. You do a
doubleblind test and see if you can tell the difference, then get back
to me. Anyway, you can encode the exact aspect in the mpeg4 aspect
tag, so MPlayer will show the movie exactly right, and then windows
users will just see it slightly wrong.

> So then we're left instructing the user to 
> 
> 1) crop, to remove black borders which waste bits
> 2) scale, to keep Rich happy
> 3) crop again to hit a multiple of 16 pixels in both directions

Umm this is stupid. Just figute out the right extra cropping to do
before you scale, so that it will come out to multiples of 16 in the
scaling. Is elementary algebra THAT inaccessible to people nowadays?

> Having done all this, is there any guarantee that the resulting file will be
> playable in anything other than mplayer anyway? I keep seeing postings from
> people who are jumping through all kinds of hoops to get mencoder to spit out
> something that other people can actually play.

Um, those are talking about stupid DVD/SVCD crap, not mpeg4. The only
problem I know of is that WMP has a bug where it misdetects valid avi
files as mp3 sometime, so you have to be careful. It usually only
happens on low quality encodes tho. A workaround is available but it
would increase filesize...

> > So the logic belongs in ve_lavc, not filters. Especially since the
> > filters might not even be used for encoding but just for playing!!
> 
> Hands up everyone who uses cropdetect while playing? Come on, there must be
> someone out there who's adopted this novel way to slow their computer down!

Umm, use cropdetect ONCE, then use the output from it for -vf crop
while playing.

> Are you proposing that ve_lavc should crop the video to multiples of 16
> itself?

Of course not.

> If not, all you're doing is creating yet another hoop for users to
> jump through. Do you really hate them so much?

No. I just know that most won't RTFM (and the fine manual isn't so
fine anyway, when it comes to encoding... :/), so it's better that the
program keep them from making bad files unless they confirm that they
want bad files.

Rich





More information about the MPlayer-dev-eng mailing list