FFMPEG deinterlace, convert to square pixel, real frame rate.

[poisondeathray]

I don't even know if what I did was necessary, so im more confused than ever, but MediaInfo and Vegas 13 report it as 29 progressive.

The original VOB? I doubt it. Post a native sample with steady motion, like a panning shot


Fieldmatching only should give you 29.97, but with every 5th frame a duplicate. Jerky motion. You combine it with decimation to give you the proper 23.976 original frames. Those two together = IVTC



I'll ask again - did you want to do it properly ? or with errors , problems and hair pulling?

Did you decrypt the discs? (Ie. remove copy protection) ? If not start over

You can interpret the AR and scale in vegas

If you insist on doing it in ffmpeg, you can use -vf setsar=1/1 for the SAR

[Wader8]

Check that post again on first page, i just updated with second test.

Isn't 5th frame duplicated in the original anyways as it's filmed in 24 and shipped as 29. I left the thing running for 20 mins now and I don't see any problems and no jerky motion even tho I'm not an expert on that, i'll go see what jerky motion exactly is.

As I said, decimate causes huge audio desync and video is fast motion - unwatchable.


Look I know I might be pressing on this method for some reason, it's just a set of tradeoffs, maybe I'm wrong, maybe Vegas 13 won't have the stuff I had with 12, but with a repository of 600 clips it's just better to be safe than sorry. I will apply other stuff on top of these clips like 720p upscale, I just think doing all the conversions at once in final is a bit of an overkill.

I did ... check the timeline and yes i can see duplicated frames, however, to tell you honestly I think it looks better than any interpolation from 24 to 30 would imo. I'm kind of a PC guy, I don't like HDTVs much so that's kind of the tradeoffs I like.

So if I get the proper audio sync with 23,9 - id still like to convert it to 24, 25 or 30 so I don't have to use odd SMTPE timecode rulers, so that's why I would use interpolation, but I don't know why I said 30 back in page one, i just meant to round it to a whole number that's the closest.

EDIT: I didn't use any pullup or vf "fps= " stuff that I found over the web, maybe old commands for older methods or what ?
Probably would need to set some of this with decimate, to fix the sync ?


Also keep refreshing the page, If you just see a new recent post, i keep updating the same posts 10-15 minutes after I post it with about 3-6 variously sized edits.

[poisondeathray]

Check that post again on first page, i just updated with second test.

Isn't 5th frame duplicated in the original anyways as it's filmed in 24 and shipped as 29. I left the thing running for 20 mins now and I don't see any problems and no jerky motion even tho I'm not an expert on that, i'll go see what jerky motion exactly is.

As I said, decimate causes huge audio desync and video is fast motion - unwatchable.


Look I know I might be pressing on this method for some reason, it's just a set of tradeoffs, maybe I'm wrong, maybe Vegas 13 won't have the stuff I had with 12, but with a repository of 600 clips it's just better to be safe than sorry. I will apply other stuff on top of these clips like 720p upscale, I just think doing all the conversions at once in final is a bit of an overkill.

I did ... well i just forgot what i meant to say here.

You think this is "better safe than sorry?" LOL LOL LOL

Do you see all those error messages and problems ?

Good luck trying to solve this

Decimating properly doesn't cause desync or fast motion after proper field matching, it returns the ORIGINAL film frames. If you have 29.97 after processing, then something is wrong. If it's out of sync , then something wrong. If you get all the ffmpeg log errors, HINT: something is wrong .

Hint: You should do it properly in the tried and true methods that 1000's of people use everyday.

I'm still going to push further to get it to 30 fps at least, and the whole thing will be upscaled to 720p in final anyway.

Doesn't make any sense. 30 FPS will be jerky, unless you do some fancy optical flow/ interpolation routines to generate /synthesis new frames (they have errors, it's not perfect)

If you're going to upscale it , What is with all this resizing with square pixels to 854x480? What a waste of time. Did you think scaling it a few times would give you better results ? Did you want to finish this project this year ?

So if I get the proper audio sync with 23,9 - id still like to convert it to 24, 25 or 30 so I don't have to use odd SMTPE timecode rulers.

23.976 to 24.0 is easy, you have to adjust the audio , since it's a known fraction, same with 25. You can do it with or without pitch correctly. 30 is not so good because the difference is too large




Anyways, I'm done . Good luck with this

Cheers

[Wader8]

Post a native sample with steady motion, like a panning shot

Well I don't know what that is

