Bug 353455 - Unable to export image sequence due to wrong symbol interpretation
Summary: Unable to export image sequence due to wrong symbol interpretation
Status: RESOLVED FIXED
Alias: None
Product: kdenlive
Classification: Applications
Component: Rendering & Export (show other bugs)
Version: unspecified
Platform: Arch Linux Linux
: NOR major
Target Milestone: ---
Assignee: Jean-Baptiste Mardelle
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-10-02 15:09 UTC by Laptander
Modified: 2015-12-14 21:47 UTC (History)
1 user (show)

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


Attachments
Screenshot while rendering images sequence (18.61 KB, image/png)
2015-10-02 15:15 UTC, Laptander
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Laptander 2015-10-02 15:09:01 UTC
It is not possible to export project to image sequences. After you try to do this, kdenlive will render not image sequences, but export to a single file, which name contains wrongly interpreted symbol.

Reproducible: Always

Steps to Reproduce:
1. Create a new kdenlive project
2. Add whatever clip to project, for example, just an image
3. Place that clip to timeline
4. Open rendering project menu
5. Select "Images sequence" as output format
6. Choose file name, for example, "untitled.png" (png or jpg does not matter)
7. Click Render to File button.

Actual Results:  
Rendering is going wrongly. Instead of image sequences, it renders to a single file with name untitled_<strange symbol here>d.png (see attached screenshot).

Expected Results:  
There should be many images, called untitled_00001.png, untitled_00002.png and so on.

You can watch rendering script by clicking Generate Script button. I tryed to replace "untitled_%05d.png" with "untitled_%2cd.png" in that script and resulting filename became "untitled_,d.png" (0x2c is a comma symbol in ascii). So, apparently, this is happening because of incorrect interpretion of "%05d" while rendering. Instead of recognising "%05d" as a numerical place holder, it is recognised as a url-encoded symbol in file name. More info about what is "%05d" you can find here: https://en.wikibooks.org/wiki/FFMPEG_An_Intermediate_Guide/image_sequence#Making_an_Image_Sequence_from_a_video

I tryed installing previous versions of kdenlive, which could export image sequences correctly, but this time previous versions were not working for me too. So I think the problem is not kdenlive itself, but some other software. Maybe sh interpreter?

And another strange thing: while rendering frame, symbol in its name is displayed as carriage return (see attached screenshot), but actually in file system it is named with Enquiry symbol (0005 digits in rectangle). See these symbols for differences:
http://unicode-table.com/en/000D/ - Carriage Return
http://unicode-table.com/en/0005/ - Enquiry
Comment 1 Laptander 2015-10-02 15:15:42 UTC
Created attachment 94810 [details]
Screenshot while rendering images sequence

You can see, that frame which is rendering at the moment is not called "untitled_00001.png", but  "untitled_d.png"
Comment 2 Laptander 2015-10-10 12:56:27 UTC
I explored a source code a bit and possibly can suggest where is the error.
If you see at https://github.com/KDE/kdenlive/blob/master/renderer/kdenlive_render.cpp#L78, you can see
        QUrl desturl = QUrl::fromEncoded(args.takeFirst().toUtf8());
        QString dest = desturl.path();
Why argument string is encoded to utf8? Is'nt is already utf8? And why then it is again extracted a path? Why just not as any other arguments:
        QString dest = args.takeFirst();

Anyway, before line #112 there is debug output, and I can see in terminal window the following:
        //STARTED RENDERING: bla-bla-bla "/home/user/untitled_\u0005d.jpg" bla-bla-bla
"\u" is an escape sequence, that interpretes the folloving four characters as a number of unicode symbol. And I think here the problem has already happened. Does such file name should be outputed here?

