00:08.20 | *** join/#utah elg (n=fugalh@216.31.27.110) |
00:08.20 | *** mode/#utah [+v elg] by ChanServ |
01:20.06 | *** join/#utah Dew420 (n=Nishi@c-67-164-197-204.hsd1.ut.comcast.net) |
01:21.09 | Dew420 | Evening |
01:58.10 | findlay | Morning |
01:59.17 | findlay | I'm a double uncle again |
02:01.51 | findlay | ~bach |
02:01.52 | ibot | hmm... bach is nice, fear him...mmmK? |
02:02.39 | findlay | ibot: no, bach is r0x0rz the 0rg4n |
02:02.40 | ibot | findlay: okay |
02:02.51 | findlay | ~bach |
02:02.51 | ibot | well, bach is r0x0rz the 0rg4n |
02:51.58 | tensai | well I wouldn't believe it if I didn't see it for myself |
02:52.11 | tensai | I just got a message sent by exchange and it has a proper References header |
02:52.20 | tensai | has Microsoft *finally* fixed threading? |
04:05.33 | findlay | time for math homework |
04:07.17 | *** join/#utah aioven__ (n=aioven@137.190.250.252) |
04:10.29 | Dew420 | That sounds like fun |
04:19.14 | *** join/#utah aioven (n=aioven@tristanbob.dsl.xmission.com) |
04:42.23 | *** join/#utah levi (n=user@levi.dsl.xmission.com) |
04:43.23 | levi | Good evening. |
04:55.52 | *** join/#utah Midorikawa (n=insanemo@oldoffice.bluehost.com) |
05:48.05 | *** join/#utah RyanE_ (i=Piadas@rberick.dsl.xmission.com) |
05:51.04 | *** join/#utah iWatson (n=dave@71-36-65-210.slkc.qwest.net) |
05:53.08 | *** part/#utah GodDog (n=dave@71-36-65-210.slkc.qwest.net) |
06:13.06 | *** join/#utah carrus85 (n=carrus85@216.83.145.38) |
06:28.12 | *** join/#utah carrus85 (n=carrus85@216.83.145.38) |
07:18.08 | *** join/#utah devhen_ (n=devhen@216.194.118.110) |
07:37.21 | *** join/#utah Sargun (n=Sargun@atarack/staff/sargun) |
07:50.27 | maquis | realizes she should probably go to bed sometime soon |
08:02.55 | Supaplex | real soon now? |
10:45.37 | *** join/#utah devhen|Work (n=devhen@216.194.118.110) |
11:21.32 | *** join/#utah detailiffanu (n=jmIrc-m@unaffiliated/detailiffanu) |
12:23.27 | *** join/#utah Sargun (n=Sargun@atarack/staff/sargun) |
12:23.27 | *** join/#utah unum (n=unum@70.89.247.221) |
12:23.27 | *** join/#utah fozzmoo (n=fozz@166-70-238-250.ip.xmission.com) [NETSPLIT VICTIM] |
12:23.27 | *** join/#utah herlo (n=clints@166-70-63-209.ip.xmission.com) |
12:23.27 | *** join/#utah goozbach (n=goozbach@brooks.netradius.com) |
12:23.27 | *** mode/#utah [+vv herlo goozbach] by irc.freenode.net |
13:29.09 | *** join/#utah ibot (i=ibot@pdpc/supporter/active/TimRiker/bot/apt) |
13:29.09 | *** topic/#utah is http://plug.org/irc | Channel log @ http://ibot.rikers.org/%23utah/ | UTOSC 2008 Call for Papers @http://2008.utosc.com | I'm getting too old for this |
13:29.09 | *** mode/#utah [+o ibot] by ChanServ |
13:47.57 | *** part/#utah MepT_Bblu (n=jmIrc-m@rogaleg.net) |
13:56.52 | *** join/#utah [1]ECRS401 (n=ECRS401@c-67-177-24-217.hsd1.ut.comcast.net) |
14:54.29 | *** join/#utah ibot (i=ibot@pdpc/supporter/active/TimRiker/bot/apt) |
14:54.29 | *** topic/#utah is http://plug.org/irc | Channel log @ http://ibot.rikers.org/%23utah/ | UTOSC 2008 Call for Papers @http://2008.utosc.com | I'm getting too old for this |
14:54.29 | *** mode/#utah [+o ibot] by ChanServ |
15:06.57 | *** join/#utah elg (n=fugalh@216.31.27.110) |
15:06.57 | *** mode/#utah [+v elg] by ChanServ |
15:13.38 | tensai | elg: transcoding was a bust. it saved a bit of space but took altogether too long and now the video is choppy. |
15:14.11 | elg | what kind of definition is the original channel? |
15:14.29 | tensai | hd in this case |
15:14.29 | elg | you can save gobs of space transcoding HD. transcoding SD will be much more modest |
15:14.29 | elg | 9GB/hr down to 600MB isn't big savings? |
15:14.29 | tensai | I don't think it resized anything |
15:14.30 | tensai | I went from 2.8GB to 2.3GB for 30 minutes |
15:15.54 | elg | yeah, that's no good |
15:15.57 | elg | what bitrate? |
15:17.26 | tensai | 1000 |
15:17.44 | tensai | I figured I'd try a low quality transcode first just to see what was possible |
15:18.36 | elg | i'm thinking it didn't do what you told it to do |
15:19.14 | tensai | it definitely did something for an hour |
15:21.48 | elg | by my calculations, 1000 kbit should give you on the order of 225 megs for a half hour show |
15:24.57 | elg | plus audio, but that would be some pretty intense audio (as in no way) |
15:24.57 | tensai | oh hey. there's the option to resize. |
15:24.57 | elg | resizing doesn't make a difference on final file size though |
15:24.57 | elg | will on quality. |
15:24.57 | elg | 640x480 at 1000 kbit and 1080i at 1000kbit will both have the same file size, but the quality of the smaller screen will be much better |
15:24.57 | tensai | what about this option for "Scale bitrate for frame size"? it was on by default. |
15:24.57 | elg | if it wasn't resizing, then yeah |
15:24.58 | elg | that makes sense |
15:24.58 | elg | so you're getting the same quality (roughly), and spending many more bits |
15:25.04 | tensai | I had it off |
15:25.04 | elg | well, then it doesn't account for it. :) |
15:25.04 | elg | if you can find the file in your myth data directory, run |
15:25.04 | elg | ffmpeg -i <filename> |
15:25.04 | tensai | so the bitrate is calculated for the entire frame and not relative to the number of pixels? |
15:25.04 | elg | and it will tell you what size, the bitrate, etc. |
15:25.29 | elg | bitrate is just that - bits per second used to encode the video |
15:26.00 | elg | either on average, or constant (average, or variable bitrate is better, especially when doing two-pass encoding) |
15:26.51 | elg | either way, unless you scale the bitrate with the frame size in an attempt to get roughly the same quality, you will have more pixels per bit with a larger frame size |
15:26.57 | elg | i.e. lower quality |
15:27.40 | tensai | that makes sense now. I was thinking it was all relative to the pixel, like how still images use 8 bit color or 32 bit color. |
15:27.59 | elg | cool |
15:28.11 | elg | so, if you got a 2.3G file, I'm guessing it didn't use the encoding settings you thought it did |
15:28.14 | tensai | I don't have the files any more. like a dolt I deleted them. |
15:28.28 | elg | :) |
15:29.49 | tensai | I'm transcoding another, so we'll see in an hour |
15:30.24 | tensai | is it possible to tell myth to transcode anything that's older than 5 days? |
15:30.40 | elg | sort of |
15:30.58 | elg | you can tell it to wait to auto-transcode stuff until 5 days has passed |
15:31.14 | tensai | that sounds sufficient |
15:31.27 | elg | yeah, unless you've got weeks of recordings you want to magically transcode ;-) |
15:31.31 | elg | but you could script that |
15:32.12 | tensai | I'm in no particular rush as I'm not that low on disk space |
15:32.41 | tensai | based on the file size so far (3% done), I should end up with about 450M |
15:33.16 | elg | more like it |
15:33.19 | tensai | using 640xauto and 1000kbit |
15:33.31 | elg | which i would term lowish quality |
15:33.47 | elg | maybe ok if you have the two high-quality options checked |
15:34.19 | elg | but that would take longer |
15:34.35 | elg | you know maybe I'll set mine to wait to transcode for 2 days |
15:37.05 | tensai | which two high quality options? I see 4. |
15:38.13 | elg | the top two |
15:38.18 | elg | i haven't messed with the interlace ones |
15:38.34 | elg | i don't know how that would effect non-interlaced source material |
15:39.08 | elg | for future investigation |
15:39.52 | elg | ffmpeg can tell whether the source is interleaved, so you'd *think* that it would automatically not use them when the source isn't interlaced, but I don't trust the myth devs that much |
17:16.48 | *** join/#utah elg (n=fugalh@216.31.27.110) |
17:16.48 | *** mode/#utah [+v elg] by ChanServ |
17:27.11 | *** join/#utah tiwula (n=lane@208.64.90.18.static.utahbroadband.com) |
17:42.58 | *** join/#utah lakshmi (n=lakshmi@unaffiliated/lakshmi) |
18:02.31 | *** join/#utah RyanE (i=Piadas@rberick.dsl.xmission.com) |
18:47.35 | *** join/#utah tristanbob_ (n=tristanb@ubuntu/member/tristanbob) |
18:53.20 | *** join/#utah sinuhe (n=user@kaptah.deevans.net) |
19:52.13 | *** join/#utah aioven_ (n=aioven@tristanbob.dsl.xmission.com) |
19:59.32 | *** join/#utah tristanbob (n=tristanb@ubuntu/member/tristanbob) |
21:28.54 | *** join/#utah elg (n=fugalh@216.31.27.110) |
21:28.54 | *** mode/#utah [+v elg] by ChanServ |
21:29.30 | *** join/#utah lakshmi (n=lakshmi@unaffiliated/lakshmi) |
22:10.17 | *** join/#utah aioven (n=aioven@tristanbob.dsl.xmission.com) |
22:24.57 | *** join/#utah aioven__ (n=aioven@tristanbob.dsl.xmission.com) |
22:38.20 | *** join/#utah elg (n=fugalh@216.31.27.110) |
22:38.20 | *** mode/#utah [+v elg] by ChanServ |
22:40.08 | tensai | elg: 870MB -> 250MB and the quality is acceptable |
22:41.11 | elg | w00t |
22:42.19 | tensai | that's SD. the HD went from 2.8MB down to the same 250MB, which is a behavior we established earlier. |
22:42.50 | elg | yup, you're equalizing |
22:42.53 | tensai | and I found the delayed autotranscode option. I think this'll work out well for me. |
22:43.10 | elg | i find cartoons don't do as well as other things at the same bitrate |
22:43.16 | elg | especially cartoons that pan a lot |
22:43.19 | elg | fyi |
22:43.23 | tensai | since I'm not displaying in HD, so I can lose a lot of quality and still not notice |
22:43.37 | elg | ya me too |
22:43.51 | elg | ntsc is like 640x480 |
22:44.03 | elg | and the pixels aren't even that concise |
22:45.36 | tensai | I also compared to some of the files that *ahem* a friend of mine downloaded |
22:46.01 | elg | :) |
22:46.07 | tensai | Video: mpeg4, yuv420p, 512x384, 29.97 fps(r), bitrate: 1122 kb/s |
22:46.13 | elg | in my experience most downloads are ~ 1024kbit |
23:22.02 | *** join/#utah Dew420 (n=Nishi@c-67-164-197-204.hsd1.ut.comcast.net) |