Bug 358741 - git master: extract frame exports proxy clip frame instead of original clip frame
Summary: git master: extract frame exports proxy clip frame instead of original clip f...
Status: RESOLVED FIXED
Alias: None
Product: kdenlive
Classification: Applications
Component: Effects & Transitions (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Vincent PINON
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-01-29 16:00 UTC by Wegwerf
Modified: 2017-09-09 17:50 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Wegwerf 2016-01-29 16:00:08 UTC
When extracting a frame in the clip monitor from a clip with a proxy, Kdenlive exports the frame from the proxy. This results in low quality exported frames. Instead, Kdenlive should export the frame from the original clip but never from the proxy clip.

Reproducible: Always

Steps to Reproduce:
1. Add clip to project.
2. Create proxy for clip.
3. Export frame from this clip with proxy.
4. Check quality of exported frame.

Actual Results:  
Low-quality frame exported from proxy clip.

Expected Results:  
Original quality frame exported from original clip.
Comment 1 Wegwerf 2016-07-07 18:07:30 UTC
Still present...
Comment 2 Wegwerf 2016-09-18 16:02:29 UTC
This is still present with recent git master. I've tested using an .mp4 clip and exported once with proxy enabled and once without proxy. The resulting images are clearly different, with the proxy'd one being rather blurred.
Comment 3 Wegwerf 2016-09-18 16:23:41 UTC
Seems that the bug is in line 989 of manager.cpp: the "resource" property seems to always point to the proxy resource. Is it the property "kdenlive:originalurl" that you intended to use instead?
Comment 4 Wegwerf 2016-09-18 19:35:35 UTC
Fixed.
Comment 5 alberto 2017-09-09 17:50:22 UTC
I just complied master which contains 61cf7cdf3 that supposedly fix this, but It doesnt

Reopening in #384538