On Fri, 2005-07-29 at 17:51 -0300, Miguel Freitas wrote:
> doubling the frame rate is optional.
True. But unless you had a slow CPU, why on earth wouldn't you want to
use the full 60fps. That's a killer feature. :)
Anyway, the point is that the overhead I thought was due to the extra
alloc/free calls is really largely due to the increased frame rate. So
the benefits of avoiding those calls isn't as large as I first thought.
Oh well.
Cheers,
Jason.

On 7/29/05, Jason Tackaberry <tack@...> wrote:
> Oops, that was an incorrect assumption. Proper deinterlacing is a novel
> concept for me: I'm too used to MPlayer. In fact it seems that all the
> tvtime methods double the framerate, so that would certainly account for
> the extra overhead in X.
doubling the frame rate is optional.
Miguel

On 7/29/05, Jason Tackaberry <tack@...> wrote:
> Here's a very crude observation: when I run the video with no tvtime
> plugin (and hence no frequent update_frame_format calls), top says X is
> using 3-5% CPU. With the tvtime using the Linear method, X uses 7-10%
> CPU.
>=20
> I assume Linear doesn't increase the framerate, so it's probably safe to
> say that overhead is caused almost entirely by the XLockDisplay,
> XShmDetach, XFree, XShmAttach, XSync, XvCreateImage, XUnlockDisplay
> calls between every frame.
there is a lot more that will use cpu when you enable the
deinterlacing, specially the deinterlacing algorithm itself and the
color conversion. both should be pretty intensive.
take a look at xine-lib/src/xine-utils/monitor.c. it has a couple of
small functions that would help you to benchmark specific actions. you
can check how many cycles are used by frame format change and compare
to the format (colorspace) conversion, for example.
Miguel

On Fri, 2005-07-29 at 13:07 -0400, Jason Tackaberry wrote:
> I assume Linear doesn't increase the framerate
Oops, that was an incorrect assumption. Proper deinterlacing is a novel
concept for me: I'm too used to MPlayer. In fact it seems that all the
tvtime methods double the framerate, so that would certainly account for
the extra overhead in X.
Of course, I guess that doesn't mean trying to find a frame in the fifo
with the desired format isn't still a good idea. :)
Jason.

Hi James,
Thanks for applying the patches, I'll try to reply to your requests, but th=
ese=20
patches are not mine, they are took from FreeBSD's ports and they were ther=
e=20
since a long time, don't ask me why they wasn't being sent (if they weren't=
)=20
and why they are still there waiting.
On Friday 29 July 2005 21:26, James Stembridge wrote:
> > 15_all_fbsd-limits.patch
> Are these defines not available somewhere standard on FreeBSD?
Yes they are defined in machine/_stdint.h (that is included by stdint.h).
Don't know why this patch was in ports.
> > 13_all_fbsd-inp-vcd.patch
> I don't see why this is needed. Can you elaborate?
As above, I don't know this, it was there, helped compiling, I just applied=
=20
all of them.
Thanks again,
=2D-=20
Diego "Flameeyes" Petten=F2
Gentoo Developer - http://dev.gentoo.org/~flameeyes/
(Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM)

Hi Diego,
On 7/27/05, Diego 'Flameeyes' Petten=F2 <flameeyes@...> wrote:
> They are needed to compile xine-lib on FreeBSD. If they could be applied =
for
> next version it would be great.
> 10_all_fbsd-cdda.patch
Applied.
> 15_all_fbsd-limits.patch
Are these defines not available somewhere standard on FreeBSD?
> 11_all_fbsd-dvdnav-bswap.patch
This should probably go via the libdvdnav developers. Michael?
> 13_all_fbsd-inp-vcd.patch
I don't see why this is needed. Can you elaborate?
> 14_all_fbsd-inttypes.patch
I've applied a different fix for this, we have an os_types.h header
which should provide the defines independent of platform.
James.

I thought I'd resubmit this patch properly, rather than nested in a long
thread.
This patch refactors xine_open_video_driver() and moves most of that
logic
into _x_load_video_output_plugin(), a function whose prototype exists in
xine-internal.h, but wasn't implemented.
Cheers,
Jason.

