[vlc-devel] Re: vlc: svn commit r13909 (jpsaman)

[Jean-Paul Saman]

Paul Sokolovsky wrote:
> Hello vlc-devel,
> 
> 
>>r13909 | jpsaman | 2006-01-14 10:36:16 +0100 (Sat, 14 Jan 2006) | 1 line
>>Changed paths:
>>   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.

Regards,
Jean-Paul Saman.

-- 
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html