Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > MPEG-4 AVC / H.264

Reply
 
Thread Tools Search this Thread Display Modes
Old 2nd January 2010, 19:32   #21  |  Link
chipzoller
Mr. Woof
 
chipzoller's Avatar
 
Join Date: Jan 2002
Location: USA
Posts: 784
What's a recommended way to use this build to open a DVD-encode project in substitute of AviSynth? Do we feed it d2v project files?
chipzoller is offline   Reply With Quote
Old 2nd January 2010, 19:38   #22  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,666
Quote:
Originally Posted by chipzoller View Post
What's a recommended way to use this build to open a DVD-encode project in substitute of AviSynth? Do we feed it d2v project files?
Correct.
Dark Shikari is offline   Reply With Quote
Old 2nd January 2010, 19:41   #23  |  Link
chipzoller
Mr. Woof
 
chipzoller's Avatar
 
Join Date: Jan 2002
Location: USA
Posts: 784
What about resizing? If correcting for PAR (no upsizing) are the built-in resizing algorithms just as effective as some of those for Avisynth?
chipzoller is offline   Reply With Quote
Old 3rd January 2010, 02:12   #24  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
I think if you want to apply filters, such as resize, you must still use Avisynth input...
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊
LoRd_MuldeR is offline   Reply With Quote
Old 3rd January 2010, 02:17   #25  |  Link
wOxxOm
Oz of the zOo
 
Join Date: May 2005
Posts: 208
ffms2 has built-in resizers (lanczos & spline included, as well as much much more options) in its API, so will it be possible to specify those in x264lavf/ffms cli command line?

Last edited by wOxxOm; 3rd January 2010 at 02:22.
wOxxOm is offline   Reply With Quote
Old 3rd January 2010, 02:25   #26  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,666
We'll be adding resizing support eventually. My thought is we'll have a few resizing modes (just an idea):

--resize WxH: resizes such that the size does not exceed W or H. Maintains aspect ratio: the input is not stretched, and by default, the SAR stays the same as the input too. So, for example:
Input: 1440x1080, SAR 4:3
Settings: --resize 1280x720
Output: 960x720 SAR 4:3

--input-sar: Overrides the SAR of the input file. Works the way SAR does currently. So, for example:
Input: 1440x1080, SAR 4:3
Settings: --input-sar 1:1
Output: 1440x1080 SAR 1:1

--output-sar: Modifies the resizing accordingly, in addition to setting the SAR. So, for example:

Input: 1440x1080, SAR 4:3
Settings: --output-sar 1:1
Result: 1920x1080, SAR 1:1

Last edited by Dark Shikari; 3rd January 2010 at 02:28.
Dark Shikari is offline   Reply With Quote
Old 3rd January 2010, 02:30   #27  |  Link
kemuri-_9
Compiling Encoder
 
kemuri-_9's Avatar
 
Join Date: Jan 2007
Posts: 1,348
Quote:
Originally Posted by roozhou View Post
@kemuri-_9

How did you calculate dts in mp4 output for vfr video when b-frames are used? It seems initdelay is still used.
I didn't touch the output muxers, i mostly dealt with the demuxer side of things.
should ask kierank/VFR_maniac.
VFR_maniac was the one who handled most of the updated mp4 code afaik.
__________________
custom x264 builds & patches | F@H | My Specs
kemuri-_9 is offline   Reply With Quote
Old 3rd January 2010, 02:30   #28  |  Link
wOxxOm
Oz of the zOo
 
Join Date: May 2005
Posts: 208
Quote:
We'll be adding resizing support eventually. My thought is we'll have a few resizing modes (just an idea)
cool))
just make sure that "--output-sar 1:1" alone won't resize the stream
And, resize quality (spline/bicubic/etc) selectors would be vital.
wOxxOm is offline   Reply With Quote
Old 3rd January 2010, 02:32   #29  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,666
Quote:
Originally Posted by wOxxOm View Post
cool))
just make sure that "--output-sar 1:1" alone won't resize the stream
Why?

--input-sar will be aliased to the old --sar option, so --output-sar will be the new option (with new behavior).
Dark Shikari is offline   Reply With Quote
Old 3rd January 2010, 02:40   #30  |  Link
wOxxOm
Oz of the zOo
 
