| Summary: | Spews copious amounts of output even at warning level | ||
|---|---|---|---|
| Product: | Fedora EPEL | Reporter: | Brian J. Murrell <brian> |
| Component: | ffmpeg | Assignee: | leigh scott <leigh123linux> |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | ||
| Priority: | P1 | ||
| Version: | 7 | ||
| Hardware: | x86_64 | ||
| OS: | GNU/Linux | ||
| namespace: | |||
|
Description
Brian J. Murrell
2021-03-02 16:17:47 CET
The link is 403 already. It would be better for you to report the issue to ffmpeg bugzilla. FTR I don't use RHEL7, this means I can't offer any support. (In reply to leigh scott from comment #1) > The link is 403 already. Could be geoblocked. I guess you will just have to take my word for it. > It would be better for you to report the issue to ffmpeg bugzilla. To which they will immediately reply to try a newer version. But I can already tell you that Fedora's ffmpeg-4.3.1-16.fc33.x86_64 does not have this problem. Only EPEL7's ffmpeg-3.4.8-1.el7.x86_64 has it and I would be entirely surprised if upstream doesn't suggestion upgrading to 4.x and closing the ticket. El7 is too old for a major ffmpeg update and rebuild of all dependant packages. (In reply to leigh scott from comment #4) > El7 is too old for a major ffmpeg update and rebuild of all dependant > packages. Don't disagree, but EL7 is still within supported windows and having a bug like this that fills up filesystems with GBs of stdout is pretty nasty. With the recent RH shenanigans with CentOS, EL8 does not have a stable upgrade/support path so upgrading to it is fraught with uncertainty at this point and as a result staying on EL7 is the only sane thing to do right now. This turns out to have been "something" (unknown as of now and not really that interested in trying to figure out where from) was sending the ffmpeg process an "h" on it's stdin while it was operating (in a script, from a cron job). Simply adding a </dev/null to the ffmpeg invocation seems to have resolved that. |