Opened 8 years ago

Closed 7 years ago

Last modified 5 years ago

#1823 closed enhancement (fixed)

Allow output file for -report option to be specified.

Reported by: dericed Owned by:
Priority: wish Component: ffmpeg
Version: git-master Keywords: report
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no


I find the -report option very useful and run a process that converts many incoming videos and stores the output of the -report option in case any later assessment is needed. Currently in order to file the report with the video I have to first find the report (either by searching the present working directory or grepping the ffmpeg output) and then move it to the place where I want to store it. There isn't really a way to predict what the output report filename will be until after the ffmpeg command has started.

I propose implementing an option to specify the filename or directory of the report.

Note: I realize that I could simply redirect and sdterr and sdtout to a file, but the output of the -report option additionally carries additional contextual data such as the exact command line and starting date which I'd like to store as well.

Change History (10)

comment:1 Changed 8 years ago by cehoyos

  • Priority changed from normal to wish
  • Status changed from new to open

comment:2 Changed 8 years ago by Cigaes

The -report option bypasses the normal option parsing in order to take effect immediately. That makes using an additional option rather clumsy.

Would it be ok to use the FFREPORT environment variable instead. Currently, it is only checked for existence? It could be checked for options:

export FFREPORT=file=/home/someone/log/ffmpeg-$(date +%Y%m%s).log

comment:3 Changed 8 years ago by dericed

Using the FFREPORT variable would work for me.

comment:4 Changed 8 years ago by Cigaes

It works now with the current git head: FFREPORT=file=/home/someone/log/%p-%t.log.
Please close the ticket if this is satisfying.

comment:5 Changed 8 years ago by michael

It doesnt work with : in the filename. So its practically unuseable on windows.

comment:6 Changed 8 years ago by Cigaes

"options values must be @ref{quoting_and_escaping, escaped} if they contain special characters or the options delimiter ':'"

Did you try quoting the file name? I do not have a windows box to test, but I can definitely get a report file with a : in its name on Linux.

comment:7 Changed 7 years ago by dericed

I've tested this in the latest git in a Mac environment and found it works well. I believe this ticket is closed by;a=commit;h=1fa47f8deafed3263ecdf5b0eb4807b77cfbb868.

comment:8 Changed 7 years ago by cehoyos

  • Resolution set to fixed
  • Status changed from open to closed

comment:9 Changed 7 years ago by DK

Yeah, guys I know it's a way to handle this but I'm running multiple FFMpegs in parallel (all the default codecs I tried are single-threaded) so I can utilise all my cores while rendering multiple videos. Since I'm starting them in arbitrary order picking from the job queue I don't want to have any issues with concurrency here, when one thread modifies env variable while another is reading it expecting previous value.

Is there a chance this can be added to the command line parameter? thanks!

comment:10 Changed 5 years ago by pcordes

Maybe try compiling ffmpeg under cygwin. Cygwin's support for Unix-style per-process environment variables doesn't interact with Windows env vars, other than importing them when a cygwin process starts.

Most of the major codecs are multithreaded ATM, including x264, x265, and I think VP9. Also utvideo, ffvhuff, and I think even the image2 PNG writer are parallelized. But sure, there are some things that aren't, esp. filters like a slow deinterlace.

Note: See TracTickets for help on using tickets.