mplayer output format mismatch

[GoogleCodeExporter]

What steps will reproduce the problem?
1. in codecs.conf coreserve section set
out YUY2,UYVY,YV12,I420
2. run mplayer with -vo gl:yuv=2
3.

What is the expected output? What do you see instead?
I see output format mismatch. 
mplayer crashes

==========================================================================

What version of the product are you using? On what operating system?
r104

Please provide any additional information below.

==========================================================================
Forced video codec: mpeg12
Forced video codec: xvid
Forced video codec: rv3040
Forced video codec: coreserve
Opening video decoder: [dshowserver] DirectShowServer video codecs
dshowserver --codec CoreAVCDecoder.ax --size 1280x720 --guid 09571a4b-f1fe-
4c60-9760de6d310c7c31 --fourc 0x31637661 --bits 16 --outfmt 0x32595559 --
pid 9574 --id b778b730 --numpages 10 --port 39819 &
Opening device (port is 39819)
len: 992
ProductVersion: 2.0.0
Decoder supports the following YUV formats: YUY2 UYVY YV12 I420 
Decoder is capable of YUV output (flags 0x2b)
Setting fmt
Starting
Initialization is complete
Using socket based mutex
[PP] Using codec's postprocessing, max q = 4.
Movie-Aspect is undefined - no prescaling applied.
VO: [gl] 1280x720 => 1280x720 Planar YV12 
EINPROGRESS in connect() - selecting
Dshowserver Connected to host
Found DirectShow filterSelected video codec: [coreserve] vfm: dshowserver 
(CoreAVC DShow H264 decoder)
==========================================================================

Original issue reported on code.google.com by kjchmiel...@gmail.com on 12 Jan 2010 at 1:18

[GoogleCodeExporter]

With attached patch it appears to be good.

==========================================================================
Forced video codec: mpeg12
Forced video codec: xvid
Forced video codec: rv3040
Forced video codec: coreserve
Opening video decoder: [dshowserver] DirectShowServer video codecs
[PP] Using codec's postprocessing, max q = 4.
Movie-Aspect is undefined - no prescaling applied.
VO: [gl] 1280x720 => 1280x720 Planar YV12 
dshowserver --codec CoreAVCDecoder.ax --size 1280x720 --guid 09571a4b-f1fe-4c60-
9760de6d310c7c31 --fourc 0x31637661 --bits 12 --outfmt 0x32315659 --pid 11396 
--id 
b75aa730 --numpages 10 --port 61643 &
Opening device (port is 61643)
len: 992
ProductVersion: 2.0.0
Decoder supports the following YUV formats: YUY2 UYVY YV12 I420 
Decoder is capable of YUV output (flags 0x2b)
Setting fmt
Starting
Initialization is complete
Using socket based mutex
Found DirectShow filterSelected video codec: [coreserve] vfm: dshowserver 
(CoreAVC 
DShow H264 decoder)
==========================================================================

Original comment by kjchmiel...@gmail.com on 12 Jan 2010 at 1:24

Attachments:

• mpcodecs_config_vo.diff

[GoogleCodeExporter]

Thanks for the patch.  it looks pretty straight-forward.  I'm currently 
focussed on
#87 which is turning out to be a lot more difficult to debug than I expected.  
Once
I'm done or give up I'll look at this more closely and apply.

Original comment by alannis...@gmail.com on 14 Jan 2010 at 3:35

• Changed state: Accepted

[GoogleCodeExporter]

I send yet another patch. It corrects some other issues. It includes previous 
change.

Original comment by kjchmiel...@gmail.com on 16 Jan 2010 at 10:19

Attachments:

• vd_dshowserver.c.diff

[GoogleCodeExporter]

Yet another version of the latest patch, it should be less mplayer version 
specific, 
mp_get_chroma_shift() that is used in previous version is missing in older 
releases of 
mplayer. It should be also more general in color space handling.
From my testing, with this patch different color spaces are better handled by 
mplayer 
color space selection algorithm and filters like expand, ass works. For testing 
i use 
-vf-add format=... just before vo to force output color space. At first glance 
I 
didn't notice performance penalty.

Original comment by kjchmiel...@gmail.com on 2 Feb 2010 at 10:42

Attachments:

• mpcodecs_get_image.diff

[GoogleCodeExporter]

Before I commit this, my concern is that you've gotten rid of the memcpy.  This 
means
that it is now required that mplayer consumes the frame before the next call to
decode() because once decode() is called, the frame is returned to dshowserver 
to be
reclaimed.

I haven't checked whether mplayer guarantees that the frame is consumed between 
calls
to decode()

Original comment by alannis...@gmail.com on 3 Feb 2010 at 6:10

[GoogleCodeExporter]

I don't know. I don't see any side effects but I understand what You mean (with
crosscompiled binary or winelib). I'll try to check it. I don't know how to 
handle
this direct rendering stuff that mplayer tries to do when buffer type is not 
EXPORT.

Original comment by kjchmiel...@gmail.com on 3 Feb 2010 at 12:16

[GoogleCodeExporter]

Another option is to defer the release of the frame until we're sure it has been
consumed.  The video-renderer must either have a callback when the frame 
consumed or
ensure it has been consumed before the next call to decode() otherwise we'd 
have a
huge memory leak

Original comment by alannis...@gmail.com on 3 Feb 2010 at 3:12

[GoogleCodeExporter]

I think mplayer guarantees this by design. This is from general.txt in DOCS/tech

    The given stream's actual position is in the 'timer' field of the
    corresponding stream header (sh_audio / sh_video).

     The structure of the playing loop :
         while(not EOF) {
             fill audio buffer (read & decode audio) + increase a_frame
             read & decode a single video frame + increase v_frame
             sleep  (wait until a_frame>=v_frame)
             display the frame
             apply A-V PTS correction to a_frame
             handle events (keys,lirc etc) -> pause,seek,...
         }

and from dr-methods.txt

MPlayer NOW! -- The libmpcodecs way.

libmpcodecs replaced old draw callbacks with mpi (mplayer image) struct.
steps of decoding with libmpcodecs:
1. codec requests an mpi from libmpcodecs core (vd.c)
2. vd creates an mpi struct filled by codec's requirements (size, stride,
   colorspace, flags, type)
3. vd asks libvo (control(VOCTRL_GET_IMAGE)), if it can provide such buffer:
   - if it can -> do direct rendering
   - it it can not -> allocate system ram area with memalign()/malloc()
   Note: codec may request EXPORT buffer, it means buffer allocation is
   done inside the codec, so we cannot do DR :(
4. codec decodes one frame to the mpi struct (system ram or direct rendering)
5. if it isn't DR, we call libvo's draw functions to blit image to video ram

so if we don't support DR by allocating EXPORT buffer, one frame decoded - one 
frame 
displayed, there is no additional buffering or callbacks.

Also, from my test with -benchmark, performance is better about 20% (without 
any 
additional filters, only codec and vo, with filters behavior vary).

Original comment by kjchmiel...@gmail.com on 3 Feb 2010 at 10:33

[GoogleCodeExporter]

Thanks for looking into this.  I appiled your patch

Original comment by alannis...@gmail.com on 4 Feb 2010 at 2:28

• Changed state: Fixed