Page 52 of 54

Posted: 19.06.2021, 13:04
by Art Blos
jjcatloaf123 wrote:Is Celestia Origin compatible with 1.7?
It has been said many times that compatibility is incomplete.

Posted: 19.06.2021, 16:22
by cartrite
onetwothree wrote:Actually i wasn't able to test windows ui with ffmpeg because it's not possible to crosscompile ffmpeg on gnu/linux using vcpkg now.

regarding your changes and remarks I'll address them
I have a dual boot machine. Grub controls the boot process and I can boot to suse leap 15.2 or windows 10. They are both real not virtual.

The main issue I had on Windows was that vcpkg installed ffmpeg with x264 disabled. So I get two options for codecs on linux, lossless and lossy h.264, but with Windows the codec tab is blank and useless. Also the first attempt always fails.

With linux , all the files, the build process, and the installation is orderly and perfected. But with windows it is total kaos. It is totally fu**** up. Files and folders are left out and the ones that do get installed go to all different places.

Added after 2 minutes 52 seconds:
So, I'm in the process of trying to figure out how too fix that.

Posted: 22.06.2021, 06:10
by onetwothree
Hi cartrite, could you try this branch:
https://github.com/CelestiaProject/Celestia/tree/fix/cmake

Added after 2 hours 29 minutes:
cartrite wrote:Also, I'm in the process of building ffmpeg with vcpkg. A long process. I noticed that x264 is disabled when building the ffmpeg tree. So I may be able to get that to work on the win32 version but for now, without x264.

try

Code: Select all

vcpkg install ffmpeg[gpl]


this should build ffmpeg with gpl feature which implies x264.

cartrite wrote:Did I see that y'all were about to abandon the cmake and go with ninga or conda builds?

i dunno what is conda, looks like a package manager. but ninja is not a replacement for cmake, it replaces make. (cmake -G Ninja .... to use ninja instead of make)

Added after 47 minutes 28 seconds:
regarding other ffmpeg issues - i've installed the recent ffmpeg and will fix them.

Posted: 22.06.2021, 15:57
by cartrite
I'm not sure how to download the branch you want me to try? I downloaded the zip file from the link but it's only 9.3 mb. Do I overwrite the master?

Added after 7 minutes 52 seconds:
I'll try to reinstall ffmpeg with the code above and see what happens. On windows.

Conda is a package manager. I just got confused.

Posted: 22.06.2021, 18:20
by onetwothree
added an additional commit to fix build with ffmpeg 4.4

Added after 39 seconds:
download link for the branch https://github.com/CelestiaProject/Celestia/archive/refs/heads/fix/cmake.zip

Posted: 22.06.2021, 21:55
by cartrite
I did not know that using "[]" in the vcpkg install command as in

Code: Select all

vcpkg install ffmpeg[x264]:x64-windows
would enable x264. It's working. Many Thanks. I'm reinstalling and I'll try your patch when finished.

Added after 2 hours 8 minutes:
I think I got it right but............
Anyhow I cloned the master version and overwrite with your version of cmake fix. I did not see any results. I still seen a blank codecs tab and the first attempt at capturing a "movie" fails. So...........

I did have success in building ffmpeg via vcpkg with 264 enabled so ................

Added after 1 hour 19 minutes:
I tried but I see no change.

Posted: 23.06.2021, 04:49
by onetwothree
those changes are to find ffmpeg files in suse and to allow building with 4.4. nothing beyond

Posted: 23.06.2021, 05:21
by cartrite
So........ I was using windows. I'll try with suse tomorrow. This you may have missed, This is what was needed

Code: Select all

if(ENABLE_FFMPEG)
  include(FindFFMPEG)
  find_package(FFMPEG REQUIRED COMPONENTS avcodec avdevice avutil avformat swscale)
  include_directories(${FFMPEG_INCLUDE_DIRS})
  add_definitions(-DUSE_FFMPEG)
endif()
My system was able to find ffmpeg but the compiler wasn't able to use it and it failed to build. Adding

Code: Select all

 include_directories(${FFMPEG_INCLUDE_DIRS})
to CMakeLists.txt is what got the compiler to work on Suse. I didn't see this addition in your changes.

Added after 5 minutes 45 seconds:
I added avdevice because it was listed at the bottom of ffmpeg.cmake file but it is probably not needed.

Posted: 23.06.2021, 05:38
by onetwothree
cartrite wrote:My system was able to find ffmpeg but the compiler wasn't able to use it and it failed to build. Adding
include_directories(${FFMPEG_INCLUDE_DIRS})
to CMakeLists.txt is what got the compiler to work on Suse. I didn't see this addition in your changes.

I hope that the following makes the same:

Code: Select all

 set_target_properties(FFMPEG::FFMPEG PROPERTIES
    IMPORTED_LINK_INTERFACE_LANGUAGES "C"
    INTERFACE_INCLUDE_DIRECTORIES "${FFMPEG_INCLUDE_DIR}")


