[–] [S] 3 points 1 month ago

That's crazy, because I was in the very same situation a few weeks ago. A friend wanted some stuff and they specifically wanted to be able to simply play it from the USB stick on their TV. I anticipated compatibility issues, so I made sure to grab mp4 copies from the start. It worked. :D

  • source
  • parent
  • context
  • [–] [S] 2 points 1 month ago (1 child)

    Thanks! For some reason on Linux, I can (in some cases) "simply" rename the file with a different extension name. Would that be sufficient to do on the recipient's device, or would I need to process it more "properly" with ffmpeg (which I am using, by the way)?

  • source
  • parent
  • context
  • [–] 5 points 1 month ago (2 children)

    This is the best answer. MKV is just a container. It’s the codec that will matter the most. As mentioned H264 is going to be the most ubiquitous. Even if you were to try to do MP4 it’s still dependent on the codec. You could do an MKV with MPEG Layer 2, but that’s starting to become too old as well. Also for H264, the RF plays a big part too. Go for something higher like 22-24. It’ll make for a slightly larger file, but you’ll great quality without being a raw file size. Too low and you’ll end up with a potato.

    As for audio, also stick with a safe codec like MP3. Using WAV is too large, AAC is limited as are some others as well.

  • source
  • parent
  • context
  • [–] 3 points 1 month ago (1 child)

    anecdata - I recently sent a usb full of .mkvs to a buddy and they all came up unplayable on his TV. I converted them to mp4 and he was fine.

  • source
  • [–] 5 points 1 month ago (1 child)

    When I digitize stuff I used MKV because it was a format that was resilient to whatever program that created it crashing in the middle of creation. Mkv is segmented and doesn't need anything to be written about the entire file. It's just small sections kind of stitched together. In my opinion this is what you should digitize to initially and then if you need other codecs then transcode later.

  • source
  • [–] 2 points 1 month ago* (2 children)

    Edit: I didn't read properly... You're doing this for other people. Maybe you should go with the conservative option, then.

    (I mean if their devices already support it, there's no harm in forgoing compatibility and just go with a more modern encoding format like HEVC or better AV1. It's not like the next laptop or TV will be unable to play it... But H264 is certainly a safe bet. That's supported everywhere.)

    Also second the point about the container. It doesn't really matter, just go with mkv. In the unlikely case it doesn't work, you can always take the video an put it in a different container. That kind of conversion is fast and without loss.

  • source
  • parent
  • context
  • [–] 5 points 1 month ago (3 children)

    I'm not an expert but MKV should be ubiquitous enough to please most people. You can tell reluctant people to install VLC and it should work with any codec.

    I download most movies who are encoded in MP5/x265/whatever265 because it saves space, but MP4 could be better for people who only have iPhones or old TVs.

  • source
  • [–] 8 points 1 month ago* (8 children)

    Pretty sure every remotely modern device can open a .mkv container. It's much more important which video codec you used for the video inside the container, that's what will cause the compatibility issues. You want to use h264 for maximum compatibility (but at the expense of taking up more storage).

  • source
  • [–] [S] 4 points 1 month ago* (2 children)

    Thanks! I always keep the raws, unless they explicitly ask me to delete them. My question is rather about which re-encoded/target container would be easiest to use for my colleagues and potential customers from a compatibility perspective.

  • source
  • parent
  • context
  • [–] 2 points 1 month ago

    The method to reset the BIOS password varies heavily by model. It's an Acer, so by definition it's consumer-grade, and doesn't have the higher security options of enterprise gear. Being so old (2012 or so, based on another comment, meaning ca. 3rd Gen Intel Core) works in your favor as well.

    Start by googling for the model and "reset BIOS password". You might also look for similar/related models that would have the same method. Make sure you exhaust this thoroughly, because the next steps are rougher.

    Next up, find forums like BIOS Mods and Bad Caps that specialize in BIOS needs. You may need to pay for a subscription, and it may get very intricate. And it may not even help.

    Finally, you can find professional repair shops like Black Horse Repair. This will involve real money, probably more than it's worth. Make sure they have a plan before you send it in.

  • source
  • [–] [S] 1 point 1 month ago

    Thank you for the idea, I’ll try your idea! And I’ll try updating you and the topic, incase anyone else has a similar problem and wants to know. Blocking it now!

    And, apologies for getting back 4 days late, the heatwave here in LA made recovery and staying cool a nightmare lol. 🫠

  • source
  • parent
  • context
  • [–] [S] 2 points 1 month ago (1 child)

    Thanks, I have tried this but unfortunately it doesn't give you a code, instead saying that the "system will halt" after I've tried the password 3 times and becomes unresponsive. I think this is because it's a UEFI - probably should have included that in my original post.

  • source
  • parent
  • context
  • [–] [S] 3 points 1 month ago

    Thanks, I can confirm that it is a UEFI. It's about 13.5 years old so it's not super ancient. I downloaded a UEFI driver from a third party site to take it from v2.14 to v2.21. I haven't actually confirmed that it installed correctly so I will do that later. Acer requires you to input any one of three identifying numbers in order to give you this driver update but even after downloading their tool to get accurate system information, it refuses to recognise the information I've copy-pasted from their own tool. It's not very user friendly.

  • source
  • parent
  • context
  • view more: ‹ prev next ›