MythLogBot@irc.freenode.net :: #mythtv

Daily chat history

Current users (75):

aloril, Anssi, anykey_, brfransen, cesman, Chutt, clever, coling, Cougar, danielk22, dblain_, dekarl, drussell_, ElmerFudd, fetzerch, foobum, frankster, ghoti, gracent, gregL, GreyFoxx, gryffus, IReboot, J-e-f-f-A, jams, jarle, jarryd, jaug0rd0r, jheizer, joe___, joki, jpabq, jpabq_, jpharvey, jst, jwhite, kc, Kevin`, knightr_, kurre2, kwmonroe, laga, lentferj, Merlin83b, mrand, MythBuild, MythLogBot, neufeld, NightMonkey, Peitolm, Peps, petefunk, poptix, purserj, rhpot1991, rsiebert_, seld, Sharky112065, skd5aner, sl1ce, SmallR2002_, sphery, sraue, SteveGoodey, superm1, tgm4883, Tobbe5178, toeb, tonsofpcs, tris, wagnerrp, wahrhaft, wolfgang1, XDS2010_, _charly_
Wednesday, January 23rd, 2013, 00:03 UTC
[00:03:08] stichnot: gigem: the bulk of my personal changes are for the greatly expanded playback group settings :)
[00:14:52] stichnot: sphery: all this so I can zoom in on my kid in a grainy concert video :)
[00:17:09] stichnot: Another question. The zoom settings are limited to the range 0.5 .. 2.0. This isn't enough. Any thoughts on a more appropriate limit?
[00:18:42] sphery: stichnot: I think Captain_Murdoch did the zoom code, might want to check with him
[00:19:55] sphery: If you have a nice way to allow--and to show in the UI--unbounded zooms (or at least only bounded by pixels :), I think that would be fine
[00:19:59] stichnot: Not to mention that the wrapping behavior is silly. If your zoom factor is 2.0 and you try to zoom in, it wraps to 1.0, but then zooming out from 1.0 puts you at 0.95. There probably shouldn't be any wrapping at all.
[00:20:21] sphery: wrapping does sound strange in zooming
[00:22:10] Captain_Murdoch: I wrote the manual zoom years ago when I got fed up with election and weather updates on the screen resizing my video down to the top right or left 3/4 of the screen. manual zoom let me zoom in on that section and totally ignore the election updates from 3 months ago when the recording was made. :) I think my original code has been changed a bit over time. I don't see a need for wrapping, but can't recall if that's my code/id
[00:22:10] Captain_Murdoch: ea or not. :|
[00:22:45] stichnot: Captain_Murdoch: thanks, I may have a go at it.
[00:24:02] stichnot: zoom is very cool in any case.
[00:24:32] Sharky112065 is now known as Sharky-AFK
[00:25:31] stichnot: I may leverage it for the problem of the green line at the bottom of 1080i HDPVR recordings (the reason I have my STB locked to 720p)
[00:31:55] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 260 seconds)
[00:36:14] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[00:39:34] jpabq: Captain_Murdoch: I make use of manual zoom every time I watch ESPN. I *HATE* the "bottomline". Locally, I patch it to cut the increments in half, so I can more accurately just move the bottomline off the screen. I have thought about committing that, but assume the default amounts where chosen for a reason.
[00:42:31] jpabq: I am honestly not sure I would even watch ESPN if I didn't have that feature.
[00:52:06] stichnot: jpabq: your increment is 2.5%?
[00:54:24] jpabq: stichnot: I would have to look. I pretty much cut in half what is ever there. I will email you the patch.
[00:57:53] stichnot: jpabq, Captain_Murdoch: When using zoom, I would also appreciate OSD feedback on the current zoom setting. I'll think about how to present that.
[01:14:17] Captain_Murdoch: I can't remember if you could only use up/down in the initial patch, so 5% was probably just to keep the user from having to hit up 10–20 times to zoom into that 3/4 box with the video in it. I only use it occasionally now but would be fine with any enhancements even bumping the increment down to 2% or so if it makes sense.
[01:14:28] stichnot: jpabq: I see, you made the up/down/left/right shift increment to be 1 pixel instead of 2 but the zoom factor is the same as before (5%)
[01:18:31] sphery: stichnot: the green line at the bottom of 1080i isn't the old "it's really 1088 high in the mpeg, but we're only supposed to display 1080", is it?
[01:19:09] sphery: jpabq: FWIW, I'd love to have smaller increments for manual zoom and position :)
[01:20:32] joki (joki!~joki@p54864E07.dip.t-dialin.net) has quit (Ping timeout: 252 seconds)
[01:21:06] joki (joki!~joki@p54864EC6.dip.t-dialin.net) has joined #mythtv
[01:21:13] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 244 seconds)
[01:21:40] sphery: we could do like we did with time stretch--where we use LEFT/RIGHT to go down/up in small increments or DOWN/UP to go down/up in large increments (hit a for adjust time stretch, then right for 0.05x or up for 0.25x)
[01:28:26] jpabq: sphery, Captain_Murdoch, sticknot, I will go ahead a commit the smaller increment change — then if anyone wants to tweak it further, they can.
[01:32:16] jpabq: Heh, I ended up missspelling stichnot. That's what he gets for going offline.
[01:54:29] tonsofpcs: #11207
[01:54:29] ** MythLogBot http://code.mythtv.org/trac/ticket/11207 **
[01:59:33] tonsofpcs: whoops, forgot -j, this'll take a while. Oh well.
[02:01:13] skd5aner: ctrl-c, make clean, make -j#
[02:01:32] skd5aner: make clean isn't probably even necessary, but I do it
[02:05:29] tonsofpcs: eh, it's not like I'll be swapping backends til tomorrrow morning anyway
[02:05:40] tonsofpcs: (and it's already done)
[02:09:00] lentferj (lentferj!~lentferj@p579B7C86.dip.t-dialin.net) has quit (Ping timeout: 252 seconds)
[02:10:13] lentferj (lentferj!~lentferj@p579B7DE1.dip.t-dialin.net) has joined #mythtv
[02:11:49] stichnot (stichnot!~stichnot@adsl-69-110-235-166.dsl.pltn13.pacbell.net) has joined #mythtv
[02:11:49] stichnot (stichnot!~stichnot@adsl-69-110-235-166.dsl.pltn13.pacbell.net) has quit (Changing host)
[02:11:49] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[02:12:10] jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv
[02:14:58] stichnot: sphery: pretty sure it's another instantiation of the 1088/1080 issue
[02:36:41] tonsofpcs: there's issues with 1088?
[02:53:20] jheizer__ (jheizer__!~jon@c-98-226-220-178.hsd1.il.comcast.net) has joined #mythtv
[02:58:12] stichnot: tonsofpcs: #11358
[02:58:12] ** MythLogBot http://code.mythtv.org/trac/ticket/11358 **
[02:59:35] tonsofpcs: stichnot: interesting. Is it a HDPVR issue maybe?
[03:00:19] tonsofpcs: if I weren't moving wires all day tomorrow and dropping in a new producton server mid-day, I'd be tempted to pull the file and put it through the analyzer
[03:01:15] tonsofpcs: oh, it's h.264....
[03:02:39] Sharky-AFK is now known as Sharky112065
[03:03:06] gigem: stichnot: That must be maintaining such a big patch. I wish xavierh would come back and finish his settings rewrite. I've been tempted to look at it and possibly pick it up, but I keep thinking up other things to do first.
[03:03:42] gigem: The point being after the settings rewrite is done, the playgroups could then be reworked.
[03:04:04] gigem: tonsofpcs: ccache and distcc can speed compiles up a lot.
[03:04:49] gigem: stichnot: s/That must be/That must be fun/
[03:04:50] tonsofpcs: gigem: well, seeing as it took about 5 minutes without -j5 on this quad core, I don't think I care too much :) it's not like VLC's compile times.
[03:06:25] gigem: -j5? I use -j14 and I'm being a little conservative. BTW, that's with using my [mostly] dedicated frontend and backend as distcc servers.
[03:06:59] tonsofpcs: this is a .... Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz
[03:07:13] tonsofpcs: with 4 GB of RAM, 258 M free right now...
[03:10:56] gigem: That is getting a bit old. Time for an upgrade! I couldn't resist the MicroCenter loss leader CPU and DDR3 pricing last summer and upgraded my dev system to an i7 3770 with 16GB. I slipped again this month and upgraded my backend to an i5 3570K with 8GB.
[03:13:35] tonsofpcs: yea, I missed that pricing. Almost got a cheap workstation as a myth box afterwards.
[03:13:55] tonsofpcs: this system cost me $400 about 3 years ago iirc
[03:15:51] tonsofpcs: anyway, can i run the newly patched backend from the build directory or do I need to make install?
[03:18:07] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv
[03:20:04] gigem: tonsofpcs: If your installed version is the same except for the patch, then yes, you can in this case. The reason being the changes are all in programs/mythbackend. If you had changed any of the libraryies, it gets much more complicated on whether or not you can use LD_LIBRARY_PATH.
[03:20:53] tonsofpcs: yea, it's got the same version number and options compiled in
[03:29:57] stichnot: tonsofpcs: This is probably an artifact of the HDPVR, combined with mythtv trying to display all 1088 lines. If the HDPVR caused the last 8 lines to be black, no one would notice.
[03:30:39] tonsofpcs: I don't think it pushes the last 8 on my display here... mind you, my output is 1080p...
[03:30:47] tonsofpcs: (HDHR)
[03:36:48] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Quit: Konversation terminated!)
[03:37:39] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv
[03:41:26] jheizer__ (jheizer__!~jon@c-98-226-220-178.hsd1.il.comcast.net) has quit (Ping timeout: 256 seconds)
[03:48:53] stichnot: gigem: fortunately, the patch turns out to be fairly unrelated to most people's commits, the biggest source of conflicts tends to be changes in #include lines.
[03:49:46] jpabq: stichnot: #10001 #8937 #8409
[03:49:46] ** MythLogBot http://code.mythtv.org/trac/ticket/10001 **
[03:49:46] ** MythLogBot http://code.mythtv.org/trac/ticket/8937 **
[03:49:46] ** MythLogBot http://code.mythtv.org/trac/ticket/8409 **
[03:50:04] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Quit: Konversation terminated!)
[03:50:48] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv
[03:54:43] stichnot: jpabq: so noted in http://code.mythtv.org/trac/ticket/11358#comment:1 :)
[03:55:42] jpabq: Heh, sorry. I actually have about 2.5% of overscan on my DLP TV, so I never noticed the problem.
[03:56:19] tonsofpcs: I have about 0.000% overscan on my DLP front-proj...
[03:58:07] stichnot: My intention is to apply a zoom transformation when the video has 1088 lines, hopefully that will work reasonably
[03:58:41] tonsofpcs: why not just drop the last 8 lines?
[03:59:23] stichnot: I tried, but it keeps segfaulting :)
[04:00:07] stichnot: I don't really know that code and I'm willing to learn, but if anyone else wants to grab it who knows what they're doing...
[04:01:34] stichnot: I would like to drop the 8 lines from the source, but nothing I tried works so my next attempt will be to follow the Zoom code.
[04:02:12] stichnot: It also means I don't necessarily have to test every VideoOutput* configuration.
[04:04:35] tonsofpcs: won't 'zoom' scale it? or can you steal their code and do a 1:1 zoom ignoring the last 8 (4?) lines of input?
[04:08:56] ** tonsofpcs is not a code writing guy but thinks algorithmicly and can hack his way through most code.... *goes back to playing with serial video protocols* **
[04:09:17] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Quit: Konversation terminated!)
[04:10:27] jheizer__ (jheizer__!~jon@c-98-226-220-178.hsd1.il.comcast.net) has joined #mythtv
[04:10:41] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv
[04:12:14] jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Quit: jya_)
[04:14:12] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Client Quit)
[04:15:21] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv
[04:18:49] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Client Quit)
[04:33:36] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv
[04:52:25] jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv
[04:57:20] Goga777 (Goga777!~Goga777@128-71-147-193.broadband.corbina.ru) has joined #mythtv
[05:08:28] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Quit: Konversation terminated!)
[05:08:40] jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Ping timeout: 252 seconds)
[05:09:40] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv
[05:21:41] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Quit: Konversation terminated!)
[05:58:10] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Quit: Body blow! Body blow!)
[05:59:25] Goga777 (Goga777!~Goga777@128-71-147-193.broadband.corbina.ru) has quit (Remote host closed the connection)
[06:07:18] jheizer__ (jheizer__!~jon@c-98-226-220-178.hsd1.il.comcast.net) has quit (Ping timeout: 264 seconds)
[06:39:55] rsiebert_ (rsiebert_!~quassel@g225061245.adsl.alicedsl.de) has joined #mythtv
[06:43:16] rsiebert (rsiebert!~quassel@g224251147.adsl.alicedsl.de) has quit (Ping timeout: 272 seconds)
[06:58:32] SteveGoodey (SteveGoodey!~steve@host86-149-167-13.range86-149.btcentralplus.com) has joined #mythtv
[06:59:00] Sharky112065 is now known as Sharky-Sleep
[07:01:17] SteveGoodey (SteveGoodey!~steve@host86-149-167-13.range86-149.btcentralplus.com) has quit (Client Quit)
[07:09:43] FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has joined #mythtv
[09:42:10] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv
[09:47:15] stuartm: jpabq: fwiw I was thinking about having the current zoom factor displayed on screen when you change it, most likely in the channel number window, as it stands now it's difficult to know just how much you've zoomed or whether you're back at 1.0 without overshooting
[09:48:08] stuartm: jpabq: nevermind, just noticed that stichnot already asked for that
[10:53:14] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 256 seconds)
[11:02:01] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv
[11:08:03] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Ping timeout: 276 seconds)
[11:22:03] IReboot (IReboot!~doug@99.234.136.184) has quit (Remote host closed the connection)
[11:24:36] IReboot (IReboot!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has joined #mythtv
[11:32:11] IReboot (IReboot!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has quit (Remote host closed the connection)
[11:37:44] IReboot (IReboot!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has joined #mythtv
[11:40:15] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv
[11:46:05] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Quit: Konversation terminated!)
[12:10:55] gracent (gracent!~Thunderbi@87.127.165.150) has joined #mythtv
[12:12:55] PatrickDickey (PatrickDickey!~quassel@2001:470:1f11:830:c9c9:d4d1:1d6c:1203) has joined #mythtv
[12:27:32] sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Ping timeout: 248 seconds)
[12:59:39] stichnot (stichnot!~stichnot@adsl-69-110-235-166.dsl.pltn13.pacbell.net) has joined #mythtv
[12:59:39] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[12:59:39] stichnot (stichnot!~stichnot@adsl-69-110-235-166.dsl.pltn13.pacbell.net) has quit (Changing host)
[13:27:04] drussell_: stichnot: Any bright ideas on the Hauppauge cards yet? Haven't had time yet to try to grok the code and try to find the right place to see what's going on... Been a busy week
[13:31:29] sraue_ (sraue_!~stephan@208-48-239-77-pool.cable.fcom.ch) has joined #mythtv
[13:38:05] stichnot: drussell_: sorry, nothing yet. I don't think there's much hope in actually reading the code. My approach will be to use the debugger plus logging to trace the difference between successful startup of a PVR-150 recording versus live TV (and maybe versus an in-progress recording if necessary).
[13:42:04] drussell_: stichnot: Yeah, it's quite a complex mess from my quick paruse of the source... I'm certainly no expert! :-) Don't even know where on earth to try tracking it down... Keep me posted as to any progress; many people will be very pleased when this gets fixed...
[13:46:15] sraue_ is now known as sraue
[13:46:44] sraue (sraue!~stephan@208-48-239-77-pool.cable.fcom.ch) has quit (Changing host)
[13:46:44] sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv
[13:49:18] jya: danielk22: look like you finding the root cause of #11159 is more important than ever… We have to choose otherwise between broken HD-PVR or broken BBC-HD :(
[13:49:18] ** MythLogBot http://code.mythtv.org/trac/ticket/11159 **
[13:50:04] stichnot: jya: how about a new setting :)
[13:50:55] drussell_: Hey, yeah... A big 'MODE' switch on the side of the box... A 'feature' :-)
[13:51:40] jya: Should put it in the configuration wizard: "Please select how you want mythtv playback to be broken..."
[13:56:05] stichnot: well, thinking about it, we could start out in BBC mode and then switch to HDPVR mode when an IDR frame is encountered...
[13:56:33] dekarl (dekarl!~dekarl@p4FCEE61F.dip.t-dialin.net) has quit (Ping timeout: 256 seconds)
[13:58:27] Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv
[13:58:27] stuartm: if it were strictly a BBC HD or HDPVR issue then maybe, but both are valid H.264 and so there may be other videos out there which would be similarly affected and those may or may not include IDR frames
[13:59:46] stuartm: better to get it fixed upstream, both encodings worked just fine in earlier versions of ffmpeg, this is a regression in their code and they need to sort it out :/
[14:02:14] dekarl (dekarl!~dekarl@p4FCEF12C.dip.t-dialin.net) has joined #mythtv
[14:03:50] bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has joined #mythtv
[14:13:19] stichnot: or use the locale to select the breakage mode :)
[14:13:53] jya: stuartm: I've developed the opinion, that our code was always buggy, it just happens to have been exposed only lately
[14:13:57] dmfrey (dmfrey!~dmfrey@webdefence.cluster-h.websense.net) has joined #mythtv
[14:14:07] jya: proof being is that it works just fine when you're not using vdpau or opengl
[14:14:31] stichnot: but seriously, since this affects the stable 0.26, we may need to consider hacks like that until it gets sorted out in master
[14:14:40] jya: stuartm: none of the other playback tool using ffmpeg exhibit the issue.. only myth
[14:15:21] jya: that includes vlc, mplayer, mplayer2, ffplay, xbmc
[14:16:11] jya: righto… off to bed… early start tomorrow
[14:26:35] sl1ce (sl1ce!~johnathan@pool-100-0-73-123.bstnma.fios.verizon.net) has quit (Quit: Konversation terminated!)
[14:27:36] sl1ce (sl1ce!~johnathan@pool-100-0-73-123.bstnma.fios.verizon.net) has joined #mythtv
[14:38:51] bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has quit (Quit: Ex-Chat)
[14:43:54] stuartm: jya: you mean the original bug affecting the HD-PVR was renderer related instead?
[14:44:59] stuartm: I can buy that, the BBC HD issue is definitely a decoding issue though
[14:45:21] Sharky-Sleep is now known as Sharky112065
[14:50:42] stichnot: I think jya has speculated in the past that the limited video buffers in VDPAU brings out the problem more readily
[14:52:40] stichnot: stuartm: manual zoom should be nicer to use now in terms of OSD feedback
[14:52:53] PatrickDickey (PatrickDickey!~quassel@2001:470:1f11:830:c9c9:d4d1:1d6c:1203) has quit (Remote host closed the connection)
[14:53:27] stichnot: except for the wacky things it does to the OSD size in general
[14:54:15] stichnot: also the fact that (at least in my theme) you can end up with the OSD menu shifted off-screen and invisible
[14:55:26] stuartm: shouldn't have any affect on the OSD, strange
[14:56:07] stuartm: TTBMK all it does is crop the video frame and then the OSD is rendered as normal on top
[15:00:27] stichnot: I think the video output window is scaled, and then the OSD is scaled to fit within the video output window. Something like that.
[15:01:23] stichnot: I don't have my head around all the levels of transformations going on there yet, but I didn't change anything wrt OSD rendering
[15:17:12] Goga777 (Goga777!~Goga777@128-71-147-193.broadband.corbina.ru) has joined #mythtv
[15:26:45] IReboot (IReboot!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has quit (Remote host closed the connection)
[15:49:02] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 256 seconds)
[15:49:50] gryffus (gryffus!~gryffus@62.77.84.170) has joined #mythtv
[15:49:54] gryffus: hello
[15:50:12] gryffus: i (our company) want to develop HTPC based on XBMC and MythTV. My question is: what hardware would you recommend and why? It needs to support hardware 1080p decoding and some bus for TV tuner card (or integrated tuner just like BCM7405). It could be ARM or Atom or any other architecture (i think Atom will be best supported?). Thanks for any advices
[15:50:19] gryffus: or TV/Satellite tuner could be implemented as a USB device, but this is not preferred because of higher price...
[15:53:28] Seeker`: I'm not entirely knowledgeable about hardware requirements, but I think the consesnsus in the past was that atoms don't have enough power to run the backend particularly well
[15:53:46] Seeker`: The scheduling algorithm is pretty CPU heavy I think
[15:53:55] Seeker`: ofc, the situation may be different today
[15:54:34] Seeker`: Also in terms of playback, I believe most people use VDPAU for non-CPU-loading 1080p playback
[15:55:45] gryffus: Seeker`: and what about ARM?
[15:56:08] Seeker`: I suspect that ARM is in a worse position than ATOM
[15:56:16] Seeker`: But thats just a hunch
[15:56:51] Seeker`: I may be wrong
[15:59:12] gryffus: ok...
[16:01:09] Seeker`: The scheduler can take a few seconds to run on my 3GHz i5 quad core machine, so it would be quite a task for a low power CPU
[16:01:38] gryffus: hmm thats not so good news
[16:02:09] Seeker`: hopefully someone with a bit more knowledge will be along shortly though :)
[16:02:50] gryffus: yes :)
[16:05:11] wagnerrp: gryffus: the scheduler is single threaded, and CPU intensive
[16:05:30] wagnerrp: however the scheduler scales in CPU demands based off how much data it is given
[16:05:58] wagnerrp: longer term guide data across more channels mean more data to churn through and longer runs
[16:06:12] wagnerrp: more recording rules mean more matches that go onto the second stage, and longer runs
[16:06:39] wagnerrp: more past recordings mean more to cross reference for duplicate matching, and again, longer runs
[16:07:28] wagnerrp: you can run a backend on an Atom, and you can even run a backend on an ARM. there are people that are doing both
[16:07:34] jheizer: Ex: in my case X6, SSD, 16GB ram, Satellite + OTA, Scheduled 968 items in 1.6
[16:08:02] wagnerrp: it all depends on how heavily you're using the system
[16:08:03] jheizer: but that is on the waaay high end for a BE
[16:08:19] jheizer: (7 year DB history)
[16:17:52] sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Quit: Ex-Chat)
[16:19:33] gryffus: ok so it seems that we will not go the ARM way... for couple of reasons one being linux compatibility (i would like to stick to my favourite distro to build upon)
[16:20:09] gryffus: we will create own embedded distribution on openSUSE base with our own instance of OBS, just like meego/mer does
[16:20:34] jpabq: If you want automatic commercial flagging, that is also CPU intensive.
[16:21:03] jpabq: Or, at least it is if you are recording H.264
[16:24:32] gryffus: MSI Media Live looks like a nice box... But we just wanted something more embedded...
[16:31:46] peper03 (peper03!~peper03@port-92-203-127-96.dynamic.qsc.de) has joined #mythtv
[16:46:23] FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has quit (Quit: FabriceMG)
[16:47:17] peper03: Ok, after a couple of days looking at other stuff, I'm looking at fixing this stubborn 'DVD still with audio' problem again and could do with some suggestions/pointers. As a recap, the main problem seems to be that the DVD data is read very quickly and the audio buffer is filled to the brim. If something like stereo output is selected, we parse and store about 12 seconds worth of audio before we actually start playing.
[16:48:34] peper03: Any video frames in this time are effectively skipped over, so you might see them flash past but not really 'see' them. I.e. audio plays from the beginning, picture shows what it should do at 12 seconds into the stream.
[16:50:26] peper03: Changing the query AudioPlayer::IsBufferAlmostFull to determine 'fullness' based on time rather than bytes helps but I'm not sure it's the best solution or what side-effects that may have in other areas.
[16:52:21] peper03: AVFormatDecoder::GetFrame rightly expects video frames, but there aren't actually likely to be very many. If there is no audio stream, it generates dummy frames, which seem to help slow down the audio processing (the audio buffer isn't constantly full).
[16:53:13] peper03: So, does anyone have any bright ideas how best to slow down audio processing when there's only the occasional video frame?
[16:55:09] peper03: The other problem of filling the audio buffers with so much data is that volume changes get delayed if you use software mixing as the volume is applied as the audio data goes into the buffer. The effect of a volume change is therefore only audible several seconds later when that data is finally played.
[16:55:37] sraue_ (sraue_!~stephan@208-48-239-77-pool.cable.fcom.ch) has joined #mythtv
[16:56:30] sraue_ is now known as sraue
[16:56:38] sraue (sraue!~stephan@208-48-239-77-pool.cable.fcom.ch) has quit (Changing host)
[16:56:38] sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv
[17:02:24] stuartm: no bright ideas, obviously if it were simple then we'd never buffer more audio (time) than video and we'd use the still frame duration in determining the time, not the framerate
[17:19:07] peper03: stuartm: The problem is that we don't know how long the frame should be displayed for. It's basically a case of 'show this frame until another comes along'.
[17:21:57] peper03: I noticed that CPU usage hits 100% in this situation once the audio buffer is full because we keep on calling GetFrame, which returns immediately because the audio buffer is full. That doesn't happen with, say, a radio source. I'm assuming that's because we generate dummy frames.
[17:22:20] peper03: Apart from anything else, hitting 100% CPU load when we're effectively only processing audio is not good either.
[17:25:47] peper03: My understanding of the whole A/V sync stuff is fairly wobbly so I'd rather not go too far down any one path only for the work to be dismissed as not workable in other cases.
[17:27:12] peper03: But I'd also rather not leave the problem as it's surely solvable and definitely a problem.
[17:27:53] stuartm: sucks that we don't get information about how long each frame should be shown in advance :( anyhow, it sounds like GetFrame() needs some re-working
[17:30:33] peper03: The high CPU load can be fixed by sleeping if we detect a full audio buffer at the beginning of GetFrame. The only question there is probably how long to sleep.
[17:30:58] Seeker`: How long would it take to run if you created a dummy frame?
[17:31:32] peper03: How do you mean exactly?
[17:31:49] Seeker`: You said it isn't an issue with radio because you create dummy frames
[17:32:02] Seeker`: Sleep for the length of time it takes to create a dummy frame on radio playback?
[17:32:16] Seeker`: (I have no idea what I'm talking about really :P )
[17:32:21] peper03: Ah, I see.
[17:32:45] peper03: Yes, sleeping for 1 frame was the about the value I tried in testing.
[17:34:43] peper03: Creating a dummy frame with a copy of the previous frame (rather than a black frame) could theoretically work but the problem with that is twofold:
[17:35:39] peper03: First, You've read an audio frame. You don't know when the next video frame will come, so you don't know when you can/should generate a dummy frame
[17:36:36] peper03: Second, the code that 'knows' we should expect invidual video frames is on the player side, not the decoder side.
[17:36:44] drussell_: Hmm, stichnot's not online right now... Looks like if I reverse patch number 483e06f the HVR-2250 analog inputs work properly again... Will have to check into it further and test more but I have to run out for a bit...
[17:41:52] peper03: Changing the test for the audio buffer to work in time rather than bytes seems to work quite well but it really needs to be quite a low value. It seems that during normal playback, there's something like 0.5–0.75 seconds worth of data buffered (working from memory). That works well in as much as there isn't too much lag when changing the volume but presumably there are instances where that wouldn't be enough.
[17:43:31] peper03: By my calculations, the worst case would be using 7.1 (i.e. 8) channels. Even then the buffer is big enough to hold 2 seconds of data before IsBufferAlmostFull returns true.
[17:43:41] peper03: Pity jya's asleep :)
[17:50:12] Goga777 (Goga777!~Goga777@128-71-147-193.broadband.corbina.ru) has quit (Read error: Connection reset by peer)
[17:51:08] Goga777 (Goga777!~Goga777@128-71-147-193.broadband.corbina.ru) has joined #mythtv
[18:08:38] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv
[18:29:03] SteveGoodey (SteveGoodey!~steve@host86-149-167-13.range86-149.btcentralplus.com) has joined #mythtv
[18:30:12] Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit ()
[18:35:17] chadmandoo (chadmandoo!~chadmando@205.240.253.201) has joined #mythtv
[18:35:22] chadmandoo: hey whats up
[18:42:26] chadmandoo (chadmandoo!~chadmando@205.240.253.201) has left #mythtv ()
[19:01:18] bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has joined #mythtv
[19:23:11] stichnot (stichnot!~stichnot@adsl-69-110-235-166.dsl.pltn13.pacbell.net) has joined #mythtv
[19:23:11] stichnot (stichnot!~stichnot@adsl-69-110-235-166.dsl.pltn13.pacbell.net) has quit (Changing host)
[19:23:11] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[19:28:47] Goga777 (Goga777!~Goga777@128-71-147-193.broadband.corbina.ru) has quit (Remote host closed the connection)
[19:38:05] gigem: !seen j-rod
[19:38:05] MythLogBot: j-rod was last seen 83 days 5 hours 14 seconds ago
[19:50:10] skrock (skrock!~skrock@c-167270d5.024-74-736b7610.cust.bredbandsbolaget.se) has joined #mythtv
[20:09:48] stichnot: drussell_: that commit seems to have nothing to do with the PVR-150 live TV problem on my end. :(
[20:16:08] bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has quit (Quit: Ex-Chat)
[20:47:30] peper03: Right, I've had another look at the stuff around GetFrame. When there's only audio, just creating dummy frames isn't going to take any time and it's not going to reduce the CPU load so something else is limiting the speed at which we read the incoming data.
[20:49:09] peper03: AvFormatDecoder::GetFrame is called by MythPlayer::DecoderGetFrame. That checks whether there are free video frames to be rendered into and if not, sleeps. That's what's limiting the speed. Creating dummy frames fills the available video frames, which are only released at a given rate.
[20:51:41] peper03: So my train of thought at the moment is to make DecoderGetFrame virtual and overwrite it in MythPlayerDVD. We know in that class that we're showing a still frame (dvd_stillframe_showing). If that's set, we could implement a similar sleep in some way to limit the decoding.
[20:52:09] peper03: That way we wouldn't need to fiddle with the audio buffers.
[20:52:26] peper03: And we'd have a 'natural' limiter.
[20:53:00] peper03: How does that sound architecturally?
[20:53:37] peper03: There are two separate threads in play but both in the same class, so there shouldn't be a problem there, should there?
[21:02:46] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv
[21:03:25] doug_ (doug_!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has joined #mythtv
[21:05:09] doug_ (doug_!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has quit (Client Quit)
[21:05:27] IReboot (IReboot!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has joined #mythtv
[21:05:43] Vernon_at_work_ (Vernon_at_work_!~singv003@lightcloud.verns.net) has quit (Remote host closed the connection)
[21:11:35] IReboot (IReboot!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has quit (Read error: Connection reset by peer)
[21:11:54] IReboot (IReboot!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has joined #mythtv
[21:17:05] skrock (skrock!~skrock@c-167270d5.024-74-736b7610.cust.bredbandsbolaget.se) has quit (Quit: WeeChat 0.3.8)
[21:32:53] dmfrey (dmfrey!~dmfrey@webdefence.cluster-h.websense.net) has quit (Quit: Ex-Chat)
[21:40:06] stuartm: peper03: some sort of semaphore or wait condition would be better than a sleep(), though since I don't really know that code I couldn't say exactly which would be most appropriate
[21:43:12] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 256 seconds)
[21:44:20] peper03: stuartm: Yeah, I meant a generic sleep. It needs to take into account playback speeds other than 1x so some sort of synchronization is almost certainly better. The trick is going to be finding what to synchronize on since one side is decoding and the other playing (although in this case with a single 'pause' frame to display, they shouldn't be very far apart time-wise anyway).
[21:46:01] peper03: I just hacked up a quick test using usleep. It sort of works except that by the time we've processed the first frame and determined we're showing a still frame, we've already read in all the audio :-o
[21:47:12] peper03: Maybe some sort of initial limit in GetFrame to prevent us reading too much. Got to watch it doesn't get hacky though.
[21:50:34] IReboot (IReboot!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has quit (Read error: Connection reset by peer)
[21:51:03] IReboot (IReboot!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has joined #mythtv
[22:17:56] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 245 seconds)
[22:26:19] stichnot (stichnot!~stichnot@216.239.45.92) has joined #mythtv
[22:26:19] stichnot (stichnot!~stichnot@216.239.45.92) has quit (Changing host)
[22:26:20] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[22:55:23] drussell_: stichnot: Makes no sense... Now I can't get it to fail with that commit in or out.... WTF?! I'm at a loss now, it's working fine on my test machine...
[23:00:49] peper03: Don't think this is going to work just like that. I can delay the calls to GetFrame and make sure that GetFrame never reads more than 100ms of audio but it's almost impossible to synchronize it properly. Wait too long and the audio buffer drains completely. Don't wait long enough (even by a fraction) and the audio buffer gets fuller and fuller.
[23:01:10] peper03: Seems like limiting the audio buffer would be easier.
[23:01:50] peper03: And simpler to implement assuming it doesn't affect other scenarios.
[23:31:41] peper03 (peper03!~peper03@port-92-203-127-96.dynamic.qsc.de) has quit (Quit: Konversation terminated!)

IRC Logs collected by BeirdoBot.
Please use the above link to report any bugs.