+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Support (https://forum.kodi.tv/forumdisplay.php?fid=33)
+--- Forum: General Support (https://forum.kodi.tv/forumdisplay.php?fid=111)
+---- Forum: Linux (https://forum.kodi.tv/forumdisplay.php?fid=52)
+---- Thread: Linux VAAPI: Nuc, Chromebox, HSW, IVB, Baytrail with Ubuntu 14.04 (/showthread.php?tid=165707)
Pages:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
RE: vaapi-sse4: Deinterlacing Testing - uomiarz - 2014-05-09
(2014-05-03, 17:50)uomiarz Wrote: I am runnung asus chromebox on Celeron® 2955U
Installed Xbuntu 14.04 and xbmc on top of it (from fernetmenta ppa)
Follow guide from post #1
I end up with terrible tearing. Usually top of the screen.
Changing deinterlace settings change tearing but it is always present.
HDMI out to amp and then TV.
Here is a fix for tearing
Code:
sudo nano /usr/share/X11/xorg.conf.d/20-intel.conf
Section "Device"
Identifier "Intel Graphics"
Driver "intel"
Option "TearFree" "true"
EndSectionMore details here:
http://forum.xbmc.org/showthread.php?tid=185329&pid=1699218#pid1699218
RE: vaapi-sse4: Deinterlacing Testing - lelouch - 2014-05-09
(2014-05-07, 20:21)illiac4 Wrote:(2014-05-06, 19:57)lelouch Wrote:(2014-05-05, 14:57)lelouch Wrote: Hi, I have been using this ppa for a while and I must say it is really good. Specially for IPTV.
I have tested IPTV on this xbmc and it works really good. DeInterlacing is good and channel switching time is also fast [about 1-2 secs].
I took my xbmc setup to test an IPTV stream with different vendor. This is where I encountered a weird problem with IPTV. It started taking about 20 -25 secs to switch channels
This is the log - http://paste.ubuntu.com/7398504/
Any help would be really appreciated. Thank you
Anyone please help ?
Usually IPTV streams are multicast. And it happens that stock modem or. router is flooded with packets. This happens especially when switching different providers or. scanning network for new programs (with tvheadend i can kill my modem in few seconds).When i am doing testings i often have to restart the modem i have got from provider. I prefer to convert multicast traffic to unicast (http). This way it works great and if you have a router that can do this (tomato compatible router, dd-wrt did not work well for this thing) then you will also get rid of messing the network stream to the whole subnet. When modem gets flooded it can response slowly or even stops responding to multicast traffic. It is also back-end depended till now best for iptv streams was iptv simple addon (but no recording), tvheadend was ok till 3.5, i have tried VDR but i dont like that i can not mass control icons and xmltv (epg) with it.
Yes IPTV streams in most of the cases are multicast streams. I totally agree with you that streams can be slow because of packet flooding or broadcast storm or anything which can choke the network with unnecessary packets. However I have verified that my network is not flooded. It was verified using tcpdump and wireshark. Even I like to convert my udp stream to http stream using udpxy. However in this network, in which I experienced very slow channel switching time, problem actually is in how the IPTV headend is sending the transport stream [Mpegts]. In PMT table pcr_id value of the PES packet elementary stream is used. [Generally pcr_id value of the first elementary transport video stream is used]
VLC is able to handle this stream pretty good so I am sure xbmc can also be tweaked to handle such streams.
This IPTV stream can be tested using this file tcpdump file. https://www.dropbox.com/s/4apjw3aq73gg4jm/outfile.pcap
Following is the example of replaying this file
tcprewrite --enet-smac=00:26:6c:bc:70:33 --enet-dmac=01:00:5e:03:02:02 --dstipmap=0.0.0.0/0:239.3.2.2 --srcipmap=0.0.0.0/0:172.24.0.33 --infile=/outfile.pcap --outfile=/outfilewr.pcap
tcprewrite --infile=/udpzero.pcap --outfile=/udpzero_chk.pcap --fixcsum
tcpreplay --loop=0 --intf1=eth0 /udpzero_chk.pcap
please note in the first tcprewrite command use your own mac addresses & ip addr to make this replaying work
Once you replay this file, then you can start xbmc and open this link udp://239.3.2.2:1234.
Opening this stream takes about 20 secs.
Developers please try this out. This might help us make xbmc's mpegts library more better. Thank you
RE: vaapi-sse4: Deinterlacing Testing - fritsch - 2014-05-09
(2014-05-09, 04:58)uomiarz Wrote:(2014-05-03, 17:50)uomiarz Wrote: I am runnung asus chromebox on Celeron® 2955U
Installed Xbuntu 14.04 and xbmc on top of it (from fernetmenta ppa)
Follow guide from post #1
I end up with terrible tearing. Usually top of the screen.
Changing deinterlace settings change tearing but it is always present.
HDMI out to amp and then TV.
Here is a fix for tearing
Code:sudo nano /usr/share/X11/xorg.conf.d/20-intel.conf
Section "Device"
Identifier "Intel Graphics"
Driver "intel"
Option "TearFree" "true"
EndSection
More details here:
http://forum.xbmc.org/showthread.php?tid=185329&pid=1699218#pid1699218
No, No and no again. This will introduce Triple Buffering and we absolutely don't want that! Cause we are using swapBuffers to update the images on screen. Use the /etc/init/xbmc.conf I provide and you won't have a single bit of tearing. It's all a backing store issue.
As you are not running this howto anyways, fix your lightdm.conf
RE: vaapi-sse4: Deinterlacing Testing - gebnix - 2014-05-12
since a few days i have several problems with skins, others than confluence, on this build :
1. if i select "change content" in filemanager's context menu of a folder to add the folder to my library, xbmc is crashing
2. video and audio setting menus in OSD during video and Live-TV playback are empty
both issues occur on Aeon MQ5, Aeon Nox and Amber.
no problems with confluence.
i can't reproduce these errors on my Raspberry Pi with official Openelec 4.0 using Amber.
is there something special in this build, which could cause these issues ?
RE: vaapi-sse4: Deinterlacing Testing - George - 2014-05-13
(2014-05-12, 19:09)gebnix Wrote: since a few days i have several problems with skins, others than confluence, on this build :
1. if i select "change content" in filemanager's context menu of a folder to add the folder to my library, xbmc is crashing
2. video and audio setting menus in OSD during video and Live-TV playback are empty
both issues occur on Aeon MQ5, Aeon Nox and Amber.
no problems with confluence.
i can't reproduce these errors on my Raspberry Pi with official Openelec 4.0 using Amber.
is there something special in this build, which could cause these issues ?
Same here. I suspect it has something to do with these changes: http://forum.xbmc.org/showthread.php?tid=194515
This build is built from master and those skins are not yet ready for Helix. Isn't it possible to compile a Gotham compatible version with the deinterlacing goodness included also?
RE: vaapi-sse4: Deinterlacing Testing - fritsch - 2014-05-13
You are free to do so.
RE: vaapi-sse4: Deinterlacing Testing - George - 2014-05-13
(2014-05-13, 10:04)fritsch Wrote: You are free to do so.
Somehow I knew that would be the answer :-) I fixed the Aeon MQ5 skin, changes available for download here.
RE: vaapi-sse4: Deinterlacing Testing - puithove - 2014-05-13
I've just purchased my first NUC and it is my first experience with Intel graphics. I'm putting this in as an upgrade for a much older and now under-powered Nvidia box. I decided to go this way based on what I read here. Unfortunately I'm having some disappointing results with the deinterlacing and I'd really appreciate some help trying to track it down.
All progressive content is playing beautifully. Interlaced content via LiveTV (or recorded) from MythTV backend is having trouble. If I set Deinterlace method to "De-Interlace", I get extremely jerky playback depending on the content. When I open the codec info panel or have debugging enabled, I can see that the FPS is dropping down under 29.97 - around 15 or so. If I use Auto Select, it chooses a different method (I think probably BOB based on the visual results), playback is smooth. I do notice in this mode the FPS is highly variable (again based on content) anywhere between 29.97 up to and including 59.94. Some content runs at a steady 59.94 and this is the same content that plays fine with "De-Interlace" method. This can change on the same channel in the same stream when going to/from commercials.
The content that seems to cause the variable FPS and the jerky playback appears to be that which the original recording was film - movies, TV shows recorded on film, etc. Other content that I'm pretty sure was sourced on video seems to be the smooth playback. If I'm right about that, it seems like it's content that has been Telecined that causes the issue.
I'm using VAAPI hardware acceleration with the SW Filters enabled, but I get the same results with HW Accel turned off, using multithreaded software decode.
CPU not even close to being maxed and load fairly evenly spread between cores.
Settings that I'm using that seem relevant:
Vertical Sync: Let driver decide
Render Method: Auto Detect
HQ scalers: 20%
Decoding method: HW
VDPAU: Off
VAAPI: On
MPEG2: On
H264: On
VC1: Off
Use SW Filter: On
Adjust refresh rate: On Start/Stop
Sync playback to display: Resample Audio
Deinterlace Video: Auto
Deinterlace Method: De-Interlace
Scaling Method: Nearest Neighbor (Lancos3 Optimized for 20% HQ).
My specs:
Openelec official release build 4.0.0 (my first go with OE and I'm really liking it thus far)
Intel NUC D54250WYK1 -> HDMI out -> Yamaha AVR -> HDMI In -> Panasonic VT50 Plasma
MythTV backend 0.27
PVR cmyth add-on
Debug log of a reboot and starting playback for a couple minutes of affected video:
https://spideroak.com/storage/OB2WS5DIN53GK/shared/647068-2-1485/01_XBMC.log?5ad3a35e903abfe3274cb051cc1edd96
This repeats repeats constantly during playback:
Code:
14:34:26 T:140635415770880 DEBUG: ffmpeg[3BFFF700]: [src] Flat options syntax is deprecated, use key=value pairs
14:34:26 T:140635415770880 DEBUG: ffmpeg[3BFFF700]: [src] w:1920 h:1080 pixfmt:nv12 tb:1001/60000 fr:0/0 sar:1/1 sws_param:
14:34:26 T:140635415770880 DEBUG: ffmpeg[3BFFF700]: [Parsed_yadif_0] mode:1 parity:-1 deint:1
14:34:27 T:140635415770880 DEBUG: ffmpeg[3BFFF700]: [auto-inserted scaler 0] w:0 h:0 flags:'' interl:0
14:34:27 T:140635415770880 DEBUG: ffmpeg[3BFFF700]: [Parsed_yadif_0] auto-inserting filter 'auto-inserted scaler 0' between the filter 'src' and the filter 'Parsed_yadif_0'
14:34:27 T:140635415770880 DEBUG: ffmpeg[3BFFF700]: [auto-inserted scaler 0] w:1920 h:1080 fmt:nv12 sar:1/1 -> w:1920 h:1080 fmt:yuv420p sar:1/1 flags:0x2
14:34:27 T:140635415770880 ERROR: CDVDVideoCodecFFmpeg::FilterProcess - cur_buf
14:34:27 T:140635415770880 DEBUG: CDVDPlayerVideo - video decoder returned errorDebug log using "Auto Select" method a few minutes later on the same TV show:
https://spideroak.com/storage/OB2WS5DIN53GK/shared/647068-2-1480/01_XBMC.log?6b2ebe8944332ab5b2cc1f5852158333
You can see there are none of the messages called out above.
RE: vaapi-sse4: Deinterlacing Testing - fritsch - 2014-05-13
Provide: /usr/lib/xbmc/xbmc-xrandr | pastebinit
From the log I see you run most of the time in 30hz mode and later in 60hz mode. Both are really bad for 59.94 content.
All fine with that sample: https://dl.dropboxusercontent.com/u/55728161/deinterlacing-test.mp4 and Deinterlace?
RE: vaapi-sse4: Deinterlacing Testing - fritsch - 2014-05-13
Please try the latest from here: http://xbmcnightlybuilds.com/category/openelec-generic/
RE: vaapi-sse4: Deinterlacing Testing - puithove - 2014-05-13
Yea, I forgot that's one of the issues I'm having. On each reboot the GUI switches to 30hz mode because that's the "Preferred" from EDID. It does successfully switch to 59.94 when playback starts (this is with jerky video in full effect):
http://sprunge.us/hVAe
So far I've just been changing the GUI to 59.94 after each reboot (If I remember). Still need to google a solution at some point.
Yes, playback of that sample seems smooth(ish) with method set to "De-Interlace". It's a 50hz file and gets played with refresh at 60.0 since I don't have a 50 mode.
http://sprunge.us/iKRb
(2014-05-13, 21:18)fritsch Wrote: Please try the latest from here: http://xbmcnightlybuilds.com/category/openelec-generic/
Actually that was one of the things I tried earlier this morning - r18369-g320ea5e - and it didn't help.
RE: vaapi-sse4: Deinterlacing Testing - FernetMenta - 2014-05-13
could you please post a log running this version?
RE: vaapi-sse4: Deinterlacing Testing - fritsch - 2014-05-13
Can it be convinced to have 50hz, by putting that xorg.conf to /storage/.config ?
Code:
Section "Device"
Identifier "Device0"
Driver "intel"
VendorName "Intel rocks the world"
EndSection
Section "Screen"
Identifier "Screen0"
Device "Device0"
Monitor "HDMI1"
DefaultDepth 24
SubSection "Display"
Depth 24
Modes "1920x1080@60p" "1920x1080@50p" "[email protected]"
EndSubSection
EndSection
Section "Monitor"
Identifier "HDMI1"
HorizSync 14.0 - 70.0
VertRefresh 24.0 - 62.0
Option "DPMS" "true"
ModeLine "1920x1080@60p" 148.500 1920 2008 2056 2200 1080 1084 1089 1125 +hsync +vsync
ModeLine "1920x1080@50p" 148.500 1920 2448 2492 2640 1080 1084 1089 1125 +hsync +vsync
ModeLine "[email protected]" 148.350 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync
EndSection
Section "Extensions"
# fixes tearing
Option "Composite" "Disable"
EndSectionEdit: Btw. please try with one of those nightlies. OE has patched out ffmpeg 2.2 out of the FM patches for 4.0 and "mixed" something up.
RE: vaapi-sse4: Deinterlacing Testing - puithove - 2014-05-13
(2014-05-13, 21:35)FernetMenta Wrote: could you please post a log running this version?
Sure, would you like it playing MythTV content, that sample, or both?
RE: vaapi-sse4: Deinterlacing Testing - fritsch - 2014-05-13
Never trust myth, but go ahead.