[FFmpeg-devel] probable dshow bug or strangeness

Roger Pack 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.
>>>> 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/

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:
http://test.freeldssheetmusic.org/music/download_file?download_id=46628&name=ffmpeg.13.exe
(it's got one minor change that may be related, plus multiple other
medium size changes but hopefully unrelated) the minor change is
https://github.com/rdp/FFmpeg/commit/d820fa3cd5c8aac256341965ce400efdf91b5edf
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
day limit"
Thanks.
-roger-


More information about the ffmpeg-devel mailing list