OFark

Members
  • Content Count

    107
  • Joined

  • Last visited

Community Reputation

10 Good

About OFark

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hi, First off we need to check to see if the docker containers can see each other: Console to the Compressarr app and type the following in to install curl: apt-get install curl then once that's done type curl and then the url to Radarr/Sonarr so, and I'm guessing here but it looks like your might be: curl 192.168.1.50:7878/radarr This isn't going to work, because you'll need to authenticate, but it should return some HTML with an error message in it, rather than nothing or a "Could not resolve host" or a "Failed to connect to..." e
  2. Today Docker stopped supporting automated builds for free accounts. Apologies for any issues there may have been during a shift to Github action builds.
  3. And thank you for not giving up and helping me make improvements.
  4. No, the container is called Matroska. It's one of the most difficult things to wrap; Containers are ways of containing the data, but can have multiple extensions. And an extension could belong to different containers. So to get round that I have to ask for what container you want to use and then pick the first appropriate file extension. FFmpeg normally has the file extension as the name of the container, but not for Matroska, just to be difficult, it lists it as the full name.
  5. No worries, I have just pushed a new version that will allow you to choose if you want to copy subtitles or not, plus other data, attachments, metadata, as well as pick a different subtitle encoder. Note on that: be sure about the source files, FFmpeg cannot encode Text to bitmap or visa versa. If you are going to choose a subtitle encoder make sure all your source files can be encoded. Otherwise just choose copy.
  6. I've just pushed a version that should fix the fixed Frame rate issue in a two pass scenario.
  7. So that error: [mp4 @ 0x55572bad8e80] track 1: codec frame size is not set [mp4 @ 0x55572bad8e80] Could not find tag for codec subrip in stream #3, codec not currently supported in container Isn't a problem I can fix. That's basically saying that the file type you've chosen (MP4) doesn't support the subtitle coming from the source. The original file is a Matroska MKV container, and MKV supports a lot more than MP4 does, although MP4 is supported more on older devices, MKV is a lot more universal. I'll do some research into how I can better manage Subtitle
  8. Does it work with a Same as source option?
  9. 8kbits vs 8mbps. Yes I see that confusion. FFmpeg defaults to kbits, hence why I'm using that. I'll make that a bit clearer in the next release. X265, basically, creates the same quality video with less data, because it's using more compressible B-Frames. Which is a massivly over simplified answer, but still valid. FFmpeg is throwing an error: x265 [error]: fps mismatch with 1st pass (1199/50 vs 24/1) [libx265 @ 0x55ecbd2ee900] Cannot open libx265 encoder. 1199/50 is sooooo close to 24/1, but not quite. I'll see what I can do about that but in the mean ti
  10. Ok found it, probably too tired for this but I found it. When using an encoder that doesn't have the pass number built into specific options it wasn't passing through the fact that the first pass was indeed the first pass and no log file was being generated. X265 doesn't have this issue, and I was mostly using that for testing. Ok I guess I must have only been using that for testing, I missed it. So I've fixed it, Docker is currently building it. I'm no expert but countless hours of testing has given me enough experience to offer this advice: 8kbit/s is no whe
  11. Hi, Thanks for the feedback. The encFile.mp4 is created when it encodes the sample. So the sample.mkv is a short sample of the original video and the encfile.mp4 is the result of, or is supposed to be the result of, a test encode with FFmpeg. I assume, as you didn't mention it, there are no FFmpeg errors mentioned in the log? A week or so ago I released a version that should have stepped over any issues creating samples, but it looks like it's falling over in the right place, so to speak. So that error line matches current code base. Honestly I'm surprised it got that f
  12. Well then from what I've seen it does indeed look like Handbrake isn't using QSV, but I know it works, I've done it myself. What CPU are you running it on?
  13. What encoder are you using in Handbrake?
  14. Have you passed /dev/dri to both? I use QSV in Handbrake just fine.
  15. Well it seems like it's not doing anything hardware. Hardware decoding is next to pointless these days. Very little if any benefit from hardware decoding. Hardware encoding should be eating up quite a bit of GPU resources, but then the quality is never going to be as good as CPU encoding, so I'd leave it as it is.