cartrite wrote:I added avdevice because it was listed at the bottom of ffmpeg.cmake file but it is probably not needed.

yes, we don't use avdevice now.

Posted: 23.06.2021, 05:41
by cartrite
My windows system seems to have x264 enabled now. But I still have a blank codec tab on the moviecapture dialog with win32.

Added after 11 minutes 13 seconds:
As I said, I was on windows. I wasn't sure what you wanted. Your change will probably work on suse. I'll try it tomorrow night. Got to try and get some sleep now. I was off all last week but I got to go back to work tomorrow.

Added after 53 seconds:
My Monday. :fie:

Posted: 23.06.2021, 14:24
by onetwothree
The latest commit to the branch should fix "Codecs" combo box.

Posted: 23.06.2021, 23:27
by cartrite
Ok I just ran the cmake fix and it did not build. I downloaded it tonight so it should have had the recent changes you made. This how I proceeded. I cloned a fresh copy of the Master branch. I copied the content folder from the other day into the new Master. Then I downloaded Celestia-fix-cmake.zip from github and overwrote the Master with that folder. Edited CMakeLists.txt to tun on ffmpeg. The FFMPEG files were found but it failed on building

Code: Select all

[ 42%] Building CXX object src/celscript/lua/CMakeFiles/celluascript.dir/celx_celestia.cpp.o
In file included from /home/cartrite/Celestia_062221/Celestia/src/celestia/celestiacore.h:33:0,
                 from /home/cartrite/Celestia_062221/Celestia/src/celscript/lua/celx_celestia.cpp:31:
/home/cartrite/Celestia_062221/Celestia/src/celestia/moviecapture.h:6:10: fatal error: libavformat/avformat.h: No such file or directory
 #include <libavformat/avformat.h>
          ^~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make[2]: *** [src/celscript/lua/CMakeFiles/celluascript.dir/build.make:93: src/celscript/lua/CMakeFiles/celluascript.dir/celx_celestia.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:1327: src/celscript/lua/CMakeFiles/celluascript.dir/all] Error 2
make: *** [Makefile:147: all] Error 2
I'm going to switch over to windows now and check the ffmpeg. Did I need to use that patch too on Linux?

Added after 10 minutes 36 seconds:

Code: Select all

 set_target_properties(FFMPEG::FFMPEG PROPERTIES
    IMPORTED_LINK_INTERFACE_LANGUAGES "C"
    INTERFACE_INCLUDE_DIRECTORIES "${FFMPEG_INCLUDE_DIR}")
What file did you put that code into? I didn't see that change. I seen 2 folders where updated 2 days ago and another 9 hours ago. The win32 fix. Is that supposed to go into CMakeLists.txt?

Added after 1 hour 5 minutes:
With windows the first movie capture still fails. It does show lossy h.264 in the codecs tab. But that is the only option. The second movie capture does work.

Posted: 24.06.2021, 05:44
by onetwothree

Code: Select all

include_directories(${FFMPEG_INCLUDE_DIRS})

unfortunately this is unavoidable.

Added after 6 hours 37 minutes:
@cartrite could you test the following (under windows):
  • remove ffmpeg
  • go to vcpkg/ports/ffmpeg
  • find portfile.cmake
  • find line set(OPTIONS "--enable-pic --disable-doc --enable-debug --enable-runtime-cpudetect")
  • add --disable-amf
  • rebuild ffmpeg[gpl]

this might fix the issue with the first move not captured.

the problem is that ffmpeg on windows uses AMF which depends on COM and the latter should be initialized to work in multithreaded environment while the current native windows ui uses only single thread. without a person skilled in windows programming it's not possible to refactor it's for multithreading.

Posted: 25.06.2021, 03:01
by cartrite
onetwothree wrote:

Code: Select all

include_directories(${FFMPEG_INCLUDE_DIRS})

unfortunately this is unavoidable. Why, It is so simple. Does it do something wrong?

@cartrite could you test the following (under windows):
  • remove ffmpeg
  • go to vcpkg/ports/ffmpeg
  • find portfile.cmake
  • find line set(OPTIONS "--enable-pic --disable-doc --enable-debug --enable-runtime-cpudetect")
  • add --disable-amf
  • rebuild ffmpeg[gpl]

this might fix the issue with the first move not captured.

the problem is that ffmpeg on windows uses AMF which depends on COM and the latter should be initialized to work in multithreaded environment while the current native windows ui uses only single thread. without a person skilled in windows programming it's not possible to refactor it's for multithreading.
I tried this. It didn't work. I busted my ass today and tried this when I got home after work tonight, I't didn't work. Tied up my my computer for over 3 hours. There has got to a better way. I can try to remember how to code for multithread but I do not like using windows. I just started using that crap a few months ago. Because a former computer failed to operate anymore. But that even took time. With Linux I kept that freaken machine running for 4 or 5 years after the windows system failed. Windows sucks. Windows people will just have to live with the bug for now. It's not that bad, your in a still frame in the beginning so capture it twice, the second time it works. I tried. Sorry I didn't ....................

