Exporting to a video some time create a video of ~1s
As said in the title, there are time I can't explain why, but it goes through the whole export, but the output video is juste ~1 to 2seconds long ending abruptly.
The export process goes through all the frames. And looking at the developer console does not show any warning or error, so I'm not sure what's happening there.
I'm using it on Mac OS X (10.15.7) and it is the last version, at least the check update says so (version 1.2.0) I haven't try to build a version from the sources yet, but most of the changes has been package updates, so I doubt it would fix anything.
Not sure how to help there to give more infos
Here are the log from one export that failed:
astrofox Starting process: /Applications/Astrofox.app/Contents/Resources/bin/ffmpeg -y -i /var/folders/z1/bjw67dmd5bvgbgmq2qhf9xrm0000gn/T/Astrofox/1947a04a1ee7cfb3685d9c3395fd9a8a86e601cb.mp4 -i /var/folders/z1/bjw67dmd5bvgbgmq2qhf9xrm0000gn/T/Astrofox/1947a04a1ee7cfb3685d9c3395fd9a8a86e601cb.aac -codec copy -shortest -movflags +faststart /Users/godzil/Desktop/BankB.mp4
app.js:1 astrofox ffmpeg version 4.3.1-tessus https://evermeet.cx/ffmpeg/ Copyright (c) 2000-2020 the FFmpeg developers
built with Apple clang version 11.0.0 (clang-1100.0.33.17)
configuration: --cc=/usr/bin/clang --prefix=/opt/ffmpeg --extra-version=tessus --enable-avisynth --enable-fontconfig --enable-gpl --enable-libaom --enable-libass --enable-libbluray --enable-libdav1d --enable-libfreetype --enable-libgsm --enable-libmodplug --enable-libmp3lame --enable-libmysofa --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenh264 --enable-libopenjpeg --enable-libopus --enable-librubberband --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvmaf --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid --enable-libzimg --enable-libzmq --enable-libzvbi --enable-version3 --pkg-config-flags=--static --disable-ffplay
libavutil 56. 51.100 / 56. 51.100
libavcodec 58. 91.100 / 58. 91.100
libavformat 58. 45.100 / 58. 45.100
libavdevice 58. 10.100 / 58. 10.100
libavfilter 7. 85.100 / 7. 85.100
libswscale 5. 7.100 / 5. 7.100
libswresample 3. 7.100 / 3. 7.100
libpostproc 55. 7.100 / 55. 7.100
app.js:1 astrofox Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '/var/folders/z1/bjw67dmd5bvgbgmq2qhf9xrm0000gn/T/Astrofox/1947a04a1ee7cfb3685d9c3395fd9a8a86e601cb.mp4':
Metadata:
major_brand : isom
minor_version : 512
compatible_brands: isomiso2avc1mp41
encoder : Lavf58.45.100
Duration: 00:00:00.17, start: 0.000000, bitrate: 9347 kb/s
Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 854x480, 9321 kb/s, 60 fps, 60 tbr, 15360 tbn, 120 tbc (default)
Metadata:
handler_name : VideoHandler
app.js:1 astrofox [aac @ 0x7f843e008800] Estimating duration from bitrate, this may be inaccurate
Input #1, aac, from '/var/folders/z1/bjw67dmd5bvgbgmq2qhf9xrm0000gn/T/Astrofox/1947a04a1ee7cfb3685d9c3395fd9a8a86e601cb.aac':
Duration: 00:00:47.33, bitrate: 167 kb/s
Stream #1:0: Audio: aac (LC), 48000 Hz, stereo, fltp, 167 kb/s
app.js:1 astrofox Output #0, mp4, to '/Users/godzil/Desktop/BankB.mp4':
Metadata:
major_brand : isom
minor_version : 512
compatible_brands: isomiso2avc1mp41
encoder : Lavf58.45.100
app.js:1 astrofox Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 854x480, q=2-31, 9321 kb/s, 60 fps, 60 tbr, 15360 tbn, 15360 tbc (default)
Metadata:
handler_name : VideoHandler
Stream #0:1: Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 167 kb/s
Stream mapping:
Stream #0:0 -> #0:0 (copy)
Stream #1:0 -> #0:1 (copy)
Press [q] to stop, [?] for help
app.js:1 astrofox [mp4 @ 0x7f843d809400] Starting second pass: moving the moov atom to the beginning of the file
app.js:1 astrofox frame= 10 fps=0.0 q=-1.0 Lsize= 194kB time=00:00:00.12 bitrate=12435.4kbits/s speed= 165x
video:190kB audio:3kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.774424%
app.js:1 astrofox Process ended with code 0 and signal null
I had the same problem on my MacBook. Once I changed the mp3 to WAV it finally kind of worked. But still it gave me 1:34 minutes instead of the full 2:44. Perhaps something to look into.
That’s interesting, will give a try!
The same behavior I'm getting here too. My OS is Ubuntu 20.04 and I have tried both wav files and mp3 files. I'm using the available Astrofox-1.2.0.AppImage file
It seems it trims every audio file while exporting to mp4 :/ , The exported video file I have received is only 2 seconds. Can anyone suggest any workaround?
I'm also seeing audio files trimmed substantially. I have a 2.5m song that's resulting in files between 10-25s.
Can everyone try the latest version, 1.3.0? The rendering engine has been completely rewritten.
1.3.0? The latest release was 1.2.0. Also, I downloaded Astrofox 2 days ago and I'm having the same problem.
1.3.0 is the latest

I tried using a brand new Astrofox installation (1.3.0 from the Astrofox website on MacOS 11.5.2) and had the exact same problem.
@supremestdoggo Can you try opening the developer tools and share what the output displays?
Here's the log: astrofox_save.log
@supremestdoggo This line seems to show the error
app.js:1 astrofox [rawvideo @ 0x7fc3d3008200] Packet corrupt (stream = 0, dts = 12).
pipe:0: corrupt input packet in stream 0
[rawvideo @ 0x7fc3d4008c00] PACKET SIZE: 5967872, STRIDE: 5525
[rawvideo @ 0x7fc3d4008c00] Invalid buffer size, packet size 5967872 < expected frame_size 8294400
Error while decoding stream #0:0: Invalid argument
Something went wrong when it tried to send frames to ffmpeg. Not sure what is going on. I tried on my macbook (MacOS 11.6) and everything ran fine. I'll keep digging but not much I can do if I can't replicate it.
I believe it is a lack of backpressure at renderProcess.push(image) in src/video/VideoRender.js . It will prematurely end the stdin write before all data has been processed at stdin; When the frames are finished rendering, it cuts short the write to stdin, as it hasn't caught up yet, and leads to the packet corruption error shown above — it's too small.
I believe the way to solve this is to have an await renderProcess.push(image), with a matching Promise for push, such that there is backpressure and the frames will advance and correspond correctly to what has been written to stdin.