Recherche avancée

Sur d’autres sites (13880)

• Ffmpeg c++ can't compile with libxh264

  10 septembre 2022, par Turgut

  I made a program that uses the source version of ffmpeg. I get the code from it's website and compile/configured it. The problem is I want to configure it with the libx264 flag so it looks like this :

  


  ./configure --enable-shared --enable-libx264 --enable-gpl


  


  Ffmpeg itself compiles with no errors, however when I try to compile my own code using make I get this error :

  


  /usr/bin/cmake -E cmake_link_script CMakeFiles/Renderer.dir/link.txt --verbose=1
/usr/bin/c++ -O3 -DNDEBUG CMakeFiles/Renderer.dir/src/main.cpp.o CMakeFiles/Renderer.dir/src/Application.cpp.o CMakeFiles/Renderer.dir/src/opengl/OpenGLRenderer.cpp.o CMakeFiles/Renderer.dir/src/opengl/texture.cpp.o CMakeFiles/Renderer.dir/src/opengl/text_render.cpp.o CMakeFiles/Renderer.dir/src/opengl/image_render.cpp.o CMakeFiles/Renderer.dir/src/logging/Log.cpp.o CMakeFiles/Renderer.dir/src/utils/color_converter.cpp.o CMakeFiles/Renderer.dir/src/utils/maths.cpp.o CMakeFiles/Renderer.dir/src/utils/sys_util.cpp.o CMakeFiles/Renderer.dir/src/types/segment.cpp.o CMakeFiles/Renderer.dir/src/types/timeline.cpp.o CMakeFiles/Renderer.dir/src/coms/json_parser.cpp.o CMakeFiles/Renderer.dir/src/coms/socket.cpp.o CMakeFiles/Renderer.dir/src/video_io/video_encoder.cpp.o CMakeFiles/Renderer.dir/src/video_io/video_decode.cpp.o CMakeFiles/Renderer.dir/src/video_io/audio_mixer.cpp.o CMakeFiles/Renderer.dir/lib/glad/src/glad.c.o -o bin/Renderer  /usr/local/lib/libavformat.a /usr/local/lib/libavcodec.a /usr/local/lib/libswresample.a /usr/local/lib/libswscale.a /usr/local/lib/libavutil.a /usr/local/lib/libavdevice.a /usr/lib/x86_64-linux-gnu/libGL.so /usr/lib/x86_64-linux-gnu/libGLU.so /usr/lib/x86_64-linux-gnu/libfreetype.so lib/glfw/src/libglfw3.a lib/spdlog/libspdlog.a /usr/lib/x86_64-linux-gnu/libz.so /usr/lib/x86_64-linux-gnu/librt.a -lm -ldl /usr/lib/x86_64-linux-gnu/libX11.so 
/usr/bin/ld: /usr/local/lib/libavcodec.a(libx264.o): in function `X264_frame':
/home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/libx264.c:349: undefined reference to `x264_picture_init'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/libx264.c:518: undefined reference to `x264_encoder_encode'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/libx264.c:551: undefined reference to `x264_encoder_delayed_frames'
/usr/bin/ld: /usr/local/lib/libavcodec.a(libx264.o): in function `reconfig_encoder':
/home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/libx264.c:297: undefined reference to `x264_encoder_reconfig'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/libx264.c:212: undefined reference to `x264_encoder_reconfig'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/libx264.c:224: undefined reference to `x264_encoder_reconfig'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/libx264.c:250: undefined reference to `x264_encoder_reconfig'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/libx264.c:217: undefined reference to `x264_encoder_reconfig'
/usr/bin/ld: /usr/local/lib/libavcodec.a(libx264.o):/home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/libx264.c:230: more undefined references to `x264_encoder_reconfig' follow
/usr/bin/ld: /usr/local/lib/libavcodec.a(libx264.o): in function `X264_close':
/home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/libx264.c:605: undefined reference to `x264_param_cleanup'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/libx264.c:609: undefined reference to `x264_encoder_close'
/usr/bin/ld: /usr/local/lib/libavcodec.a(libx264.o): in function `parse_opts':
/home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/libx264.c:621: undefined reference to `x264_param_parse'
/usr/bin/ld: /usr/local/lib/libavcodec.a(libx264.o): in function `X264_init':
/home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/libx264.c:699: undefined reference to `x264_param_default'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/libx264.c:704: undefined reference to `x264_param_default_preset'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/libx264.c:729: undefined reference to `x264_param_parse'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/libx264.c:763: undefined reference to `x264_param_parse'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/libx264.c:795: undefined reference to `x264_levels'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/libx264.c:820: undefined reference to `x264_param_parse'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/libx264.c:821: undefined reference to `x264_param_parse'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/libx264.c:822: undefined reference to `x264_param_parse'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/libx264.c:823: undefined reference to `x264_param_parse'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/libx264.c:883: undefined reference to `x264_param_apply_fastfirstpass'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/libx264.c:924: undefined reference to `x264_param_apply_profile'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/libx264.c:1012: undefined reference to `x264_param_parse'From the updated error it appears you're explicitly linking with /usr/local/lib/libavcodec.a etc. So the problem almost certainly lies with your CMakeLists.txt file(s). – 

/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/libx264.c:1032: undefined reference to `x264_encoder_open_163'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/libx264.c:1041: undefined reference to `x264_encoder_headers'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/libx264.c:1072: undefined reference to `x264_encoder_maximum_delayed_frames'
/usr/bin/ld: /usr/local/lib/libavcodec.a(vaapi_encode_h264.o): in function `vaapi_encode_h264_configure':
/home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode_h264.c:1096: undefined reference to `vaQueryVendorString'
/usr/bin/ld: /usr/local/lib/libavcodec.a(vaapi_encode_h265.o): in function `vaapi_encode_h265_get_encoder_caps':
/home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode_h265.c:1176: undefined reference to `vaGetConfigAttributes'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode_h265.c:1190: undefined reference to `vaGetConfigAttributes'
/usr/bin/ld: /usr/local/lib/libavcodec.a(vaapi_encode.o): in function `vaapi_encode_wait':
/home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:157: undefined reference to `vaSyncBuffer'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:168: undefined reference to `vaSyncSurface'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:170: undefined reference to `vaErrorStr'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:161: undefined reference to `vaErrorStr'
/usr/bin/ld: /usr/local/lib/libavcodec.a(vaapi_encode.o): in function `vaapi_encode_free_output_buffer':
/home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:2412: undefined reference to `vaDestroyBuffer'
/usr/bin/ld: /usr/local/lib/libavcodec.a(vaapi_encode.o): in function `vaapi_encode_make_packed_header':
/home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:60: undefined reference to `vaCreateBuffer'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:71: undefined reference to `vaCreateBuffer'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:64: undefined reference to `vaErrorStr'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:75: undefined reference to `vaErrorStr'
/usr/bin/ld: /usr/local/lib/libavcodec.a(vaapi_encode.o): in function `vaapi_encode_make_param_buffer':
/home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:101: undefined reference to `vaCreateBuffer'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:104: undefined reference to `vaErrorStr'
/usr/bin/ld: /usr/local/lib/libavcodec.a(vaapi_encode.o): in function `vaapi_encode_alloc_output_buffer':
/home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:2430: undefined reference to `vaCreateBuffer'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:2435: undefined reference to `vaErrorStr'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:2447: undefined reference to `vaDestroyBuffer'
/usr/bin/ld: /usr/local/lib/libavcodec.a(vaapi_encode.o): in function `vaapi_encode_issue':
/home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:637: undefined reference to `vaDestroyBuffer'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:583: undefined reference to `vaBeginPicture'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:592: undefined reference to `vaRenderPicture'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:601: undefined reference to `vaEndPicture'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:618: undefined reference to `vaDestroyBuffer'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:621: undefined reference to `vaErrorStr'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:595: undefined reference to `vaErrorStr'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:634: undefined reference to `vaEndPicture'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:586: undefined reference to `vaErrorStr'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:603: undefined reference to `vaErrorStr'
/usr/bin/ld: /usr/local/lib/libavcodec.a(vaapi_encode.o): in function `vaapi_encode_output':
/home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:668: undefined reference to `vaMapBuffer'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:699: undefined reference to `vaUnmapBuffer'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:701: undefined reference to `vaErrorStr'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:671: undefined reference to `vaErrorStr'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:715: undefined reference to `vaUnmapBuffer'
/usr/bin/ld: /usr/local/lib/libavcodec.a(vaapi_encode.o): in function `vaapi_encode_profile_entrypoint':
/home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:1381: undefined reference to `vaMaxNumProfiles'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:1387: undefined reference to `vaQueryConfigProfiles'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:1389: undefined reference to `vaErrorStr'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:1411: undefined reference to `vaProfileStr'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:1441: undefined reference to `vaMaxNumEntrypoints'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:1447: undefined reference to `vaQueryConfigEntrypoints'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:1450: undefined reference to `vaErrorStr'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:1474: undefined reference to `vaEntrypointStr'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:1499: undefined reference to `vaGetConfigAttributes'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:1503: undefined reference to `vaErrorStr'
/usr/bin/ld: /usr/local/lib/libavcodec.a(vaapi_encode.o): in function `vaapi_encode_init_rate_control':
/home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:1574: undefined reference to `vaGetConfigAttributes'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:1578: undefined reference to `vaErrorStr'
/usr/bin/ld: /usr/local/lib/libavcodec.a(vaapi_encode.o): in function `vaapi_encode_init_gop_structure':
/home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:1953: undefined reference to `vaGetConfigAttributes'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:1958: undefined reference to `vaErrorStr'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:1977: undefined reference to `vaGetConfigAttributes'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:1982: undefined reference to `vaErrorStr'
/usr/bin/ld: /usr/local/lib/libavcodec.a(vaapi_encode.o): in function `vaapi_encode_init_slice_structure':
/home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:2206: undefined reference to `vaGetConfigAttributes'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:2211: undefined reference to `vaErrorStr'
/usr/bin/ld: /usr/local/lib/libavcodec.a(vaapi_encode.o): in function `vaapi_encode_init_packed_headers':
/home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:2269: undefined reference to `vaGetConfigAttributes'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:2274: undefined reference to `vaErrorStr'
/usr/bin/ld: /usr/local/lib/libavcodec.a(vaapi_encode.o): in function `vaapi_encode_init_roi':
/home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:2377: undefined reference to `vaGetConfigAttributes'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:2382: undefined reference to `vaErrorStr'
/usr/bin/ld: /usr/local/lib/libavcodec.a(vaapi_encode.o): in function `vaapi_encode_init_quality':
/home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:2331: undefined reference to `vaGetConfigAttributes'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:2336: undefined reference to `vaErrorStr'
/usr/bin/ld: /usr/local/lib/libavcodec.a(vaapi_encode.o): in function `vaapi_encode_init_max_frame_size':
/home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:1902: undefined reference to `vaGetConfigAttributes'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:1908: undefined reference to `vaErrorStr'
/usr/bin/ld: /usr/local/lib/libavcodec.a(vaapi_encode.o): in function `ff_vaapi_encode_init':
/home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:2630: undefined reference to `vaCreateConfig'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:2635: undefined reference to `vaErrorStr'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:2646: undefined reference to `vaCreateContext'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:2653: undefined reference to `vaErrorStr'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:2727: undefined reference to `vaSyncBuffer'
/usr/bin/ld: /usr/local/lib/libavcodec.a(vaapi_encode.o): in function `ff_vaapi_encode_close':
/home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:2762: undefined reference to `vaDestroyContext'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_encode.c:2767: undefined reference to `vaDestroyConfig'
/usr/bin/ld: /usr/local/lib/libavcodec.a(vaapi_decode.o): in function `ff_vaapi_decode_destroy_buffers':
/home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_decode.c:133: undefined reference to `vaDestroyBuffer'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_decode.c:143: undefined reference to `vaDestroyBuffer'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_decode.c:146: undefined reference to `vaErrorStr'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_decode.c:136: undefined reference to `vaErrorStr'
/usr/bin/ld: /usr/local/lib/libavcodec.a(vaapi_decode.o): in function `vaapi_decode_make_config':
/home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_decode.c:468: undefined reference to `vaMaxNumProfiles'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_decode.c:476: undefined reference to `vaQueryConfigProfiles'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_decode.c:540: undefined reference to `vaCreateConfig'
/usr/bin/ld: /usr/local/lib/libavcodec.a(vaapi_decode.o): in function `vaapi_decode_find_best_format':
/home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_decode.c:310: undefined reference to `vaQuerySurfaceAttributes'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_decode.c:322: undefined reference to `vaQuerySurfaceAttributes'
/usr/bin/ld: /usr/local/lib/libavcodec.a(vaapi_decode.o): in function `vaapi_decode_make_config':
/home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_decode.c:624: undefined reference to `vaDestroyConfig'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_decode.c:479: undefined reference to `vaErrorStr'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_decode.c:544: undefined reference to `vaErrorStr'
/usr/bin/ld: /usr/local/lib/libavcodec.a(vaapi_decode.o): in function `vaapi_decode_find_best_format':
/home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_decode.c:325: undefined reference to `vaErrorStr'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_decode.c:313: undefined reference to `vaErrorStr'
/usr/bin/ld: /usr/local/lib/libavcodec.a(vaapi_decode.o): in function `ff_vaapi_decode_make_param_buffer':
/home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_decode.c:44: undefined reference to `vaCreateBuffer'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_decode.c:47: undefined reference to `vaErrorStr'
/usr/bin/ld: /usr/local/lib/libavcodec.a(vaapi_decode.o): in function `ff_vaapi_decode_make_slice_buffer':
/home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_decode.c:90: undefined reference to `vaCreateBuffer'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_decode.c:104: undefined reference to `vaCreateBuffer'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_decode.c:95: undefined reference to `vaErrorStr'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_decode.c:109: undefined reference to `vaErrorStr'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_decode.c:112: undefined reference to `vaDestroyBuffer'
/usr/bin/ld: /usr/local/lib/libavcodec.a(vaapi_decode.o): in function `ff_vaapi_decode_issue':
/home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_decode.c:163: undefined reference to `vaBeginPicture'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_decode.c:172: undefined reference to `vaRenderPicture'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_decode.c:181: undefined reference to `vaRenderPicture'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_decode.c:190: undefined reference to `vaEndPicture'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_decode.c:192: undefined reference to `vaErrorStr'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_decode.c:166: undefined reference to `vaErrorStr'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_decode.c:210: undefined reference to `vaEndPicture'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_decode.c:212: undefined reference to `vaErrorStr'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_decode.c:175: undefined reference to `vaErrorStr'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_decode.c:184: undefined reference to `vaErrorStr'
/usr/bin/ld: /usr/local/lib/libavcodec.a(vaapi_decode.o): in function `ff_vaapi_common_frame_params':
/home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_decode.c:650: undefined reference to `vaDestroyConfig'
/usr/bin/ld: /usr/local/lib/libavcodec.a(vaapi_decode.o): in function `ff_vaapi_decode_uninit':
/home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_decode.c:707: undefined reference to `vaDestroyContext'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_decode.c:709: undefined reference to `vaErrorStr'
/usr/bin/ld: /home/turgut/Desktop/CppProjects/videoo-render/lib/ffmpeg/libavcodec/vaapi_decode.c:715: undefined reference to `vaDestroyConfig'


  


  (The error is a bit longer but I think this is ample for now.)

  


  The thing is, this code also runs on the cloud and compiles just fine without the --enable-libx264 flags. And inside the cloud, it works just fine even with the libx264 flag. But when I follow the exact same steps as the cloud and try to compile it locally, it gives this error.

  


  Here are the steps I have followed :

  


  First I removed ffmpeg (It was a bit messy) using sudo apt-get --purge autoremove ffmpeg then I made sure its deleted by searching find / -name ffmpeg and manually deleting my findings. Then, I ran apt-get install -y libx264-dev, followed by ./configure --enable-shared --enable-libx264 --enable-gpl inside the directory where I have downloaded the source files. Then ran make and make install where ffmpeg source files are. I ran ldconfig so it can detect shared libs (This is how it works on the cloud) and finally ran make on my own codes directory and got the error mentioned.

  


  Here is my CMakeFile :

  


  cmake_minimum_required(VERSION 3.7)

project(Renderer C CXX)
set(CMAKE_CXX_STANDARD 14)

SET( EXECUTABLE_OUTPUT_PATH ${dir}/bin )
set( CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/bin )


add_definitions(-DGL_SILENCE_DEPRECATION)
add_definitions("-g -lglad -lGL -lGLU -lX11 -lvdpau -lz -lva -lavformat -lavcodec- -lswscale -lavutil -lavfiter -lswresample 
-lavdevice -lpostproc  -loa -lz -lx264 -llzma -lbz2 -lrt -lx264 -pthread -lm  -lva-drm -lva-x11")

list(APPEND SOURCES
    ...
)

find_path(AVCODEC_INCLUDE_DIR libavcodec/avcodec.h)
find_library(AVCODEC_LIBRARY avcodec)

find_path(AVFORMAT_INCLUDE_DIR libavformat/avformat.h)
find_library(AVFORMAT_LIBRARY avformat)

find_path(AVDEVICE_INCLUDE_DIR libavdevice/avdevice.h)
find_library(AVDEVICE_LIBRARY avdevice)

find_path(AVCODEC_INCLUDE_DIR libavcodec/avcodec.h)
find_library(AVCODEC_LIBRARY avcodec)

find_path(AVUTIL_INCLUDE_DIR libavutil/avutil.h)
find_library(AVUTIL_LIBRARY avutil)

find_path(SWRESAMPLE_INCLUDE_DIR libswresample/swresample.h)
find_library(SWRESAMPLE_LIBRARY swresample)

find_path(SWSCALE_INCLUDE_DIR libswscale/swscale.h)
find_library(SWSCALE_LIBRARY swscale)

set(THREADS_PREFER_PTHREAD_FLAG ON)

add_executable(Renderer src/main.cpp src/Application.cpp src/Application.h ${SOURCES})

target_link_libraries(Renderer PRIVATE Threads::Threads)

list(APPEND EXTRA_LIBS
    "-lGL -lGLU -lX11 -lz -lva -lswresample -lx264 -shared -lvdpau -lva  -lm  -lva-drm -lva-x11"
)

target_include_directories(Renderer PRIVATE 
    ${AVFORMAT_INCLUDE_DIR} 
    ${AVCODEC_INCLUDE_DIR} 
    ${SWRESAMPLE_INCLUDE_DIR}
    ${SWSCALE_INCLUDE_DIR}
    ${AVUTIL_INCLUDE_DIR}
    ${AVDEVICE_INCLUDE_DIR} 
)

target_link_libraries(Renderer PRIVATE 
    ${AVFORMAT_LIBRARY} 
    ${AVCODEC_LIBRARY} 
    ${SWRESAMPLE_LIBRARY}
    ${SWSCALE_LIBRARY}
    ${AVUTIL_LIBRARY} 
    ${AVDEVICE_LIBRARY} 
)



  


  Like I said, it works on the cloud just the way it is and everything works without the --enable-libx264 flag.

  


  How can I fix this ? I'm on ubuntu 22+

  


• Monster Battery Power Revisited

  28 mai 2010, par Multimedia Mike — Python, Science Projects

  So I have this new fat netbook battery and I performed an experiment to determine how long it really lasts. In my last post on the matter, it was suggested that I should rely on the information that gnome-power-manager is giving me. However, I have rarely seen GPM report more than about 2 hours of charge ; even on a full battery, it only reports 3h25m when I profiled it as lasting over 5 hours in my typical use. So I started digging to understand how GPM gets its numbers and determine if, perhaps, it’s not getting accurate data from the system.

  I started poking around /proc for the data I wanted. You can learn a lot in /proc as long as you know the right question to ask. I had to remember what the power subsystem is called — ACPI — and this led me to /proc/acpi/battery/BAT0/state which has data such as :

  present :                 yes
  capacity state :          ok
  charging state :          charged
  present rate :            unknown
  remaining capacity :      100 mAh
  present voltage :         8326 mV
  

  "Remaining capacity" rated in mAh is a little odd ; I would later determine that this should actually be expressed as a percentage (i.e., 100% charge at the time of this reading). Examining the GPM source code, it seems to determine as a function of the current CPU load (queried via /proc/stat) and the battery state queried via a facility called devicekit. I couldn’t immediately find any source code to the latter but I was able to install a utility called ’devkit-power’. Mostly, it appears to rehash data already found in the above /proc file.

  Curiously, the file /proc/acpi/battery/BAT0/info, which displays essential information about the battery, reports the design capacity of my battery as only 4400 mAh which is true for the original battery ; the new monster battery is supposed to be 10400 mAh. I can imagine that all of these data points could be conspiring to under-report my remaining battery life.

  Science project : Repeat the previous power-related science project but also parse and track the remaining capacity and present voltage fields from the battery state proc file.

  Let’s skip straight to the results (which are consistent with my last set of results in terms of longevity) :

  
  
  

  So there is definitely something strange going on with the reporting— the 4400 mAh battery reports discharge at a linear rate while the 10400 mAh battery reports precipitous dropoff after 60%.

  Another curious item is that my script broke at first when there was 20% power remaining which, as you can imagine, is a really annoying time to discover such a bug. At that point, the "time to empty" reported by devkit-power jumped from 0 seconds to 20 hours (the first state change observed for that field).

  Here’s my script, this time elevated from Bash script to Python. It requires xdotool and devkit-power to be installed (both should be available in the package manager for a distro).
  

  PLAIN TEXT

  PYTHON :

  1. # !/usr/bin/python
  2.  
  3. import commands
  4. import random
  5. import sys
  6. import time
  7.  
  8. XDOTOOL = "/usr/bin/xdotool"
  9. BATTERY_STATE = "/proc/acpi/battery/BAT0/state"
  10. DEVKIT_POWER = "/usr/bin/devkit-power -i /org/freedesktop/DeviceKit/Power/devices/battery_BAT0"
  11.  
  12. print "count, unixtime, proc_remaining_capacity, proc_present_voltage, devkit_percentage, devkit_voltage"
  13.  
  14. count = 0
  15. while 1 :
  16.   commands.getstatusoutput("%s mousemove %d %d" % (XDOTOOL, random.randrange(0,800), random.randrange(0, 480)))
  17.   battery_state = open(BATTERY_STATE).read().splitlines()
  18.   for line in battery_state :
  19.     if line.startswith("remaining capacity :") :
  20.       proc_remaining_capacity = int(line.lstrip("remaining capacity : ").rstrip("mAh"))
  21.     elif line.startswith("present voltage :") :
  22.       proc_present_voltage = int(line.lstrip("present voltage : ").rstrip("mV"))
  23.   devkit_state = commands.getoutput(DEVKIT_POWER).splitlines()
  24.   for line in devkit_state :
  25.     line = line.strip()
  26.     if line.startswith("percentage :") :
  27.       devkit_percentage = int(line.lstrip("percentage :").rstrip(’\%’))
  28.     elif line.startswith("voltage :") :
  29.       devkit_voltage = float(line.lstrip("voltage :").rstrip(’V’)) * 1000
  30.   print "%d, %d, %d, %d, %d, %d" % (count, time.time(), proc_remaining_capacity, proc_present_voltage, devkit_percentage, devkit_voltage)
  31.   sys.stdout.flush()
  32.   time.sleep(60)
  33.   count += 1

• The 11th Hour RoQ Variation

  12 avril 2012, par Multimedia Mike — Game Hacking, dreamroq, Reverse Engineering, roq, Vector Quantization

  I have been looking at the RoQ file format almost as long as I have been doing practical multimedia hacking. However, I have never figured out how the RoQ format works on The 11th Hour, which was the game for which the RoQ format was initially developed. When I procured the game years ago, I remember finding what appeared to be RoQ files and shoving them through the open source decoders but not getting the right images out.

  I decided to dust off that old copy of The 11th Hour and have another go at it.

  
  
  

  Baseline
  The game consists of 4 CD-ROMs. Each disc has a media/ directory that has a series of files bearing the extension .gjd, likely the initials of one Graeme J. Devine. These are resource files which are merely headerless concatenations of other files. Thus, at first glance, one file might appear to be a single RoQ file. So that’s the source of some of the difficulty : Sending an apparent RoQ .gjd file through a RoQ player will often cause the program to complain when it encounters the header of another RoQ file.

  I have uploaded some samples to the usual place.

  However, even the frames that a player can decode (before encountering a file boundary within the resource file) look wrong.

  Investigating Codebooks Using dreamroq
  I wrote dreamroq last year– an independent RoQ playback library targeted towards embedded systems. I aimed it at a gjd file and quickly hit a codebook error.

  RoQ is a vector quantizer video codec that maintains a codebook of 256 2×2 pixel vectors. In the Quake III and later RoQ files, these are transported using a YUV 4:2:0 colorspace– 4 Y samples, a U sample, and a V sample to represent 4 pixels. This totals 6 bytes per vector. A RoQ codebook chunk contains a field that indicates the number of 2×2 vectors as well as the number of 4×4 vectors. The latter vectors are each comprised of 4 2×2 vectors.

  Thus, the total size of a codebook chunk ought to be (# of 2×2 vectors) * 6 + (# of 4×4 vectors) * 4.

  However, this is not the case with The 11th Hour RoQ files.

  Longer Codebooks And Mystery Colorspace
  Juggling the numbers for a few of the codebook chunks, I empirically determined that the 2×2 vectors are represented by 10 bytes instead of 6. Now I need to determine what exactly these 10 bytes represent.

  I should note that I suspect that everything else about these files lines up with successive generations of the format. For example if a file has 640×320 resolution, that amounts to 40×20 macroblocks. dreamroq iterates through 40×20 8×8 blocks and precisely exhausts the VQ bitstream. So that all looks valid. I’m just puzzled on the codebook format.

  Here is an example codebook dump :
  

  ID 0x1002, len = 0x0000014C, args = 0x1C0D
    0 : 00 00 00 00 00 00 00 00 80 80
    1 : 08 07 00 00 1F 5B 00 00 7E 81
    2 : 00 00 15 0F 00 00 40 3B 7F 84
    3 : 00 00 00 00 3A 5F 18 13 7E 84
    4 : 00 00 00 00 3B 63 1B 17 7E 85
    5 : 18 13 00 00 3C 63 00 00 7E 88
    6 : 00 00 00 00 00 00 59 3B 7F 81
    7 : 00 00 56 23 00 00 61 2B 80 80
    8 : 00 00 2F 13 00 00 79 63 81 83
    9 : 00 00 00 00 5E 3F AC 9B 7E 81
    10 : 1B 17 00 00 B6 EF 77 AB 7E 85
    11 : 2E 43 00 00 C1 F7 75 AF 7D 88
    12 : 6A AB 28 5F B6 B3 8C B3 80 8A
    13 : 86 BF 0A 03 D5 FF 3A 5F 7C 8C
    14 : 00 00 9E 6B AB 97 F5 EF 7F 80
    15 : 86 73 C8 CB B6 B7 B7 B7 85 8B
    16 : 31 17 84 6B E7 EF FF FF 7E 81
    17 : 79 AF 3B 5F FC FF E2 FF 7D 87
    18 : DC FF AE EF B3 B3 B8 B3 85 8B
    19 : EF FF F5 FF BA B7 B6 B7 88 8B
    20 : F8 FF F7 FF B3 B7 B7 B7 88 8B
    21 : FB FF FB FF B8 B3 B4 B3 85 88
    22 : F7 FF F7 FF B7 B7 B9 B7 87 8B
    23 : FD FF FE FF B9 B7 BB B7 85 8A
    24 : E4 FF B7 EF FF FF FF FF 7F 83
    25 : FF FF AC EB FF FF FC FF 7F 83
    26 : CC C7 F7 FF FF FF FF FF 7F 81
    27 : FF FF FE FF FF FF FF FF 80 80
  

  Note that 0x14C (the chunk size) = 332, 0x1C and 0x0D (the chunk arguments — count of 2×2 and 4×4 vectors, respectively) are 28 and 13. 28 * 10 + 13 * 4 = 332, so the numbers check out.

  Do you see any patterns in the codebook ? Here are some things I tried :

  • Treating the last 2 bytes as U & V and treating the first 4 as the 4 Y samples :
    
    
    
  • Treating the last 2 bytes as U & V and treating the first 8 as 4 16-bit little-endian Y samples :
    
    
    
  • Disregarding the final 2 bytes and treating the first 8 bytes as 4 RGB565 pixels (both little- and big-endian, respectively, shown here) :
    
    
    
  • Based on the type of data I’m seeing in these movies (which appears to be intended as overlays), I figured that some of these bits might indicate transparency ; here is 15-bit big-endian RGB which disregards the top bit of each pixel :
    
    
    

  These images are taken from the uploaded sample bdpuz.gjd, apparently a component of the puzzle represented in this screenshot.

  Unseen Types
  It has long been rumored that early RoQ files could contain JPEG images. I finally found one such specimen. One of the files bundled early in the uploaded fhpuz.gjd sample contains a JPEG frame. It’s a standard JFIF file and can easily be decoded after separating the bytes from the resource using ‘dd’. JPEGs serve as intraframes in the coding scheme, with successive RoQ frames moving objects on top.

  However, a new chunk type showed up as well, one identified by 0×1030. I have never encountered this type. Where could I possibly find data about this ? Fortunately, iD Games recently posted all of their open sourced games at Github. Reading through the code for their official RoQ decoder, I see that this is called a RoQ_PACKET. The name and the code behind it are both supremely unhelpful. The code is basically a no-op. The payloads of the various RoQ_PACKETs from one sample are observed to be either 8784, 14752, or 14760 bytes in length. It’s very likely that this serves the same purpose as the JPEG intraframes.

  Other Tidbits
  I read through the readme.txt on the first game disc and found this nugget :

          g)      Animations displayed normally or in SPOOKY MODE
                  SPOOKY MODE is blue-tinted grayscale with color cursors, puzzle
  
                  and game pieces.  It is the preferred display setting of the
  
                  developers at Trilobyte.  Just for fun, try out the SPOOKY
  
                  MODE.
  

  The MobyGames screenshot page has a number of screenshots labeled as being captured in spooky mode. Color tricks ?

  Meanwhile, another twist arose as I kept tweaking dreamroq to deal with more RoQ weirdness : After modifying my dreamroq code to handle these 10-byte vectors, it eventually chokes on another codebook. These codebooks happen to have 6-byte vectors again ! Fortunately, I was already working on a scheme to automatically detect which codebook is in play (plugging the numbers into a formula and seeing which vector size checks out).