Yes, I have seen this (problem with stop/start in GraphStudio without reconnecting filters) before. The problem here is that is not exactly bug of x264vfw but bug somewhere in DirectShow filters. I am not sure which of the filters to blame:
- Microsoft's DirectShow wrapper for VFW i.e. AVI Compressor (bar with x264vfw in GraphStudio)
or
- Source filter i.e. Integrated Webcam in your case
or
- GraphStudio itself (that it start/stops without reconnecting or not updating something).
In result I get ICM_COMPRESS message where icc->lpbiOutput->biSizeImage is incorrect (probably size of last encoded frame and not the buffer size which is set by good apps before every ICM_COMPRESS message.
Currently there is already workaround for the buggy apps that don't update this field for every ICM_COMPRESS message but at least have it correct at first after ICM_COMPRESS_BEGIN message. But it doesn't work in your case because this remembered buffer size is cleared after ICM_COMPRESS_BEGIN (due stop/start) in prepare to the correct one.
So only workarounds I can suggest and need feedback:
- don't clear remembered size after ICM_COMPRESS_BEGIN which is not very good because in between you could changed other params and most dangerous reallocate this output buffer (but keep buffer pointer the same)
- add some probably hidden option (i.e. not visible like simple value in windows registry) to fully disable this size check in x264vfw. At user who set it will be the one to take risk of buffer overrun / crash / etc in the case of buggy app providing buffer not large enough to write output. Also I am not sure if "Load Defaults" button should reset this hidden flag also.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just got this with the latest 32bit GraphStudioNext and x264vfw:
x264vfw [error]: output frame buffer too small (size 123 / needed 240423)
So not fixed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, I have seen this (problem with stop/start in GraphStudio without reconnecting filters) before. The problem here is that is not exactly bug of x264vfw but bug somewhere in DirectShow filters. I am not sure which of the filters to blame:
- Microsoft's DirectShow wrapper for VFW i.e. AVI Compressor (bar with x264vfw in GraphStudio)
or
- Source filter i.e. Integrated Webcam in your case
or
- GraphStudio itself (that it start/stops without reconnecting or not updating something).
In result I get ICM_COMPRESS message where icc->lpbiOutput->biSizeImage is incorrect (probably size of last encoded frame and not the buffer size which is set by good apps before every ICM_COMPRESS message.
Currently there is already workaround for the buggy apps that don't update this field for every ICM_COMPRESS message but at least have it correct at first after ICM_COMPRESS_BEGIN message. But it doesn't work in your case because this remembered buffer size is cleared after ICM_COMPRESS_BEGIN (due stop/start) in prepare to the correct one.
So only workarounds I can suggest and need feedback:
- don't clear remembered size after ICM_COMPRESS_BEGIN which is not very good because in between you could changed other params and most dangerous reallocate this output buffer (but keep buffer pointer the same)
- add some probably hidden option (i.e. not visible like simple value in windows registry) to fully disable this size check in x264vfw. At user who set it will be the one to take risk of buffer overrun / crash / etc in the case of buggy app providing buffer not large enough to write output. Also I am not sure if "Load Defaults" button should reset this hidden flag also.
Should be probably fixed in 39_2453bm_40246 release.
View and moderate all "bugs Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Bugs"
Just got this with the latest 32bit GraphStudioNext and x264vfw:
x264vfw [error]: output frame buffer too small (size 123 / needed 240423)
So not fixed.
View and moderate all "bugs Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Bugs"
I've resolved this disconnecting and connecting the input / output pins