+- 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: Raspberry Pi (https://forum.kodi.tv/forumdisplay.php?fid=166)
+---- Thread: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) Part 1 (/showthread.php?tid=211501)
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
RE: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) - popcornmix - 2015-03-29
(2015-03-29, 05:08)zaphod24 Wrote: I managed to get Kodi to crash with OMXplayer enabled and watching live tv. Logs at http://sprunge.us/dcKW
Interesting. The log gives a good indication of where the problem lies. Being able to reproduce would be helpful to get a fix.
I don't suppose you ever see a crash (or other failure) from a recording of this channel?
It would be useful to get hold of a sample file.
RE: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) - Gregoire - 2015-03-29
When updating to the last testbuild I had "MD5 check failed" message. What am I doing wrong?
RE: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) - MONSTA - 2015-03-29
build #0328
Crashs and reboots when trying to play hevc. Although Rpi2 is weak to play, but anyway.
RE: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) - Milhouse - 2015-03-29
@Gregoire: You have a corrupt download, download the relevant tar again.
These are the md5 hashes for the two #0328 builds:
Code:
1a8977a7a7ee42c6358dfb28d9f03465 OpenELEC-RPi.arm-devel-20150328210216-#0328-g61e13a3.tar
b4db6b8f05f2f350f8d1b25bf88f0bbd OpenELEC-RPi2.arm-devel-20150328210216-#0328-g61e13a3.tarI've just downloaded the builds and confirmed the hashes are correct, both for the tar itself and also the extracted KERNEL and SYSTEM files.
If you continue to experience this error with a known good tar then I would suspect SD corruption, or some other filesystem problem, or maybe even an unstable overclock.
Re: RE: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) - Milhouse - 2015-03-29
(2015-03-29, 13:14)MONSTA Wrote: build #0328
Crashs and reboots when trying to play hevc. Although Rpi2 is weak to play, but anyway.
An actual OS reboot, or Kodi restart?
In the case of a Kodi restart, the crashlog would be very useful. The recently uploaded debug build would provide a more complete crashlog (but requires a FAT partition of at least 384MB). HEVC shouldn't crash the Pi/Pi2, even if it struggles to play HEVC content.
Edit: Can reproduce with Sintel_1080p_27qp_24fps_1aud_9subs.mkv (it's a Kodi restart) - will upload a debug crashlog shortly.
RE: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) - Gregoire - 2015-03-29
(2015-03-29, 13:23)Milhouse Wrote: @Gregoire: You have a corrupt download, download the relevant tar again.
These are the md5 hashes for the two #0328 builds:
Code:1a8977a7a7ee42c6358dfb28d9f03465 OpenELEC-RPi.arm-devel-20150328210216-#0328-g61e13a3.tar
b4db6b8f05f2f350f8d1b25bf88f0bbd OpenELEC-RPi2.arm-devel-20150328210216-#0328-g61e13a3.tar
I've just downloaded the builds and confirmed the hashes are correct, both for the tar itself and also the extracted KERNEL and SYSTEM files.
If you continue to experience this error with a known good tar then I would suspect SD corruption, or some other filesystem problem, or maybe even an unstable overclock.
I just checked the MD5 on my PC and it's good. I'll have to check further. Thanks for the tips.
RE: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) - Milhouse - 2015-03-29
Seems to be a little random. Tried again with Sintel_1080p_27qp_24fps_1aud_9subs.mkv, but now it played without crashing. Instead Kodi crashed when playing bbb_1080p_c.ts (Big Buck Bunny) which worked previously when testing just a few minutes ago.
HEVC Kodi crashlog when playing bbb_1080p_c.ts: http://sprunge.us/BbGQ
It seems that Kodi will crash as soon as playback commences (or within a second or two).
RE: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) - popcornmix - 2015-03-29
(2015-03-29, 13:42)Milhouse Wrote: HEVC Kodi crashlog when playing bbb_1080p_c.ts: http://sprunge.us/BbGQ
Seems to crash in hevcdsp_qpel_neon.S. Does reverting the "qpel" HEVC patch avoid the issue?
EDIT:
Actually "qpel" is already upstream. The "epel" patch is the only custom patch we have, so may be worth reverting that first.
RE: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) - noggin - 2015-03-29
Just tried #0328 and the DTS HD-MA decode and MVC decode are amazing. Brilliant work. Just ripped my Gravity 3D Blu-ray to an MKV and get full DTS HD and 24p Full HD MVC decoding and output in Frame Packed 3D.
However I have some 720/50p H264 + 5.1 AC3 .wtv off-air recordings from DVB-S2 which now stutter a little (though no drop/skips are reported) with both OMXPlayer and MMAL decoding if I disable pass-through and thus allow internal decoding to LPCM multichannel. This isn't specific to the Milhouse builds though - I've just reverted to a 5.0.6 OE release build and that also judders a little with passthrough disabled?
I guess I should raise this elsewhere as it's not Milhouse specific - but it is a pity as it means there is still a setting change required (or does the DTS-HD MA decode option override pass through and thus allow DTS-HD to be decoded, but DTS and DD to be passed, rather than the DTS core of a DTS HD signal being passed through in that combination of settings?)
RE: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) - popcornmix - 2015-03-29
(2015-03-29, 14:10)noggin Wrote: Just tried #0328 and the DTS HD-MA decode and MVC decode are amazing. Brilliant work. Just ripped my Gravity 3D Blu-ray to an MKV and get full DTS HD and 24p Full HD MVC decoding and output in Frame Packed 3D.Good to hear.
Quote:However I have some 720/50p H264 + 5.1 AC3 .wtv off-air recordings from DVB-S2 which now judder a little with both OMXPlayer and MMAL decoding if I disable pass-through and thus allow internal decoding to LPCM multichannel. This isn't specific to the Milhouse builds though - I've just reverted to a 5.0.6 OE release build and that also judders a little with passthrough disabled?Pi 2 I assume?
So you get judder with DTS-HD decode, no judder with DTS passthrough? With passthrough disabled and DTS-HD decode disabled judder too?
Can you post a sample file?
Quote:I guess I should raise this elsewhere as it's not Milhouse specific - but it is a pity as it means there is still a setting change required (or does the DTS-HD MA decode option override pass through and thus allow DTS-HD to be decoded, but DTS and DD to be passed, rather than the DTS core of a DTS HD signal being passed through in that combination of settings?)If passthrough is enabled, that takes priority.
RE: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) - noggin - 2015-03-29
(2015-03-29, 14:14)popcornmix Wrote:Yes - Pi 2.Quote:However I have some 720/50p H264 + 5.1 AC3 .wtv off-air recordings from DVB-S2 which now judder a little with both OMXPlayer and MMAL decoding if I disable pass-through and thus allow internal decoding to LPCM multichannel. This isn't specific to the Milhouse builds though - I've just reverted to a 5.0.6 OE release build and that also judders a little with passthrough disabled?Pi 2 I assume?
Quote:So you get judder with DTS-HD decode, no judder with DTS passthrough? With passthrough disabled and DTS-HD decode disabled judder too?
Sorry wasn't clear. Files have Dolby Digital audio. Until now I've run with pass through enabled and have no stutter. However with the DTS HD MA and Dolby True HD decode (but not passthrough) capability, I disabled passthrough as I thought this would be needed to force decoding. With passthrough disabled I get stutter on these files.
My secondary question is whether there would be scope for the following functionality :
DD/DTS audio present only - passthrough
DTS HD-MA/HRA / Dolby True HD audio present - decode to PCM (rather than passthrough the legacy cores/accompanying streams?)
i.e. would it be possible to have "Decode HD Audio if present, otherwise Passthrough" functionality?
Quote:Can you post a sample file?
Yes - what's the best way of cutting a .wtv file - the original is 10GB ?
Quote:Quote:I guess I should raise this elsewhere as it's not Milhouse specific - but it is a pity as it means there is still a setting change required (or does the DTS-HD MA decode option override pass through and thus allow DTS-HD to be decoded, but DTS and DD to be passed, rather than the DTS core of a DTS HD signal being passed through in that combination of settings?)If passthrough is enabled, that takes priority.
Yes - I guess my suggestion is that now we have HD Audio decode there is a scenario where you may want passthrough of audio formats that can be, but that DTS HD-MA/HRA and Dolby True HD could be treated like formats that can't be passed through (optionally) to allow them to be treated like FLAC and AAC are in passthrough mode (i.e. decoded to PCM)
There are still benefits to passthrough (particularly in Metadata and AVR processing terms)
RE: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) - Milhouse - 2015-03-29
(2015-03-29, 13:55)popcornmix Wrote: Seems to crash in hevcdsp_qpel_neon.S. Does reverting the "qpel" HEVC patch avoid the issue?
EDIT:
Actually "qpel" is already upstream. The "epel" patch is the only custom patch we have, so may be worth reverting that first.
I have four HEVC samples (Big Buck Bunny @ 720p/1080p, Singtel @ 720p/1080p). I've had crashes with all four files. I can play one or two files in a random order, stop playback, and then starting playback of a third file will crash Kodi (sometimes it may take a few more attempts to trigger the crash, but never more than 5). Sometimes the crash will happen when stopping playback.
I've gone back through the builds and they all crash eventually. The initial HEVC build #0227 and the updated #0304 both crash.
I test reverting the epel patch but as this was added in #0304, and #0227 also crashes, I have my doubts.
RE: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) - popcornmix - 2015-03-29
(2015-03-29, 14:35)noggin Wrote: Yes - I guess my suggestion is that now we have HD Audio decode there is a scenario where you may want passthrough of audio formats that can be, but that DTS HD-MA/HRA and Dolby True HD could be treated like formats that can't be passed through (optionally) to allow them to be treated like FLAC and AAC are in passthrough mode (i.e. decoded to PCM)
Unfortunately we don't know if audio is DTS or DTS-HD until we've opened the dcadeclib codec and fed it an audio packet.
It may be tricky to conditionally switch at that point.
Making the "DTS-HD" disable DTS passthough would be possible, but you can already do that yourself (enable AC3 passthrough and disable DTS passthough).
But really I'd like to resolve the stutter issue with AC3 with passthrough disabled first.
ffmpeg (or avconv) can be used to cut files from command line. Make sure you use "-vcodec copy -acodec copy" to avoid changing the audio/video encoding.
See here for syntax.
RE: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) - popcornmix - 2015-03-29
(2015-03-29, 14:36)Milhouse Wrote: I test reverting the epel patch but as this was added in #0304, and #0227 also crashes, I have my doubts.
If it's not the epel patch, then a nightly build on Windows/linux should have similar ffmpeg hevc code. Can you provoke a crash there?
RE: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) - noggin - 2015-03-29
(2015-03-29, 14:43)popcornmix Wrote: Making the "DTS-HD" disable DTS passthough would be possible, but you can already do that yourself (enable AC3 passthrough and disable DTS passthough).
But really I'd like to resolve the stutter issue with AC3 with passthrough disabled first.
ffmpeg (or avconv) can be used to cut files from command line. Make sure you use "-vcodec copy -acodec copy" to avoid changing the audio/video encoding.
See here for syntax.
OK - am happy with ffmpeg - just wasn't sure if -vcodec copy -acodec copy properly preserved the full file structure or remuxed.
Will cut some examples and check that the short versions also stutter.
** EDIT - have PMed you with clip link **