On 2007-05-22 09:12, Dirk Meyer wrote: > The expand plugin causes a lot of problems, see the note at the > beginning of child.py: > > | # The expand post-processing filter messes up changing the aspect > | # during runtime. It results in a black border sometimes, sometimes > | # the aspect change does not even work at all. Removing it fixes this > | # problem. This needs to be fixed! > | USE_EXPAND = False
There definitely used to be an aspect bug with expand plugin (it was my fault, I added it :)) but I submitted a fix for it that was merged a long time ago. But I'm not sure if this is same problem you ran into, but I'll try to reproduce it. I guess this explains why video played by popcorn was no longer being expanded. Incidentally I use kaa.popcorn to play pretty much everything I watch on my HTPC, so I notice when things don't work properly pretty quick. :) > I also have problems with PARAM_VO_CROP_* (see note on usage of this > in child.py) resulting in a crash. Maybe I use some parts wrong. I also added notes about this in child.py. For purposes of zooming, I think you can accomplish the same thing as VO_CROP by passing negative values for the first tuple (x,y) if you want crop on the top/left side, and increasing the (w,h) values if you want to crop on the bottom/right side. If you want to crop _within_ the window, this won't work, but if I understand what you want to do with zooming, I think you don't need to use VO_CROP here. The frame_output_cb callback gets called by the video out thread, not the main thread. I don't really know if it's safe to call xine API functions that have side effects. > That should work. The only case where the code you commented out makes > a difference is when you have a new width, height or aspect and again > a new aspect _one_ frame later. So you mean you're getting two aspect changes in two adjacent frames? And the second aspect change is not representative of what's in the stream? > BTW, content swicthing between 4/3 and 16/9 has some funny effect in > mplayer and xine with the exapnd filter. The picture gets smaller > every time the aspect changes. Strange bug. I'll play with this later and see if I can reproduce. > The monitor I used for testing is 1280x1024 with 4/3. These are non > square pixel. Yes but the previous code basically hardcoded for this scenario. Anyway, I do admit this is confusing. I still can't get my head wrapped around the non-square pixel video / non-square pixel display case without taking a few minutes to remind myself how it's supposed to work, and as soon as you start dealing with a combination of frame aspect and _pixel_ aspect, it's a real mindfuck. Consequently it's hard to get right. (Also I'm getting old and increasingly senile, and as a result, stupider.) I think we should enumerate all the possible configurations to help at the very least devise a test plan. > I have no idea _what_ the parameter I return are about. You know, > missing and doc and such things. :) Well, _xine_frame_output_cb is the python version of frame_output_cb, which is called frequently inside xine. Kaa just passes the call along into python space. So the lack of documentation in this area is less my fault and more xine's. :) But see http://xinehq.de/index.php/hackersguide for a bit of info. The callback is called within xine-lib in xine-lib/src/xine-engine/vo_scale.c in _x_vo_scale_redraw_needed(). In kaa.xine, this callback is translated to python space in kaa/xine/src/drivers/x11.c in x11_frame_output_cb(). The return value for the python function is in the form (dst_x, dst_y), (win_x, win_y), (dst_w, dst_h), display_pixel_aspect. (dst_x, dst_y) refers to the offset within the window where xine will position the video frame; it will normally by (0,0) but if you specify negative values it will effectively crop a bit off the left and/or top edges. (win_x, win_y) is something I'm unclear about, but I think it's used in the vo layer, and only by certain VOs. (dst_w, dst_h) is the display resolution of the video that xine will draw; if you specify values that are larger than the window, it will effectively crop a bit off the right and/or bottom edges. display_pixel_aspect is the display's pixel aspect. :) > I get an aspect in the function and give one back. I guessed it was an > extra scale aspect from either movie or window aspect. The one you get is the _video_'s pixel aspect ratio. This, for example, helps you calculate the appropriate display width/height for the given video. The one you return is the _display_'s pixel aspect ratio. For almost all cases, this value is going to be 1.0. In your case (1280x1024 4:3) it's going to be 0.937, or (1280.0/1024)/(4/3). ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Freevo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freevo-devel
