[vlc-devel] Re: vlc: svn commit r13909 (jpsaman)
jean-paul.saman at planet.nl
Mon Jan 16 08:53:37 CET 2006
Paul Sokolovsky wrote:
> Hello vlc-devel,
>>r13909 | jpsaman | 2006-01-14 10:36:16 +0100 (Sat, 14 Jan 2006) | 1 line
>> M /trunk/modules/access/dshow/common.h
>> M /trunk/modules/access/dshow/dshow.cpp
>>Revert revision 13903. It is implemented in a different way by checking if the
>>option --dshow-chroma is set. If it is set then the chroma is forced, otherwise
>>it is not. This should solve the regression of previous commit, by letting users
>>specify the chroma type to use. To get the previous default behaviour specify IV420
>>as preferred chroma type either on the commandline or in the Capture Device advanced tab.
> Thanks for fixing this! But I'm not entirely sure it really does
> exactly that. So, now, if dshow-croma is specified, it will enumerate only
> metiatypes compatible with specified chroma, but then again will add
> *hardcoded* I420 to the list which will likely be selected due to its
> priority. Some next poor guy might bang his head against this issue
Well, I currently don't understand that part of the code very well.
Therefor I only do some minimal changes till I or someone else has time
to make a *good* solution.
> Well, I guess the current aim is to fix reported issue and don't
> remove the previous behavior completely, possibly because it was known
> to solve some issue previously and cannot be readily tested now. But
> what device needs that anyway?
Apparently some encoder cards (Osprey, etc.). I got a report from one of
the VideoLAN testers that his encoder cards stopped working with your
patch, so I reverted it. It looks that some cards need a predefined chroma.
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html
More information about the vlc-devel