Added after 49 minutes 18 seconds:
With all due respect, what is actually wrong with this

Code: Select all

include_directories(${FFMPEG_INCLUDE_DIRS})
It makes it work. I'm not really sure why that is not acceptable.

I got limited skills working with windows code but I'll look at it. I had some conversations with Chris and Fridger about this long ago
. From what I remember, They discussed multithreading and it is not that complex, It's all about adding a build option. That is unless the code changed drastically. Which it probably did.

Posted: 25.06.2021, 08:19
by onetwothree
cartrite wrote:With all due respect, what is actually wrong with this

include_directories(${FFMPEG_INCLUDE_DIRS})
It makes it work. I'm not really sure why that is not acceptable.


Nothing wrong I just hoped to avoid this as I'm using custom targets with ffmpeg. So this line is included in the recent changes.

Posted: 25.06.2021, 08:48
by cartrite
I wanted to add this. Just woke up and I'm ready to go back to hell for day 3. But .........
I never found the line as you wrote it. My line in that file looked like this.

Code: Select all

set(OPTIONS "--enable-asm --enable-yasm --disable-doc --enable-debug --enable-runtime-cpudetect")
. I changed it to this

Code: Select all

set(OPTIONS "--enable-pic --disable-amf --enable-asm --enable-yasm --disable-doc --enable-debug --enable-runtime-cpudetect")
. I didn't see any change after rebuilding Celestia as far as capturing a video.

Added after 2 minutes 42 seconds:
Do you see anything wrong? Would asm or yasm be a problem? I'm thinking no but thought I'd ask.

Added after 1 minute 45 seconds:
Or maybe I shouldn't have added --enable-pic?

Posted: 25.06.2021, 10:05
by onetwothree
--enable-pic doesn't have effect for windows, it's always on. asm/yasm should do any harm, this is more about optimizations enabled.

i saw only error about com and i my case video recording didn't worked at all.

do you have any messages in console (both in celestia built-in and cmd.exe)?

Posted: 25.06.2021, 13:25
by cartrite
I never used a console with windows. I'll give it at tonight. Maybe it will show something.

Added after 8 hours 55 minutes:
You might find this interesting. Windows command prompt doesn't record anything but I have git installed which has a git bash. This what it recorded.
$ ./celestia-win
Loading image from file .\splash\splash.png
Error getting joystick caps.
Couldn't load localized resources: locale\res_LANGUAGE.dll
[h264_mf @ 00000268F3F5D780] COM must not be in STA mode
[h264_mf @ 00000268E32BB180] MFT name: 'H264 Encoder MFT'
Output #0, matroska, to 'C:\Users\spopo\Videos\test9.mkv':
Metadata:
encoder : Lavf58.45.100
Stream #0:0: Video: h264 (H264 / 0x34363248), yuv420p, 640x480, q=2-31, 400 kb/s, 24 fps, 1k tbn
Failed to open the codec
Saving preferences . . .
Opened registry key
I'll have to look for the res_LANGUAGE.dll. That may get translations working. With the moviecapture, the first line starting with [h264 is where it fails completely and an error message appears. After I click on ok, I try a second time and that is the second line starting with [h264. It does record the scene for as long as I wish after keying in F11. It stops when I key in F12. The video is saved. I'm not sure why it is saying "Failed to open codec".

Added after 30 minutes 34 seconds:
I had a good look in the folders and the above translations dll is not there. Not with the other dll's. So it probably isn't getting built.

Posted: 26.06.2021, 10:18
by onetwothree
translation dll are build separately yet. in po subdirectory there is a perl script translate_resources.pl. you can take it from 1.6.x branch or wait a few days until a pull request for it is merged. It accepts one parameter - win32 or x64. This script creates dll files with translated resources in locale/win32 or locale/x64.

cartrite wrote:[h264_mf @ 00000268F3F5D780] COM must not be in STA mode

I expected that `--disable-amf` fixes this error.

Posted: 10.07.2021, 21:16
by Goofy
Hi.
I use Cartrite's celestia setup from his 1018by cartrite » 17.06.2021, 17:46 (thanks a lot!), and it looks to work with no problems.
The only I found is when trying to launch fullscale screen using this command line:
"C:\CELESTIA\Celestia-1.7.0-Delta\celestia-win.exe" –fullscreen
it gives the error
"Invalid command line option 'fullscreen' :think:
Is this normal at the momemt?
Will it be added sometime?
Thank you

Goofy :smile: