Please do not post a support request without first reading and following the advice in

[SCRIPT] RetroPie Convert Videos

  • @hiulit I have some changes to the script that fixes a few things

    1. Fixes the "converted-" folder issue with the first converted video
    2. Checks the result of avconv and if it failed it logs the result code and renames the file <rom>-video.mp4-failed so that you don't unknowingly stomp your valid video with a now corrupt one. ( which I certainly never did, just looking out for other folks ;) )

    I can email it to you?

  • @meleu It's needs a little love, but it's ok! Thanks! ;)

  • @alturis Hi there! If you have a GitHub account, I would prefer if you could create a Pull Request If not, you can find my email at ;) Thanks a lot!

  • @hiulit Hmm.. I do have a github account and use it quite a lot to work on my own projects. But I dont have much experience using it in this respect. It looks to me like in order to create a pull request I first need to be able to create my own branch of it. Which it is saying I do not have permission to do when I try it.

    Ah ok i see. I am able to create a fork and create a pull request that way. Done.

  • I've just released Retropie-Convert-Videos v1.0.2.


    • Fixed some outputs.
    • Fixed git clone URL in


  • @hiulit I have forked your repository here and modified your script so it uses ffmpeg and encode with VAAPI acceleration on a generic host machine (assuming that a VAAPI compatible GPU is present)
    The results are pretty good speed wise (and also quality wise). The script takes the original video bitrate and set it for the encoded yuv420p. I am no expert of bash so there are few limitation, one is that the home directory is set in the script itself
    Maybe you can/will merge everything in your script and adapt it so it can run on retropie or host and select the correct encoding?

  • @Menion said in [SCRIPT] RetroPie Convert Videos:

    I am no expert of bash so there are few limitation, one is that the home directory is set in the script itself

    Just curious, why didn't you use the original home detection or the config variant you still have as a comment in your script?

  • @Clyde because the modified script shall run on a host pc without requiring to have Retropie

  • @Menion Perfectly understandable, but reading the rom path from the cfg file or as an command line argument wouldn't be Retropie-dependant either, and yet more consistant with the other options.

    Just some friendly feedback. And thanks for mentioning me in the credits. 😊

  • The script requires improvement, but I am very bad in bash script

  • @Menion I would be very much inclined to help you, but my bash skills are extremely limited, too. My video conversion script is an example of the maximum level of my bash knowledge, and even for that I had to do some web research. Maybe @hiulit can give you some clues.

  • No problem. Meanwhile I need to figure out why the bitrate set seems to produce odd results. Without specifying anything the encoding goes up to double the bitrate of the original file, while setting it the result is 40% less. I know that with single pass enconding the bitrate cannot be precise, but this is a little bit too much

  • @Menion Hey, thanks!

    A couple of questions:

    • Does your script work with a Raspberry Pi? Or does it only work on a "host" machine?
    • Does your script only work with VAAPI compatible GPUs? And if so, how could we detect it with the script?

    About merging your script with mine, I would be more inclined in creating a new branch and having two separate scripts, the "default" one and the "host version" one.

    Also, right now i don't have that much time to take a deep look at your script to check it but I'll try in some time soon(ish).

    PS. I'm with @Clyde about using home="$(get_config "home")" instead of hardcoding it into the script ;)

  • The script should work with any vaapi host, but there is no detection of it, it is just hard coded

  • @hiulit
    I've started to use your script and works like a charm. I've even modified it to support video scrapes attained by using Skyscraper on the retropie. I was just wondering though the following.

    1- When the conversion is done, the converted videos are put into the converted directory, correct? can these then be copied back to the original directory to override the bad videos to reduce space usage?

    2- Also if I use the --convert-system flag and let say I already converted a set of videos but then scrape new ones. Will re-running the conversion tool reconvert all the videos or just those that had not been done? If it's all the videos is there a why to just convert specific videos.

  • @furnace Hey thanks! I'm glad you find it useful :D

    It would be great if you can show me what modifications you've done, so maybe I can merge it with my version. Do you have a GitHub account to create a Pull request to my repository with you changes?

    Now, I'm talking without looking at the code:

    1. The script creates this converted folder so you can check if the videos are converted correctly or not. If not, they will a -failed suffix. The ones that are converted successfully are to be copied manually to the proper folder. I didn't code it in the script just in case anything goes wrong with the conversion.

    2. I think it won't reconvert all the videos. Well, it depends, if you pass a from_color argument, the script will only search for the videos that have that particular "color encoding system". If you don't pass any from_color then yes, it will reconvert all the videos. I think.

    In that latter case, I think I will try and add another option to the script to detect the "color encoding system" of the videos you want to encode.

  • @hiulit

    Thanks for the feedback.

    Sorry I don't have a github account. To modify the scripts though it was fairly simple. Steven Selph's Scraper will put the videos in a folder call video within the ROM folder. Skyscraper can be set to do the same, except the path will be $home/Retropie/roms/media/videos. So all I did was change the VIDEOS_DIR to the proper path.

    Also your script looks for video file names that end in "-video.mp4", I replaced that to *.mp4 because the video file names are different between the two.

    I had not set the from_color parameter before, so I'll test that out. Though I had tried to take a video that was not functional with the OMX enabled and pass it to AVprobe as per you script to see the encoding and it returned yuv420p. But once I convert them they are functional. I'm thinking the conversion might change something else which enables the functionality with OMX enabled. I'll keep investigating this and let you know.

  • @furnace I can try to do something to "detect" the folders. And yeah, I think I can change the -video.mp4 for just .mp4. Thanks!

  • @hiulit
    Or just as you force the customer to set the -to-color, you could just make the user to set a variable like
    -source_scraper in the config to shelp or skyscraper and based on this set the video path. Cause I doubt someone would use various scrapers for different systems.

  • @furnace Yeah, something like that could work. Thanks!

Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.

Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.