*solved* Trouble with previously working clips in the R_E_C_U_R 2.1.0 beta

technical questions/help
#1

I’ve been using the stable release for quite a while without issues, but since I had to do a clean reinstall anyway I decided to try the 2.1 beta today. Over all it’s working, but when I try to play the same clips I’ve been using for months in v2.0.2 they play at the wrong aspect ratio and resolution (stretched a bit horizontally, and enlarged enough that about 10% of the frame is lost on the right and bottom edges) when I use ofvideoplayer and don’t play at all with ofomxplayer (PLAYING is displayed in the player bar but the location doesn’t advance and there’s no output). The same files worked fine with both backends in v2.0.2.

This is how all of the clips are encoded:

recur-clip-info

Any idea what might be wrong before I revert back to the older version? Do the clips need to be encoded at 720x480 now? I chose 640x480 because it was listed as the preferred resolution somewhere on the github when I originally set it up last year.

#2

Sounds random - for sure nothing in the way videos should be encoded has changed.

I’m not sure why this would happen - would need to take a deeper look into it (send through an example video and I will take a look next time I find time - this prob won’t be soon tho :pensive:)

unfortunately with general rpi updates sometimes low level video playing drivers change which can cause these kind of things. Iv found it pretty hard to regression test the video players when doing this kinda thing. Hopefully it’s a bug or mistake I introduced and can be fixed. If you find workaround any else out also let me know :innocent:

#3

Here’s one of the clips I tried:

The only change other than reformatting the SD card and writing the 2.1.0 image to it is that I’m using a different keypad now, which shouldn’t matter. The only video setting I changed from the defaults was switching from PAL to NTSC.

#4

False alarm, it took me a lot longer to figure out than it should have but it turns out the issue was that the output was being routed through auto_waaave and the new version of auto_waaave defaults 16:9. I rerouted my whole setup a little while ago and I’m still getting used to it; in the old one preset 1 on the matrix switch would have put the direct r_e_c_u_r output on the monitor at startup.

Sorry about that!

I’m still experiencing some stability issues, where certain clips that worked fine before are now immediately crashing OF2 (I get the recur splash screen on the output until I restart OF2 but everything else still works) as soon as I load them into a player. I’m going to re-encode and see if that helps at all.

#5

No luck with that specific clip, but everything else seems to be OK.

Here’s the file that’s giving me trouble:

I’ve re-encoded it from the source file with both FFMPEG and Handbrake, same results. The one I uploaded is from Handbrake, using the same preset I’ve been using to prepare all of my clips for recur. This worked fine with 2.0.2 (and all the other clips I’ve tried are OK with the same encode settings). ofomxplayer and ofvideoplayer behave the same way - as soon as it’s loaded intoa player, openframeworks crashes (either to the recur splash or to a blank terminal screen with a cursor but no prompt or anything else).

Not the end of the word to just not use this file for now, but I figure it’s something you’d want to check.

chat.scanlines.xyz