Re: [Development] QtWebkit to vcxproj

[raven-worx Software]

Oswald Buddenhagen  wrote:


note that vcxproj support for the build of qt as a whole has been
dropped a while ago, which is reflected by incomplete projects being
generated. you may be able to use them successfully for debugging, but
there is no way to use them for actually building qt reliably.


i know. I had do to some fixing in the generated projects to make them  
compile.  But those generated vcxproj files were essential to get  
started with.


Now i have a Qt5 (almost all major modules) converted and compiling  
adn even running.
QtWebkit conversion also looks good so far. Only WTF, JavaScriptCore  
and WebCore modules are missing.


The webkit sources already come with vcxproj files of these 3 modules.  
Can i take those instead directly? Meaning are those just core modules  
of Webkit? Or do they need some special Qt configuration?




___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Regarding issues related to Qt3D

[swarit wipra]

Hi,
I am getting following error, when running Qt 3d app.

05-19 19:26:06.857 17339 17339 W libClimateHMI.so: (null):0 ((null)): Can't
find surface 2
05-19 19:26:06.869   221   628 D AudioFlinger: mixer(0xab962fb0) throttle
end: throttle time(3)
05-19 19:26:06.877 17339 17339 W libClimateHMI.so: (null):0 ((null)): Can't
find surface 2
05-19 19:26:47.118   221   628 D audio_hw_primary: out_set_parameters:
enter: usecase(0: playback) kvpairs: routing=2 out->devices(2) adev->mode(0)
05-19 19:26:47.169 17339 17434 E libEGL  : call to OpenGL ES API with no
current context (logged once per thread)
05-19 19:26:47.248 17339 17339 I System.out: ClimateServiceIFClient :
onPause
05-19 19:26:47.248 17339 17339 D libClimateHMI.so: (null):0 ((null)):
ClimateHmiIF :  NotifyOnPause  ---  0xf7452b34
05-19 19:26:47.248 17339 17339 D libClimateHMI.so: (null):0 ((null)):
UIClimateNotification :  NotifyOnPause  ---  0xf7452b34
05-19 19:26:47.290 17339 17405 W art : Native thread exiting without
having called DetachCurrentThread (maybe it's going to use a
pthread_key_create destructor?):
Thread[10,tid=17405,Native,Thread*=0xab7c3548,peer=0x12d330a0,"QtThread"]

Please guide me to fix it.
Best Regards
Swarit
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Should the system proxies default setting be switched to true?

[Thiago Macieira]

See https://bugreports.qt.io/browse/QTBUG-53649

