Not sure about doing the 10bit encoding, but I've been converting less-important files after my conclusion tests (to CRF 32), and for those I'd say I'm fairly happy with the results. And on my gaming machine, getting 350fps encoding on SD and 80fps on HD files. (3.8Ghz, 16 core).

I'll try a real full movie as a friend has a new 4K Tv that they only use HD on for satellite. I don't remember if it supports AV1 when we looked at the manuals (though it hated DivX because of royalties, but overriding the tag to FourCC and they opened fine) and if it does I'd like to see how it performs.

Also tried doing Dingo Doodles, and can't seem to get a better size without going 60+, though it's still sharp the collaboration with Puffin Forest (16Mb test file, with the odd green logo) turned ugly for moments which i'm not quite happy with. Guess it's not as good for hand drawn lacking shading work.


edit: Dingo Doodles using x265 at 80-100kbit seems to look/work good. so there's that.

The idea is that with 8-bit color you will have more color banding and therefore require a higher bitrate to eliminate it. So if you are going for decent quality that can make the 10-bit version end up taking less space to get a good looking image.

What you are reporting sounds about right to me. For most of my blurays unless it's something I'm really particular about I use a CRF of 30 and when viewed via my projector it's totally fine. Maybe if I was in front of my computer and it was a movie I really wanted to preserve all the details for I might want to do 18 or maybe 20 like you said.

Makes sense. where 11/12 bit would probably be better, in that you want it wide enough to cover the width in possible differences.

Anyways, a couple encodes seems 10bit gets about 1-2.5% smaller. So there is that.

and ffplay does a good job on my chromebook even on full 1080, which is a surprise, i never really used ffprobe or ffplay before.

Are you using ffmpeg for your encoding testing (using AV1 of whatever)? If so, can you give some examples of complete ffmpeg commands, with all the used options?

Last time (two years ago or so) I experimented with those MPEG-2 videos I mentioned earlier, I wrote down I used e.g. something like this (I had extracted the video m2v and audio mp2 file from the original .rec MPEG-2 file earlier with ProjectX):

ffmpeg -y -i examplevideo.m2v -i examplevideo.mp2 -f mp4 -vcodec libx265 -acodec copy -preset veryslow -crf 17 examplevideo.mp4

Did you use something similar, only with different vcodec and crf values? Do you normally re-encode the audio too, or just copy the original (as there seems to be usually less space savings to be achieved from re-encoding the audio)?

I've also written down some much more longer commands with many more options, without really understanding why all the options are there, probably got them from some online discussion, as a good example which is supposed to give good end results.

I experimented with the intro of the movie "300" (that Spartan movie) with the rotating logo and the intro story with thunder etc. The rotating logo and the thunder revealed well how close to the original the encoding produced, e.g. I noticed that for some reason even high-quality encoding could easily make that thunder very blocky, like it was made of huge lego bricks.

It is basically exactly this part:

https://www.youtube.com/watch?v=x69ItQlDEHE

Especially at the scene where there is a thunder over the skulls, the thunder for some reason easily turned into legos, which is not what it was in the original MPEG-2 video. In that Youtube video that same "thunderskull" part seems fine though...

Not too different. But testing different crf types i used bash's commands in order to simplify it. So it would look more like:

#do several encodes
for X in 20 25 30 35 40 45 50; do ffmpeg -i test.mp4 -an -vcodec libsvtav1 -crf "$X" "test_$X.mp4"; done

The presets are obscure so i didn't use them (-1 to 13?). And the pix format i didn't override either in my original sets.

Afterwards use ffplay or drag the file to firefox to play and look over the video to see how it looked. Though the computer i'm on doesn't have full 1080 (due to older monitor), obvious blocking can still be noticed from the 1080 videos. Though most of the Youtube videos i used as sources i got in 480 or 720, so i could scrutinize better vs the rave.

edit: Found the preset options... a handful of the settings make sense, the rest doesn't.
https://gitlab.com/AOMediaCodec/SVT-AV1/-/blob/master/Docs/CommonQuestions.md#what-presets-do Guess i should probably do a stronger preset for background jobs then...

edit: okay so minor tests, 10 second sections.

Took an input that went from 2Mb to 1Mb using preset 10, while preset 5 took it to about 744k, and preset 3 took it to 637k. Preset 1 takes it to 623k. Very much diminishing returns going under 5.

So if i named them, then...
1 - Placebo
3 - veryslow
5 - Slow
7/8 - medium?
10 - fast
12 - ultrafast
13 - ?? (Says not for consumption, so maybe for tests or using as data for an additional passes?).

The default is assumed 8-10. and 9-12 is intended for streaming. So there's that...

