Videos do load but cannot play them in Natron. No thumb nail shownd. MP4 and MOV do not work.

Hello,

I found another problem this time concerning Natron reading videos.

I tried so many differents type of videos but nothing. I can load the videos, but inside the node no thumbnail picture preview is shown. The problem stays with both MOV and MP4.

I work on linux mint and have Natron 2.3.14 version.

Thank you guys, I am really struggling to learn.

What codec ?

Hello Fabio,

It is an Mp4 token with an Iphone or Samsung or a video token with a reflex Nikon d3100

![Natro_error_video_mp4|690x363](upload://2Klk5qIKVXil98EGEGCA1gek7hF.png

Thank you a lot!

Working for me:

Natron 2.3.14 Windows 10

Oh man…That’s why I am having so many problems.

That’s so sad :frowning:

I love linux but sometimes does not help me out.

There are some problems with mp4 in linux version of Natron. In my case (Xubuntu 18.04), sometimes while reading mp4 file, some frames could not be read (ffmpeg error), meaning that those unread frames would become black. So, a workaround would be to turn video to image sequence:

Press Ctrl+Alt+T to open terminal and do:

cd /path/to/video

mkdir src

ffmpeg -i input.mp4 -qmin 1 -qmax 1 src/%05d.jpg

This will create high quality jpg from mp4 file and places it in src folder. Then you can drag all jpg files to Natron workspace to read it without any errors.

Is it linux or ffmpeg related ?

In Windows, have you ever seen any read node frame go black when reading an mp4 file while compositing? If not, then it is related to linux. Related issue (the same issue with me: end of file error of ffmpeg persistent message) on github: https://github.com/NatronGitHub/Natron/issues/231

Video works fine on Linux here (both custom built version using system libraries and 2.3.14 binary).

I noticed that 2.3.14 has some broken symlinks in IO.ofx.bundle/Libraries, may be related:

libOpenColorIO.so.[0-9] -> ../../../../../lib/libOpenColorIO.so.[0-9]
libgomp.so.[0-9] -> ../../../../../lib/libgomp.so.[0-9]
liblcms2.so.2 -> ../../../../../lib/liblcms2.so.2
1 Like

Hi Rodlie,
any idea when next version will be released ?
Will it include the fixes/modifications you made for your custom build ? :slight_smile:

@rodlie this was already fixed in the build scripts: https://github.com/NatronGitHub/Natron/commit/d8551d8eb13e21f80b3903e7d738fedcdce61d81

@fabiof17 it’s easy to tag a release, but the difficult part is to set up build systems for all three platforms. The linux build should be rather easy thanks to the docker-based SDK, but AFAIK nobody has macOS or Windows builds set up. The Windows SDK also needs an overhaul, which takes some time. I could do it myself, of course, but I think at this point contributors have to start taking this over. It is in my opinion more important to get the three platforms to build than to add Qt5 support or whatever. As soon as external contributors can start building Natron for all three platforms, then we can start talking about new features.

I agree. Before bringing something new, let’s make something that works for all plateforms.
I’m just expecting the next version in order to start playing with the callbacks in PyPanel and PyModalDialog. I’ll need it for my next pyton scrit, when the current one will be finished.

I will overhaul the Windows SDK and start providing test builds soon. Regarding macOS, I only have access to 10.11 (but targeting 10.9 (or lower) is no issue).

Regarding features etc I agree with Frédéric. I will not do any PR’s with features until we at least have a working build system (and 2.3.15 is out).

1 Like

On macOS the standard build is done using MacPorts, and it is very difficult to make a 10.9 MacPorts on a 10.11 system, so I strongly recommend having a 10.9 system.
Luckily, 10.9 works very nicely in a VM, provided that the host is running macOS/OSX, and it’s 100% legal (if you have a license for the host macOS).
Building in a VM can be painful because of the disk space it occupies, so I just keep the basic system (macOS + Xcode) in the VM, and I put the whole /opt directory in a “sparsebundle image” named “opt” mounted from the host. The name should have no space in it (MacPorts doesn’t like paths with spaces). A sparsebundle is a hfs disk image which is dynamically and automatically resizable. This means that it will not keep growing and filling up you host disk.

Here’s my setup for the macOS VM:

  • network: NAT, port forwartding host:3022 guest:22

To mount the sparsebundle, you must first create the sparsebundle on the host using Disk Utility (a 100GB image should be OK, and that’s just the maximum allowed size).

Then mount the host disk using SMB: lookup the host IP and do something like this in the guest terminal:
open 'smb://192.168.0.13/your_host_user_name'

macOS may ask for a password, and whether it should save it in the keychain, say yes.

Then mount the sparseimage: sudo hdiutil attach -owners on /Volumes/your_host_user_name/Path/To/MacPorts-opt-OSX-109.sparsebundle

And in the host you now just have to sudo rmdir /opt; sudo ln -s /Volumes/opt / (if you named the image opt, it should mount as /Volumes/opt)

now you can install macports and start building.

1 Like

Thanks for the info, I usually build depends manually on macOS so I forgot that MacPorts is tricky with different targets. Will setup as you advised.

I’m currently building the Windows SDK (takes forever), will start setting up macOS after that.

So, Windows builds will be delayed… Been messing with the SDK for a couple of days now on Windows and I’m having issues with latest MSYS2 (that auto updated itself several times during the SDK build) and some of the packages that needs to be built, with Qt being the top offender (missing several windows defines during build).

At this time I don’t know why Qt fails (the correct Windows headers with the defines are included), so I will be doing a complete reinstall and try again (using a known working toolchain would be best, but I’m unsure if I got any).

I might port the Windows SDK to MXE as an alternative (predictable) build solution.

Thank you guys for your work.