| Summary: | "Save" -> "Open" a specific project results in a corrupted project | ||
|---|---|---|---|
| Product: | [Applications] kdenlive | Reporter: | Uwe Dippel <udippel> |
| Component: | Timeline & Editing | Assignee: | Jean-Baptiste Mardelle <jb> |
| Status: | REPORTED --- | ||
| Severity: | normal | ||
| Priority: | NOR | ||
| Version First Reported In: | 25.08.0 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: |
diff -u of .kdenlive-s
Shows the 'white' result - and the remnants of the previous project |
||
*** Bug 508759 has been marked as a duplicate of this bug. *** Created attachment 184705 [details]
diff -u of .kdenlive-s
diff -u of .kdenlive that works (no cut) and the one not loading correctly (after one cut)
Created attachment 184777 [details]
Shows the 'white' result - and the remnants of the previous project
Sorry, if this gets lengthy. I didn't edit it in any way. There are some longer times of seemingly inactivity, but that's only during the the selection of files, saving of the project, and so forth. I excluded these for privacy reasons.
I started with a new project, loaded France.ts, removed one audio track, dragged it to the timeline, made a single cut, removed the space, saved the project as France_demo, created a new project, loaded the existing France_demo. Result: all video pops out as white.
The source file is France.ts; the project file France_demo.kdenlive.
Unfortunately, a second candidate. So I think, this needs some evaluation after all. The attachment is an unedited screencast showing the complete creation and editing action on a source file; and its failure to load a simple, previously created project. The details are commented with the attachment. This second one behaves identical to the first one w.r.t. a workaround: Dragging the .ts to the timeline, including (in my case) disabling audio tracks and switching them around, followed by rendering the tracks to .mp4 (respectively .ac3) works flawlessly. Loading these results for a second time, edits on timings of the .mp4 (and .ac3) can be done successfully. I had the time to try these files with the most recent appImage of kdenlive. The behaviour is identically wrong. The very first action on timing results in a white video track at rendering respectively Save->Load (Kdenlive Version 25.08.1) I don't know if this helps, I do hope so! ffmpeg -ignore_unknown -i Anaheim.ts -ss 0 -t 60 -map 0 -c copy Try_out_white_1.ts (Anaheim.ts has a length of 01:48:28.62 according to ffmpeg) This one is fine, can be edited, saved, loaded. (I thought that I had a workaround, but:) ffmpeg -ignore_unknown -i Anaheim.ts -ss 0 -t 22:22:22 -map 0 -c copy Try_out_white_all.ts once again fails as before. So it looks like the end is the problem? Let's try: ffmpeg -ignore_unknown -i Anaheim.ts -ss 0 -to 01:46:00 -map 0 -c copy Try_out_white_no_end.ts YES! This works. Audio is very much out of sync, though. I'm not an expert on this, but it looks strange: you can set a cut point at second 23 in a clip of close to two hours, and it fails. You cut off the last few minutes of that clip, and the cut at second 23 works. Confirmed for 25.12.0, too. After some 20 clean clips, yet another one with this behaviour; always the same source: public broadcast (cable), with tvheadend. As can be seen from above, I wasn't able to cut the original file(s) down to one handled easily, and still show the original flaw. The two files that I still have, and expose this behaviour, are close to 10 GB. In case anybody was interested to act on this bug, I could upload either to some resource. Making either publicly available would be suboptimal due to copyright reasons, both are recordings from broadcasts of copyrighted movie material. (I know, it's a one-man-show, but I keep reporting, hoping for a solution ...) Due to the festive season, I had time to edit and render more clips. Yesterday I hit one that shows the white video track from the moment of dropping it into the time line, while it was perfectly okay in the clip monitor. Earlier someone had asked about encoding problems. Well, I could always file a bug report with tvheadend; but I'm afraid then we'll run in circles. I do believe now that the problem lies in dragging the file from the project bin into the time line. With this most recent clip, I can drag it into the time line successfully, as long as I don't place it at the beginning of the time line. But that doesn't help, because placing it a few seconds to the right already brings audio (despite of remaining 'grouped') out of sync by seconds. On request, I can make another screen recording; though I think it rather needs the original data to see where the routine breaks down at handling specific data sequences in multimedia signals. I found another work around within kdenlive: Using Clip Monitor, set a zone, extract it to the bin. Then it can be parsed into the time line splendidly. Still, the encoding of the source might be flawed. Though, wouldn't this pop up in tvheadend bug reports? Also, VLC, dragon and kdenlive's own Clip Monitor find no problem. |
SUMMARY (This is a hopefully less misconstrued continuation of #508759) It happens with some source file that it cannot be loaded into the timeline to be edited, subsequently "Save"d in order to be reloaded successful ("Open") again. STEPS TO REPRODUCE 1. Start new project (1 video, 1 audio) 2. Load a specific .ts file (1 video stream, 3 audio streams) 3. Remove ("Clip Properties") all but the first audio stream 4. Drag this file from the bin to the timeline 5. Observe that "Save"->"Load" works 6. "Cut Clip" at a point of choice in the timeline OBSERVED RESULT 7. Observe that "Save"->"Load" does not work any longer: "Project Monitor" shows the complete video track as all white; however, "Clip Monitor" still works, and so does audio in the Project Monitor ("Play") 8. Rendering fails, results in a completely white video, with audio working (in some of my many instances kdenlive crashed, but I have nothing tangible on this. For the time being, I assume that the problem focuses on the impossibility to Re-"Load" this project, ever, once a single "Cut Clip" has been issued in the timeline. EXPECTED RESULT "Load" returns the last, saved, state of the project // Rendering it is possible SOFTWARE/OS VERSIONS fedora 42 ubuntu 24.04 kdenlive 25.08.0 kdenlive 23.08.5 ADDITIONAL INFORMATION The file is an over-the-air recording, with some recording artifacts. It plays properly in vlc, and in "Clip Monitor" as well as "Project Monitor" as long as no edits have been done in the timeline. ffmpeg -i Anaheim.ts -ss 00:06:29 -t 01:48:20 -c:v copy -c:a copy Anaheim.mp4 works, and results in a playable file, of course including video (00:06:29 is the identical edit point of the single cut in kdenlive, see above) Since this is just a rearrangement, I also tried to re-encode: ffmpeg -i Anaheim.ts -ss 00:06:29 -t 01:48:20 -c:v libx264 -c:a aac Anaheim.mp4 This also goes through. The source file is this one: 8185155092 Aug 25 22:58 Anaheim.ts mediainfo provides: General ID : 1 (0x1) Complete name : Anaheim.ts Format : MPEG-TS File size : 7.62 GiB Duration : 1 h 48 min Overall bit rate mode : Variable Overall bit rate : 10.1 Mb/s Frame rate : 50.000 FPS Video ID : 5201 (0x1451) Menu ID : 1 (0x1) Format : AVC Format/Info : Advanced Video Codec Format profile : High@L4 Format settings : CABAC / 4 Ref Frames Format settings, CABAC : Yes Format settings, Reference frames : 4 frames Format settings, GOP : M=8, N=48 Codec ID : 27 Duration : 1 h 48 min Bit rate : 8 724 kb/s Width : 1 280 pixels Height : 720 pixels Display aspect ratio : 16:9 Frame rate : 50.000 FPS Standard : Component Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits Scan type : Progressive Bits/(Pixel*Frame) : 0.189 Stream size : 6.61 GiB (87%) Color range : Limited Color primaries : BT.709 Transfer characteristics : BT.709 Matrix coefficients : BT.709 Audio #1 ID : 5202 (0x1452) Menu ID : 1 (0x1) Format : AC-3 Format/Info : Audio Coding 3 Commercial name : Dolby Digital Codec ID : 6 Duration : 1 h 48 min Bit rate mode : Constant Bit rate : 448 kb/s Channel(s) : 2 channels Channel layout : L R Sampling rate : 48.0 kHz Frame rate : 31.250 FPS (1536 SPF) Compression mode : Lossy Delay relative to video : -612 ms Stream size : 348 MiB (4%) Service kind : Complete Main Dialog Normalization : -23 dB compr : -0.56 dB dynrng : -0.71 dB dsurmod : Not Dolby Surround encoded mixlevel : 105 dB ltrtcmixlev : -3.0 dB ltrtsurmixlev : -4.5 dB lorocmixlev : -3.0 dB lorosurmixlev : -4.5 dB dialnorm_Average : -23 dB dialnorm_Minimum : -23 dB dialnorm_Maximum : -23 dB Audio #2 ID : 5203 (0x1453) Menu ID : 1 (0x1) Format : AC-3 Format/Info : Audio Coding 3 [and so on ...]