19.05.2024, 20:14
thanks for your deep investigation of audio not loading!
something i already thought of previously: vapour and most encoders you use beneath hybrid gui are not really ment to be used as "integrated" audio and video solutions like, for example, when u use .avi with vdub and avs. audio is always present, i don't have to worry, i don't have to load it separetely.
this probably stems from historical switch to dvd ripping and everything it entitles, ie it entitles splitting audio and video to process/compress, then merging them at the end.
in that case it wouldn't be loading in vdub too.
but it does.
it probably has to do with which decoders are used.....
your script is synthetic, blank clip, mine is mjpeg.avi, which you can try for yourself with my script.....the link to video is in the first post.
there's probably some sort of "lost in translation" issue, maybe depending on input options (decoders) used....
if you remember, i installed python and vapour in addition to hybrid (to be able to load .vpy to vdub2), dunno if that could cause any weird interactions(?).
but none of that is important if audio can't be piped to hybrid anyway. but it's interesting anomaly.
one can, offcourse, compress that script via vdub2, because it's working there.
i attached the dubug. kinda big, forgot to turn it off few months ago...
.vpy script attached too.
par, dar, and then the --sar option in x264!
your screenshot kinda-sorta looks ok untill you compare it to source clip of 480x576 but set to 4:3 ar in player or vdub.
but i can see why you reached for mpeg2 16:9 PAR, it makes some sense.
after some trial and error, tinkering, and even some math, i figured it out and solved it.
here's the ratio:
480/576=0.8333333333333333333333 ratio (yeap, i need more decimals)
4/3=1.333333333333333333
1.333333333333333 / 0.8333333333333333333 =1.6
so 1.6 is our "correction ratio" we need to apply to 480x576(0.83) to get 768x576(4:3).
so now we need to find fraction that best represents it.
that would be 64:40 (64/40=1.6), ie we'll input --sar 64:40 to x264 via hybrid's 'misc' tab of "crop/resize" dialog, the "overwrite input par" section.
nothing else in "crop/resize", just "overwrite par" on 'misc' tab. everything else is off. no resize, letterbox, whatever.
this yields proper 4:3 on playback.
how to check?
play with mpc-hc, then "file->save image". is the image 768x576?
if it's not, sar (better to say par) is wrong.
it's interesting that even small drifts from 64:40 par will yield mediainfo suggesting it's 4:3 DAR, but on playback it's not 768x576.
for example, 84/54 ratio yields 746*576 image.
39/25 yields 748*576.
64/41 yields 749*576.
(how do i even know this? because first time i didn't use enough decimals, 1.3/0.83=1.566 and i used that instead of 1.6)
another way to check is to use pot player and drag the borders of player window until you achieve 768x576 window (dragging the borders produces resolution printout in top left of the screen), then compare screenshot of that player (both player and paused video inside, i used "faststone capture" to capture that screen) to original source video set to 4:3 ar in player.
any ar difference will be visible on cycling these two images in, for exampe, irfanview.
so that settles that issue.
i have also previously used "overwrite input par" in conjuction with resize to upscale 480x576 (4:3 DAR) for yt:
set "overwrite input par" to 3/4, set upscale (on 'base' tab of "crop/resize") to 1920x1080.
done.
test?
i compared actual picture dimensions on tv-screen. sd 480x576 (4:3) source and 10920x1080 (also 4:3!) hd encoding had same dimensions, ar is preserved.
something i already thought of previously: vapour and most encoders you use beneath hybrid gui are not really ment to be used as "integrated" audio and video solutions like, for example, when u use .avi with vdub and avs. audio is always present, i don't have to worry, i don't have to load it separetely.
this probably stems from historical switch to dvd ripping and everything it entitles, ie it entitles splitting audio and video to process/compress, then merging them at the end.
Quote:Properly loads in Hybrid. (without audio, but with no length problem)
=> no clue why it's not working for you, my guess is that something is wrong with the script.
in that case it wouldn't be loading in vdub too.
but it does.
it probably has to do with which decoders are used.....
your script is synthetic, blank clip, mine is mjpeg.avi, which you can try for yourself with my script.....the link to video is in the first post.
there's probably some sort of "lost in translation" issue, maybe depending on input options (decoders) used....
if you remember, i installed python and vapour in addition to hybrid (to be able to load .vpy to vdub2), dunno if that could cause any weird interactions(?).
but none of that is important if audio can't be piped to hybrid anyway. but it's interesting anomaly.
one can, offcourse, compress that script via vdub2, because it's working there.
i attached the dubug. kinda big, forgot to turn it off few months ago...
.vpy script attached too.
Quote:PAR != DAR. Whether you want to preserve the vertical or horizontal resolution to the original can be configured in Hybrid,...
My screenshot was just to show that 64:45 seems to be the correct input PAR, not that it would create a 4:3 DAR.
par, dar, and then the --sar option in x264!
your screenshot kinda-sorta looks ok untill you compare it to source clip of 480x576 but set to 4:3 ar in player or vdub.
but i can see why you reached for mpeg2 16:9 PAR, it makes some sense.
after some trial and error, tinkering, and even some math, i figured it out and solved it.
here's the ratio:
480/576=0.8333333333333333333333 ratio (yeap, i need more decimals)
4/3=1.333333333333333333
1.333333333333333 / 0.8333333333333333333 =1.6
so 1.6 is our "correction ratio" we need to apply to 480x576(0.83) to get 768x576(4:3).
so now we need to find fraction that best represents it.
that would be 64:40 (64/40=1.6), ie we'll input --sar 64:40 to x264 via hybrid's 'misc' tab of "crop/resize" dialog, the "overwrite input par" section.
nothing else in "crop/resize", just "overwrite par" on 'misc' tab. everything else is off. no resize, letterbox, whatever.
this yields proper 4:3 on playback.
how to check?
play with mpc-hc, then "file->save image". is the image 768x576?
if it's not, sar (better to say par) is wrong.
it's interesting that even small drifts from 64:40 par will yield mediainfo suggesting it's 4:3 DAR, but on playback it's not 768x576.
for example, 84/54 ratio yields 746*576 image.
39/25 yields 748*576.
64/41 yields 749*576.
(how do i even know this? because first time i didn't use enough decimals, 1.3/0.83=1.566 and i used that instead of 1.6)
another way to check is to use pot player and drag the borders of player window until you achieve 768x576 window (dragging the borders produces resolution printout in top left of the screen), then compare screenshot of that player (both player and paused video inside, i used "faststone capture" to capture that screen) to original source video set to 4:3 ar in player.
any ar difference will be visible on cycling these two images in, for exampe, irfanview.
so that settles that issue.
i have also previously used "overwrite input par" in conjuction with resize to upscale 480x576 (4:3 DAR) for yt:
set "overwrite input par" to 3/4, set upscale (on 'base' tab of "crop/resize") to 1920x1080.
done.
test?
i compared actual picture dimensions on tv-screen. sd 480x576 (4:3) source and 10920x1080 (also 4:3!) hd encoding had same dimensions, ar is preserved.