[FFmpeg-devel] probable dshow bug or strangeness
rogerdpack2 at gmail.com
Thu Jan 15 15:41:43 CET 2015
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.
>>>> 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
>>>> with driver.
>>>> This apparently happens enough where I can't just blame the driver if
>>>> where it lies. Maybe it is supposed to be set in dshow_pin.c somewhere
>>>> 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
>>>> buffer length and not necessarily the data length. When I change it to
>>>> 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.
The latest Medialooks seem to work ok for me [windows 7] maybe they
fixed a bug (I did report one to them LOL)?
Do you have an older installer that repro's the problem [or, if you
can repro it locally, maybe test this:
(it's got one minor change that may be related, plus multiple other
medium size changes but hopefully unrelated) the minor change is
basically I'm just curious to see if the problem's still there, since
I can't seem to repro it with Medialooks anymore, thanks to their "30
More information about the ffmpeg-devel