2016-02-10, 03:12
The zero-copy change is a big improvement - particularly if sdram is overclocked! Many thanks @popcornmix and colleagues.
However I have found a couple of HEVC regressions (oddly enough, only with Big Buck Bunny 1080 and 720p, both .ts files (bbb_720p_c.ts and bbb_1080p_c.ts - download using "Save as..."). Tested over both smb:// and nfs://.
Config: RPi2, arm_freq=1000, core_freq=500, gpu_freq=400
First regression:
When playing HEVC Big Buck Bunny 1080p (.ts) with stock 450MHz sdram - which I know isn't really playable - playback will repeatedly restart at about 1m24s (although it sometimes varies a bit). Note that "Repeat" is off, so it's not stopping and restarting - it's just restarting...
However with sdram_freq=600 (over_voltage_sdram=5, sdram_schmoo=0x02000020), the same video plays without restarting (there is some minor slow down while zooming into the burrow at start, and villians emerging from grass at ~5m03s, otherwise it's pretty much perfect - total 15 skipped frames, 5 missed).
Maybe there's some memory-bottleneck induced playback error that causes the restart? The 720p version of Big Buck Bunny will play through to the end with sdram=450.
Debug log with 450MHz sdram: http://sprunge.us/GVPU (1080p playback restarted itself two times at timestamp 1m24s, then a third time at timestamp 1m26s)
Second regression:
With HEVC Big Buck Bunny 1080p OR Big Buck Bunny 720p, and with sdram_freq=450 or 600, any attempt to seek will restart playback from the beginning. All my other HEVC samples don't suffer from this seek/restart issue. I tested an mpeg2 ts - this had no seek issues.
Debug log with 600MHz sdram: http://sprunge.us/QEeV (seeking using BigStepForward - each time playback restarts)
Presumably these two regressions are linked somehow.
However I have found a couple of HEVC regressions (oddly enough, only with Big Buck Bunny 1080 and 720p, both .ts files (bbb_720p_c.ts and bbb_1080p_c.ts - download using "Save as..."). Tested over both smb:// and nfs://.
Config: RPi2, arm_freq=1000, core_freq=500, gpu_freq=400
First regression:
When playing HEVC Big Buck Bunny 1080p (.ts) with stock 450MHz sdram - which I know isn't really playable - playback will repeatedly restart at about 1m24s (although it sometimes varies a bit). Note that "Repeat" is off, so it's not stopping and restarting - it's just restarting...
However with sdram_freq=600 (over_voltage_sdram=5, sdram_schmoo=0x02000020), the same video plays without restarting (there is some minor slow down while zooming into the burrow at start, and villians emerging from grass at ~5m03s, otherwise it's pretty much perfect - total 15 skipped frames, 5 missed).
Maybe there's some memory-bottleneck induced playback error that causes the restart? The 720p version of Big Buck Bunny will play through to the end with sdram=450.
Debug log with 450MHz sdram: http://sprunge.us/GVPU (1080p playback restarted itself two times at timestamp 1m24s, then a third time at timestamp 1m26s)
Second regression:
With HEVC Big Buck Bunny 1080p OR Big Buck Bunny 720p, and with sdram_freq=450 or 600, any attempt to seek will restart playback from the beginning. All my other HEVC samples don't suffer from this seek/restart issue. I tested an mpeg2 ts - this had no seek issues.
Debug log with 600MHz sdram: http://sprunge.us/QEeV (seeking using BigStepForward - each time playback restarts)
Presumably these two regressions are linked somehow.