Has anyone ever tried encoding a video by splitting it into parts

>>58612124
hey thats my gf your posting

>>58612151
Tell your """gf""" to stop posting pics of herself on the internet.

>>58612124
>tfw this is a gravure idol with the body of an oppai loli

>>58612124
>Has anyone ever tried encoding a video by splitting it into parts and using different crf values then muxing the result back into 1 file?
yes
>Was it worth the extra trouble?
no

File: xvid1-zones.gif (2KB, 308x151px) Image search: [Google]

2KB, 308x151px

You're talking about zones, and it was really popular in the XviD days to make stuff fit on CDR. You'd generally compress the hell out of credits to make more room everything else. Totally worth it if you're hurting for space.

>>58612272
Any experience with it in h.264?

>>58612290
why not just try it? are you just not sure you need it, or do you not know how to do it?

>>58612357
Laziness really. The video I wanna do this on has a lot of action scenes and stills, so I'd rather ask about other's experiences with it.
But yeah I'm probably gonna end up just trying it regardless.

>>58612427
>The video I wanna do this on has a lot of action scenes and stills
that doesn't really tell me much

CRF used normally will use more bits for a fast action scene and less bits on slow scenes

it's probably why nobody bothers with things like >>58612272
anymore, credits tend to be relatively easy to encode, and so modern codecs in CRF mode will yield very low bitrate credits without needing to do anything special

not to mention getting a watchable movie onto a cd with xvid was just generally a challenge, the quality was so minimal that any little thing potentially made a visible difference

>>58612476
>CRF used normally will use more bits for a fast action scene and less bits on slow scenes
Yeah I know, but I was thinking using a relatively high crf value on stills, and a much lower one for the action scenes.
I figured it wouldn't yield much of a difference since h.264 is fairly advanced and adjusts accordingly, but I wanted to ask regardless.

>>58612206
What is her real age?

>>58612594
She's probably around 20 on that image. Makeup and photoshop do wonders.

http://deturl.com/play.asp?v=%2DWA3xOVZDAU She actually looks her age in videos.

>>58612533
if you want a more consistent rate, you could just use CBR

>>58612533
>>58612725
to be clear, what you're describing is what most would call a problem

CRF is the solution, it gives fast scenes more bits, and slow scenes less bits, to give a more consistent perceived quality, while avoiding under/over budgeting bits

CBR is the old standard, simply give every scene the same number of bits, this gives slow scenes more bits than they need, and fast scenes less than they need. but that's what you said you want

CBR, or the somewhat fancier constrained-VBR, are used nowadays for streaming (where you have a fixed bandwidth limit), but not so much for permanent storage

File: 1476916465209.jpg (133KB, 899x1200px) Image search: [Google]

133KB, 899x1200px

>>58612124
What is the sauce on this beauty

>>58613038

>>58612629

>>58613038
Her legs reveal the true age.

File: 1459459566989.jpg (74KB, 600x900px) Image search: [Google]

74KB, 600x900px

>>58613038
Nagasawa Marina. C'mon man a reverse image search, it's not that hard.

OP, people used to do this years ago for 700mb xvids. Encode the whole file at ~800kbit but then encode the credits separately at ~200kbit or less.

CRF does already take into account scene complexity, but if you want to be more aggressive about it AND you have more knowledge than x264's optimiser about what scenes are important, the option is certainly there

>>58613687
That's what I did literally right after. I didn't even read the tread to see if anyone else said anything about her cause I'm stupid. Shes a fucking goddess though

Since this is video editing related, what is /g/ preferred program to add subtitles to mkv files? Either hardsub or softsub.

>>58614093
Whoops meant to say MKVToolNix

>>58614121
mkvmerge is the part of mkvtoolnix you're referring to, though, so you weren't even wrong

File: Capture.png (18KB, 664x337px) Image search: [Google]

18KB, 664x337px

Just encode to lossless. Storage is cheap.

>>58614121
>>58614137
But is it free as in freedom?

>>58614147
yes

>>58612124
why do japs have elephant ears

File: 1386179821247.jpg (236KB, 1920x1080px) Image search: [Google]

236KB, 1920x1080px

>>58614151

>>58613983
>CRF does already take into account scene complexity, but if you want to be more aggressive
Yeah, this was my goal. Though it honestly doesn't seem to be making much of a difference.

>>58615097
Use preset placebo

https://trac.ffmpeg.org/wiki/Encode/H.264

>>58612533
>Yeah I know, but I was thinking using a relatively high crf value on stills, and a much lower one for the action scenes.
hmm, maybe what you're after is CRF but with an upper bitrate limit

that is, you set your CRF to what you want for still scenes, but have a low-ish upper bitrate limit so fast scenes don't blow out the bitrate

