lazy l3ib ramblings

nobody really does anything.

HTPC adventure updates

holy wall of text

I’ve changed my 24hz modeline to this:

Modeline “1920x1080@23.976” 74.25 1920 2558 2602 2752 1080 1084 1089 1125 +hsync +vsync

glxgears says it’s a bit faster than 23.976Hz, but mplayer is perfectly smooth. On that note, there were two mplayer issues that I encountered and seem to have solved.

The first problem is correct colorspace conversion (YUV to RGB). The xorg radeon driver’s xv output and mplayer’s opengl output both originally output RGB values in the range [0,255], which is correct for a computer monitor. However, TVs are designed to work with [16,235].

Both of the mentioned output drivers use pixel shaders to go from YUV to RGB. Modifying the fragment program in radeon’s xv output looked extremely painful. However, mplayer’s opengl output allows one to use an arbitrary fragment program. With debugging enabled, it spits out the fragment program that it generated (in case you haven’t supplied your own.)

I started with the fragment program generated by mplayer -vo gl:colorspace=2:levelconv=2. This actually gives correct output, except that it allows for the possibility of output values outside of the range [16,235]. Fixing this was trivial. The resulting fragment program can be used with mplayer -vo gl:customprog=/path/to/pro.fp.

The second problem was that every so often, the video would appear to “jump” or “skip”. This is solved using mplayer -mc 0, to disable A-V sync correction. However, it is desirable to have A-V sync correction when playback starts and when seeking. To fix this, I did a quick hackjob @ mplayer.c to disable correction once the A-V difference is within a certain range, and re-enable it during seeking.

I also had some problems with xmms2 and HDMI audio output. xmms2 expects write operations to the sound card to block until they are completed. For some reason, the mysterious alsa radeon hdmi thingy driver blocks for too long. To fix this, I did a quick hack which ensures non-zero available space in the sound buffer before trying to write to it. I should probably submit a bug report at some point…

  1. l3ib posted this
More Information