Open wodfer opened 7 years ago
The files/codecs/resolutions that are ok are the ones the ffmpeg libraries can handle, which in practice is most of them (with the notable exception of cineform).
And the fact that you can see the frame in the application indicates that your file is one of the ones that is OK. (And the filename suggests it's an h.264 .mp4 file, which is definitely one that ffmpeg handles).
What was the action that immediately preceded the crash in that picture?
As soon as I move the scan frame bar it crashes. I've tested this numerous times. Only seem to work well with mjpeg files for me on Windows 10.
Since it waits until you advance the frame (either manually or via calibration), that suggests it is a problem with the glBlitFramebuffer() call. So this is likely another version of the opengl driver problem others have experienced with Win10. This would be unusual in that it only occurs with certain video files while working fine with others on the same machine.
Hello everybody, I'd like to refresh this thread because I'm having a similar issue: I can open an .mp4 file (see the attached 1screen.png) but when start playing with the slider to find a desired frame count, the preview gets half green (see the attached green.png) and if I go forth with the slider, just the program shuts down and the Apple crash report log appear (attached the log file). This seems to happen with both .mp4 and .mov files, not with .dpx sequences.
Thanks for your help franco
Hi there,
I find it gets a bit touchy using most movie files. The best way I found was using TIFF Sequence files.
It might work if you have software to convert the MP4 to a TIFF, PNG or JPEG Sequence File.
RC
On March 18, 2020 at 7:39 PM, faraanco notifications@github.com wrote:
Hello everybody, I'd like to refresh this thread because I'm having a similar issue: I can open an .mp4 file (see the attached 1screen.png) but when start playing with the slider to find a desired frame count, the preview gets half green (see the attached green.png) and if I go forth with the slider, just the program shuts down and the Apple crash report log appear (attached the log file). This seems to happen with both .mp4 and .mov files, not with .dpx sequences.
Thanks for your help franco
AeoCrash.log
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.
So, you think is not a matter of which codec or sw I used to encode those video files?
Many thanks f
I've just had problems with video files, no matter what codec I used. The sequence files just always worked better for me.
RC
On March 19, 2020 at 12:10 PM, faraanco notifications@github.com wrote:
So, you think is not a matter of which codec or sw I used to encode those video files?
Many thanks f
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.
The wrapper type is of no effect. It is using non intraframe codecs. I would highly recommend the use of intraframe only codecs. ffmpeg decoding is not set up well for random frame access of temporal codecs. When using a codec like h264 not every frame exists. For the predictive p frames this is a problem for aeo light when using random frame access functions like calibration. Extracting probably would probably not be an issue because when the frames are accessed sequentially it reproduces properly. The use of non intraframe codecs is also not recommened because it will yield bad audio. The codecs always degrade high rate of change picture data which is what optical audio is. The mp4 file only has a full image every 12 or 15 frames and the others are generated predictively which for sound information will be not good.
Nice, got it.
Thank you very much!!
f
I tried on two different Macs with Catalina, with h264 (inter-frame) and prores (intra-frame). It crashes almost immediately in both cases when scrolling the sequence. Using a sequence of dpx or tiff is ok, but it takes a lot of space.
yes...
so, what the solution?
thanks
f
Il 13 giugno 2020 alle 20.17 fabrizio carraro notifications@github.com ha scritto:
I tried on two different Macs with Catalina, with h264 (inter-frame) and prores (intra-frame). It crashes almost immediately in both cases when scrolling the sequence. Using a sequence of dpx or tiff is ok, but it takes a lot of space. — You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/usc-imi/aeo-light/issues/10#issuecomment-643659034 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AO3Y6WHAZ7SCBOMR45PPYVTRWO7CBANCNFSM4EA5QLRQ .
I tried on two different Macs with Catalina, with h264 (inter-frame) and prores (intra-frame). It crashes almost immediately in both cases when scrolling the sequence. Using a sequence of dpx or tiff is ok, but it takes a lot of space.
I'm unable to reproduce Catalina errors as I've no access to a Catalina Mac. Are you able to confirm that the same ProRes file processes without crashing on a Mac running Mojave?
Using Tiff files works better than .mov or any movie files on a Mac. You might want to get an inexpensive PC for making your audio files. I use an HP PC for aeo-light. Works so much better than the Mac. No headaches. I’m primarily a Mac user but having access to both systems helps a lot with getting results you need.
RC
Sent from my iPonyExpress
On Jun 15, 2020, at 10:51 AM, Greg Wilsbacher notifications@github.com wrote:
I tried on two different Macs with Catalina, with h264 (inter-frame) and prores (intra-frame). It crashes almost immediately in both cases when scrolling the sequence. Using a sequence of dpx or tiff is ok, but it takes a lot of space.
I'm unable to reproduce Catalina errors as I've no access to a Catalina Mac. Are you able to confirm that the same ProRes file processes without crashing on a Mac running Mojave?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.
After loading MP4 or mov files AEO Light is getting quit while scanning the frame for giving the set-out point. I tried different sources. All the file getting quit.
After loading MP4 or mov files AEO Light is getting quit while scanning the frame for giving the set-out point. I tried different sources. All the file getting quit.
Convert the .mp4 to a codec like Prores that has no inter-frame compression and then run the file.
Thank You. Now pro res mov file is not quitting but I am not getting correct speed audio and audio is wobbling. Dit mov file should have over scan picture to get a correct sound? Thank You, Venkatesh
From: Greg Wilsbacher @.> Sent: 17 June 2024 18:31 To: usc-imi/aeo-light @.> Cc: Venkatesh Manickam @.>; Comment @.> Subject: Re: [usc-imi/aeo-light] Program crashes when scanning frames and calibrating mp4 (#10)
After loading MP4 or mov files AEO Light is getting quit while scanning the frame for giving the set-out point. I tried different sources. All the file getting quit.
Convert the .mp4 to a codec like Prores that has no inter-frame compression and then run the file.
- Reply to this email directly, view it on GitHubhttps://github.com/usc-imi/aeo-light/issues/10#issuecomment-2173340392, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BJIB56EGBCKUCLPUW2D7NSLZH3M2BAVCNFSM6AAAAABJNHFUYKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNZTGM2DAMZZGI. You are receiving this because you commented.Message ID: @.**@.>>
So, I start a new project, choose an mp4 file, buffer incoming video. Then I either scan frame to see the optical tracks or go to image processing and choose calibrate. Then program locks up / crashes.
You ought to say something about what files/codecs/resolutions are ok when adding files to AEOlight.
https://imgur.com/a/XjKGy
thx