From: James S. <jst...@fa...> - 2003-06-26 20:41:12
|
Hi Guenter, > efficiency, especially cache-efficiency is the key here. so the plugin > interface has to be designed very carefully. besides that, no objections Efficiency is exactly what I had in mind when I was thinking about this. I was trying to add copying by slices to the ffmpeg decoder but found it much harder than it should have been because of the postprocessing code being in there. I know we've discussed this before in relation to RGB frame formats, but I'd still like to see more support for displaying video in it's native format rather than converting everything to yv12/yuy2. I'm not suggesting we add every format under the sun, just a few of the more common ones (e.g. yuv 4:1:1 for dv and 4:1:0 for svq1). > well, just make a proposal then :) renaming config options shouldn't be > too much of a problem, i think it can be done without breaking the api > so this could be done incrementally as well. I'm going on holiday on saturday and have a day on the train, so I may well come back with something in a couple of weeks. > why not give this feature a chance? so far, no frontend i know has > implemented this correctly. most frontends do not implement it at all > (e.g. gxine), others (e.g. xine-ui) got the concept completely wrong. > > anyway, i think having those experience levels shouldn't hurt anyone Sure, if the consensus is that they should be kept, then they should be kept. Out of interest, how would a frontend implement them correctly? James. |