Also, doing tests, and with the presets, the 'cartoons' that didn't compress. They look much better at preset 3 with low bitrate, even at 50kbit while 80kbit was the minimum on x265. Here i'd thought it wouldn't do well for Dingo Doodles or say JessJackDaw or others, but it is probably fine with the preset cranked up enough and targeting 50-60% of the original bitrate.

Alright, well learned a few new things for the svt-av1 codec. with keyint set higher than 2-3 seconds, a lot of space can be saved, and if you set a bitrate, lookahead to 120 frames will help too.

Curiously this looks like: -svtav1-params 'keyint=1000:lookahead=120'

Of course 1000 frames is about 33 seconds if 30fps, just means exact seeking is less likely but the space tradeoff is worth it in my mind.

Doubt there's much more to really get. Though on still image mp4's (like albums or snes mixes) 3kbit for video is sufficient (though i also did 1fps, so...)

Thanks for keep sharing your encoding adventure rtcvb32! :)
I have some questions if you dont mind,

Have you found accurate final size calculators?
Whats the source of all the codecs you are using? A pack? K-lite? Are free beer?
Whats the standard FPS nowadays? 30, 60 & maybe above?
Are NTSC (29.97) & PAL (25) still a thing?

Do those parameters kind-of rely on the the old divx concepts?

With keyframes as the baseline where compression happens:
From there, -only changes are saved-
for every following frame until the next keyframe
The perfect fit for "long standstill-esque" video sequences
for obvious reasons

And its drawbacks:
-The seek feature to the user (as you mentioned)
-The streaming cost, if the keyframe transmission fails,
the thing needs to be retransmited
(starting from the last OK keyframe)
A life saver here could be the decoder/vplayer logic,
giving priority to keep the business going
at the trade of a "broken picture" until the playback
reaches the next keyframe...
-Computing resources required to decode (Still apply on this GPU era?)
-The permanent loss of quality: Poor chances to restore the theoric original
-The distant the keyframes, the higher chance
of sound going terribly out of sync (My hell experience...
with uncompressed audio as the -only- maybe-exception)

So basically back to my dvd rip days,
I ended up using some default preset with multi pass
as the time needed to compress was the least of my concerns
(compared to the final video quality, cpu power to decode,
estimate accurate final filesize to fill the entire CD,
variable playback speed, true playability on the vplayers of my like,
seek, easily & correctly start playing at any given point,
ease to marry external subtitles, mux 2 audio tracks,
ease to use in containers mkv-ogg, aspect ratio...)
And honestly, I filed all those advanced/special parameters
& complexities to the -useful for (realtime) streaming-...

What are your comments on those drawbacks/concerns?

Thanks again & happy encoding!

If you're using a fixed bitrate, then yes, otherwise with CRF expect it to be wildly all over the place.
However it's safe to target/assume 10Mb a minute for HD content and less below that.

The codec is built into the Browser and using ffmpeg. So no clue. When i used DivX/Xvid in the past and x264 i used VirtualDub and a vfw build, then the only options included tuning options and speed. Without understanding what good bitrate decisions would be i'd often overshoot the bitrate by quite a bit.

Standard FPS i think is 30. 60 just looks janky to me, and it seems always will. Just makes my head hurt. Though that might be that the interpolation to fill in missing frames from 24 or 29 fps to 60 it has to do an odd speed conversion which has a skip or extra frame every X frames or seconds which just gets to me. If the Jankiness is gone, i don't see why 50 or 60 can't be the default. 60fps is fine for gaming however.

I'm sure they are both a thing, and have come across interlaced Blueray videos, which makes deinterlacing a pain unless you're using certain tools, i don't want to download huge tools so i'm not really using those unfortunately so i don't know.

Though NTSC interlacing was a workaround for limited bitrate back in the day, so why it would still be used today...

no clue. I'm heavily using the listed parameter list for svt-av1.

My main concern is space, if the video doesn't get corrupted then that's all great. Afterall i'm willing to do a quick recompress of a video or transcode a video over the network if the hardware can't manage it. The TV i have here seems like it can decode and play live AV1 at 720p, while 1080 it really struggles with.

As for resources to decode, hard to say. Youtube for example is already using AV1, although mostly on 360p and below, while above it stays with h264 unless you opt into AV1. Very soon likely AV1 will be the default, but right now a number of GPU's and hardware will be having AV1 decoding included as part of the core package. Probably give it 5-8 years (If the banking collapses today doesn't break everything).

As for recovering from corrupted frames, other than ECC of some description i'm not sure.