Nor I do know what "tried and true" methods are anyways.

Maybe it's more of a VOB problem, the last VOB doesn't even start, so that one will only work when I use the concat input.

Plus, the audio's more important in this case, don't want to mess that up, not sure what I'm going to do about that yet.

Pretty much what broke it was that I don't have time to mess with avisynth and handbrake is 264 only, so what are my options, i'll screw the industry and do it my own way like I usually end up.

Thanks for everything, well if you still want to add something go ahead, im going to be around for awhile.

[pandy]

Based on your description:

@ffmpeg -threads %NUMBER_OF_PROCESSORS%*1.5 -i %1 -map 0:v -c:v rawvideo -vf pp="hb/vb/dr",yadif=1:-1:0,hqdn3d=2:2:2:2,decimate=cycle=2,scale="'if(gt(a,16/9),848,-1)':'if(gt(a,16/9),-1,480)':sws_flags=spline",pad=848:480:(ow-iw)/2:0 -y %1.avi

Not sure if this is what are you searching for but...

[Wader8]

Based on your description:

@ffmpeg -threads %NUMBER_OF_PROCESSORS%*1.5 -i %1 -map 0:v -c:v rawvideo -vf pp="hb/vb/dr",yadif=1:-1:0,hqdn3d=2:2:2:2,decimate=cycle=2,scale="'if(gt(a,16/9),848,-1)':'if(gt(a,16/9),-1,480)':sws_flags=spline",pad=848:480:(ow-iw)/2:0 -y %1.avi

Not sure if this is what are searching for but...

Allright ... even tho I kind of swayed away from the path a bit, i might try this to see what it throws out

What's with 848x480 ?

[pandy]

allright ... Even tho i kind of swayed away from the path a bit, i might try this to see what it throws out

what's with 848x480 ?

848=(trunc((480*16)/144))*16

[jagabo]

In other words, 848 is the nearest mod 16 frame size for a 16:9, 480 line video.

[Wader8]

Well ofcourse I don't get it, I don't really know that much details, when I calculate it throws me out 477 for 848. Not sure why I would have to keep 480 lines.

But on the other hand 864x486 came out fine with the script I've been working on, have to do concat separately, there was some warning about "non-monoamorphic DTS may cause desync" but it didn't, i didn't bother to convert to 30 because I'm growing impatient a bit (10 windows and 50 tabs each of google searchings and 3 year old text-only trac posts opened for 4 days straight gives me a headache) and couldn't find a single example on the web, everyone's converting to 29 from 30, then made a 5 minute video in vegas upscaled to 720p and rendered in mpeg2ps, put on youtube for a test and looks great, or rather, good enough for what I'm doing.

From all the stuff i researched, only about 2% was from 2014 that was barely useful, and we're in ... september. I don't really know what goals do ffmpeg devs have in mind, but I know one thing they don't.

So all the stuff here was helpful so I really appreciate it very much.

So ffmpeg has to have the mod 16, wouldn't it do errors without that ?

[jagabo]

As poisondeathray pointed out, it's a waste of time and a loss of quality to resize more than once. If Vegas doesn't understand.

You shouldn't be working VOB files. You should use a program like VOB2MPG to convert them to MPG files. VOB often contain extra data, are non linear, etc. And the accompanying IFO files often override settings in the VOB files (aspect ratio, etc.). VOB2MPG will concatenate the VOB files and remux the audio and video to MPG.

[pandy]

Well ofcourse I don't get it, I don't really know that much details, when I calculate it throws me out 477 for 848. Not sure why I would have to keep 480 lines.

?? how 53*16 can be 477?

put on youtube for a test and looks great, or rather, good enough for what I'm doing.

Don't bother with hq encoding for YT - it will be cut by YT (re-encoded) to lowest common denominator and looks like old, washed pants anyway.

From all the stuff i researched, only about 2% was from 2014 that was barely useful, and we're in ... september. I don't really know what goals do ffmpeg devs have in mind, but I know one thing they don't.

So all the stuff here was helpful so I really appreciate it very much.

Use google, select not older than 1 year - it works fine for me - second - go to FFMPEG site and read docs - more or less they cover wide area and they improving with time (progress is significant - there is no doubt on this)
Second - FFMPEG is free project, based on voluntary work and their private (mostly) time - always You can write documentation and improve FFMPEG - i reading source to discover non documented things.

So ffmpeg has to have the mod 16, wouldn't it do errors without that ?

