XPost: misc.phone.mobile.iphone, rec.photo.digital   
   From: mariasophia@comprehension.com   
      
   ...Winston wrote:   
   > problem with MOV and Live Photos is/was user induced.   
      
   For the benefit of others following along, I want to not get dragged into a   
   completely irrelevant personality contest in order to keep this PSA focused   
   on the technical side so readers can understand why two systems behaved   
   differently given this PSA is about how to fix Windows explorer being blind   
   to iPad sidecar MOV thumbnails.   
      
   The fundamental point of this PSA is to solve this compatibility issue.   
    "Windows Explorer cannot generate thumbnails for iPad Live Photo   
     sidecar .mov files without HEVC support."   
      
   For context, the original issue had nothing to do with IrfanView at all.   
      
   It began with Windows Explorer being unable to display thumbnails for the   
   .MOV sidecar files created by iPad Live Photos. The still image is a JPG   
   (or HEIF), but the motion clip is a short .MOV file that is usually   
   encoded in HEVC (H.265). Windows 10 cannot extract a thumbnail from an   
   HEVC-encoded MOV unless the system has a working HEVC decoder. Without   
   that decoder, Explorer shows only blank icons even though players like   
   MPC-BE can still play the file using their own internal codecs.   
      
   The fix was simply to install a modern thumbnail provider (Icaros, included   
   in the K-Lite Codec Pack), which registers a 32-bit HEVC-capable handler so   
   Explorer can finally decode a frame and display thumbnails for the MOV   
   sidecar files. This was and is the main focus of this helpful PSA.   
      
   Irfanview only came up as an offshoot to this PSA, which was a secondary   
   issue of playing the MOV files that are now thumbnailed by Icaros freeware.   
      
   Every setup can be different, where, in my case the QuickTime option in   
   IrfanView had been enabled years ago when QuickTime for Windows was still   
   common. IrfanView preserves its settings across upgrades, so once that   
   option is enabled it will keep trying to load QUICKTIME.DLL even if the DLL   
   is no longer present. That is what caused the failure on my system.   
      
   As I said many times, so there is no logical reason to dispute it:   
    Disabling the QuickTime option resolved the issue immediately.   
      
   That is not controversial and not unusual. It's not a riddle.   
   Many Windows systems have a long configuration history, and IrfanView does   
   not reset those settings automatically.   
      
   Winston's system did not have that option enabled, so IrfanView used   
   DirectShow from the start. That likely explains why his results were   
   different. Again, this is not a 'riddle'. It's expected behavior.   
      
   Regarding iTunes, I am not claiming that iTunes replaces DirectShow or   
   that it is required for playback. The point is simply that iTunes   
   installs Apple Application Support, Apple Mobile Device Support,   
   CoreMedia components, ImageIO, and other Apple-originated libraries.   
      
   These are not part of a stock Windows installation.   
   They're just not.   
      
   Their presence means Winston's system is not identical to a bare Windows   
   10/11 environment, and that difference is worth noting for readers who may   
   be testing on systems without any of those Apple components installed.   
      
   None of this is about blame. It is simply a matter of configuration   
   history. Two systems with different histories and different installed   
   components behaved differently, and both sets of observations are valid   
   for the systems on which they occurred.   
   --   
   Posting this clarification for others who may encounter similar behavior   
   on systems where IrfanView was configured years ago or where QuickTime   
   had once been installed.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)