[MPlayer-dev-eng] Re: [MPlayer-users] ssa reader for mplayer using vf_overlay

[Robert Henney]

On Thu, Sep 29, 2005 at 09:57:24AM -0400, Jason Tackaberry wrote:

[...]
> The solution to your problem should be pretty simple: don't set the lock
> byte to BUFFER_LOCKED until after you're done writing to it.  This might
> seem counter-intuitive until you realize that the lock/unlock status is
> actually from the perspective of your application, not vf_overlay.  So
> when the buffer is unlocked, you're allowed to write to it.  When it's
> locked, you're not.  So make your changes to the buffer, issue the
> invalidate slave command, and then set the buffer to BUFFER_LOCKED
> (0x20).  vf_overlay won't read it until it's set to this state.

That solved the lock problem I was having.  As you say I had been
looking at it backwards, with the idea that setting the lock was to tell
the overlay not to read from the buffer until it received an invalidate
request.

> I haven't noticed any problems myself with this.  I've never been
> concerned about calculating the invalidate rectangles since I've been
> using Evas, and it does that for me.  If there's a bug in this area, I'm
> guessing that it has to do with the coordinate translation code.  Is
> there any hardware scaling of your video happening?  If so, vf_overlay
> will scale the OSD from display size to frame size, and it will
> translate all coordinates from one to the other.  You can try using
> software scaling in the filter chain to prevent any resizing and see if
> it fixes your problem.

I believe at this time it was probably a combination of a bug in my code
combined with my previously not making correct use of the lock byte that was
causing this.

> Are you specifying a slice?  You probably should be, since it will
> improve performance a fair bit when you just want to overlay a line or
> two of text.  If so, what you're describing could be a bug there as
> well.

So far I've not made use of slices, but I plan to add that soon.  Many
of the particular scripts I'm using to test with have text at the very top
and bottom of the screen simultaneously, but granted in normal use most 
of the time that would not be the case.

speaking of which, would adding support of multiple slices be possible?
this would benefit my use, but even for conventional osd use I could see
a benefit.  One example might be osd menus being placed near the top of
a display, while an osd status bar is continually displayed at the
bottom.

I already suspect so, but would issuing a "visible=0" at the times when
I've nothing to put on the screen improve performance too?

> This might happen if the overlay is getting scaled as I described above.
> See if this goes away also when you use software scaling before
> vf_overlay in the filter chain.  If at the point in the filter chain
> vf_overlay appears the frame size and display size are equal, no OSD
> scaling will occur and we can rule this out.  If you find that this
> helps what you're describing, try editing the vf_overlay.c and change
> all occurrences of SWS_FAST_BILINEAR to SWS_BICUBIC and see if that
> helps.

Haven't had chance to test this yet, but I should soon.


I did find one video so far that vf_overlay doesn't seem to handle.
until setting "visible=1", things are find, but afterwards the colors
in the video run all over the screen.  Adding "scale" does fix this,
so it might the particular color space the video uses that vf_overlay
doesn't handle yet.  The output below probably contains the clues.

 robh at hpbox:~$ mplayer -quiet -slave -vf overlay=12345 /mnt/c/\[Seiran\]Boku_wa_Imouto_ni_DVD_RAW\[h264-ac3\]\[21BD970E\].mkv 
 MPlayer dev-CVS-050927-01:56-3.3.5 (C) 2000-2005 MPlayer Team
 CPU: Advanced Micro Devices Athlon K7 (Family: 6, Stepping: 2)
 Detected cache-line size is 64 bytes
 CPUflags:  MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 0 SSE2: 0
 Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx
 
 Failed to open /dev/rtc: Permission denied (it should be readable by the user.)
 Playing /mnt/c/[Seiran]Boku_wa_Imouto_ni_DVD_RAW[h264-ac3][21BD970E].mkv.
 [mkv] Track ID 1: video (V_MS/VFW/FOURCC), -vid 0
 [mkv] Track ID 2: audio (A_AC3), -aid 0, -alang eng
 [mkv] Track ID 3: audio (A_AC3), -aid 1, -alang eng
 [mkv] Will play video track 1
 [mkv] Will play audio track 2
 Matroska file format detected.
 VIDEO:  [H264]  640x480  24bpp  23.976 fps    0.0 kbps ( 0.0 kbyte/s)
 ==========================================================================
 Opening audio decoder: [liba52] AC3 decoding with liba52
 Using 3DNowEx optimized IMDCT transform
 AC3: 2.0 (stereo)  48000 Hz  160.0 kbit/s
 Using MMX optimized resampler
 AUDIO: 48000 Hz, 2 ch, s16le, 160.0 kbit/10.42% (ratio: 20000->192000)
 Selected audio codec: [a52] afm:liba52 (AC3-liba52)
 ==========================================================================
 Opening video filter: [overlay=12345]
 ==========================================================================
 Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
 Selected video codec: [ffh264] vfm:ffmpeg (FFmpeg H.264)
 ==========================================================================
 Building audio filter chain for 48000Hz/2ch/s16le -> 0Hz/0ch/??...
 AO: [oss] 44100Hz 2ch s16le (2 B/s)
 Building audio filter chain for 48000Hz/2ch/s16le -> 44100Hz/2ch/s16le...
 Starting playback...
 VDec: vo config request - 640 x 480 (preferred csp: Planar YV12)
 VDec: using Planar YV12 as output csp (no 0)
 Movie-Aspect is 1.33:1 - prescaling to correct movie aspect.
 overlay: 640x480 BGRA; shmem key: 12345; MMX accelerated.
 VO: [xv] 640x480 => 640x480 Planar YV12 
 quit
 
 Exiting... (Quit)

-- 
robh