Join Date: May 2005
Posts: 208
Quote:
so --output-sar will be the new option (with new behavior)
as you see fit, sir. I just thought that a switch that enables and does the resizing should have corresponding mnemonics, AND - what if I want to both resize and use some specific SAR for the output? e.g. resize from 1440x1080 to 720x480 and set 4:3 SAR... I'm not sure I see an intuitive way of doing it along the proposed scheme, but i am not too smart either
wOxxOm is offline   Reply With Quote
Old 3rd January 2010, 02:42   #31  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
Quote:
Originally Posted by Dark Shikari View Post
--resize WxH: resizes such that the size does not exceed W or H. Maintains aspect ratio: the input is not stretched, and by default, the SAR stays the same as the input too. So, for example:
Input: 1440x1080, SAR 4:3
Settings: --resize 1280x720
Output: 960x720 SAR 4:3
Sorry, but I think that would be really confusing. If I enter "--resize WxH" then I'd expect the output at exactly WxH. That's how any application I'm aware of works.

Maybe something like "--resize-width W" and "--resize-height H" could be added for resize that automatically maintains the correct aspect ratio?

Or just a placeholder, like MEncoder's resize option. For example "--resize -1:720" would resize to Wx720 with W chosen automatically to maintain the correct AR.
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊

Last edited by LoRd_MuldeR; 3rd January 2010 at 02:44.
LoRd_MuldeR is offline   Reply With Quote
Old 3rd January 2010, 02:47   #32  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,666
Quote:
Originally Posted by LoRd_MuldeR View Post
Sorry, but I think that would be really confusing. If I enter "--resize WxH" then I'd expect the output at exactly WxH. That's how any application I'm aware of works.
The number one complaint I've gotten about ffmpeg, from hundreds upon hundreds of users, is exactly the opposite of what you said: that, by default, resizing will stretch the image.

I don't know a single image editing program that, by default, allows you to stretch the image when resizing. I don't see why x264 should be any different. 99.9% of users do not want to stretch the video, so why should we design the program around the 0.1% who do?
Dark Shikari is offline   Reply With Quote
Old 3rd January 2010, 02:54   #33  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
Quote:
Originally Posted by Dark Shikari View Post
The number one complaint I've gotten about ffmpeg, from hundreds upon hundreds of users, is exactly the opposite of what you said: that, by default, resizing will stretch the image.

I don't know a single image editing program that, by default, allows you to stretch the image when resizing. I don't see why x264 should be any different. 99.9% of users do not want to stretch the video, so why should we design the program around the 0.1% who do?
There's an important difference:

If I use the resize filter in an image editing program, which has a GUI(!), and I enter the target size, then the "width" edit box is updated in realtime when I change the value in the "height" box - and vice versa. So the user will always see what he'll get as the final result and he can uncheck the "maintain aspect ratio" option at any time. But when I explicitly(!) pass "--resize WxH" to a CLI application, it would be really unorthodox to get something different from WxH, because there is no indication that "--resize WxH" actually means "--resize-to-the-biggest-size-that-accurately-fits-into WxH". When I explicitly(!) specify a value, I'm expecting to get that value and nothing else. And again: That's how any CLI application I'm aware of works. GUI applications are a different topic...
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊

Last edited by LoRd_MuldeR; 3rd January 2010 at 03:10.
LoRd_MuldeR is offline   Reply With Quote
Old 3rd January 2010, 02:59   #34  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,666
OK, then suggest a better method. I'm open ideas; the above I came up with in about 5 minutes. The method must have the following properties:

1. It must be conducive to batch encoding of many different input files, in which a user has a maximum size he wants.
2. It must minimize the number of additional parameter options.
3. It must, by default, prevent the user from inadvertently stretching his videos.
4. It must provide some way to change the SAR, including both a way to change the SAR while not changing the resolution (stretching), and a way to change the SAR while changing the resolution too (not stretching).
Dark Shikari is offline   Reply With Quote
Old 3rd January 2010, 03:09   #35  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
Well, I can think of three methods:
1. Use "--resize WxH" for explicit resizing and use "--resize-width W" respectively "--resize-height H" for automated/managed resize that will keep the AR
2. Use "--resize WxH" for explicit resizing and use "--resize-maximum WxH" alias "--target-screen-size WxH" alias "--managed-resize WxH" for automated/managed resize that will keep the AR
3. Use "--resize WxH" for explicit resizing and use "--resize ?xW" respectively "--resize Hx?" for automated/managed resize that will keep the AR
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊

