[kdenlive] [Bug 414815] Automatic creating profile upon clip addition crashes the app

2019-12-09 Thread Ilia Lilov
https://bugs.kde.org/show_bug.cgi?id=414815

--- Comment #2 from Ilia Lilov  ---
I just tried Kdenlive 20.03.70 appimage from here:
https://binary-factory.kde.org/job/Kdenlive_Nightly_Appimage_Build/lastSuccessfulBuild/artifact/
No crash happens on the same video file now.

My clip has variable framerate, so framerate number shown by different software
varies slightly depending on algorithm used by the software. 29.303FPS is my
smartphone's answer on my "30FPS, please" request. If I understand correctly,
the most part of smartphones nowadays film variable framerate only. I will have
to compose a video from 2 smartphones and 1 normal fixed-FPS camera footages in
few days, so I'll test how Kdenlive will be able to handle that.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdenlive] [Bug 415371] Applying LUT to SMPTE 170M colorspace videos is incorrect

2019-12-19 Thread Ilia Lilov
https://bugs.kde.org/show_bug.cgi?id=415371

--- Comment #3 from Ilia Lilov  ---
Created attachment 124599
  --> https://bugs.kde.org/attachment.cgi?id=124599=edit
Frame from the video after nochange.cube applied

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdenlive] [Bug 415371] Applying LUT to SMPTE 170M colorspace videos is incorrect

2019-12-19 Thread Ilia Lilov
https://bugs.kde.org/show_bug.cgi?id=415371

--- Comment #2 from Ilia Lilov  ---
Created attachment 124597
  --> https://bugs.kde.org/attachment.cgi?id=124597=edit
Original frame from the video

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdenlive] [Bug 415371] Applying LUT to SMPTE 170M colorspace videos is incorrect

2019-12-19 Thread Ilia Lilov
https://bugs.kde.org/show_bug.cgi?id=415371

Ilia Lilov  changed:

   What|Removed |Added

 CC||lilo...@gmail.com

--- Comment #1 from Ilia Lilov  ---
Created attachment 124595
  --> https://bugs.kde.org/attachment.cgi?id=124595=edit
3dlut which performs no changes on source image

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdenlive] [Bug 415373] Apply LUT effect does not report on invalid LUT files

2019-12-19 Thread Ilia Lilov
https://bugs.kde.org/show_bug.cgi?id=415373

Ilia Lilov  changed:

   What|Removed |Added

 CC||lilo...@gmail.com

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdenlive] [Bug 415373] New: Apply LUT effect does not report on invalid LUT files

2019-12-19 Thread Ilia Lilov
https://bugs.kde.org/show_bug.cgi?id=415373

Bug ID: 415373
   Summary: Apply LUT effect does not report on invalid LUT files
   Product: kdenlive
   Version: git-master
  Platform: Debian stable
OS: Linux
Status: REPORTED
  Severity: minor
  Priority: NOR
 Component: User Interface
  Assignee: j...@kdenlive.org
  Reporter: lilo...@gmail.com
  Target Milestone: ---

Version of Kdenlive where bug is present (downloaded as Nightly AppImage):
20.03.70-539f6b3 (it's not present in versions list for reporting, so I chosen
"git-master" as the closest). The bug appeared at least as early as in 19.04.2.

To reproduce (100% repeatability):
- Create a project with any builtin profile.
- Open any clip and add it to a track.
- Add "Apply LUT" effect to the clip.
- For "LUT file to apply" field, browse and select a file named *.cube or *.3dl
containing any random bytes, i.e. which is not valid 3dlut file. No warning
will appear.

This silent behavior may be very painful while regularly working with 3D LUTs
which introduce very fine, i.e. almost not visible changes, so there is no easy
way to be sure that the LUT is applied.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdenlive] [Bug 415374] New: Apply LUT effect fails on grid resolution 65 and above

2019-12-19 Thread Ilia Lilov
https://bugs.kde.org/show_bug.cgi?id=415374

Bug ID: 415374
   Summary: Apply LUT effect fails on grid resolution 65 and above
   Product: kdenlive
   Version: git-master
  Platform: unspecified
OS: Linux
Status: REPORTED
  Severity: minor
  Priority: NOR
 Component: User Interface
  Assignee: j...@kdenlive.org
  Reporter: lilo...@gmail.com
  Target Milestone: ---

Version of Kdenlive where bug is present (downloaded as Nightly AppImage):
20.03.70-539f6b3 (it's not present in versions list for reporting, so I chosen
"git-master" as the closest). The bug appeared at least as early as in 19.04.2.