Em sexta-feira, 13 de maio de 2016, às 09:11:35 PDT, Andy Shaw escreveu:
> Since there does not seem to be any general objections, I have submitted a
> patch for this - https://codereview.qt-project.org/159120 - this is for
> 5.8. If anyone does see an issue then please say so in the comments, I will
> give it a bit of time before merging once it gets its +2 in order to give
> it a chance to be tried out in case someone hits a problem.
> 
> Andy
> 
> Fra: Simon Hausmann
> Sendt: 12. mai 2016 10:01:35
> Til: Andy Shaw; Kai Koehne; development@qt-project.org
> Emne: Re: [Development] Should the system proxies default setting be
> switched   to true?
> 
> Right, it begs the question: If a third-party application like Chrome can
> use system proxy settings by default, why can't or don't we? :)
> 
> 
> Simon
> 
> From: Development 
> on behalf of Andy Shaw  Sent: Thursday, May 12, 2016
> 9:54:41 AM
> To: Kai Koehne; development@qt-project.org
> Subject: Re: [Development] Should the system proxies default setting be
> switchedto true?
> 
> There is an issue but this comes from the Windows side and is also
> documented by Microsoft as being a problem I believe on their side. But
> this should only be experienced the first time it needs to do this though,
> whereas before it would do this all the time. However, I would personally
> expect that if this is happening for a user, it will not be happening for
> just Qt either.
> 
> Andy
> 
> Fra: Kai Koehne
> Sendt: 12. mai 2016 08:41:21
> Til: Andy Shaw; development@qt-project.org
> Emne: RE: [Development] Should the system proxies default setting be
> switched   to true?
> 
> +1 for switching to using the system proxy settings by default.
> 
> I'm still a bit wary about the 'Windows issue' though. To cite our
> documentation [1]:
> 
>   "On Windows platforms, this function may take several seconds to execute
> depending on the configuration of the user's system."
> 
> Was that the problem with Windows versions configured for automatically
> querying for PAC files, but never getting any response?
> 
> Regards
> 
> Kai
> 
> [1]: http://doc.qt.io/qt-5/qnetworkproxyfactory.html#systemProxyForQuery
> 
> > -Original Message-
> > From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> > project.org] On Behalf Of Andy Shaw
> > Sent: Wednesday, May 11, 2016 3:51 PM
> > To: development@qt-project.org
> > Subject: [Development] Should the system proxies default setting be
> > switched to true?
> > 
> > For some time now we have had the means to configure Qt to use system
> > proxies so that they are on by default or to turn it on via
> > QNetworkProxyFactory. However, this is off by default so it is becoming a
> > reoccurrence that people don't realise that it is not using the system
> > proxies until later on. Potentially not until after a product has been
> > released.
> > 
> > 
> > The reasoning that this was not done before was due to the fact that there
> > was a problem on Windows with it taking too long in some cases to get the
> > information. However this seems to be solved for the most part and
> > expected in some cases due to the fact that it is down to the system, but
> > it is just an initial start up check in this case.
> > 
> > 
> > That said, does anyone see any problems with switching it so that we can
> > now have it turned on by default from Qt 5.8? Naturally the configure
> > option would stay so people can still turn it off if they wish.
> > 
> > For reference the original thread about this can be found:
> >   http://lists.qt-project.org/pipermail/development/2012-> > 
> > October/007037.html
> > 
> > 
> > Andy
> > ___
> > Development mailing list
> > Development@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Help needed: Qt 3D Android build issue

[Sean Harmer]

Hi Marc,

On Thursday 26 May 2016 08:32:21 Marc Mutz wrote:
> Hi,
> 
> In QAtomic, we use compare_exchange_strong with a single memory_order
> argument. The failure mode is therefore calculated by libctdc++, the
> relevant code in atomic_base.h has not changed from 4.8.0 to 6.1.0, and
> appears to do the correct thing. It does use signed bitmasking operations
> with enums that have values with the high bit set (on 32-bit platforms), so
> theoretically there can be a miscompile there.
> 
> A workaround for Qt might be to pass an explicit failure mode, which would
> avoid aforementioned code in libstdc++.
> 
> If the failure is reproducible, then someone with access to the
> configuration could try the attached patch.

Thanks for the patch. The issue was worked around by upgrading the Android CI 
nodes to use gcc 4.9 rather than 4.8.

If anybody else if using 4.8 then they can try this patch.

Cheers,

Sean

> 
> Thanks,
> Marc
> 
> On Monday 23 May 2016 13:54:16 Sean Harmer wrote:
> > Bump, is anybody able to help here please?
> > 
> > Thanks,
> > 
> > Sean
> > 
> > On Friday 20 May 2016 10:13:51 Sean Harmer wrote:
> > > Hi,
> > > 
> > > Trying to submit a simple patch to Qt 3D we are hitting a weird
> > > compilation error on Android CI configurations. The change is:
> > > 
> > > https://codereview.qt-project.org/#/c/157592/
> > > 
> > > and the compilation errors can be seen in full at:
> > > 
> > > http://testresults.qt.io/logs/qt/qt3d/489c6abe13e098eb87fa2c0a8639d43dfc
> > > a
> > > 8c0
> > > 2f/LinuxRHEL_6_6x86_64AndroidAndroid_22armv7GCCRelease_DisableTests_Open
> > > GLES
> > > 2_NoUseGoldLinker/1e29b40895b69af3bcc7f2f8a4b041b69e05b286/buildlog.txt.
> > > gz
> > > 
> > > but in brief they are:
> > > 
> > > In file included from /opt/android/ndk/sources/cxx-stl/gnu-
> > > libstdc++/4.8/include/atomic:41:0,
> > > 
> > >  from
> > > 
> > > /home/qt/work/install/include/QtCore/qatomic_cxx11.h:45, from
> > > /home/qt/work/install/include/QtCore/qbasicatomic.h:53, from
> > > /home/qt/work/install/include/QtCore/qatomic.h:46, from
> > > /home/qt/work/install/include/QtCore/qglobal.h:1145, from
> > > ../../include/Qt3DCore/../../src/core/qt3dcore_global.h:43,
> > > 
> > >  from ../../include/Qt3DCore/qt3dcore_global.h:1,
> > >  from
> > > 
> > > ../../include/Qt3DRender/../../src/render/qt3drender_global.h:43,
> > > 
> > >  from ../../include/Qt3DRender/qt3drender_global.h:1,
> > >  from
> > > 
> > > ../../include/Qt3DRender/5.7.0/Qt3DRender/private/../../../../../src/ren
> > > d
> > > er/ backend/backendnode_p.h:54, from
> > > ../../include/Qt3DRender/5.7.0/Qt3DRender/private/backendnode_p.h:1,
> > > 
> > >  from backend/entity_p.h:55,
> > > 
> > >  from backend/entity.cpp:40:
> > > /opt/android/ndk/sources/cxx-stl/gnu-libstdc++/4.8/include/bits/atomic_b
> > > a
> > > se. h: In member function 'virtual void
> > > Qt3DRender::Render::Entity::sceneChangeEvent(const QSceneChangePtr&)':
> > > /opt/android/ndk/sources/cxx-stl/gnu-
> > > libstdc++/4.8/include/bits/atomic_base.h:577:70: error: failure memory
> > > model cannot be stronger than success memory model for
> > > '__atomic_compare_exchange' return __atomic_compare_exchange_n(&_M_i,
> > > &__i1, __i2, 0, __m1, __m2); ^ /opt/android/ndk/sources/cxx-stl/gnu-
> > > libstdc++/4.8/include/bits/atomic_base.h:577:70: error: failure memory
> > > model cannot be stronger than success memory model for
> > > '__atomic_compare_exchange' return __atomic_compare_exchange_n(&_M_i,
> > > &__i1, __i2, 0, __m1, __m2); ^ /opt/android/ndk/sources/cxx-stl/gnu-
> > > libstdc++/4.8/include/bits/atomic_base.h:577:70: error: failure memory
> > > model cannot be stronger than success memory model for
> > > '__atomic_compare_exchange' return __atomic_compare_exchange_n(&_M_i,
> > > &__i1, __i2, 0, __m1, __m2); ^ /opt/android/ndk/sources/cxx-stl/gnu-
> > > libstdc++/4.8/include/bits/atomic_base.h:577:70: error: failure memory
> > > model cannot be stronger than success memory model for
> > > '__atomic_compare_exchange' return __atomic_compare_exchange_n(&_M_i,
> > > &__i1, __i2, 0, __m1, __m2); ^
> > > /opt/android/ndk/sources/cxx-stl/gnu-libstdc++/4.8/include/bits/atomic_b
> > > a
> > > se .h: In member function 'virtual void
> > > Qt3DRender::Render::Entity::initializeFromPeer(const
> > > QNodeCreatedChangeBasePtr&)':
> > > /opt/android/ndk/sources/cxx-stl/gnu-
> > > libstdc++/4.8/include/bits/atomic_base.h:577:70: error: failure memory
> > > model cannot be stronger than success memory model for
> > > '__atomic_compare_exchange' return __atomic_compare_exchange_n(&_M_i,
> > > &__i1, __i2, 0, __m1, __m2); ^
> > > 
> > > The patch makes no direct use of atomics, only via QSharedPointer.
> > > BogDan
> > > reports that it builds fine with latest NDK.
> > > 
> > > Is this a genuine error on our part or some corner case issue with the
> > > CI's installed NDK?
> > > 
> > > 

Re: [Development] QtWayland synchronisation between GL and compositor

[Gunnar Sletta]

Hi Tomek,

You're not really missing anything :)

In the case of an asynchronous swapBuffers, there is a slight chance the 
wl_buffer release on the next draw pass will be premature, because there is 
nothing the qtwayland module that catches when the GPU is done with a frame. 

