continuous play

Thiago Macieira thiago at kde.org
Mon Sep 16 22:56:46 BST 2013


On segunda-feira, 16 de setembro de 2013 19:51:05, Harald Sitter wrote:
> On Mon, Sep 16, 2013 at 8:34 PM, Thiago Macieira <thiago at kde.org> wrote:
> > Actually, the problem is in the C++ side.
> > 
> > A file called "\xe92.ogg" is NOT QUrl("é2.ogg").
> > 
> > There are two problems with that: first, that you forgot the "file:" part.
> 
> yes but no :P
> 
> The phonon gstreamer debug is what is not correct because it simply
> qDebugs the QUrl object, however what is actually passed to gstreamer
> is:
> QFile::encodeName("file://" + url).toPercentEncoding(encodingExclude);
>
> hence why gstreamer actualy gets a correct encoding and scheme:

Well, that's even worse. A valid QUrl for a local file already has the "file:" 
part, so that would create a double file:.

Also, QUrl already properly encodes the different parts of the URL as 
necessary. QByteArray::toPercentEncoding is wrong when applied to a URL. It 
will also *double* percent encode anything that QUrl left encoded.

You didn't say what that "url" variable was above. Since you cannot 
operator+(const char*, const QUrl &) (there's no overload that will match that 
and QUrl does not have any cast operators), I have to assume you have either a 
QString or a QByteArray there. Any valid full URL in a QByteArray or QString 
will have percent-encoded forms.

So:

  QUrl u("file:é2.ogg");
  QByteArray url = u.toEncoded(); // url == "file:%C3%A92.ogg"
  QFile::encodeName(...).toPercentEncoding(...) == file://file:"%25C3%25A92.ogg"

This is so much worse!

So, when fixing this, please remember:

1) Any local file URL has "file:"

2) In Qt 4, QUrl's constructor and QUrl::toString() are broken and flawed. Do 
not use them, ever. Not even in debugging, since they will just confuse you. 
Use QUrl::fromEncoded and QUrl::toEncoded.
[The source above is valid for Qt 5. To do the same in Qt 4, use:
	QUrl u = QUrl::fromEncoded("file:é2.ogg");
]

3) QUrl already encodes everything correctly. To get a proper URL to be passed 
to other API or serialised, simply use QUrl::toEncoded().

> >> > gstfilesrc.c:1141:gst_file_src_uri_set_uri:<source> Invalid URI
> >> > 'file://%C3%A92.ogg' for filesrc: The URI 'file://%C3%A92.ogg' is
> >> > invalid
> > 
> > Second, an "é" in a URL is ALWAYS "%C3%A9", which corresponds to a file
> > name "\xc3\xa92.ogg". There's no way to change that, not now, not ever,
> > and any implementation that allows that is broken.
> > 
> > If you want to reach the file called "\xe92.ogg", you need to write
> > "%E92.ogg".
>     const QFileInfo fileInfo(filename);
>     if (fileInfo.exists()) {
>         bool localFs = QAbstractFileEngine::LocalDiskFlag &
> QFSFileEngine(filename).fileFlags(QAbstractFileEngine::LocalDiskFlag);
>         if (localFs && !filename.startsWith(QLatin1String(":/")) &&
> !filename.startsWith(QLatin1String("qrc://"))) {
>             d->url = QUrl::fromLocalFile(fileInfo.absoluteFilePath());
> 
> Nothing else happens between MediaSource("\xe92.ogg") and the qDebug,
> so  QUrl::fromLocalFile is what comes up with QUrl("é2.ogg").

Your debugging might be broken. Remember qDebug() is not 8-bit safe in Qt 4. 
Also, QDebug's operator<< for QUrl uses QUrl::toString(), which I said above 
you should never use in Qt 4 because it confuses you.

We should not continue because you have faulty debugging.

Even if we did, QUrl::fromLocalFile() always set the scheme to "file", so 
QUrl::fromLocalFile(anything) will never produce QUrl("é2.ogg"), and you'll 
never see that even with the flawed methods. So I know there's something wrong 
right there.

Assuming that the source is Qt 4, we have:

	// source is encoded in Latin 1, *NOT UTF-8*
	MediaSource("é2.ogg"); // is actually:
	MediaSource(QString::fromAscii("é2.ogg"));

so fileName = {U+00E2, U+0032, U+002E, U+006F, U+0067, U+0067}; in the 
constructor. That means it will run:

            d->url = QUrl::fromLocalFile(fileInfo.absoluteFilePath());

which will yield d->url = "file:///something/local/%C3%A92.ogg".

As it it should be. There's nothing wrong.


-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-multimedia/attachments/20130916/baaa019e/attachment.sig>
-------------- next part --------------
_______________________________________________
kde-multimedia mailing list
kde-multimedia at kde.org
https://mail.kde.org/mailman/listinfo/kde-multimedia


More information about the kde-multimedia mailing list