search

chenyunecjtu / coreavc-for-linux

Automatically exported from code.google.com/p/coreavc-for-linux
GNU General Public License v2.0
0 stars 1 forks source link

Win32 builds with non-related info being printed to stdout #11

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
What steps will reproduce the problem?
1. Build mplayer with coreavc-for-linux
2. Run with -vc coreavc (and NOT -really-quiet or the like)
3. Look at the stdout

What is the expected output? What do you see instead?
Seeing strange info being printed, and things which should not be related
to the coreavc decoder. Also doesn't matter which version of CoreAVC is
used. Here is an example:

Forced video codec: coreavc
Opening video decoder: [dshow] DirectShow video codecs
len: 964
ProductVersion: 0.0.0.4
Decoder does not support upside-down RGB frames
Decoder supports the following YUV formats: YUY2 IYUV YV12 I420
Decoder is capable of YUV output (flags 0x27)
VDec: vo config request - 720 x 480 (preferred colorspace: Packed YUY2)
[PP] Using codec's postprocessing, max q = 4.
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is 1.82:1 - prescaling to correct movie aspect.
VO: [directx] 720x480 => 874x480 Planar YV12
VideoDecoder::SetExtAttr: registry failure
Selected video codec: [coreavc] vfm: dshow (CoreAVC DShow H.264 decoder for
x86 - http://www.coreavc.com/)

What version of the product are you using? On what operating system?
Latest mplayer svn and coreavc-for-linux svn. Win32, Windows XP.

Please provide any additional information below.
What is the "len: #" line being printed for? Does this number have any
significance? I am guessing it was just something you accidentally left in
while working on the code.

The PostProcessing line is in regards to code related to the DivX dshow
decoder, correct? That should not be appearing at all, since CoreAVC has no
internal PostProcessing above the normal H.264 inloop deblocking. Also the
line with "SetExtAttr" is only related to reading info from the registry in
regards to DivX again.

All of these have appeared in the stdout since alannisota's original
coreavc patches on the mplayer ML, except the line printing "len: #" which
I've only seen since using this google project. Nothing really extremely
important here, as much as my last issue. Just things that could be cleaned
up more. Though I am curious if someone could reply, does the same stuff
get printed on non-win32 builds?

Original issue reported on code.google.com by nsch...@gmail.com on 27 Sep 2007 at 3:23

GoogleCodeExporter commented 8 years ago 
I am able to use R36 properly on windows builds.  However, I am now using 
1.7.0. 
0.0.4 is 2 years old, and I don't have the bandwidth to support older drivers 
seeing
as this is basically a one-man show.

If you still have issues on current mplayer with current patch, let me know.

Original comment by alannis...@gmail.com on 7 May 2008 at 5:02