To reproduce (100% repeatability):
- Get .cube 3D LUT file with grid resolution 65 (see below on how to).
- Create a project with any builtin profile.
- Open any clip and add it to a track.
- Add "Apply LUT" effect to the clip.
- For "LUT file to apply" field, browse and select the .cube file. The LUT will
not be applied.

Grid resolution 64 and below work fine.
Note that .cube file standard defines maximum grid resolution of 256. (
https://wwwimages2.adobe.com/content/dam/acom/en/products/speedgrade/cc/pdfs/cube-lut-specification-1.0.pdf
)
To quickly get .cube file to test, install Argyll CMS and run (the path may
differ on your platform):
cd /usr/share/color/argyll/ref
collink -ia -3c -r 65 ProPhoto.icm sRGB.icm test.cube
Default (without "-r" key) and recommended resolution by Argyll is 65.

The bug is additionally complicated to realize due to bug 415373.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdenlive] [Bug 415374] Apply LUT effect fails on grid resolution 65 and above

2019-12-19 Thread Ilia Lilov
https://bugs.kde.org/show_bug.cgi?id=415374

Ilia Lilov  changed:

   What|Removed |Added

   See Also||https://bugs.kde.org/show_b
   ||ug.cgi?id=415373
 CC||lilo...@gmail.com

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdenlive] [Bug 415373] Apply LUT effect does not report on invalid LUT files

2019-12-19 Thread Ilia Lilov
https://bugs.kde.org/show_bug.cgi?id=415373

Ilia Lilov  changed:

   What|Removed |Added

   See Also||https://bugs.kde.org/show_b
   ||ug.cgi?id=415374

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdenlive] [Bug 415371] New: Applying LUT to SMPTE 170M colorspace videos is incorrect

2019-12-19 Thread Ilia Lilov
https://bugs.kde.org/show_bug.cgi?id=415371

Bug ID: 415371
   Summary: Applying LUT to SMPTE 170M colorspace videos is
incorrect
   Product: kdenlive
   Version: git-master
  Platform: Debian stable
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: Video Display & Export
  Assignee: j...@kdenlive.org
  Reporter: lilo...@gmail.com
  Target Milestone: ---

Created attachment 124594
  --> https://bugs.kde.org/attachment.cgi?id=124594=edit
SMPTE 170M colorspace video

Version of Kdenlive where bug is present (downloaded as Nightly AppImage):
20.03.70-539f6b3 (it's not present in versions list for reporting, so I chosen
"git-master" as the closest). The bug appeared at least as early as in 19.04.2.

To reproduce (100% repeatability):
- Create a project with any builtin profile.
- Add attached video file "smpte170m_sample.mp4" as clip to the project. Answer
to "Create and switch to new profile?" message doesn't matter.
- Move the clip to video track. Activate Timeline->"Fit zoom to project" to
ensure the clip is added (the video contains single frame, so it is difficult
to navigate to it manually).
- Add "Apply LUT" effect to the clip.
- For "LUT file to apply" field, browse and select attached file
"nochange.cube". Frame image in monitor will show that brightness and contrast
are changed, which is incorrect behavior, because nochange.cube represents
trivial handmade 3dlut which introduces absolutely no modifications to the
image. Rendering video produces the same wrong frame images as monitor does.

As a proof, you could perform the same actions on any BT.709 colorspace (the
most popular one for AVC) video file, and ensure applying nochange.cube
introduces no changes to the image.

I've attached two scaled down *.png files to quickly demonstrate the problem.

Video file is from my smartphone of quite popular model, so SMPTE 170M
colorspace (sometimes referred as BT.601 colorspace) doesn't seem to be too
rare to ignore. Anyway, it is defined as allowed for AVC.
ffmpeg video stream summary of the video (attention to "yuvj420p(pc,
smpte170m)"):
Metadata:
  major_brand : isom
  minor_version   : 512
  compatible_brands: isomiso2avc1mp41
  encoder : Lavf58.20.100
Duration: 00:00:00.04, start: 0.00, bitrate: 42597 kb/s
  Stream #0:0(und): Video: h264 (Baseline) (avc1 / 0x31637661), yuvj420p(pc,
smpte170m), 1920x1080, 42495 kb/s, SAR 1:1 DAR 16:9, 24.42 fps, 24.42 tbr,
24422 tbn, 48844 tbc (default)


