[MEncoder-users] V210 10-bit 422 Output

[Larry Reznick]

RC wrote:
> On Thu, 14 Aug 2008 07:24:57 -0700
> Larry Reznick <lreznick at idistream.com> wrote:
>
>   
>> It seems to me you would know that because when I added v210 support
>> to  codecs.conf I posted how to do it to the MPlayer list and you were
>> involved in an aspect of the discussion. 
>>     
>
> One thread 6+ months ago, and I'm supposed to immediately remember you
> or the codec by name, and so is everyone else on this list?
>   

I didn't expect you to remember the thread, but if the term "v210" threw 
you, I would have thought you'd do a bit of research before answering. 
BTW, interesting how the support for the dll exists as of "6+ months 
ago" but the entry I posted back then about interfacing it in 
codecs.conf never seems to have made it into the svn distribution of 
codecs.conf.

>> I want that data as it comes, not processed  through some conversion
>> filter that might reduce the quality. 
>>     
>
> Well, you already have the data "as it comes" in the file.  If the
> container is a problem, you could easily use mplayer -dumpvideo.  I
> assume you're "decoding" it with MPlayer for some reason...
>
> And as long as you're converting to a color space with a higher
> bit-depth, there's no inherent reason for any loss.  Whether libsws is
> bit-accurate or not (for speed/quality reasons) is an open question. 

It seemed to me that the data would be encoded using v210. The dumpvideo 
option wouldn't deliver raw frame format but the v210 elementary stream, 
wouldn't it? I want a raw form -- the 10-bit YUV 4:2:2 frames -- so that 
would have to be decoded, right? When I'm dealing with 420 frames and I 
want raw, I'll use MPlayer or MEncoder to deliver YUV4MPEG2 or raw. 
Without the ability to select a 10-bit 422 format, I can't get these 
frames in their 422 format. Certainly, RGB format would be a higher 
bit-depth, but the software variation I'm generating these for must test 
with 10-bit 422.


--Larry