"Encoded successfully" msg even though encode failed

[loungebob]

This file keeps failing on me. Output window says because of a memory issue. No wonder, fastflix uses like 16GB during initial conversion before it fails. But I'll dig into this file a bit more later.

I think it should not proclaim a successful encode when it fact, it failed :-)

[cdgriffith]

Hi @loungebob That issue should have been fixed in 3.3.0, looks like you are possibly on an older version. I'd suggest grabbing the latest.

The memory thing itself is interesting, could you give the output of the generated command? (Fine to remove paths to files) Before we have seen this with overlay filter for subtitles but I think you are using an earlier version that doesn't have those, so must be something else.

[loungebob]

Says starting 3.3.1 but I see I'm still way behind. I'll upgrade now and see what happens.

[loungebob]

Also, the blue spinny windows cursor thingy keeps blue and spinning all the time when hovering over the FastFlix window. It did not use to do that. However, while this normally means windows is busy and the active window cant be used, I can still change settings in FF but with the annoying blue spinny thing instead of a normal cursor. Nothing wild, just thought I'd mention it.

Aaand, the file in question is a 10bit SDR not HDR file. I'm a bit unsure if I need to change settings accordingly. Can I still use main10 profile? I left all the other settings like with a normal HDR encode but I see there's new stuff in 3.4.2 like the Force HDR10 signaling ticked active, should I untick that for SDR?

[cdgriffith]

Thanks for the heads up about the cursor, that's a bug.

You can use main10 for SDR videos just fine, correct. It will not be changed over from bt.709 to bt.2020, so behind the scenes FastFlix automatically disabled the HDR options that may be checked there. (Haven't gotten it so the GUI itself grays those out for non-HDR videos).

Also if it says starting 3.3.1 and getting memory error, check and see if you have subtitle track that is being "Burn In"ed. (No clue why it would say it was successful then, will give that code another look over)

[loungebob]

using 3.4.2 now. encode still fails. there’s errors saying it could not map the DTSHDMA stream and it’ll guess. It’s a mono stream, not much to map :-) also, there’s an error saying that some filters dont support changing frame size during the encode but as far as I can see, the frame size stays constant. Ultimately it fails again because of the memory allocation issue. I’ve never had that with a file before. And as far as burned-in subs are concerned, I think I would have to define that manually if this is supposed to happen, wouldnt I? All subs in the original mkv look normal to me. Who does hardcoded subs anyway? That’s what forced ones are for.

![Uploading 0BEFCBA6-F40E-487E-A227-9D79BC5A1C49.png…]()

[loungebob]

![Uploading 1364BD26-6EB2-4C41-8599-99F0CEDAE773.png…]()

[cdgriffith]

Not sure why but the images aren't showing yet, they just say "Uploading" so can't see them yet. Very curious why it can't map a audio stream.

For the subtitles, as of 3.2.1 FastFlix will automatically mark the first forced / default subtitle track to "Burn In" (aka overlay). It's the standard in the world of UHD due to the fact image based subtitles are becoming the norm. Which means that plex or other media players would have to transcode them while playing if they weren't overlayed. Most systems can't handle a realtime 4K encode, and on top of that Plex and other players don't yet support HDR, so it incorrectly cuts off 10bit videos in bt.2020 colorspace into 8-bit bt.709 videos, so they look terrible. Can always uncheck it in the Subtitles tab.

The message about filters don't support changing frame size is probably the "overlay" filter for the subtitles. I see that when the subtitle image files are in like 1080 but the film is in 4K.

[loungebob]

Cant see them either. Up from phone, dont know if it’s me or github. They’re not important. Basically screens of the errors.

I get this now when loading the file

QObject::connect: Cannot queue arguments of type 'QTextCursor' (Make sure 'QTextCursor' is registered using qRegisterMetaType().)

Also, what? I was under the impression burn-in means the sub is rendered into the picture and becomes ineditable. No one ever should want that. Is that what happened to my other encodes? Nooooo. Let’s hope we understand burn-in differently.

I disabled the burn-in and it looks like it’s going ok now.

[loungebob]

Oh thank heavens it didnt burn-in (hardcode) any of the subs in any of the earlier encodes yay!

[cdgriffith]

You understand it correctly. And you're right, that should at least be an option in settings to disable that behavior. Glad it didn't mess your stuff up!

[loungebob]

I canceled the encode for now. It estimated the final size at 90GB, more than 2x the original size. Maybe it’s the SDR messing it up?

I have a massive aversion to burning anything into the picture. Way back in DVD times and when subs were a mess standards wise I barely understood a burn-in but nowadays, it just destroys the whole idea of archiving and best possible picture quality. For alien speak and foreign parts there’s forced subs that can be enabled and disabled in the player and - I dont use it so it’s hard to judge - if PLEX and Co cant handle subs efficiently, maybe they need to be nudged.

[loungebob]

Glad it didn't mess your stuff up!

Me too! 😂

[cdgriffith]

3.4.3 should have a few concerns addressed 😄

Adds a warning message about the subtitles and gives a way in settings to disable that behavior all together. Also disabled the cursor changing to a spinning icon since apparently there are cases that it doesn't switch back.

[loungebob]

I canceled the encode for now. It estimated the final size at 90GB, more than 2x the original size. Maybe it’s the SDR messing it up?>

Any idea what this might be? In the last 10 encodes the closest I got was about 90% of the source material and I guess that's because the source was already heavily compressed. But twice the original? And I checked the original is a remastered version, very nicely I might add, not too much DNR but also not confetti central. It should compress nicely.

[loungebob]

3.4.3 should have a few concerns addressed 😄

Adds a warning message about the subtitles and gives a way in settings to disable that behavior all together. Also disabled the cursor changing to a spinning icon since apparently there are cases that it doesn't switch back.

I'll check it out tonight!

[cdgriffith]

What settings are you using for those large encodes? My guess is CRF + preset combo is set to high for them.

Do you do any VMAF / PNSR compare from source to final?

[loungebob]

yuck you made me read up on VMAF / PNSR. more stuff! I have eyes, they know if the quality is good. although, they tend to be confused. maybe I'm getting old. anyway, I'll check the VMAF / PNSR values on the file asap.

I almost always use CRF 13 to compensate for using the fast preset. works just fine on all the other encodes.

[cdgriffith]

x265's CRF mode is extremely source dependent for it's QP guesswork estimation of quality, so can vary wildly. I honestly wish there was a way to set it with min / max bitrate values.

VMAF / PNSR can just help make sure not setting CRF needlessly high. Re-encoding is really only good for reducing file size, video transformation or device compatibility. I'm guessing you're after the first so would reduce CRF until VMAF (or your eyes 😉 ) shows a noticeable dip and choose one higher.

[loungebob]

FFMetrics wont run that file (some complex filters error) and the other App/GUI does run but needs to decompress the source file first and you cant define just parts of the file to be run one needs to run the whole file. And I cant be bothered with command line tools. So I decided to just not archive that version of that movie. I can live with that ;-)