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