--output-ppm-stream does not obey -s

[GoogleCodeExporter]

Using the following command line:

gource -r 30 -1280x720 -s .5 --disable-progress --stop-at-end --highlight-users 
--output-ppm-stream - input.gource | ffmpeg -y -f image2pipe -vcodec ppm -r 30 
-i - -vcodec libx264 -b 8000000 -r 30 -threads 4 -vpre slow output.mp4

The issue is that gource bogs down quite a bit as it gets into the second half 
of the project log. This is understandable as there are a large number of files 
and lots going on, so I'm not really expecting realtime performance.

However, it'd be great if gource would actually obey the -s switch and stick to 
creating half-second days at 30 fps in the PPM output (as per the above 
config). The PPM output seems to mirror what's going on in the gource window 
real-time, which is a slow-motion version of what I want. In other words, if 
someone's outputting PPM, it'd be reasonable to expect that they don't really 
care about actual rendering speed - so the PPM should only have 15 frames per 
second in my case, no matter what happens in the project log itself.

In other words, as per the above config, the PPM has 15 frames for every day 
near the beginning. (half-second days at 30 fps) However, near the end, I can 
count as many as 24 frames per day.

Using gource 0.28 on Ubuntu.

Original issue reported on code.google.com by amar...@gmail.com on 1 Dec 2010 at 6:36

[GoogleCodeExporter]

Forgot to mention: AWESOME app! Thanks for creating it. I actually thought 
codeswarm was cool...

Original comment by amar...@gmail.com on 1 Dec 2010 at 6:37

[GoogleCodeExporter]

Hi.

Gource actually works pretty much how you propose when you use the 
--output-ppm-stream option. For -r 30 it runs at 60fps internally (ie each 
frame is calculated as if a 60th of a second had passed since the previous 
frame), and outputs every other frame to STDOUT (ie 30fps). 

(it doesn't run at 30fps internally, as the directory layout physics starts to 
fall apart at under 60fps).

So the video you produce should in theory look flawless in the sections you saw 
it bog down when rendering. If it isn't, eg like if there are repeated frames, 
then there is indeed a problem in how it is screen capturing the frames.

Cheers

Andrew

Original comment by acaudw...@gmail.com on 1 Dec 2010 at 7:38

[GoogleCodeExporter]

Hi Andrew, thanks for the response. I've tried it with another, much 
larger/busier log file (essentially the entire perforce repository of a company 
with 200 developers), and I set -s to .05 to get 20 days in a second, which 
should mean that the video plays out in under 2 minutes (there's 6 years worth 
of effort in the logs).

With -r 30 and -s .05 a day should be 1.5 frames (or rather 3 days would be 2 
frames). However, this is never the case: early on in the log I'm getting ~20 
frames per day, and later (with much more activity) it's above 70. The frames 
have the right stuff in them, each and every one is different, but the 
animation itself is just a lot slower than the -s switch would dictate. In 
other words, I don't think it's a problem with the capture mechanism, it's 
probably an issue with -s being more of a "guideline" to gource, and not a hard 
rule.

Original comment by amar...@gmail.com on 1 Dec 2010 at 6:52

[GoogleCodeExporter]

What are you using to determine it staying on one day for 70+ frames? Is it the 
clock?

Where it gets behind, do the number of commits per second exceed the fps?

Original comment by acaudw...@gmail.com on 2 Dec 2010 at 1:16

[GoogleCodeExporter]

Andrew,

I'm going through the video file frame by frame and looking at the date/time 
indicator at the top of the image. Yes, the number of commits per second do 
exceed the fps to a very large degree.

-Marton

Original comment by amar...@gmail.com on 2 Dec 2010 at 1:58

[GoogleCodeExporter]

I am trying to do the same thing as Amar, I am trying to boil 5 years down to 5 
minutes. This is the command I am using:

gource gource.log --seconds-per-day 0.16439 --time-scale 1.0 
--disable-auto-skip --max-file-lag 20.00 --file-idle-time 0 --max-files 10000 \
--title "Request Tracker" --date-format '%Y-%m-%d %T'   -1600x1080 
    --highlight-users   --user-friction 1.0 --max-user-speed 50 --highlight-dirs 
    --bloom-multiplier 0.5  --bloom-intensity 0.75  --user-scale 
1.6 --user-image-dir images/    --highlight-users   --hide mouse,progress   --key 
    --stop-at-end   --output-framerate 30 --output-ppm-stream - | ffmpeg -y  -r 30 
-f image2pipe -vcodec ppm -i - -threads 0 -r 24000/1001 -b 6144k -bt 8192k 
-vcodec libx264 -pass 1 -flags +loop -me_method dia -g 250 -qcomp 0.6 -qmin 10 
-qmax 51 -qdiff 4 -bf 16 -b_strategy 1 -i_qfactor 0.71 -cmp +chroma -subq 1 
-me_range 16 -coder 1 -sc_threshold 40 -flags2 
-bpyramid-wpred-mixed_refs-dct8x8+fastpskip -keyint_min 25 -refs 1 -trellis 0 
-directpred 1 -partitions -parti8x8-parti4x4-partp8x8-partp4x4-partb8x8 -an 
GourceMovie_RT.mp4

The period I am trying to convert is from the "2010-07-02" to "2012-03-27". 
This is 634 days, and hence the video should be approx 1:40, however it is 3:40 
- and does not seem to have a smooth progression of the date at the top.

I am quite sure that I have some periods with more commits than the fps so I 
will try to "cheat" and push these in the log-file to ensure that I do not have 
more than 1 commit pr. second and see if I get better results.

Original comment by e...@altapay.com on 30 Nov 2013 at 1:45

[GoogleCodeExporter]

Work-around found: The opposite of my first suggestion, I group all changes by 
hour such that there is at max 24 "events" pr. day, this makes the time run 
clean and smooth.

Original comment by e...@altapay.com on 30 Nov 2013 at 3:27