On 7/27/05, Diego 'Flameeyes' Petten=F2 <flameeyes@...> wrote:
> This patch instead changes the #ifdef PIC to #ifdef __PIC__. The reason i=
s
> that PIC is defined just when you are building with libtool and i that to
> enable PIC mode (-fPIC -DPIC); instead __PIC__ is defined by gcc when PIC
> mode is enable via -fPIC flag or by other flags that requires PIC enabled
> (hardened flags, if I understood this well).
>=20
> I know that part of this code is in ffmpeg, but it would be great if that=
can
> be fixed (at least the xine-lib part).
I've applied the xine-lib part, the ffmpeg changes need to be
submitted to the ffmpeg developers.
James.

On 7/29/05, Diego 'Flameeyes' Petten=F2 <flameeyes@...> wrote:
> this is a new patch that I'm going to put on Gentoo's xine-lib soon, and =
it's
> needed to allow it to compile on xine-lib.
> The problem is that malloc.h in freebsd is not used, and just throw an #e=
rror
> saying to use stdlib.h
> The way it's used in that file makes the patch working fine.
> The check for malloc.h is already done.
Thanks, applied.

Hi Diego,
On 7/27/05, Diego 'Flameeyes' Petten=F2 <flameeyes@...> wrote:
> As for gcc4, #warn directive is now invalid and throws an error, blocking
> compilation, the right directive to use to issue a warning is #warning.
> The attached patch fixes the compilation errors.
This patch should be directed to vidix developers:
vidix-devel@...
James.

On Fri, 2005-07-29 at 13:22 -0300, Miguel Freitas wrote:
> > every frame disposes and reallocates/attaches an X shmem buffer. Now,
> > malloc()/free() is very fast, but I think the overhead for all the shme=
m
> > and Xlib calls is probably less trivial.
>=20
> right. it would be very interesting to benchmark this.
Here's a very crude observation: when I run the video with no tvtime
plugin (and hence no frequent update_frame_format calls), top says X is
using 3-5% CPU. With the tvtime using the Linear method, X uses 7-10%
CPU.
=20
I assume Linear doesn't increase the framerate, so it's probably safe to
say that overhead is caused almost entirely by the XLockDisplay,
XShmDetach, XFree, XShmAttach, XSync, XvCreateImage, XUnlockDisplay
calls between every frame.
These and other calls introduce some additional overhead in the xine-lib
process too, no doubt, although that's more difficult to measure with
top. :)
Obviously these numbers aren't meaningful as benchmarks, but it seems to
indicate there's some room for improvement.
> i mean, it seems like a good optimization to me. we should not
> maintain 2 different fifos in video_out (we don't know how many
> different formats are being used by decoders and post plugins) but
> rather priorizing frames with the same format when trying to allocate
> a new frame from the fifo.
I guess in that case it's not a fifo anymore, strictly speaking. :) But
yes, that kind of optimization doesn't sound complicated, and done at
that level, all video outs would benefit from it, plus it won't increase
memory usage either.
Cheers,
Jason.

Hi Jason,
On 7/29/05, Jason Tackaberry <tack@...> wrote:
> I notice that when I insert a deinterlacer into the chain that
> update_frame_format gets called it seems once for every frame (or
> possibly twice), going between YV12 and YUY2.
yes, since libmpeg2 decoder works with YV12 frames and tvtime needs
YUY2, they will be allocating frames with different formats. this
would be the same for a post plugin that changes frame size, for
example.
> For Xv, this means that
> every frame disposes and reallocates/attaches an X shmem buffer. Now,
> malloc()/free() is very fast, but I think the overhead for all the shmem
> and Xlib calls is probably less trivial.
right. it would be very interesting to benchmark this.
=20
> Wouldn't it be better for each vo to maintain buffers for both YV12 and
> YUY2 and only reallocate when the size changes? Obviously this isn't a
> very clever idea, so I'm sure someone else has thought of it.
actually it is a good idea ;-)
i mean, it seems like a good optimization to me. we should not
maintain 2 different fifos in video_out (we don't know how many
different formats are being used by decoders and post plugins) but
rather priorizing frames with the same format when trying to allocate
a new frame from the fifo.
Miguel

I notice that when I insert a deinterlacer into the chain that
update_frame_format gets called it seems once for every frame (or
possibly twice), going between YV12 and YUY2. For Xv, this means that
every frame disposes and reallocates/attaches an X shmem buffer. Now,
malloc()/free() is very fast, but I think the overhead for all the shmem
and Xlib calls is probably less trivial.
Wouldn't it be better for each vo to maintain buffers for both YV12 and
YUY2 and only reallocate when the size changes? Obviously this isn't a
very clever idea, so I'm sure someone else has thought of it. The only
explanation I can see is that the memory overhead (since doing this
requires roughly twice as much memory for all the buffered frames)
doesn't justify the cpu savings. But I'd be curious to hear if there's
any deeper reason for the current behaviour.
Cheers,
Jason.