this way effectively only intense scenes have lower quality, and everything else is clamped by the CRF

this'd be more efficient than using CBR, as you'd still benefit from the bitrate dropping very low for still/credits scenes

for example;

ffmpeg ... -c:v libx264 -crf 17 -maxrate 16M -bufsize 32M ...

this will target CRF17, but won't exceed 16Mb/s /sustained/ bitrate (the buf[fer] size gives it room to reach up to in this case 32Mb/s, but only temporarily, good for things like short bursts of static, or an explosion or whatever)

>>58615221
You've got it backwards, I want a high bitrate for action scenes in order to preserve the quality, but a low bitrate for stills, just enough to be visually transparent (larger crf values correspond to lower bitrates).
I was thinking I could compress a little bit more this way, but the crf quantizer is optimized as it is.

>>58615221
>up to in this case 32Mb/s
this is a bit inaccurate
think of it more like this is the assumed buffer size that the player of that video will have available, assuming the player only has a <maxrate> bandwidth access to the file

that might be a bit confusing, just understand it allows for short bursts above the maxrate, and that this is beneficial

>>58615287
What CRF are you using?

>>58615287
that's not what you suggested in >>58612533
if this is what you meant, then that is exactly what CRF does standard, it raises the bitrate for fast scenes, and lowers it for slow scenes, targeting a quantizer value (which is the number you give it)

effectively you get a consistent quality level throughout

>>58614144
What kind of a lossless video takes that little space?

>>58615326
Depends on the video, but typically 19 for 1080p, 17 for 720p, and 15 for 480p.

>>58615287
>>58615330
oh, and yes, the decision making algorithms in x264/x265 are really good

I met marina nagasawa

>>58615330
>that's not what you suggested in >>58612533(You)
Really? I figured high crf for stills and low crf for actions implied a higher bitrate for action and lower bitrate for stills, even though that not technically correct.

>>58615215
There isn't much of a difference between placebo and veryslow, which is what I typically use.

>>58615287
sometimes it's worth spending cpu time filtering the video in some way before encoding
for example, if it's not a very high quality source, perhaps it might need debanding or deblocking, or if it's a high quality, but grainy film source, then perhaps try a denoising filter

grain especially is very hard to encode, due to its random nature, i personally use QTGMC in progressive mode, with dfttest as a denoiser, it's a bit different to most in that it doesn't just smooth out noise, but rather "stabilizes" it, preserving the appearance, but making it easier to encode

>>58615420
it does, i'm just not interpreting it like you're thinking it
crf with bitrate limits is the best i could think of that gave the result i thought you were after, at least, without resorting to manually cutting up the video and using custom CRF values for each, which you COULD do, but would really not be worth the time/effort

>>58615439
>high quality, but grainy film source, then perhaps try a denoising filter
Denoising filters usually help compression efficiency even if the source doesn't have much noticeable grain.
I use the BM3D filter, which works pretty well but it's killer on my cpu and encode times.

>>58615531
yea, good denoisers use a lot of cpu time, QTGMC is no exception, it might even be the slowest there is
it's primarily a deinterlacer, and uses things like mvtools to "regenerate" missing fields in interlaced content to make convincing full-rate progressive video out of interlaced material
the way it works makes it good at denoising progressive material too, in a rather unique way (and you can tell it to use a conventional denoiser on top of that, which i do)

i only use it when i need to, since it makes encodes around twice as slow, but the results are excellent, imo

video encoding is always a toss-up between how much time you're willing to sink into it, how big an output you can accept, and what kind of quality you'll end up with
you can't have it all

>>58612124
It's perfectly fine to merge streams where only crf differs in encoding settings.

So you can either make bunch of avisynth scripts, enocde and merge. This way you can also easily reencode part if it was still not good enough yet. Or if you prefer to have it in single file, here's how you do zones in x264, which is probably what you are using anyway.
http://www.chaneru.com/Roku/HLS/X264_Settings.htm#zones

>>58615215
this
and remember to change psy-rd to something else than the default, so you look like you know your x264 :^)

>>58615399
How, where, are you telling the truth?

>>58613253
Explain further

>>58612124
http://www.chaneru.com/Roku/HLS/X264_Settings.htm#zones

>>58615581
I'll have to try out QTGMC, I've been using IT as my ivtc filter, but the results can be pretty bad.

>>58615637
Actually, I was going to do it the avisynth way, although with vapoursynth.

>>58615796
thankfully i haven't needed to do any IVTC myself, since i'm in a PAL country

>>58615892
can you do
deint=qtgmc().selecteven()
tdeint(slow=2, full=false, clip2=deint)
in pal country?