Possibly relevant:
https://github.com/KDE/kdenlive/blob/master/src/project/dialogs/projectsettings.cpp#L575 - something about image sequences
https://github.com/KDE/kdenlive/blob/master/src/dialogs/renderwidget.cpp#L977 - adding "_%05d"
/src/renderer.h
/renderer/renderjob.cpp
/src/project/jobs/jobmanager.cpp
Comment 3 Laptander 2015-10-12 11:28:07 UTC
I have replaced 
        QUrl desturl = QUrl::fromEncoded(args.takeFirst().toUtf8());
        QString dest = desturl.path();
to
        QString dest = args.takeFirst();
compiled from sources and tnen I could export images sequences!
But I have noticed two things: 
1) while rendering, dialog window do not show currently rendering number of frame, but just a single job. I think at first line in rendering window there should be displayed sequence job and at the second it should display currently rendering frame.
2) In target folder along with exported frames (untitled_00001.jpg, ...), I can also find a corrupted file called untitled_%05d.jpg. Of cource I can delete it, but I think that should be fixed.

So, for this bug to be fixed make described above changes in source code.
As I already said, I cannot understand, why we first make QUrl from QString? We should not decode that "%05", right? And then from that QUrl we make QString with path() method. What is the silly reason?
By the way, if that convertation is really needed for some reason,  it is wrong anyway. At line #77 we have QUrl::fromEncoded(args.takeFirst().toUtf8()), but according to http://doc.qt.io/qt-5/qurl.html#fromEncoded, this constructor expects ASCII only characters, but utf8 could contain non ascii characters.

This bug is happening due to path() http://doc.qt.io/qt-5/qurl.html#path at line #78 https://github.com/KDE/kdenlive/blob/master/renderer/kdenlive_render.cpp#L78
Maybe we need to give it another (which?) formatting option? Default is FullyDecoded, which is not our case. http://doc.qt.io/qt-5/qurl.html#ComponentFormattingOption-enum
Comment 4 Jean-Baptiste Mardelle 2015-11-16 20:00:49 UTC
Hello, 
Thanks for investigating this issue. Problem should be fixed by my last commit in branch 15.12 (that will be released as Kdenlive 15.12 in december):
https://quickgit.kde.org/?p=kdenlive.git&a=commit&h=4186cc41deacb52ca61ffe99d2b20472464ec4fe

Testing welcome.
Comment 5 Laptander 2015-11-20 17:42:13 UTC
Hello, Jean-Baptiste Mardelle. Thank you for your work.
I have just compiled and installed a new version kdenlive 15.11.80 from commit c7edc15
Behavior with rendering images sequenses is the same (except I have noticed new rendering profiles) as I described above: 1) while rendering, it is only displayed the whole job name, but not frame number. Maybe it is meant to be so. 2) Still appears corrupted file which is named untitled_%05d.png. That should be removed.
Comment 6 Jean-Baptiste Mardelle 2015-11-20 22:33:11 UTC
Hi Laptander,
Thanks for the feedback. I can confirm that the minor problems described in 1) and 2) still occur. However, for me the images sequence is correctly rendered. Can you confirm if the sequence is rendered or not ? Also if it does not work, which FFmpeg or Libav version are you using?
Comment 7 Laptander 2015-11-21 15:24:30 UTC
Yes, except minor problems, images sequences are renderable for me too.
Comment 8 Jean-Baptiste Mardelle 2015-11-22 15:51:48 UTC
Git commit 00b82e517919e71cf83a886db993a4ac93e66357 by Jean-Baptiste Mardelle.
Committed on 22/11/2015 at 15:51.
Pushed by mardelle into branch 'Applications/15.12'.

Small cleanup and don't create useless render file

M  +5    -5    renderer/renderjob.cpp
M  +16   -20   src/dialogs/renderwidget.cpp
M  +1    -1    src/dialogs/renderwidget.h

http://commits.kde.org/kdenlive/00b82e517919e71cf83a886db993a4ac93e66357
Comment 9 Laptander 2015-11-22 18:21:54 UTC
Thank you! Now there is no even corrupted file.
I think now I can close that bug report.