[MPlayer-dev-eng] Announce of Movieconvert

[Jan Knutar]

> A) mplayer -identify doesn't always deliver correct video bitrate
> values These bitrate values are essential for movieconvert because
> they are needed for all size calculations. There seems to be
> different cases of this error. On *.vob files or DVD's the bitrate
> value seems to be too high (maybe it is exactly twice as high as it
> should be). This confuses even gmplayer. On other files like for
> instance
> http://pdl3.warnerbros.com/thematrix/us/med/trailer_final_1000_dl.zip
> you get an bitrate of zero.

You could run mencoder -noaudio -ovc copy $source -o /dev/null
And grab the correct bitrate from the output of that.

The bitrate value indicated in mpeg2 headers seem to be a "maximum" 
value. I've noticed that if I make SVCD's with vbitrate=1500, and max 
bitrate at 2500, that mplayer will report 2500 as the bitrate on 
playback.

The mencoder method is much more accurate, but takes long :-)

> C) mplayer seeking is very unreliable
> I have implemented the possibility of cutting the video by
> determining start and end of video graphical.

Don't expect to get any better cutting granularity than the source 
file's keyframe interval. For divx that'd be ~10 seconds :-)

> But seeking is much too unreliable.
> Sometimes it differs over 3000 seconds (mainly on mpeg1 Videos). I
> tried very hard to find a workaround for this, but I failed. 

When I was last playing with the divx2svcd script, I wanted to try make 
the splitting into volumes by size done by mencoder instead of tcmplex.

I ran into same problem. However, I had an idea on how to sort of solve 
it, haven't tried it yet though.

Afaik, seeking in mpeg1 is done by estimating the bitrate (or relying on 
the header figures), and jumping to the position in the bytestream that 
would match teh requested time, if the bitrate estimate was correct. 
This means that adjusting the -ss value should increase and decrease 
teh actual time we end up at, I'm assuming mpeg1 has some timestamps 
embeded which makes the time somewhat reliable atleast... (This 
wouldn't work on DVD, right?).
Anyway, ever heard of "binary search"? :-) You could run a series of 
mplayer -ss $time -frames 2 and look for the time in the output, while 
varying the time using binary search method. I think it'd have to be 
slightly modified though, because in the end you'd end up oscillating 
between the two closest time positions over and under the requested 
value, due to the granularity caused by only being able to seek to 
keyframes. 

Or, you could try write patch for mplayer (YES PLEASE!!) that implements 
frame exact seeking (YES PLEASE!!!) :D

> D) please dont use combined Options
> For instance do not use crop=width:height:x:y use instead
> crop_w=width,crop_h=height,crop_x=x,crop_y=y the second version you
> can generate from GUI components automatically, for using the first
> version you have to write a special function which will deal with
> this format.

Er, why can't you generate that from GUI components? Surely you just get 
a callback or somethign when someone enters something into a text box, 
and then you update a struct with all the encoding options, ann then 
when you call mencoder, you just build the option string from the 
values in the struct? It sounds ilke you'd be mangling a mencoder 
command string each time an option in your itnerface is changed. :-\

> E) please sort the mplayer options
> For instance you do an -vf scale=width:height -sws 1 why not -vf
> scale_w=width,scale_h=height,sws=1

Is it that much of a pain for you?

For example

char videofiltersandshit[400]

snprintf(videofiltersandshit, 400, "-vf scale=%d:%d,crop=%d:%d -sws %d",
	settings->scale_x, settings->scale_y, settings->crop_x,
	settings->crop_y, settings->scaler_method);

compared to...

snprintf(videofiltersandshit, 400, 
	"-vf scale_w=%d,scale_h=%d,sws=%d,crop_w=%s,crop_h=%d",
	settings->scale_x, settings->scale_y, settings->scaler_method,
	settings->crop_x, settings->crop_y);

Yes, I can see how these small changes makes it easier for the 
programmer and the user that uses mencoder directly ... not.

> or why is -ofps not a lavc or xvid
> option

Because lavc and xvid can't alter nor convert framerates.

> (it will be ignored if "-ovc copy" is selected)

Yes, because you can't drop or insert frames without reencoding.

>  and why do you
> have different seperators in -lavcopts and in -vf (":" or ",")?

Would you use the same separator for separating both unique filters, and 
separating the options to the filters? How would you know where the 
filter-specific options ended, and a new filter started?