https://github.com/acaudwell/Gource/issues/216
ffmpeg now says "Invalid data found when processing input" #216
Comments
|
Same issue here. My version is ffmpeg-4.2.1. |
|
Does this happen with Gource 0.49 if you build it from source too? Wondering if its a change in behaviour with ffmpeg. Also what distro and release is this occuring on? |
|
Yes, it does. But 2.8.15 works fine. |
|
Can confirm I see the same issue with ffmpeg 4.2.1. ffmpeg 3.4.6 is fine. |
|
The Gource ppm header has a comment line I see that the last change to the I think maybe |
|
Hmm. That doesn't seem to be the right bit of code. Since the comment in the header Gource includes is superfluous. I've removed it as a workaround for now a3e7269. |
|
Gource 0.51 Seems the issue still exists
|
|
Oh? The fix is in the sub module, in src/core (src/core/ppm.cpp), is it possible the submodule is out of date? Tried it again seems to be working. |
|
is there any way how I can troubleshoot it? I checked and btw, it works if I set |
|
Things you could try:
If it is using the new code and its still an issue could you could supply the command line your using, what resolution your running at. |
|
Would be useful to get other peoples experience with the fix. |
|
I did what you suggested above, recompiled and the issue still exists.
How I run:
btw, it works fine with ffmpeg 3.4.2 |
|
Thanks I will try those settings. I notice the resolutions seem to be different in the output, I wonder if its has to do with Apple Retina display handling, maybe you could also try adding the One other thing to rule out is if you have several versions of gource and its running an old one? |
|
kia ora @acaudwell I confirmed that this change resolves this issue for me on FreeBSD when moving from 0.47 to 0.51. It's being used in dwatch(1) and you can see it in action later on in https://www.invidio.us/watch?v=xqOl_HY86n8 debugging kernels! |
|
@dch good to know. Didn't know about this thanks for the link. |
|
Having upgraded to 0.51 on macOS thanks to #225: $ gource --help | head -1
Gource v0.51
I seem to still be running into the same issue. The generated log file's first couple of lines look like this: $ head -2 prompt.ppm
P6
2560 1440 255
Display resolution is 2560x1600. The machine (Macbook Pro 2019, 13-inch, running 10.15.1) is also hooked up to two external displays, each of them displaying at 1920x1200. Gource was being run on the primary display (2560x1600). ffmpeg was run like this: $ ffmpeg -y -r 60 -f image2pipe -vcodec ppm -i prompt.ppm -vcodec libx264 -preset medium -pix_fmt yuv420p -crf 1 -threads 0 -bf 0 prompt.mp4
ffmpeg version is 4.2.1, installed via Homebrew. If there's anything else I can provide to help diagnose this, apologies for omitting it and please don't hesitate to ask. |
|
Maybe it's related to the image size? You could try and render a smaller window (e.g. add You could also try this SDL window flag option: #216 (comment) |
|
It seems to still happen at 2560x1440. So the thing to eliminate if its any ppm video at that resolution or if its specific to gource. |
|
I should also really look at an alternative lossless video format with some basic compression. I might try adding a png output option with minimal compression so it's not too slow. |
|
Thanks @acaudwell, I'll look at checking those things (won't be back at my office desk until Tuesday so might not be until then -- unless I can get the data I was using down the wire at home). I think I did forget to mention one thing: I'd run gource with |
|
Turns out I could get access to the log file. Running this all again on my personal Macbook Pro (2019, 13inch) it worked just fine. Created the $ gource -1280x720 -c 4 prompt.log -o prompt.ppm
and converted like this: $ ffmpeg -y -r 60 -f image2pipe -vcodec ppm -i prompt.ppm -vcodec libx264 -preset medium -pix_fmt yuv420p -crf 1 -threads 0 -bf 0 prompt.mp4
and the conversion went through without incident. The setup here, vs the one on my desk at work, is more or less identical in terms of the main machine. The only difference here is that I'm running with the lid closed and hooked up to an external display. running at 1920 x 1080, the default for that display. If I'm reading the above correctly, this is where the flag you mention comes in? And I take it this is something to be done when building Gource from source? If so, when I get a chance and am sure I have the correct setup, I'll try and give that a go (unless the above is enough to help nail this). In that setup I'm left with the head of the If I run with the lid open, on the main display:
I get this in the That results pretty quickly in me getting a |
|
I think I've confirmed this is an ffmpeg bug with ppm image sequences. Given a video that is 1920x1080 (also seems to be a problem with that resolution). Convert it to a sequence of ppm images in one file: Try to convert it to another format: During conversion there is the If you do the same thing but with |
|
Also looks like it's only the 4.2.1 release that hangs when you get the If you use a nightly build/ build from master it just continues on if it gets an error so it's not really an issue at that point. I recommend that as a work around if you're having this problem. Presumably for homebrew you can add |
|
Thanks, when I next get a chance I'll try that out. |
|
Tried reinstalling ffmpeg with --HEAD and seems like it works. |
|
I just ran into this very problem yesterday when I upgraded my docker stack to use Alpine 3.11, which packages FFmpeg 4.2.1. Glad you were able to dig into it; I had feared it was yet another ffmpeg bug that would have taken me ages to investigate. Was this reported upstream to the ffmpeg devs? FFmpeg 4.2.2 just released 13 days ago, I'll see if that release solves the 4.2.1 issue. The shortlog contained a lot of 'fixes'. |
|
I confirmed that the ffmpeg 4.2.2 release seems to have resolved the issue entirely; no I'd recommend anyone still having the issue to either downgrade to 4.1.4, or upgrade to 4.2.2. |
|
Good to know its no longer an issue in 4.2.2! |
|
I had issue with ffmpeg 4.2.2 (Homebrew/homebrew-core#48445), my gource is 0.51. I am switching to 2.8.15 now (seems working fine for me so far). |
|
Looks like I still suffer the |
|
I also get this with ffmpeg 4.2.2 (also tried git-2020-02-18-ebee808) & gource 0.51 OK forget this. Sorry. I had a corrupt .ppm due to resource issues on my machine. |
|
@SamMackrill Does it still run fine if FFmpeg is taken out of the loop? e.g. running just Gource. |
Thanks, it was Gource exiting early all along, sorry! |
|
@SamMackrill No problem. An alternative to saving ppm first and then feeding that into FFmpeg is to feed the PPM stream directly from stdout of Gource straight into FFmpeg with FFmpeg's |
|
Yes, the stable ffmpeg 4.2.2 fixes the issue |
|
ffmpeg 4.4 just gave me the same error while converting mka (dca) to ac3. I'll try downgrading to 4.2.2 and see what happens. |
catchingknives commented on Sep 28, 2019 •
Since version 0.5 ffmpeg comes back with the errors/warnings
Stream #0: not enough frames to estimate rate; consider increasing probesize(but increasing probesize doesn't help) and
Invalid data found when processing inputwhen using the command line
gource -1280x720 -o - | ffmpeg -y -r 60 -f image2pipe -vcodec ppm -i - -vcodec libx264 -preset ultrafast -pix_fmt yuv420p -crf 1 -threads 0 -bf 0 gource.mp4as used in this example. This also applies to WebM encoding and for the method where you first go via the raw (ppm) video. ffmpeg always fails at the same second mark in my input file so it seems there's something there which it doesn't like?