[FFmpeg-devel] probable dshow bug or strangeness

Roger Pack rogerdpack2 at gmail.com
Tue Mar 11 16:54:47 CET 2014

On 3/10/14, Don Moir <donmoir at comcast.net> wrote:
> ----- 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.

Maybe ask on SO or the dshow MS forum?
I seem to not see much code out in the wild that doesn't trust

More information about the ffmpeg-devel mailing list