Feature #583

ffaudio patch that adds Video-playing option for mp4, flv, etc. files and streams

Added by Jim Turner over 5 years ago. Updated over 5 years ago.

Target version:
Start date:
October 29, 2015
Due date:
% Done:


Estimated time:
Affects version:


Please consider adding this patch for ffaudio-core which adds a config option to pop up a window to play the video part of streams handled by ffaudio, while using Audacious' controls and other audio plugins! Let me know if you find any issues that need to be addressed to get this into mainline.

See recent Plugin Forum thread for more details at

I have hacked up ffaudio (, adding SDL to the Makefile and a new [ffaudio] section to the config file to enable an optional VIDEO popup window for ffaudio-supported formats that include video streams, to play the video portion in sync with the audio and controlled by the Audacious controls (start, stop, pause, and seek slider, etc.) It seems to work well and smooth (IMHO) with all the mp4, m4a, flv, swf. etc. files and streams I've thrown at it, including live-streaming Youtube videos via youtube-dl (after I added some queueing tricks). I've done my best not to alter any of the audio-processing, and let the audio processing drive the video. Normal Audacious operation should not be effected unless the user specifically adds the [ffaudio] section and the option "play_video=TRUE" to the config file.

Though not intended to replace full-featured video-players, it fully achieves my goal of a simple "visualization" window that displays the video! I built against my v. 3.6.0 version of Audacious, but since I couldn't build the current GIT version due to conflicts with my development (hacked v. 3.6.0) environment in /usr/local/, I checked the differences between my original and the latest GIT version finding only a single line (line 377) difference (I added the new tta extension at the bottom to mine). See the comment in my new version containing "BUILD NOTE" to tweak for current version of Audacious!

Please feel free to test out and comment!

config file additions (optional):


play_video=FALSE    #Set to true if you want popup video visualization window, false for normal Audacious operation.
video_qsize=16      #Useful values: 8-56 or so.  Not enough=jittery video, too many=audio/video noticably out of sync.
video_sws_scale=16  #SWS_BICUBIC - see Libswscale before changing this value, default should work fine for most.
video_windowtitle=Audacious    #Text you want shown in the window's title bar. (default: nothing)
video_xmove=0       #-1, 0, 1, or 2 (see code comments) - Controls how/where window is placed on screen.
video_xsize=0       #-1, 0, or fixed width (see code comments) -1=restore to saved width, use aspect to recalc. height
video_ysize=0       #-1, 0, or fixed height                    ", 0=use video's height
                    #Best to specify only xsize OR ysize as non-zero and let Audacious calculate to preserve aspect.
video_resizedelay=0 #millisecs to delay after resizing video window, experiment if you have issues.

Also, is there a way for me to build and install for testing purposes your latest GIT version (in /usr/) while not affecting my own current (3.6.0) development / current use build that is in /usr/local/ ? (I can't compile your latest GIT version of the plugins without removing my local build since the compile tries to reference /usr/LOCAL/include/libaudcore...)


Jim Turner

TO DO?: 1) Add some code above the "#ifndef _WINDOWS" lines for X-specific stuff in Windows, I almost certain it can be done, as I saw some examples, but I have no way to compile or test on Windows. 2) Add some sort of checkbox under Services.plugins.Input.ffmpeg.settings for play_video, maybe? 3) Special characters in the "video_windowtitle=<string>" option to allow for inclusion of song tile, artist, file name, etc. in the pop up window titlebar? Can you think of anything else? (40.3 KB) Source Jim Turner, October 29, 2015 06:59 (34.8 KB) Jim Turner, October 29, 2015 06:59
Makefile.diff (330 Bytes) Makefile.diff Jim Turner, October 29, 2015 06:59


#1 Updated by John Lindgren over 5 years ago

  • Status changed from New to Rejected

I don't think so. Even if this code looked more robust and less like a quick hack, we're not prepared to handle the whole host of new bugs that video playback opens up. As I said before, the world has video players already. Let's not try to reinvent the wheel.

Also available in: Atom PDF