No problem here.Image and sound
Openpli 5 .GStreamer 1.9.0.
Posted 4 April 2016 - 11:30
I see that Milo has added cross-answers-mipsel.txt as a link to a cross-answers-mips.txt in meta-openembedded: https://github.com/o...62f20a7c596ac0b
I am already glad that I no longer need to use bbappend files to fix this, but unfortunately it is not working .
It gives me a link to the incorrect file.
Perhaps the reason is that in the submodules link does not work as intended?
Does anybody after this correction work mipsel cross-answers files?
Posted 4 April 2016 - 11:33
Does anybody after this correction work mipsel cross-answers files?
No. For me it is not working too..indeed wrong link. I copy cross-answer-mips.txt and rename it to cross-answers-mipsel.txt.
Dreambox dm920, Uclan Ustym4Kpro, Gigablue UHD TRIO 4K and Dreambox dm8000. Wavefrontier T55 13.0|19.2|23.5|28.2 + Ziggo.
Posted 4 April 2016 - 11:46
Of course, if I create symlink manually it worked.
But if you change the submodule then can not make a push.
Therefore, I use bbappend files to fix it: https://github.com/T...142863a3fa9bbca
Edited by Taapat, 4 April 2016 - 11:48.
Posted 4 April 2016 - 14:37
@Beeker just tried last head gstreamer plugins good .
Unfortunately it does fail at compile time : last head :
https://cgit.freedes...03b2d0f424c0595
The previous commit there compile is ok.
https://cgit.freedes...4c8e4b0174a1518
the compile error log is tremendous big 1395 rules.
For the time being I now adapted the gstreamer1.0-plugins-good.inc
and add the
TARGET_CFLAGS += "-Wno-error"
Then it compiles again with very last head. I tested the full gstreamer on vuduo2 looks that it works fine.
But I do not like in general tp use -Wno-error mostly warning do mean something. deprecated or ...
included here the full error log I have before the -Wno-error. I can't find the excact cause and or warning which triggers compile error if -Wno-error is not set.
Posted 4 April 2016 - 14:49
I cleaned up a bit the full gstreamer bundle . There where white spaces in bb recipes and a lot off patches not used anymore. Also in general the patch files are in the bb recipe and not in inc and bb files. exception on this is the retrospection patch on gstreamer plugins. That is in the general plugin.inc file and in map files.
Here the cleaned gstreamer 1.9.0.1 bundle srcrev for each package are those from today 4 april 10:40 UTC time (belgium 12:40 time).
Full cleaned bundle here :
Compiled fresh flashed on duo2 tested all ok (also youtube)
Compiled for dm8000 also ok (not flashed or tested yet on dm8000)
note : the gst-libav (which is currently using ffmpeg n3.0 does not use introspection)
Edited by christophecvr, 4 April 2016 - 14:52.
Posted 4 April 2016 - 14:59
With TARGET_CFLAGS += "-Wno-error" ok.
We have to wait a few days.
n file included from /home/christophe/openpli50/openpli-oe-core/build/tmp/sysroots/vuduo2/usr/include/gstreamer-1.0/gst/gst.h:54:0, from /home/christophe/openpli50/openpli-oe-core/build/tmp/sysroots/vuduo2/usr/include/gstreamer-1.0/gst/rtp/gstrtpbuffer.h:27, from ../../../git/gst/rtpmanager/rtpjitterbuffer.c:22: ../../../git/gst/rtpmanager/rtpjitterbuffer.c: In function 'rtp_jitter_buffer_insert': /home/christophe/openpli50/openpli-oe-core/build/tmp/sysroots/vuduo2/usr/include/gstreamer-1.0/gst/gstclock.h:80:43: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] #define GST_CLOCK_TIME_IS_VALID(time) (((GstClockTime)(time)) != GST_CLOCK_TIME_NONE)
I assume it will be solved soon.
Dreambox dm920, Uclan Ustym4Kpro, Gigablue UHD TRIO 4K and Dreambox dm8000. Wavefrontier T55 13.0|19.2|23.5|28.2 + Ziggo.
Posted 4 April 2016 - 15:32
With TARGET_CFLAGS += "-Wno-error" ok.
We have to wait a few days.
n file included from /home/christophe/openpli50/openpli-oe-core/build/tmp/sysroots/vuduo2/usr/include/gstreamer-1.0/gst/gst.h:54:0, from /home/christophe/openpli50/openpli-oe-core/build/tmp/sysroots/vuduo2/usr/include/gstreamer-1.0/gst/rtp/gstrtpbuffer.h:27, from ../../../git/gst/rtpmanager/rtpjitterbuffer.c:22: ../../../git/gst/rtpmanager/rtpjitterbuffer.c: In function 'rtp_jitter_buffer_insert': /home/christophe/openpli50/openpli-oe-core/build/tmp/sysroots/vuduo2/usr/include/gstreamer-1.0/gst/gstclock.h:80:43: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] #define GST_CLOCK_TIME_IS_VALID(time) (((GstClockTime)(time)) != GST_CLOCK_TIME_NONE)I assume it will be solved soon.
I did not searched very well but did not found this specific error. But indeed looks like that issue should be solved in gstreamer.
Posted 4 April 2016 - 16:04
I have not checked which version offers Beeker on OE, but I understand that he offers taged versin 1.9.0.1, which is the only numeral after 1.8.0, with comment "Back to development".
I think it is right, because in this case we can without problems update the any component to a newer version of git, if there are any critical fixes.
If he offers not taged version, then it's really not right.
Posted 4 April 2016 - 16:22
I send a small patch to OE for gstreamer-bad, no update.pull request closed.
Gstreamer 1.6.3 needs to be updated to 1.8.0 in OE and the git recipes to 1.9.0.1
If OE has updated gstreamer 1.6.3 to 1.8.0. Openpli can use them with bbappends.
The recipes here, are just for experimental use.
Awaiting for my patch....
Dreambox dm920, Uclan Ustym4Kpro, Gigablue UHD TRIO 4K and Dreambox dm8000. Wavefrontier T55 13.0|19.2|23.5|28.2 + Ziggo.
Posted 4 April 2016 - 16:50
1.8.0 is not as good as you think.
For example, check this video (not from my): https://drive.google...HZDWE4tbnM/view
Last gstreamer plays their without picture.
Users report that changing libgstmatroska.so library to 1.4.5 version this vidoe is played without any problems.
I have not found which commit break this, but the fact is that the 1.8.0 have problems with some mkv.
Posted 4 April 2016 - 18:43
I'm afraid it is not smart to use gstreamer 1.9 right know as it is just the first thing after the stable 1.8.... I suggest the best that could be choosen here is 1.8... and arrange that oe has it right-a-way....
WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W
Posted 4 April 2016 - 19:20
Hi, with sample is problem that pts is not set on buffers, I guess problem in matroskademux.
gst-launch-1.0 filesrc location=/media/net/MAROS_NB/problem.mkv ! matroskademux ! h264parse ! fakesink silent=false -v
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (37124 bytes, dts: 0:00:00.040000000, pts: none, duration: 0:00:00.040000000, offset: 36396, offset_end: -1, flags: 00002040 discont delta-unit ) 0x76212370 /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (40924 bytes, dts: 0:00:00.080000000, pts: none, duration: 0:00:00.040000000, offset: 73520, offset_end: -1, flags: 00002040 discont delta-unit ) 0x76248c18 /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (56945 bytes, dts: 0:00:00.120000000, pts: none, duration: 0:00:00.040000000, offset: 114444, offset_end: -1, flags: 00002040 discont delta-unit ) 0x76248a38 /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (61886 bytes, dts: 0:00:00.160000000, pts: none, duration: 0:00:00.040000000, offset: 171389, offset_end: -1, flags: 00002040 discont delta-unit ) 0x762120f0 /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (53214 bytes, dts: 0:00:00.200000000, pts: none, duration: 0:00:00.040000000, offset: 233275, offset_end: -1, flags: 00002040 discont delta-unit ) 0x76248ad8 /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (63493 bytes, dts: 0:00:00.240000000, pts: none, duration: 0:00:00.040000000, offset: 286489, offset_end: -1, flags: 00002040 discont delta-unit ) 0x762125f0
Posted 4 April 2016 - 19:24
1.8.0 is not as good as you think.
For example, check this video (not from my): https://drive.google...HZDWE4tbnM/view
Last gstreamer plays their without picture.
Users report that changing libgstmatroska.so library to 1.4.5 version this vidoe is played without any problems.
I have not found which commit break this, but the fact is that the 1.8.0 have problems with some mkv.
This file clearly has something problematic and stricter checking in newer gstreamer makes it fail. Remuxing it with ffmpeg makes it work fine, so it is definitely something about the specific muxer (WonderShare Matroska Muxer).
ffmpeg -i Крыша\ мира\ -\ Сезон\ 1\ -\ Серия\ 4.mkv -c copy -f matroska test.mkv
test.mkv then plays absolutely fine.
Above command doesn't change the video or audio streams. Just remuxing with the ffmpeg matroska muxer.
edit: while remuxing, ffmpeg reports: [matroska @ 0x7fd8aa0c3600] Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly
So it is definitely problem of the source used muxer not setting correctly the timestamps. From the above message, I guess that such kind of file will stop working in ffmpeg too in the future.
Edited by malakudi, 4 April 2016 - 19:26.
0 members, 2 guests, 0 anonymous users