[FFmpeg-devel] probable dshow bug or strangeness

Roger Pack rogerdpack2 at gmail.com
Wed Mar 12 21:40:00 CET 2014


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
>
>
>>
>> ----- Original Message -----
>> From: "Roger Pack" <rogerdpack2 at gmail.com>
>> To: "FFmpeg development discussions and patches"
>> <ffmpeg-devel at ffmpeg.org>
>> Sent: Monday, March 10, 2014 2:58 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-


More information about the ffmpeg-devel mailing list