2012-08-28, 08:50
the only reason for a 4k less than 220" is that you are an idiot and like to show it off by buying stupidly expensive equipment, then brag about it in the belief your penis has grown.
2012-08-28, 09:26
2012-08-28, 14:09
You could spend the 10k in an enlargement? (of your screen of course)
2012-08-29, 11:04
2013-09-07, 17:00
(2012-08-28, 08:50)spiff Wrote: the only reason for a 4k less than 220" is that you are an idiot and like to show it off by buying stupidly expensive equipment, then brag about it in the belief your penis has grown.
4K content is noticeably better even on a 55". The difference is not as dramatic as a larger screen. But anyone would be able to tell the difference.
2013-10-03, 05:14
I thought I'd bump this and hoped I could maybe get an explanation on this issue. We can argue the benefits of 4K or not for a while, but I'd like to know why it's single threaded?
On XBMC 13 Alpha 1-8 on Windows, with an AMD GPU, with DXVA2 enabled, the automatic behaviours are as follows:
8bit 1080p h.264 = Uses DXVA
10bit 1080p h.264 = CPU, multi-threaded
8bit lossless 1080p h.264 - CPU, multi-threaded
8bit 4k h.264 = CPU, single threaded
I'm guessing that for some reason, XBMC is opting not to use the GPU for high resolution h.264, okay... But why is it opting to be single threaded while using CPU decoding? Is this just a technical oversight or is it the result of a more difficult issue?
On XBMC 13 Alpha 1-8 on Windows, with an AMD GPU, with DXVA2 enabled, the automatic behaviours are as follows:
8bit 1080p h.264 = Uses DXVA
10bit 1080p h.264 = CPU, multi-threaded
8bit lossless 1080p h.264 - CPU, multi-threaded
8bit 4k h.264 = CPU, single threaded
I'm guessing that for some reason, XBMC is opting not to use the GPU for high resolution h.264, okay... But why is it opting to be single threaded while using CPU decoding? Is this just a technical oversight or is it the result of a more difficult issue?
2013-10-04, 06:36
8bit lossless 1080p h.264 - CPU, multi-threaded
I highly doubt that. Without checking the code, iirc only hi10p is multithreaded.
I highly doubt that. Without checking the code, iirc only hi10p is multithreaded.
2013-10-05, 01:19
(2013-10-04, 06:36)wsnipex Wrote: 8bit lossless 1080p h.264 - CPU, multi-threaded
I highly doubt that. Without checking the code, iirc only hi10p is multithreaded.
You can doubt it all you want, I have it happening. I have some lossless h.264 8bit encodes, I'm a film student and uploading lossless h.264 with FLAC is the smallest way to upload lossless content to YouTube, allowing youtube's own lossy re-encode to be the only lossy pass, instead of you uploading a lossy version and then YouTube re-encoding it. Youtube's usage of FFMPEG allows this to work.
XBMC reports the video format being decoded as 'High 4:4:4 Predictive', which is a but funny since lossless h.264 is 4:2:0, but anyway. 50-%80% of the quad core CPU is engaged and no frames dropped. This is what I've gotten with all Gotham Alphas. on 12.2, it drops frames like crazy due to the lack of multithreading.
2013-10-05, 02:41
I don't know if that was intentional or not, but I'm guessing the same logic applies to both: no hardware decoder exists for either, so enabling multi-thread software decoding is safe. As for why it's only safe on codecs that are only software decoded, I do not know.
2013-10-05, 02:47
(2013-10-05, 02:41)Ned Scott Wrote: I don't know if that was intentional or not, but I'm guessing the same logic applies to both: no hardware decoder exists for either, so enabling multi-thread software decoding is safe. As for why it's only safe on codecs that are only software decoded, I do not know.
My question then would be: Why does XBMC fall from DXVA for my 4K files on it's own? Is there some sort of resolution limit in XBMC which makes it fall back to software decoding at a certain point?
Also, is there any reason why all CPU h.264 decoding shouldn't be multi-threaded? Is there a technical reason for this?
2013-10-05, 04:27
(2013-10-05, 02:47)DJ_Izumi Wrote:(2013-10-05, 02:41)Ned Scott Wrote: I don't know if that was intentional or not, but I'm guessing the same logic applies to both: no hardware decoder exists for either, so enabling multi-thread software decoding is safe. As for why it's only safe on codecs that are only software decoded, I do not know.
My question then would be: Why does XBMC fall from DXVA for my 4K files on it's own? Is there some sort of resolution limit in XBMC which makes it fall back to software decoding at a certain point?
Also, is there any reason why all CPU h.264 decoding shouldn't be multi-threaded? Is there a technical reason for this?
Because it's not safe for all flavors. We don't want XBMC to be crashing on random user content. Maybe in the future as more work is done but right now, it's not safe.
2013-10-05, 05:14
(2013-10-05, 04:27)davilla Wrote: Because it's not safe for all flavors. We don't want XBMC to be crashing on random user content. Maybe in the future as more work is done but right now, it's not safe.
Okay, well, then can you explain the following situation?
With DXVA disabled, 1080p 8bit h.264 is played multi-threaded. However, 4k 8bit h.264 is decoded single threaded. ...Why is it 'safe' for 1080p but not 4k?
2013-10-05, 09:34
AFAIK AMD GPUs can't handle 4k in their driver. Older AMD GPUs with legacy driver even crash and sometimes cause a bluescreen when you try to hw-decode anything larger than 2048x2048 (which is the max video resolution defined in the h264 standard, windows8 encoder/decoder is also limited to this). I have AMD GPUs with legacy driver and noticed those crashes/bluescreens when I tried to playback a FullSBS video. This was the reason why a resolution limit was added for DXVA some time ago. But this limit recently has been removed again because primarily nVidia cards can handle this - so there is atm no DXVA resolution limit anymore. If it fails to do HW-decoding in your case, blame AMD.
2013-10-05, 11:46
According H264 spec (Rec. ITU-T H.264 (01/2012) p301), max resolution for H264 L5.2 is [email protected]. So, H264 spec allow greater than 2048x2048.
