Video instead texture

[Apeirogon]

Is there are any way to show video at wall?

[wildweasel]

You'd have to have every single frame of it as a texture, then define the animation in [wiki]ANIMDEFS[/wiki]. There's no support for video codecs in GZDoom right now.

[Rachael]

While wildweasel is technically correct, there's absolutely no way to sync the video with its audio using this method, and all textures are animated based on the system timer, not the level's internal timer. You cannot queue sounds this way.

[Apeirogon]

You'd have to have every single frame of it as a texture, then define the animation in [wiki]ANIMDEFS[/wiki]. There's no support for video codecs in GZDoom right now.

This is first what I though. But because video, in general case, is sequence of pictures bounded together by black codec magick, maybe some lossless format can be used for this.

While wildweasel is technically correct, there's absolutely no way to sync the video with its audio using this method, and all textures are animated based on the system timer, not the level's internal timer. You cannot queue sounds this way.

You mean "you cant start animation when player cross some line"?

[Jaxxoon R]

It's possible to iteratively change a texture on a wall to each frame of the video using an ACS script, I did it for Wooo3's fmvs.

[Nevander]

I'd just create an animated texture based on frames from the video, and then place a MapSpot beside the texture for the sound source. Using an ACS script and a lineid for the line you want the video to play, do a [wiki]SetLineTexture[/wiki] and then [wiki]PlaySound[/wiki] together in the same tic so they will be synced.

[wildweasel]

I'd just create an animated texture based on frames from the video, and then place a MapSpot beside the texture for the sound source. Using an ACS script and a lineid for the line you want the video to play, do a [wiki]SetLineTexture[/wiki] and then [wiki]PlaySound[/wiki] together in the same tic so they will be synced.

Bear in mind though, sync can be broken by things like saving the game.

[Chris]

Bear in mind though, sync can be broken by things like saving the game.

Or an audio underrun. Or simply time; the audio device and system clocks use different timing sources, and no two timing sources run at exactly the same rate (one second for the audio device is not the same as one second for the system clock). The difference in speed for the audio or visual source may not be apparent, but over time the difference will become more and more significant until it's obviously not in sync anymore.

[Nevander]

It's always in sync for me though, I don't see why it wouldn't be. You could always make several clips of a longer audio file and then play them in sequence then.

[Chris]

It's always in sync for me though, I don't see why it wouldn't be.

Depends on how long the clip is (shorter clips have less time to drift out of sync, obviously), how sensitive you are to synchronization (if you're not listening for it, a sound can be desynced by a fair amount without it being bothersome), and the system (some systems take longer for the drift to become noticeable, while others can be more readily apparent).

It also depends on the synchronization itself. The human brain is a lot more forgiving with a sound cue coming after its visual counterpart (given that sound travels much slower than light, the brain is tuned to accept some delay between seeing something and hearing it while still considering it the "same event"), although a sound cue that happens first before the visual cue tends to stand out more since that's not something that happens in nature. So if the sound drifts backwards it will take longer before the brain realizes something's wrong, compared to it drifting forward. Also, if the sound starts out fairly delayed and drifts forward, it will take longer for the desynchronization to be an issue compared to it starting less delayed and drifting forward.

[Apeirogon]

and no two timing sources run at exactly the same rate (one second for the audio device is not the same as one second for the system clock).

HOLD ON
Show movie frame with animations supports fractional tics format, like 4.3 ticks or 0.33333333... so I can make one "frame" second eaqule to one "audio" second.
What exactly difference between this two clock? Or how find out this difference, if it own for every single computer?

[Rachael]

You can't. This is hardware dependent code. GZDoom by rule does not have access to this information.

You're also gonna lose sync if the player presses the pause key.

[Mikk-]

I'd just create an animated texture based on frames from the video, and then place a MapSpot beside the texture for the sound source. Using an ACS script and a lineid for the line you want the video to play, do a [wiki]SetLineTexture[/wiki] and then [wiki]PlaySound[/wiki] together in the same tic so they will be synced.

Bear in mind though, sync can be broken by things like saving the game.

And the sync for the ANIMDEFS method mentioned above can be broken simply by opening the game menu as the animation ticker continually functions

[Chris]

What exactly difference between this two clock? Or how find out this difference, if it own for every single computer?

You can't. It's not only different between computers, it's not exactly constant on one computer either; clocks also have a thing called jitter, where it can tic just a little bit earlier or a little bit later than intended (welcome to engineering; nothing is perfect or exact, just "good enough" within some margin of error).

The proper way I've seen to synchronize video and audio streams is to base playback on some reference clock. This reference clock will basically tell you which video frame and which audio sample you should be at, at any given time. By keeping a rough average of each stream's actual position relative to that reference, you can correct for significant deviations (e.g. slow down an audio stream if it's getting too far ahead, skip video frames if it's too far behind) until it's back within an acceptable margin of error.

[Apeirogon]

What exactly difference between this two clock? Or how find out this difference, if it own for every single computer?

You can't. It's not only different between computers, it's not exactly constant on one computer either; clocks also have a thing called jitter, where it can tic just a little bit earlier or a little bit later than intended (welcome to engineering; nothing is perfect or exact, just "good enough" within some margin of error).

The proper way I've seen to synchronize video and audio streams is to base playback on some reference clock. This reference clock will basically tell you which video frame and which audio sample you should be at, at any given time. By keeping a rough average of each stream's actual position relative to that reference, you can correct for significant deviations (e.g. slow down an audio stream if it's getting too far ahead, skip video frames if it's too far behind) until it's back within an acceptable margin of error.

You mean something like

Code: Select all

int global_constant_defined_outside=0;

script clock (void)
{
ACS_NamedExecute(video_show)
ACS_NamedExecute(audio_show)
global_constant_defined_outside ++;
delay(1)
}

script video_show (void)
{if(player_press_button_that_show_movie)
{
if(global_constant_defined_outside==0){show_frame_with_number_one;}
if(global_constant_defined_outside==1){show_frame_with_number_two;}
if(global_constant_defined_outside==2){show_frame_with_number_three;}
...
if(global_constant_defined_outside==inf){show_last_frame; terminate;}
}
delay(1)
}

script audio_show (void)
{
same_as_video_except_sounds_play_check_only_number_(n)*34_wher_n_eaql_integer_or_zero
}