Hi! On Wed, Jul 07, 2010 at 12:42:38PM -0700, Niels Mayer wrote: > Thanks for your help and response... > > FYI, here's a few bug reports/feature-missing things: > > (1) I finally figured out those flashing squares that appear every > time gst123 changes songs. It's album-art images, displayed in an X > window! These need to stay up longer, as only by forcing the audio > device to be busy and playing back a giant directory of files, I was > able to actually see that these are windows containing images, and not > some weird new display-glitching bug caused by KDE's "Smooth Tasks" > widget. To be useful, the display of the image needs to be held for a > certain amount of time after you're sure the window-system has > actually rendered the image. Perhaps a single integer option > --albumart-time -- when set to 0 image display is suppressed, > otherwise, an integer like 1000 which would hold the album-art image > for 1 second. > > (And yes, I realize that a fix for this issue is easily had in my > script "play-cd" (shorthand for play sound only @ 44.1, vs "play-tv" > w/ X/Video @ 48k): > | #!/bin/sh > | args="`/bin/ls -d $*`" > | export DISPLAY='' > | exec gst123 -a alsa=mythcd $args > )
I didn't explicitely do anything to make the pictures come up. Its just that gst123 will try to decode everything that is on the play list, audio files, video files and other files. Normally other files are not a problem, because gst123 will detect that it can not read the file, and remove it from the playlist. However, GStreamer will decode images like album art, so they are flashing up, and once the decoding is done disappear again. I am not sure yet how to fix this. One could simply blacklist some filename patterns (like *.jpg, *.png, ...), but then again, a file called this way could theoretically contain an ogg file. Also the blacklist might not be complete. So what would be better would be to use the same strategy GStreamer uses to figure out the right decoding object, and then blacklist some of those. In any case, I've added this item to the TODO, and of course I'll also accept patches. > (2) Sometimes video windows come up at the wrong size (tiny). You can > resize them with the window manager and resize it back and get the > correct aspect. Or you can quit and run it again and find it sized > correctly. I had hoped that this would no longer be an issue, because of the changes that I made some time ago. But if it is still happening, it should be fixed. You also may be able to correct this using the "1" or "f" keys. I've added this item to the TODO. > (3) Is there a way to create a specific, stable, window-name for the > video window created, perhaps settable as commandline parameter. That > way for captions, you don't really need to worry about "overwriting" > the video with transparent letters like you would on an actual TV > caption. Instead, wrap your program in an external program such as > Python, or WINTERP (*) that "captures" the video window (much like a > window manager would, or how "mplayer" windows are displayed insider > wrappers like smplayer kmplayer etc) and parses the time-data-stream > information continuously output by gst123. Below the video window you > stick a text widget and display caption text independently of the > video. There's really no need to overlay and worry about transparency > mapping through letters and slowing down the rendering, and all that > potential, hardware-dependent fail. Stick the text in a GUI toolkit > where all the region and language issues can be handled > appropriately... Such tools are happy to update a few times a second > to display new captions while X is off rendering the video (or > stepping out of the way) in the most efficient, platform-independent > manner available. Right, it might be nice to have a window title parameter which can contain some special sequences (like %f for the filename being played, or %t and %T for time and total time), so that the window title can be used to output something useful. However, I think that gst123 should be able to display seek position without any extra programs, because most users will just install gst123 and use it as it is. About winterp: looks like a program which could be used to do some interesting things. However, I would recommend using something else as scripting language, not scheme. My experience with scheme is that it is so totally unlike most programming languages, that you need to think a lot more to get anything done or understand any code, even if you are normally good at programming. Python might be a better choice, because it doesn't have such a different structure than C / C++ / Java (which many programmers know already). Cu... Stefan -- Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev