cTiVo
cTiVo copied to clipboard
mackworth
3.5 Beta Release...Universal Version
@mackworth for ffmpeg, have you considered using brew's bottles for it and lipo'ing them together?
https://formulae.brew.sh/api/bottle/ffmpeg.json
@larsenv Thanks; I did do a variant on that in order to protect the ability to run on older version of MacOS. See note below.
In the original release post, I mentioned:
After several days of fighting with build systems to get ffmpeg into the right shape, I'm disappointed to see it isn't operating quite as quickly as Handbrake. Considering Handbrake uses ffmpeg internally, I can only conclude they know how to build it better. Any one who wants to collaborate to improve my build of ffmpeg would be appreciated.
After further testing, I realized that despite the names I gave them, the internal-ffmpeg FormatDefault and the HandBrake Format HB Default are significantly different. To be specific, ffmpeg has the ability to trade off conversion speed and file size for a given level of quality. Near as I can tell, the HandBrake setting Apple 720p30 invokes ffmpeg with a -preset faster setting, resulting in about a 30% bigger file ( e.g. 1.3GB v 1.0GB). To more accurately compare, I created a custom Format with as close as I could come to HB settings using the Video Options string <<<INPUT>>> -vcodec h264 -profile:v high -level 3.1 -crf 21 -vf "yadif" -preset faster. Now ffmpeg came in 14% faster, with comparable file size and crf quality settings. As I'm sure there are other settings that I'm missing, such as scaling, I'm not saying the internal ffmpeg is faster than HandBrake, just that it's definitely in the same ballpark, so my initial concern was unwarranted.
Thank You for that, testing on a MacMini M1
Model Name: Mac mini Chip: Apple M1 Total Number of Cores: 8 (4 performance and 4 efficiency) Memory: 16 GB
Unfortunately it is still impossible to use GPU resources to re-code using HB CLI profiles. This results in 98% CPU levels for every pull down.
@mackworth cTiVo 3.5.0 seems to work perfectly fine on my 13-inch 2019 Intel MacBook Pro running macOS 12.0.1. It imports to the Apple TV app just fine.
Not much to say about it tbh, sorry, it works just like it did before.
@tdlivings is that true with the GUI as well?
@larsenv thanks for the report. No change is good to hear, except maybe … faster?
No, the cTiVo app is tight. It works very well. Even though it is bigger it runs very fast. More importantly, it doesn't cause the memory leaks some are reporting with other apps.
Just got an M1 Mini so been doing a bit of testing. cTiVo feels very quick and the numbers spank my 2018 6-core Mac mini across the board. For example, a test encode using Default ran in 114 seconds vs 220 seconds (just the encode portion). On the M1 using Handbrake, encoding using the hardware encoders is roughly twice as fast as using the software encoders.
However, with my 59.940 fps input file, the hardware encoders yielded a weird 59.732 fps output file that has an annoying flicker every few seconds. I tried forcing the frame rate with bit an -r 60 and -r 59.94 but it made no difference in the output file frame rate (according to Mediainfo). At similar bit rates, the subjective quality of the HW encoded files was noticeably worse (just like on the 2018).
I got a base (8GB/256GB) M1 as my "daily driver" (I have a M1 MBA for a few months and found it so much smoother to use than the Intel Mini but plan to continue to run cTiVo as a "server app" on the 64GB 2018 Mini so these tests were just for fun.
Edit: I think that the "annoying flicker" is actually in the source file (MPEG-4) rather than being added by the encoding. I see it in the game (I'm using 5' segment from an NBA game) but not the commercials.
Additional: I tried using Compressor to get some comparison output files but it dies a horrible death on the clip. The error is "RequestCVPixelBufferForFrame returned: 3 for absolute frame XXXX" which the Internet seems to think is a corrupted frame that Compressor can't handle. ffmpeg and Handbrake don't seem to be able to power through it.
Edit: Whoops. Strike that. fmpeg and Handbrake DO seem to be able to power through it.
@mackworth cTiVo works on my brand new M1 Pro MacBook Pro, however I'm not sure if the encoding's faster. Downloading has always been slow (which is out of your control), and encoding a ~200 second video takes at least 2 minutes.
Also, it gets stuck on "Wait SkipMode (Mark)" on this recording with Skip Mode that's marked with [?].
(Additional: I tried using Compressor to get some comparison output files but it dies a horrible death on the clip. The error is "RequestCVPixelBufferForFrame returned: 3 for absolute frame XXXX" which the Internet seems to think is a corrupted frame that Compressor can't handle. ffmpeg and Handbrake don't seem to be able to power through it.)
I have been trying compressor and I have it working fine. It recodes the downloaded decrypted TiVo file as usual and then adds it to the Apple TV app. My main problem in the past has been audio/video sync problem. So far so good. The only caveat is the video is added to the home movies directory as opposed to TiVo adding it to the TV show directory.
I duplicated "Add to TV Home Videos" and made some tweaks. Then I have compressor monitoring the series output folder and automatically recode and put into the media/tv shows/ABC World News folder. This is my test show. Looks good so far and the recode is using GPU resources primarily. I only wish I could remove the commercials and embed the close captioning as my daughter is deaf.
@larsenv: Depending on which preset you're using, that performance isn't bad. A 200-second video might be 110M(?), and I'm seeing about 60 MB/minute, which would be about 2 minutes. More generally, I'm seeing 40-60% of video time processing. (Note: that's total end-to-end throughput with downloading being done in parallel with prior downloads being encoded and captions/commercials, so not directly comparable, but in the same ballpark.)
stuck on "Wait SkipMode (Mark)" on this recording
That is correct behavior for some shows. If it "might" have SkipMode (on a channel with SkipMode, not news, a few other constraints), then cTiVo is willing to wait up to 6 hours to see if they ultimately arrive (I've see it take that long). If you want it to go ahead anyways, just uncheck the Skipmode box in the download table for that show. You should be able change that time using a terminal command: defaults write com.ctivo.ctivo WaitForSkipModeInfoTime 240 (admittedly untested).
@tannebil More info on @tdlivings compressor stuff here: https://github.com/mackworth/cTiVo/issues/398
@tdlivings I'm trying to remember: was there a reason we gave up on Compressor as a cTIVo Format? That would allow cTIVo to add the commercial skip and caption info after compressor finishes. Nonetheless, you can have cTiVo run captions during the download anyways, even with Decrypted TiVo Show Format. This will give you a parallel .SRT file your player may recognize automatically, or you should be able to patch into your MP4 file with Atomic Parsley.
The Home Video sorting can be manually fixed in TV app: select Show, Get Info, Options Tab, media Kind: TV Show.
Although I haven't tried this in years, I believe you can also set the mediaKind atom in the MP4 file with Atomic Parsley -stik "TV Show" or with MP4Tags -type tvshow
Yes, we gave up because of the ancient elements in compressor and how it was a barrier to building an error free TiVo preset. It just didn't want to play nice as a plug in.
Apple doesn't like captions. I can add them in final cut but it still doesn't hard code them into the file as a toggle-able unit like some other programs I have used before the 64-bit transition. Instead it outputs them as a separate file like the TiVo app.
For merging the subtitles into the file, you could use subler if you want GUI, or ffmpeg if you want scripting.
ffmpeg syntax is
/Applications/cTiVo.app/Contents/MacOS/ffmpeg -i "$infile.mp4" -i "$infile.srt" -c copy -c:s mov_text "$outfile.mp4"
That says "copy all the streams from the input file, then copy the text from the srt track".
BTW, you'll see a warning: Multiple -c, -codec, -acodec, -vcodec, -scodec or -dcodec options specified for stream 2, only the last option '-c:s mov_text' will be used. which can be ignored.
Subler can also mark the media kind as well. ffmpeg syntax is
/Applications/cTiVo.app/Contents/MacOS/ffmpeg -i "$infile.mp4"-c copy -metadata media_type=10 "$infile.mp4"
10 is for tv shows; 9 is for movies.
Combined would be:
/Applications/cTiVo.app/Contents/MacOS/ffmpeg -i "$infile.mp4"-i "$infile.srt" -c copy -metadata media_type=10 -c:s mov_text "$infile.mp4"
Has anyone tried varying the bit rate when doing a HW encode using ffmpeg? It just ignores the parameter when I try to do it but maybe I've screwed up the syntax? I've seen numerous posting says that -b:v should work.
<<<INPUT>>> -vcodec hevc_videotoolbox -vtag hvc1 -b:v 1200k -allow_sw 1 -profile:v main -vf "yadif,scale=w=floor(iw*min(1,min(1280/iw,720/ih))/2)*2:h=-2"
No matter what value I use for "-b:v", I get an output file with a video rate of 2069k. It happens on both my M1 Mini and my 2018 Mini (the output files are slightly smaller than on the M1 but -b:v similarly has no effect)
-b doesn't show as a parameter for the hevc_videotoolbox but I suspect that's because it's a global option for all the video codecs.
btanner@MM-M1 ~ % /applications/ctivo.app/contents/macos/ffmpeg -hide_banner -h encoder=hevc_videotoolbox
Encoder hevc_videotoolbox [VideoToolbox H.265 Encoder]:
General capabilities: delay hardware
Threading capabilities: none
Supported pixel formats: videotoolbox_vld nv12 yuv420p bgra p010le
hevc_videotoolbox AVOptions:
-profile
Update: It works OK with HB using the -b parameter. As I recall, HB uses ffmpeg under the covers so maybe something in the ffmpeg command line tool?
I am new here to GitHub and a love CTivo. I have been using 3.4.3 forever before I upgraded my iMac to the new-fangled M1 Chip with 12.0.1 mac OSx. Tryiign out this version. Im noticing now its taking FOREVER to encode. Noticed a slowdown for sure for encoding (download is fine) Is anyone else experiencing this? ... seems to chock an sit there for awhile.
@Paul4250 have you tried the 3.5 beta? Don’t be scared of the beta label. No known issues (beyond TiVo’s general download glitch problem that affects all versions).
Greetings!
Yes I have. I downloaded 3.5 this morning. I noticed the 3.5B crashed at 50% as it was encoding and started the entire process over again (it was only a test, so it didn’t matter too much). Just slow. I’m going to check on a work computer I have here at home that is running 10.14.6
From: Hugh Mackworth @.> Reply-To: mackworth/cTiVo @.> Date: Monday, February 14, 2022 at 12:29 PM To: mackworth/cTiVo @.> Cc: Paul4250 @.>, Mention @.***> Subject: Re: [mackworth/cTiVo] 3.5 Beta Release...Universal Version (Issue #469)
@Paul4250https://github.com/Paul4250 have you tried the 3.5 beta? Don’t be scared of the beta label. No known issues (beyond TiVo’s general download glitch problem that affects all versions).
— Reply to this email directly, view it on GitHubhttps://github.com/mackworth/cTiVo/issues/469#issuecomment-1039415848, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AXYOU465HUHGM3QED5YQUCTU3FCY5ANCNFSM5I53H22Q. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you were mentioned.Message ID: @.***>
@Paul4250 just noticed this response; my apologies. Is 3.5.0 still not working for you?