Opened 11 years ago

Closed 10 years ago

#2405 closed bug (fixed)

MediaPlayer doesn't use overlay altough it is available

Reported by: nutela Owned by: marcusoverhagen
Priority: normal Milestone: R1
Component: System/Kernel Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: x86

Description (last modified by stippi)

grep -i overlay /var/log/syslog KERN: Radeon - ALLOCATE_OVERLAY_BUFFER: success: mem_handle=4, offset=502000, CPU-address=94502000, phys-address=d8502000

MediaPlayer std error:
OpenDMLParser::Parse: JUNK chunk ignored, size: 376 bytes
FormatProposal() error
VideoConsumer::CreateBuffers() - get_area_info(): Operation on invalid team
VideoConsumer::Connected - COULDN'T CREATE BUFFERS
BMediaRoster::Connect: aborting after BBufferConsumer::Connected, status = 0xffffffff
VideoProducer::Connect() - consumer error: General system error
BMediaRoster::Connect: aborted
FormatProposal() error

Change History (13)

comment:1 Changed 11 years ago by euan

I'd question whether the Radeon overlay is working. Would be good to know what overlay format is being requested.

comment:2 Changed 11 years ago by stippi

Interesting. The get_area_info() call is made regardless of overlays. It is needed to map media kit BBuffers to the memory of BBitmaps:

// figure out the bitmap creation flags
uint32 bitmapFlags = 0;
if (fTryOverlay) {
	// try to use hardware overlay
	bitmapFlags |= B_BITMAP_WILL_OVERLAY;
	if (i == 0)
		bitmapFlags |= B_BITMAP_RESERVE_OVERLAY_CHANNEL;
} else
	bitmapFlags = B_BITMAP_IS_LOCKED;
	
fBitmap[i] = new BBitmap(bounds, bitmapFlags, colorSpace);
status = fBitmap[i]->InitCheck();
if (status >= B_OK) {
	buffer_clone_info info;
	uint8* bits = (uint8*)fBitmap[i]->Bits();
	info.area = area_for(bits);
	area_info bitmapAreaInfo;
	status = get_area_info(info.area, &bitmapAreaInfo);
	if (status != B_OK) {
		fprintf(stderr, "VideoConsumer::CreateBuffers() - "
			"get_area_info(): %s\n", strerror(status));
		return status;
	}
	info.offset = bits - (uint8*)bitmapAreaInfo.address;
	info.size = (size_t)fBitmap[i]->BitsLength();
	info.flags = 0;
	info.buffer = 0;
		// the media buffer id
	BBuffer *buffer = NULL;
	if ((status = fBuffers->AddBuffer(info, &buffer)) != B_OK) {
		ERROR("VideoConsumer::CreateBuffers - ERROR ADDING BUFFER TO GROUP\n");
		return status;
	} else
		PROGRESS("VideoConsumer::CreateBuffers - SUCCESSFUL ADD BUFFER TO GROUP\n");
}

If you can watch the video without overlay, it means the exact same code path works for non-overlay bitmaps, which is a bit strange. I guess the team could indeed be different. For normal bitmaps, the app_server would have allocated the area/memory, while for overlay bitmaps, it would have actually been the graphics driver/kernel. Maybe some privilege thing is preventing this from working?

comment:3 Changed 11 years ago by stippi

Description: modified (diff)

comment:4 Changed 11 years ago by nutela

Yes I can watch video but in "info" it says BDrawBitMap is used and hence a lot of frames are dropped (old machine). Nice progress nevertheless.

comment:5 Changed 11 years ago by stippi

I am waiting on a reply from Axel on the matter. I am guessing the analysis of the problem with regards to get_area_info() is correct, Haiku is probably just more restrictive with these "security matters", but then a decision needs to be made how to deal with this situation. One way would be to copy the buffers, but that's undesirable, especially if the performance on the old computer is a concern.

Hm... thinking about it - Another problem could be that the respective driver allocates the memory for the bitmaps with the wrong flags (B_USER_CLONABLE_AREA missing or whatever it was).

comment:6 Changed 11 years ago by axeld

The overlay buffers usually reside in the frame buffer area that is created by the kernel driver. I don't really understand why get_area_info() would fail, though - this can only happen in case vm.cpp::get_address_space_by_area_id() does not find the area in question.

The B_USER_CLONEABLE_AREA flag should not have an influence on get_area_info(), though. It looks like this needs a bit more investigation.

comment:7 Changed 10 years ago by herdemir

I can watch videos in overlay mode with VLC, but not with MediaPlayer. Is it still not implemented in Media Player or is it a bug? I need ovelay mode in order to test the codecs with media player to report the results, especially with HD videos.

comment:8 Changed 10 years ago by stippi

IIRC, when I wrote this code, I tested it on ZETA when I still had a graphis card with driver capable of doing overlays. So as far as MediaPlayer goes, this code is supposed to work. If you are watching videos in overlay mode in VLC, then your driver setup and app_server obviousy work on Haiku as far as that goes. It could be that the reporting in the information window is simply not fully implemented, and that overlays indeed work. If you turn off "smooth scaling" in the settings, and you get blocky scaling when you enlarge the video, then you do not run in overlay mode. If the scaling remains smooth, then it's an overlay, regardless of the info window.

comment:9 Changed 10 years ago by axeld

Overlay never worked in MediaPlayer. IIRC when you implemented it, you couldn't enable it due to the internal structure of the media buffer handling.

comment:10 Changed 10 years ago by stippi

With so many past examples, I would never rule out me being totally senile. But the way I remember it, I couldn't turn on overlay support in the original framework from Marcus, since the video playback thread would change one video buffer at the time when switching videos, but needed to release and change them all at once.

However, after I rewrote the whole framework to use media nodes, I believe the overlay code was working, especially since exactly that is working in Clockwerk. When you look at the MediaPlayer command line output, you can see it first tries to connect the nodes using B_YCbCr422 format and then retries using B_RGB32.

comment:11 Changed 10 years ago by axeld

All I know is that overlay never worked for me in MediaPlayer, and that you always had an explanation when we talked about it in the past ;-)

comment:12 Changed 10 years ago by axeld

In any case, if it's indeed supposed to work in general, I could have a look, since I have a machine where overlay is working fine.

comment:13 Changed 10 years ago by axeld

Component: Applications/MediaPlayerSystem/Kernel
Resolution: fixed
Status: newclosed

Ah well, reading through the comments already explained everything (and brought the memories back, too ;-)): area_for() did not work on user accessible kernel areas. It now does since hrev32135, and overlay is now working fine.

Note: See TracTickets for help on using tickets.