Siarhei Siamashka wrote:
>> >> The advantage of XV is that you don't have to optimize your *client*
>> >> software for a specific board (which naturally yields the optimal
>> >> solution), instead you optimize the driver. Thus instead of one
>> >> program working nicely, you have N programs working nicely for the
>> >> same effort. Don't get me wrong, using the framebuffer directly is
>> >> fine and dandy for a number of use cases, but if X is going to be
>> >> running, XV is the only decent way to interact with it really.
>> >
>> > I'm not fully convinced on the performance issue but I do agree that
>> > XV is much more polyvalent and powerful than fbdev.
>>
>> Judging from the code you attached, and assuming I'm not totally
>> wrong, the only part where XV "needs" to be inferior is the data
>> transfer between the client and the server. And when XSHM is used,
>> that overhead is bound to be dwarfed by the decoding and color
>> conversion to a point of not mattering any more.
>
> Still XV is harder to use in a video player to get good performance. The
> problem is mostly related to OSD and subtitles.
If the hardware supports the native output format of the decoder, and
there is enough video memory for all delayed frames (3 frames for MPEG2,
16 for H.264), XV imposes an additional copy of each frame from the SHM
segment into the actual video memory. If there is insufficient video
memory or if pixel format conversion is required, there is no reason for
XV to be less efficient than the application accessing the framebuffer
directly.
> With direct access to framebuffer, video decoding is very simple. The
> client just does color format conversion and then can easily draw
> subtitles over the image in the framebuffer.
Unless alpha blending of subtitles with the video frame is required, one
can simply draw the subtitle text directly in the X window used for video
and enable colour keying for the overlay.
> With XV everything gets more complex if we want to avoid any redundant
> memcpy operations to copy data around. The client needs to provide a
> ready frame with all the subtitles and OSD data drawn over it in a planar
> format to XV. But subtitles can be applied only to the frame which is
> already retired from video decoding pipeline and is not used as a
> reference frame for decoding next frames anymore. So if everything is
> implemented right, the frame is available with some delay which needs to
> be compensated and taken into account.
Any post-decode rendering into the video frames requires either an extra
copy or a delay. When the hardware support the codec-native pixel format
and sufficient video memory is present, decoding directly to video memory
and rendering subtitles after a delay is the most efficient. XV does not
allow this, unfortunately.
If pixel format conversion is required, the player can simply render the
subtitles into the video frames after a safe delay before passing them
to XV, which will do the format conversion while writing the frame to
video memory. No extra copy needed. The delayed subtitle rendering
is trivial to implement.
The overall style of your reply seems a bit strange:
me: Implementing fast video output (on beagleboard) using XV is somewhat
harder than just using direct framebuffer access, because you need to
implement delayed subtitle rendering (handled by "direct rendering" in
MPlayer) in order to avoid extra data copies.
you: The delayed subtitle rendering is trivial to implement (plus some
additional useful details about delayed subtitle rendering).
Are you trying to question something? You have also taken an easy way with
omapfbplay instead of investing efforts in tweaking one of the full-fledged
media players to get it work well
Thanks anyway for the additional details. Gregoire and Kalle may find all this
information useful and they are the ones who are *actually* working
on "Improved MPlayer: At the performance level of Omapfbplay" and XV for
beagleboard.
BTW, the comment about colour keying is quite interesting (though MPlayer is
normally using alpha blending for subtitles). It might be worth implementing
(as it is *really* trivial). Probably you should submit your idea to
mplayer-dev-eng mailing list.
> As I mentioned before, this stuff is implemented in MPlayer using "direct
> rendering" method (-dr option), also see [1]. The problem is that the
> last time I checked it (admittedly long ago), direct rendering was not
> working well in MPlayer (including not making use of direct rendering for
> some codec/configuration combinations and rendering bugs with subtitles).
> Theoretically, everything should be fixable given enough efforts. But in
> practice it may be definitely more complex than just going with direct
> framebuffer rendering hacks
Am I misreading you, or is the above paragraph saying that XV is suboptimal
because mplayer has bugs when *not* using it?
Yes, you are definitely misreading me.