Re: [MCF-Devel] Re: Pixel format suggestions for MCF

mf wrote:
> [email protected] wrote:
> 
>> Are the Dshow-based players out there all that primitive that they 
>> don't have
>> any aspect-ratio support at all?  Note that MPEG streams have AR 
>> adjustment as
>> an integral part of the format, so this would mean these programs 
>> wouldn't be
>> able to play lots of MPEG streams properly either..
> 
> 
> The MPEG decoder adjusts the aspect ratio in that case. Yes, the simple 
> DShow players are that primitive, but it's easy to make a simple 
> postprocessing (I don't mean MPEG filtering, just post-processing in the 
> literal meaning of the word) filter that adjusts the aspect ratio (maybe 
> a filter that also does subtitle mixing and other MCF-specific things?). 
> Smart players have control over the filter graph and can just disable 
> that filter, and use their own builtin aspect ratio handling.
> 
> Now there's also one thing that would really attract me, and that's an 
> MCF video renderer filter. It could simply process and mix the video and 
> then pass it on to the hardware renderer (video overlay), but for 
> high-end machines it could do software or hardware bicubic resizing for 
> when the video is played in a zoomed mode (fullscreen for instance), and 
> do AR in that resizing step (the whole point of anamorphic video in the 
> first place), and mix in subtitles AFTERWARDS (for text subtitles, that 
> would mean extra crispness). Since I use RGB32 for output (no overlay, 
> resizing done by DirectDraw), this would be just /great/.

I think in the case of MCF and decoding architecture, the size 
(width/height) of the picture to decode is written in the container, not 
in the codec private data, and not in the codec data (in the most 
general case). So the application that want to play a video has to get 
the decoding side one way or another. I don't know if it should be 
"over" the codec API or through the codec API. But what I'm sure is that 
it has to be codec in the container. So the same goes for AR. (this is 
already the case)

Now about the decoding architecture, that should be discussed within the 
UCI mailing list :D