>>58615892
>>58615796
if you aren't familiar with PAL, 24fps video is simply sped up to 25fps, then of course split into 50 fields for interlaced media
so all you need to do to reverse it is combine the fields and resample the audio and change the output framerate to slow it back down

>>58615956
this
if everything filmed ever came from america only places to see and greet other people

>>58615956
-- the only complication is determining if the audio was pitch-corrected or not
earlier stuff was sped up without pitch correction, you want to apply pitch correction when slowing it down only if they added pitch correction in the first place

>>58615950
you don't need to deinterlace 24fps-on-PAL content at all, 2 fields = 1 frame, a plain weave/combine is enough
tv/home camera content is often actual 50 fields/s though, which is where deinterlacing to 50fps (progressive) comes into play

File: vlcsnap-2017-01-12-20h15m34s779.png (392KB, 720x540px) Image search: [Google]

392KB, 720x540px

>>58616016
but what if you have progressive, interlaced and telecined frames, all in 29.97 fps goodness
then what?

>>58616145
then i'd be in america, cursing whoever made that monstrosity

>>58614144
> 36 minutes
> 90GB
I bet it's 480p.

>>58616145
Deinterlace and ivtc the relevant sections.

>>58616156
human eye cant see any more than 480i anyway

>>58616438
you're missing the point, the human eye can't see more than 9Mb/s, therefore lossless video is pointless

>>58612161
>telling women not to post photos of themselves online
can you just stop being a fucking faggot ruining things for straight men?

>>58616145
120fps

>>58616156
It's actually 1080p60

>>58616156
considering the speed he's getting, he's probably using x264/x265's lossless modes
with some content, you can get pretty decent ratios

File: Untitled.png (37KB, 806x593px) Image search: [Google]

37KB, 806x593px

>>58616572
it's huffyuv

>>58616652
.. why?

i mean, i've used huffyuv before, but nowadays i'd just use x264 with a fast preset if i needed to store something lossless temporarily

not to mention, the only thing i can think of that would make sense to store permanently lossless would be screencaps, and you'd want YUV444 for those, which huffyuv doesn't support (it has an RGB mode, but it's even less efficient)

File: a.png (17KB, 640x92px) Image search: [Google]

17KB, 640x92px

>>58616652
>>58616731
here's a few comparisons i did just now
2160 frame, 960x720 clip

as you can see, there's really no reason not to at least use x264/ultrafast, it's about as quick, yet compresses much better

>>58616917
I've been just using MeGUI's pre-rendering, but I just noticed runs the huffyuv encode in the same process as Avisynth. Since Avisynth is single-thread limited, I may have to try x264.

>>58617027
looking at the filename, is this a temporary encode just to apply QTGMC deinterlacing, to be passed on to a lossy encoder later?

if so, why not do it all in one pass?

i personally use vapoursynth and ffmpeg on linux, and just pipe between the two, like this;

vspipe /path/to/script.vpy - --y4m | ffmpeg -i - ...

no intermediate necessary, vapoursynth takes the input, applies qtgmc/whatever according to the script (analogous to avisynth), then outputs raw video with a yuv4mpeg header (so i don't need to specify things like pixel format or frame size to ffmpeg manually), which is piped straight into ffmpeg, to be encoded into the final output

>>58617110
I'm doing 1080 and 720. Faster to just do the filtering once.

>>58617027
Avisynth is single threaded?! How has this not been deprecated in favour of vapoursynth?

>>58617110
what i do is a little fancier than that, actually, i've got it all in a for loop so i can set it to process everything in a folder automatically

for i in *.mkv; do mkdir done; vspipe /path/to/script.vpy --arg inputFile="$PWD/$i" - --y4m | ffmpeg -hide_banner -i - -i "$i" -map 0 -map 1 -map -1:v -c copy -c:v libx265 -preset slow -aspect 16:9 -b:v 0 -x265-params "crf=17:min-keyint=48:keyint=7200:bframes=16:ref=6:scenecut=70:aq-mode=2:rc-lookahead=60:me=star:vbv-maxrate=16000:vbv-bufsize=32000" -c:a libopus -b:a 224k -frame_duration 60 -af "channelmap=channel_layout=5.1" -f matroska -n "done/$i"; done

>>58617154
The Vapoursynth instructions are literally:
1. Install Vapoursynth
2. Learn Python

Avisynth is just a little easier to learn.

>>58617154
i tried installing vapoursynth on windows once, it was a bit of a pain in the ass

unlike on arch where all the popular plugins are in the AUR

>>58617211
and that, the only way i got anywhere was to study existing scripts
it is more powerful once you figure it out, since you do have all of python available to you