Aside from bug reporting, I can suggest quick and dirty solution for ones who
have the same task as I do. My task is to shoot color calibration target on my
camera, create camera ICC profile, and produce .cube file which would convert
image from my camera colorspace to sRGB colorspace, i.e. fixing camera color
distortion. I use Argyll CMS and all the steps described well at
https://argyllcms.com/doc/Scenarios.html#PS1 (using collink with "-3c" key to
produce .cube file after that), so I was able to perform everything except I
noted the bug under question. The single additional step is needed to evade the
bug: open the footage with color target in kdenlive, apply nochange.cube I've
attached, render video, extract desired frame, and use it for "scanin" program
instead of original footage frame. So, resulting .cube file will fix both
camera color distortion and kdenlive LUT applying color distortion.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdenlive] [Bug 414813] Wrong leading thumbnail when clip and project profiles differ

2019-12-03 Thread Ilia Lilov
https://bugs.kde.org/show_bug.cgi?id=414813

Ilia Lilov  changed:

   What|Removed |Added

 CC||lilo...@gmail.com

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdenlive] [Bug 414814] New: New rendering format parameters not checked at creation

2019-12-03 Thread Ilia Lilov
https://bugs.kde.org/show_bug.cgi?id=414814

Bug ID: 414814
   Summary: New rendering format parameters not checked at
creation
   Product: kdenlive
   Version: git-master
  Platform: Debian stable
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: User Interface
  Assignee: j...@kdenlive.org
  Reporter: lilo...@gmail.com
  Target Milestone: ---

Version of Kdenlive where bug is still present: 19.11.80 (it's not present in
versions list for reporting, so I chosen "git-master" as the closest). The bug
appeared as early as 19.04.2 at least.

To reproduce (100% repeatability):
- Open "Project" -> "Render" menu.
- Select "MP4 - the dominant format" format (doubtfully that is mandatory
step).
- Press "Create new profile" button.
- Enter any Profile name (let's say "test"), in "Parameters" field change
"acodec" parameter value to something mistaken, let's say "acodec = bbc".
- Press OK.
- Newly created format will be shown in the list with a star but without red
highlighting due to erroneous parameters.

Upon some actions later (for example, upon changing project profile and saving
the project), the format will be reevaluated, so "Rendering" window finally
will have the format marked as erroneous by red highlighting.

Actually, there are two bugs which implicitly report the same problem: 384148
and 411261. I would not like to create duplication, but considering how titles
of both are formulated, I believe the essence of the problem will continue to
be slipped away until explicitly titled bug report would appear.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdenlive] [Bug 411261] Rendering dialog does not recognize "f=mkv" render output format on initial load

2019-12-03 Thread Ilia Lilov
https://bugs.kde.org/show_bug.cgi?id=411261

Ilia Lilov  changed:

   What|Removed |Added

   See Also||https://bugs.kde.org/show_b
   ||ug.cgi?id=414814

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdenlive] [Bug 384148] rendering window reports "mkv" as unsupported

2019-12-03 Thread Ilia Lilov
https://bugs.kde.org/show_bug.cgi?id=384148

Ilia Lilov  changed:

   What|Removed |Added

   See Also||https://bugs.kde.org/show_b
   ||ug.cgi?id=414814

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdenlive] [Bug 395056] Video thumbnails in timeline display incorrect frames when using speed effect (or when clip's fps different from project's fps)

2019-12-03 Thread Ilia Lilov
https://bugs.kde.org/show_bug.cgi?id=395056

Ilia Lilov  changed:

   What|Removed |Added

   See Also||https://bugs.kde.org/show_b
   ||ug.cgi?id=414813

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdenlive] [Bug 414813] New: Wrong leading thumbnail when clip and project profiles differ

2019-12-03 Thread Ilia Lilov
https://bugs.kde.org/show_bug.cgi?id=414813

Bug ID: 414813
   Summary: Wrong leading thumbnail when clip and project profiles
differ
   Product: kdenlive
   Version: git-master
  Platform: Debian stable
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: User Interface
  Assignee: j...@kdenlive.org
  Reporter: lilo...@gmail.com
  Target Milestone: ---

Version of Kdenlive where bug is present: 19.11.80 (it's not present in
versions list for reporting, so I chosen "git-master" as the closest). The bug
appeared not earlier than 19.04.2 at least.


