Can I play a clip backward?

[stevie777]

Hey guys! When I load a video file I can loop it that it always start s again.

Is there a way to let it run backwards to the beginning?

And can I create shorter loops just of a few seconds for example by setting start-and endpoint in the clip?

Thanks for.your help!

[Magic]

Hi Stevie, thanks for your question.

Unfortunately there isn't a way to play a clip backwards. This is because most video is encoded specifically to play in one direction, and it can't be decoded backwards, at least in real-time. What you'd probably have to do is load the clip into some kind of offline editor that would let you reverse it, and then re-encode it. But the bottom line is you'd need two separate clips if you wanted to play forwards and backwards.

As far as the loop points, yes, you can just set the start and end point using the Start Time and End Time boxes. These let you specify a time in seconds.

Does that help?

Eric

[stevie777]

Hi Eric!

Thanks for your fast answer for shure you helped me.

[They Said They Saw]

Hi Eric,

sorry to jump on this (possibly closed) thread but that is precisely what I am after and I am gutted to hear Magic can't do that.

I have no idea how the software works, but sure must be a solution: many other VJ software are able to scratch video or ping pong playing, because the problem are not the movies in general but the type of codec, DXV from resolume (but available to anyone) and any type of MJPEG should do the trick, the file will be massively huge due to hold a keyframe per frame but extremely light to play. MP4 for their compression, are never recommended for VJing.

this is an example made on other software, by now almost obsolete, hence my interest in your fantastic program.
https://www.youtube.com/watch?v=C71U0FHJ36k


Your proposal of re-encoding backwards (although inconvenient due to duplicates) would make sense if there is a way to share the active frame number on both clips (forward and backward) this way the movement would be seamless when switching sources. Is it there any way to do that?

On the other hand, would be possible to force the output of a video to scrach using a shader? that would be very interesting too.

Any help achieving something similar to the link I've posted will be greatly appreciated, the way Magic can handle clips as layers and it's timeline is quite unique and it is also the reason I decided to get and explore this program.

Thanks,

Miguel

[Magic]

Hi Miguel, the history here is that we wanted to support as many codecs as possible, so we used an existing video engine called FFmpeg (https://www.ffmpeg.org/), which supports tons of codecs. But it doesn't support DXV unfortunately, and it also doesn't support backwards playback (simply because most codecs aren't designed to play backwards).

We would have needed to implement an entirely separate playback engine for DXV. Also, most of our users don't want to re-encode their videos, and as you noted the DXV file sizes are very large, which isn't ideal. So for all these reasons, it didn't seem worth investing our time just for one codec.

However, we are working on a solution which I think will address all of these issues, and we are planning to release it with Magic v1.62. Basically it will involve caching frames so that some or all of them are loaded into memory. Thus, you will be able to shuttle forwards or backwards very quickly and efficiently. We haven't worked out the exact details yet, but I think it will be pretty cool. One of the great advantages of Magic vs. other VJ apps is that it has a 64-bit version, so you can load a lot of stuff into memory -- many gigabytes' worth of media if you have enough RAM -- to improve performance.

[They Said They Saw]

I see, your explanation does ring a bell. I recall VJO (my old vj software of choice) having different modules even for different containers, I assume now that the reason may well be what you said.

Still, the need of video scratching or shifting playing direction is massive on the type of work I do since all my compositions are footage based.

The implement you are commenting about would be a godsend feature for me, but it makes me wonder how effective would be against long single clips since cacheing the whole clip could be a killer (perhaps chacheing what is being played while being played?) or when scratching different layers at once in a multilayered composition.

Nevertheless, I am looking forward for that update and I'd love to offer myself as beta tester in that area since is the part I understand and which I can provide extensive feedback.

Thanks for your fantastic work.

[Magic]

The implement you are commenting about would be a godsend feature for me, but it makes me wonder how effective would be against long single clips since cacheing the whole clip could be a killer (perhaps chacheing what is being played while being played?) or when scratching different layers at once in a multilayered composition.

True, but I think our solution will still address that. Stay tuned

[They Said They Saw]

so we used an existing video engine called FFmpeg (https://www.ffmpeg.org/), which supports tons of codecs.

With a bit more of testing, I can see that actually the video support is really good, I have been able to play even .flv without any hassle, the part I most enjoy is the fact that you can change the clip on the fly while projecting and the output doesn't flicker at all, it just switches from one avi to other. It feels very robust since you can edit and play on the go.

The downside of working with compressed video, is that when using the HueSaturation module, even at a value of 0.1 on Saturation, it creates artifacts on the output while a less compressed video much displays better results.

But I guess that conversation should go in another post.

Thanks,

Miguel

[Syd]

to the best of my knowledge whilst the dxv codec binaries are 'free' in price, the source/headers etc needed to implement (hardware accelerated) support in other players isn't available.

interestingly though, I just this minute noticed FFMPEG seem to have committed support for vidvox's free and open HAP codec for VDMX

https://github.com/FFmpeg/FFmpeg/commit ... 5d75c5c1e4

[Magic]

Aah, that's cool. I'll update the FFmpeg version then. But, there will still be an issue with HAP's performance, because it's supposed to be used with a shader that does YUV to RGB, and FFmpeg doesn't support that, as far as I know.