Option for Cropping to happen before Resizing

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Load a 1280x720 video
2. Set Crop in options to T:40,B:40 (top & bottom, if cropping applied first 
video will now be 1280x640)
3. Set video size to 640x320

What is the expected output? What do you see instead?
In v1.3.2 the output video would be 640x320, in v1.4 it will be 640x240, 
because the order in which cropping and resizing happened is reversed.
I could probably change my crop and resize to match the 1.3.2 behaviour, but 
I'd prefer the program to calculate it for me.

What version of the product are you using? On what operating system?
v1.4 on WinXP

Please provide any additional information below.
- Paul Gevers recommended I open this issue here, see the thread at 
http://groups.google.com/group/winff/browse_thread/thread/359b7e66aab5e60f
- In the example I gave, it's relatively simple to adjust the numbers, in 1.4 I 
could just make cropping T:20 B:20 and I'd get a 640x320 file, but some other 
types of crops come up with uneven numbers.
- Eg, 1280x720 -> 640x480 was L:160 R:160 in v1.3.2, now it's 852x480 then 
L:106 R:106, or something close to those numbers, like 856x480/LR108. I haven't 
tested that and I'm not sure it would even work, some codecs demand dimensions 
divisible by 8. The pixel squareness would also be slightly off.

Original issue reported on code.google.com by JamesHoa...@gmail.com on 1 Jan 2012 at 8:28

[GoogleCodeExporter]

Hmm, if this is indeed correct (I have still to confirm) then I change my mind: 
I think this is indeed a bug. The point is that I believe the output size 
should be the size specified in the window, so we will have to change the 
metric, or more likely, the location of the cropping syntax, just like I did 
with seek.

I will investigate. 

Original comment by poipodec...@hotmail.com on 1 Jan 2012 at 1:19

• Changed state: Accepted
• Added labels: Component-Logic, OpSys-All, Usability

[GoogleCodeExporter]

It seems that ffmpeg now always crops AFTER scaling if the -s option is used, 
no matter where I put the video filter for cropping. The resize, padding and 
cropping needs rework to get this going. I am not sure if this is compatible 
with the named -s options. I.e. this is not easy.

Notes:
1) BUG: Winff currently does NOT replace existing crop settings in the preset.
2) I think the presets with cropping functionality are wrong at the moment.
3) Things like -aspect might give unexpected results if we go this way, and 
should probably be replaced by -vf setdar

Original comment by poipodec...@hotmail.com on 1 Jan 2012 at 5:47

[GoogleCodeExporter]

I just found out that this is basically a duplicate of issue 77. I don't mark 
it as such as that bug was fixed, and reintroduced by my latest crop fixes for 
issue 137.

I am nearly finished with my changes and will commit them pretty soon to trunk. 
I hope that somebody is willing to test.

Original comment by poipodec...@hotmail.com on 3 Jan 2012 at 9:21

• Changed state: Started

[GoogleCodeExporter]

I just uploaded commit r604 that should fix the coding part of this bug. I 
still need to update the presets. Working on that. 

I appreciate feedback. If positive or no comments I will port the changes to 
the 1.4 branch and release 1.4.1 later this or next week.

Original comment by poipodec...@hotmail.com on 4 Jan 2012 at 6:55

• Added labels: Component-Presets

[GoogleCodeExporter]

I have uploaded a new presets file for libavcodec53 to the download section. I 
would appreciate testing.

http://winff.googlecode.com/files/presets-libavcodec53-v3.xml.gz

Original comment by poipodec...@hotmail.com on 8 Jan 2012 at 7:32

[GoogleCodeExporter]

I tested with these new presets on 1.4.0 (I don't have the r604 update) and the 
issue was still present, but I'm guessing I need the code update.

Original comment by JamesHoa...@gmail.com on 9 Jan 2012 at 7:10

[GoogleCodeExporter]

Indeed, both code and presets are needed; presets file alone fix a problem with 
where both size and cropping are used IN the preset file. I hope to make a 
1.4.1 release soon if no one objects. As I can not make the Windows binary we 
will have to wait after the release for Matt or Ian.

Original comment by poipodec...@hotmail.com on 9 Jan 2012 at 7:13

[GoogleCodeExporter]

This issue is fixed in the 1.4.1 release.

Debian/Ubuntu packages are currently building. I hope Ian or BiggMatt will soon 
create a Windows package.

Original comment by poipodec...@hotmail.com on 14 Jan 2012 at 7:57

• Changed state: Fixed

[GoogleCodeExporter]

This problem seems to be present in 1.5.3 (Windows). Regression?

Original comment by r...@electroworks.net on 4 Mar 2014 at 11:54

[GoogleCodeExporter]

Or maybe the fix doesn't work in all cases. @ryan, can you please describe what 
you did exactly (e.g. which preset and which addition options by you)?

I think the clue is in my third note in message #2.

Original comment by poipodec...@hotmail.com on 16 Mar 2014 at 11:06

• Changed state: Started
• Removed labels: Component-Presets