[FFmpeg-devel] probable dshow bug or strangeness

[Don Moir]

----- Original Message ----- 
From: "Roger Pack" <rogerdpack2 at gmail.com>
To: "FFmpeg development discussions and patches" <ffmpeg-devel at ffmpeg.org>
Sent: Wednesday, March 12, 2014 4:40 PM
Subject: Re: [FFmpeg-devel] probable dshow bug or strangeness


> On 3/11/14, Don Moir <donmoir at comcast.net> wrote:
>>
>> ----- Original Message -----
>> From: "Don Moir" <donmoir at comcast.net>
>> To: "FFmpeg development discussions and patches" <ffmpeg-devel at ffmpeg.org>
>> Sent: Monday, March 10, 2014 5:27 PM
>> Subject: Re: [FFmpeg-devel] probable dshow bug or strangeness
>>
>>>
>>>
>>>> On 3/7/14, Don Moir <donmoir at comcast.net> wrote:
>>>>> I am posting here since not quite sure and need some advice.
>>>>>
>>>>> I got word that some captures devices were not working. Everything
>>>>> enumerated and went thru but no display.
>>>>>
>>>>> You get packets with zero size and then no decode success.
>>>>>
>>>>> I traced this into dshow_pin.c and function libAVMemInputPin_Receive.
>>>>> In
>>>>> this function there is:
>>>>>
>>>>> buf_size = IMediaSample_GetActualDataLength(sample);
>>>>>
>>>>> In this case, buf_size is always zero. I think it is supposed to be set
>>>>> somewhere with IMediaSample_SetActualDataLength and could be a coding
>>>>> issue
>>>>> with driver.
>>>>>
>>>>> This apparently happens enough where I can't just blame the driver if
>>>>> thats
>>>>> where it lies. Maybe it is supposed to be set in dshow_pin.c somewhere
>>>>> but
>>>>> don't know.
>>>>>
>>>>> When this happens (buf_size == 0), the real data length appears to be
>>>>> returned by  IMediaSample_GetSize(sample); This is supposed to be the
>>>>> actual
>>>>> buffer length and not necessarily the data length. When I change it to
>>>>> use
>>>>> IMediaSample_GetSize it works perfect.
>>>>
>>>> Are you sure it's not just re-using the previous frame's worth of data?
>>>
>>> I think I am sure about that. It plays normal if I use GetSize and nothing
>>> with GetActualDataLength.
>>>
>>>> Maybe you should just ignore frames with size 0?
>>>> Just wondering.
>>>
>>> GetActualDataLength is always zero in this case. I think yes you should
>>> ignore it but as a quick fix I used:
>>>
>>> buf_size = GetActualDataLength(sample);
>>> if (!buf_size)
>>>    buf_size = GetSize(sample);
>>>
>>> If you completely ignore nothing will display and basically same thing.
>>>
>>> The above is not correct and something else is going on. Still looking
>>> into it but have to do some other things first. If you have
>>> any ideas let me know.
>>
>> Using above quick fix only allows for some display. It is not correct though
>> (display is a bit weird) and that does not overcome the
>> real problem which is still unknown.
>>
>> The thing about GetSize in this case is it always returns the expected frame
>> size. Be it RGB, YUV, etc, the size returned by GetSize
>> is the expected frame size.
>>
>> I have about 3 or 4 normal USB cameras and they all work correctly with
>> GetActualDataLength etc. Just some assortment of capture
>> devices are not working and this information came to me from end users.
>>
>> The problem as reported to me was: Everything list ok but you get no
>> display. So I had to find some software capture device that
>> reproduced the problem.
>>
>> I came across MediaLooks capture device and it seems to indicate the
>> problems reported by users. List ok but no display.
>>
>> Roger if you or anyone else wants to take a look, you can download the
>> MediaLooks dshow filter here. It's free (ignore buy button)
>> and easy. Download, Install, no BS.
>>
>> http://www.medialooks.com/screen_capture/
>>
>> You can use ffplay or other code using ffmpeg to reproduce the problem. I
>> can't say right now if this particular device accounts for
>> all devices reported by users but it's a good start and these reported
>> problems all had the same indication of: (list ok but no
>> display).
>>
>> Works fine in VLC. I should be able to get back to it in a couple days, but
>> if anyone has a suggestion I will look at that right
>> away.
>
> I am able to see the issue with the medialooks capture.
> I wonder if VLC gets the same values back for GetActualDataLength or not.
> Also it appears VLC is receiving it at I420 by default, not bgra? hmm...
> -roger-

I don't think it matters about the color format. Checked several things going back and forth and don't recall that making any 
difference.

2 other things though. These don't have have anything to do with zero length problem.

1)

static enum AVPixelFormat dshow_pixfmt(DWORD biCompression, WORD biBitCount)
{
    switch(biCompression) {
    case BI_BITFIELDS:
    case BI_RGB:
        switch(biBitCount) { /* 1-8 are untested */
            case 1:
                return AV_PIX_FMT_MONOWHITE;
            case 4:
                return AV_PIX_FMT_RGB4;
            case 8:
                return AV_PIX_FMT_RGB8;
            case 16:
                return AV_PIX_FMT_RGB555;
            case 24:
                return AV_PIX_FMT_BGR24;
            case 32:
-                return AV_PIX_FMT_RGB32;
+                return AV_PIX_FMT_0RGB32;
        }
    }
    return avpriv_find_pix_fmt(ff_raw_pix_fmt_tags, biCompression); // all others
}

BI_RGB is assumed to opaque and not alpha. The alpha is hidden in AV_PIX_FMT_RGB32. It should have been named AV_PIX_FMT_ARGB32 and 
opaque should have been named AV_PIX_FMT_XRGB32 to avoid confusion.

2)

See ticket 3447

http://trac.ffmpeg.org/ticket/3447