18.05.2024, 21:05
Quote:You should adjust the input PAR if your source isn't properly flagged. (4:3 is usually a DAR)
yes, i know (i was using that to make some upscaled sd straight from 480x576 mpeg2, to upload to yt), but mp4 probably has DAR flags same as prev. mpeg versions....i think one can set them in ffmpeg....
that would be simpler. ie i usually just encode 480x576 and set 4:3 flag in mpeg2 so player corrects it on playback....
(simillar to many weird resolutions of dvb-s mpeg2, for example 544 x 576)
your 640x539 image can't be proper aspect ratio, 640 / 4/3 is 480.
768x576 is correct (attached), in a square pixel world. and preserving vertical resolution.
that clip has no audio, and it should have it. like i said, i fed modded .py script to hybrid (without audio, script made by mangling the temp script from temp folder of windows), and audio is source .avi file.....
inspect this clip and you'll know what i'm doing:
https://www.mediafire.com/file/bpnkx5ol8...4.wmv/file
peculiar thing is that both path to .py and path to .avi file are listed in audio job path, as visible in that .wmv.
maybe i should load audio via vapoursynth script too, with "best source"....
if you play that clip ("tivtc 50 and ml degrain tempPreviewVapoursynthFile05_03_13_984.mp4") in mpc-hc or pot player you'll just hear first brief moment of the audio.
the source clip with ok audio is linked in the first post ( https://www.mediafire.com/file/7k7hfnoiy...s.avi/file )
somehow hybrid begins to convert audio but just gives up after 107ms.
when the video input is .py script, and audio input is mjpeg avi file.
about mpeg2: that comes from years of tinkering with codecs, all the way back to divx, xvid: motion estimation of these is too sensitive to noise and can produce false-motion, ie motion of noise is mistaken for real motion and then you have weird distortions of still backgrounds, for example.
on top of that, h264 has inloop filter (just a throwback to realvideo and vp codecs' bluriness, really) that just makes mess of noise, with all those different block sizes (8x8 dct is just for i-frames, right?) etc. i usually keep that at -4:-4, but either way it's pretty bad.
while mpeg2 just grinds everything, noise or no noise.
there is a post by manono on doom9 somewhere along these lines, but offcourse i wasn't reading about that, i was testing. i just read it much later and it put a smile on my face. offcourse cce (if you remember japanese cinema craft encoder?) is also 10x faster than any mpeg4 or h264 encoder, it seems they made everything important in assembler....heh....
(there's even a peculiarity that mencoder was making mpeg2 at usual mpeg4 (lower) bitrates that looked quite fine, there's even peculiarity that one can put mpeg2 in .avi, but that too is just a peculiarity)
why all of this? because at some (high) levels of noise, you just can't denoise it properly. some analog satellite tv recordings have much noise. my sources were usually analog, and noisy....i was never ripping dvds.
it's quite fun to preserve some noise in today's world of clean, overcompressed and blurry videos of tv and yt.
as for interlacing, support for interlaced encoding since divx/xvid was hit and miss when it comes to hardware players, which don't mean much to me, but it's ok if it plays properly straight on tv, read from usb flash stick....as mpeg2 does.
i mean i guess it can be done with x264 (although there was some confusion about laced modes of 264, ie its application in x264) but then again those compression woes remain, so.....
offcourse, mpeg2 needs higher bitrate.
but hdd space is cheap these days.