Engine as a video codec (video decoder)

[NickDoom]

Can demo .lmp be played as video files somehow? Some stub video codec which actually calls (G)ZDoom engine, playing demo to a video player buffer instead of screen&speakers.

[Redneckerz]

That would increase the file size exponentially and be subject to accuracy loss. An LMP is a real time playback of a demo rendered in engine.

There are historic cases that have done this, actually, but they died out, for the reason given above.

Besides, any such tool would likely target PrBoom+ first since that's what demo users use and has a lot of variables related to it.

[Rachael]

No, bloat is evil, plus a myriad of other issues.

[NickDoom]

No, no, NOT EMBEDDING A VIDEO INTO .LMP!!!
You misunderstood me or I misunderstood your answer but I'm talking about a small and elegant hack which simply redirects the output to a standard video player interface, synchronising with the VP's needs instead of real-time clock and playing a common tiny demo file accordingly to the engine-to-player data flow.
Yes, it'll require installed (G)ZDoom with proper .WADs, exactly like demos are played now. But it'll allow to apply some VP's post-effects as well as grabbing a video with ANY encoding (not a real-time encoding like video grabbers do).
Having a "(G)ZDoom engine as a system-wide video decoder" (with help of some stub library, I think) will allow to render .LMP demos directly into final encoding, even if it's not real-time (and vice versa, if CPU can't take all that blood fireworks in some mods, there'll be no framerate troubles on replay).
Seriously, why grab a video from a screen if you can ask the engine politely to give it. It'll take one small "fake output" library which looks like a video decoder to a system, and some support for external sync in the engine. And instead of Demo→screen-by-screen grab→bloated (barely compressed) file→re-encoding to VP9 the chain will look like Demo→encoding to VP9. Without dropped frames, quality loss (on re-encoding) etc.

[Gez]

I think it's largely out of scope, since demos have never been the focus of GZDoom in the first place.

[Graf Zahl]

Keep in mind that just saving each frame to the hard drive without passing it to a video encoder will cause performance issues. A video screen readback is not a cheap operation.

[Redneckerz]

No, no, NOT EMBEDDING A VIDEO INTO .LMP!!!

That's literally not what i am saying, either.

You misunderstood me or I misunderstood your answer but I'm talking about a small and elegant hack which simply redirects the output to a standard video player interface, synchronising with the VP's needs instead of real-time clock and playing a common tiny demo file accordingly to the engine-to-player data flow.

You know what you are writing, yourself? This isn't an attack, but i feel you use a lot of terminology that, according to your own admission that English isn't your second language, is confusing for most of us. This was also readily apparent in your VoxelDoom thread.

Onto to your question,The only thing that comes close to this is ZDRec, an old ZDaemon based port that ticks some of these boxes. Sadly its not available anymore and it got no traction for the sole reason that produced files are huge (Its a video after all). Even that has no integration with any player, as it simply produces a video file.

I take it you either want a hack that works with OBS or with VLC/Windows Media Player. In which case GZDoom is not your port of call.

Yes, it'll require installed (G)ZDoom with proper .WADs, exactly like demos are played now. But it'll allow to apply some VP's post-effects as well as grabbing a video with ANY encoding (not a real-time encoding like video grabbers do).

The demo community has programs based on PrBoom that allow frame by frame editing of a demo, but its not a video file. What you seek is seemingly a plugin to direct to a player or editor of choice so you can add post processing effects in (like in Adobe Premiere or such).

Such a thing is far beyond the scope of GZDoom, and GZDoom isn't a demo-oriented port in the first place.

[Graf Zahl]

What would make sense is to add a feature to the engine to play back a demo and export it as a stream of images - but that could never be done as a real time feature because it's simply too slow. For exporting a video you need a constant predetermined frame rate - that simply does not mix with playing at the same time - real time playing needs to compensate for frame drops while a video exporter must not do that under any circumstances.

[Rachael]

What would make sense is to add a feature to the engine to play back a demo and export it as a stream of images - but that could never be done as a real time feature because it's simply too slow. For exporting a video you need a constant predetermined frame rate - that simply does not mix with playing at the same time - real time playing needs to compensate for frame drops while a video exporter must not do that under any circumstances.

Should we reopen this thread, then?

[Graf Zahl]

No. Unless someone is willing to add such a feature.
I only said, this is the only case I deem worthy of thinking about when it comes to exporting gameplay footage. Everything else won't work as intended due to the different needs of how frame rate needs to be handled.

[Redneckerz]

What would make sense is to add a feature to the engine to play back a demo and export it as a stream of images - but that could never be done as a real time feature because it's simply too slow. For exporting a video you need a constant predetermined frame rate - that simply does not mix with playing at the same time - real time playing needs to compensate for frame drops while a video exporter must not do that under any circumstances.

