XPost: alt.comp.os.windows-11   
   From: nospam@needed.invalid   
      
   On Sat, 3/1/2025 9:36 PM, Lawrence D'Oliveiro wrote:   
   > On Thu, 27 Feb 2025 13:27:15 -0500, Paul wrote:   
   >   
   >> I tried it. I named my sample file from the Internet   
   >>   
   >>    Nine.mp4   
   >>   
   >> and File Explorer says   
   >>   
   >>    File Type:  MP4   
   >>   
   >> That is because Windows "trusts" the file extension.   
   >>   
   >> If I remove the extension entirely, File Explorer says   
   >>   
   >>    File Type:  file   
   >>   
   >> so it hasn't a clue what it is then.   
   >   
   > I just tried a .ts file I happened to have handy, with the ffprobe command   
   > (part of the FFmpeg suite). Changing the extension to .mp4 made no   
   > difference, it was still able to show a summary of the streams (audio and   
   > video) in the file either way.   
   >   
   > Moral: I wouldn’t trust Microsoft’s attempts at multimedia handling as   
   far   
   > as I can throw them. Stick to something tried and true and developed by   
   > acknowledged experts, like FFmpeg.   
   >   
      
   You realize the gentleman is on limited bandwidth, and can't afford   
   to go crazy with the downloads. That's why we're giving a built-in,   
   in the machine, a try. The symptoms suggest, perhaps just the   
   packet payloads are encrypted, and some port of the materials   
   outside of that can be parsed.   
      
   I already made a post with details on the Gyan FFMPEG download   
   offering, so if the guy wants an FFMPEG.exe, it is available.   
      
   You can use ffprobe.exe and dump the interleaved frames of information   
   into a really big file, for examination. the compressibility of   
   the file, the entropy, might hint at encryption, but it's going to   
   be pretty close, because high quality video formats already   
   "look mostly random".   
      
      nine.ts     180,179,388 bytes   
      nine.ts.7z  160,030,696 bytes   88.8% of original, using 7Z Ultra   
      
   If the file sample does not compress that well,   
   it could be because it is encrypted. Only if the Transport Stream   
   was 100% encrypted, would it compress poorly enough to be noteworthy.   
   If just the payloads are encrypted, the file will still be compressible.   
   Just not down to 88.8% .   
      
   Dumping the .ts into a hex editor, there weren't a lot of landmarks   
   in there. The nine.ts sample had no 4CC codes. There was an occasional   
   burst of padding. And there was a tiny bit of text string suggesting   
   the short-form Guide Data for "what is up next on this channel".   
   That is all I could see in the sample I have here.   
      
   Our broadcast signals here (8VSB), don't use a lot of multiplexes.   
   I have one signal I can get on an antenna, which is a multiplex   
   of four, and the sub-channels would be SD. All the others are HD.   
   But I don't have a PVR, and I have a tuner card, and my tuner   
   card uses unencrypted .wtv for packaging (what is recorded to disk).   
      
      Paul   
      
   --- SoupGate-DOS v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)