[FFmpeg-devel] probable dshow bug or strangeness
Michael Niedermayer
michaelni at gmx.at
Thu Mar 13 18:33:08 CET 2014
On Thu, Mar 13, 2014 at 10:38:33AM -0600, Roger Pack wrote:
> 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.
if theres some patch i should apply, please someone provide
one with a commit message (for git am)
[...]
thanks
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The worst form of inequality is to try to make unequal things equal.
-- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140313/994c777d/attachment.asc>
More information about the ffmpeg-devel
mailing list