RetroFE forums
General Category => General Discussion & Help => Topic started by: Multiplexer on December 29, 2016, 11:54:20 PM
-
Hi,
I appear to be having a couple of issues. The first is an intermittent controller problem using a dual shock 2 (Using rockfire usb) and dual shock 4 controller over bluetooth or usb.
Sometimes they work perfectly fine, other times RetroFE seems to buffer the buttons that are pressed, for example you could press the up button 10 times and nothing will happen, 20 seconds later all 10 presses will happen all at the same time. There also seems to be problems using an Xbox controller. I am currently using windows 10 Pro x64 but this problem existed with windows 7 also and with all releases of RetroFe that I have tried.
The second problem I appear to be having is that when playing platform videos, the audio will randomly stop part way through. This seems to be more of a problem when a 1920x1080 is reduced size within a theme. Just in case it is conflicting hardware, this is my PC spec. Intel core i7 2600K, AMD Radeon R9 390, Sound Blaster Recon 3D PCIe.
Other than these 2 problems, RetroFE is Excellent. The best frontend I have tried including one I have paid for!
-
I'm not entirely happy with the event handling either; I don't have your specific issues, but I too see some irregularities when it comes to handling (keyboard in my case) input. Currently, input handling for the menus is handled separately in two different locations: the main handler looks at the input, and changes some internal states, and the menu itself handles the scrolling based on the internal state. I've been thinking about combining that in one location, but it will require a bit of structure rethinking. It has my attention though.
With regards to your videos: I encountered that issue in the past as well. I was under the impression that it was caused by a lack of hardware support for the video playback in combination with a slow CPU. It disappeared when I switched my CPU to turbo mode. Considering your CPU however (way faster than mine) I may need to rethink the source of this problem. RetroFE currently uses the gstreamer video library, and I've considered switching to another library for quite some time now. I may need to give that another look.
-
The input handler rewrite is coming along quite nicely. 😀
Sent from my SM-G920F using Tapatalk
-
Cool. Looking forward to the next release
-
I am also looking forward to the next release. The other problem, which has been mentioned before is that RetroFE always crashes on exit when there is a controller connected. This occurs with all 3 that I have. Dual shock 2, Dual Shock 4 and Xbox. The error pop up only occurs when windows error reporting is switched off (which I do), otherwise it silently crashes but is still logged in Windows Event Viewer:-
Faulting application name: retrofe.exe, version: 0.0.0.0, time stamp: 0x5807355e
Faulting module name: SDL2.dll, version: 2.0.4.0, time stamp: 0x5771dbfc
Exception code: 0xc0000005
Fault offset: 0x00145169
Faulting process ID: 0x1670
Faulting application start time: 0x01d26538a61a8fa9
Faulting application path: E:\RetroFE\core\retrofe.exe
Faulting module path: E:\RetroFE\core\SDL2.dll
Report ID: d785c078-0478-4abc-83b6-3a01b4aff312
Faulting package full name:
Faulting package-relative application ID:
-
Yes, I'm familiar with that issue, but I haven't been able to reproduce it yet. I'm working on a Windows compile and debug environment though (I hardly ever use Windows, so it's a bit of a learning curve). Once I can reproduce it I can generally fix it. This is one of those times when it would really be useful to have more C++ developers working on a program, preferably on different operating systems. :)
-
Controller crash issue is fixed in bit bucket.
Sent from my SM-G920F using Tapatalk
-
Great, Thanks!
-
Regarding the video issues: I notice my CPU has so little to do that it drops down to 800 MHz, which may cause the video playback issues... I haven't been able to stop it from doing that yet. 😢
Sent from my SM-G920F using Tapatalk
-
I was working a while ago on the video playback issues with gstreamer; I discovered that in some situations, the videos end up getting converted to a color format that isn't natively supported and thus requires a second color format conversion step even when decode acceleration is enabled. There are a couple of other inefficiencies as well (the code manually copies each video frame into a SDL texture, for example), but my experimentation at the time got confounded with some flaky hardware and trying to test on multiple platforms. I just recently fixed the flaky hardware, so I may take a crack at it again, but it was not an easy path to pursue! The interactions of gstreamer in its various versions, the OS video acceleration support with various cards and kernel and driver versions, SDL in its various versions, and the multithreaded RetroFE code was very frustrating at times.
When you just fire up the gstreamer command-line tools, they auto-configure to get the most efficient video playback possible, but this ends up being through a video overlay rather than integrating into a pre-existing display framework like SDL. This means that gstreamer is often decoding video frames directly into video memory, with no extra copies or translation. Efficiently getting video frames into SDL textures via gstreamer in a way that works for everyone was the source of most of my difficulty. Using a different video library might help, but I think a lot of the underlying difficulties will remain.
-
Regarding the audio associated with the video:
Currently RetroFE sets some "capabilities" for the video to a specific format and manually copies the frames into SDL textures, but doesn't specify anything about the audio. This means it'll automatically select the "best" audio playback for your system configuration, but it's going to be opening a separate connection to your system's audio framework than the one SDL is using for playing the sound effects associated with switching items and opening menus. When I tried running RetroFE on a Linux system that didn't have PulseAudio running, this meant that SDL grabbed the ALSA interface and neither the videos nor any games I launched were able to open the audio interface to play sound!
I made a pull request a while back that tried to address those problems by copying audio samples into SDL the same way video frames are, and by closing the audio interface before launching a game, but I think there may be some potential deadlock situations still lurking in the code that manages the audio and video locks, and my flaky hardware issues mentioned previously made me put off trying to fix it and re-upload at the time. I should try fixing this again with the latest version, though.
-
Please do. Provided it's stable, I'm very open to using a new video library.
Sent from my SM-G920F using Tapatalk
-
I'm not sure switching to a different video library would be as effective as just using gstreamer better; it's very full-featured and even has plugins to use most of the other video libraries, like the ffmpeg ones. At this point I've invested a lot of time in figuring out how gstreamer works, and I'm sure there's a significant learning curve for all the cross-platform video playback libraries.
Last night I got a significant improvement to video playback working, at least on a couple of Linux machines I had handy. I'll do more testing with Mac and Windows soon, but here's what I found:
1. The code was selecting the YUY2 pixel encoding for the raw video frames; this is a packed YUV format, which is a common default for streaming video sources like USB webcams, but is almost never used by stored media codecs such as the ones we use for screen-capture videos or DVD/BluRay. This meant that gstreamer automatically added a conversion layer in its decode process that would translate the native layered YUV (usually I420/IYUV) output of the codec, necessitating an entire buffer copy and software loop over each video frame before we even got access to it.
2. Each GstBuffer, which contains references to the raw video data for a frame, was being copied into a new buffer we allocated as soon as we received it. Then, on the display loop execution, we would copy that buffer's contents into the video's SDL Texture. This is an unnecessary extra copy of the frame data, which slows things down again a bit, and discards the metadata associated with the buffer. Instead of copying the data, I just increase the refcount on the GstBuffer and store that; then my display routine copies directly from the GstBuffer to the SDL Texture and decrements the GstBuffer refcount when it's done.
3. The current code doesn't take into account some subtleties of how the raw video frame data is sometimes stored. I have some handheld emulation videos (GameBoy varieties) that displayed in a garbled manner because the video data is not contiguous in the frame buffer; each line is padded out to a power of 2 by the codec and the display routines are expected to deal with the difference between the video's horizontal resolution and the larger 'stride' of the data buffer, which was not being done. When the buffer data is non-contiguous, gstreamer adds a GstVideoMeta structure to each GstBuffer; this describes the offset and stride of each plane in the buffer (they're not the same size, since each U or V sample covers the space of 4 Y samples in I420, for example) in a way that allows them to be mapped separately and passed into SDL_UpdateYUVTexture function. After adding this, all my videos played correctly!
I had perceptibly slow video playback and some input response lag on my i5 NUC machine, but it's apparently full-speed and more responsive to control input after my changes. I'll test them on Mac and Windows and some other Linux machines and then make a pull request once I'm fairly confident I didn't introduce any problems.
-
Great news! Looking forward to it. I've also checked in some changes, so this should make a nice set for 0.7.20b4. I'm working towards a 0.7.20 full release again soon.
Sent from my SM-G920F using Tapatalk
-
Me too. In the mean time the solution for me was to just re-encode the video in the same resolution as that to which I wanted to show. Works perfectly then. As for the controller, that is now working great, thank you. I wish I knew how to do programming because I would love to help. As it stands the extent of my programming skills was when I had a C64 and I could do:
10 PRINT "HELLO"
20 GOTO 10
RUN
Man, I wish I had applied myself more at school!
-
The pull request for this is up now; I've tested the build on Linux, Mac, and Windows.
-
The pull request for this is up now; I've tested the build on Linux, Mac, and Windows.
I saw it, thank you. :) I'll give it a few tests myself, and then merge it with the main base.
-
I've seen no issues; I've merged it with the main branch. :)
-
I'm not sure if it's related but I've noticed video distortion on many videos (~50% of a large collection) since syncing to head this weekend, most of mine are from emumovies for reference
(http://i68.tinypic.com/hvoytc.png)
-
Fyi I'm running a windows build on Win 10
-
Can you send me one to test with?
Sent from my SM-G920F using Tapatalk
-
Sure, do you have somewhere I can upload to? I don't want to use a video hosting site since it will probably reconvert. Alternatively if you have an emumovies account an the video above is just the wonderswan system movie from their ftp
-
If it's below 4 MB you can upload it here; otherwise you could use dropbox, MEGA or Google Drive. You can even try to email me. :)
If that's a problem, I'll see if I can find it on the EmuMovies FTP tomorrow.
-
Looks like the limit for attachments is 4Mb, I've PM'd you a link
-
Oddly enough, that's what a lot of my handheld system videos looked like *before* the changes I made. I did test on Windows 10, but I didn't have any of the funky-resolution handheld system videos on that machine, so I'll have to see if I can reproduce it there with the videos I've got. It's definitely an error relating to the embedded padding that occurs when the video resolution isn't a power-of-2, and this also throws off the offsets of the various layers in the buffer, so the chroma samples aren't applied properly.
I think what happened is that whichever codec got loaded in your pipeline didn't set the VideoMeta on the buffer that would describe how the layers are packed in the buffer, so the code assumed that they were packed contiguously. But I previously wrote some code that can figure out the packing just based on the resolution and the buffer size, so I should be able to slip that in for the case where the size doesn't match what we expect for a contiguously-packed buffer.
-
If that's the same video for the Wonderswan that is currently available here: http://emumovies.com/files/file/1092-wonderswan-system-intro-video-hq-480p/ then it's not a matter of which video; it plays fine on my machine. I've implemented the code that calculates the strides/offsets without the metadata and verified that it continues to play it correctly on my machine, but it's possible something else strange is going on. I'll try this video out on a couple of other environments and see if I can provoke a failure to verify my fix on, but I think it'll work.
-
I have forwarded the link to you, PinealServo. I can confirm that this video causes issues on my Linux system as well. I haven't tried it on my Windows machine yet.
I've had similar issues with videos before this change as well, so it's not limited to the change you made. It's just different videos causing the issue now. :)
-
I think I finally got this one licked. Hopefully all the videos will play correctly now, aside from aspect ratio issues for videos with non-square pixels.
-
That's good to hear. :) As soon as the aspect ratio also works I plan to do some last testing (already did some testing with your latest build), and import it into the main branch. Since it also contains support for multiple key assignment I'll need to check further how your change compares to the code Catelite sent me for that purpose. For the future, let's make sure we mention what feature we work on in the development thread so we don't all work on the same feature. :)
-
I'm not sure if it's related but I've noticed video distortion on many videos (~50% of a large collection) since syncing to head this weekend, most of mine are from emumovies for reference
Can you retest with the latest code? Your multiple key support should be in there as well, and I haven't had any video issues yet.
Slight warning: it seems the libgstvideo-1.0.0.dll needs an update; I get an error under Windows regarding the gst_buffer_get_video_meta procedure.
-
Great :) I'll sync up and test tonight, thx!
-
For those of you pulling from bitbucket: I did some more investigation into the issue relating to libgstvideo, and it turns out that since the gstreamer binary libraries were last updated in the repository, the gstreamer headers (which you have to install separately for development at this point) changed slightly so that what was once a macro got changed to a function. If you installed gstreamer 1.6 or newer on Windows, you'll run into this problem and you'll get a pop-up window telling you about a DLL problem. Note that you don't get any benefit from having newer gstreamer libraries installed; when you run RetroFE as packaged in the Artifacts directory, it uses the version from the repo rather than the one you built against the headers of. Until the libraries in the repo are updated, or some other solution is put in place, I'd recommend installing and building against gstreamer 1.4 if you hit the problem.
On Linux and Mac, there aren't any binary libraries in the repo, so this mismatch doesn't occur. You'll build with the same headers that your version of the installed libraries were built with, so it will all match up and be happy.
-
Videos looking good again on windows here too, thx PinealServo :)
-
Any thoughts regarding our options? Should we upgrade to a later gstreamer version or should people who compile use an older version?
Sent from my SM-G920F using Tapatalk
-
There are two other options I can see:
1. Include the header files for gstreamer in the ThirdParty directory like we do with the SDL libs. Including the whole as-installed gstreamer directory could be rather large, though.
2. There's old code in the python script, currently commented out, that would pull the gstreamer libraries from the same place the headers are installed. If we fix that, we could remove the 'core' directory in the repository.
None of the options are a perfect solution, but that's dependency management for you. :)