Last edited by LoRd_MuldeR; 3rd January 2010 at 03:11.
LoRd_MuldeR is offline   Reply With Quote
Old 3rd January 2010, 03:54   #36  |  Link
mariush
Registered User
 
Join Date: Dec 2008
Posts: 589
I think resizing shouldn't influence the sar values, it may be too confusing for users (though most would use GUIs)

--resize widthxheight (don't care about aspect ratio, just do it as instructed, assume user knows what he's doing)

--update-sar if user wants to change the sar value from whatever is default in the source
--ignore-sar or --ignore-input-sar to ignore the sar specified in the input

or --input-sar and --output-sar, first to override the input sar, second to set the output sar, without any resizing performed

Irfanview has in Batch convert mode two additional options "Resize the longest side" and "Resize the shortest side", so maybe --resize-long and --resize-short and have the other dimension automatically adjusted to mantain proportion with the source (i'd say ignore sar in this case or automatically set it to 1:1 unless user sets --output-sar then)

I think most users would assume when they resize the image they'd have the sar to 1:1...
For example... someone gets a DVD, runs DVD decrypter on it and generates a single VOB file.. Opens it in Video Lan Client and looks in the messages window to see the width and height of the window VLC created (or uses Alt+PrintScr), so then they'd just use --resize widthxheight expecting image will be at that dimensions but if x264 preserves the sar from the vob file then result is messed up.

ps. I also think the resizing algorithm should be selectable, unless the speed difference between them is minimal. I personally use bicubic a lot when resizing from big resolution to lower resolution and when video goes to youtube type of sites. For personal backups I use Lanczos.

Last edited by mariush; 3rd January 2010 at 03:59.
mariush is offline   Reply With Quote
Old 3rd January 2010, 08:20   #37  |  Link
buzzqw
HDConvertToX author
 
Join Date: Nov 2003
Location: Cesena,Italy
Posts: 6,552
btw why not using the mencoder approach ?
"scale" and "crop" filters are easy to use (like crop=720:432:0:72,scale=640:272 or crop=720:432:0:72,scale=640:-2)

or totally explicit as ffmpeg

(even autocrop could be usefull too )

BHH
__________________
HDConvertToX: your tool for BD backup
MultiX264: The quick gui for x264
AutoMen: The Mencoder GUI
AutoWebM: supporting WebM/VP8
buzzqw is offline   Reply With Quote
Old 3rd January 2010, 10:31   #38  |  Link
Sharc
Registered User
 
Join Date: May 2006
Posts: 3,997
Whatever we do I suggest one should stick to the formula:
New SAR = Original SAR x (resized_height x cropped_width) : (cropped_height x resized_width).
Otherwise we will end up in producing distorted pictures.
The 'original SAR' needs to be taken from a set of standard values for commercial media. (e.g. for BD, PAL DVD and NTSC DVD sources).
Sharc is offline   Reply With Quote
Old 3rd January 2010, 15:30   #39  |  Link
ACoolie
Registered User
 
Join Date: Mar 2008
Posts: 30
Although this is OT, I like the GraphicsMagick command line options for scaling. By default, --resize works how DS requested. By adding an "!" to the end of the string, resize scales the video to that exact size. Ordinary users are protected, and if you know what you are doing it's easy to override.
ACoolie is offline   Reply With Quote
Old 3rd January 2010, 16:59   #40  |  Link
easyfab
Registered User
 
Join Date: Jan 2002
Posts: 332
Thanks for LAVF/FFMS input .

As I most of the time leave the defaults, could it be possible to also have a default output file (input: exemple.avi -> output: exemple.mkv or input :exemple.mkv -> output : exemple(1).mkv ) to enable the use of drag and drop.
easyfab is offline   Reply With Quote
Reply

Tags
beta, ffmpegsource, libavformat, test, x264

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 16:40.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.