In stack that I'm familiar with, the Sailfish OS compositor, we've tackled this 
either by making sure the GPU completes the copy into its framebuffer during 
swap (which is the case for the Jolla Phone), or by sitting on the buffer until 
the GPU is actually done with it and only sending wl_release back to the client 
once the GPU is actually done (which is the case for the cancelled Jolla 
Tablet). If the compositor is a QtQuick compositor running on the render 
thread, sitting on the wl_release for that extra time make for an especially 
fun coding exercise :)

On the client side, the EGL library will make sure that the client is blocked 
when rendering kicks in (some time after the first GL draw call, but typically 
during the client's eglSwapBuffers) if there are no wl_buffers available for 
rendering, so there is no writes to buffers currently in use on the compositor 
side there. 

cheers,
Gunnar


> On 26 May 2016, at 11:45, Tomek Bury  wrote:
> 
> Hi all,
> 
> Is there any mechanism that that synchronises wl_buffer release by the 
> compositor to the GL driver's pipeline?
> 
> I can't figure out how this synchronisation is supposed to work. My initial 
> thought was that the sequence of actions will be something like this. The 
> client sends a new frame to the compositor, in response the compositor would:
> 
> * create EGL image from wl_buffer
> * create GL texture from the EGL image
> * draw client's buffer somewhere 
> * CREATE SYNC OBJECT
> * destroy texture
> * destry image
> * swap buffers
> 
> and perhaps in a different thread:
> * WAIT ON SYNC OBJECT
> * release wl_buffer back to the client
> 
> But I can't see any sync objects created or waited on. 
> 
> Simply depending on eglSwapBuffers() can't work, especially for a 
> tripple-buffered compositor. Let's say GL driver uses buffers called A, B and 
> C in the compositor process. Buffer A is visible now, B is already finished 
> in terms of GL API calls and the compositor has just finished issuing draw 
> commands to buffer C and calls eglSwapBuffers(). In response the GL/EGL 
> driver has to wait until hardware completes all drawing associated with 
> buffer B, hide A ,show B and start using A as a new back buffer. Buffer C can 
> still be in the making.
> 
> Releasing client's wl_buffer only because eglSwapBuffers() was called by the 
> compositor will create a race between compositor's GL driver completing frame 
> C in a background and client's GL driver reusing it's buffer. What am I 
> missing?
> 
> Cheers,
> Tomek
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [QtMultimedia] How to make to use a HW codecs by QML media player on Linux?

[Denis Shienkov]

I have created a BUG: https://bugreports.qt.io/browse/QTBUG-53646

2016-05-26 12:01 GMT+03:00 Denis Shienkov :

> UPD: Seems the problem is ***NOT IN QtMM***..
>
> For example, when I have compiled an usual cpp-based QMediaPlayer example,
> and to set there:
>
> {quote}
> root@apalis-t30:~/Downloads# export
> QT_GSTREAMER_WIDGET_VIDEOSINK=nv_omx_hdmi_videosink
> root@apalis-t30:~/Downloads# export
> QT_GSTREAMER_WINDOW_VIDEOSINK=nv_omx_hdmi_videosink
> {quote}
>
> then CPU loas ~50%, I is good!
>
> So, seems, the problem is in QML && OpenGL!!! It is very-very sad:(
>
> BR,
> Denis
>
>
> 2016-05-25 17:12 GMT+03:00 Denis Shienkov :
>
>> Now, I have added this output:
>>
>> {code}
>> qDebug() << "*** TEST Best sink name" << elementName << ", m_videoSink:"
>> << m_videoSink;
>> {code}
>>
>> to the ctor of QGStreamerVideoOverlay in file
>> /src/gsttools/qgstreamervideooverlay.cpp,
>> and now I see this output:
>>
>> {quote}
>> root@apalis-t30:~/Downloads# ./video-player welcome.avi
>> QIconvCodec::convertToUnicode: using Latin-1 for conversion, iconv_open
>> failed
>> QIconvCodec::convertFromUnicode: using Latin-1 for conversion, iconv_open
>> failed
>> Unable to query physical screen size, defaulting to 100 dpi.
>> To override, set QT_QPA_EGLFS_PHYSICAL_WIDTH and
>> QT_QPA_EGLFS_PHYSICAL_HEIGHT (in millimeters).
>> Setting videosink to  "nv_omx_hdmi_videosink"
>> NvxLiteH264DecoderInit : Opening TVMR H264 block
>> NvxLiteH264DecoderInit : Opening TVMR H264 block
>> *** TEST Best sink name "nv_omx_hdmi_videosink" , m_videoSink: 0x15e1e8
>> *** TEST Best sink name "nv_omx_hdmi_videosink" , m_videoSink: 0x15e5c0
>> NvMMLiteOpen : Block : BlockType = 260
>> ++ NvAvpOpen +++
>> NvMMLiteBlockCreate : Block : BlockType = 260
>>  TVMRFrameDelivery +++
>> BeginSequence 1920x720
>> pnvsi->nDecodeBuffers = 3
>> Display Resolution : (1920x720)
>> Display Aspect Ratio : (1920x720)
>> cbBeginSequence@433: SurfaceLayout = 2
>> pStreamInfo->NumOfSurfaces = 7, MaxDPB = 24, InteraceStream = 0,
>> InterlaceEnabled = 0
>> Allocating new output: 1920x720 (x 9)
>> Warning: "A lot of buffers are being dropped."
>> Warning: "A lot of buffers are being dropped."
>> Warning: "A lot of buffers are being dropped."
>> Warning: "A lot of buffers are being dropped."
>> ^Croot@apalis-t30:~/Downloads#
>> {quote}
>>
>> where are:
>>
>> {quote}
>> *** TEST Best sink name "nv_omx_hdmi_videosink" , m_videoSink: 0x15e1e8
>> *** TEST Best sink name "nv_omx_hdmi_videosink" , m_videoSink: 0x15e5c0
>> {quote}
>>
>> BUT: Nothing changes, the CPU loading ~300% as before... So, seems, the
>> problem is *NOT IN VIDEO-SINK* selection...
>>
>> So, now, I am confused.. WTF? WTF? WTF? :(
>>
>> BR,
>> Denis
>>
>>
>>
>> 2016-05-25 16:53 GMT+03:00 Denis Shienkov :
>>
>>> The solution from:
>>>
>>> https://devtalk.nvidia.com/default/topic/894891/jetson-tk1/gstreamer-1-0-and-qt5-video-playback/
>>>
>>> with adding the:
>>>
>>> {code}
>>> qDebug() << "Setting videosink to " << videoSinkString;
>>> qputenv("QT_GSTREAMER_WINDOW_VIDEOSINK",
>>> videoSinkString.toUtf8());
>>> {code}
>>>
>>> to the main.cpp, where videoSinkString is nv_omx_hdmi_videosink, does
>>> not work too...
>>>
>>> WTF?
>>>
>>>
>>>
>>> 2016-05-25 15:07 GMT+03:00 Denis Shienkov :
>>>
 Now, I have recompiled the QtMM plugin (with default gstreamer 0.10),
 but with adding of debug macro DEBUG_PLAYBIN.
 Then I got following log: https://paste.kde.org/p6ztesnsq

 Where I do not see any mentions about the selected gst sinks.. I see
 only this:

 {quote}
 Set video output: QGstreamerVideoRenderer(0x153fe0)
 Current sink: fakesink0 0x13e590 pending:  0x0 new sink: fakesink0
 0x13e590
 Video sink has not changed, skip video output reconfiguration
 Video sink has chaged, reload video output
 void QGstreamerPlayerSession::setVideoRenderer(QObject*)
 Set video output: QGstreamerVideoRenderer(0x153fe0)
 Current sink: fakesink0 0x13e590 pending:  0x0 new sink:
 qvideosurfacegstsink0 0x1bc470
 Reconfigure video output
 The pipeline has not started yet, pending state:
 QMediaPlayer::StoppedState
 Video sink has chaged, reload video output
 void QGstreamerPlayerSession::setVideoRenderer(QObject*)
 Set video output: QGstreamerVideoRenderer(0x153fe0)
 Current sink: qvideosurfacegstsink0 0x1bc470 pending:  0x0 new sink:
 qvideosurfacegstsink0 0x1bc470
 Video sink has not changed, skip video output reconfiguration
 {quote}

 what is it 'fakesink', 'qvideosurfacegstsink0' ? where is any of
 desired:

 {quote}
 root@apalis-t30:~/Downloads# gst-inspect | grep sink | grep nv
 omx:  nv_omx_audiosink: OpenMAX IL audiosink element
 omx:  nv_gstbin_videosink: OpenMAX IL videosink element
 omx:  nv_omx_videosink: OpenMAX IL videosink element
 omx:  nv_omx_hdmi_videosink: OpenMAX IL hdmi videosink element
 omx:  nv_omx_overlays

Re: [Development] QtWebkit to vcxproj

[Oswald Buddenhagen]

On Wed, May 25, 2016 at 04:11:00PM +0200, raven-worx Software wrote:
> i am trying to create a vcxproj-Project of the QtWebKit module.
>
there is no hope whatsoever to get that working.

note that vcxproj support for the build of qt as a whole has been
dropped a while ago, which is reflected by incomplete projects being
generated. you may be able to use them successfully for debugging, but
there is no way to use them for actually building qt reliably.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] QtWayland synchronisation between GL and compositor

[Tomek Bury]

Hi all,

Is there any mechanism that that synchronises wl_buffer release by the
compositor to the GL driver's pipeline?

I can't figure out how this synchronisation is supposed to work. My initial
thought was that the sequence of actions will be something like this.
The client
sends a new frame to the compositor, in response the compositor would:

* create EGL image from wl_buffer
* create GL texture from the EGL image
* draw client's buffer somewhere
* CREATE SYNC OBJECT
* destroy texture
* destry image
* swap buffers

and perhaps in a different thread:
* WAIT ON SYNC OBJECT
* release wl_buffer back to the client

But I can't see any sync objects created or waited on.

Simply depending on eglSwapBuffers() can't work, especially for a
tripple-buffered compositor. Let's say GL driver uses buffers called A, B
and C in the compositor process. Buffer A is visible now, B is already
finished in terms of GL API calls and the compositor has just finished
issuing draw commands to buffer C and calls eglSwapBuffers(). In response
the GL/EGL driver has to wait until hardware completes all drawing
associated with buffer B, hide A ,show B and start using A as a new back
buffer. Buffer C can still be in the making.

Releasing client's wl_buffer only because eglSwapBuffers() was called by
the compositor will create a race between compositor's GL driver completing
frame C in a background and client's GL driver reusing it's buffer. What am
I missing?

Cheers,
Tomek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.7.0 change files

[Tuukka Turunen]

> -Original Message-
> From: Development [mailto:development-
> bounces+tuukka.turunen=qt...@qt-project.org] On Behalf Of Thiago
> Macieira
> Sent: tiistaina 24. toukokuuta 2016 21.22
> To: development@qt-project.org
> Subject: Re: [Development] Qt 5.7.0 change files
> 
> Em terça-feira, 24 de maio de 2016, às 10:50:13 PDT, Jani Heikkinen escreveu:
> > I and Antti have now done initial change files for every qt submodule
> > (if not already available). Maintaitainers: Please take those over &
> > modify files properly and add missing data.  We just ran
> >
> > Create_changelog.pl ../ v5.6.0...HEAD
> 
> Do we plan on releasing v5.7.0 before v5.6.1 or not?
> 
> If so, then the above is fine. If we release v5.6.1 first, please use the 
> 5.6.1
> branch on the left of ..
> 

If all goes well Qt 5.6.1 should come out before Qt 5.7.0 final. 

--
Tuukka

> > + added some default data there so most probably those need some
> > + actions (at
> > least +2) from you
> 
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.7.0 change files

[Oswald Buddenhagen]

On Tue, May 24, 2016 at 11:21:58AM -0700, Thiago Macieira wrote:
> Em terça-feira, 24 de maio de 2016, às 10:50:13 PDT, Jani Heikkinen escreveu:
> > I and Antti have now done initial change files for every qt submodule (if
> > not already available). Maintaitainers: Please take those over & modify
> > files properly and add missing data.  We just ran
> > 
> > Create_changelog.pl ../ v5.6.0...HEAD
> 
> Do we plan on releasing v5.7.0 before v5.6.1 or not?
> 
> If so, then the above is fine. If we release v5.6.1 first, please use the 
> 5.6.1 
> branch on the left of ..
> 
no, 5.6.1 has lower priority.

anyway, this raises an interesting question about the 5.6.2 and 5.7.1
(and later) changelogs. we won't get around duplicating content unless
we actually sync up releases, which is unrealistic for resource reasons.

> > + added some default data there so most probably those need some actions (at
> > least +2) from you
> 
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Supported platforms for Qt 5.8

[Tuukka Turunen]

Sounds good to me in principle, especially since we very likely have again next 
generation of both iOS and OS X to support in Qt 5.8.

Especially in iOS users tend to upgrade to new versions quite quickly (and then 
see if their devices still can run that or not).

Yours,

Tuukka

From: Development 
[mailto:development-bounces+tuukka.turunen=qt...@qt-project.org] On Behalf Of 
Jake Petroules
Sent: keskiviikkona 25. toukokuuta 2016 21.17
To: development@qt-project.org
Subject: [Development] Supported platforms for Qt 5.8

Hi all,

Might be a bit premature, but is anyone opposed to dropping OS X 10.9 and iOS 
7.x in Qt 5.8? This would follow dropping one OS X and iOS release per Qt 
release for the past 3 releases, but after that I think we should slow to 
dropping one release for each release we add (so, once annually or about once 
every two Qt minor releases). 10.10 and 8.0 were larger releases that began a 
new "generation" so I think that gives us a better baseline to start with 
before slowing to an annual upgrade cycle.
--
Jake Petroules - 
jake.petrou...@theqtcompany.com
Consulting Services Engineer - The Qt Company
Qbs build system evangelist - qbs.io

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [QtMultimedia] How to make to use a HW codecs by QML media player on Linux?

[Denis Shienkov]

UPD: Seems the problem is ***NOT IN QtMM***..

For example, when I have compiled an usual cpp-based QMediaPlayer example,
and to set there:

{quote}
root@apalis-t30:~/Downloads# export
QT_GSTREAMER_WIDGET_VIDEOSINK=nv_omx_hdmi_videosink
root@apalis-t30:~/Downloads# export
QT_GSTREAMER_WINDOW_VIDEOSINK=nv_omx_hdmi_videosink
{quote}

then CPU loas ~50%, I is good!

So, seems, the problem is in QML && OpenGL!!! It is very-very sad:(

BR,
Denis


2016-05-25 17:12 GMT+03:00 Denis Shienkov :

> Now, I have added this output:
>
> {code}
> qDebug() << "*** TEST Best sink name" << elementName << ", m_videoSink:"
> << m_videoSink;
> {code}
>
> to the ctor of QGStreamerVideoOverlay in file
> /src/gsttools/qgstreamervideooverlay.cpp,
> and now I see this output:
>
> {quote}
> root@apalis-t30:~/Downloads# ./video-player welcome.avi
> QIconvCodec::convertToUnicode: using Latin-1 for conversion, iconv_open
> failed
> QIconvCodec::convertFromUnicode: using Latin-1 for conversion, iconv_open
> failed
> Unable to query physical screen size, defaulting to 100 dpi.
> To override, set QT_QPA_EGLFS_PHYSICAL_WIDTH and
> QT_QPA_EGLFS_PHYSICAL_HEIGHT (in millimeters).
> Setting videosink to  "nv_omx_hdmi_videosink"
> NvxLiteH264DecoderInit : Opening TVMR H264 block
> NvxLiteH264DecoderInit : Opening TVMR H264 block
> *** TEST Best sink name "nv_omx_hdmi_videosink" , m_videoSink: 0x15e1e8
> *** TEST Best sink name "nv_omx_hdmi_videosink" , m_videoSink: 0x15e5c0
> NvMMLiteOpen : Block : BlockType = 260
> ++ NvAvpOpen +++
> NvMMLiteBlockCreate : Block : BlockType = 260
>  TVMRFrameDelivery +++
> BeginSequence 1920x720
> pnvsi->nDecodeBuffers = 3
> Display Resolution : (1920x720)
> Display Aspect Ratio : (1920x720)
> cbBeginSequence@433: SurfaceLayout = 2
> pStreamInfo->NumOfSurfaces = 7, MaxDPB = 24, InteraceStream = 0,
> InterlaceEnabled = 0
> Allocating new output: 1920x720 (x 9)
> Warning: "A lot of buffers are being dropped."
> Warning: "A lot of buffers are being dropped."
> Warning: "A lot of buffers are being dropped."
> Warning: "A lot of buffers are being dropped."
> ^Croot@apalis-t30:~/Downloads#
> {quote}
>
> where are:
>
> {quote}
> *** TEST Best sink name "nv_omx_hdmi_videosink" , m_videoSink: 0x15e1e8
> *** TEST Best sink name "nv_omx_hdmi_videosink" , m_videoSink: 0x15e5c0
> {quote}
>
> BUT: Nothing changes, the CPU loading ~300% as before... So, seems, the
> problem is *NOT IN VIDEO-SINK* selection...
>
> So, now, I am confused.. WTF? WTF? WTF? :(
>
> BR,
> Denis
>
>
>
> 2016-05-25 16:53 GMT+03:00 Denis Shienkov :
>
>> The solution from:
>>
>> https://devtalk.nvidia.com/default/topic/894891/jetson-tk1/gstreamer-1-0-and-qt5-video-playback/
>>
>> with adding the:
>>
>> {code}
>> qDebug() << "Setting videosink to " << videoSinkString;
>> qputenv("QT_GSTREAMER_WINDOW_VIDEOSINK",
>> videoSinkString.toUtf8());
>> {code}
>>
>> to the main.cpp, where videoSinkString is nv_omx_hdmi_videosink, does not
>> work too...
>>
>> WTF?
>>
>>
>>
>> 2016-05-25 15:07 GMT+03:00 Denis Shienkov :
>>
>>> Now, I have recompiled the QtMM plugin (with default gstreamer 0.10),
>>> but with adding of debug macro DEBUG_PLAYBIN.
>>> Then I got following log: https://paste.kde.org/p6ztesnsq
>>>
>>> Where I do not see any mentions about the selected gst sinks.. I see
>>> only this:
>>>
>>> {quote}
>>> Set video output: QGstreamerVideoRenderer(0x153fe0)
>>> Current sink: fakesink0 0x13e590 pending:  0x0 new sink: fakesink0
>>> 0x13e590
>>> Video sink has not changed, skip video output reconfiguration
>>> Video sink has chaged, reload video output
>>> void QGstreamerPlayerSession::setVideoRenderer(QObject*)
>>> Set video output: QGstreamerVideoRenderer(0x153fe0)
>>> Current sink: fakesink0 0x13e590 pending:  0x0 new sink:
>>> qvideosurfacegstsink0 0x1bc470
>>> Reconfigure video output
>>> The pipeline has not started yet, pending state:
>>> QMediaPlayer::StoppedState
>>> Video sink has chaged, reload video output
>>> void QGstreamerPlayerSession::setVideoRenderer(QObject*)
>>> Set video output: QGstreamerVideoRenderer(0x153fe0)
>>> Current sink: qvideosurfacegstsink0 0x1bc470 pending:  0x0 new sink:
>>> qvideosurfacegstsink0 0x1bc470
>>> Video sink has not changed, skip video output reconfiguration
>>> {quote}
>>>
>>> what is it 'fakesink', 'qvideosurfacegstsink0' ? where is any of desired:
>>>
>>> {quote}
>>> root@apalis-t30:~/Downloads# gst-inspect | grep sink | grep nv
>>> omx:  nv_omx_audiosink: OpenMAX IL audiosink element
>>> omx:  nv_gstbin_videosink: OpenMAX IL videosink element
>>> omx:  nv_omx_videosink: OpenMAX IL videosink element
>>> omx:  nv_omx_hdmi_videosink: OpenMAX IL hdmi videosink element
>>> omx:  nv_omx_overlaysink: OpenMAX IL overlaysink element
>>> omx:  nv_gl_eglimagesink: OpenMAX IL videosink element
>>> nvxvimagesink:  nvxvimagesink: Video sink
>>> root@apalis-t30:~/Downloads#
>>> {quote}
>>>
>>> sinks? I do not understand nothing.. o_O How I can see the selected sink
>>> nam