Capturing Footage in Real-Time Without Additional Hardware from RetroPie’s Libretro Core Emulators
The following guide demonstrates how to enable the capture of real-time gameplay footage from various console systems available in the RetroPie emulator suite, a number of which can utilise the RetroArch framework to provide an integrated audio-video recording facility.
Implemented natively on a standard Raspberry Pi, this approach runs without the need for any external hardware (such as an Elgato capture-card).
Topics
- A Little Background Information
- A Note Before Proceeding
- Installing FFmpeg and Selected Codecs
- Rebuilding RetroArch to Enable FFmpeg Recording
- Checking FFmpeg has Been Enabled in RetroArch
- Activating the RetroArch Recording Features
- Performance Enhancements
- Streaming to Twitch
- Related Posts
- External Links
A Little Background Information
My motivation to undertake what has become a sizeable research, development, and experimentation, project grew from a simple desire to obtain recordings of emulators running under RetroPie. I’d previously managed to enable the audio-video feature provided by the Atari ST emulator, Hatari, and was hopeful that a software-only solution was feasible for other systems.
At time of writing this guide has been tested on RetroPie 3.7, 3.8.1, and 4 (rc-1) setups, all running on installations of Raspbian Jessie 2016-05-27, and RetroPie 4.0.3 installed on Raspbian Jessie with Pixel 2016-09-23
Searching for other emulators offering recording, I found only the non-Libretro variant of Fuse to have in-built facilities; whilst serviceable for capturing ZX Spectrum games, the audio-video files generated by the emulator are of a decidedly non-standard format.
Fundamentally it was my experiments when attempting to transcode footage of Technician Ted captured from Fuse, first with avconv, and later with FFmpeg, and a subsequent enquiry on the RetroPie forum, which spawned the series of articles which form this how-to guide.
For reference, the system used whilst researching this project was a Raspberry Pi 3, overclocked to 1300mhz (please see Overclocking the Raspberry Pi 3: Thermal Limits and Optimising for Single vs Multicore Performance for specifics).
I strongly advise that a full backup be made of the system, as there is no simple method to reverse the actions of the compilation and installation processes described below.
A full image of the Raspberry Pi‘s SD Card can be made using a tool such as Win32DiskImager
Installing FFmpeg and Selected Codecs
The FFmpeg audio-video suite is the key component required to facilitate in-game recording; unfortunately the Raspbian operating system which underpins RetroPie does not come with this collection of tools and codecs pre-installed.
As defined by the project’s Wikipedia page: FFmpeg is a free software project that produces libraries and programs for handling multimedia data.
Obtaining required software on Raspbian is often as simple as using the apt command, specifying the appropriate package to acquire; at time of writing, however, this option cannot be used as neither FFmpeg, nor several required codecs, are available in the repository.
The solution is to obtain the source code and build these components directly; for an all-in-one script which performs this task, and a full description of the process for those interested, please see my guide: Compiling Software from Source Code on the Raspberry Pi: The FFmpeg Suite
Rebuilding RetroArch to Enable FFmpeg Recording
Please see the my earlier post: What is RetroPie? for a little background on RetroPie, RetroArch, and Libretro.
At time of writing, the version of the RetroArch framework implemented by RetroPie specifically excludes the in-built recording facility which utilises FFmpeg, however this feature can be implemented with relative ease.
Please Note: the process listed in this section obtains and builds the latest, not necessarily stable, RetroArch source from GitHub. Should you encounter issues, the solution is to build a specific known-good release of RetroArch. I shall be updating this guide in due course, but for the time being please see the revised instructions in the comments for this post (search this page for “OBTAIN AND BUILD SPECIFIC VERSION OF RETROARCH TO ENABLE FFMPEG RECORDING”).
As explained by RetroPie forum administrator BuZz in the thread containing my initial question regarding in-game recording:
“Assuming you are comfortable in the terminal:
Install your ffmpeg headers etc, then”
cd ~/RetroPie-Setup/ # remove the config that disables ffmpeg on the RPI sed -i "s/--disable-ffmpeg//" scriptmodules/emulators/retroarch.sh # build new retroarch from source sudo ./retropie_packages.sh retroarch # put the file back how it was git checkout scriptmodules/emulators/retroarch.sh
These commands can be executed line-by-line from a terminal; alternatively, should you wish to run the code as a single script:
-
Create a new text file in nano with an appropriate name and an extension of
.sh -
Denote the file as a bash script by entering the first line as:
#!/bin/bash - Copy and paste the code block into the file, then save it.
-
Make the file executable using the
chmodcommand. - Run the script from the command line.
The above code selects the RetroPie-Setup directory, then modifies the retroarch.sh script to remove the parameter which disables the recording subsystem. Next the retropie_packages.sh script is called to fetch, compile, and install RetroArch. Finally a standard version of the retroarch.sh script is retrieved from RetroPie’s github repository.
Given that acquisition, compilation, and installation of FFmpeg is a prerequisite for this process, I’ll not repeat instructions regarding use of the bash command line, the nano text editor, setting permissions, and related tasks. Please refer to Compiling FFmpeg and Codecs from Source Code: All-in-One Script for an illustrated example of creating and executing a script.
It is possible that the retroarch.sh script which is modified at the start of this process may be out of date with respect to the RetroArch source code which is subsequently fetched and built. If in doubt, to avoid issues one option would be to update RetroPie prior to running this code; another approach is to perform this procedure on a fresh installation.
If FFmpeg is not present on the system when RetroArch is built after removing the --disable-ffmpeg switch, or has not been compiled utilising static rather than shared libraries, there will be no warnings or errors, but RetroArch will not contain the recording features.
Checking FFmpeg Has Been Enabled in RetroArch
Once FFmpeg has been compiled and installed, and RetroArch has been rebuilt, it’s worth confirming that the recording facility has been incorporated. This is a simple check as the RetroArch menu (a.k.a RGUI) will contain additional entries if the process has been successful.
In RetroPie 3.x by default a controller which has been setup via Emulation Station will automatically have several hotkey combinations mapped, including select + x to access the RetroArch menu. For further details please see the RetroArch Configuration page on the RetroPie wiki.
Alternatively, with a USB or Bluetooth keyboard connected the RetroArch menu can be accessed via the F1 key.
The changes visible in the GUI menu depend upon the RetroArch version installed, as shown by the number in the buttom-left of the screen.
For RetroArch 1.3.4 or earlier only, after the RGUI menu has loaded, enter the Settings sub menu, and confirm that a new entry for Recording is now present:
In RetroArch 1.3.6. this Recording menu will not be present. This may be explained by the fact that despite RetroArch 1.3.4 containing a Recording menu, it’s not possible to use the options within to directly start and stop the process whilst an emulator is running, nor modify settings including the file name and location, use of a configuration file, or recording of filtered output.
For RetroArch 1.3.4 and 1.3.6, within the Settings menu, select the Driver sub menu. The option for Record Driver should now read ffmpeg rather than null. This confirms that RetroArch recognises and has enabled the FFmpeg suite.
Please note: there does not appear to have been a full 1.3.5 RetroArch release, hence the jump from 1.3.4 to 1.3.6.
Activating the RetroArch Recording Features
At this stage the RetroArch framework has been rebuilt to expose the native FFmpeg-based features, and we can take a final couple of steps to allow recording to commence.
Activation of recording unfortunately cannot be undertaken from within the RetroArch GUI menu, and instead requires that parameters be added to the commands that launch a given emulator; this is achieved via an emulators.cfg configuration file. RetroPie provides a separate config per system, located within /opt/retropie/configs, which contains a series of directories named per machine, rather than per emulator.
An Overview of the Emulators.cfg File
This section provides background information regarding the content of the emulators.cfg file, its role in launching an emulator, and connection to the runcommand menu. Feel free to skip ahead to the next section for details on modifying a configuration file to add recording options.
The entries in the emulators.cfg file play a dual role, both providing the commands to launch an emulator, and being used to display the options in the runcommand “Select Default Emulator” and “Select Emulator for Rom” sub-menus.
The runcommand menu is accessed by pressing any key on the keyboard, or the button mapped as A on a controller, when launching a game from Emulation Station. For details see the RetroPie wiki Runcommand page.
As an example, below is the configuration file for the the Atari VCS emulator, Stella, located at /opt/retropie/configs/atari2600:
lr-stella="/opt/retropie/emulators/retroarch/bin/retroarch -L /opt/retropie/libretrocores/lr-stella/stella_libretro.so --config /opt/retropie/configs/atari2600/retroarch.cfg %ROM%" default="lr-stella" stella="stella -maxres 320x240 %ROM%"
The emulators.cfg file consists of name / value pairs, in the form: parameter = "value". A configuration file can comprise multiple items, which generally allow the selection of different emulators for the same system, as is the case with the N64, Megadrive, and SNES.
The name of the actual Atari 2600 emulator is Stella; as is the convention, the Libretro / RetroArch core version is named with a lr- prefix.
Multiple entries also enable a single emulator to be launched with varying configurations; for example the Atari ST emulator Hatari offers ‘fast’ and ‘compatible’ options, both with and without border display.
In the above example the first line specifies an entry named “lr-stella” (emphasised in bold for clarity), which is the Libretro core version of the Stella emulator. The value for this item consists of the commands used to launch the emulator within the RetroArch framework, loading the rom selected via Emulation Station.
A list of systems and their corresponding emulators can be found on the RetroPie wiki Supported Systems page.
The name “lr-stella” also appears on the second line as the value for the parameter named “default”; this specifies the entry to use when launching any rom for which an emulator has not been explicitly set (via the “Select emulator for rom” sub-menu).
On the final line appears an entry for the non-Libretro core version of the VCS emulator; the name of the executable, stella, appears first, followed by a command line parameter to set the resolution, followed by a variable, %ROM%, representing the selected game to run.
Within the Runcommand “Choose Default Emulator” menu, these emulators.cfg entries appear as follows:
Adding Recording Options to the RetroPie Runcommand Menu
As described in the preceeding section, the emulators.cfg file contains one or more entries which ultimately launch a game selected via Emulation Station within a given emulator.
Using the Atari 2600 as an example, the original entry for the Libretro emulator in the file /opt/retropie/configs/atari2600/emulators.cfg is:
lr-stella="/opt/retropie/emulators/retroarch/bin/retroarch -L /opt/retropie/libretrocores/lr-stella/stella_libretro.so --config /opt/retropie/configs/atari2600/retroarch.cfg %ROM%"
The format of the runcommand entry is as follows:
- Name of entry as it will appear in the runcommand menu (e.g. “lr-stella”)
- Path and filename of the RetroArch executable
-
RetroArch parameter,
-L, used to specify a Libretro core. - Path and filename of the Libretro core shared library.
-
RetroArch parameter,
--config, used to specify an emulator-specific configuration file - Path and filename of the Libretro of the RetroArch emulator-specific configuration file
To activate the FFmpeg recording features, we need to insert an additional parameter, providing the path and filename for the recording output file.
As it’s unlikely that you’ll always want to run the emulator with recording activated, you will probably want to make a copy the original Libretro emulator entry, modifying the name and adding the paramater; the runcommand menu can then be used to quickly choose between recording and non-recording versions of the Libretro emulator.
- First copy the entire “lr-stella=” entry, pasting it back into the file below the original.
- Update the name of the new entry as “lr-stella-record-hdd-noconfig” to make it easily identifiable within the runcommand menu.
-
Immediately after the filename of the Libretro emulator core shared library file (
stella_libretro.so), insert a space and add the--recordparameter, followed by another space. -
Finally, add the full path and filename of the audio-video output file to create:
/media/pi/EXT_HDD/RPi_AVI/recording_VCS.mkv
The entire new line appears as follows:
lr-stella-record-hdd-noconfig="/opt/retropie/emulators/retroarch/bin/retroarch -L /opt/retropie/libretrocores/lr-stella/stella_libretro.so --record /media/pi/EXT_HDD/RPi_AVI/recording_VCS.mkv --config /opt/retropie/configs/atari2600/retroarch.cfg %ROM%"
N.b: I’m directing output to an external hard disk for performance reasons. Please see the section Recording to an External Storage Device, below, for details.
Simply adding the --record parameter is sufficient to activate the recording feature once the emulator is launched, however this causes RetroArch to utilise default FFmpeg parameters which will allow only the least demanding emulators to run at full speed.
All is not lost, however, as we can provide a configuration file to specify custom values allowing real-time recording at 60 FPS even with demanding systems such as the lr-pcsx_reamred PlayStation emulator.
Recording with the Custom RecordConfig Option
Creation and customisation of a recordconfig configuration file is discussed in detail in the Performance Enhancements section, below.
In anticipation, we can add an item to the runcommand entries in the previously modified emulators.cfg to specify the location and name of the FFmpeg configuration file.
- First copy the entire “lr-stella-record-hdd-noconfig=” entry, pasting it back into the file below the original.
- Update the name of the new item as “lr-stella-record-hdd” to distinguish it from the existing entries.
-
Immediately after the path and filename of the
--recordparameter, insert a space, then add the--recordconfigparameter, followed by another space. -
Finally, add the full path and filename of the recording configuration file:
/home/pi/RetroPie/recording/config/config.cfg
The completed additional entry should appear as:
lr-stella-record-hdd="/opt/retropie/emulators/retroarch/bin/retroarch -L /opt/retropie/libretrocores/lr-stella/stella_libretro.so --record /media/pi/EXT_HDD/RPi_AVI/recording_VCS.mkv --recordconfig /home/pi/RetroPie/recording/config/config.cfg --config /opt/retropie/configs/atari2600/retroarch.cfg %ROM%"
The final, updated version of the Stella emulators.cfg file is as follows:
lr-stella="/opt/retropie/emulators/retroarch/bin/retroarch -L /opt/retropie/libretrocores/lr-stella/stella_libretro.so --config /opt/retropie/configs/atari2600/retroarch.cfg %ROM%" lr-stella-record-hdd-noconfig="/opt/retropie/emulators/retroarch/bin/retroarch -L /opt/retropie/libretrocores/lr-stella/stella_libretro.so --record /media/pi/EXT_HDD/RPi_AVI/recording_VCS.mkv --config /opt/retropie/configs/atari2600/retroarch.cfg %ROM%" lr-stella-record-hdd="/opt/retropie/emulators/retroarch/bin/retroarch -L /opt/retropie/libretrocores/lr-stella/stella_libretro.so --record /media/pi/EXT_HDD/RPi_AVI/recording_VCS.mkv --recordconfig /home/pi/RetroPie/recording/config/config.cfg --config /opt/retropie/configs/atari2600/retroarch.cfg %ROM%" default="lr-stella-record-hdd" stella="stella -maxres 320x240 %ROM%"
Following the addition of entries to the emulators.cfg file, the runcommand menu will appear as follows:
Unfortunately it is necessary to repeat the above steps for each Libretro core emulator for which recording is required, as RetroPie maintains a separate emulators.cfg per system; it is possible, however, to utilise a single recording configuration file, as demonstrated in the following section.
As the path and filename for the recording must be supplied via the emulators.cfg file, each time the emulator is launched with the recording parameters any existing file will be overwritten. To partly offset this inconvenience I suffix the output file to identify the emulator; for the Atari 2600 I use recording_VCS.mkv, for the PlayStation recording_PSX.mkv, etc.
If I’m making multiple recordings from the same emulator, the most efficient method to rename files is to remotely connect to the Raspberry Pi via ssh, changing the filename after exiting the emulator and returning to Emulation Station.
UPDATE: RetroPie forum member meleu suggested an improvement to avoid the inconvenience of renaming the file before each emulator launch, by automatically appending the filename with a timestamp (year-month-day-hourminutesecond), for example:
recording_VCS_2016-07-14-221955.mkv
This is achieved by updating the --record parameter as follows:
--record /media/pi/EXT_HDD/RPi_AVI/recording_VCS_$(date +%Y-%m-%d-%H%M%S).mkv
Performance Enhancements
We can utilise two approaches to achieve real-time recording at a full 60FPS even when running demanding emulators such as lr-pcsx-rearmed (PlayStation).
Firstly, it is possible to fully customise the FFmpeg subsystem to minimise the recording overhead. Secondly, we can direct output to a fast external medium, such as a USB hard disk.
Both options, which are best applied in tandem, are demonstrated in the following sections.
Custom FFmpeg Recording Configuration
By supplying a configuration file it is possible to totally customise the FFmpeg subsystem to achieve far better recording performance (albeit whilst necessarily trading some quality for speed).
Without a configuration file, recording utilises the following FFmpeg settings, according to the RetroArch wiki:
“By default… lossless coding is used. This means libx264/RGB, with -qp 0… The audio codec used is FLAC. libx264/RGB ensures very nice bitrates even when lossless and very fast encoding.”
Real-time recording using these default settings is possible, but only on RetroArch emulators which do not overly tax the system, such as the Atari 2600.
I have determined that the equivalent configuration settings, as specified in a recordconfig file are as follows:
vcodec = libx264rgb
pix_fmt = bgr24
acodec = flac
format = matroska
video_qp = 0
The name and location of the file specified via the --recordconfig parameter is entirely arbitrary, providing that the directories in the path exist and the file itself is accessible to the pi user. I created a couple of subdirectories below the standard RetroPie user location:
/home/pi/RetroPie/recording/config
As per the examples in the preceeding sections, I named my custom recording configuration file config.cfg, and placed it within the new /recording/config directory hierarchy.
In order to achieve real-time recording at a full 60fps (Ntfs) or 50fps (Pal) in emulators up to and including the PlayStation, I augmented the default FFmpeg configuration with settings to reduce the overhead of recording. The content of my config.cfg is as follows:
format = matroska
threads = 3
vcodec = libx264rgb
video_preset = ultrafast
video_tune = animation
pix_fmt = bgr24
video_qp = 0
acodec = flac
Once the configuration file has been created with the above content, and saved to the location specified in the the emulators.cfg file as specified previously, launching the emulator with the appropriate runcommand entry should automatically begin generating a recording file.
Recording ends when the emulator is exited. Unfortunately it is not currently possible to start, stop, or otherwise alter the recording from within the RetroArch GUI menu.
Please note: When the PlayStation emulator is running with the enhanced graphics mode enabled, the recording outputs blank video in place of all 3D visuals.
Tuning the FFmpeg Recording Configuration
For those interested in further tuning the recording configuration file, the following analysis of the recording configuration file content may be of use:
threads = 3 allows FFmpeg to utilise three of the Pi Model 2 or Model 3‘s processor cores (leaving one for the single-core emulator itself).
video_preset = ultrafast is an x264 video codec specific preset, which itself incorporates a large number of configuration values which enable the encoder to consume far less resources, whilst maintaining a high quality output file.
video_tune = animation this setting fine-tunes the video compression for animation, which in common with retro-gaming graphics, tends to have large areas of static and similar-coloured output.
The permutations are nearly endless, and whilst I spent considerable time experimenting until I was able to achieve high-quality 60fps real-time recording with the PlayStation emulator, the configuration can doubtlessly be improved upon.
When tuning the settings, much depends on which codecs, and versions thereof, you incorporate into your FFmpeg build. Many settings are specific to the video and audio codec specified. The FFmpeg project site includes copious, very detailed documentation.
It appears that the values are parsed from the configuration file by RetroArch without any re-ordering; this is significant as they are used to directly drive the FFmpeg tool, which requires that parameters are passed in a specific order.
Mixing the parameters for one codec by passing them after specifying another invariably causes problems. Please see the FFmpeg documentation regarding parameter placement.
Recording to an External Storage Device
The overhead of recording whilst running an emulator is greatly reduced if the output is directed to an fast external storage device, such as a hard drive, rather than to the Pi‘s SD Card.
In tests, a standard USB 2 hard disk allows real-time recording at a full 60 FPS in emulators ranging from the relatively undemanding Atari 2600, through the Megadrive and SNES, and up to the comparatively complex PlayStation. I’ve not yet tested recording within the Libretro incarnation of the N64 emulator Mupen64plus.
In comparison, when directing output to a fast internally mounted SanDisk Class 10 48MB/s SD Card, the more demanding emulators suffered a noticeable drop in performance.
For details on mounting an external USB hard disk, at boot and within Emulation Station, please see my companion guide: Automatically Mounting an External USB Hard Disk on the Raspberry Pi
Where an emulator is launched via a runcommand which directs recording output to an external storage device, in the event that the drive is not connected or not mapped to expected mount point, the emulator runs as normal; no errors or warnings will be displayed, and nothing will be reported in runcommand.log.
Streaming to Twitch
Whilst I had planned to investigate and include information regarding using RetroArch’s FFmpeg facilities to live-stream from Libretro emulators to Twitch, circumstances have transpired which have precluded this. Perhaps at some point I shall return to this aspect of the project.
In the meantime there is a section on the RetroArch wiki covering FFmpeg Recording and Live Streaming which provides a sample recordconfig file. It is likely that the custom config outlined earlier, combined with the stream-specific settings from the wiki example, will enable operation with Twitch.
The configuration file as it appears on the aforementioned site is as follows:
vcodec = libx264 acodec = libmp3lame pix_fmt = yuv420p scale_factor = 2 threads = 3 video_crf = 25 video_preset = superfast video_tune = animation audio_global_quality = 75 sample_rate = 44100 format = flv
The provided RetroArch recording parameter from the same site is:
--record rtmp://live.twitch.tv/app/$YOUR_TWITCH_ID --recordconfig twitch.cfg
A Labour of Love
Retro Resolution is entirely a labour of love. Please consider offering a donation if the information here has helped illuminate, enlighten, or otherwise assisted you!
Related Posts
- Links: Raspberry Pi and Gaming Emulation via RetroPie
- Compiling Software from Source Code on the Raspberry Pi: The FFmpeg Suite
- Automatically Mounting an External USB Hard Disk on the Raspberry Pi
- PlayStation Emulation on the Pi: Enhancing the Experience with the Options Menu – Part Two: Graphics
- Atari ST and STe Computing on the Raspberry Pi with RetroPie’s Hatari Emulator
External Links
- FFmpeg project documentation
- RetroArch wiki: FFmpeg Recording and Live Streaming
About
Disclaimers
Privacy Policy
Terms and Conditions
© Retro Resolution
Retro Resolution: video gaming 
Hi, I don’t know if you can help but I followed your instructions and the overlay menu (or rgui as it is described on RetroPie page) won’t show anymore.
I noticed when I tried to verify if ffmpeg was there. The select+X hockey hangs the emulators, although I can still use RetroPie trough SSH.
I don’t know if the freeze is related to the modifications presented here tough, since I didn’t even knew this menu existed before this.
Anyway, any touths?
LikeLike
Hi,
Sorry to hear about your difficulties with this. I have a couple of ideas:-
Is the RetroPie installation where you rebuilt RetroArch up-to-date? As mentioned in the guide, it’s possible that if you have an older installation that you could end up with a version of retroarch that is newer (potentially incompatible), as rebuilding fetches the latest version of Retroarch.
Secondly, you could try rebuilding retroarch again, without removing the “disable-ffmpeg” parameter, to see if this is causing an issue.
The newest build I’ve tested against is version 4 release candidate 1.
LikeLike
I’m using RetroPie 4.0.2, it’s a fresh install but yes, maybe they update something since I installed it 2 days ago.
How do I rebuild it? Kinda noob here.
LikeLike
I’m happy to help via this thread, but I’m also on the RetroPie forum, which is very active and a great source of information; below is a link to a thread where I posted about this guide, and have assisted some forum users with various issues:
https://retropie.org.uk/forum/topic/2394/how-to-guide-recording-live-gameplay-in-retropie-s-retroarch-emulators-natively-on-the-raspberry-pi-and-twitch-streaming
LikeLike
Could you let me know which version of RetroPie you have installed, and also (assuming you can get it to display) the version of RetroArch (displayed in the bottom-left if the RGUI menu)?
LikeLike
It’s a fresh installed RetroPie 4.0.2. Got my Raspberry 3 three days ago. Will try rebuild it, can it be done trough the retropie-setup menu?
LikeLike
Hi,
Thanks for the feedback. I’ve updated my test system this afternoon, and found that something’s changed between 4 rc-1 and 4.0.2 regarding the menu – visually it’s very different, although I can launch the menu without any problems. I’m not sure why you can’t launch the menu.
Does RGUI work if you load it directly from the RetroPie menu in EmulationStation (rather than from within a running emulator)?
Regarding the actual recording, I found that I can still record using VCS and Megadrive, but I can’t with PlayStation games any longer – the emulator launches then immediately returns to Emulation Station. A segmentation fault is logged in /dev/shm/runcommand.log (they’ve moved the location of the log files since 4 rc-1 as well…)
I’ve started a new topic on the RetroPie forum, which I’m hoping should aid me in investigating this:
https://retropie.org.uk/forum/topic/3728/playstation-ffmpeg-recording-causes-seg-fault-in-retropie-4-0-2-recording-megadrive-vcs-etc-still-fine
If you use the RetroPie setup and update everything, it should pull the latest versions for you, using the binary builds. When RetroArch is rebuilt to incorporate FFmpeg, this pulls the latest source code and builds it locally on your Pi – it appears that this is pulling a somewhat newer version, as it has a very different UI (although it still reports the same version number 1.3.6).
Hopefully if somebody responds to my RetroPie forum post I can find a way to pull a specific commit of RetroArch from Git, as a work-around for the recording issue (assuming that this is a RetroArch problem and not some change in the PSX emulator).
LikeLike
The problem is apparently in the very latest RetroArch version – I replaced my RetroPie 4.0.2’s RetroArch with the ffmpeg-enabled version 1.3.4 from my RetroPie 3.8 system and was able to record from the PlayStation.
I initially tried replacing the lr-pcsx-rearmed PlayStation core from my RetroPie 3.8 build, but as expected it made no difference (both are version r22).
Unfortunately I didn’t back up my RetroPie 4 rc1’s ffmpeg-enabled build of RetroArch 1.3.6 before I updated everything earlier. I need to look into pulling and building a specific version of RetroArch.
LikeLike
I’m far from my Pi right now and can’t test if the Rgui works from Emulationstation. Will test later. I’m also following the forum treads that you linked. Do you prefer that I answer you back here or in one of the treads?
LikeLike
Here’s fine – at the moment – worth monitoring the forum thread though.
Forum admin BuZz says RetroPie’s Retroarch isn’t forked from the main libretro project (seems it was in the past – retropie’s github page still has it listed as a fork).
I have located the source for Retroarch 1.3.6 as released on 17th July:
https://github.com/libretro/RetroArch/archive/v1.3.6.tar.gz
Later I’ll grab it via wget and look at building it with ffmpeg enabled (I’ll need to investigate and modify retropie’s retroarch setup script to prevent it grabbing the latest source, and make it use a specific version instead)
LikeLike
From tests it seems that sometime in the last few days some changes have been made to RetroArch 1.3.6; as well as adding a very funky new UI, when recording is enabled using FFmpeg something fails when the PlayStation emulator lr-pcsx-rearmed is used (as soon as ‘runcommand’ starts the emulator segmentation faults are logged, and the system returns to Emulation Station). Recording from VCS, Megadrive, 32X, and SNES were all working as normal.
[Edit] the ‘funky new ui’ is, according to friends on the RetroPie forum, actually an old RGUI menu theme, ‘xbm’, which somehow became enabled as the latest RetroArch source was built.
I have determined the steps required to pull a specific version of RetroArch from the Git archive (in this case 1.3.6 as released on 17th July), and have the existing RetroPie setup system build this (instead of the default behaviour of pulling the very latest source code).
I’ll write this up as an addendum to my original guide, but for now the required process is:
(These instructions are clearer in my forum post, as they use markdown formatting which clarifies the commands:
https://retropie.org.uk/forum/topic/2394/how-to-guide-recording-live-gameplay-in-retropie-s-retroarch-emulators-natively-on-the-raspberry-pi-and-twitch-streaming/43)
OBTAIN AND BUILD SPECIFIC VERSION OF RETROARCH TO ENABLE FFMPEG RECORDING
[edit – updated 28th September 2016 – adding manual ./configure step due to minor change in build subsystem; adding sudo to various commands following change in permissions of temporary build directories; adding creation of temporary build directories]
Modify the RetroPie setup script for RetroArch:
cd /home/pi/RetroPie-Setup
If the following directories are not already present:
sudo mkdir tmp
sudo mkdir tmp/build
remove parameter which is disabling ffmpeg in retroarch:
sed -i “s/–disable-ffmpeg//” scriptmodules/emulators/retroarch.sh
Edit the script to prevent call which obtains the very latest version of RetroArch source from git repository:
sed -i ‘s@(gitPullOrClone “$md_build” https://github.com/libretro/RetroArch.git)@#\1@’ scriptmodules/emulators/retroarch.sh
Obtain RetroArch version 1.3.6 (as a tar) from the git archive:
cd /home/pi/RetroPie-Setup/tmp/build
sudo wget https://github.com/libretro/RetroArch/archive/v1.3.6.tar.gz
Unpack tar archive file:
sudo tar xzvf v1.3.6.tar.gz
Remove the tar file:
sudo rm v1.3.6.tar.gz
Rename directory to that expected by setup script:
sudo mv RetroArch-1.3.6/ retroarch
cd retroarch
Manually run the configuration script for RetroArch
sudo ./configure
Run the setup script to build RetroArch 1.3.6 with ffmpeg enabled:
cd /home/pi/RetroPie-Setup
sudo ./retropie_packages.sh retroarch
Replace the modified script file (to prevent issues when running future updates via the retropie setup script, due to uncommitted changes in the local git repository casused by modifying this file)
git checkout scriptmodules/emulators/retroarch.sh
NOTE:
after running the script, the temporary build folder should be empty
/home/pi/RetroPie-Setup/tmp/build
…and /opt/retropie/emulators/retroarchshould contain the freshly rebuilt version 1.3.6 retroarch
LikeLike
Hey, got home and tried to test the Rgui again. Tryed to open it at Emulationstatio screen, no good, maybe I did something wrong but the “select+X” wont work. Then I start the Sega Genesis emulator, hit the hotkey and, surprise, it opened… But quite different, now I see what you have been talking about a complete different Rgui. If I try this at the Super Nintendo emulator it still freezes.
So, I think it’s safe to say that the problem is with the new Rgui. I’ll now update everything and follow your nes instructions. No need to recompile ffmpeg right?
Feedback you later. Thanks for the help until now. (Oh, and sorry my bad english man, not my native language).
LikeLike
Your English is fine – don’t worry!
No need to rebuild ffmpeg again; the new instructions will fetch a stable version of source code for retroarch 1.3.6 (as used in earlier RetroPie 4.x builds). I tested it successfully using Atari VCS, megadrive, 32X, SNES, and PlayStation.
Any problems, just leave a comment, and I’ll try to help.
By the way, according to a couple of forum users, the ‘new’ GUI is actually old, it’s the xbm ui – for whatever reason the very latest source code caused it to be selected ip(there’s an entry in rgui for this). I was helping a forum user investigate this, but ran into unrelated stability problems on my Pi which needed my attention this evening.
LikeLike
To open RGUI in Emulation Station, you go to the RetroPie menu (tjis appears as a system, like SNES, Ports, etc); there’s a ‘retroarch’ entry in this menu to launch the retroarch rgui directly – it isn’t run using the hotkey / button combination (that’s used only once a emulator is running).
LikeLike
Ok man, IT DID IT. Follow your instructions, the freeze is gone and I can acces Retroarch outside emulators, found a new world of configurations to try. And, as expected, the ffmpeg is show as record drive. Now I’ll finish your guide and update you when I succesly record something.
Again, thank you A LOT!!!
LikeLike
Brilliant news, glad to help – and you helped me refine the process too; it was a always a bit brittle the old way, at the mercy of the latest cutting edge RetroArch source.
Now RetroArch can be built against a known-good version suitable for specific releases of RetroPie (such as RetroArch 1.3.4 for RetroPie 3.8; RetroArch 1.3.6 for RetroPie 4rc1, 4.9.2)
LikeLike
Oh, just one more thing. When I did the “git pull scriptmodules/emulators/retroarch.sh” it went wrong. Returned the follow msg “fatal: Invalid gitfile format: scriptmodules/emulators/retroarch.sh
Fatal: Could not read from remote repository.
Please make sure you have the correct access rights and the repository exists.”
LikeLike
[Edit]
My mistake, the correct command is:
git checkout scriptmodules/emulators/retroarch.sh
My apologies
LikeLike
No problem. Just tested record a snes gameplay. Worked well, although the emulator got reeeally slow.
Don’t know if it’s because I record to a pendrive (maybe the pendrive is garbage, who knows) or if it’s because I did not overclock (planing to do it next, also using your guide).
But it worked, the video was fine, sound clean, awesome all the way.
LikeLike
Great to hear it’s recording now.
If you direct output to an external USB hard drive you’ll be able to achieve a full 60fps whilst recording even with more demanding emulators, including the PlayStation. (The N64 is a stretch though, given the generally poor performance of the RetroArch core version of Mupen64, and N64 emulation in general).
I’ve not tried recording to a USB flash drive, but when outputting to the internal micro SD I saw slowdown on most emulators – the Atari VCS was fine though.
Flash drives vary greatly in performance, and generally use cheap NAND memory which generally offers poor write performance, although you can get drives with decent speeds.
I can really only vouch for use of usb-2 connected mechanical hard drives; I use the VCS, Spectrum (Fuse), Megadrive, 32X, SNES, Atari 800 (with a custom-built RetroArch core), and PlayStation emulators to record – all output at full frame rate whilst recording. I don’t think overclocking is required, although my machine is currently running 1300mhz CPU and 500mhz GPU.
LikeLike
Well, I do have a external HDD, will try today and let you know. Again, thanks for everything man.
LikeLike
You’re very welcome! Hope you have a smooth experience with the USB hard disk.
LikeLike
Ok. I do have a external HDD, will try and let you know later. Again, thank you for everything man.
LikeLike
Hey, Hi again. I finally had the time to test record the gameplay with my USB HDD and It wont work. I don’t know why.
My HDD actually mount at /media/usb0, same as my Pendrive, the configuration on emulator.cfg is right. Works with the pendrive but not with my HDD…Don’t know where I’m getting it wrong.
LikeLike
Ok, forget the last post. It works. The problem was with my HD. I formated it and everything star to work. Had zero lag, was amazin. You were right, USB HDD is the way to go.
I tryed to find alternate configurations to video quality but the ffmpeg site is hard to ready. The output video with your config is a little blurry while on my TV it’s damm sharp.
Figure it is like this because compression? Don’t undestand about video quality yet. I pretend to make a retro game channel on youtube. I’m from Brazil and here whe don’t have many channels about it, figure that a better video quality would be important.
LikeLike
Hi,
Good to hear it’s recording smoothly to an external usb hard disk now.
Is your output about the same quality as the videos I have posted to the RetroResolution YouTube channel (including the video at the start of the guide)?
(Ensure that the video quality option in your YouTube player is set to 720p for best results)
The recording approach which uses the configuration file does add compression which reduces the video quality; it’s a necessary trade-off to allow for full 60fps recording from complex emulators such as the PlayStation.
For the simpler emulators, such as the Atari VCS, you can use the recording mode where no custom config is supplied – this gives a lossless, pixel-sharp result, but it takes a lot of processing time.
I’m sure that a more efficient combination of options in the custom config is possible, but I spent a long time getting a balance to obtain reasonable output from the PlayStation – ffmpeg is very complex…
A couple of other points to bare in mind –
Firstly, YouTube appears to be adding a level of compression itself when video is uploaded, especially if that video is the low resolution native to retro consoles.
Before uploading I transcode the video, resizing it so that it is treated by YouTube as 720p HD. This really improves the quality.
The second point is regarding the transcoding; I haven’t found a way to avoid a little loss of quality when processing to resize and / or make the format compatible with sites including Twitter. I do use the highest quality setting, however, so the increase in encoding artifacts is minimal.
LikeLike
Regarding transcoding:
Please see the section named “Using FFmpeg to Transcode Files: Examples”, in the guide “Compiling Software from Source Code on the Raspberry Pi: The FFmpeg Suite”:
https://retroresolution.com/2016/05/31/compiling-software-from-source-code-on-the-raspberry-pi-the-ffmpeg-suite/#li_ffmpeg_transcode
The following is the final transcoding example I provided, which resizes the video and allows uploading to Twitter or YouTube, by changing the video format. Please see the aforementioned section for details:
————
Set a combination of parameters to output a file suitable for uploading to Twitter (4:2:0 Planar x264 video, at 30 fps, with near-lossless compression, scaled to twice the input file resolution, with aac encoded audio) :-
ffmpeg -i input.mkv -threads 2 -c:v libx264 -qp 1 -r 30 -pix_fmt yuv420p -vf scale=-1:ih*2 -c:a aac output.mp4
—————
Twitter needs a frame rate of less than 30fps, but for YouTube you can remove the “-r 30″ parameter.
As I recall YouTube also allows the planar 4:4:4 video format, so you can also ommit ” -pix_fmt yuv420p”
LikeLike
Hey, thanks again. Will play a bit with config. Right now I’m trying to understand FFMPEG.
Anyways, thanks a lot. You helped me a lot.
LikeLike
You’re welcome. I’m interested to hear how you get on – good luck with your YouTube channel
LikeLike
Hey, how are you?
So, have being messing around video quality on FFMPEG and found that your settings are actually very good indeed. Even if I suppress the config file the gain in quality is not that great, but the performance loss is. So, I’m sticking to your settings.
Also, funny thing. For some reason I lost the configuration. Retroarch did not show ffmpeg as record driver anymore. So I did all the tutorial again, recopile ffmpeg and retroarch. Before force the installation of a specific version of Retroarch I decided to test again the one wich gave problem to us and, surprise, it actually works now, even with that different interface.
So maybe all that procedure to get the more stable Retroarch wont be necessary anymore
Anyways, thanks again.
LikeLike
Hi,
Thanks for the feedback, I really appreciate it.
I assume a change has been made in the RetroArch github repo which fixes whatever was causing the problem with lr-pcsx-rearmed, sometime in the last couple of weeks. I’m glad it’s working without the additional steps.
I still ought to include the notes on pulling and compiling a specific version of RetroArch though, as it’s good to build against a known-good version.
Glad you found my config settings to be pretty optimal – I spent a ridiculous amount of effort testing different combinations!
LikeLike
Thanks for the great post. I was able to follow along with your instructions and get recording working on my RetroPie. I created a blog post detailing my results: How To Record A GamePlay Video From A RetroPie but I could not have done it without your post and hard work.
Great stuff and thanks for sharing!
LikeLike
Thank you! I’m glad you were also successful in getting recording to work from RetroPie.
LikeLike
Great in-depth guide you have there, by the way. Appreciate the links!
LikeLike
Thanks! You deserve the links, for the most part I was just following your lead.
I posted this in the forums but I got Twitch streaming going: How To Live Stream To Twitch from a RetroPie I’m still working on the FFmpeg settings as there still is some lag on the Pi.
LikeLike
Fantastic! I’d been trying to find a combination of custom ffmpeg settings for streaming which would prevent RetroArch throwing an error; so glad you’ve managed to find settings which work.
I’ll update my guide to link to Selsine’s Twitch streaming article; for the time being, here are Selsine’s custom ffmpeg config settings:
vcodec = libx264
acodec = libfdk_aac
pix_fmt = yuv420p
threads = 2
scale_factor = 1
format = flv
video_preset = ultrafast
video_profile = baseline
video_tune = animation
video_level = 1.2
sample_rate = 44100
audio_preset = aac_he_v2
As Selsine notes:
“They give you decent performance while you are playing and still stream to twitch. The issue with these settings is that they give your stream an “acceptable” rating on Twitch which isn’t what we want in the end. Consider these settings a work in progress.”
LikeLike
Selsine has updated the custom ffmpeg config settings to give better performance, and an ‘excellent’ rating from Twitch. Brilliant work!
For instructions on fully implementing Twitch streaming, please see Selsine’s excellent guide (linked in the post above)
vcodec = libx264
acodec = libfdk_aac
pix_fmt = yuv420p
threads = 2
scale_factor = 1
format = flv
video_preset = ultrafast
video_profile = main
video_tune = animation
video_bufsize = 512k
video_minrate = 512k
video_maxrate = 512k
video_r = 60
video_g = 120
video_keyint_min = 60
sample_rate = 44100
audio_preset = aac_he_v2
audio_global_quality = 1
Selsine notes: “There is only a bit of audio distortion and the stream now gets an excellent rating on Twitch”
LikeLike
Hey dude!
I’m trying to write a personal customized RetroPie script module to automate the steps to make RetroArch able to record a gameplay.
I think that there’s a lot of steps that aren’t so trivial to automate, for example those codecs that needs to be downloaded/compiled in a specific version…
To simplify a little (at least for the first tests) I would like to ask you: What codecs are really necessary to get only the gameplay recording capability? (no need for streaming to twitch for a while)
I’m asking it because that libopus does not seem to be necessary (based on its description).
LikeLiked by 1 person
Good question. I’d assume you can get away with just including whichever codecs you specify in the custom ffmpeg options – e.g. flac audio, libx264 video. I’m not sure if container support for Matroska is built in – the ffmpeg documentation is comprehensive, but somewhat daunting.
I’ve not tried cutting back ffmpeg / codecs itself, as just getting a working recording, and writing the guides, took a huge effort and I was simply elated to have it working!
Really interested to see what you can achieve. I’d love to get the streaming working, but am on other projects at the moment.
LikeLiked by 1 person
In my guide I did show how to grab and build a specific release of ffmpeg itself; depending upon the structure of the repository from which individual codecs are obtained, you should be able to script the build of specific versions.
I was able to build a known-good version of retroarch itself as well, although that’s a hybrid approach, utilising slightly modified RetroPie build scripts (it’s in the comments section below the article itself. I meant to write it up properly. I think you’ve seen this on the RetroPie forum, thinking back)
LikeLiked by 1 person
I thought your issue in RetroArch was the xmb menu_driver only. Did you faced some other problem?
BTW, I think I’ve already said but I say it again: I really appreciate your detailed writing style. 🙂
LikeLike
Hi,
There was a problem with xmb being defaulted in a specific retroarch build in September; that same build also prevented recording from the lr-pcsx-rearmed PlayStation emulator – for me this was the bigger issue.
Shortly after I’d worked around this by forcing use of a specific version of retroarch, both issues were resolved. That’s the risk of using the ‘build from source’ option, as overnight source may well contain bugs!
LikeLike
Thanks for your positive comments regarding my writing, I very much appreciate it!
LikeLiked by 1 person
Hello, first let me say that your instructions are some of the best I have ever seen in regards to learning about this. Secondly I have a question as I just seem to be having issues with recording Genesis/Megadrive games. Using the lr-genesis-plus-gx emulator the game plays fine and records, but it is audio only. The lr-picodrive allows video to be captured but the gameplay becomes super choppy. I currently do not have the pi overclocked, and I am utilizing the recommended settings in the config file as well as playing around with the number of threads. I am playing the roms from a usb thumbdrive and writing to the same drive or a different drive with the same results. Is there any advise on why the lr-genesis-plus-gx is refusing to allow video, or a recommendation for the picodrive performance? If you have answered this already, I do apologize.
LikeLike
Hi,
Thank you for your kind words regarding the guide, they are very much appreciated.
I believe that the issue with the choppy performance whilst recording, in the case of picodrive, is that you are writing the output to a USB thumb drive.
Earlier in this comments thread another reader had a similar issue, which was resolved by recording to a USB hard disk (discussion with
Thiago, comments posted September 2nd 2016).Most USB flash drives unfortunately have very poor write performance, which causes the described issues in the emulator as the system pauses as the data is saved. I was able to record from the Atari VCS emulator, Stella, to the Pi’s SD card without issue, mainly as the relatively static display requires lower data throughput.
With a USB hard drive, flawless recording is possible even when running relatively complex emulators, including Ltd d for PlayStation gaming.
Regarding the audio-only recording with the lr-genesis emulator, I must admit that I’ve not used this; the only other emulator I’ve seen this occur on is the PC Engine, but I do not know why (it may be a RetroArch issue in general, as opposed to the Raspberry Pi implementation specifically).
I hope thus helps you achieve smooth audio/video recording; please leave a comment to let me know how you get on.
LikeLike
Great work on the guide, thank you very much! Using scale_factor on the cfg to double the resolution really ramps up the CPU usage to make it impossible! I found a way to make it work and failed to get a recording thus far though.
Raspberry Pi 3 has an integrated hardware encoder, dubbed h264_omx and to use it you need to compile ffmpeg with these added:
–enable-omx
–enable-omx-rpi
–enable-mmal
I compiled FFMPEG with these, but when I choose h264_omx as my encoder it results in an empty recording. What am I doing wrong?
Also, most encoders and formats do not work, which is really super weird.
LikeLike
Ran into a bunch of issues with this. Retropie 4.1 with rpi 3:
After compiling ffmpeg, emulationstation didn’t start correctly… Had to do an apt-get install vlc (although I saw that install libvlc5 was enough)
Trying to ./retropie-packages.sh retroarch after removing the –disable-ffmpeg part of the script failed with a Hunk FAILED on some patch diff file. Solution was to go in the retropie setup script, remove retroarch and install it again from sources. Then everything worked!
Thank you!
LikeLike
Thanks for the feedback; glad you found a solution.
RetroPie is a moving target comprising a myriad components from disparate sources, and there have been problems in the past as a component has been updated and either includes a breaking change, or an outright bug.
Unfortunately testing the setup process outlined in the guide is too time consuming to repeat for every RetroPie release. I very much appreciate you sharing your experience and your solution.
LikeLike