Your question sounds like it's framed in a general sense. Unfortunately, in practice these legacy analog video sources usually each require their own unique solution. "Trivial" is probably the opposite word I would use. Anyway, you ideally need to know a few things:
The frequencies, pulse widths, and polarities of the HSYNC and VSYNC signals.
The temporal relationship between the HSYNC and VSYNC signals.
The driving circuitry of the HSYNC, VSYNC, and VIDEO signals.
You have provided a couple scope plots which address some of the info needed for #1. The easiest thing to recognize are that the polarities are both active high, or "positive" as it's normally called in literature.
Your frequency measurements are quite important, probably more than you think. The HSYNC frequency corresponds with the 625-line scanning system, most commonly used in conjunction with PAL color encoding in Europe. This frequency is 15.625KHz which has a period of 64µs. The VSYNC frequency shows 50.08Hz, and the .08Hz is actually the interesting part here. 625-line signaling is supposed to be exactly 50Hz (20ms period) because each field is made up of 312.5 lines (64µs \$\times\$ 312.5 lines = 20ms). However, you have 50.08Hz (19.968ms period). The difference between 20ms and 19.968ms is 32µs, which is half a line. This means your video signal is exactly 312 lines. The missing half of a line indicates that your signal is progressive video instead of the typical interlaced video. This is actually common for older computers and video game consoles. Since 625-line signaling is usually referred in the modern era as 576i (576 = visible line count, i = interlaced), we usually call this type of video 288p (576 \$\div\$ 2 = 288) where p = progressive.
You don't have an accurate measure of the pulse widths, but we can eyeball it from the plots to get a general idea. Your HSYNC pulse width is roughly 14µs. This could pose a problem, since the standard width for 625-line standard definition video is 4.7µs ± 0.2µs. Your VSYNC pulse looks like it's around 1.0ms, but since VSYNC is usually counted in an integer number of lines it's more likely 1.024ms (64µs \$\times\$ 16 lines = 1.024ms). Again, this is probably going to be a problem since the standard VSYNC width should be 2.5 lines (160µs), although I've seen 3 lines (192µs) used in many similar devices from the late 80's and early 90's. Probably anything between 2.5 and 3 should be fine, but 16 is likely way too long. Anyway, you're likely going to have to shorten both these widths somehow.
I asked you for more details regarding #2, but you haven't provided it. So, just to explain my reasoning, you want to know this because when you're designing logic to combine the HSYNC and VSYNC into CSYNC (composite sync) it can be important to know. Generating CSYNC is the first step in getting to the result you want. This is a complicated topic, and there are ways to do it correctly. However, many of these legacy computers and video games used shortcuts that can sometimes be "good enough" in most cases. I go over these in a blog post I made highlighting the issue. The easiest method is AND logic and a common device which used this method is the 1st version of the Sega Master System. Since your polarities are positive instead of negative, this would actually turn into NOR logic for your specific case (think De Morgan's theorem). So we basically need a NOR gate to implement this solution. If your VSYNC is not "coincident" with the HSYNC edges (i.e. changes state on HSYNC leading edges), then you could run into issues with the CSYNC generated with this method. That's why it's good to look at both syncs at the same time on the oscilloscope to see their temporal relationship.
The schematic link you provided coincidentally is missing the pages for the video circuit, which we need for #3. However, I did find another source of the document which includes the missing pages. Although the schematics are very blurry in this version, I think I can make out enough info. I'm pretty sure that the HSYNC and VSYNC come directly from 74LS00 outputs. The VIDEO signal seems to be 1-bit monochrome and comes out of a 74LS03 which is open collector with a pullup resistor R14 that appears to read 120Ω.
I think this is enough info to design a solution that could work. Below is an LTspice schematic and accompanying simulation. The two syncs are first NOR-ed together into CSYNC using the two N-channel MOSFETs with a common pullup resistor. Then, the 74LS03 output with the 120Ω pullup resistor is "mixed" together with the CSYNC via the 56Ω and 240Ω resistors to form a valid video signal. When terminated into a 75Ω load (i.e. what is in your TV) a valid video signal should show -0.3V for CSYNC and +0.7V for VIDEO, assuming a DC offset of 0V (i.e. the black level). A non-zero black level is fine and SCART allows for DC coupling the video (no AC coupling capacitor needed) as long as the black level is between 0V and +2.0V. Our black level is at ~0.4V, and so our sync swings from ~0.4V down to ~0.1V and our video signal swings from ~0.4V up to ~1.1V. The 1nF capacitor forms a crude analog reconstruction filter. It also filters general high-frequency noise and slows the rise/fall times of the sync pulses (to be closer to 625-line specifications).
The simulation above was run with ideal pulse widths (HSYNC = 4.7µs, VSYNC = 3 lines) and also assumes that the VSYNC is "coincident" with the HSYNC edges. I also made the VSYNC period shorter so we can see two VSYNC pulses without having to simulate over 312 lines. Not considered in the circuit is the problem highlighted at the beginning of this answer, where your pulse widths are way too large. The simplest way to remedy this would be to use a monostable multivibrator or "one-shot" (e.g. 74LS123, 74HCT423) to adjust the width of each pulse before NOR-ing them together. However, RC-based timers like these are known to not only be imprecise but also produce significant jitter on the trailing edges. If you're making a one-off of this circuit, then it's probably OK since you can manually tweak the RC values to achieve the proper widths. A properly designed TV shouldn't trigger on the trailing edge anyway (although I've seen this happen before...).
To close this out, I just wanted to clarify once again that using AND/NOR logic to generate CSYNC can cause incompatibilities. Even though this shortcut was used frequently in the past, it's still not ideal especially in the modern world. I cover this in great detail in the blog post I linked above, so I suggest reading it thoroughly if you want more details.
