Back to Home / #mythtv / 2002 / 10 / Prev Day | Next Day
#mythtv IRC Logs for 2002-10-03

00:05<mdz>CVS wanted libvorbis, that was gladly provided. otherwise it built fine
00:05<mdz>the current mythtv installation is in use now, though, so I'll have to test it another time
00:06<Chutt>ah, yeah, libavcodec added that, i think
00:06<mdz>yep
00:07<mdz>heh, just watching recorded material uses less than 1% CPU
00:11<mdz>I was thinking recently about the possibility of using different encoding parameters depending on whether playback was happening at the same time
00:11<mdz>it seems like I could bump up the quality for recordings when I wouldn't ever be watching
00:12<Chutt>i'm going to be working on adding support for stuff like that next
00:12<mdz>oh, nice
00:12<Chutt>well, at least different quality levels and the like
00:13<Chutt>yet another big database change
00:15<mdz>now is the time for it
00:15<Chutt>heh
00:16<Chutt>so, think you can build debs of this stuff?
00:16<mdz>yeah, definitely. I just need to sit down and do it
00:16<mdz>I've got too many projects going on at once
00:16<Chutt>heh, that's cool
00:16<mdz>hopefully this weekend I can work on it
00:17<Chutt>whenever, though, really
00:17<mdz>basic packages, which left the database creation up to the user, should be pretty straightforward
00:17<Chutt>cool.
00:17<mdz>down the road it could set up the database and such as well
00:17<Chutt>having a package for one distro would help a bit
00:17<mdz>it should be possible to make it entirely plug-and-play...at this point in the development, that could be a good thing or a bad thing :-)
00:17<Chutt>then i can just tell people to try that
00:18<mdz>on the upside, you could get a lot more people trying it. on the downside, you could get a lot more people trying it and not getting it to work.
00:18<Chutt>yup
00:18<mdz>(or not work the way they expect)
00:19<mdz>is the copy of libavcodec in the source tree entirely stock, or is it modified from the original?
00:20<Chutt>it's slightly modified
00:20<mdz>ok, I'll be sure to use that one instead of linking against a packaged version
00:20<Chutt>i made a couple global static variables not global static variables
00:20<Chutt>i need to finish that up and submit a patch to the ffmpeg guys
00:21<mdz>ffmpeg doesn't seem very active these days
00:21<Chutt>threadsafety issues =)
00:21<Chutt>it's fairly active
00:21<Chutt>i resync with their cvs tree every couple days, generally
00:21<mdz>ah, I can't keep up with anything except releases on that front
00:22<mdz>the current release stuff is great until you actually want to watch the stuff you've encoded, at which point the A/V sync makes you crazy
00:22<Chutt>really?
00:22<Chutt>it's pretty much exact for me
00:22<mdz>hmm
00:22<mdz>you do have a faster machine...not that much faster, though
00:22<Chutt>nope
00:23<mdz>what made you decide to go with nuppelvideo instead of ffmpeg?
00:24<Chutt>the av sync =)
00:24<mdz>heh
00:24<Chutt>even though someone's rewritten it since then
00:24<mdz>that's what I would have said, but if ffmpeg worked for you...
00:24<Chutt>that was one of the first contributions i got, was some guy re-did the a/v sync code and rewrote most of the player class
00:25<Chutt>nuppelvideo was the only thing that kept decent sync when i was testing back in may
00:25<mdz>especially if you're dropping a frame once in a while
00:25<mdz>ffmpeg doesn't seem to handle that situation very gracefully
00:27<mdz>what settings do you generally use for capture? if I assume that the defaults are the defaults because they're what you use, then you use rtjpeg at 640x480? how much CPU does that take on your system?
00:27<Chutt>640x480 mpeg4 @ 2800 kbps nowadays
00:27<Chutt>capturing alone takes 35-40% cpu
00:28<Chutt>capturing 2 streams at once takes 80%
00:28<Chutt>can't capture two and play another back, though, without impacting the captures
00:28<mdz>I'd be so jealous if you could :-)
00:28<Chutt>i think an xp 2000+ could do it
00:29<mdz>that's quite reasonable for 640x480
00:29<mdz>do you get any lower CPU usage at 2800 vs. 2200, or just better quality?
00:29<Chutt>i think the cpu's about the same
00:29<mdz>I seem to recall reading somewhere that encoding performance wasn't affected too much by bitrate
00:29<Chutt>slightly less, iirc
00:29<mdz>output bitrate, that is
00:30<mdz>XPs are very reasonably priced these days
00:30<Chutt>extremely
00:30<mdz>I bought this one just so I could use my old machine for video
00:30<Chutt>but, that's another reason why i'm looking at using a smaller machine just for playback
00:31<mdz>now I'm even thinking about swapping them
00:31<mdz>I hate that motherboard, though, the one that's in the video box now. that was my other excuse
00:31<Chutt>heh
00:32<mdz>that board will take an XP...I'm not sure if it will only take certain models
00:32<Chutt>if only nvidia would put out audio drivers that support the built in dolby digital encoder on the motherboard i have
00:33<mdz>that'd be nice
00:33<mdz>it'd also be nice if hauppauge would release drivers for the PVR
00:34<Chutt>heh
00:34<Chutt>apparently
00:34<Chutt>the usb pvr is partially supported now
00:34<mdz>yuck, USB
00:34<Chutt>not by hauppauge, though
00:34<mdz>that one will only do 6mbit/sec, right?
00:34<Chutt>exactly
00:34<Chutt>yeah
00:34<mdz>not full-rate
00:35<Chutt>i'd probably buy one of their pvr cards if it was supported, though
00:35<Chutt>maybe two =)
00:35<mdz>yep
00:36<mdz>I actually bought one, and sent it back
00:36<Chutt>heh
00:36<mdz>there are drivers for another kfir board
00:36<mdz>the one at linuxtv
00:37<Chutt>heh, yeah
00:37<mdz>I think it's even more expensive than the wintv-pvr though
00:37<Chutt>but it's very expensive
00:37<Chutt>and doesn't have a tuner built in, i don't think
00:37<Chutt>anyway
00:37<Chutt>i need to get to bed sometime
00:37<Chutt>so, later =)
00:37<mdz>yeah, me too
00:37<mdz>good night
00:38-!-mdz is now known as mdz-away
05:00<-- mdz-awayhas quit (Read error: 110 (Connection timed out))
05:01--> mdz-away(~mdz@209-6-103-23.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com) has joined #mythtv
06:49-!-SadMan [sadman@212.89.225.153] has joined #mythtv
09:29-!-You are now known as mdz-work
10:32<-- mdz-awayhas quit (card.freenode.net irc.freenode.net)
10:32-!-Chutt [] has quit [card.freenode.net irc.freenode.net]
10:32-!-davehunn [] has quit [card.freenode.net irc.freenode.net]
10:33--> mdz-away(~mdz@209-6-103-23.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com) has joined #mythtv
10:33-!-Chutt [~bleh@dsl093-011-148.cle1.dsl.speakeasy.net] has joined #mythtv
10:33-!-davehunn [~david@pc1-mars1-4-cust156.mid.cable.ntl.com] has joined #mythtv
15:11<vektor>Chutt: I remember when I first found QString.
15:11<vektor>Chutt: I used it everywhere.
15:11<vektor>Chutt: However, I think your code would be a bit cleaner if you didn't. ;-)
15:11<Chutt>err
15:12<Chutt>whatever
15:12<Chutt>it does utf-8, unlike the c++ string class
15:12<vektor>Like, ttfont.* doesn't need it..
15:12<vektor>You also use .latin1() in one place, and .ascii() in another.
15:12<vektor>Oh yeah, I didn't say use c++ strings.
15:12<Chutt>perhaps that's meant to be that way?
15:13<Chutt>the ttfont stuff really only displays latin1
15:13<vektor>Exactly, which is why I'd suggest that ttfont.h take const char *'s.
15:13<vektor>Since that's all it can (currently) do internally.
15:13<Chutt>so i'd convert externally instead of internally
15:13<vektor>Yeah.
15:14<Chutt>there's no real reason to do that
15:14<vektor>Just cleanliness.
15:14<vektor>Anyway...
15:14<vektor>Doesn't matter.
15:15<Chutt>it's cleaner to use one consistant string storage method for all external functions :p
15:15<vektor>Hah!
15:16<vektor>Fine, I'll cave. But I dunno... It just makes it harder for me to use your ttfont.*.
15:16<Chutt>that's getting rewritten to use the newer freetype, btw.
15:16<vektor>Cool.
15:16<vektor>Where?
15:16<Chutt>well, i'm not 100% sure it is
15:16<vektor>I'm going to update the merging code.
15:16<vektor>So I don't know if it matters.
15:16<Chutt>but some guy wrote to the mailing list and asked how he could help, and if that was needed
15:17<vektor>Oh.
15:17<vektor>It's ok, I'll redo work when that happens if necessary.
15:17<vektor>I just want a starting point that's all.
15:17<Chutt>ok
15:17<Chutt>you're going to update the actual drawing stuff?
15:17<Chutt>and send me back a diff? :p
15:18<vektor>um, yeah?
15:18<vektor>is that ok?
15:18<vektor>I'm just playing around with this other app I did.
15:18<vektor>It's my t pass-thru app.
15:18<Chutt>yeah, of course it's ok
15:18<vektor>I want to display some cool alpha blended text.
15:18<vektor>So I'm using your text drawing code as a starting point.
15:18<vektor>And fucking it up.
15:18<Chutt>i just want any improvements you make, that's all =)
15:18<vektor>and I think I can improve drawing quality.
15:18<vektor>And then I'll send you back my changes.
15:18<vektor>if that's ok.
15:19<Chutt>because the text rendering right now is fairly poor
15:19<vektor>I just don't want you to think I'm like leeching code and that's all ;-)
15:19<vektor>yeah i think it is.
15:19<Chutt>if i didn't want people to reuse crap, it wouldn't be GPLd
15:19<vektor>did i tell you i used to work at 'inscriber'?
15:19<vektor>we were well known for our text :)
15:19<vektor>erm, are well known :)
15:20<vektor>i learned a few tricks.
15:20<Chutt>ah, cool
15:20<vektor>where do you work, btw?
15:21<Chutt>little place called relatable
15:21<vektor>sounds wird :)
15:21<Chutt>audio recognition, mainly
15:22<vektor>oh cool!
15:22* vektoris a bit of an audio nerd :)
15:22<Chutt>heh
15:22<vektor>so you're down with signal processing?
15:22<vektor>ewww, DRM stuff
15:22<Chutt>well, not drm, really
15:22<Chutt>though it can be used for that
15:23<vektor>i'm taking a grad course on discrete time signal processing this term.
15:23<Chutt>heh, cool
15:23<vektor>but is that kind of what you're into?
15:24<Chutt>yeah
15:24* vektorlagged
15:24<Chutt>well, that and a lot of heavy-duty custom database crap
15:24<Chutt>clustering, etc
15:24<vektor>Ah, that kind of explains your mysql interest :)
15:24<Chutt>heh
15:25<Chutt>i had never used a sql database before i started messing around on mythtv
15:25-!-vektor_ [reet@u170n210.hfx.eastlink.ca] has joined #mythtv
15:25<vektor_>Less lag from home.
15:25<vektor_>Most of my signal processing experience comes from video rather than audio.
15:25<Chutt>heh
15:25<vektor_>Have you done any image processing stuff in the past?
15:25<Chutt>never touched video before mythtv, either
15:26<vektor_>Wow.
15:26<Chutt>so it's only been a few months
15:26<vektor_>Video is cool. :)
15:26<vektor_>Image resampling is weirder than audio resampling.
15:26<vektor_>Partly due to human perception of images.
15:26<vektor_>That is, sinc is great for signal reconstruction, but you can trick the eyes to do better.. ;-)
15:27<vektor_>Can I ask you a silly signal processing question? Maybe you'll know the answer...
15:27<Chutt>sure
15:28<vektor_>Say I have an impulse signal, that is, all zeros and a single one at 0.
15:28<vektor_>Is that signal correctly bandlimited?
15:28<Chutt>i have no idea =)
15:29<vektor_>Like, from what I can tell, the ideal reconstruction of that signal would be a perfect sinc...
15:29<vektor_>Oh..
15:29<vektor_>ok.
15:29<vektor_>;-)
15:29<Chutt>my signal processing knowledge is mostly just what i needed to figure out for work
15:29<vektor_>ah.
15:29<vektor_>Do you do audio recognition entirely in the frequency domain?
15:29<Chutt>nope
15:30<vektor_>ok..
15:30<Chutt>we do a bunch of stuff i can't talk about =)
15:30<vektor_>oh, sorry ;-0
15:30<vektor_>;-)
15:30<vektor_>i'm going to try and get some code done before i go home
15:30<vektor_>nice chatting with ya :)
15:31<Chutt>yea, likewise
15:31-!-vektor_ [] has quit ["too bad the scene is dead"]
15:31<Chutt>later
15:31<vektor>lates :)
15:33<vektor>ttfont corrects for aspect ratio, but only for 4/3..
15:33<vektor>afaict
15:33<vektor>so you don't handle 16:9 tvs yet i guess... no?
15:33<Chutt>right
15:33<vektor>k
15:45<vektor>Chutt: did you write this 'merge_text' function?
15:47<Chutt>part of it
15:47<vektor>which part?
15:47<Chutt>most of it?
15:48<Chutt>i don't remember
15:48<Chutt>why, what's broken?
15:50<vektor>well you have this white mode and black mode
15:50<vektor>(black == inverted)
15:50<vektor>but in the inverted mode you don't set the chroma
15:50<vektor>i'm wondering why not
15:50<Chutt>ah
15:50<Chutt>that's because i was only drawing black as an outline to the text
15:51<vektor>sure, so why not set chroma?
15:51<Chutt>seemed to look better on screen that way
15:51<vektor>you also wipe the whole chroma for four pixels, even though the text might not cover that much.
15:52<Chutt>right
15:52<vektor>but you only do that when it's fully opaque
15:52<vektor>i find that an odd algorithm
15:52<Chutt>heh
15:52<vektor>especially since it's like you're compositing onto white?
15:53<vektor>or what?
15:53<vektor> tmp1 = (255 - *src) * a;
15:53<vektor>i don't understand that.
15:53<Chutt>that's what looked best, is all
15:53<vektor>ok.
15:54<Chutt>the two lines go together
15:54<Chutt>the tmp1 + tmp2
15:55<Chutt>it's just a fairly standard way to blend two 8 bit values together, iirc
15:55<vektor>well tmp2 is blinn's division by 255 algorithm.
15:56<vektor>so it looks like you're compositing on white.
15:56<vektor>but i want to make sure that's what you're doing.
15:58<Chutt>yeah
20:54-!-kleetus [~kleetus@ip68-3-180-244.ph.ph.cox.net] has joined #mythtv
20:55<kleetus>when running the "mythfilldatabase' app...it just exits without doing anything..is there something that needs to be dne differently with xmltv?
20:59<kleetus>nevemind..hehe...i neglected to run setup
21:03<kleetus>hey vektor...thanks for the info on the juddering video...you clear up some of my questions about video and such.
21:32<Chutt>heh
21:32<Chutt>kleetus, just heed my mailing list message if you upgrade to today's cvs
21:32<Chutt>since the db changed again
21:39<kleetus>ok thanks...warning heeded..thanks!