I'm trying different hard disk filesystems (NTFS, ext2/3, etc.) on an external HD that's used mainly to store video files for playback on a PC (using VLC) and on a flat-screen TV (using WDTV).
Though HD speed probably isn't the limiting factor in either scenario, I'd like to have as high a sequential read speed as possible. One of the programs I'd like to use to measure the disk read speed is iozone -- found at http://www.iozone.org/ -- but the setting of one of the test parameters, record size, has me stumped. If I understand this article -- http://www.cyberciti.biz/tips/linux-fil ... ozone.html -- correctly, I need to set the record size parameter to match the size or sizes of the data block that VLC reads from the video file it's playing.
So my question is, in what size 'chunks' does VLC read data from the disk? I can't imagine that it would be as low as 4k (since we are talking about relatively large file sizes), but I also wouldn't be surprised if it were different depending on the format/compression, display resolution, bits per pixel, and overall or average bit rate. But does anyone here know?
Thank you.
Sizes of data block input into VLC? (HD testing)
Re: Sizes of data block input into VLC? (HD testing)
OK, I found the VLC developer's site, scanned the documentation & wiki, and downloaded the source code. The documentation & wiki are pretty good and describe the code modules and data structures, but the code is rather complex and I'm afraid I am in over my head trying to code dive for my answer. 
Sigh. I ran a dumb sweep of record sizes (4K to 1024K) on iozone for a 4G file overnight, and as one might expect, random read rates scale up as the record size increases, though not perfectly linearly. The random read rate for a 4K record size was awful, less than 1Mbytes/sec, but the random read rate for a 1024K record size was close to the 'pure' buffered disk read rate of 23.8Mbytes/sec (as measured by hdparm). Of course, it's highly unlikely that a 4G video file would get fragmented into 4K pieces scattered randomly throughout the disk!
It's more reasonable to expect that records as small as 4K would be mostly in sequence on the disk, and the sequential read rate is indeed good, almost 18Mbytes/sec for the 4K record size test. But what's odd is that, for 512K and 1024K record sizes, the random read rates were measured to be significantly higher than the sequential read rates. That doesn't make sense to me.... I must be doing the test incorrectly.
Sigh. I ran a dumb sweep of record sizes (4K to 1024K) on iozone for a 4G file overnight, and as one might expect, random read rates scale up as the record size increases, though not perfectly linearly. The random read rate for a 4K record size was awful, less than 1Mbytes/sec, but the random read rate for a 1024K record size was close to the 'pure' buffered disk read rate of 23.8Mbytes/sec (as measured by hdparm). Of course, it's highly unlikely that a 4G video file would get fragmented into 4K pieces scattered randomly throughout the disk!
It's more reasonable to expect that records as small as 4K would be mostly in sequence on the disk, and the sequential read rate is indeed good, almost 18Mbytes/sec for the 4K record size test. But what's odd is that, for 512K and 1024K record sizes, the random read rates were measured to be significantly higher than the sequential read rates. That doesn't make sense to me.... I must be doing the test incorrectly.
Re: Sizes of data block input into VLC? (HD testing)
I contacted Don Capps, the developer of iozone, about what seemed to be the strange result that I saw with the random read rates exceeding the sequential read rates for large record sizes, and he gave me a very clear and logical explanation of what was going on:
I would appreciate any comments (but especially from someone familiar with the code).
He also gave be an excellent tip, to use strace to determine the transfer sizes of the applications I'm interested in.... unfortunately, I got invalid results using strace with VLC. strace reported the total number of bytes read by VLC as being smaller than the size of the test video file. (strace gave me reasonable results for the bytes read by other video players such as mplayer and totem.)If the random read location happen to overlap any previous random read, then some portion of the second random read could come from the cache.
I would appreciate any comments (but especially from someone familiar with the code).
Return to “General VLC media player Troubleshooting”
Who is online
Users browsing this forum: No registered users and 110 guests