Hi Jason,
> That's good to hear. I did as you suggested and, knock on wood,
> everything looks like it's working.
Cool. That approach should be much easier to handle, since there are
fewer components involved.
> One thing I'm not sure about is in buffer_display_frame() if I should
> call free() on the passthrough frame after calling display_frame() of
> the passthrough vo. I sheepishly admit that most of my success
> working
> with xine-lib is based on a combination what both works and doesn't
> crash, without giving a great deal of thought to correctness.
> Everything seems to work both with and without
> passthrough_frame->free(), so I'm just not sure what's correct. :)
I think you should not call free(), because (given that I understand
your current approach correctly), you never locked that frame by
calling something like draw() or lock() on it. The safest way is to
have a look at the frame's reference counter (called "lock_counter").
Besides, if you do not free() it and it still works, it does not need
free()ing. Otherwise the engine would lock up soon, because it is
running out of free frames.
Michael

Hi Miguel,
> spawning two video_out_loop() for this application doesn't seem like a
> good thing to me. you don't need it and i guess it will only cause
> trouble.
Yes. This way, some housekeeping is done twice which is assumed to be
done only once. (Like passing the frames through metronom.)
> the good news is that vo driver is *almost* guaranteed to be called
> only by a single thread so locking problems shouldn't be an issue. the
> only exception are the asynchronous calls from the frontend to report
> window resizing, repainting or, in your case, overlay updating.
I think update_frame_format() is called via draw() by the decoder
thread. Everything else is indeed only called by the video out thread.
Michael

Hi Miguel,
On Thu, 2005-07-28 at 16:50 -0300, Miguel Freitas wrote:
> in other words: just hack xine-engine to be able to get the vo driver
> loaded without the vo loop. i promise we will add that feature to next
> releases when we get your plugin to work well.
That's good to hear. I did as you suggested and, knock on wood,
everything looks like it's working. Attached is a patch to xine-lib
that refactors xine_open_video_driver() and moves most of that logic
into _x_load_video_output_plugin(), a function whose prototype exists in
xine-internal.h, but wasn't implemented. All my testing is cursory, but
so far this is all the extra functionality I need from xine-lib.
Implemented this way (i.e. using vo_driver_t directly, instead of
xine_video_port_t) I am also able to safely (i.e. no crashes) able to
use the image buffers allocated by the target vo (something I discussed
with Michael in an earlier email). So in addition to not exploding into
a zillion pieces, this approach is also faster. :)
> spawning two video_out_loop() for this application doesn't seem like a
> good thing to me. you don't need it and i guess it will only cause
> trouble.
Yes, and yes. Synchronizing two non-trivial threads is already hard
enough. Adding a third is asking for trouble. :)
> the good news is that vo driver is *almost* guaranteed to be called
> only by a single thread so locking problems shouldn't be an issue. the
> only exception are the asynchronous calls from the frontend to report
> window resizing, repainting or, in your case, overlay updating.
Assuming my vo just straight proxies the get/set property and gui data
exchange functions, I shouldn't need to worry about locking since
presumably the target vo should take care of whatever it needs.
One thing I'm not sure about is in buffer_display_frame() if I should
call free() on the passthrough frame after calling display_frame() of
the passthrough vo. I sheepishly admit that most of my success working
with xine-lib is based on a combination what both works and doesn't
crash, without giving a great deal of thought to correctness.
Everything seems to work both with and without
passthrough_frame->free(), so I'm just not sure what's correct. :)
Thanks for all your advice.
Cheers,
Jason.

Hi Mike,
your zoom patches are in CVS now, however with some changes and
additions (e.g. the patch you sent missed keyboard shortcuts in keys.c).
Changed files are: actions.c keys.c osd.c osd.h
Please check out, test it and give response (if you are using anonymous
CVS, wait a few hours to update).
Thanks,
Hans-Dieter
PS: Looking at the changes, you can learn more about coding style; if
you have any questions, feel free to contact me.

Community

Help

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

CountryState

JavaScript is required for this form.

I agree to receive quotes, newsletters and other information from sourceforge.net and its partners regarding IT services and products. I understand that I can withdraw my consent at any time. Please refer to our Privacy Policy or Contact Us for more details