probable dshow bug or strangeness
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. So just not sure how to best handle it and can't find good information about it. It appears though, IMediaSample_GetSize is the thing to use and seems IMediaSample_GetActualDataLength can be ignored but have no real clue. I am still running some test with it and maybe someone out there has some more info.
On 3/7/14, Don Moir <donmoir@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? Maybe you should just ignore frames with size 0? Just wondering. -roger-
----- Original Message ----- From: "Roger Pack" <rogerdpack2@gmail.com> To: "FFmpeg development discussions and patches" <ffmpeg-devel@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@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.
On 3/10/14, Don Moir <donmoir@comcast.net> wrote:
----- Original Message ----- From: "Roger Pack" <rogerdpack2@gmail.com> To: "FFmpeg development discussions and patches" <ffmpeg-devel@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@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 GetActualDataLength...hmm... -roger-
----- Original Message ----- From: "Don Moir" <donmoir@comcast.net> To: "FFmpeg development discussions and patches" <ffmpeg-devel@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@gmail.com> To: "FFmpeg development discussions and patches" <ffmpeg-devel@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@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.
On 3/11/14, Don Moir <donmoir@comcast.net> wrote:
----- Original Message ----- From: "Don Moir" <donmoir@comcast.net> To: "FFmpeg development discussions and patches" <ffmpeg-devel@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@gmail.com> To: "FFmpeg development discussions and patches" <ffmpeg-devel@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@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-
----- Original Message ----- From: "Roger Pack" <rogerdpack2@gmail.com> To: "FFmpeg development discussions and patches" <ffmpeg-devel@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@comcast.net> wrote:
----- Original Message ----- From: "Don Moir" <donmoir@comcast.net> To: "FFmpeg development discussions and patches" <ffmpeg-devel@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@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. 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. 2) See ticket 3447 http://trac.ffmpeg.org/ticket/3447
On 3/12/14, Don Moir <donmoir@comcast.net> wrote:
----- Original Message ----- From: "Roger Pack" <rogerdpack2@gmail.com> To: "FFmpeg development discussions and patches" <ffmpeg-devel@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@comcast.net> wrote:
----- Original Message ----- From: "Don Moir" <donmoir@comcast.net> To: "FFmpeg development discussions and patches" <ffmpeg-devel@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@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
Also LGTM.
----- Original Message ----- From: "Roger Pack" <rogerdpack2@gmail.com> To: "FFmpeg development discussions and patches" <ffmpeg-devel@ffmpeg.org> Sent: Thursday, March 13, 2014 12:38 PM Subject: Re: [FFmpeg-devel] probable dshow bug or strangeness
On 3/12/14, Don Moir <donmoir@comcast.net> wrote:
----- Original Message ----- From: "Roger Pack" <rogerdpack2@gmail.com> To: "FFmpeg development discussions and patches" <ffmpeg-devel@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@comcast.net> wrote:
----- Original Message ----- From: "Don Moir" <donmoir@comcast.net> To: "FFmpeg development discussions and patches" <ffmpeg-devel@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@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 :)
I had to started to look at the VLC code and then something else came up I had to work on.. The relevant VLC files are dshow.cpp, filter.cpp, and bdagraph.cpp. It does things a bit different in Receive etc, queueing up samples etc. With the time I had spent on it, I did not see anything earth shaking so just need to get back to it. It appears in the in the VLC code, GetActualDataLength returns a proper value. A zero value is an indication of an error and should not happen. In other words, Receive being called with zero data length is not really defined. This kind of winds it way thru in the VLC code, and about as far as I got with it at the time. In VLC filter.cpp and in CapturePin::Receive, the sample is queued up and did not go much beyond that, although, there is an AddRef on the sample. A guess is, something upstream from Receive is not being done correctly. Also AddRef could play a role here but I tested it with no luck. If a reference value is not correct, a fliter is suppose to return zero I believe, but that's as far as I got with it. Some other things might be setting the time stamp correctly etc, but no real clue on that. Should be able to get back on it tomorrow but thanks for helping and keep digging. I may go ahead and verify that this is the same problem with other devices that have this same indication as well. Using the quick but broken fix is enough to at least get a display and enough to verify problem with other devices.
On Thu, Mar 13, 2014 at 10:38:33AM -0600, Roger Pack wrote:
On 3/12/14, Don Moir <donmoir@comcast.net> wrote:
----- Original Message ----- From: "Roger Pack" <rogerdpack2@gmail.com> To: "FFmpeg development discussions and patches" <ffmpeg-devel@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@comcast.net> wrote:
----- Original Message ----- From: "Don Moir" <donmoir@comcast.net> To: "FFmpeg development discussions and patches" <ffmpeg-devel@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@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
----- Original Message ----- From: "Michael Niedermayer" <michaelni@gmx.at> To: "FFmpeg development discussions and patches" <ffmpeg-devel@ffmpeg.org> Sent: Thursday, March 13, 2014 1:33 PM Subject: Re: [FFmpeg-devel] probable dshow bug or strangeness
I also wonder what this "i420" mentioned by VLC even is, maybe our list_options output here is not verbose enough?
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)
At least 3 patches are going to be needed to be applied for dshow code. 2 are straight forward and one(or more) is not determined yet. The 2 that are known need to put up properly of course. Just finding these things as we look into a more serious problem and so far just put up as notification as an aid for anyone trying to test the 3 problem that might run into these things.
Roger Pack <rogerdpack2 <at> gmail.com> writes:
I also wonder what this "i420" mentioned by VLC even is,
See below.
maybe our list_options output here is not verbose enough?
Probably.
[dshow <at> 02903300] pixel_format=yuv420p min s=128x96 fps=1 max s=2048x2048 fps=59.9999
This is i420.
[dshow <at> 02903300] pixel_format=yuv420p min s=128x96 fps=1 max s=2048x2048 fps=59.9999
The second one is YV12, actually probably in different order. Carl Eugen
----- Original Message ----- From: "Roger Pack" <rogerdpack2@gmail.com> To: "FFmpeg development discussions and patches" <ffmpeg-devel@ffmpeg.org> Sent: Thursday, March 13, 2014 12:38 PM Subject: Re: [FFmpeg-devel] probable dshow bug or strangeness
On 3/12/14, Don Moir <donmoir@comcast.net> wrote:
----- Original Message ----- From: "Roger Pack" <rogerdpack2@gmail.com> To: "FFmpeg development discussions and patches" <ffmpeg-devel@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@comcast.net> wrote:
----- Original Message ----- From: "Don Moir" <donmoir@comcast.net> To: "FFmpeg development discussions and patches" <ffmpeg-devel@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@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 :)
I had to started to look at the VLC code and then something else came up I had to work on.. The relevant VLC files are dshow.cpp, filter.cpp, and bdagraph.cpp. It does things a bit different in Receive etc, queueing up samples etc. With the time I had spent on it, I did not see anything earth shaking so just need to get back to it.
It appears in the in the VLC code, GetActualDataLength returns a proper value. A zero value is an indication of an error and should not happen. In other words, Receive being called with zero data length is not really defined. This kind of winds it way thru in the VLC code, and about as far as I got with it at the time. In VLC filter.cpp and in CapturePin::Receive, the sample is queued up and did not go much beyond that, although, there is an AddRef on the sample.
A guess is, something upstream from Receive is not being done correctly. Also AddRef could play a role here but I tested it with no luck. If a reference value is not correct, a fliter is suppose to return zero I believe, but that's as far as I got with it. Some other things might be setting the time stamp correctly etc, but no real clue on that.
Should be able to get back on it tomorrow but thanks for helping and keep digging. I may go ahead and verify that this is the same problem with other devices that have this same indication as well. Using the quick but broken fix is enough to at least get a display and enough to verify problem with other devices.
So started looking at this again. The code I used to use for dshow 'works' and so I have that code base to compare with. Now though, I am wondering what 'works' means for this device :) In 3 of the different unrelated programs I tested with, I get this sort of nested display when the main window has the focus. When main window does not have the focus I get a normal looking display. In VLC, you seem to get this normal looking display even when the main window has the focus. When I apply the quick fix stated above, I also get a nested display and same as the unrelated programs I tested with. Even when GetActualDataLength returns a proper value I am seeing this nested display so that is something else a little odd about this. Could be some simple explanation for this though and just not concerned with this at the moment. Could be something like DirectX usage of window versus normal windows usage of window or similiar. My initial goal for using avdevice, was to distance myself from dshow related code. I have not been able to do that entirely since I still need to list the devices and their capabilites and give this list back to the caller. I could parse the av_log output but that is just silly so I choose to use my own listing code and that still ties me to dshow. Via current discussions on device list and their capabilites, I don't have a good feeling about that getting much less clumsy. I just don't have a clue right now if that is going to improve things or not. Looks to me just like more things to go wrong, efficiency concerns, etc. My gut feeling right now is I should revert back to older dshow code I was using. Much has changed since then and would be a lot of work to put that back in, but right now avdevice is not really buying me anything. I don't know if I am going to get rid of avdevice or not, but I should be able to figure out the problem there. Just tracking thru a lot of code to check differences and trying to get more familiar with the ffmpeg and other dshow code.
On 3/16/14, Don Moir <donmoir@comcast.net> wrote:
----- Original Message ----- From: "Roger Pack" <rogerdpack2@gmail.com> To: "FFmpeg development discussions and patches" <ffmpeg-devel@ffmpeg.org> Sent: Thursday, March 13, 2014 12:38 PM Subject: Re: [FFmpeg-devel] probable dshow bug or strangeness
On 3/12/14, Don Moir <donmoir@comcast.net> wrote:
----- Original Message ----- From: "Roger Pack" <rogerdpack2@gmail.com> To: "FFmpeg development discussions and patches" <ffmpeg-devel@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@comcast.net> wrote:
----- Original Message ----- From: "Don Moir" <donmoir@comcast.net> To: "FFmpeg development discussions and patches" <ffmpeg-devel@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@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 :)
I had to started to look at the VLC code and then something else came up I had to work on.. The relevant VLC files are dshow.cpp, filter.cpp, and bdagraph.cpp. It does things a bit different in Receive etc, queueing up samples etc. With the time I had spent on it, I did not see anything earth shaking so just need to get back to it.
It appears in the in the VLC code, GetActualDataLength returns a proper value. A zero value is an indication of an error and should not happen. In other words, Receive being called with zero data length is not really defined. This kind of winds it way thru in the VLC code, and about as far as I got with it at the time. In VLC filter.cpp and in CapturePin::Receive, the sample is queued up and did not go much beyond that, although, there is an AddRef on the sample.
A guess is, something upstream from Receive is not being done correctly. Also AddRef could play a role here but I tested it with no luck. If a reference value is not correct, a fliter is suppose to return zero I believe, but that's as far as I got with it. Some other things might be setting the time stamp correctly etc, but no real clue on that.
Should be able to get back on it tomorrow but thanks for helping and keep digging. I may go ahead and verify that this is the same problem with other devices that have this same indication as well. Using the quick but broken fix is enough to at least get a display and enough to verify problem with other devices.
So started looking at this again. The code I used to use for dshow 'works' and so I have that code base to compare with. Now though, I am wondering what 'works' means for this device :) In 3 of the different unrelated programs I tested with, I get this sort of nested display when the main window has the focus. When main window does not have the focus I get a normal looking display. In VLC, you seem to get this normal looking display even when the main window has the focus.
When I apply the quick fix stated above, I also get a nested display and same as the unrelated programs I tested with. Even when GetActualDataLength returns a proper value I am seeing this nested display so that is something else a little odd about this. Could be some simple explanation for this though and just not concerned with this at the moment. Could be something like DirectX usage of window versus normal windows usage of window or similiar.
Nested when viewed how here? I'll admit it would be nice to hammer out the bugs in avdevice so the rest of us can benefit...I wonder if converting things to cpp would work, but that might be tricky... -roger-
----- Original Message ----- From: "Roger Pack" <rogerdpack2@gmail.com> To: "FFmpeg development discussions and patches" <ffmpeg-devel@ffmpeg.org> Sent: Monday, March 17, 2014 2:41 PM Subject: Re: [FFmpeg-devel] probable dshow bug or strangeness
On 3/16/14, Don Moir <donmoir@comcast.net> wrote:
----- Original Message ----- From: "Roger Pack" <rogerdpack2@gmail.com> To: "FFmpeg development discussions and patches" <ffmpeg-devel@ffmpeg.org> Sent: Thursday, March 13, 2014 12:38 PM Subject: Re: [FFmpeg-devel] probable dshow bug or strangeness
On 3/12/14, Don Moir <donmoir@comcast.net> wrote:
----- Original Message ----- From: "Roger Pack" <rogerdpack2@gmail.com> To: "FFmpeg development discussions and patches" <ffmpeg-devel@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@comcast.net> wrote: > > ----- Original Message ----- > From: "Don Moir" <donmoir@comcast.net> > To: "FFmpeg development discussions and patches" > <ffmpeg-devel@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@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 :)
I had to started to look at the VLC code and then something else came up I had to work on.. The relevant VLC files are dshow.cpp, filter.cpp, and bdagraph.cpp. It does things a bit different in Receive etc, queueing up samples etc. With the time I had spent on it, I did not see anything earth shaking so just need to get back to it.
It appears in the in the VLC code, GetActualDataLength returns a proper value. A zero value is an indication of an error and should not happen. In other words, Receive being called with zero data length is not really defined. This kind of winds it way thru in the VLC code, and about as far as I got with it at the time. In VLC filter.cpp and in CapturePin::Receive, the sample is queued up and did not go much beyond that, although, there is an AddRef on the sample.
A guess is, something upstream from Receive is not being done correctly. Also AddRef could play a role here but I tested it with no luck. If a reference value is not correct, a fliter is suppose to return zero I believe, but that's as far as I got with it. Some other things might be setting the time stamp correctly etc, but no real clue on that.
Should be able to get back on it tomorrow but thanks for helping and keep digging. I may go ahead and verify that this is the same problem with other devices that have this same indication as well. Using the quick but broken fix is enough to at least get a display and enough to verify problem with other devices.
So started looking at this again. The code I used to use for dshow 'works' and so I have that code base to compare with. Now though, I am wondering what 'works' means for this device :) In 3 of the different unrelated programs I tested with, I get this sort of nested display when the main window has the focus. When main window does not have the focus I get a normal looking display. In VLC, you seem to get this normal looking display even when the main window has the focus.
When I apply the quick fix stated above, I also get a nested display and same as the unrelated programs I tested with. Even when GetActualDataLength returns a proper value I am seeing this nested display so that is something else a little odd about this. Could be some simple explanation for this though and just not concerned with this at the moment. Could be something like DirectX usage of window versus normal windows usage of window or similiar.
Nested when viewed how here?
You can view it using ffplay but you have to make this change first in dshow_pin.c / libAVMemInputPin_Recieve buf_size = IMediaSample_GertActualDataLength(sample); if (!buf_size) buf_size = IMediaSample_GetSize(sample); After that you should get a display and it should be nested so you can see what I am talking about. I seem to get this nested display in everything except VLC. Not sure what kind of problem or if it is a problem at the moment.
I'll admit it would be nice to hammer out the bugs in avdevice so the rest of us can benefit...
Yes, I don't sleep well unless I know the answer even if I end up leaving it. Already mentioned I would try to resolve it. The problem with this is that there are many nuances with dshow and just takes one thing to be out of order somewhere or not quite right. so even if you have similiar code, you still have to hunt and peck since there is a trail of dependencies that may be different.
I wonder if converting things to cpp would work, but that might be tricky...
The other dshow code I am using to test that 'works' is cpp and so trying to match that with the ffmpeg code. It's has a different pipeline to the end result so breaking that down.
----- Original Message ----- From: "Don Moir" <donmoir@comcast.net> To: "FFmpeg development discussions and patches" <ffmpeg-devel@ffmpeg.org> Sent: Monday, March 17, 2014 3:08 PM Subject: Re: [FFmpeg-devel] probable dshow bug or strangeness
----- Original Message ----- From: "Roger Pack" <rogerdpack2@gmail.com> To: "FFmpeg development discussions and patches" <ffmpeg-devel@ffmpeg.org> Sent: Monday, March 17, 2014 2:41 PM Subject: Re: [FFmpeg-devel] probable dshow bug or strangeness
On 3/16/14, Don Moir <donmoir@comcast.net> wrote:
----- Original Message ----- From: "Roger Pack" <rogerdpack2@gmail.com> To: "FFmpeg development discussions and patches" <ffmpeg-devel@ffmpeg.org> Sent: Thursday, March 13, 2014 12:38 PM Subject: Re: [FFmpeg-devel] probable dshow bug or strangeness
On 3/12/14, Don Moir <donmoir@comcast.net> wrote:
----- Original Message ----- From: "Roger Pack" <rogerdpack2@gmail.com> To: "FFmpeg development discussions and patches" <ffmpeg-devel@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@comcast.net> wrote: >> >> ----- Original Message ----- >> From: "Don Moir" <donmoir@comcast.net> >> To: "FFmpeg development discussions and patches" >> <ffmpeg-devel@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@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 :)
I had to started to look at the VLC code and then something else came up I had to work on.. The relevant VLC files are dshow.cpp, filter.cpp, and bdagraph.cpp. It does things a bit different in Receive etc, queueing up samples etc. With the time I had spent on it, I did not see anything earth shaking so just need to get back to it.
It appears in the in the VLC code, GetActualDataLength returns a proper value. A zero value is an indication of an error and should not happen. In other words, Receive being called with zero data length is not really defined. This kind of winds it way thru in the VLC code, and about as far as I got with it at the time. In VLC filter.cpp and in CapturePin::Receive, the sample is queued up and did not go much beyond that, although, there is an AddRef on the sample.
A guess is, something upstream from Receive is not being done correctly. Also AddRef could play a role here but I tested it with no luck. If a reference value is not correct, a fliter is suppose to return zero I believe, but that's as far as I got with it. Some other things might be setting the time stamp correctly etc, but no real clue on that.
Should be able to get back on it tomorrow but thanks for helping and keep digging. I may go ahead and verify that this is the same problem with other devices that have this same indication as well. Using the quick but broken fix is enough to at least get a display and enough to verify problem with other devices.
So started looking at this again. The code I used to use for dshow 'works' and so I have that code base to compare with. Now though, I am wondering what 'works' means for this device :) In 3 of the different unrelated programs I tested with, I get this sort of nested display when the main window has the focus. When main window does not have the focus I get a normal looking display. In VLC, you seem to get this normal looking display even when the main window has the focus.
When I apply the quick fix stated above, I also get a nested display and same as the unrelated programs I tested with. Even when GetActualDataLength returns a proper value I am seeing this nested display so that is something else a little odd about this. Could be some simple explanation for this though and just not concerned with this at the moment. Could be something like DirectX usage of window versus normal windows usage of window or similiar.
Nested when viewed how here?
You can view it using ffplay but you have to make this change first in dshow_pin.c / libAVMemInputPin_Recieve
buf_size = IMediaSample_GertActualDataLength(sample); if (!buf_size) buf_size = IMediaSample_GetSize(sample);
After that you should get a display and it should be nested so you can see what I am talking about. I seem to get this nested display in everything except VLC. Not sure what kind of problem or if it is a problem at the moment.
I'll admit it would be nice to hammer out the bugs in avdevice so the rest of us can benefit...
Yes, I don't sleep well unless I know the answer even if I end up leaving it. Already mentioned I would try to resolve it. The problem with this is that there are many nuances with dshow and just takes one thing to be out of order somewhere or not quite right. so even if you have similiar code, you still have to hunt and peck since there is a trail of dependencies that may be different.
I wonder if converting things to cpp would work, but that might be tricky...
The other dshow code I am using to test that 'works' is cpp and so trying to match that with the ffmpeg code. It's has a different pipeline to the end result so breaking that down.
Roger, if you end up testing that in ffplay or whereever, if you click the main ffplay display window making it active, you should see the nested display I am talking about. If you click some other window, you should get a normal display. Again, I see this nested display in the other dshow programs I tested in as well, just not in VLC. Also sent some code out to be tested with other capture devices that are not working and should have answer on that soon. This will just verify if it is the same problem or not for all the devices not working with this same indication.
On 3/13/14, Michael Niedermayer <michaelni@gmx.at> wrote:
On Thu, Mar 13, 2014 at 10:38:33AM -0600, Roger Pack wrote:
On 3/12/14, Don Moir <donmoir@comcast.net> wrote:
----- Original Message ----- From: "Roger Pack" <rogerdpack2@gmail.com> To: "FFmpeg development discussions and patches" <ffmpeg-devel@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@comcast.net> wrote:
----- Original Message ----- From: "Don Moir" <donmoir@comcast.net> To: "FFmpeg development discussions and patches" <ffmpeg-devel@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@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. -roger-
On Mon, Mar 31, 2014 at 02:12:21PM -0600, Roger Pack wrote:
On 3/13/14, Michael Niedermayer <michaelni@gmx.at> wrote:
On Thu, Mar 13, 2014 at 10:38:33AM -0600, Roger Pack wrote:
On 3/12/14, Don Moir <donmoir@comcast.net> wrote:
----- Original Message ----- From: "Roger Pack" <rogerdpack2@gmail.com> To: "FFmpeg development discussions and patches" <ffmpeg-devel@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@comcast.net> wrote:
----- Original Message ----- From: "Don Moir" <donmoir@comcast.net> To: "FFmpeg development discussions and patches" <ffmpeg-devel@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@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
On 3/11/14, Don Moir <donmoir@comcast.net> wrote:
----- Original Message ----- From: "Don Moir" <donmoir@comcast.net> To: "FFmpeg development discussions and patches" <ffmpeg-devel@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@gmail.com> To: "FFmpeg development discussions and patches" <ffmpeg-devel@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@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.
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/d820fa3cd5c8aac256341965ce400efdf91b5ed... 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-
participants (4)
-
Carl Eugen Hoyos -
Don Moir -
Michael Niedermayer -
Roger Pack