Opened 17 years ago
Closed 15 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: | ||
Platform: | x86 |
Description (last modified by )
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 by , 17 years ago
comment:2 by , 17 years ago
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 by , 17 years ago
Description: | modified (diff) |
---|
comment:4 by , 17 years ago
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 by , 17 years ago
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 by , 17 years ago
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 by , 15 years ago
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 by , 15 years ago
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 by , 15 years ago
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 by , 15 years ago
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 by , 15 years ago
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 by , 15 years ago
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 by , 15 years ago
Component: | Applications/MediaPlayer → System/Kernel |
---|---|
Resolution: | → fixed |
Status: | new → closed |
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.
I'd question whether the Radeon overlay is working. Would be good to know what overlay format is being requested.