Main page
[00:08] superdump (n=rob@unaffiliated/superdump) left irc: "WeeChat 0.3.1-dev"
[00:31] BradleyS (n=BradleyS@99-37-5-191.lightspeed.bcvloh.sbcglobal.net) left irc:
[00:33] BradleyS (n=BradleyS@99-37-5-191.lightspeed.bcvloh.sbcglobal.net) joined #handbrake-dev.
[01:00] splodge-bottom (n=roberts@inode.com) left irc: Client Quit
[01:01] BradleyS (n=BradleyS@99-37-5-191.lightspeed.bcvloh.sbcglobal.net) left irc: Client Quit
[01:04] barf (n=Dark_Shi@193.69.144.164) left irc: Client Quit
[01:07] barf (n=Dark_Shi@193.69.144.164) joined #handbrake-dev.
[01:07] barf (n=Dark_Shi@193.69.144.164) left irc: Remote closed the connection
[01:11] [CIA-23] dynaflash * r3082 macosx/Controller.m: MacGui: Queue Edit uncomment remove reloaded queue item since "somehow" I missed it on the first go round.
[01:17] bogo_lode (n=bogo_lod@75.108.108.82) joined #handbrake-dev.
[01:56] brianmario (n=brianmar@v15.corp.metainterfaces.com) left irc: Client Quit
[03:03] [Rodeo-laptop] j45: your second patch (1144) looks OK (but I only did limited testing)
[03:05] [Rodeo-laptop] fixes quite a few issues (frame splitting due to incorrect detected framerate, illegal offsets for some sources, and now you seem to always get the same output regardless of whether you have 0 bframes, bframes or bframes and bpyramid - which was not always the case before)
[03:05] [Rodeo-laptop] tested using x264, bframes off, on and bpyramid on 2 file and one DVD source so far
[03:13] [Dark_Shikari] Rodeo-laptop: nice
[03:13] [Dark_Shikari] good to see the feature was useful
[03:13] [Rodeo-laptop] very
[03:15] [Rodeo-laptop] I did notice a slight variation in one of my file sources pre- and post-patch (video is .02 s shorter, audio is .02 s long or something) - not sure what the difference means
[03:15] [Rodeo-laptop] it's a crappy source anyway, the audio is out-of-sync
[03:15] [Rodeo-laptop] regardless of whether the patch is applied or not
[03:19] [j45] Rodeo-laptop: were you able to verify that it properly handles frames that have a longer duration than init_delay? I won't split frames any more, but x264 must do some time shifting of dts in order for that to work right.
[03:19] [Rodeo-laptop] my 2 file sources suffered from many issues
[03:19] [Rodeo-laptop] basically, all the issues I mentioned (frame splitting, illegal offsets etc.)
[03:20] [Rodeo-laptop] at first glance they appear OK with the patch
[03:20] [Rodeo-laptop] except for the out-of-sync audio but that's unrelated and hppens with and without the patch
[03:20] [j45] and they play right? no kickoff?
[03:20] [Rodeo-laptop] I don't think so
[03:21] [Rodeo-laptop] I've done so many test encode I'm not sure tbh
[03:21] [Rodeo-laptop] but I'll look through them, just give me a few more minutes, now trying x264 in MKV
[03:21] [Dark_Shikari] mkv should be easy, no dts
[03:22] [j45] at some point, i want to find a video that i know has a frame with a long duration and inspect what the dts looks like for it and the frames around it
[03:22] [Rodeo-laptop] I noticed issue with one of my test sources and MKV, pre-patch
[03:22] [j45] mkv should be unchanged
[03:27] [Rodeo-laptop] with patch, bframes off is smooth (unsurprisingly I guess)
[03:30] [Rodeo-laptop] with bframes, smooth too - checking b-pyramid
[03:32] [Rodeo-laptop] OK, haven't been through all my encodes, but my problem sources seem fine
[03:33] [j45] cool
[03:33] [Rodeo-laptop] next step: try the source that had an issue with MKV (which I guess could still have it since MKV should be unchanged)
[03:54] [Rodeo-laptop] well I cannot even reproduce my MKV issue from the other day (with the same build)
[03:55] [Rodeo-laptop] though it was after an end of semester party, so I was probably drunk
[03:55] [j45] gremlins
[03:56] [Rodeo-laptop] anyway, output with your patch seems fine
[03:56] [Rodeo-laptop] for my DVD source, even identical
[04:03] [Rodeo-laptop] even in my file source, each frame appears to have the same "Current time" in QuickTime 7
[04:03] [Rodeo-laptop] despite the duration being different (I suppose the difference must be near the end, perhaps the last frame)
[04:06] [Rodeo-laptop] yeah the difference is the timestamp of the last frame, as far as I can see
[04:23] bogo_lode (n=bogo_lod@75.108.108.82) left irc: Client Quit
[04:25] brianmario (n=brianmar@c-24-7-56-53.hsd1.ca.comcast.net) joined #handbrake-dev.
[04:49] [Rodeo-laptop] j45?
[04:50] [j45] ?
[04:50] [Rodeo-laptop] OK, with your patch
[04:50] [Rodeo-laptop] as far as I can see, every frame's timestamp is the same as without our patch when bframes are off
[04:51] [j45] thanks. i'll do a little more testing myself tomorrow and then get it checked in
[04:51] [Rodeo-laptop] which i guess is a good thing
[04:51] [Rodeo-laptop] except with one source
[04:51] [Rodeo-laptop] where the duration of the last frame differs
[04:52] [Rodeo-laptop] I think I know why this happens (without understanding the underlying concepts, however)
[04:52] [Rodeo-laptop] your code does:
[04:52] [Rodeo-laptop] / The last frame has no next frame, so derive it's duration
[04:52] [Rodeo-laptop] + // from the frame rate
[04:52] [Rodeo-laptop] + duration = 90000. / ((double)job->vrate / (double)job->vrate_base);
[04:53] [Rodeo-laptop] but since handBrake misdetects the frame rate for that source, the result is a frame with a very short duration
[04:53] [Dark_Shikari] Rodeo-laptop: last frame's duration should be equal to the previous frame's duration
[04:53] [j45] the durations are computed differently, but the sum of durations and offset are going to be the same for ever frame but the last
[04:53] [Dark_Shikari] for one-frame videos, it should be equal to inverse framerate
[04:54] [Rodeo-laptop] OK
[04:55] [Rodeo-laptop] well, as far as I can see it's not
[04:55] [Rodeo-laptop] next to last frame goes from 02:16.83 -> 02:16.88, last frame 02:16.88 -> 2:16.90
[04:56] [Rodeo-laptop] (in QT 7)
[04:56] [Rodeo-laptop] this is not a big deal, just the only case where pre-patch and post-patch don't match
[04:56] [j45] the way i did it, last frame duration is inverse frame rate
[04:57] [Rodeo-laptop] but what is "frame rate" if the source is VFR?
[04:57] [Rodeo-laptop] and if what HandBrake detected as "frame rate" is far from even the average frame rate of the source?
[04:58] [j45] i could have done it the way Dark_Shikari suggests, but that would require saving the duration of each frame in case it is the second to last for use in the last frame
[04:59] [Rodeo-laptop] also, I was able to get the same output as pre-patch by replacing the line with the old line:
[04:59] [Rodeo-laptop] duration = buf->stop - buf->start;
[04:59] [Rodeo-laptop] but of course this isn't necessarily right either
[04:59] [Rodeo-laptop] just the same as before
[04:59] [j45] we always set the rate to something. it may not be accurate tho
[04:59] [Rodeo-laptop] yeah that's what I mean - for most MKV sources, frame rate won't be accurate
[04:59] [Rodeo-laptop] well, not necessarily most but many
[05:00] [j45] also, I was able to get the same output as pre-patch by replacing the line with the old line <-- I was thinking about changing it to do this
[05:01] [Rodeo-laptop] for some reason that line seems to get the last frame's duration closer to the source's real framerate
[05:02] [Rodeo-laptop] or something along those lines
[05:02] brianmario_ (n=brianmar@c-24-7-56-53.hsd1.ca.comcast.net) joined #handbrake-dev.
[05:06] [Rodeo-laptop] and chnaging the line to do that also has the side effect of matching the times you get if you use ffmpeg as the encoder
[05:10] [Rodeo-laptop] anyway, you know a lot more about this than I do, plus the duration of the last frame probably isn't important unless there are side effects I don't know about
[05:10] [Rodeo-laptop] so, good night everyone
[05:10] Rodeo-laptop (n=tim@adsl-84-227-233-83.adslplus.ch) left #handbrake-dev.
[05:13] saintdev (n=saint@unaffiliated/saintdev) joined #handbrake-dev.
[05:13] #handbrake-dev: mode change '+v saintdev' by BrakeBot!n=BrakeBot@rocky.lapsus.org
[05:19] brianmario (n=brianmar@c-24-7-56-53.hsd1.ca.comcast.net) left irc: Read error: 113 (No route to host)
[05:19] brianmario_ (n=brianmar@c-24-7-56-53.hsd1.ca.comcast.net) left irc: Client Quit
[06:52] brianmario (n=brianmar@c-24-7-56-53.hsd1.ca.comcast.net) joined #handbrake-dev.
[07:09] [j45] long detailed article about handbrake for windows http://www.maximumpc.com/article/features/handbrake
[07:14] [Dark_Shikari] wow, I looked at the stats again
[07:14] [Dark_Shikari] nearly 3 million downloads of handbrake
[07:14] [dynaflash] we suck
[07:14] [Dark_Shikari] 0.9.4
[07:32] saintdev (n=saint@unaffiliated/saintdev) left irc: "It's the end of the world as I know it."
[07:32] [dynaflash] lol. this is bullshit from that article:
[07:32] [dynaflash] "There are a few different reasons why your rip may have turned out bad. First and foremost, make sure you're not trying to tap into your CPU's cycles while encoding."
[07:32] [dynaflash] lol
[07:33] [dynaflash] if that were the case none of my stuff would work
[07:34] [j45] it's windows. doing 2 things at once has always been dicy :p
[07:34] [dynaflash] ha, otherwise probably one of the more in depth articles I have seen. pretty good really.
[07:38] [dynaflash] frankly for the ps3, xbox, psp blah blah owners we should just link to it.
[07:47] superdump (n=rob@unaffiliated/superdump) joined #handbrake-dev.
[07:47] #handbrake-dev: mode change '+v superdump' by BrakeBot!n=BrakeBot@rocky.lapsus.org
[07:59] berylium (n=berylium@173-11-180-153-houston.txt.hfc.comcastbusiness.net) joined #handbrake-dev.
[08:03] brianmario (n=brianmar@c-24-7-56-53.hsd1.ca.comcast.net) left irc: Client Quit
[08:16] berylium_home (n=berylium@173-11-180-153-houston.txt.hfc.comcastbusiness.net) left irc: Read error: 113 (No route to host)
[08:23] brianmario (n=brianmar@c-24-7-56-53.hsd1.ca.comcast.net) joined #handbrake-dev.
[08:59] ritsuka (n=Ritsuka@host137-240-dynamic.27-79-r.retail.telecomitalia.it) joined #handbrake-dev.
[08:59] #handbrake-dev: mode change '+v ritsuka' by BrakeBot!n=BrakeBot@rocky.lapsus.org
[09:05] [ritsuka] j45: I got a lot of negative offsets in mp4 with your latest patch on a vfr source, obviously all the players read the file the same way, but it's not a nice thing to have :)
[09:24] brianmario (n=brianmar@c-24-7-56-53.hsd1.ca.comcast.net) left irc: Client Quit
[10:15] mduell__ (n=mduell@cpe-72-20-146-25.cmts2.phonoscopecable.net) left irc: Client Quit
[11:36] BradleyS (n=BradleyS@99-37-5-191.lightspeed.bcvloh.sbcglobal.net) joined #handbrake-dev.
[13:05] splodge-bottom (n=roberts@inode.com) joined #handbrake-dev.
[14:37] thierryp (n=thierry@zankai.inria.fr) joined #handbrake-dev.
[14:39] ritsuka (n=Ritsuka@host137-240-dynamic.27-79-r.retail.telecomitalia.it) left irc:
[16:38] barf (n=Dark_Shi@193.69.144.164) joined #handbrake-dev.
[16:40] [j45] hmm, negative offset would mean x264 gave us a dts that is larger than the pts for the same frame. need a sample of that source.
[17:16] superdump (n=rob@unaffiliated/superdump) left irc: "WeeChat 0.3.1-dev"
[17:25] thierryp (n=thierry@zankai.inria.fr) left irc: Read error: 110 (Connection timed out)
[17:31] [j45] Dark_Shikari: i was afraid this might be the case. x264 isn't handling long frames properly and returning a DTS that is after the PTS for them
[17:31] [j45] eg. init_delay 4504 offset -3, PTS 355853, DTS 355856 frame duration 4507
[17:50] [Dark_Shikari] that doesn't make sense
[17:50] [Dark_Shikari] x264 doesn't change timestamps
[17:51] [Dark_Shikari] ever
[17:51] [Dark_Shikari] dts are just reordered pts
[17:51] [j45] It doesn't need to change timestamps. when there are long frames, re-ordering will create this situation
[17:52] [j45] i think a simple solution is:
[17:52] [j45] if (pts < dts)
[17:52] [j45] dts = pts
[17:52] [j45] pts will not change, so presentation will be correct
[17:53] [j45] and it's ok to shorten the duration between dts as long as it doesn't get shorter than the decoder permits. since these are long frames, that won't happen
[17:55] splodge-bottom (n=roberts@inode.com) left irc: Client Quit
[17:56] [Dark_Shikari] I don't think its possible for pts to be less than dts unless the pts input to libx264 is nonmonotonic
[17:56] [j45] nonmonotonic?
[17:58] [Dark_Shikari] monotonically increasing PTS means
[17:58] [Dark_Shikari] for any frame X
[17:58] [Dark_Shikari] PTS(X) > PTS(X-1)
[17:59] [Dark_Shikari] Yes, I have found test files where this isn't true
[17:59] [Dark_Shikari] if it's not true, the file is broken
[17:59] [Dark_Shikari] (frame X in display order, of course, not coded)
[18:00] [Dark_Shikari] so make sure that your input pts are valid
[18:00] [Dark_Shikari] (btw, what x264cli does is that if pts are nonmonotonic, it prints a warning to the log and pretends that the next frame is equal to (previous frame's PTS) + (1/fps))
[18:11] [j45] i know my pts's are good. and monotonic
[18:12] [j45] i think we need to run through an example, but illustrating what i mean is difficult for me
[18:13] [j45] I think and example where you have 4 frames in display order I B B P of duration 1 1 3 1 generates the problem
[18:13] [Dark_Shikari] talk to kierank, vfrmaniac, or kemuri9
[18:13] [Dark_Shikari] they know more about the dts handling than I do
[18:14] [j45] coding order would be I P B B with dts 0 1 4 5 and pts 0 1 2 5
[18:14] [j45] 2 < 4
[18:15] [Dark_Shikari] as I said, talk to them, they'd know more about how to come up with a solution than me
[18:15] [j45] ok
[18:34] brianmario (n=brianmar@v15.corp.metainterfaces.com) joined #handbrake-dev.
[18:39] thierryp (n=thierry@home.parmentelat.net) joined #handbrake-dev.
[18:39] thierryp (n=thierry@home.parmentelat.net) left irc: Remote closed the connection
[18:39] thierryp (n=thierry@home.parmentelat.net) joined #handbrake-dev.
[19:03] splodge-bottom (n=roberts@inode.com) joined #handbrake-dev.
[19:18] splodge-bottom (n=roberts@inode.com) left irc: Client Quit
[19:20] splodge-bottom (n=roberts@inode.com) joined #handbrake-dev.
[19:22] thierryp (n=thierry@home.parmentelat.net) left irc: Remote closed the connection
[19:48] Bebbo (n=Bebbo@78.32.184.5) joined #handbrake-dev.
[19:51] s55 (n=Scott@cpc1-livi1-0-0-cust180.sgyl.cable.virginmedia.com) joined #handbrake-dev.
[20:07] thierryp (n=thierry@home.parmentelat.net) joined #handbrake-dev.
[20:22] thierryp (n=thierry@home.parmentelat.net) left irc: Client Quit
[20:22] splodge-bottom (n=roberts@inode.com) left irc: Client Quit
[20:27] Nathan73 (n=trafficb@p5DDF9E5A.dip.t-dialin.net) joined #handbrake-dev.
[21:05] berylium_work (n=john@69.15.172.241) joined #handbrake-dev.
[21:15] ritsuka (n=Ritsuka@host137-240-dynamic.27-79-r.retail.telecomitalia.it) joined #handbrake-dev.
[21:16] #handbrake-dev: mode change '+v ritsuka' by BrakeBot!n=BrakeBot@rocky.lapsus.org
[21:41] [ritsuka] j45: x264 is giving us the right pts/dts, but mp4 needs a positive offsets, and the only way to make it so for vfr source is to know all the offsets of all frames. That's how I did it in my mp4 muxer. So the easiest solution is too store all the offsets in an array and add them at the end of the encoding with MP4SetSampleRenderingOffset()
[21:51] brianmario (n=brianmar@v15.corp.metainterfaces.com) left irc: Read error: 54 (Connection reset by peer)
[21:53] brianmario (n=brianmar@v15.corp.metainterfaces.com) joined #handbrake-dev.
[21:53] Bebbo (n=Bebbo@78.32.184.5) left #handbrake-dev.
[22:06] [j45] ritsuka: x264 intended to give dts that are always less than pts. when that works, offset is as simple as pts - dts
[22:08] [ritsuka] mmm
[22:08] [ritsuka] do you have to pass and init_delay to x264?
[22:11] [ritsuka] if yes, then that's the problem, because I don't know how you can know what it would be before knowing all the frames duration
[22:14] [j45] no. the problem is that some frames are longer than init_delay and cause a condition where pts for the frame is < dts. You can fix this by truncating dts down (set dts = pts). the presentation doesn't change since you are not modifying pts. you just shortened the time till the next frame is given to the decoder. this is fine as long as you don't accumulate slip and end up with too many decoded frames waiting to be displayed
[22:14] [ritsuka] yes, that's why I said you can't know exactly what the init_delay will be
[22:15] [j45] my point is you don't need to know
[22:15] [j45] adjustments can be made to dts to avoid problems without knowing
[22:15] [ritsuka] my point is that you need, because if you truncate it in mp4 you would change even the pts
[22:16] [j45] you adjust the render offset in the opposite direction so pts does not change
[22:16] [j45] offset = pts - adjusted_dts
[22:17] [ritsuka] pts = dts + offset
[22:17] [j45] and ...
[22:19] [j45] i don't see what you are trying to illustrate with that. it just seems to validate my point
[22:19] [ritsuka] and if you change the offset the pts will not be the same, so I can't understand what you are saying
[22:20] [ritsuka] mm ok I understood
[22:20] [ritsuka] or not
[22:20] [ritsuka] but I am not really sure about your reasoning
[22:21] [ritsuka] isn't the point of vfr to pass the duration of the frame without altering it? if you start changing everything let's just keep using cfr&
[22:21] [j45] pts = offset + dts. lets give them some values, pts 10, dts 15. this gives offset -5 which is invalid. so make adjusted_dts 10. now offset is 0 and pts is still 10
[22:22] [j45] because pts = offset + adjusted_dts
back next →
1 2
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