• 0 Posts
  • 175 Comments
Joined 11 months ago
cake
Cake day: December 29th, 2023

help-circle



  • 2 pass will encode a file once, and store a log of information about what it did… then on the 2nd pass it’ll use that information to better know when it should use more or less bitrate/keyframes - honestly i’m not too sure of the specifics here

    now, it’s most often used to keep a file to a particular file size rather than increasing quality per se, but id say keeping a file to a particular size means you’re using the space that you have effectively

    looks like with ffmpeg you do need to run it twice - there’s a log option

    i mostly export from davinci resolve so i’m not too well versed in ffmpeg flags etc

    doing a little more reading it seems the consensus is that spending more time on encoding (ie a higher preset) will likely give a better outcome than 2 pass unless you REALLY care about file size (like the file MUST be less than, but as close to 100mb)


  • if you’re planning on editing it, you can record in a very high bitrate and re-encode after the fact… yes, re-encoding looses some quality, however you’re likely to end up with a far better video if you record and 2x the h264 bitrate and then re-encode to your final h265 (or av1) bitrate than if you just record straight to h264 at your final bitrate

    another note on this: lots of streaming stuff will say to use CBR (constant bitrate), which is true for streaming, however i think probably for re-encode VBR (variable bitrate) with multi-pass encode will give a good trade-off - CBR for live because the encoding software can’t predict what’s coming up, but when you have a known video it can change bitrate up and down because it knows when it’ll need higher bitrate










  • expanding on this, depending on technical skill level:

    i’d probably get some SBCs like raspberry pi (or cheaper; raspberry pi is probably overkill here!) to be the terminals, run asterisk and have an extension for each terminal… run a voip client that automatically picks up any call it receives, and connects to a mic & speaker, connect a button to GPIO and write a script to call a conference extension for all devices (or multiple buttons for multiple extensions to call individual locations)… i’d probably add a second button for a “call back”-like feature - a terminal broadcasts a message and there’s a button to reply only to the terminal the last call was from

    this would allow you to use phones as terminals too - even receiving “calls”, although in that case the caller would have to wait for the phone user to pick up - just like a regular phone. probably more useful as a transmitter

    all of these things aren’t super difficult in isolation - probably setting up asterisk is the hardest part


  • one of the benefits of using a packet switched solution is that it’s expandable in the future… adding extra terminals anywhere there’s networking is pretty powerful - you can change your mind about location, or even technology in general and not have to worry

    … and it’s probably much easier to extend on in the future too - say open source AI assistants get better, you might want to build one that integrates with timers etc, that’s much easier with packet switched … or even more likely, you want to broadcast to the intercom from outside your house or even just make mobile phones able to be transmitters inside the house

    you’re totally right that simple point to point intercom stuff like that is a much simpler solution, but packet switched is king for a lot of future-proofing reasons - perhaps not something that OP cares about (a project completed is better than a perfect plan not begun), but worth mentioning