[FFmpeg-devel] probable dshow bug or strangeness
Michael Niedermayer
michaelni at gmx.at
Mon Mar 31 23:19:26 CEST 2014
On Mon, Mar 31, 2014 at 02:12:21PM -0600, Roger Pack wrote:
> On 3/13/14, Michael Niedermayer <michaelni at gmx.at> wrote:
> > 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)
>
> OK here's the patch, thanks Don Moir.
applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf
-------------- 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/20140331/84165ac6/attachment.asc>
More information about the ffmpeg-devel
mailing list