Issues trying to compile about obs-vaapi HOT 13 CLOSED

I have several other plugins that I'm able to build as part of OBS which use cmake simply by doing this in my obs build:

Seems a bit odd to make source code modifications to OBS just to make it build a plugin that is presumably supposed to compile just fine on its own. 👀

This makes it hard/impossible to compile separate projects separately, upgrade one without the other, correctly mark the rpm name/version/upstream url for the plugin...

from obs-vaapi.

I have several other plugins that I'm able to build as part of OBS which use cmake simply by doing this in my obs build:

Seems a bit odd to make source code modifications to OBS just to make it build a plugin that is presumably supposed to compile just fine on its own. eyes

This makes it hard/impossible to compile separate projects separately, upgrade one without the other, correctly mark the rpm name/version/upstream url for the plugin...

Seems you may be a bit confused by my post.

I would like to compile the plugin independently, which is great. That is the starting point.

I would -also- like to be able to compile it as part of OBS as a path-moving-foward notion in the event that it should supercede the current FFMPEG VAAPI plugin already in OBS.

In my OBS build I am not modifying any OBS code other than adding plugins to the plugins list. My git clones are literally just dropping each plugin's code into obs's plugin directory. This is actually common practice for things such as the obs browser and other plugins that are pending being merged into obs. If you read the StreamFX documentation it also provides options for compiling StreamFX standalone -or- as part of OBS. Nothing new here.

from obs-vaapi.

I tested with OBS 28.0 RC1 at the moment.

I know that have been some issues with the pkg-config file in 27.x releases, so perhaps that is the reason obs-module.h is not found.

The defines not being found is a similar issue. It checkes for the new 10 bit formats in OBS 28.0 as it should be possible to record in 10 bit too.

Guess I will have to look atsomethings to make it compile with older OBS headers too,

from obs-vaapi.

I tested with OBS 28.0 RC1 at the moment.

I know that have been some issues with the pkg-config file in 27.x releases, so perhaps that is the reason obs-module.h is not found.

The defines not being found is a similar issue. It checkes for the new 10 bit formats in OBS 28.0 as it should be possible to record in 10 bit too.

Guess I will have to look atsomethings to make it compile with older OBS headers too,

My last OBS build was from a few days ago (f5be6f5fdd2fe34b18518ecd38030f0768845688) -- which is the tagged rc1 build so it should be there afaik :/. As I noted the obs include was found/resolved once I added obs/ infront of it (thats how its done in obs-gstreamer), but i dont know why the second error is occurring

from obs-vaapi.

How did you install your OBS? It is important that it installs the header files / pkg-config file in the regular locations. Perhaps instead meson is finding something from another install/package?

from obs-vaapi.

How did you install your OBS? It is important that it installs the header files / pkg-config file in the regular locations. Perhaps instead meson is finding something from another install/package?

It's a cloned copy of rpmfusion's obs build spec sheet. nothing abnormal there. obs-studio-devel package provides the headers in /usr/include/obs/

from obs-vaapi.

I know that have been some issues with the pkg-config file in 27.x releases, so perhaps that is the reason obs-module.h is not found.

Since obsproject/obs-studio@1fd7770 the libobs.pc dependency sets /usr/include/obs as the include directory. Previous versions of libobs.pc were apparently broken, as they set /usr/include and installed headers to obs/*.h but since at least 2017 the documentation states to include as <*.h> without obs/

This is an obs-studio bug that apparently... no one ever noticed? Ouch.

from obs-vaapi.

For me video_io.h:74 has these:

	/* planar 4:2:0 format, 10 bpp */
	VIDEO_FORMAT_I010, /* three-plane */
	VIDEO_FORMAT_P010, /* two-plane, luma and packed chroma */

Can you check if you have that too?

from obs-vaapi.

I know that have been some issues with the pkg-config file in 27.x releases, so perhaps that is the reason obs-module.h is not found.

Since obsproject/obs-studio@1fd7770 the libobs.pc dependency sets /usr/include/obs as the include directory. Previous versions of libobs.pc were apparently broken, as they set /usr/include and installed headers to obs/*.h but since at least 2017 the documentation states to include as <*.h> without obs/

This is an obs-studio bug that apparently... no one ever noticed? Ouch.

I think I know where that comes from. In OBS source tree's obs.h is found at libobs/obs.h so obs/obs.h is not helpful in in-tree builds. So regular builds and in-tree builds are kind of incompatible in that regard.

from obs-vaapi.

In my OBS build I am not modifying any OBS code other than adding plugins to the plugins list. My git clones are literally just dropping each plugin's code into obs's plugin directory. This is actually common practice for things such as the obs browser and other plugins that are pending being merged into obs.

It's uncommon practice outside of OBS, and I'd argue it's bad practice as a general software development thing... it's a violation of scope and not at all required for merging if it hasn't been merged, and not the most effective thing to optimize for.

Also, it's obviously a separate issue.

Seems you may be a bit confused by my post.

No, I think I understood quite well. :p

from obs-vaapi.

I think I know where that comes from. In OBS source tree's obs.h is found at libobs/obs.h so obs/obs.h is not helpful in in-tree builds. So regular builds and in-tree builds are kind of incompatible in that regard.

Hmm, but this really does not seem to be true as the documentation actually does say to use the same style either way.

I really just think this is broken. The best option, probably, is to do a configure check to see whether cc.has_header('obs.h', dependencies: libobs_dep) works, and if so, set a define for an if/else that selects which header style to use.

from obs-vaapi.

In my OBS build I am not modifying any OBS code other than adding plugins to the plugins list. My git clones are literally just dropping each plugin's code into obs's plugin directory. This is actually common practice for things such as the obs browser and other plugins that are pending being merged into obs.

It's uncommon practice outside of OBS, and I'd argue it's bad practice as a general software development thing... it's a violation of scope and not at all required for merging if it hasn't been merged, and not the most effective thing to optimize for.

Also, it's obviously a separate issue.

Seems you may be a bit confused by my post.

No, I think I understood quite well. :p

The goal behind compiling it as part of OBS is per the original discussion here:

https://ideas.obsproject.com/posts/1868/replace-linux-ffmpeg-vaapi-plugin-with-new-gstreamer-vaapi

I very much understand the reasoning behind keeping a "standalone" plugin as standalone --IF it is to remain standalone. As I've stated already, the request to allow it to build as part of OBS is aligned with the discussion noted -- eventually merging this plugin into OBS as a replacement, not keeping it standalone.

from obs-vaapi.

I fully understand the desire for this kind of build.

Once the plugin turns out usable I may consider looking at that. TL;DR is that I hate writing CMake to the spine and writing meson for me is like almost fun in contrast. But I also haven't taken a look at OBS's CMake rewrite. It certainly is possible it probably should get its own issue in the tracker..

from obs-vaapi.