Possible problems for fbcon, DirectFB, etc
on
XFree86 Alters License
·
· Score: 2, Informative
If the new license is generally seen to be GPL incompatible, this could make things more difficult for GPL projects such as fbcon, DirectFB or even mplayer's output drivers that are based on drivers from XFree86.
Paul: You mention that it makes little sense to sync audio to video and then state that this is what most applications do.
On the contrary, syncing video output to the audio is much easier, since audio resampling is a big pain. It's much easier to just watch the soundcard buffer and decide approximately when to show the frame as you imply. You only run into big difficulties when you want to sync audio to the video (or more accurately, sync video blits and audio output to the vertical refresh rate of your output device).
There are times when this is a very important. You imply that video framerates are between 20-30fps, which is quite small. For playback of video sources we need to handle framerates of 50fps and 59.94fps. At such a high framerate, the monitor refresh must track the video input in order to achieve smooth video. See the link to Dave Marsh's faq on judder I mention in the article.
In these cases, you need to set the monitor to the correct refresh rate and then watch the error between the refresh and the sound card clock, and resample the audio when necessary: playing with the refresh rate on the fly would cause a monitor resync and disturb playback!
If video cards let applications drive the refresh of the monitor (software genlock), we could run it based on the audio clock and get the advantages you describe. However given the current state of the hardware it's better to do these small resamplings. That said, actually doing this in linux is still infeasible without some updates to the APIs and drivers, which we are working on.
I would recommend making sure you are accounting for the gamma of your monitor in your matricies. That is, your transforms should be, R'G'B'->RGB->XYZ->L*a*b* and then compare. You can also try making comparitions in L*u'v' space, which is also supposed to be "perceptually uniform". You should also generate some gradients in L*a*b* space and see if they match some you might find on the web.
That said, both of these colour spaces are really only approximations, and I think they'll be weighted towards uniformity in pure colours. Maybe a colour that pulls from a wider range of the spectrum like orange or gold might be smaller than the green or blue areas. I'm going to try and generate some test images to verify this either way.
To nitpick, MJPEG uses Y'CbCr at 4:2:0 sampling, so your chroma samples cover four pixels in the current field.
The NTSC version of the DV codec does use 4:1:1 sampling, however each chroma sample still covers four pixels in the current field, so you're not getting any more quality. It's just a different way of sampling.
I still don't understand why people are so bent on seeing a dvd on their massive 21 inch monitor rather than their 36 inch tv
Quality. A north american TV runs at approximately 60hz interlaced, so each of those 60 frames is at half vertical resolution. With DVDs, you have the possibility (with a good software player) of watching a movie at the original 24 progressive frames per second, which means each frame gets the full resolution.
Also, if you have a projector which takes in VGA input, you get those full progressive frames on a big screen.
This whole.web stuff between Chris Ambler's IOD and IANA/NSI/ICANN has been going on for a long time, and it was never pretty. There is no obvious winner here, so be careful when picking sides.
Even if you don't like big corporate money-sucking NSI, it's difficult to feel fuzzy about wanna-be big corporate money-sucking IOD.
The OpenIM I-D that was submitted to the IETF is basically a requirements/architecture for a server-server protocol. However, they don't talk any specifics. It seems that the intent was to respond to the IETF's call-for-proposals by saying "We don't want to open our protocol, and we don't want to have to implement an IETF standard protocol.".
There are many reasons why investigating server-server protocols rather than peer-peer protocols is a bad idea. Some of them are:
Server-Server protocols push intelligence and state into the network, forcing us to rely on these 'conversion servers' very heavily. This is generally considered to be 'a bad thing'.
Loss of consistent namespace. Messaging 'oim:icq:6028461' rather than 'sip:vektor@div8.net'.
Increased difficulty in implementing end-to-end security and authentication, since we can't rely on the signalling to help, and we have to talk through a proxy at all times.
The other main problem with their proposal is that they group presence information propagation and instant messaging into one system with no logical separation.
I'm the author of kphone, a VoIP application for KDE 2.0 which uses the SIP signalling protocol for call setup.
SIP is the IETF standard for signalling of VoIP calls (as well as other multimedia conferences). It is supported in products by 3Com, Nortel, Cisco,... Very cool.
You can check it out in the kdenonbeta package of KDE 2.0.
Slashdot Mirror
If the new license is generally seen to be GPL incompatible, this could make things more difficult for GPL projects such as fbcon, DirectFB or even mplayer's output drivers that are based on drivers from XFree86.
Paul: You mention that it makes little sense to sync audio to video and then state that this is what most applications do.
On the contrary, syncing video output to the audio is much easier, since audio resampling is a big pain. It's much easier to just watch the soundcard buffer and decide approximately when to show the frame as you imply. You only run into big difficulties when you want to sync audio to the video (or more accurately, sync video blits and audio output to the vertical refresh rate of your output device).
There are times when this is a very important. You imply that video framerates are between 20-30fps, which is quite small. For playback of video sources we need to handle framerates of 50fps and 59.94fps. At such a high framerate, the monitor refresh must track the video input in order to achieve smooth video. See the link to Dave Marsh's faq on judder I mention in the article.
In these cases, you need to set the monitor to the correct refresh rate and then watch the error between the refresh and the sound card clock, and resample the audio when necessary: playing with the refresh rate on the fly would cause a monitor resync and disturb playback!
If video cards let applications drive the refresh of the monitor (software genlock), we could run it based on the audio clock and get the advantages you describe. However given the current state of the hardware it's better to do these small resamplings. That said, actually doing this in linux is still infeasible without some updates to the APIs and drivers, which we are working on.
-Billy Biggs
I would recommend making sure you are accounting for the gamma of your monitor in your matricies. That is, your transforms should be, R'G'B'->RGB->XYZ->L*a*b* and then compare. You can also try making comparitions in L*u'v' space, which is also supposed to be "perceptually uniform". You should also generate some gradients in L*a*b* space and see if they match some you might find on the web.
That said, both of these colour spaces are really only approximations, and I think they'll be weighted towards uniformity in pure colours. Maybe a colour that pulls from a wider range of the spectrum like orange or gold might be smaller than the green or blue areas. I'm going to try and generate some test images to verify this either way.
To nitpick, MJPEG uses Y'CbCr at 4:2:0 sampling, so your chroma samples cover four pixels in the current field.
The NTSC version of the DV codec does use 4:1:1 sampling, however each chroma sample still covers four pixels in the current field, so you're not getting any more quality. It's just a different way of sampling.
Quality. A north american TV runs at approximately 60hz interlaced, so each of those 60 frames is at half vertical resolution. With DVDs, you have the possibility (with a good software player) of watching a movie at the original 24 progressive frames per second, which means each frame gets the full resolution.
Also, if you have a projector which takes in VGA input, you get those full progressive frames on a big screen.
Even if you don't like big corporate money-sucking NSI, it's difficult to feel fuzzy about wanna-be big corporate money-sucking IOD.
There are many reasons why investigating server-server protocols rather than peer-peer protocols is a bad idea. Some of them are:
- Server-Server protocols push intelligence and state into the network, forcing us to rely on these 'conversion servers' very heavily. This is generally considered to be 'a bad thing'.
- Loss of consistent namespace. Messaging 'oim:icq:6028461' rather than 'sip:vektor@div8.net'.
- Increased difficulty in implementing end-to-end security and authentication, since we can't rely on the signalling to help, and we have to talk through a proxy at all times.
The other main problem with their proposal is that they group presence information propagation and instant messaging into one system with no logical separation.SIP is the IETF standard for signalling of VoIP calls (as well as other multimedia conferences). It is supported in products by 3Com, Nortel, Cisco, ... Very cool.
You can check it out in the kdenonbeta package of KDE 2.0.