FFMPEG will be happy with everything reasonable - perhaps it will output warning that this is not recommended or something similar - issue is that video codecs are mostly block oriented and granularity of blocks is 16, 8 , 4. Personally i prefer 16 as compatible with most of modern and older video codecs - that's why i've proposed 848x480 - see no gain to have 856 or 852 but feel free to use any resolution you want - it was example to modify...

[Wader8]

?? how 53*16 can be 477?

When I put width 848 into a 16:9 calculator it throws out height 477 http://andrew.hedges.name/experiments/aspect_ratio/

I just don't get it why you keep height the same.

Don't bother with hq encoding for YT - it will be cut by YT (re-encoded) to lowest common denominator and looks like old, washed pants anyway.

I always encode my videos in high quality for youtube so it has a higher source to work with cutting that all down, and also I always upscale it so it switches to a higher quality selector which has a higher bitrate treshold.

I think I had 4 minutes and I ended up with 350 MB, most of the projects will be a half this, maybe some a bit more, but around here.


I don't have the ac-tex damaged error and something about MVs since I recode the concat VOBs, only happened with one of them, seems like the vobs act like they're one but in 4-5 parts. Except some warnings about frames that can't be deinterlaced (says Frame #4234225 still interlaced)

[smrpix]

Wasn't the point of this exercise to maintain quality? You've drifted far off course.

Open your vobs directly in Vegas, match project settings to vob sources, select clips, combine, refine, smart render to match source, upload. Done.

[Wader8]

Wasn't the point of this exercise to maintain quality? You've drifted far off course.

Open your vobs directly in Vegas, match project settings to vob sources, select clips, combine, refine, smart render to match source, upload. Done.

Okay, importing 200 GB into Vegas ....


Yes I could do it that way, actually vegas opens VOBs as chapters, creates 50 files. I just didn't want to mess with vegas to do some prepwork.

[smrpix]

I just didn't want to mess with vegas to do some prepwork.

The way I see it, given your reported sources, there's no reason to mess with prep work if you're using Vegas.

By bringing your files directly into Vegas
you don't have to convert vobs to mpg,
you don't have to concatenate externally,
you don't have to deinterlace massive files,
You can see your clips directly to make selections
You don't have to use Avisynth and create even more larger files
You can set your selections aside in their own bins for easy access
you can quickly access your set-aside subclips for recombining
you can smart-render output virtually losslessly

There is no downside to doing this properly.

But then again I promised to shut up about this, didn't I?

[Wader8]

Right maybe I should try it for the next season, I did the first 2, can't change it anymore, timecodes are vob-concat specific, not done with the extraction with season 2, so when I finish that i'll try that for season 3.

[pandy]

?? how 53*16 can be 477?

When I put width 848 into a 16:9 calculator it throws out height 477 http://andrew.hedges.name/experiments/aspect_ratio/

I just don't get it why you keep height the same.

This is simple - there 480 lines in video but pixels are usually not present (this is simplification to not start huge and violent dispute).
So 480 is always constant - remain part is simple - multiply number of lines (480) by aspect ratio factor (16/9) - this will produce some number (853.333333333333....), next divide this number by 16 and you receive another number (53.33333333333333333.... you can say this is number of block and each block is made from 16 pixels), next is truncation (or rather correctly rounding - this was case where error was smaller for truncation) - finals result is number of the pixels in line so 848 pixels (as we upscaling thus we not adding any vital data then i would say almost always it is better to truncate and use saved bits to improve overall quality).

Side to this - calculator used by you seem to not doing/using modulo calculation so this is plain aspect ratio calculator not video aspect ratio calculator where codecs limitations (or rather architecture) are involved in calculation process.

Don't bother with hq encoding for YT - it will be cut by YT (re-encoded) to lowest common denominator and looks like old, washed pants anyway.

I always encode my videos in high quality for youtube so it has a higher source to work with cutting that all down, and also I always upscale it so it switches to a higher quality selector which has a higher bitrate treshold.

don't get me wrong - i pointed that i see lot of guides where people use insane presets to provide video to YT - where it is ok to use insane or similar presets for personal use the i see no point to use them to encode video and later upload this video to YT only - YT recode every uploaded video with own profile which is more like very fast than very slow quality - people spending ours then YT anyway recode video.
So if you have relatively quick uplink then i see no added value to encode hq for YT.
Upsizing is OK to force HD profile on YT.

