Opened 14 years ago
Last modified 4 years ago
#6656 new bug
Overlay does not work anymore
Reported by: | axeld | Owned by: | stippi |
---|---|---|---|
Priority: | normal | Milestone: | R1.1 |
Component: | Applications/MediaPlayer | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
After a long pause, I've updated my main machine to hrev38768 that has overlay support. After Stippi's recent MediaPlayer changes, I don't seem to have any overlay anymore, the image just stays black.
Attachments (2)
Change History (11)
comment:1 by , 14 years ago
comment:2 by , 14 years ago
Will try this later today, as I'm experiencing the same problem on my Radeon.
comment:3 by , 14 years ago
I don't see a call to SetBufferGroup() in ::Connected(), nor anywhere else in the MediaPlayer here, though Video/AudioProducer do implement calls by that name. Am I missing something?
comment:4 by , 14 years ago
Sorry abou that, it's SetOutputBuffersFor() in VideoConsumer::Connected().
comment:5 by , 14 years ago
Enclosing that call in an if (!fTryOverlay) { block results in overlay behaving over here. At least I assume it is since I see a correct image, and attempting a screenshot simply gets a black area for the image as expected. Anything else you want me to test?
comment:6 by , 14 years ago
Thanks for the test. Disabled shared BBufferGroup in overlay mode in hrev38834. Perhaps I don't have time to investigate this, especially since I would have to replace my graphics board, which I probably won't do (that board is buggy with my monitor resolution).
comment:7 by , 14 years ago
Not sure if this is related (or a driver issue)
see attached overlay vs non-overlay under the Radeon video driver (ATI x300). Tested on hrev40692 gcc4 hybrid.
(x300-overlay vs x300-no-overlay)
by , 14 years ago
Attachment: | x300-no-overlay.jpg added |
---|
by , 14 years ago
Attachment: | x300-overlay.jpg added |
---|
comment:8 by , 13 years ago
comment:9 by , 4 years ago
Milestone: | R1 → R1.1 |
---|
You could do a quick check if my recent fix for the producer to actually use the consumer buffers made the difference: In VideoConsumer::Connected (IIRC), there is a call to SetBufferGroup(). Disable that call if it's running in overlay mode. If that gives you back overlays, it means there is an unnecessary memcpy() involved again, and it probably hints at a problem with mapping the overlay BBitmap area_id for creating the BBuffers. One curiosity I observed was that the BBuffers ->Data() pointers are different from the BBitmap ->Bits() pointer after the mapping, however, it's indeed the same memory block (at least in non-overlay mode).