Bug 436725 - 5.0.0-prealpha does not produce a log_encode.log file
Summary: 5.0.0-prealpha does not produce a log_encode.log file
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Applications
Component: Animation (show other bugs)
Version: nightly build (please specify the git hash!)
Platform: Debian stable Linux
: NOR normal
Target Milestone: ---
Assignee: Eoin O'Neill
URL:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2021-05-07 11:19 UTC by Ahab Greybeard
Modified: 2021-05-13 04:03 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ahab Greybeard 2021-05-07 11:19:45 UTC
SUMMARY
The May 06 5.0.0-prealpha (git cb99b9e) appimage does not produce an encode log output file for .gif or .mp4 output rendering. (These were the only two output formats tested.)

The 4.4.0-alpha and the 4.4.3 appimages do produce log outputs.

STEPS TO REPRODUCE
1. Create/obtain an animated .kra file and render it to a destination folder.
2. Examine the contents of the destination folder.

OBSERVED RESULT
2. The rendered video output file is correctly present but there is no encode log file.

EXPECTED RESULT
2. There should be an encode log file.


SOFTWARE/OS VERSIONS
Krita

 Version: 5.0.0-prealpha (git cb99b9e)
 Languages: en_GB, en, en, en_GB, en
 Hidpi: false

Qt

  Version (compiled): 5.12.9
  Version (loaded): 5.12.9

OS Information

  Build ABI: x86_64-little_endian-lp64
  Build CPU: x86_64
  CPU: x86_64
  Kernel Type: linux
  Kernel Version: 4.19.0-16-amd64
  Pretty Productname: Debian GNU/Linux 10 (buster)
  Product Type: debian
  Product Version: 10
  Desktop: MATE

OpenGL Info
 
  Vendor:  "NVIDIA Corporation" 
  Renderer:  "GeForce GTX 750 Ti/PCIe/SSE2" 
  Version:  "4.6.0 NVIDIA 460.67" 
  Shading language:  "4.60 NVIDIA" 
  Requested format:  QSurfaceFormat(version 3.0, options QFlags<QSurfaceFormat::FormatOption>(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile  QSurfaceFormat::CompatibilityProfile) 
  Current format:    QSurfaceFormat(version 4.6, options QFlags<QSurfaceFormat::FormatOption>(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile  QSurfaceFormat::CompatibilityProfile) 
     Version: 4.6
     Supports deprecated functions true 
     is OpenGL ES: false 

QPA OpenGL Detection Info 
  supportsDesktopGL: true 
  supportsOpenGLES: true 
  isQtPreferOpenGLES: false 

Hardware Information

  GPU Acceleration: auto
  Memory: 16039 Mb
  Number of Cores: 8
  Swap Location: /tmp
Comment 1 wolthera 2021-05-07 11:23:39 UTC
I think we actually moved that to the %temp% folder recently :D
Comment 2 wolthera 2021-05-07 11:31:14 UTC
Hm... no, it may have accidentally been refactored away, gonna assign emmet and eoin.
Comment 3 Ahab Greybeard 2021-05-07 11:41:48 UTC
I hope it hasn't been decided to put it in the %temp% folder because it can contain valuable information when users have problems with rendering an animation.
As such, it's important that they can find it easily and provide it for analysis.
Comment 4 Eoin O'Neill 2021-05-12 00:21:19 UTC
Hey Ahab Greybeard,

This change has to do with the unification of multiple FFMPEG wrappers. We currently have a discussion around the FFMPEG wrapper and it's future on phabricator ( https://phabricator.kde.org/T14331 ) which encompasses some of the discussion around using the temp folder, what to do with temporary files, and more.

Currently, the plan is to always store the log file in the system temporary folder and to only move (really, copy) the log file into the destination folder (where the video file was going to save) if we determine that FFMPEG ran into an error, which the new C++ wrapper is better at determining. Before, the log file was always saved into the target directory regardless of success or failure, which created a lot of garbage and unused data for the artists IMO. Additionally, with the increased scope of parts that use FFMPEG within Krita, it would be nice to have a unified place for us to ask users to check if they want to know how ffmpeg ran for their given task. 

With that in mind, we're still in the planning and discussion phase, with more changes planned beyond 5.0's release. Please, if you have any specific requests regarding animation / ffmpeg / log file production, please give us your thoughts on the phabricator page so that we can have a single place to track discussion around this topic. Additionally, since KnowZero has also been helping with FFMPEG features and frontend changes, it will also help him to see artist and user feedback on some of the more recent changes to the FFMPEG wrapper as well.

I'm going to leave this open and assigned. For 5.0's immediate release, I will at least make sure that FFMPEG will reliably place error files where videos were supposed to go when errors occur and triple check that all of the FFMPEG operations produce a log file in the temp folder as they should.
Comment 5 Eoin O'Neill 2021-05-13 04:03:40 UTC
Git commit ad1d00edb61fad9ac864e45318291789ec6f5e5c by Eoin O'Neill.
Committed on 13/05/2021 at 04:00.
Pushed by eoinoneill into branch 'master'.

Reinstate FFMPEG logging in a way that respects new FFMPEG design and usage across various Krita systems.

Logs are always rendered in a temp directory. When an error occurs, the log will be copied to the
desired video output directory.

M  +1    -0    libs/ui/animation/KisDlgImportVideoAnimation.cpp
M  +36   -4    libs/ui/animation/KisFFMpegWrapper.cpp
M  +3    -2    libs/ui/animation/KisVideoSaver.cpp

https://invent.kde.org/graphics/krita/commit/ad1d00edb61fad9ac864e45318291789ec6f5e5c