Yes, 2-pass encoding. When converting The Gamers and other videos to DVD for play at friend's places i would do 2 pass encoding too (Nero 6), which yielded superior video vs bitrate since it basically just made it a VBR knowing which sections were less needy in data, and ones that needed it more. I remember an encoding of ROD TV series where the rain in the anime made it so blocky and useless it was annoying, though everything else was beautiful, at least with standard bitrate.

Then It seems that problem persists

A different ballpark Im not familiar with, but interesting.
About codecs supported: That was basically the reason I quit the hobby,
a total discouraging mess when you add other electronics than PC
to the expectations (In my time: dvd players, tvs with usb ports, car stereos,
the few portable cheap Chinese players which Im thankful because
to my eyes those are the ones that pushed all this to the consumer devices industry...)
and I was sticking only to divx, xvid, mp3 & ac3

Exactly. That acnecdote reminds me I still had a chance
to try those early predicting parameters
I tried to convert a slide show presentation to a video (for logistics simplicity)
where the predictor thought was an excellent idea to -gradually transition-
the initial black background color of the starting slide to the white of next one
Was hilarious to watch it:
-That video was completely different to the original
-The codec was more worried to smooth that change color
that happily -affected everything else- like text!...
it gave a weird color to the text edges (to compensate?!) making it barely readable...
...And we are not talking here yet about resolution, aspect ratio, bitrate...
it was simply those novel codec parameters against me
Fun times! :)

So, it seems the duty is still an art where patience, trial & error are valuable virtues :)

Uh no, Youtube is using both h264 and VP9 since mostly a decade.
And AV1 is quite frequent for all resolutions in the latest ~5 years, even if it's still not consistent (sometimes videos are skipped) or could even happen after a month of delay.
I didn't know that creators had to opt-in tho O_o

Probably correct, but they're moving to AV1, likely due to royalty-free nature of AV1 and that it would better allow 4K content.

Pretty sure it's done on Google's side, and it's the user that has to opt-in, due to the extra processing power required at present. I've downloaded some videos and gotten the AV1 codec within a webm container from youtube. (Though the plugin doesn't tell me which codec...)

https://filmora.wondershare.com/youtube/av1-settings-on-youtube.html

I see but.. you seem to have missed this phrase of mine about AV1. O_o
"And AV1 is quite frequent for all resolutions in the latest ~5 years, even if it's still not consistent (sometimes videos are skipped) or could even happen after a month of delay. "
Anyway I'm using youtubedl (and its forks) since ages, so I'm quite aware of YT's formats and codecs :P

Well i suppose other updates of interest. First that there's an easy VBR option for AC3 you can use; To use this you use -q:a N, N being the value you want to preserve with.

For purely someone talking and not including music (so audio books, and most videos) 0.5 can work getting you close to 70kbit, 0.7 is about 128kbit, 1 is about 160kbit and so on.

When you go under 0.5 then it sounds like you suddenly switch to tape, and the audio quality is far lower (So unless you're ripping Vinyl records or old magnetic tapes, don't go under 0.5). I'm finding for non-music non-theatrical stuff, 0.7 really is about my favorite level for quality vs size. And for music I'd probably stick with 0.8-1, unless you're super big on quality levels.

Then we come to subtitles. I just had a VERY annoying time working with some old 2008 ogg media files, where subtitles are involved. It complains about no tag for the stream, unsupported codec, or in some cases a lack of a timestamp data. Trying to convert raw copy or anything results in it complaining. From what i can see, doing a raw convert to mkv first solves most of the issues (mp4 it complains about unsupported container codec, etc, so do mkv as a temporary before trying to recode): ffmpeg -i input.ogv -map 0 -c copy output.mkv

In the event of missing timestamps, prepending (before inputs) with -fflags +genpts will resolve the timestamp issues from what i've seen. ie: ffmpeg -fflags +genpts -i input.ogv -map 0 -c copy output.mkv


Though problems I'm currently having involve trying to transfer subtitles from one file to another. Oh sure i can transfer them, but the length timing and even content is the same (one has a better encoding for video) and the timing is borked and I'm not sure how to fix it. 10 minutes in skipping forward and the timing is off like 1.5-2 seconds. Subtitles contain time offsets (mm:ss.ms) not exact frame offset, so this shouldn't be an issue, and yet i can't figure it out.

There is subtitle software that can shift the time of all subtitles (if each subtitle needs a uniform adjustment). There's even online tools that will do this.

Which i'll likely have to look into. Still the timing of the two videos is identical in length and no extra stuff, so i don't see why the timing is off. And ffmpeg can adjust the time for the subtitles easily enough.

hmmm actually looking at it, finding a key frame later on is 2.5-3 seconds difference... The gap isn't seeming enough for the 24 vs 23.976 framerate difference.