Main page
[00:32] superdump (~rob@unaffiliated/superdump) left irc: Quit: WeeChat 0.3.2-dev
[01:09] s55 (~Scott@cpc1-livi1-0-0-cust180.sgyl.cable.virginmedia.com) left irc: Quit: Leaving
[01:32] brianmario (~brianmari@v15.corp.metainterfaces.com) left irc: Quit: brianmario
[01:39] [BradleyS] i'd like to fix an edge case where calculated dimensions don't respect mod, but would like advice
[01:39] [BradleyS] the scenario is simple
[01:40] [BradleyS] pretty much anywhere this is done, we do it wrong (similarly). i'd like to focus on hb_fix_aspect in libhb
[01:41] [BradleyS] when constraining dimensions to min and max, first calculate the closest value respecting mod
[01:42] [BradleyS] if it's smaller than the minimum dimensions, we snap to the minimums
[01:42] [BradleyS] this is fine as long as the minimum dimensions are a multiple of the modulus, which they always are. current minimum for both dimensions is 32px, which is mod 2, 4, 8, 16
[01:43] [BradleyS] on line 135 i even left the comment: "// min_width and min_height should be multiples of modulus"
[01:43] [BradleyS] the problem is the way we handle max
[01:43] [BradleyS] when handling minimums, we specify the value. 32px. constant.
[01:44] [BradleyS] when handling maximums, we use the source's native dimensions. variable.
[01:44] [BradleyS] similarly to how we calculate mins, we first calculate the closest value respecting mod
[01:45] [BradleyS] if it's greater than the source's dimensions, we snap to the source dimensions. that's our max.
[01:45] [BradleyS] the problem is, we can't guarantee the modulus now.
[01:47] [BradleyS] i'm not even sure we can guarantee mod 2, unless somewhere else in the code, odd dimensions are made even
[01:48] [BradleyS] lets say we take a dvd source, 720x480. we select mod 4 and with some autocropping we end up with 716x478.
[01:48] [BradleyS] this works fine
[01:48] [BradleyS] now, load the output as input.
[01:50] [BradleyS] it's entirely possible to adjust the modulus to say, mod 8, and get a result larger than the source dimensions
[01:50] [BradleyS] with the current code, hb would snap to the source dims, 716x478. but neither dimension is mod 8.
[01:51] [BradleyS] we're basically looking at a carryover from hb's dvd-input-only days, where mod 16 could be reasonably assumed.
[01:53] [BradleyS] so what needs to happen is, when calculating dimensions and the closest value respecting mod is larger than the source dimension, we need to find the largest value that's mod N and smaller than or equal to the source dimension.
[01:54] [BradleyS] i would have implemented this by now in hb_fix_aspect, but i wonder if a utility function or other option would be better
[01:55] [BradleyS] right now we have things like MIN() MAX() and MULTIPLE_MOD() which do some nifty calculations for us
[01:55] [BradleyS] i wonder if we could either create another, or expand MULTIPLE_MOD() to operate within the necessary constraints
[01:56] [BradleyS] would be nice to do something like, job->width = ( job->width, modulus, max_size )
[01:57] *** BradleyS is clearly having another boring Friday night
[02:05] [BradleyS] it's trivial to get the result of MULTIPLE_MOD() and just subtract modulus until the value is less than the source max
[02:06] [BradleyS] but kinda ugly to have a loop like that everywhere this calculation is done
[02:18] *** BradleyS is reminded that libhb allows for dimensions > source, so i guess this is only applies elsewhere. still, a utility function might be of benefit
[03:45] Rodeo-laptop (~tim@adsl-188-155-46-17.adslplus.ch) left irc: Ping timeout: 246 seconds
[03:47] Rodeo-laptop (~tim@adsl-188-155-46-17.adslplus.ch) joined #handbrake-dev.
[04:06] [Dark_Shikari] ping
[04:12] [Dark_Shikari] http://pastebin.com/f6dd893ef <--is this good for what you guys need?
[04:47] #handbrake-dev: mode change '+v Rodeo-laptop' by dynaflash!~dynaflash@c-24-131-180-202.hsd1.mn.comcast.net
[04:51] [Rodeo-laptop] thanks dyna
[04:52] [Rodeo-laptop] Dark_Shikari: you'd have to ask jbrjake but this seems to be what he asked for
[04:52] [Rodeo-laptop] of course, you'd need a function to unparse so that the effective settings can be updated as you change presets etc.
[04:52] [Rodeo-laptop] and there's the WinGUI problem
[04:53] [Rodeo-laptop] since it doesn't use libhb
[04:53] [Dark_Shikari] eheheh
[04:54] [Rodeo-laptop] which means either re-implementing all that stuff in the WinGUI (PITA to maintain) or use a special CLI option to apply the presets and unparse (not elegant, though it could also be used as a dry-run by CLI users I guess)
[04:54] [Dark_Shikari] Or LINKING TO LIBHB
[04:54] [Dark_Shikari] and doing it right
[04:55] [Rodeo-laptop] yes, but that's a good way to further delay x264 preset support in HB, unless of course the devs agree to leave the WinGUI behind for a while
[04:56] [dynaflash] not a good idea
[04:57] [Rodeo-laptop] indeed, I doubt any HB dev would want to do that
[04:57] [Dark_Shikari] shouldn't the GUIs eventually be unified
[04:57] [Dark_Shikari] or at least generally do the same thing?
[04:57] [Rodeo-laptop] well, they are, pretty much, with a few exceptions
[04:58] [Dark_Shikari] not linking to libhb is a pretty huge exception
[04:58] [Rodeo-laptop] mostly related to the fact that the WinGUI is a CLI wrapper
[04:58] [Rodeo-laptop] yes but graphically speaking, the WinGUI is very close to the other UIs, and something as big as x264 preset support is not going to be implemented in only 2/3 UIs
[04:59] [dynaflash] correct
[04:59] [Dark_Shikari] then you'll either have to fix the wingui
[04:59] [Dark_Shikari] or copy param_unparse
[04:59] [Dark_Shikari] or limit the ability to display the current commandline
[04:59] [Dark_Shikari] or modify the interface to display only the modifications to the presetted commandline
[04:59] *** Rodeo-laptop thinks that the special CLI dry-run (apply presets etc. and unparse), while inelegant, is feasible
[05:00] [Dark_Shikari] Rodeo-laptop: there's an easier option
[05:00] [Rodeo-laptop] the WinGUI already gets the presets from ./HandBrakeCLI --preset-list, doesn't it?
[05:00] [Dark_Shikari] hmm true
[05:00] [Dark_Shikari] dunno
[05:00] [Dark_Shikari] whatever, the GUI needs the presets
[05:00] [Rodeo-laptop] which is why it has very weird formatting
[05:02] [dynaflash] afaik, other than s55 almost no devs every work on the wingui
[05:03] [dynaflash] a few have played with it from time to time but nothing has really come of linking to libhb
[05:03] [dynaflash] hell, I have never even compiled it.
[05:41] brianmario (~brianmari@c-24-7-56-53.hsd1.ca.comcast.net) joined #handbrake-dev.
[06:17] Rodeo-laptop (~tim@adsl-188-155-46-17.adslplus.ch) left irc: Quit: Rodeo-laptop
[07:10] bogo_lode (~bogo_lode@75.108.108.82) left irc: Quit: I give up...
[08:44] TedJ (~ted@115-64-133-105.static.tpgi.com.au) joined #handbrake-dev.
[09:32] ritsuka (~Ritsuka@host246-247-dynamic.33-79-r.retail.telecomitalia.it) joined #handbrake-dev.
[09:32] #handbrake-dev: mode change '+v ritsuka' by BrakeBot!~BrakeBot@rocky.lapsus.org
[09:54] brianmario (~brianmari@c-24-7-56-53.hsd1.ca.comcast.net) left irc: Quit: brianmario
[11:55] s55 (~Scott@cpc1-livi1-0-0-cust180.sgyl.cable.virginmedia.com) joined #handbrake-dev.
[11:55] #handbrake-dev: mode change '+o s55' by HandBot!~HandBot@concorde.lapsus.org
[12:05] #handbrake-dev: mode change '+v TedJ' by s55!~Scott@cpc1-livi1-0-0-cust180.sgyl.cable.virginmedia.com
[13:44] s55 (~Scott@cpc1-livi1-0-0-cust180.sgyl.cable.virginmedia.com) left irc: Quit: Leaving
[13:46] Rodeo-laptop (~tim@adsl-188-155-46-17.adslplus.ch) joined #handbrake-dev.
[14:11] s55 (~Scott@cpc1-livi1-0-0-cust180.sgyl.cable.virginmedia.com) joined #handbrake-dev.
[14:12] #handbrake-dev: mode change '+o s55' by BrakeBot!~BrakeBot@rocky.lapsus.org
[14:36] Rodeo-laptop (~tim@adsl-188-155-46-17.adslplus.ch) left irc: Remote host closed the connection
[14:37] Rodeo-laptop (~tim@adsl-188-155-46-17.adslplus.ch) joined #handbrake-dev.
[15:24] TedJ (~ted@115-64-133-105.static.tpgi.com.au) left irc: Quit: I regret nothing!
[15:30] #handbrake-dev: mode change '+v Rodeo-laptop' by dynaflash!~dynaflash@c-24-131-180-202.hsd1.mn.comcast.net
[15:30] [dynaflash] it appears my excising of full screen mode was a bit wreckless
[15:45] s55 (~Scott@cpc1-livi1-0-0-cust180.sgyl.cable.virginmedia.com) left irc: Quit: Leaving
[15:45] s55 (~Scott@cpc1-livi1-0-0-cust180.sgyl.cable.virginmedia.com) joined #handbrake-dev.
[15:46] #handbrake-dev: mode change '+o s55' by BrakeBot!~BrakeBot@rocky.lapsus.org
[16:51] [CIA-25] dynaflash * r3128 macosx/HBPreviewController.m:
[16:51] [CIA-25] MacGui: In preview only set the origin of the hud control panel for the preview window when setting the title, after that the origin will animate much smoother along with the window.
[16:51] [CIA-25] - Avoids the nasty resetting of the hud controller when the preview window resizes.
[19:08] [CIA-25] sr55 * r3129 win/C#/ (14 files in 3 dirs):
[19:08] [CIA-25] WinGui:
[19:08] [CIA-25] - Tied Microsoft StyleCop into the build process.
[19:08] [CIA-25] - Included a settings file for StyleCop so anyone who picks up the project can use the global project settings.
[19:08] [CIA-25] - Started Clearing up Warnings generated by stylecop.
[19:08] [CIA-25] - Also included Resharper 5 config files that users can use.
[19:09] [Rodeo-laptop] what's StyleCop? Some sort of automated tool to check coding style consistency?
[19:11] brianmario (~brianmari@2002:1807:3835:0:226:bbff:fe13:6693) joined #handbrake-dev.
[19:11] [s55] basically yes
[19:12] [Rodeo-laptop] so we're going to see some more code refactoring soon?
[19:12] [Rodeo-laptop] :-)
[19:12] [s55] http://stylecopforresharper.codeplex.com/
[19:12] [s55] thats a plugin for resharper that I sue
[19:12] [s55] use
[19:13] [s55] Makes clearing up style issues really fast with keyboard shortcuts
[19:13] [s55] stylecop homepage
[19:13] [s55] http://code.msdn.microsoft.com/sourceanalysis
[19:13] [s55] I figured I should probably try clear things up and make everything a bit more consistant
[19:14] [s55] Probably just do refactoring as I go along / get bored
[19:14] [Rodeo-laptop] how is getting modulus support in all modes going?
[19:14] [s55] done
[19:14] [s55] it's in
[19:14] [s55] I just enabled the dropdown for all modes apart from strict and the preset code already loads in modulus for everything anyway
[19:15] [Rodeo-laptop] oh right - since there was "in progress" in the commit message, I though it was only partly done
[19:15] [s55] cli query generators been hooked up to pass it through
[19:15] [s55] just refactoring in progress
[19:15] [Rodeo-laptop] so there's very little blocking a snapshot now
[19:15] [Rodeo-laptop] aside from dyna's ongoing struggle with live preview
[19:15] [s55] yeh
[19:15] [s55] gotta disappear for 15
[19:16] *** Rodeo-laptop wonders if we could get some last-minute preset changes for the snapshot
[19:16] [Rodeo-laptop] like adding decomb to the built-ins
[19:18] [dynaflash] live preview doesn't have to block a snapshot, afaic its better than it was
[19:19] [Rodeo-laptop] well, unless the snapshot happens this weekend, we might as well get your latest chnages in
[19:24] [dynaflash] yeah, found another scenario where it borks
[19:32] [s55] Decomb on by default?
[19:32] [s55] not slow down the encode a tad?
[19:35] [jbrjake] do not want to add decomb to more presets at this time
[19:36] [jbrjake] working on improvements to it that will change its output and would rather not expose more people to the old method right before it changes
[19:36] [s55] sounds cool
[19:38] [jbrjake] i think i've got it now to where it should be possible to amp up the sensitivity without getting more false positives on progressive frames
[19:58] [Rodeo-laptop] awesome
[19:58] [Rodeo-laptop] that's what you've been working on all this time you weren't o IRC, decomb 3.0?
[19:58] [Rodeo-laptop] :-)
[19:59] ritsuka (~Ritsuka@host246-247-dynamic.33-79-r.retail.telecomitalia.it) left irc: Quit: ritsuka
[20:15] *** dynaflash should have f'ing made a diff when he though it was working right :\
[20:15] [Rodeo-laptop] dynaflash should use git
[20:16] [dynaflash] don't start with me
[20:16] [dynaflash] lol
[20:19] [s55] or local svn server
[20:19] [s55] less head on table incidents
[20:23] [dynaflash] well, a simple diff would have sufficed
[20:28] [s55] hmm, I think our VLC link-in has caused the VLC guys a few support headaches
[20:28] [s55] we have our own sticky in their mac forum
[20:28] brianmario (~brianmari@2002:1807:3835:0:226:bbff:fe13:6693) left irc: Quit: brianmario
[20:42] [Rodeo-laptop] lol
[20:42] [Rodeo-laptop] makes sense - we must be a PITA for them - though of course if they hadn't released an 64-bit build before it was ready&
[20:43] [s55] well, it's not like we havn't released crappy builds
[20:58] zukavski (~zukavski@c-76-127-154-68.hsd1.nh.comcast.net) left irc: Ping timeout: 240 seconds
[21:33] s55 (~Scott@cpc1-livi1-0-0-cust180.sgyl.cable.virginmedia.com) left irc: Read error: Connection reset by peer
[21:40] s55 (~Scott@cpc1-livi1-0-0-cust180.sgyl.cable.virginmedia.com) joined #handbrake-dev.
[21:40] #handbrake-dev: mode change '+o s55' by HandBot!~HandBot@concorde.lapsus.org
[21:40] zukavski (~zukavski@c-76-127-154-68.hsd1.nh.comcast.net) joined #handbrake-dev.
[22:01] bogo_lode (~bogo_lode@75.108.108.82) joined #handbrake-dev.
[22:59] [CIA-25] sr55 * r3130 win/C#/ (12 files in 4 dirs):
[22:59] [CIA-25] WinGui:
[22:59] [CIA-25] - Some tweaks to the StyleCop Settings File.
[22:59] [CIA-25] - Some abbreviations added to the ReSharper config file.
[22:59] [CIA-25] - Some more warnings cleaned up.
[23:04] [BradleyS] jbrjake: i sent you some decomb material awhile back, should i resend?
[23:12] [BradleyS] here's one http://drop.io/lqfllpt
[23:30] [CIA-25] sr55 * r3131 win/C#/ (38 files in 8 dirs):
[23:30] [CIA-25] WinGui:
[23:30] [CIA-25] - Cleanup more StyleCop warnings.
[23:33] [jbrjake] BradleyS: thanks, but i still have that one from the last time you upped it
[23:40] [BradleyS] jbrjake: ok cool. did that strike you as a problem source?
[23:55] Creteil (bigbob@vlm28-1-88-177-120-215.fbx.proxad.net) joined #handbrake-dev.
[23:59] Creteil (bigbob@vlm28-1-88-177-120-215.fbx.proxad.net) left #handbrake-dev.
up
Generated by logs2html module for eggdrop v.2.3.4
Find latest version at http://sourceforge.net/projects/logs2html or http://shmupsik.osetia.org