To reproduce (100% repeatability):
- Run Kdenlive (mandatory; don't use already running process).
- "Project" -> "Add Clip or Folder", add any video file. Answer to "Switch to
clip profile...?" dialog does not matter.
- Drag and drop the clip to any video track on timeline.
- Move the clip at leftmost position of the track on timeline (proven to be
mandatory step).
- "File" -> "New", choose any profile, saving project or not does not matter.
- "Project" -> "Add Clip or Folder", add any other video file, file profile
must not match project profile. Ignore "Switch to clip profile...?" dialog or
answer "Cancel".
- Drag and drop the clip to any video track. Leading video thumbnail of the
clip will be from the first clip, not from the second as expected.


In my case, differences between project profile and clip profile are the
following:

Project:
Frame size: 1920 x 1080 (16:9)
Frame rate: 25 fps
Pixel Aspect Ratio: 1
Color Space: ITU-R 709
Interlaced: no

Clip:
Frame size: 1920 x 1080 (1920:1080)
Frame rate: 25 fps
Pixel Aspect Ratio: 1
Color Space: ITU-R 601
Interlaced: no

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdenlive] [Bug 414814] New rendering format parameters not checked at creation

2019-12-03 Thread Ilia Lilov
https://bugs.kde.org/show_bug.cgi?id=414814

Ilia Lilov  changed:

   What|Removed |Added

 CC||lilo...@gmail.com

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdenlive] [Bug 414815] New: Automatic creating profile upon clip addition crashes the app

2019-12-03 Thread Ilia Lilov
https://bugs.kde.org/show_bug.cgi?id=414815

Bug ID: 414815
   Summary: Automatic creating profile upon clip addition crashes
the app
   Product: kdenlive
   Version: git-master
  Platform: Debian stable
OS: Linux
Status: REPORTED
  Severity: crash
  Priority: NOR
 Component: User Interface
  Assignee: j...@kdenlive.org
  Reporter: lilo...@gmail.com
  Target Milestone: ---

Created attachment 124303
  --> https://bugs.kde.org/attachment.cgi?id=124303=edit
Video causing kdenlive crash

Version of Kdenlive where bug is present (downloaded as Beta AppImage):
19.11.80 (it's not present in versions list for reporting, so I chosen
"git-master" as the closest). The bug appeared not earlier than 19.04.2 at
least.

To reproduce (100% repeatability):
- Create a project with "HD 1080p 25 fps" builtin profile.
- Add attached video file as clip to the project. Warning message will appear:
"No profile found for your clip. Create and switch to new profile (1920x1080,
29.00fps)?".
- Press "Continue" button on the message (mandatory step; "Cancel" would not
allow to reproduce).
- First frame of the video will be shown in Project Monitor for less than a
second, and the app crashes after that.


Application output during the crash:

### ProjectClip::setproducer
### ClipController::updateProducer
### ClipController::addmasterproducer
QPoint(0,1)
MUTEX LOCK setmodel
MUTEX UNLOCK setmodel
MUTEX LOCK loadEffects: 
/// GOT AUDIO TRACKS:  (2)
qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 2251, resource
id: 11608789, major code: 40 (TranslateCoords), minor code: 0
### JOB finished 1
QLibraryPrivate::unload succeeded on
"/tmp/.mount_kdenlijMmsSG/usr/plugins/kf5/kio/file.so" (faked)
/tmp/.mount_kdenlijMmsSG/AppRun: line 26:  5741 Segmentation fault 
 kdenlive --config kdenlive-appimagerc $@

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdenlive] [Bug 414815] Automatic creating profile upon clip addition crashes the app

2019-12-03 Thread Ilia Lilov
https://bugs.kde.org/show_bug.cgi?id=414815

Ilia Lilov  changed:

   What|Removed |Added

 CC||lilo...@gmail.com

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdenlive] [Bug 414814] New rendering format parameters not checked at creation

2021-04-24 Thread Ilia Lilov
https://bugs.kde.org/show_bug.cgi?id=414814

--- Comment #5 from Ilia Lilov  ---
I just checked in the latest nightly build (21.07.70-3ea8bbc), the bug is still
reproducible exactly by the steps in initial bug report.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdenlive] [Bug 415374] Apply LUT effect fails on grid resolution 65 and above

2021-04-24 Thread Ilia Lilov
https://bugs.kde.org/show_bug.cgi?id=415374

--- Comment #2 from Ilia Lilov  ---
I just checked in the latest nightly build (21.07.70-3ea8bbc), the bug in not
reproducible anymore, i.e. LUT with resolution 65 and above can be successfully
applied.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdenlive] [Bug 414815] Automatic creating profile upon clip addition crashes the app

2021-03-06 Thread Ilia Lilov
https://bugs.kde.org/show_bug.cgi?id=414815

Ilia Lilov  changed:

   What|Removed |Added

 Status|NEEDSINFO   |RESOLVED
 Resolution|WAITINGFORINFO  |FIXED

--- Comment #4 from Ilia Lilov  ---
I've tested on 20.12.2 just now, the bug is not reproducible anymore.

-- 
You are receiving this mail because:
You are watching all bug changes.