Fix: parallel streams are concatenated instead of overlaid, output is N times too long

[Komuccap1]

Problem

create_video_with_gaps() assigns every clip its position on the webinar timeline
with .with_start(relativeTime) and then passes the list to
concatenate_videoclips(). That function discards .start and lays the clips
end to end.

A webinar is normally recorded as several parallel streams (presenter camera,
screen share, sometimes a second screen). With them appended instead of overlaid,
the output is roughly N times longer than the recording, and the same minutes are
shown again from a different source.

The audio path does not have this problem — create_audio_with_gaps() uses
CompositeAudioClip, which does honour .start. So video is sequential while
audio sits on the real timeline: the two drift apart by design.

Reported in #8 — 3 hours of source produced a 5.5 hour file after ~14 hours of
rendering.

Reproduction

from moviepy.video.VideoClip import ColorClip
from moviepy import concatenate_videoclips, CompositeVideoClip

# two parallel streams, 20 s of webinar
cam = [ColorClip((640, 360), (10, 10, 10), duration=10).with_start(t) for t in (0, 10)]
scr = [ColorClip((1920, 1080), (20, 20, 20), duration=10).with_start(t) for t in (0, 10)]
clips = sorted(cam + scr, key=lambda c: c.start)

print(concatenate_videoclips(clips, method='compose').duration)   # 40.0  <- wrong
print(CompositeVideoClip(clips).with_duration(20).duration)       # 20.0  <- correct

Fix

Replace concatenate_videoclips with CompositeVideoClip over a full-length black
background. The background also covers the gaps, so the manually inserted filler
clips are no longer needed and the function gets shorter.

Verified with the snippet above: 40.0 s → 20.0 s.

Note on layout

This restores correct duration and A/V sync. Where two streams are live at the same
time they now stack, with the later clip on top — which stream ends up visible
depends on the order in eventLogs. Proper composition (screen full frame with the
camera as a corner inset, or vice versa) is a separate decision and out of scope for
this fix; the point here is that the timeline is no longer wrong.

[Komuccap1]

Разобрался с причиной удвоения. Дело в create_video_with_gaps() в processor.py:
клипам проставляются позиции на таймлайне через .with_start(relativeTime), а
затем список уходит в concatenate_videoclips(), которая эти метки выбрасывает
и кладёт клипы встык. Вебинар пишется несколькими параллельными потоками (камера,
демонстрация экрана), поэтому итог выходит во столько раз длиннее, сколько было
потоков.

Звук при этом собирается через CompositeAudioClip, который метки уважает. То
есть видео идёт последовательно, а звук лежит на настоящем таймлайне — рассинхрон
получается by design.

Ощущение «замедления» обманчиво: сами чанки играют с нормальной скоростью, просто
одно и то же время вебинара показывается второй раз другой камерой.

Два открытых PR по этой теме:

• Fix: parallel streams are concatenated instead of overlaid, output is N times too long #17 — минимальная правка: concatenate_videoclips → CompositeVideoClip поверх
  чёрного фона полной длины. Один файл, 16 строк добавлено, 20 удалено. Чинит
  длительность и синхрон, не трогает всё остальное.
• Replace MoviePy with ffmpeg for 10-100x performance improvement #15 — большая переработка от @cyberb: полный отказ от moviepy в пользу ffmpeg,
  плюс нормальные раскладки кадра. Решает и производительность тоже.

Если нужно прямо сейчас, а ждать мержа не хочется — правка из #17 применяется к
своей копии за минуту.