[MPlayer-dev-eng] Announce of Movieconvert

[nix.wie.weg at gmx.de]

Before I forget to mention: thanks for your answer!

Jan Knutar wrote:

>>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 :-)
>  
>
The mencoder -noaudio -ovc copy $source -o /dev/null is a nice idea, 
probably I will try this at user request. (but I think there should be 
also a possibility to get the correct value with "-identify".

>  
>
>>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 :-)
>  
>
This is clear and OK for me! If I only could get so close :)

>  
>
>>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. 
>  
>
I do this already in some way, but sometimes this doesnt work either.
I use -slave mode and if I have to jump long distance I use relative 
seeking.

>Or, you could try write patch for mplayer (YES PLEASE!!) that implements 
>frame exact seeking (YES PLEASE!!!) :D
>
>  
>
Are there no active mplayer developers around here, who see this kind of 
stuff as there personal field of activity, if you write an GUI you can't 
fix everything which you build your program upon by yourself.

>>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. :-\
>  
>

>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.
>
>  
>
no but you can write the following:

typedef struct {
    // name of option as generated by glade
    char glade_name[MOVC_MAX_OPTION_LENGTH];
    // type of option hscale, label, spinbutton ...
    int type;
    // how it is called as mplayer option
    char menc_option[MOVC_MAX_OPTION_LENGTH-20];
    // to which group it is counted as mplayer option, lavc(opts), 
xvid(opts) ...
    char menc_option_group[MOVC_MAX_OPTION_LENGTH];
    // should the value be threated as exception
    int is_exception;
    // default value
    double default_menc_value;
} option;

const option vopts[] = {
    { "lavc_bpp_hscale", HSCALE, "vbitrate", "lavc", YES, 800.0 },
    { "lavc_vqmin_spinbutton", SPINBUTTON, "vqmin", "lavc", NO, 2.0 },
    { "lavc_vqscale_spinbutton", SPINBUTTON, "vqscale", "lavc", NO, 0.0 },
    { "lavc_keyint_spinbutton", SPINBUTTON, "keyint", "lavc", NO, 250.0 },
    { "lavc_mbd_spinbutton", SPINBUTTON, "mbd", "lavc", NO, 0.0 }
}

char *tmp;
for( i= 0; i < sizeof(vopts)/sizeof(option); i++) [
    tmp= get_one_option( vopts[i] );
    strcat (videofiltersandshit,  tmp);
    free(tmp);
}

>>or why is -ofps not a lavc or xvid
>>option
>>    
>>
>
>Because lavc and xvid can't alter nor convert framerates.
>  
>
Even worse, in which case can you then alter frames? Is it a filter? And 
dont hang on -ofps there are many options out there of this kind and it 
is ok, because mplayer is a grown application, but sometimes somebody 
should look over it.

>  
>
>>(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? 
>  
>
No I dont want the same, I want one for dividing suboptions and the same 
for dividing filters and another one for dividing filteroptions and the 
same for subsuboptions (if ever something like this should be implemented)

>
>  
>