Re: [Mlt-devel] More experiments with Java bindings - toying with frames
Brought to you by:
ddennedy,
lilo_booter
From: Stepan R. <st...@sr...> - 2004-08-08 14:57:17
|
On Sun, 8 Aug 2004, Charles Yates wrote: > On Sun, 2004-08-08 at 13:51, Stepan Roh wrote: >> Hello. >> >> I was playing a bit with Java bindings. My goal was to be able to get >> thumbnails to produce timeline. I finally implemented it with accessing >> producer directly and retrieving frames one by one. It almost works >> (frames are retrieved as thay should be), but whenever I try to get an >> image from frame by calling mlt_frame_get_image it segfaults in >> mlt_resize_yuv422. I guess I do something wrong, but have no idea what :-( >> Can someone look on it? Thanks a lot. > > OK - you're close - there are two ways to do this. > > The first is simplest - by default the bindings use the 'fezzik' > producer to map file extensions to the real producer and also apply the > rescaling, resizing and resampling filters. > > If you use: > > MltProducer p = new MltProducer( "avformat", args[0]); > > The code will work pretty much as you have it. Though there are a couple > of gotchas... Great, it works with "avformat". > The main one is that you will probably always get back a yuv422 (packed) > image - the mlt_image_rgb24 is a placeholder which is ignored by most > producers (esp. avformat). The value of format after the call will > reflect this. The width and height will always be that of the source, > thus it won't be great for thumbnails. I think I spotted a problem in mlt_frame_get_image(): if someone gets image different from mlt_image_yuv422, it will get to him on subsequent calls as mlt_image_yuv422. I guess the fix to it is to have "format" property and in mlt_frame_get_image() assign current format to it. That way line *format = mlt_image_yuv422; will be changed to correct *format = mlt_properties_get_int( properties, "format" ); and everything will work as expected. > When you use "fezzik" the rules change slightly. > > The colour space issue is still there, so you will only reliably be able > to obtain yuv422. However, the initial values of width and height are > taken into account by the rescaling and resizing filters, so you need to > assign them as the actual width and height that your thumbnails should > be, and you should also specify a rescaling interpolation method and the > aspect ratio that you want :-). If I understrand it correctly arguments width, height and format are just "hints". Am I right? I hope MLT gets more documentation in the future :-) > Something like: > > int prepare_image( int width = 192, int height = 144 ) > { > uint8_t *buffer = NULL; > mlt_image_format format = mlt_image_yuv422; > return mlt_frame_get_image( self->frame, &buffer, &format, &width, > &height, 0); > } > > might work for a kind of PAL-centric method (this is untested). > > The other properties that might be of interest to set prior to the > prepare_image are: > > MltFrame frame = p.get_frame(0); > frame.properties( ).set( "consumer_aspect_ratio", "1.333333333" ); > frame.properties( ).set( "rescale.interp", "nearest" ); > > Dan would probably suggest a correction to the aspect ratio? But that's > the general principle anyway. It works now with "fezzik" too. Super! However segfault if "consumer_aspect_ratio" is not set is not very user-friendly (especially if services.txt says: If a property "consumer_aspect_ratio" exists on the frame :-) > Hope that helps, Yes, thanks. Now I'll have to convince Java to show those images. Have a nice day. Stepan Roh |