Main page
[00:00] [brianmario] interesting: http://kovensky.project357.com/builds/mplayer/git/20090514-eab4b2f-2622317/ffmpeg.txt
[00:00] [brianmario] first commit in that list
[00:01] [brianmario] so I think blueray backups will/can have a lot more than 20 streams
[00:01] [brianmario] subtitles, chapters, audio, (angles?), maybe other stuff specific to the BR spec?
[00:02] [j45] that commit is dated a year ago
[00:03] [brianmario] looks like it's some guys fork, for windows builds
[00:03] [j45] is ffmpeg using git now?
[00:04] [j45] i'm still using svn with ffmpeg
[00:04] [j45] ah, that explains it
[00:04] [j45] from the official ffmpeg svn:
[00:04] [j45] r21484 | jai_menon | 2010-01-27 11:13:35 -0800 (Wed, 27 Jan 2010) | 4 lines
[00:04] [j45] Schedule an increase in the maximum number of streams
[00:04] [j45] at next libavformat major version bump.
[00:05] [brianmario] had another question too
[00:06] [brianmario] is it possible to use the HB cli to apply a watermark?
[00:06] [j45] no. though jbrjake has talked about adding watermarks once or twice
[00:07] [saintdev] j45: a lot of devs use the git repo, but svn is still the official repo
[00:12] [j45] brianmario: i'm adding a bug report in the forums for this so it doesn't get forgotten. who knows when the ffmpeg version bump will actually happen. so i think we should patch it for now.
[00:12] [brianmario] j45: cool, I think it'd be worth doing sooner than later
[00:13] [brianmario] seems pretty low risk too
[01:00] [Rodeo] Dark_Shikari, jbrjake (when you get back): latest x264_param_unparse diff, http://handbrake.fr/pastebin/pastebin.php?show=1259
[01:01] [Rodeo] same with some testing code: http://handbrake.fr/pastebin/pastebin.php?show=1260
[01:01] [Rodeo] ./x264 --test-presets
[01:20] brianmario (~brianmari@v15.corp.metainterfaces.com) left irc: Quit: brianmario
[01:34] [Rodeo] hmm, something about files produced by the latest snapshot is causing issues with tsmuxer: http://forum.handbrake.fr/viewtopic.php?f=11&t=15485&p=73265#p73265
[02:31] bogo_lode (~bogo_lode@75.108.108.82) left irc: Quit: I give up...
[03:18] [j45] the wacko fps tsmuxer is reporting is the timebase that is encoded in the h.264 stream. it, like ffmpeg, misinterprets what this value is for
[03:19] [j45] the timebase changed when we started using x264's vfr dts ability
[03:29] brianmario (~brianmari@2002:1807:3835:0:226:bbff:fe13:6693) joined #handbrake-dev.
[03:53] [Dark_Shikari] yay for programs written entirely for CFR
[05:08] Rodeo (~tim@lap34-2-82-237-95-151.fbx.proxad.net) left irc: Quit: Rodeo
[06:01] dynaflash (~dynaflash@2002:1883:b4ca:0:219:e3ff:fed3:585c) left irc: Read error: Operation timed out
[06:02] dynaflash (~dynaflash@2002:1883:b4ca:0:219:e3ff:fed3:585c) joined #handbrake-dev.
[06:47] saintdev (~saint@unaffiliated/saintdev) left irc: Quit: It's the end of the world as I know it.
[07:50] superdump (~rob@unaffiliated/superdump) joined #handbrake-dev.
[09:04] ritsuka (~Ritsuka@host135-48-dynamic.10-79-r.retail.telecomitalia.it) joined #handbrake-dev.
[09:33] brianmario (~brianmari@2002:1807:3835:0:226:bbff:fe13:6693) left irc: Quit: brianmario
[10:20] thierryp (~thierry@2a01:e35:2e2b:e2c0:226:bbff:fe18:c9c1) joined #handbrake-dev.
[10:59] jbrjake (~jbrjake@219-253.127-70.tampabay.res.rr.com) left irc: Ping timeout: 245 seconds
[10:59] jbrjake (~jbrjake@219-253.127-70.tampabay.res.rr.com) joined #handbrake-dev.
[12:24] ritsuka (~Ritsuka@host135-48-dynamic.10-79-r.retail.telecomitalia.it) left irc: Quit: ritsuka
[13:13] ritsuka (~Ritsuka@host135-48-dynamic.10-79-r.retail.telecomitalia.it) joined #handbrake-dev.
[13:46] thierryp (~thierry@2a01:e35:2e2b:e2c0:226:bbff:fe18:c9c1) left irc: Quit: ciao folks
[14:23] ritsuka (~Ritsuka@host135-48-dynamic.10-79-r.retail.telecomitalia.it) left irc: Quit: ritsuka
[14:48] Rodeo (~tim@lap34-2-82-237-95-151.fbx.proxad.net) joined #handbrake-dev.
[15:52] #handbrake-dev: mode change '+o dynaflash' by ChanServ!ChanServ@services.
[16:41] thierryp (~thierry@ANice-256-1-34-133.w90-4.abo.wanadoo.fr) joined #handbrake-dev.
[17:16] thierryp (~thierry@ANice-256-1-34-133.w90-4.abo.wanadoo.fr) left irc: Remote host closed the connection
[17:36] jbrjake (~jbrjake@219-253.127-70.tampabay.res.rr.com) left irc: Ping timeout: 245 seconds
[17:39] jbrjake (~jbrjake@219-253.127-70.tampabay.res.rr.com) joined #handbrake-dev.
[18:30] 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:43] #handbrake-dev: mode change '+o dynaflash' by ChanServ!ChanServ@services.
[18:55] thierryp (~thierry@2a01:e35:2e2b:e2c0:226:bbff:fe18:c9c1) joined #handbrake-dev.
[19:08] [dynaflash] I have kind of been thinking about this whole x264 presets business
[19:09] #handbrake-dev: mode change '+v Rodeo' by dynaflash!~dynaflash@c-75-73-86-40.hsd1.mn.comcast.net
[19:10] #handbrake-dev: mode change '+v jbrjake' by dynaflash!~dynaflash@c-75-73-86-40.hsd1.mn.comcast.net
[19:10] [dynaflash] lol. even though I know he is camping
[19:10] [Rodeo] maybe he'll manage to post from his phone
[19:11] [dynaflash] ha
[19:12] [dynaflash] anyway, in general just rambling
[19:13] [dynaflash] as long as we could unparse the x264 preset back into the gui's widgets ... I am good with it.
[19:13] [dynaflash] maybe as a separate set of presets
[19:13] [Rodeo] ?
[19:13] [dynaflash] initially
[19:13] [Rodeo] not sure what you mean tbh
[19:13] [dynaflash] well
[19:13] [dynaflash] as was talked yesterday ad nauseum
[19:14] [dynaflash] hb's advanced panel has transparency
[19:14] [Rodeo] yes
[19:14] [dynaflash] the opt string reflects the widgets and vice versa
[19:14] [dynaflash] in my own mind, this is a crucial thing for hb
[19:15] [dynaflash] however, given that
[19:15] [dynaflash] solely adopting x264's presets ( thinking particularly of device presets I guess ) ...
[19:16] [dynaflash] in my opinion makes hb's presets totally reliant upon x264
[19:17] [Rodeo] I'm perosnally against adopting x264 device presets right away
[19:17] [dynaflash] while I respect x264's dedication to keeping presets current ...
[19:17] [Rodeo] besides, they don't exist yet
[19:17] [dynaflash] I do not want hb strangled by the wims of x264 ( no disrespect intended.
[19:17] [dynaflash] well, they are coming as D_S says
[19:18] [Rodeo] yes
[19:18] [Rodeo] full support for that of course affects more than just x264opts
[19:18] [dynaflash] ... and lets face it, the device based preset in hb are pretty much the overwhelming majority of the presets commonly used. I think we can all agree on that.
[19:18] [Rodeo] since it also sets resolution, etc.
[19:18] [dynaflash] right, of course
[19:19] [dynaflash] now, I *am* interested in speed vs. compression
[19:19] [Rodeo] my opinion is that we should focus on supporting preset/tune/profile first
[19:20] [dynaflash] also, we need it displayed extremely simply unless we go to the advanced tab, where all bets are off and wizards can be wizards. An advanced video playground.
[19:20] [j45] i was thinking about that and came up with a mechanism to track the "overrides". i think the tricky part is indicating to the user what the overrides are. a simple solution is just another x264 options string display that shows only the overrides.
[19:22] [dynaflash] j45: how do we do that for the user that just says he wants "iPod/iPhone" but give them a simple speed/quality option ?
[19:22] [Rodeo] j45: and what's that meachnism?
[19:22] superdump (~rob@unaffiliated/superdump) left irc: Quit: WeeChat 0.3.2-dev
[19:22] [dynaflash] without going to an advanced opts panel/string
[19:22] [dynaflash] in my mind this is what will make it work or fail
[19:23] [dynaflash] for hb
[19:23] [dynaflash] now, consider the iPod preset ....
[19:24] [dynaflash] many of the opts can be bumped or lowered depending on > or < compression / speed
[19:24] [dynaflash] how do we do that with a slider or some such for the non opt string crowd ?
[19:26] [Rodeo] ?
[19:26] [j45] as a baseline, you need a way to zero out the overrides. so someone can say, "I want 'slower' + something" and not have to know what the defaults for 'slower' are
[19:26] [Rodeo] iPod compaitiblity mostly requires baseline profile (in terms of x264 options), and possibly a ref/level restriction
[19:27] [j45] i was thinking a checkbox that says 'allow advanced override options" or sum such thing.
[19:27] [dynaflash] j45: for the normal preset mode ?
[19:28] [dynaflash] meaning not messing with advanced ?
[19:28] [j45] then in the advanced tab, whenever the user changes a value, it is marked as an override (if they have been allowed)
[19:28] [dynaflash] hmm
[19:28] [dynaflash] that would obviously work
[19:29] [j45] when the user changes an x264 preset, only those setings marked override are re-applied after the preset defaults are set
[19:29] [dynaflash] but my concern is this"
[19:29] s55 (~Scott@cpc1-livi1-0-0-cust180.sgyl.cable.virginmedia.com) joined #handbrake-dev.
[19:29] [dynaflash] :
[19:29] [j45] you still have to indicate to the user somehow what has been overridden
[19:31] [j45] i had a couple ideas. one is that the current preset is taken to be the "default" x264 values. and you only show the overrides in the advanced panel's x264 options entry box.
[19:31] ritsuka (~Ritsuka@host135-48-dynamic.10-79-r.retail.telecomitalia.it) joined #handbrake-dev.
[19:32] [j45] another was to keep the current behavior of that box (using non-preset x264 defaults) and highlight the text in red (or whatever color you like) that differs from the current preset.
[19:32] #handbrake-dev: mode change '+v ritsuka' by dynaflash!~dynaflash@c-75-73-86-40.hsd1.mn.comcast.net
[19:32] #handbrake-dev: mode change '+o s55' by dynaflash!~dynaflash@c-75-73-86-40.hsd1.mn.comcast.net
[19:37] *** Rodeo is having a lot of trouble following
[19:38] [dynaflash] okay
[19:38] [dynaflash] well ...
[19:38] [dynaflash] I think this ...
[19:38] [dynaflash] after jbrjake gets back
[19:38] [dynaflash] we really need to sit down and figure out how this all will play into hb's preset system. As a project.
[19:41] [dynaflash] after all, its well worth noting that hb's presets encompass more than x264 opts
[19:41] [dynaflash] audio tracks, resolution, etc. etc.
[19:42] [dynaflash] mp4 opts
[19:42] [Rodeo] yes
[19:42] [dynaflash] chapters
[19:42] [dynaflash] .etc.
[19:43] [Rodeo] well, until x264 device is implemented and we decide whether to use it or not, all the settings will remain in the HB presets
[19:43] [Rodeo] and things like chapters, audio etc. always will
[19:43] [Rodeo] presumably
[19:43] [dynaflash] probably
[19:44] [Rodeo] that's why I don't like x264 device very much: it covers many things that are encoder-independent
[19:44] [Rodeo] it overlaps with HB presets
[19:44] [Rodeo] whereas x264 preset/tune/profile don't really, they're just another way to represent a set of x264 options
[19:45] [dynaflash] which is worth noting
[19:45] [Dark_Shikari] encoder independent?
[19:45] [Dark_Shikari] since when does theora work on an ipod?
[19:45] [dynaflash] how about the ipod 5g atom ?
[19:45] [Dark_Shikari] ;)
[19:45] [Rodeo] well, MPEG-4 ASP works on an iPod
[19:46] [Dark_Shikari] you mean SP. it doesn't do qpel afaik
[19:46] [Dark_Shikari] or gmc
[19:46] [Rodeo] maybe :-)
[19:46] [Dark_Shikari] dynaflash: there's nothing that says you _can't_ add it.
[19:46] [dynaflash] I know
[19:47] [Rodeo] right, MPEG-4 SP
[19:47] [Rodeo] Dark_Shikari: right. that atom is a muxer setting
[19:47] [Rodeo] how does that fit into x264 device?
[19:47] [dynaflash] well, so is ac3 in mp4
[19:48] [dynaflash] in the case of libmp4v2 and the atv preset.
[19:48] [Dark_Shikari] Rodeo: x264 device is a subset of device options
[19:48] [Dark_Shikari] in other words, there are two parts of device otpions
[19:48] [Dark_Shikari] 1) things handbrake has to do
[19:48] [Dark_Shikari] 2) things the encoder has to do
[19:48] [Dark_Shikari] x264 can handle 2).
[19:50] [dynaflash] so, in this instance hb would use x264's encoder device opts, and hb would handle the muxer, res stuff
[19:50] [Dark_Shikari] yes.
[19:50] [dynaflash] including audio ?
[19:50] [Dark_Shikari] yes.
[19:51] [dynaflash] including rf ?
[19:51] [Dark_Shikari] RF is not a device compatibility issue, ever.
[19:51] [dynaflash] maybe not to x264's presets
[19:51] [Dark_Shikari] RF=0 sets lossless, lossless is a compatibility issue, and x264's --profile setting already handles that.
[19:51] [dynaflash] but I would beg to differ for hb's presets
[19:51] [Dark_Shikari] Why?
[19:52] [dynaflash] simple, we know within reason what rf values are safe for a given device
[19:52] [Dark_Shikari] that's stupid
[19:52] [dynaflash] ... that we support
[19:52] [Dark_Shikari] that is simply outright wrong
[19:53] [dynaflash] oh ?
[19:53] [Dark_Shikari] the only correct way to represent that is via VBV
[19:53] [Dark_Shikari] simply a "range of RF values that are safe" is pure guessing
[19:53] [dynaflash] no
[19:53] [Dark_Shikari] you're making a bet that it won't go over the max bitrate
[19:53] [dynaflash] its from much empiricle testing on a given device
[19:53] [Dark_Shikari] and I can tell you for sure, that if I take handbrake defaults
[19:53] [Dark_Shikari] if I cat /dev/random into handbrake on the ipod preset
[19:53] [Dark_Shikari] IT WILL NOT PLAY ON AN IPOD.
[19:54] [dynaflash] corner case imo
[19:54] [Dark_Shikari] that's stupid. just enable vbv
[19:54] *** dynaflash has done much vbv as you know
[19:54] *** Rodeo wonders why we're debasting about a feature that hasn't made it into x264 yet when we haven't agreed on things that apply before said feature
[19:55] [dynaflash] so Dark_Shikari: what would you propose for the atv preset in light of a sane rf value ?
[19:55] [Dark_Shikari] VBV
[19:55] [Dark_Shikari] Like we spent like 2 fuckign weeks testing
[19:55] [Dark_Shikari] lol
[19:55] [dynaflash] That a typical user would use
[19:55] [Dark_Shikari] VBV
[19:55] [Dark_Shikari] stick that in the preset requirements
[19:55] [dynaflash] ya, I kmnoiw
[19:56] [dynaflash] know even
[19:56] [dynaflash] so, the preset has no rf value to apply ? just vbv ?
[19:57] [dynaflash] which I know as well as you that said rf producing x bitrate against the vbv would produce cbr ?
[19:57] [Dark_Shikari] yes, if you set rf=1, it would produce CBR
[19:57] [Dark_Shikari] Of course, handbrake can make its own UI decisions
[19:57] [Dark_Shikari] you could say "fuck it, no RF below 10"
[19:57] [Dark_Shikari] in order to make your lives easier
[19:58] [dynaflash] or on sd vbv would produce generally cbr on an rf of 15
back next →
1 2 3
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