Milovana.com

I have been collecting CHs for quite some time, and I try to get them in their original quality.
That inevitably led to a collection that ballooned over the years to over 500GB...

I've therefore decided to re-encode my collection, to near-perfect H265 re-encodings at 0.04 bits per pixel.
H265 decoding is HW-accelerated in most computers nowadays, and I will be selectively doing this only on videos that have been encoded very wastefully.

For example, the (beautifully made) Cock Hero Dreamgirls weighs in at 1.5GB, even though it lasts only 20min - a whopping 0.437 bits per pixel... My re-encoding (which is visually very hard to distinguish) is only 190MB.

So I'll be doing this - for now - to any of my CHs that crosses the "magic" 0.1 bpp threshold.

It will apparently take approximately a week to re-encode my entire collection (I am using a low-powered i5 to do it, don't judge)... But I've now scripted it to run automatically, so I don't care much about the time it will take - only for the breathing room it will give to my aging laptop.

Has any of you guys done anything similar? I know that space is dirt-cheap these days, but NVME space is still important for laptops - and getting my collection of 150-ish videos to an estimated 180GB (which even fits in a USB stick these days!) will surely feel nice.

When it's done I'll update this post with the sizes of my videos, in case anyone else needs a re-upload.

P.S. I wonder if I can set up an .onion site on Tor to permanently serve these from a raspberry PI - and how safe that would be... If any of you are technically inclined, feel free to share/pm.

milomanarian wrote: Sat Jul 29, 2023 8:23 pm P.S. I wonder if I can set up an .onion site on Tor to permanently serve these from a raspberry PI - and how safe that would be... If any of you are technically inclined, feel free to share/pm.

It's very possible, but Tor shouldn't be misused for sharing larger files. If you'd specifically want to host some site with your reencodes, it'd be smarter to just forward your ports and share it over the clearnet.

As fate would have it, this post

viewtopic.php?t=26350

...seems to provide an upload method to the archive - so no need to abuse Tor, indeed.
I will ask him if he is OK with it first.

Below, some preliminary results from the re-encoding taking place over the last 24h. Comparing with the originals, I can't see any difference in quality (tested with VLC and mpv) - and there is no loss of sync either.

1556146821 Day.out.mp4
661944290 Day.out.mkv

1513326474 Dreamgirls.mp4
190133503 Dreamgirls.mkv

3599341592 Edge.Sessions.mp4
1687761419 Edge.Sessions.mkv

4105530205 Fuck.Sanctum.mp4
1674509976 Fuck.Sanctum.mkv

2489593336 Hexed.mp4
1010955867 Hexed.mkv

6352524252 Inferno.Canto.3.mp4
2596902067 Inferno.Canto.3.mkv

3285184494 Lust.Nightmare.1.mp4
1306668082 Lust.Nightmare.1.mkv

2253134788 RLGL-Kimmy.Granger.mp4
884042937 RLGL-Kimmy.Granger.mkv

With these files alone, 25GB turned into 10GB

Re-encoding will continue during the week - will update with the complete list when it's done, and if rdmehd approves, I will upload the results in his Archive.

milomanarian wrote: Sat Jul 29, 2023 8:23 pm
I've therefore decided to re-encode my collection, to near-perfect H265 re-encodings at 0.04 bits per pixel.
H265 decoding is HW-accelerated in most computers nowadays, and I will be selectively doing this only on videos that have been encoded very wastefully.

For example, the (beautifully made) Cock Hero Dreamgirls weighs in at 1.5GB, even though it lasts only 20min - a whopping 0.437 bits per pixel... My re-encoding (which is visually very hard to distinguish) is only 190MB.

Are you using Handbrake?

milomanarian wrote: Sat Jul 29, 2023 8:23 pm When it's done I'll update this post with the sizes of my videos, in case anyone else needs a re-upload.

Why not just provide your settings so they can do the same on their own?

milomanarian wrote: Sat Jul 29, 2023 8:23 pm P.S. I wonder if I can set up an .onion site on Tor to permanently serve these from a raspberry PI - and how safe that would be... If any of you are technically inclined, feel free to share/pm.

Be careful doing this as some creators have asked not to repost their videos.

47dahc wrote: Sun Jul 30, 2023 7:22 pm Are you using Handbrake?

No. I am using my own hand-baked "recipe" of UNIX pipes being fed by video decoding engines, and in turn feeding encoder instances in dual-pass mode, via the slowest/HQ encoding settings.

Translation: this creates superb encodings, at 1/3rd - 1/10th the storage space of the originals.
The cost: lots of encoding time.

47dahc wrote: Sun Jul 30, 2023 7:22 pm Why not just provide your settings so they can do the same on their own?

The point of this is that you don't have to spend weeks re-encoding your collection like I do; no point redoing what I am doing and spending electricity over and over, while your computer's fans blow at max speed for weeks...

Also: the process is rather complex. It's not easy to explain what I am doing.

But I admit I had not considered this next point...

47dahc wrote: Sun Jul 30, 2023 7:22 pm Be careful doing this as some creators have asked not to repost their videos.

Perhaps I am violating Milovana's rules by proposing this.
If so, I admit I was unaware - I begun doing this for my own benefit (my laptop running out of storage) and realized this could have helped others as well.

If that is the case, I will indeed retract my proposal.

This would do wonders to my CH collection, mine is 1.69 TB.

Can you tell me how are you doing this?

mortimer wrote: Sun Jul 30, 2023 8:21 pm This would do wonders to my CH collection, mine is 1.69 TB.

Can you tell me how are you doing this?

I'll try.

Let's look at a very clear example: Dreamgirls, posted in Milovana here: viewtopic.php?t=20590 - a beautiful softcore CH that lasts 19:47, but has a size of 1513326474 bytes (1.5GB).

Is that a lot? Let's see.

We ask ffmpeg's magic machinery to give us insight into the file:

$ ffprobe Dreamgirls.mp4
...
Stream #0:1[0x2](eng): Video: h264 (High) (avc1 / 0x31637661), yuv420p(progressive), 1280x720 [SAR 1:1 DAR 16:9], 10059 kb/s, 25 fps, 25 tbr, 25 tbn (default)
Metadata:
creation_time : 2018-02-05T18:58:56.000000Z
handler_name : Video Media Handler
vendor_id : [0][0][0][0]
encoder : AVC Coding

What do we learn from this? We learn that this uses H264 (which is vastly inferior to H265) and that the frame sizes are 1280x720, at 25 frames per second. We also learn that we have 19x60 + 47 = 1187 seconds total, so at a double-pass encoding with 0.08 bits per pixel (which in my experience is a good value for H264) we'd expect the video information of this file to occupy this much space:

- 1187 seconds * 25 frames/second = 29675 frames
- For each frame, 1280 x 720 pixels = 921600 pixels
- So at 0.08 bits per pixel, a good video encoding with H264: 0.08 x 921600 x 29675 = 2187878400 bits
- Divide by 8 => 273484800 bytes, or, 273MB.

But our original is 1.6GB!

And why use H264? With H265, we can drop to 0.04 bits per pixel, and achieve visually identical results!

Don't take my word for it - here's my version of Dreamgirls, at a "whopping" 190133503 bytes (181MB).
Please import in your account before downloading:

https://mega.nz/file/3qBD3R5Z#EtKST47wF ... FUrrDYLTXA

Have a look with VLC or mpv, and judge for yourself if a reduction from 1.6GB to 180MB is acceptable or not - given the end result's quality. Personally, I find it hard to distinguish it from the original. Maybe if this was projected on a 50inch TV, and you were really, really close to the TV? Maybe.

But that's not the case for me - and I suspect for many Milovanians.

As a collector approaching 3 TB of Cock Hero content (big thanks to all the creators here!) I applaud the effort and willingness to share your methods and results. Like most things in life, video encoding is a game of compromises. Quality, file size, and player compatibility are all factors that a creator should consider. Some lack the technical knowledge to make good tradeoffs, while others spend hours checking the output of the encoder to ensure their quality standards are met. I see no harm in re-encoding their work for personal use, but they may take offense to publishing a re-encode that lowers the bar.

On a more technical note, bits per pixel is not an objective measurement of video quality. The number of bits required for a given frame of video is dependent on the complexity of the image and the frames that come before and after. The quality can vary widely at a given bits per pixel based on the information density of the content, both spatially and temporally. It is for this reason that most encoders recommend using a Constant Rate Factor rather than targeting a specific bitrate or file size. The encoder is already designed to minimize bits per pixel for a given level of perceived quality. I would be interested to see the resulting bits per pixel value at a given CRF for a variety of Cock Heros.

Personally, I always try to download the highest quality original from the creator. Any subsequent re-encode (and yes, even the "upscales" or AI processing) could add some visual coloring or introduce artifacts. We all know downloading from a streaming site will look worse because there is little care to the encoding settings or resulting quality. Streaming sites optimize for bitrate and cheapest/fastest encoding. I understand everyone has different priorities and more options are always better! I would suggest putting something in the filename to indicate re-encode and the settings used.

jtcrave69 wrote: Mon Jul 31, 2023 10:20 pm As a collector approaching 3 TB of Cock Hero content (big thanks to all the creators here!) I applaud the effort and willingness to share your methods and results. Like most things in life, video encoding is a game of compromises. Quality, file size, and player compatibility are all factors that a creator should consider. Some lack the technical knowledge to make good tradeoffs, while others spend hours checking the output of the encoder to ensure their quality standards are met. I see no harm in re-encoding their work for personal use, but they may take offense to publishing a re-encode that lowers the bar.
...
Personally, I always try to download the highest quality original from the creator. Any subsequent re-encode (and yes, even the "upscales" or AI processing) could add some visual coloring or introduce artifacts. We all know downloading from a streaming site will look worse because there is little care to the encoding settings or resulting quality. Streaming sites optimize for bitrate and cheapest/fastest encoding. I understand everyone has different priorities and more options are always better! I would suggest putting something in the filename to indicate re-encode and the settings used.

Well-said.
I'd indeed label them as "re-encodes" in rdhmed's Archive (he already OK-ed my request to upload my results).

jtcrave69 wrote: Mon Jul 31, 2023 10:20 pm On a more technical note, bits per pixel is not an objective measurement of video quality. The number of bits required for a given frame of video is dependent on the complexity of the image and the frames that come before and after. The quality can vary widely at a given bits per pixel based on the information density of the content, both spatially and temporally. It is for this reason that most encoders recommend using a Constant Rate Factor rather than targeting a specific bitrate or file size. The encoder is already designed to minimize bits per pixel for a given level of perceived quality. I would be interested to see the resulting bits per pixel value at a given CRF for a variety of Cock Heros.

Fair point. I too, collect the originals for that reason - but even though I can maintain the originals in an external USB drive, I do intend to keep only the re-encodes in my laptop.

Also, most CHs display sensual, slow-moving beautiful women. That means that we can afford to spend the bits we save from the easy-to-encode slow scenes that are on 80% of the production on the (usually at the end) rapidly switching ones. All 15 created so far by my re-encodes look amazing, at least as far as I'm concerned.

Here's a list of bits per pixel for the originals, BTW - I am currently re-encoding only those that are above 0.1bpp.

0.0740 : X-Change - Day 1.mp4
0.0700 : X-Change - Day 2.mp4
0.0760 : X-Change - Day 3.mp4
0.0120 : Obsession.mp4
0.0190 : A.Night.in.1999.mp4
0.0290 : Infinity.Xtra.1.mp4
0.0310 : Infinity.Xtra.2.mp4
0.0320 : Infinity.1.mp4
0.0320 : Infinity.2.mp4
0.0350 : In.a.dreamy.state.2.mp4
0.0350 : Infinity.Xtra.3.mp4
0.0360 : Edge.and.Ruin.challenge.by.xFah.mp4
0.0360 : Noodle.Dance.mp4
0.0380 : Infinity.3.mp4
0.0380 : Island.2.mp4
0.0390 : Island.1.mp4
0.0390 : Island.4.mp4
0.0400 : Crescendo.mp4
0.0400 : In.a.dreamy.state.3.mp4
0.0400 : In.a.dreamy.state.5.mp4
0.0400 : Island.3.mp4
0.0400 : Island.5.mp4
0.0440 : Omega.mp4
0.0440 : Stacy.vs.Sybil.mp4
0.0470 : In.a.dreamy.state.6.mp4
0.0480 : Island.6.mp4
0.0490 : Overplay.1.mp4
0.0520 : Dark.progression.mp4
0.0530 : Overdrive.2.mp4
0.0530 : Overdrive.3.mp4
0.0530 : Overdrive.4.mp4
0.0600 : Softcore.Collaboration.4.Part1.mp4
0.0610 : Softcore.Collaboration.4.Part2.mp4
0.0620 : Arcade.mp4
0.0620 : Halcyon.Daze.mp4
0.0630 : Dreamscape.5.DPL.mp4
0.0630 : RLGL-Michaela.Isizzu.mp4
0.0630 : Softcore.Collaboration.3.mp4
0.0640 : Erotic.delirium.mp4
0.0640 : Heavenly.1.mp4
0.0660 : Abundant.Asses.and.Bountiful.Boobs.AI.mp4
0.0660 : Symbol.of.Faith.1.mkv
0.0670 : In.a.dreamy.state.1.mp4
0.0670 : RLGL-Sabrisse.mp4
0.0690 : Mia.vs.Dani.mp4
0.0700 : Passion.2.mp4
0.0710 : RLGL-Lesbian.Lovers.mp4
0.0720 : Filthy.Cute-Edging.Mode.mp4
0.0720 : RLGL-Kasey.Chase.mp4
0.0730 : Descent.2.mp4
0.0730 : RLGL-Clover.mp4
0.0740 : RLGL-Guerlain.mp4
0.0770 : Heavenly.2.mp4
0.0770 : Melt.mp4
0.0770 : Royale-Casino.Royale.avi
0.0780 : Klinik.Industries-Vi22.mp4
0.0780 : Quickie-Kittens.and.Cream.mp4
0.0790 : Blueberry.Vortex.mp4
0.0790 : Emily.vs.Naomi.mp4
0.0790 : Intermarium.mp4
0.0800 : Royale-Tillandzia.Royale.Sidetracked.avi
0.0810 : RLGL-Uma.Jolie.mp4
0.0810 : Softcore.Collaboration.1.mp4
0.0830 : Royale-Battle.Royale.avi
0.0850 : In.The.Zone.mp4
0.0850 : Royale-Tillandzia.Royale.avi
0.0850 : Sex.mp4
0.0910 : Madness.3.mp4
0.0920 : Chaos.mp4
0.0920 : Pink.Complex.streaming.mp4
0.0940 : LustfulDesires_01_3.mp4
0.0950 : Primal.Glitch.mp4
0.0960 : Night.and.day.mp4
0.0970 : Flesh.mp4
0.0970 : Infected.mp4
0.0970 : World.Championships.3.mp4
0.0990 : Lust.Dream.mp4
0.1020 : Day.out.mp4
0.1020 : Edge.Sessions.mp4
0.1020 : Hexed.mp4
0.1030 : Fuck.Sanctum.mp4
0.1050 : RLGL-Kimmy.Granger.mp4
0.1060 : Lust.Nightmare.1.mp4
0.1070 : Inferno.Canto.3.mp4
0.1080 : Doom.mp4
0.1080 : Passion.1.mp4
0.1080 : RLGL-Nancy.mp4
0.1090 : Cum.Hero.Perfect.4.mp4
0.1090 : Sexy.Youtube.Long.mp4
0.1090 : Temptation.3.mp4
0.1090 : The.Long.Dark.Goon.mp4
0.1100 : 7.Deadly.Sins-Ep.1.Innocence.part.1.mp4
0.1110 : 7.Deadly.Sins-Ep.1.Innocence.part.2.mp4
0.1110 : Binary.State.mp4
0.1170 : French.Touch.mp4
0.1210 : Vulcan.AndreXHero.beatbar.edit.mp4
0.1220 : Evolution.mp4
0.1280 : Inferno.Canto.2.mp4
0.1300 : French.Riviera.mp4
0.1320 : Rhythms.of.Desire.v1.1.mp4
0.1340 : Freedom.mp4
0.1340 : Passion.3.mp4
0.1350 : Contract.mp4
0.1350 : Temptation.2.mp4
0.1350 : World.Championships.1.mp4
0.1360 : RLGL-Softcore.mp4
0.1380 : Groove.2.mp4
0.1400 : World.Championships.2.mp4
0.1410 : Chemical.Crush.mp4
0.1440 : Chroma.3.mp4
0.1510 : Heavenly.3.mp4
0.1600 : Versus.2023.mp4
0.1610 : Bright.Progression.mp4
0.1610 : Descent.1.mp4
0.1610 : Softcore.Collaboration.2.mp4
0.1620 : Perpedgual-Blowjobs.and.messy.wet.pussies.mp4
0.1620 : Perpedgual-Lesbians.and.Machines.mp4
0.1670 : Lust.Nightmare.2.mp4
0.1810 : Redemption.mp4
0.1830 : Earn.your.release.mp4
0.1840 : Inferno.Canto.1.mp4
0.1900 : Spectrum.mov
0.1920 : Dreamscape.2.Initiation.mp4
0.1920 : Dreamscape.4.Gentle.Pleasure.mp4
0.1920 : Dreamscape.5.Blissful.Immersion.mp4
0.1930 : Dreamscape.3.Ultimate.Seduction.mp4
0.1930 : Dreamscape.6.Teen.Dreams.mp4
0.1930 : Dreamscape.7.PureLove.mp4
0.1930 : Madness.2.mp4
0.1930 : Satisfaction.mp4
0.1930 : Suave.mp4
0.1940 : Melancholy.mp4
0.1990 : Duro.2.mp4
0.2060 : Overdrive.1.mp4
0.2110 : NOIR.mp4
0.2130 : Perfect.Girls.mp4
0.2140 : Strip.Softcore.mp4
0.2150 : Psytrance.4.mp4
0.2170 : Groove.1.mp4
0.2180 : Chroma.2.mov
0.2230 : Psytrance.1.avi
0.2260 : Audition.4.mp4
0.2270 : Girlfriends.mp4
0.2360 : Psytrance.2.avi
0.2400 : Klinik.Industries-Vi33a.mp4
0.2470 : Psytrance.3.avi
0.2800 : Chroma.1.mov
0.2810 : Symbol.of.Faith.2.mp4
0.2820 : Chroma.4.mp4
0.2840 : Champion.of.Cocknia.mp4
0.3010 : Klinik.Industries-Vi89.mp4
0.3070 : Fantasy.1.mp4
0.3140 : Fantasy.3.mov
0.3660 : Fantasy.2.mov
0.3670 : Madness.1.mp4
0.4370 : Dreamgirls.mp4

You can now see why I chose Dreamsgirls as an example: it is a very nice softcore CH, but it was the worst encoding of them all

Interesting stats! I can see what you're trying to do and you've put a lot of thought into this. I'm just not sure bits per pixel is a good metric for deciding what can be compressed further.

As an extreme example, imagine I upscaled a video from 1080p to 4k with a simple doubling of pixels in both directions. The resulting video will have 4 times the pixels, but no extra visual information. Even older codecs will compress the frames back down to the source 1080p detail. The bits per pixel calculation at 4k will look very good though, 1/4th the value of the exact same video at 1080p. The same could happen with framerate. If I simply double every frame to get from 30 fps to 60 fps, the bits per pixel value will be cut in half.

Let's single out Supermassive because I know he is particular about video quality and artistic intent:

0.0770 : Melt.mp4
0.0790 : Blueberry.Vortex.mp4
0.0850 : Sex.mp4
0.0920 : Chaos.mp4
0.0950 : Primal.Glitch.mp4
0.0970 : Flesh.mp4
0.1030 : Fuck.Sanctum.mp4
0.1090 : The.Long.Dark.Goon.mp4
0.1410 : Chemical.Crush.mp4
0.1610 : Bright.Progression.mp4

This is a wide range of bits per pixel for videos that are similar in quality and production. Given how meticulous Supermassive is, I can assume the extra bits in Bright Progression are necessary for his chosen presentation.

Dreamgirls is definitely an outlier, and your re-encode is impressive for the size savings! But on a 40" TV I can tell that fine details in the hair and clothes are lost. Even on a smaller screen, check the background girls in the red title frames, they look muted compared to the original. But it is certainly good enough and meets your goal to cram as much as you can into limited storage.

Here's a VMAF graph comparing your re-encode to the original. VMAF is designed to measure human perceptible quality differences. 95 is considered imperceptible. The average for the whole video is excellent at 94.8, but there are some dips below 90 that would be noticeable and helped by a higher bitrate.


Can you share your encoder settings? The big win is just going to H.265. If you're not too picky about the quality of the result, I would try a simple re-encode to H.265, slow preset with a CRF of 30. If the space savings aren't enough, try again with a higher CRF. Rule of thumb, +6 to CRF should cut the file size in half.

Once you're happy with a max CRF value, then you can encode without concern about target bitrate. Some videos will naturally compress more than others.

Then, get ready to repeat this whole exercise when AV1 is standard. I lost hours of my life trying to fit a 100+ DVD collection onto an 80 GB hard drive in the mid 2000s. xvid codec. All unwatchable now.

Aren't terabytes quite cheap nowadays? Of course, Mega seems to be the real limit.

jtcrave69 wrote: Tue Aug 01, 2023 7:07 am Interesting stats! I can see what you're trying to do and you've put a lot of thought into this.
...

Thank you for your insightful and excellent feedback - much appreciated.

Then again, the overall feedback (including some from an actual creator - thanks for chiming in, gynephilos!) does make me think again about all this. I know the process makes sense for my needs - and since I've written the scripts and they are chugging along fine (25 CHs re-encoded so far, and more than 40GB saved!) I'll definitely make use of the results on my laptop. In the end, I expect I will gain more than 200GB, which will give my 1TB NVME some very useful breathing room.

But my needs don't necessarily match with my fellow Milovanians; and there are indeed some creators that will rightfully get pissed with an amateur meddling with their art

Oh well. At least you guys now know it's possible to improve things - and Dreamgirls did get a nice re-encode as part of the process

Cheers to all, keep CH-ing!

jtcrave69 wrote: Tue Aug 01, 2023 7:07 am Interesting stats! I can see what you're trying to do and you've put a lot of thought into this. I'm just not sure bits per pixel is a good metric for deciding what can be compressed further.

I think this paragraph of this thread can't be overstated. Actually, the bits per pixel is completely trash metric in all use-cases except one: when you want to compare the performance of different compression alghoritms on one same exact video, but even then you can simply use (relative) size of resulting video.

Why? Because it does not relate to quality at all. You can encode pixels in many ways, but for video compression what you will find in many alghoritms is some way of describing pixel entropy only (so change of color or brightness). There might be encoding that saves rgb information of pixel, or it might be saving hue and brightness (that can also depend on what kind of scene is being compressed), but lets say you are faced with video that has 10 seconds of pure full hd (1920x1080) blackness. You could encode that with 24 bits for first pixel and then say you have 2073600 following pixels of same color (so all of them). That is 6 bits per second, and it comes out at around 2 milionth parts of bit per pixel for each second. And since video is all black, no other alghoritm will produce better results, even if you encode it with 0.04 bits per pixel you will not have any better image quality.
You can get it several orders of magnitude better if you also use third set of 3 bits to record for how many frames this repeats, bu that is not realistic here, such alghoritms are mostly used when video is split to small sections where there is high probability of one section being same over multiple frames.

On the other hand, if video contains a scene of moving fractals (which i.e. Blueberry Vortex does) you have movement on color (rgb or hue/brightness) axis, on spatial axis (they move x/y and they also grow or shrink), and they are very intricate, there are many small details that cannot be easily compressed with common video alghoritms, so forcing that to a certain bits per pixel value will result in huge deterioation of image quality. You will also have huge deterioation in sequences where there is fast movement of large area of video, or things like strobe lights and certain effects.

That is why something like CRF is light years better metric, since it correlates with perceived image quality, not with video size. Its change only correlates with resulting video size of same video compressed on different CRF, and that is only thing you can correlate to, since each video will have different content, and not all content can be uniformly compressed while retaining uniform quality.

The appeal of bits per pixel for this idea is that it collapses resolution, frame rate, and file size to a single value for comparison. As resolution and framerate scale, the bits per pixel will be constant for a desired quality level for a single type of video. This could be useful across videos in a certain genre or style - slow moving beach Cock Heros have one target range, while fast PMVs with lots of noise and transitions have another. Then, pick a cutoff you're comfortable with and squish any that are above it. With high quality 2 pass encoding, the result can still be very good since the bits per pixel value is an average over the video.

I would use bitrate for this case since it is more directly related to file size which is the limiting factor on the laptop. Also, the target device is known so I could find a bitrate that works well enough for the screen size and resolution. I don't know if you are resizing also but it is worth considering to squeeze more out of the storage space.

If the goal instead is to make the smallest possible file without losing any quality, then CRF is the way to go. I could see others appreciating H.265 re-encodes (or even AV1) that maintain the original quality (>95 average VMAF with no spikes below 93) at a smaller file size. Especially useful with limited network connections, Mega caps, and portable storage. I've considered doing that to my own collection but it's so much easier to just add more server storage and stream to limited devices, and I'm fortunate to have very fast internet.

Keep experimenting, this topic can bring out strong opinions and preferences, but there is a lot of room to improve and share with the community on this front!

I would like to add my 2c that carefully re-encoded H265 files would be really helpful for me as I explore this new CH world at Milovana. A lot of the files are surprisingly large and not the easiest to download on Mega, having them smaller would be handy. Of course I would go back and get the originals for any that I really like.

Obviously respect the author's wishes for re-encoding and re-uploading as applicable, and have the attribution and tags that it's a re-encode. I think opt out rather than opt in makes sense as per rdmehd's archive.

Anywhere I can have a look at re-encoded Dreamgirls? Mega link says "no longer available". Thanks!