Main page
[00:20] yeager (~quassel@ubuntu/member/yeager) left irc: Ping timeout: 245 seconds
[02:36] [Rodeo] dynaflash: revision 3125 accidentally removed the dialog that shows up when attempting to quit while there are encodes in queue -> now you can quit HB while encoding, using cmd+q, without any warning (it just quits)
[02:41] [Rodeo] damn it, I can't seem to spot it
[02:52] brianmario (~brianmari@v15.corp.metainterfaces.com) left irc: Quit: brianmario
[02:55] [Rodeo] OK, it gets weird
[02:56] [Rodeo] I was able to "modify" the 3125 commit to not remove the warning and dialog, by removing both the HBPreviewController.* and PictureController.* segments (leaving only the xib chnages)
[02:57] [Rodeo] but if I remove either the HBPictureController.* segments or PictureController.* segments (not both), then the warning and dialog still goes way
[03:21] bogo_lode (~bogo_lode@75.108.108.82) left irc: Quit: I give up...
[03:46] [dynaflash] I'll fix it
[04:28] Rodeo (~tim@lap34-2-82-237-95-151.fbx.proxad.net) left irc: Quit: Rodeo
[04:35] brianmario (~brianmari@c-24-7-56-53.hsd1.ca.comcast.net) joined #handbrake-dev.
[07:29] Rodeo (~tim@lap34-2-82-237-95-151.fbx.proxad.net) joined #handbrake-dev.
[07:44] superdump (~rob@unaffiliated/superdump) joined #handbrake-dev.
[07:54] yeager (~quassel@253-210-96-87.cust.blixtvik.se) joined #handbrake-dev.
[07:54] yeager (~quassel@253-210-96-87.cust.blixtvik.se) left irc: Changing host
[07:54] yeager (~quassel@ubuntu/member/yeager) joined #handbrake-dev.
[08:18] yeager (~quassel@ubuntu/member/yeager) left irc: Remote host closed the connection
[08:57] brianmario (~brianmari@c-24-7-56-53.hsd1.ca.comcast.net) left irc: Quit: brianmario
[11:37] thierryp (~thierry@zankai.inria.fr) joined #handbrake-dev.
[15:58] [CIA-23] dynaflash * r3155 macosx/Controller.m:
[15:58] [CIA-23] MacGui: Fix pending encodes left in queue at quit warning that was borked in 3154.
[15:58] [CIA-23] - applicationShouldTerminate was trying to call a method that was removed in that revision which then aborted the rest of the shutdown logic.
[15:58] #handbrake-dev: mode change '+v Rodeo' by dynaflash!~dynaflash@2002:1883:b4ca:0:219:e3ff:fed3:585c
[15:58] [dynaflash] Rodeo: ^^^
[16:03] [Rodeo] oh thanks
[16:05] [dynaflash] sorry about that one. Never should have let it slip
[16:05] [Rodeo] too bad the bug made its way into the snapshot
[16:05] [dynaflash] yep, was just thinking that
[16:06] [dynaflash] oh well, thats what snaps are for
[16:06] [Rodeo] except it wasn't spotted by a snap user
[16:07] [dynaflash] except snaps are marked as being unstable
[16:08] [Rodeo] oh I see it's on purpose
[16:08] [dynaflash] maybe if we had more testers testing stuff instead of just devs .....
[16:08] [dynaflash] ;)
[16:09] [Rodeo] well, I would have spotted it earlier if I had still been using 3036 while that preview stuff was being sorted
[16:09] [Rodeo] if I hadn't* still been using 3036
[16:10] [dynaflash] point is its no ones fault, its life
[16:11] [Rodeo] well, it is kind of your fault though
[16:12] [dynaflash] I spose
[16:12] *** dynaflash tries to think of a git or svn repository that does not contain bugfixes for bugs introduced in previous revs
[17:56] dynaflash (~dynaflash@2002:1883:b4ca:0:219:e3ff:fed3:585c) left irc: Quit: dynaflash
[18:43] dynaflash (~dynaflash@c-75-73-86-40.hsd1.mn.comcast.net) joined #handbrake-dev.
[18:44] #handbrake-dev: mode change '+o dynaflash' by ChanServ!ChanServ@services.
[18:48] [j45] so, with libx264's new preset and tuning api, is there a way to query what the actual parameters were set were? a reverse parse like what rodeo was working on?
[18:48] [Rodeo] no
[18:48] [Rodeo] not yet at least
[18:48] [Rodeo] well, unless param2string counts
[18:49] [Rodeo] but then it's not an API function
[18:49] [j45] do we need to make our own, or is there any chance that will get into x264?
[18:49] [Rodeo] well, tbh, I haven't really submitted it
[18:49] [Rodeo] AFAIK D_S isn't opposed to it, but he'd like to hasv
[18:50] [Rodeo] have pengvado's opinion first
[18:50] [Rodeo] and he's also uncomfortable with my fucntion returning a string
[18:50] [Dark_Shikari] yes. that's bad.
[18:50] [Dark_Shikari] it should fill a callee-supplied buffer
[18:50] [Dark_Shikari] using snprintf
[18:50] [j45] does param2string do everything that needs to be done?
[18:51] [Dark_Shikari] this means you can write a macro if you want to handle printing
[18:51] [Dark_Shikari] i.e. the macro does bufferpos += snprintf ...
[18:51] [Dark_Shikari] amount of space in buffer left -= ...
[18:51] [Rodeo] I guess this should be fixed before I post it
[18:51] [Dark_Shikari] param2string( ¶m1, ¶m2, buf, size )
[18:51] [Dark_Shikari] or something
[18:52] [Rodeo] you want to make it replace param2string?
[18:52] [Dark_Shikari] er, I mean
[18:52] [Dark_Shikari] param unparse
[18:52] [Dark_Shikari] whatever
[18:52] [Dark_Shikari] no, it shouldn't replace 2string
[18:52] [Dark_Shikari] or well, actually, that might be an interesting idea
[18:52] [Rodeo] IMO they don't exactly serve the same purpose
[18:52] [Dark_Shikari] make param2string only print things different from the defaults
[18:52] [Dark_Shikari] it would make the SEI far shorter
[18:53] [Dark_Shikari] but let's not mess with that atm
[18:53] [Rodeo] well, the formatting isn't exactly the same
[18:53] [j45] maybe generalize x264_param2string so it can be used for both?
[18:54] [Dark_Shikari] dunno
[18:54] [Dark_Shikari] I don't like the idea of printing whole cqms into the output file
[18:54] [Dark_Shikari] it's retarded and redundant
[18:54] [Dark_Shikari] and the sei is already too big
[18:54] [Rodeo] yes
[18:54] [Dark_Shikari] it's causing vbv issues with tiny frames
[18:54] [Rodeo] though my function attempts to print as little cqms as possible
[18:54] [Dark_Shikari] it's still not necessary imo
[18:54] [Dark_Shikari] the cqm is already written to the bitstream
[18:55] [Rodeo] for param2string, definitely not
[18:55] [Dark_Shikari] I mean in theory, but... blegh
[18:55] [Rodeo] I should mention that my functions attempts to generate a string that's fully parseable by x264_param_prase
[18:55] [Dark_Shikari] I know
[18:55] [Rodeo] so we can't just omit cqms
[18:55] [Rodeo] OK
[18:57] [Rodeo] OK, so I'm not sure I get the idea of using a buffer and snprintf
[18:58] [Rodeo] can you elaborate?
[18:59] [j45] have you looked at x264_param2string? i think he means that, but pass the buffer in from the caller.
[18:59] [Dark_Shikari] yes
[18:59] [Rodeo] well, AFAIK param2string use sprintf
[18:59] [Dark_Shikari] the idea being that x264 should NEVER malloc a user-accesible buffer
[18:59] [Rodeo] let me chekc, it's been a while since I checked$
[18:59] [Dark_Shikari] as x264_free is not an external function
[19:00] [Dark_Shikari] or, er, a buffer that the user is responsible for freeing
[19:00] [Rodeo] that's easy enough
[19:01] [j45] snprintf limits the size written to the string to guarantee you don't overrun the buffer. so the function could take the input and length, and use snprintf to fill the buffer
[19:01] [Rodeo] yeah I think I'm starting to see how this could be done
[19:01] [Dark_Shikari] a simple macro should abstract it all
[19:01] [Rodeo] and should we return something then (like whether we were able to unparse the whole thing or not)
[19:02] thierryp (~thierry@zankai.inria.fr) left irc: Quit: ciao folks
[19:02] [Dark_Shikari] Rodeo: which should be easy enough to stick in said magic macro
[19:02] [Dark_Shikari] it'll unroll to a fuckton of C code
[19:02] [Dark_Shikari] but who cares
[19:03] [j45] Rodeo: something like, written = snprintf(s, len, .....); s+= written; len -= written; written = snprintf( ...
[19:03] [Rodeo] yep, I think I get the idea now
[19:03] [Rodeo] how about this:
[19:03] [Rodeo] int x264_param_unparse( x264_param_t *param, x264_param_t *defaults, char *buf, int size );
[19:03] [Rodeo] sound like what you have in mind?
[19:03] [Dark_Shikari] yes
[19:03] [Rodeo] OK
[19:04] [Rodeo] I may start making modifications later today
[19:04] [Dark_Shikari] it should be trivial tod o
[19:04] [Dark_Shikari] because you just have to change the writing macro
[19:04] [Rodeo] yes
[19:04] [Dark_Shikari] all the rest can stay the same.
[19:04] [Rodeo] though I don't actually have a writing macro yet
[19:04] [Rodeo] but sure
[19:04] [Dark_Shikari] so that's a find and replace on sprintf =p
[19:05] [Rodeo] pretty much, except maybe for some special cases, not sure
[19:05] s55 (~Scott@cpc1-livi1-0-0-cust180.sgyl.cable.virginmedia.com) joined #handbrake-dev.
[19:11] [Rodeo] well, OK, the function is now changed to use a caller-supplied buffer
[19:11] [Rodeo] still using sprintf, but indeed, it looks like a find and replace should do
[19:11] [Rodeo] will get on that later
[19:17] superdump (~rob@unaffiliated/superdump) left irc: Quit: WeeChat 0.3.2-dev
[19:22] #handbrake-dev: mode change '+o s55' by dynaflash!~dynaflash@c-75-73-86-40.hsd1.mn.comcast.net
[19:51] ritsuka (~Ritsuka@host32-48-dynamic.10-79-r.retail.telecomitalia.it) joined #handbrake-dev.
[19:52] [j45] so for the ui, it seems like there are 4 additional controls needed. preset (slider?), psy tuning (combo box?), fastdecode checkbox, zerolatency checkbox.
[19:53] [Dark_Shikari] zerolatency is useless for handbrake
[19:53] [Dark_Shikari] don't include it
[19:57] [Rodeo] also, profile combobox
[19:57] [Rodeo] IMO that would simplfy a lot of the presets
[19:57] [Rodeo] fewer optiins, we just use a profile at the end
[19:58] [Dark_Shikari] why not have a Compatibility combobox or something
[19:58] [Dark_Shikari] with both profiles and devices
[19:58] [Dark_Shikari] so you can do
[19:58] [Rodeo] meh
[19:58] [Dark_Shikari] "Slow"
[19:58] [Dark_Shikari] "Film"
[19:58] [Dark_Shikari] "iPod"
[19:58] [Rodeo] that overlaps with the HB preset system
[19:59] [Rodeo] just my opinion, but I don't think we should support x264's "device" or "target"
[19:59] [dynaflash] Dark_Shikari: While this may seem stupid, I gotta ask ....
[20:00] [Rodeo] would delay implementation by causing the rewrite of a lot of code which already exists in the form of HB presets
[20:00] [dynaflash] has anyone actually tested "device" against the "device" in question ?
[20:00] [Rodeo] i.e. resolution and other x264-independent settings
[20:00] [Dark_Shikari] dynaflash: we don't have --device yet
[20:00] [Rodeo] "device" doesn't exist yet
[20:00] [Dark_Shikari] we will, and it will duplicate handbrake's logic completely
[20:01] [Dark_Shikari] the eventual intention is to move all this into x264
[20:01] [Dark_Shikari] it will even tell the calling all to resize the video if necessary
[20:01] [Dark_Shikari] *calling app
[20:01] [dynaflash] hmmmm
[20:01] [dynaflash] well .....
[20:01] [dynaflash] imho you need more device testers in that case
[20:01] [Dark_Shikari] We have doom9.
[20:01] [Rodeo] granted, x264 is handBraske's principal video encoder, but Im' totally against making it "x264GUI"
[20:02] [Dark_Shikari] Rodeo: handbrake has far more features it can add
[20:02] [Dark_Shikari] IMO we should move things into libx264 that are relevant to libx264
[20:02] [dynaflash] fwiw, doom9 is shit for many of the devices hb users encode for
[20:02] [Dark_Shikari] device is relevant because it determines encoder parameters
[20:02] [Dark_Shikari] dynaflash: what?
[20:02] [Dark_Shikari] the number of ipod, appletv, etc users is very high
[20:02] [Dark_Shikari] we got a dozen devices tested on b-pyramid within a day of posting a thread
[20:03] [Dark_Shikari] back in the DXVA-issue days they had hundreds of testers
[20:03] [Dark_Shikari] And clearly, if handbrake can write good enough restrictions
[20:03] [Dark_Shikari] so can x264
[20:05] [dynaflash] I am not debating that. but the question is "should it ?"
[20:05] [Dark_Shikari] it would be useful to all sorts of applications
[20:06] [Dark_Shikari] and it provides a central place to change presets
[20:06] [Dark_Shikari] if a new device comes out, we add it, and instantly ALL x264-using applications support it
[20:06] [Dark_Shikari] without ANY MODIFICATIONS.
[20:06] [Dark_Shikari] and if there's a bug, and we fix it
[20:06] [Rodeo] if anything, that will come later
[20:06] [Dark_Shikari] it fixes all x264-using applications
[20:06] [dynaflash] but, here is my question with this hypothesis:
[20:07] [dynaflash] if a use uses the x264 supplied atv preset for hb ...
[20:07] [dynaflash] and it does not work ...
[20:07] [Dark_Shikari] You complain to us, and we fix it
[20:07] [dynaflash] then what.
[20:07] [Rodeo] we'd have to release more often
[20:07] [Dark_Shikari] er, why?
[20:07] [Dark_Shikari] Currently, if there was a bug in the appletv in handbrake 0.9.4
[20:07] [Dark_Shikari] you wouldn't release a new version
[20:07] [Rodeo] well, to update to the latest x264 tha fixes the bug?
[20:07] [Dark_Shikari] you'd just say "use svn"
[20:08] [Dark_Shikari] So nothing would change ;)
[20:08] [Rodeo] for a preset that's entirely broken?
[20:08] [Dark_Shikari] why would it be entirely broken?
[20:08] [Dark_Shikari] that would mean you did no QA
[20:09] [Rodeo] true
[20:09] [Dark_Shikari] the presets would be exactly the same, if not better than if you did them yourselves
[20:09] [Dark_Shikari] since we would get approval for anything you wanted to support
[20:09] [Dark_Shikari] since you know what you're doing with these things
[20:09] [Rodeo] thing is, as you said, x264 device would support more than just resolution
[20:10] [j45] hmmm, do we need to be able to look at a set of x264 options and deduce that they correspond to a certain x264 preset/tuning so that the ui for those controls reflects the current set of options?
back next →
1 2 3 4
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