Engine as a video codec (video decoder)
Moderator: GZDoom Developers
-
- Posts: 87
- Joined: Tue Nov 20, 2018 12:27 pm
- Location: English is not my first language, sorry.
Engine as a video codec (video decoder)
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
- Spotlight Team
- Posts: 1052
- Joined: Mon Nov 25, 2019 8:54 am
- Graphics Processor: Intel (Modern GZDoom)
Re: Engine as a video codec (video decoder)
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.
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.
Re: Engine as a video codec (video decoder)
No, bloat is evil, plus a myriad of other issues.
-
- Posts: 87
- Joined: Tue Nov 20, 2018 12:27 pm
- Location: English is not my first language, sorry.
Re: Engine as a video codec (video decoder)
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.
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.
Re: Engine as a video codec (video decoder)
I think it's largely out of scope, since demos have never been the focus of GZDoom in the first place.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49067
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Engine as a video codec (video decoder)
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
- Spotlight Team
- Posts: 1052
- Joined: Mon Nov 25, 2019 8:54 am
- Graphics Processor: Intel (Modern GZDoom)
Re: Engine as a video codec (video decoder)
That's literally not what i am saying, either.NickDoom wrote:No, no, NOT EMBEDDING A VIDEO INTO .LMP!!!
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.NickDoom wrote: 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.
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.
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).NickDoom wrote: 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).
Such a thing is far beyond the scope of GZDoom, and GZDoom isn't a demo-oriented port in the first place.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49067
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Engine as a video codec (video decoder)
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.
Re: Engine as a video codec (video decoder)
Should we reopen this thread, then?Graf Zahl wrote: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.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49067
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Engine as a video codec (video decoder)
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.
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
- Spotlight Team
- Posts: 1052
- Joined: Mon Nov 25, 2019 8:54 am
- Graphics Processor: Intel (Modern GZDoom)
Re: Engine as a video codec (video decoder)
So something similar to a .gif dumper that outputs its individual frames as images, but then with demo's.Graf Zahl wrote: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.
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
-
- Posts: 87
- Joined: Tue Nov 20, 2018 12:27 pm
- Location: English is not my first language, sorry.
Re: Engine as a video codec (video decoder)
Thanks for keeping my knowledge about my English up-to-date I can't improve unless I have "bug reports".Redneckerz wrote: 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
So the demo will be played like "-timedemo", technically it's 35 fps but I shouldn't expect 35 fps output, am I right?Graf Zahl wrote: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.
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
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.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.
- Redneckerz
- Spotlight Team
- Posts: 1052
- Joined: Mon Nov 25, 2019 8:54 am
- Graphics Processor: Intel (Modern GZDoom)
Re: Engine as a video codec (video decoder)
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.NickDoom wrote: 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.
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.NickDoom wrote: 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
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.
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).NickDoom wrote: 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.
Expecting any of this to be in GZDoom (that does not have demo recording as its focus) is a big no.
-
- Posts: 87
- Joined: Tue Nov 20, 2018 12:27 pm
- Location: English is not my first language, sorry.
Re: Engine as a video codec (video decoder)
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. BecauseRedneckerz wrote:Unless someone else is willing to do put that in, Graf certainly is not going to.
I'm just trying to explain at last.Redneckerz wrote:Unless someone else is willing to do put that in
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.Redneckerz wrote: 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 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
- Spotlight Team
- Posts: 1052
- Joined: Mon Nov 25, 2019 8:54 am
- Graphics Processor: Intel (Modern GZDoom)
Re: Engine as a video codec (video decoder)
Very well then. But if its simply done, is that a bridge too far for you to endeavor in, or?NickDoom wrote: 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 that you understand but for any further developments, consider the demo running community on DoomWorld. Such a feature may have more use there.