[MPlayer-dev-eng] [PATCH]: framestep & tile filter.

[danny]

Alle 01:48, sabato 30 agosto 2003, Arpi ha scritto:
> Hi,
>
> > The other one (tile) does what my vo_tga does at the start: tile some
> > images to have a big one with the small 'preview' on it.
>
> hmm, looks ok, but you should use strtol() for int parsing, instead of
> reinventing the wheel, and use memcpy_pic() instead of reimplementint it
> called copy_plane...
Done, put strtol in my function (for error handling) and use memcpy_pic()
>
> also filter could support YUV formats too, the packed ones (yuy2 etc) seems
> quite trivial (handle same way as rgb16), but the planar yv12 is easy too
>
Done for 444P, 422P, 411P, YUY2, YV12, I420, YVU9, IF9, IYUV (it was really 
easy, some chroma_width/height and x/y shift)

I tested the program with your format=fourcc filter in the chain.

I don't take in account MP_IMGFLAG_COMMON_PLANE and MP_IMGFLAG_COMMON_STRIDE, 
is a correct assumption or not?

In my test I never had this flag but i don't know if this is correct for 'real 
life' examples (some codecs use the images in this way? It seems to me that, 
supporting stride, both the flag doesn't need to be activated, you can load 
the correct value in the plane[], stride[] and your done).

In the framestep filter there also the option to print some info on the image 
format (actually commented with a #ifdef). It was very useful to understand a 
litte bit more about YUV2, 444P and son on so i leave it.

> also the filter could support DR (by implementing get_image()), but we
> discussed this on IRC with Rich, and out-of-order decoding may emss up the
> whole thing, so it must be implemented in a very tricky/clever way.
> i'll try to do that.
At a first glance you need the frame number (from the decoder!) and some 
buffer (when you get a picture 1/2 frame ahead and you should write the whole 
image.
>
> > On this filter i face some problem, the worst of all is the
> > query_format(...) function
> >
> > Now to use the tiling with the xv output you need to put a scale filter
> > after the tile one.
>
> yes this is a known problem of the vf layer, not the only one :(
> the next_config() wrapper tries to insert scale filter, but it doesnt
> always work.
>
> > The last question involve the make process.
> >
> > If i modify a .c module in the directory libmpcodecs and i type make from
> > the main mplayer directory the build process doesn't work (nothing to do
> > for all!).
> >
> > I have to type:
> >
> > 	make -C libmpcodecs && make
> >
> > Is regular or i missing, once, something?
>
> yes, either 'make dep' (ro make depend) after ./configure (ala kernel),
> or touch .developer in the source root dir

Is not possible to (simply) call the needed recursive make when something on 
which libavcodec.a depend change (all the .c in the directory, the .h and the 
other include used, in practice merge all the dependency of the lib itself 
and check them in the main makefile to decide ONLY if you must go in the 
subdirectory, not what to do in the directory)
>
>
> A'rpi / Astral & ESP-team
>
> --
> Developer of MPlayer G2, the Movie Framework for all -
> http://www.MPlayerHQ.hu
>
> _______________________________________________
> MPlayer-dev-eng mailing list
> MPlayer-dev-eng at mplayerhq.hu
> http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng

Attached there is the patch (complete, apply to CVS, also with a little bit 
info on the en man pages).

	Thanks.

		Daniele Forghieri

	
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tile_step.diff
Type: text/x-diff
Size: 20364 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20030831/2caf79c7/attachment.diff>