Hello all,
It would be really nice to be able to link to Wine's strmbase in tests. There is already one test that implements large parts of the filter and pin functionality that is used there, and it seems to me that it would be in our interest to be able to add more tests that would involve putting our own filters in graphs, e.g. to be able to test filter and pin methods directly, or to stream large amounts of data without having to put it in resource files.
This almost "just works". The only thing preventing simply adding "#include <wine/strmbase.h>" and linking to strmbase is that the latter uses debug functions which live in libwine, and so cross-compiling results in undefined references to wine_dbg_log() and wine_dbg_sprintf().
I've attached a patch as a proof-of-concept, which provides stubs for these functions (actually they are semi-stubs, as they proved useful when debugging the patch itself). As can be seen, it reduces the code necessary to set up test_render_filter_priority() to 1/3 of its original length (and it might be possible to reduce it further by using BaseRenderer and TransformFilter).
Is this something that would be workable?
ἔρρωσθε, Zeb
Hi,
While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=38212
Your paranoid android.
=== build (build) === Make failed
On 5/5/18 2:47 PM, Zebediah Figura wrote:
Hello all,
It would be really nice to be able to link to Wine's strmbase in tests. There is already one test that implements large parts of the filter and pin functionality that is used there, and it seems to me that it would be in our interest to be able to add more tests that would involve putting our own filters in graphs, e.g. to be able to test filter and pin methods directly, or to stream large amounts of data without having to put it in resource files.
This almost "just works". The only thing preventing simply adding "#include <wine/strmbase.h>" and linking to strmbase is that the latter uses debug functions which live in libwine, and so cross-compiling results in undefined references to wine_dbg_log() and wine_dbg_sprintf().
I've attached a patch as a proof-of-concept, which provides stubs for these functions (actually they are semi-stubs, as they proved useful when debugging the patch itself). As can be seen, it reduces the code necessary to set up test_render_filter_priority() to 1/3 of its original length (and it might be possible to reduce it further by using BaseRenderer and TransformFilter).
Is this something that would be workable?
ἔρρωσθε, Zeb
Just remember that strmbase is actually based off a REAL development library in the Microsoft SDK. It is not identical and the only reason we would care is if we continue to support source ports via Wine. If we want to support that then we need to try to get strmbase to be as identical to that one as possible.
If we have abandoned source ports all together then it matters little.
-aric
On 08/05/18 09:57, Aric Stewart wrote:
Just remember that strmbase is actually based off a REAL development library in the Microsoft SDK. It is not identical and the only reason we would care is if we continue to support source ports via Wine. If we want to support that then we need to try to get strmbase to be as identical to that one as possible.
If we have abandoned source ports all together then it matters little.
-aric
Sure, that's definitely another thing to consider. The last few changes to strmbase that I submitted were in the interest of allowing this patch to work, but they were also based on the MSDN documentation for CBasePin.
Obviously Wine's strmbase can't be really compatible with Windows', since the latter is exclusively C++. But I have no idea whether following the documentation is something we should try to do, or whether we should just abandon it and try to write code that works best for Wine. Nor do I know that there would be any major differences in these. So if anyone has input on this question as well, please don't hesitate to speak.
ἔρρωσθε, Zeb
On 5/8/18 10:51 AM, Zebediah Figura wrote:
On 08/05/18 09:57, Aric Stewart wrote:
Just remember that strmbase is actually based off a REAL development library in the Microsoft SDK. It is not identical and the only reason we would care is if we continue to support source ports via Wine. If we want to support that then we need to try to get strmbase to be as identical to that one as possible.
If we have abandoned source ports all together then it matters little.
-aric
Sure, that's definitely another thing to consider. The last few changes to strmbase that I submitted were in the interest of allowing this patch to work, but they were also based on the MSDN documentation for CBasePin.
Obviously Wine's strmbase can't be really compatible with Windows', since the latter is exclusively C++. But I have no idea whether following the documentation is something we should try to do, or whether we should just abandon it and try to write code that works best for Wine. Nor do I know that there would be any major differences in these. So if anyone has input on this question as well, please don't hesitate to speak.
I use to be passionate about it back when I original wrote the code. But time and distance has mellowed my view on this.
I feel like it would be advantageous for us to mirror the Windows version as much as possible if for no other reason than to try to avoid confusion.
However that said. I no long see any reason for us to strive to be fully compatible and add wine specific things there that help all our filters across our source is a good thing.
-aric
On 05/05/18 21:47, Zebediah Figura wrote:
Hello all,
It would be really nice to be able to link to Wine's strmbase in tests. There is already one test that implements large parts of the filter and pin functionality that is used there, and it seems to me that it would be in our interest to be able to add more tests that would involve putting our own filters in graphs, e.g. to be able to test filter and pin methods directly, or to stream large amounts of data without having to put it in resource files.
This almost "just works". The only thing preventing simply adding "#include <wine/strmbase.h>" and linking to strmbase is that the latter uses debug functions which live in libwine, and so cross-compiling results in undefined references to wine_dbg_log() and wine_dbg_sprintf().
I've attached a patch as a proof-of-concept, which provides stubs for these functions (actually they are semi-stubs, as they proved useful when debugging the patch itself). As can be seen, it reduces the code necessary to set up test_render_filter_priority() to 1/3 of its original length (and it might be possible to reduce it further by using BaseRenderer and TransformFilter).
Is this something that would be workable?
ἔρρωσθε, Zeb
Hello,
I recognize this is not an easy question, but it would be nice to have an answer one way or the other. Currently I've been avoiding working on quartz tests since I don't want to do the work of rewriting strmbase if it's possible that I wouldn't have to.
ἔρρωσθε, Zeb
-
Aric Stewart -
Marvin -
Zebediah Figura