So something similar to a .gif dumper that outputs its individual frames as images, but then with demo's.

If its a lengthy demo, the stream of images dumped will be enormous. Not a problem with current HDD/SSD sizes - But finding the correct frame would be the next step.

Even in that case its so far beyond what GZ purports to be that one would be better off using PrBoom+ as a base for such a modification - Not GZDoom. That''s no sleight on GZ, its simply not intended for such a obscure feature.

Either way, good thinking

[NickDoom]

i feel you use a lot of terminology that, according to your own admission that English isn't your second language, is confusing for most of us. This was also readily apparent in your VoxelDoom thread

Thanks for keeping my knowledge about my English up-to-date I can't improve unless I have "bug reports".

No. Unless someone is willing to add such a feature.
I only said, this is the only case I deem worthy of thinking about when it comes to exporting gameplay footage. Everything else won't work as intended due to the different needs of how frame rate needs to be handled.

So the demo will be played like "-timedemo", technically it's 35 fps but I shouldn't expect 35 fps output, am I right?
That's how video editors usually work. They're OK with non-realtime sources. They request a frame from a source decoder library (which is the GZDoom Codec in this case), wait until the decoder unpack it, process the frame and pass it to the target encoder (which can be very slow), and source decoder (GZDoom Codec) waits until both editor and encoder finish processing the frame.
Avisynth works the similar way. It's a "fake codec" (a frameserver working thru a common video codec interface) with it's own "videos" which are actually procession scripts. And it encounters the same problem: "that could never be done as a real time feature", so if the processing script is heavy and the .avs "pseudo-video" is opened with a player, not an editor, there'll be awful lags between each frames. I'm OK with such restriction

If its a lengthy demo, the stream of images dumped will be enormous. Not a problem with current HDD/SSD sizes - But finding the correct frame would be the next step.

That's why I suggest output to a video decoder interface, not to a hard drive. A frameserver, not a HDD filler. And the most common and standard interface is the video codec interface. Avisynth works this way, it "decodes" .avs scripts, and ZDoom (or PrBoom) can "decode" .lmp demos exactly the same way.

[Redneckerz]

That's how video editors usually work. They're OK with non-realtime sources. They request a frame from a source decoder library (which is the GZDoom Codec in this case), wait until the decoder unpack it, process the frame and pass it to the target encoder (which can be very slow), and source decoder (GZDoom Codec) waits until both editor and encoder finish processing the frame.

The thing is GZDoom has no such ''codec'', for the simple reason that it does not need it. No port has a codec like you describe.

Avisynth works the similar way. It's a "fake codec" (a frameserver working thru a common video codec interface) with it's own "videos" which are actually procession scripts. And it encounters the same problem: "that could never be done as a real time feature", so if the processing script is heavy and the .avs "pseudo-video" is opened with a player, not an editor, there'll be awful lags between each frames. I'm OK with such restriction

You seem to misunderstand here - This feature as suggested will never be in GZDoom. for a variety of reasons given. GZDoom does not have a frameserver, to go with.

Its good to know that you are okay with imposed restrictions, but you seem to miss the most important restriction of them all - Inclusion in GZDoom. Unless someone else is willing to do put that in, Graf certainly is not going to.

That's why I suggest output to a video decoder interface, not to a hard drive. A frameserver, not a HDD filler. And the most common and standard interface is the video codec interface.

GZDoom has neither of these, so by that basis alone it does not meet your suggestion. As suggested, your best is the demo recording community, and they use PrBoom+ most of the time (Through LMPC and the like).

Expecting any of this to be in GZDoom (that does not have demo recording as its focus) is a big no.

[NickDoom]

Unless someone else is willing to do put that in, Graf certainly is not going to.

I don't insist, I understood and stopped doing it already. Maybe I've not pointed on that enough, but I'm describing the task itself. Because

Unless someone else is willing to do put that in

I'm just trying to explain at last.

The thing is GZDoom has no such ''codec'', for the simple reason that it does not need it. No port has a codec like you describe.

I didn't say it has. I've tried to say it can be simply done by writing a stub "fake codec" library which actually is a bridge from the engine to a video editor. And it looks like "GZDoom Codec" for the editor.
I understand it's a useless explanation "unless someone else is willing to do put that in", but I wanted to explain what did I mean by that.
I give up Not with my English.

[Redneckerz]

I didn't say it has. I've tried to say it can be simply done by writing a stub "fake codec" library which actually is a bridge from the engine to a video editor. And it looks like "GZDoom Codec" for the editor.

Very well then. But if its simply done, is that a bridge too far for you to endeavor in, or?

I understand that you understand but for any further developments, consider the demo running community on DoomWorld. Such a feature may have more use there.