(OT - i'm curious when YT start limiting this by spectral analysis of video content and based on upper part of spectrum they will start limiting this kind of workaround - to save bits and obviously reduce operational costs and increase profit.)

I don't have the ac-tex damaged error and something about MVs since I recode the concat VOBs, only happened with one of them, seems like the vobs act like they're one but in 4-5 parts. Except some warnings about frames that can't be deinterlaced (says Frame #4234225 still interlaced)

I'm almost sure that this is low quality source with some form of telecine - i'm afraid that there is no simple solution for your problem - seem that concatenation was made also incorrectly if bitstream syntax is violated.

[Wader8]

This is simple - there 480 lines in video but pixels are usually not present (this is simplification to not start huge and violent dispute).
So 480 is always constant - remain part is simple - multiply number of lines (480) by aspect ratio factor (16/9) - this will produce some number (853.333333333333....), next divide this number by 16 and you receive another number (53.33333333333333333.... you can say this is number of block and each block is made from 16 pixels), next is truncation (or rather correctly rounding - this was case where error was smaller for truncation) - finals result is number of the pixels in line so 848 pixels (as we upscaling thus we not adding any vital data then i would say almost always it is better to truncate and use saved bits to improve overall quality).

Side to this - calculator used by you seem to not doing/using modulo calculation so this is plain aspect ratio calculator not video aspect ratio calculator where codecs limitations (or rather architecture) are involved in calculation process.

That's way over my head, unfortunately I can't comprehend it, would require way more details than this, still, I guess it has to do with the whole numbers thing that requires it all in blocks of dividable numbers whatever.

Does maybe 4:2:0 stuff has something to do with it, cause I still don't get it why it has to stay 480 "lines" whatever they are.

Just pretend I'm as dumb as Jack O'neill and you're Major Carter trying to explain the naquadira power generator

don't get me wrong - i pointed that i see lot of guides where people use insane presets to provide video to YT - where it is ok to use insane or similar presets for personal use the i see no point to use them to encode video and later upload this video to YT only - YT recode every uploaded video with own profile which is more like very fast than very slow quality - people spending ours then YT anyway recode video.
So if you have relatively quick uplink then i see no added value to encode hq for YT.
Upsizing is OK to force HD profile on YT.

No I'm not tinkering with it for days, I found 2 specification PDFs about MPEG2 encoder that's in vegas and followed them to adjust my settings for non-dvd progressive video.

Most "best settings for youtube" people usually just copycat the H264 FAQs on youtube, or some other fancy "top 10 guides" website.

If I do that, the youtube's encoder then has a weaker source to convert, so 2 conversions with H264 would happen; limiting that to only 1 by avoiding doing it myself.

(OT - i'm curious when YT start limiting this by spectral analysis of video content and based on upper part of spectrum they will start limiting this kind of workaround - to save bits and obviously reduce operational costs and increase profit.)

I hope not, though I was disappointed with "Original" quality flag when it was still used, now it's been removed. It only increased bitrate by less than 10 percent.

I haven't tested since if 1152p still worked, but I think that they raised the bar and made it into 4K, ... actually just this moment i searched a bit and I think i found something https://encodingtalk.com/threads/your-thoughts-about-the-youtube-1440p-video-quality-option.3087/

Seems like Original was replaced with 1440p and changed, but it raised the treshold a bit.

Resolution       Factor     Youtube
1920 x 1080      67,5       1080p
2048 x 1152      72         1080p
2176 x 1224      76,5       1440p
2304 x 1296      81         1440p
2432 x 1368      85,5       1440p
2560 x 1440      90         1440p
2688 x 1512      94,5       1440p
2816 x 1584      99         1440p

So the smallest resolution to trigger 1440p seems to be 2176x1224 (besides the 16:10 format 1920x1200). 2048x1152 doesn't cut it anymore, as mentioned above.

Notes:
The "Factor" is a multiple of 16 (for width) and 9 (for height); I didn't try any other uneven combinations.
AviDemux seems unable to resize videos to larger than 2900, so I wasn't able test any higher resolutions.
Bitrate increased from 3.243kbps to 5.179kbps with the test file I was using.
I didn't see the "Original" quality setting once.

I'm almost sure that this is low quality source with some form of telecine - i'm afraid that there is no simple solution for your problem - seem that concatenation was made also incorrectly if bitstream syntax is violated.

I was saying, the errors went away after the concat, so it's fine now, for my own method I was using.