[FFmpeg-devel] probable dshow bug or strangeness
Roger Pack
rogerdpack2 at gmail.com
Thu Mar 13 17:38:33 CET 2014
On 3/12/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: 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.
I also wonder what this "i420" mentioned by VLC even is, maybe our
list_options output here is not verbose enough?
C:\installs\ffmpeg-20140307-git-64e4bd7-win32-static\bin\ffmpeg.exe -f
dshow -list_options true -i video="MediaLooks Screen Capture" yo.mpg
ffmpeg version N-61143-g64e4bd7 Copyright (c) 2000-2014 the FFmpeg developers
built on Mar 7 2014 00:01:08 with gcc 4.8.2 (GCC)
configuration: --enable-gpl --enable-version3 --disable-w32threads
--enable-avisynth --enable-bzlib --enable-fontconfig --enable-frei0r
--enable-gnutls --enable-iconv --enable-libass --enable-libbluray
--enable-libcaca --enable-libfreetype --enable-libgsm --enable-libilbc
--enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb
--enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus
--enable-librtmp --enable-libschroedinger --enable-libsoxr
--enable-libspeex --enable-libtheora --enable-libtwolame
--enable-libvidstab --enable-libvo-aacenc --enable-libvo-amrwbenc
--enable-libvorbis --enable-libvpx --enable-libwavpack
--enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid
--enable-zlib
libavutil 52. 66.101 / 52. 66.101
libavcodec 55. 52.102 / 55. 52.102
libavformat 55. 33.101 / 55. 33.101
libavdevice 55. 11.100 / 55. 11.100
libavfilter 4. 3.100 / 4. 3.100
libswscale 2. 5.101 / 2. 5.101
libswresample 0. 18.100 / 0. 18.100
libpostproc 52. 3.100 / 52. 3.100
[dshow @ 02903300] DirectShow video device options
[dshow @ 02903300] Pin "Video 0"
[dshow @ 02903300] pixel_format=yuyv422 min s=128x96 fps=1 max
s=2048x2048 fps=59.9999
[dshow @ 02903300] pixel_format=yuyv422 min s=128x96 fps=1 max
s=2048x2048 fps=59.9999
[dshow @ 02903300] pixel_format=uyvy422 min s=128x96 fps=1 max
s=2048x2048 fps=59.9999
[dshow @ 02903300] pixel_format=uyvy422 min s=128x96 fps=1 max
s=2048x2048 fps=59.9999
[dshow @ 02903300] pixel_format=yuv420p min s=128x96 fps=1 max
s=2048x2048 fps=59.9999
[dshow @ 02903300] pixel_format=yuv420p min s=128x96 fps=1 max
s=2048x2048 fps=59.9999
[dshow @ 02903300] pixel_format=yuyv422 min s=128x96 fps=1 max
s=2048x2048 fps=59.9999
[dshow @ 02903300] pixel_format=yuyv422 min s=128x96 fps=1 max
s=2048x2048 fps=59.9999
[dshow @ 02903300] pixel_format=yuv420p min s=128x96 fps=1 max
s=2048x2048 fps=59.9999
[dshow @ 02903300] pixel_format=yuv420p min s=128x96 fps=1 max
s=2048x2048 fps=59.9999
[dshow @ 02903300] pixel_format=bgra min s=128x96 fps=1 max
s=2048x2048 fps=59.9999
[dshow @ 02903300] pixel_format=bgra min s=128x96 fps=1 max
s=2048x2048 fps=59.9999
[dshow @ 02903300] pixel_format=bgra min s=128x96 fps=1 max
s=2048x2048 fps=59.9999
[dshow @ 02903300] pixel_format=bgra min s=128x96 fps=1 max
s=2048x2048 fps=59.9999
[dshow @ 02903300] pixel_format=bgr24 min s=128x96 fps=1 max
s=2048x2048 fps=59.9999
[dshow @ 02903300] pixel_format=bgr24 min s=128x96 fps=1 max
s=2048x2048 fps=59.9999
[dshow @ 02903300] pixel_format=uyvy422 min s=128x96 fps=1 max
s=2048x2048 fps=59.9999
[dshow @ 02903300] pixel_format=uyvy422 min s=128x96 fps=1 max
s=2048x2048 fps=59.9999
video=MediaLooks Screen Capture: Immediate exit requested
I still wonder what values VLC is getting back from
GetActualDataLength...or if it has a work around :)
> 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.
LGTM.
> 2)
>
> See ticket 3447
>
> http://trac.ffmpeg.org/ticket/3447
Also LGTM.
More information about the ffmpeg-devel
mailing list