From: Christoph P. <chr...@gm...> - 2006-12-08 21:24:50
|
Hi all, 2006/12/7, Thibaut Mattern <thi...@gm...>: > Hi, > > On 12/2/06, Miguel Freitas <mfr...@gm...> wrote: > > Hi Richard, > > > > On 11/13/06, Richard S. <tee...@gm...> wrote: > > > Hi, xine can't play H.264 video with huge frameref (ref=12). > > > A sample file can be found here: http://www.megaupload.com/?d=B596B9FT > > > > yes, this is a known bug. > > yes..... > > > being a known bug doesn't mean we are happy with it and we will keep > > it unfixed. it is a high priority bug, but the fix is not clear. > > currently we allocate frames directly from video out driver (like XV) > > and, for most system, asking for more frames than we already do would > > break things. so we need to do something different... > > we need better a frame allocator, iirc the difficulty is to detect > when to allocate a new "indirect "frame. > > > we will continue this discussion, i just wanted to give you a quick > > acknowledge while i go through my inbox. > > > > Miguel > > Thibaut I'm currently porting the xshm output plugin to xcb [1]. It already works +/- (problems with heavy resizing and when shm isn't present, but i'll solve them). There i have in mind to allocate one shared segment, stored in xshm_driver_t. The standard alloc frame routine would just return a "normal" (just a buffer) image. During the rendering the shared segment in xshm_driver_t would be adjusted if needed and the image would be rendered into the shared segment. Imho that would solve this problem quite nice (nearly infinite number of frames available) while not having a performance impact (the yuv2rgb must be done anyway). Resizes should be faster (especially when we never shrink the shared segment you can resize as hard as you want to and shouldn't have much impact ;-) Sorry that I'm not attaching any sample code ... but you'll get some soon ... Christoph [1] http://xcb.freedesktop.org/wiki/ ; they have clean multithreading concept and they're doing their ways into the distros soon |