| Friday, May 11th, 2012, 00:06 UTC | ||
| [00:06:38] | stichnot (stichnot!chatzilla@mythtv/developer/stichnot) has quit (Ping timeout: 240 seconds) | |
| [00:42:43] | amejia (amejia!~andres@xbmc/staff/amejia) has quit (Read error: Connection reset by peer) | |
| [00:44:21] | amejia (amejia!~andres@xbmc/staff/amejia) has joined #mythtv | |
| [00:51:13] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [00:51:54] | zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [00:54:25] | andreax (andreax!~andreaz@p54BF21A3.dip.t-dialin.net) has quit (Read error: Connection reset by peer) | |
| [00:55:00] | jya: | Beirdo: have you looked over the crystalhd stuff |
| [00:55:24] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [00:55:49] | jya: | I wanted to have a quick look last night, so decided to upgrade to ubuntu 12.04 that ships with crystalhd libs… Unfortunately, the "quick upgrade", turned out to be a 5hours nightmate in getting all the services running on it . |
| [00:55:57] | jya: | but now I can start with crystalhd :) |
| [00:56:13] | jya: | though I have no way to test, if it's a compilation issue, that shouldn't be too hard |
| [00:57:15] | Beirdo: | jya: the first thing I found that seemed to fix much of it... #define __LINUX_USER__ before including |
| [00:57:44] | jya: | by the way… about that… |
| [00:57:59] | jya: | I get litelly, a dozen warning for each file being compiled now on the mac |
| [00:58:01] | Beirdo: | but that may still not have matching lib version, and they don't say what version to use. |
| [00:58:48] | jya: | http://pastebin.com/Y9sQK9Hy |
| [00:59:48] | Beirdo: | looks like your include files are crappy and full of repeated definitions |
| [01:01:10] | Beirdo: | I dunno ;) |
| [01:01:57] | Beirdo: | anyways, it's well past time to go home. Hope the traffic has died down |
| [01:19:32] | stichnot (stichnot!~chatzilla@mythtv/developer/stichnot) has joined #mythtv | |
| [01:20:05] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (Read error: Connection reset by peer) | |
| [01:20:31] | jya (jya!~jyavenard@120.148.99.165) has joined #mythtv | |
| [01:20:31] | jya (jya!~jyavenard@120.148.99.165) has quit (Changing host) | |
| [01:20:32] | jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [01:41:15] | jya: | Do we have a mechanism / storage in place for saving cache information? |
| [01:41:43] | jya: | HLS has a flag that states if the stream received is live or not, but also if it can be cached.. |
| [01:42:50] | jya: | Just for the sake of seeking properly in the file, and not have to wait for fetching new data, I thought we would cache the stream at least for the duration of the playback session. However, I can't keep this in RAM, it could take GB quite quickly |
| [01:44:14] | jya: | so is there a preferred caching method, like based on a key or something. could check if my key (say based on URL and segment number) exist and retrieve the packet from disk rather than redownloading it |
| [01:44:34] | danielk22: | jya: QNetworkAccessManager has caching capabilities, but I'm not familiar with our use of it in the mythdownloadmanager |
| [01:45:28] | jya: | danielk22: I see. so when I try to redownload a segment, in fact it could very well be in a cache already … maybe I don't even have to worry about this at all |
| [01:45:31] | danielk22: | Just looking at the code I see we do assign a QNetworkDiskCache(). |
| [01:46:16] | danielk22: | Yep, or worrying may just mean tweaking the cache settings. |
| [01:48:21] | danielk22: | I don't think we call QNetworkDiskCache::setMaximumCacheSize() and I don't know if the default will be sufficient for A/V files. |
| [01:50:16] | jya: | for sure... |
| [01:50:36] | jya: | a 40 minutes TV episode would typically be around a GB in size |
| [01:50:48] | jya: | that's a fair amount of caching |
| [01:51:32] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 244 seconds) | |
| [02:03:51] | Captain_Murdoch: | jya, you might be able to use a QNetworkDiskCache somehow. |
| [02:04:24] | wagnerrp: | danielk22: had something cause my recording disk to stall earlier tonight, terminating storage of the recording |
| [02:04:25] | Captain_Murdoch: | nevermind, see daniel mentioned that. you might be able to use it directly. |
| [02:04:39] | wagnerrp: | however it seems when that happens, we continue to record, we just discard the data |
| [02:05:41] | wagnerrp: | the filesize keeps incrementing, and it doesnt get marked as failed |
| [02:05:42] | danielk22: | wagnerrp: It would have to be a pretty serious stall. We will wait for the disk to recover up to about 120 MB of data. |
| [02:05:58] | wagnerrp: | yep, last i saw was 129MB |
| [02:06:42] | wagnerrp: | not sure what caused it, but thats not mythtv's fault |
| [02:06:43] | danielk22: | wagnerrp: So by filesize you mean the actual filesize or the DB? |
| [02:06:50] | wagnerrp: | im just more looking at how it was handled |
| [02:07:02] | wagnerrp: | the file was closed, so it stopped |
| [02:07:09] | wagnerrp: | but the value in the database continued to increment |
| [02:07:23] | wagnerrp: | and the backend continued to record even though the data wasnt going anywhere |
| [02:08:46] | danielk22: | wagnerrp: We don't really handle the disk going away. But that said I would expect the buffers to max out and then get reclaimed when the recording ends. |
| [02:10:01] | danielk22: | wagnerrp: We buffer reads from the recording device (which often has tiny hardware buffers that need to be serviced many times per second. And then we buffer writes to the disk. |
| [02:10:01] | wagnerrp: | well thats what im getting at |
| [02:10:11] | wagnerrp: | the TFW aborts, and just starts nulling everything else |
| [02:10:22] | wagnerrp: | but it never signals the actual recording to give up |
| [02:10:32] | wagnerrp: | so the recording continues on as if nothing had happened |
| [02:11:08] | danielk22: | Hmm, and I guess it doesn't get flagged as bad either since it was fine when it went through the recorder, it just didn't make it to disk? |
| [02:12:12] | danielk22: | Do you have some logging that captures the TFW aborting? |
| [02:12:37] | wagnerrp: | actually, where is the error flag stored? recordedmarkup? |
| [02:13:44] | wagnerrp: | http://pastebin.com/h0Mm995P |
| [02:14:06] | danielk22: | wagnerrp: No its a flag that gets set by FinishedRecording. |
| [02:14:59] | wagnerrp: | but where is the flag stored? |
| [02:16:14] | danielk22: | In recorderprogram.videoprop |
| [02:17:10] | danielk22: | Ok, so TFW::ignore_writes was set.. |
| [02:17:19] | wagnerrp: | yeah, just HDTV,1080 |
| [02:17:21] | wagnerrp: | no DAMAGED |
| [02:17:59] | danielk22: | We could check on that periodically in TVRec fairly easily. |
| [02:19:37] | wagnerrp: | is it possible this was induced by mythcommflag? |
| [02:19:55] | wagnerrp: | it was started just a minute earlier, and was burning through that file as fast as the disk would let it |
| [02:20:05] | wagnerrp: | although its odd that the backend would be starved for over a minute |
| [02:21:47] | danielk22: | wagnerrp: I'd check the disk. Two people of mythtv-users had similar problems and it turned out their disk was near death. |
| [02:21:55] | wagnerrp: | two minutes even |
| [02:22:53] | wagnerrp: | its one of the "advanced format" western digitals that lies about its block size |
| [02:23:01] | wagnerrp: | it and ZFS have never played nice |
| [02:25:17] | wagnerrp: | although oddly, that is the one i forced it to use 4K blocks |
| [02:25:43] | wagnerrp: | where as the identical drive where it ignorantly uses 512B blocks tends to behave much better |
| [02:25:51] | wagnerrp: | seems counter to what should be happening |
| [02:27:37] | danielk22: | wagnerrp: Even if those are unaligned 4K blocks the performance shouldn't be bad enough to cause this. |
| [02:28:43] | wagnerrp: | normally its not, and i was shuffling around content on that same drive at ~75MB/s just a few hours ago |
| [02:30:44] | wagnerrp: | well, chalk the failure itself up to user error |
| [02:31:06] | wagnerrp: | i was more just bringing this up in regards to how we handle the failure with the new recording quality mechanism |
| [02:31:47] | danielk22: | wagnerrp: Yeah, I think we can handle it. I'll need to think a bit on how to do it somewhat elegantly. |
| [02:49:33] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya) | |
| [02:52:37] | jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [03:19:42] | ** Beirdo doesn't wanna jinx it, but... the vista slave is still running! ** | |
| [03:34:55] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Remote host closed the connection) | |
| [03:35:00] | ** wagnerrp wonders if it is shackled and dressed in loin cloth ** | |
| [03:38:34] | wagnerrp: | danielk22: you still up? |
| [03:39:06] | wagnerrp: | question on the dev list on what changed in proto version 74 |
| [03:39:15] | wagnerrp: | honestly, i dont see anything |
| [03:39:43] | wagnerrp: | was that to maintain consistency with something added to a feature branch? |
| [04:04:41] | gregL (gregL!~greg@cpe-74-76-125-87.nycap.res.rr.com) has quit (Read error: Connection reset by peer) | |
| [04:07:22] | Beirdo: | iiinteresting |
| [04:07:38] | Beirdo: | I just got an abort from mythcommflag |
| [04:08:04] | Beirdo: | av_free is erroring out in VideoBuffers::DeleteBuffers. |
| [04:11:27] | Beirdo: | and my ALRM handler allows us to see the message sent in the abort! :) |
| [04:11:51] | gregL (gregL!~greg@cpe-74-76-125-87.nycap.res.rr.com) has joined #mythtv | |
| [04:11:51] | Beirdo: | at least for ones coming from malloc |
| [04:28:26] | zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [04:32:57] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [04:33:11] | amejia_ (amejia_!~andres@xbmc/staff/amejia) has quit (Quit: Konversation terminated!) | |
| [04:37:09] | zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [04:41:12] | pheld (pheld!~heldal@cl-5.osl-01.no.sixxs.net) has quit (Ping timeout: 272 seconds) | |
| [04:43:43] | pheld (pheld!~heldal@cl-5.osl-01.no.sixxs.net) has joined #mythtv | |
| [04:55:49] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [05:01:55] | Beirdo: | oh this is new |
| [05:02:16] | Beirdo: | my backend machine just decided it was vacation time |
| [05:07:52] | mzanetti_ (mzanetti_!~mzanetti@server1.muehlhaeuser.de) has quit (Ping timeout: 252 seconds) | |
| [05:09:09] | mzanetti_ (mzanetti_!~mzanetti@server1.muehlhaeuser.de) has joined #mythtv | |
| [05:09:42] | CaCtus491 (CaCtus491!~Kent@123-243-197-152.static.tpgi.com.au) has quit (Ping timeout: 252 seconds) | |
| [05:10:21] | CaCtus491 (CaCtus491!~Kent@123-243-197-152.static.tpgi.com.au) has joined #mythtv | |
| [05:12:08] | Unhelpful_ (Unhelpful_!~quassel@rockbox/developer/Unhelpful) has joined #mythtv | |
| [05:12:51] | Unhelpful (Unhelpful!~quassel@rockbox/developer/Unhelpful) has quit (Remote host closed the connection) | |
| [05:45:33] | Unhelpful_ is now known as Unhelpful | |
| [06:05:17] | kormoc (kormoc!~kormoc@mythtv/developer/kormoc) has quit (Quit: kormoc) | |
| [06:12:15] | solars (solars!~solars@194.208.132.118) has joined #mythtv | |
| [06:15:02] | Beirdo: | OK, WTF? |
| [06:15:18] | Beirdo: | Canonical (idiots) removed oprofile from precise? |
| [06:19:35] | Goga777 (Goga777!~Goga777@2.95.137.147) has joined #mythtv | |
| [06:19:43] | Goga777 (Goga777!~Goga777@2.95.137.147) has quit (Read error: Connection reset by peer) | |
| [06:37:19] | jstenback_ (jstenback_!~jstenback@2620:101:8003:200:224:e8ff:fe39:34c2) has quit (Ping timeout: 264 seconds) | |
| [06:37:57] | jstenback (jstenback!~jstenback@2620:101:8003:200:224:e8ff:fe39:34c2) has joined #mythtv | |
| [06:52:28] | Beirdo: | I think I'll hit the sack |
| [07:10:08] | mrand (mrand!~mrand@ubuntu/member/mrand) has quit (Ping timeout: 240 seconds) | |
| [07:25:18] | mrand (mrand!~mrand@ubuntu/member/mrand) has joined #mythtv | |
| [07:50:07] | rsiebert (rsiebert!~quassel@g231184151.adsl.alicedsl.de) has joined #mythtv | |
| [07:53:40] | rsiebert_ (rsiebert_!~quassel@g225057213.adsl.alicedsl.de) has quit (Ping timeout: 260 seconds) | |
| [09:14:42] | JackWinter (JackWinter!~jack@vodsl-4996.vo.lu) has left #mythtv ("Konversation terminated!") | |
| [09:23:14] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv | |
| [09:55:48] | jya: | Beirdo: most of the av_blah function, will automatically delete a packet if an error occur |
| [09:56:12] | jya: | so if you free it whenever you exit the av function, without first checking for error, you'll get a crash |
| [09:56:24] | jya: | happened to me yesterday when I was redoing the AC3 encoder |
| [09:56:40] | jya: | the documentation is actually rather explicit on the subjet |
| [09:56:43] | jya: | subject |
| [10:05:02] | 16WAAJXO3 (16WAAJXO3!~mike@c-98-232-220-158.hsd1.or.comcast.net) has quit (Remote host closed the connection) | |
| [10:05:39] | dekarl1 (dekarl1!~dekarl@p4FCEF838.dip.t-dialin.net) has quit (Ping timeout: 265 seconds) | |
| [10:05:52] | mike (mike!~mike@c-98-232-220-158.hsd1.or.comcast.net) has joined #mythtv | |
| [10:06:18] | mike is now known as Guest96614 | |
| [11:08:22] | XChatMav (XChatMav!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 255 seconds) | |
| [11:34:07] | stichnot (stichnot!~chatzilla@mythtv/developer/stichnot) has quit (Remote host closed the connection) | |
| [11:56:52] | natanojl: | Captain_Murdoch: I got HLS to work on my Sony Ericsson Arc S with ICS after I changed audio codec to libfaac/aac and removing "if (c->codec_id == CODEC_ID_AAC)c ->profile = FF_PROFILE_AAC_MAIN;" in AVFormatWriter::AddAudioStream() |
| [12:08:00] | dmfrey (dmfrey!~dmfrey@64-121-93-243.c3-0.smt-ubr1.atw-smt.pa.cable.rcn.com) has joined #mythtv | |
| [12:19:45] | danielk22: | wagnerrp: There aren't any.. There was a UPnP discovery change in early patches but IIRC I managed to make those changes in a separate patch without a proto-bump. I just forgot to remove the proto bump from the commit. |
| [12:21:45] | danielk22: | sorry 'bout that |
| [12:21:46] | amessina (amessina!~amessina@2001:470:1f11:a4:d6be:d9ff:fe8d:7c1e) has joined #mythtv | |
| [12:33:34] | jarle (jarle!~jarle@70.84-234-133.customer.lyse.net) has quit (Remote host closed the connection) | |
| [12:35:36] | jarle (jarle!~jarle@70.84-234-133.customer.lyse.net) has joined #mythtv | |
| [12:40:00] | pheld (pheld!~heldal@cl-5.osl-01.no.sixxs.net) has quit (Ping timeout: 272 seconds) | |
| [12:40:42] | stichnot (stichnot!~chatzilla@192.55.54.40) has joined #mythtv | |
| [12:40:42] | stichnot (stichnot!~chatzilla@mythtv/developer/stichnot) has joined #mythtv | |
| [12:40:42] | stichnot (stichnot!~chatzilla@192.55.54.40) has quit (Changing host) | |
| [12:44:06] | dinamic|screen (dinamic|screen!~remote@buffalo.cendio.se) has joined #mythtv | |
| [12:57:09] | pheld (pheld!~heldal@cl-5.osl-01.no.sixxs.net) has joined #mythtv | |
| [13:08:40] | danielk22: | sphery: ALTER DATABASE %1 DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci; <-- What is this? |
| [13:09:02] | danielk22: | It's done unconditionally before every schema upgrade. |
| [13:09:34] | danielk22: | Is it something we still need or is it legacy? |
| [13:10:36] | stichnot: | Beirdo: in case you're interested, after the ffmpeg resync, the frontend segfaults on the sample in #10606 , somewhere in the ffmpeg code |
| [13:10:36] | ** MythLogBot http://code.mythtv.org/trac/ticket/10606 ** | |
| [13:18:48] | Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv | |
| [13:24:27] | Captain_Murdoch: | natanojl, great. I wanted to test AAC encoding before reenabling it or adding support to select the audio codec. I need to revisit webm as well, I had that working at one point but it broke along the way somewhere. I'll try to test that with my mobile devices and get a patch in sometime. I added a note to my TODO |
| [13:28:29] | ** jya swearing at whomever decided to make GetRealFileSize const ** | |
| [13:30:54] | zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [13:41:02] | sphery: | danielk22: It was originally put in (at latin1) when users were complaining about UTF-8 character issues in an attempt to prevent some issues. All it does is change the default for new tables created without an explicit charset specified. My preference is to never rely on the defaults--I've updated dbcheck.cpp to always specify charset, but haven't updated the temp table creation for mfdb/scheduler (but I need to make some changes to them, ... |
| [13:41:08] | sphery: | ... anyway, so will do so). |
| [13:42:13] | sphery: | In hindsight, I think the original problem was due to Gentoo users having UTF8 as the server default charset, and our old schema creation/update code didn't specify charset--however, since that change only updated the defaut for new tables created in the database, it didn't actually fix the issue. |
| [13:44:38] | sphery: | If we're careful to always specify charset, we should be ok removing that. |
| [13:46:39] | natanojl: | Captain_Murdoch: Let me know if you want't me to test anything |
| [13:49:05] | jya: | natanojl: so in which codec do you know convert your audio ? |
| [13:49:19] | jya: | streaming with any audio other than aac will not work with iOS device |
| [13:50:37] | natanojl: | jya: libfaac. It was libmp3lame before |
| [13:50:55] | jya: | mp3 ? |
| [13:51:05] | jya: | wonder how that ever worked on an apple device then |
| [13:51:20] | jya: | the spec states that HLS is to be h264 / aac or h264 / ac3 |
| [13:51:25] | danielk22: | sphery: It's probably best to leave it in with a note saying not to rely on it. That will prevent some broken schema's when we forget to specify... |
| [13:52:38] | danielk22: | sphery: I'm removing that annoying 5 second wait on schema upgrade.. so I'll probably be moving that as part of the changes. |
| [13:52:39] | jya: | natanojl: may be time to use the native aac encoder now that we've updated ffmpeg, and not having to rely on libfaac |
| [13:54:40] | natanojl: | jya: I found this where Apple says HE-AAC or AAC-LC, stereo or MP3 (MPEG-1 Audio Layer 3), stereo. http://developer.apple.com/library/ios/docume . . . 32-CH102-SW8 |
| [13:54:43] | jya: | AFAIK, a stream must contain AAC stereo, and an optional AC3 stream |
| [13:54:51] | sphery: | danielk22: sounds good... I have a partial patch that begins reimplementing the schema upgrade wizard (converting it to an event-driven approach, compatible with mythui--rather than the current, "everything in main thread, blocking" approach), but it will be a while before it's done |
| [13:55:06] | natanojl: | jya: Yeah aac worked as well as libfaac |
| [13:55:27] | jya: | natanojl: weird, I only just read about that two weeks ago and I read something different |
| [13:55:46] | jya: | ah, maybe that was for the Apple TV |
| [13:56:30] | jya: | yeah, I'm confusing with the Apple TV, where it can receive AAC stereo and optionally a AC3 stream |
| [13:57:21] | sphery: | danielk22: and I'd love to have that wait gone... It probably doesn't make a lot of sense, anymore, since we've limited upgrades to only the master backend host's mythbackend or mythtv-setup on any host (but we could change that to mythtv-setup only on master backend host :)... before when we allowed upgrade by any backend or mythtv-setup, chances of multiple attempting upgrade at once were much higher--and since the test is flawed (i.e. ... |
| [13:57:27] | sphery: | ... wouldn't detect that someone else is upgrading if it checked schema version on a complex update that took > 5s)... |
| [13:58:25] | natanojl: | jya: ok |
| [13:58:27] | sphery: | jya: switching to native aac encode/getting rid of need for libfaac would be great! |
| [13:59:09] | jya: | sphery: supposiidly, lost of work has been done on the AAC native encoder, and i read that it should be as good as libfaac for stereo |
| [13:59:57] | jya: | I read that about a year ago on the ffmpeg list |
| [14:02:39] | jya: | sphery: to use the native aac encoder, it's just a matter of changing the codec type |
| [14:04:36] | jya: | natanojl: can you try with "aac" codec name instead of libfaac/aac ? |
| [14:04:46] | jya: | CODEC_ID_AAC |
| [14:05:33] | cocoa117 (cocoa117!~cocoa117@188-222-31-239.zone13.bethere.co.uk) has joined #mythtv | |
| [14:09:56] | jya: | natanojl: try in mythtranscode/transcode.cpp , comment avfw->SetAudioCodec("libmp3lame"); line 1122 and add avfw->SetAudioCodec("aac") |
| [14:10:00] | jya: | that should do |
| [14:11:44] | jya: | my HLS decoder compiles ! :) now to test... |
| [14:11:45] | natanojl: | jya: Yeah, I did already try that ad it worked. I'll doublecheck though |
| [14:12:11] | jya: | natanojl: problem with that is, it won't work on 0.25 |
| [14:13:16] | jya: | looking at httplivestream.cpp ; would be much nicer to do all of this in real time ; no need to do database stuff, and call mythtranscode |
| [14:15:18] | natanojl: | yes, it works |
| [14:17:51] | jya: | cool.. one less dependency |
| [14:18:14] | jya: | should be made the default over mp3 |
| [14:21:16] | danielk22: | jya: I wouldn't want to do the transcode in the mythbackend process. That would allow ffmpeg to take down the backend. |
| [14:21:53] | jya: | danielk22: what's the difference between starting another process, or doing it in another thread ? |
| [14:22:23] | jya: | there are many other things we do with ffmpeg that could "take down the process" |
| [14:23:06] | danielk22: | A thread shares memory so if you get a segfault in ffmpeg it will take down the backend as well. |
| [14:23:27] | jya: | danielk22: well, even more reason to not make it segfault :) |
| [14:23:55] | danielk22: | jya: heh, you could spend the next 20 years of your life on that and still get nowhere :) |
| [14:24:21] | jya: | i mean, with that reasoning, there's nothing you want to do on the backend then |
| [14:24:38] | jya: | and have the backend only spawn new process |
| [14:24:50] | jya: | in the worse case, just fork.. |
| [14:24:51] | danielk22: | ffmpeg just isn't very robust against corrupted bitstreams and the developers are not interested in anything that would sacrifice speed for robustness. |
| [14:24:55] | jya: | but that would limit portability |
| [14:25:10] | jya: | danielk22: but here we are the one creating the bitstream ! |
| [14:25:43] | danielk22: | jya: Aren't they ingesting a bitstream that we are then transcoding? |
| [14:25:51] | danielk22: | s/they/we/ |
| [14:26:21] | jya: | that would be raw video / audio… how could it be corrupted in such a way that it make it crash |
| [14:26:45] | danielk22: | You mean it's just YUV and PCM ? |
| [14:27:03] | jya: | well, you have to decode it first before you can encode it |
| [14:27:18] | danielk22: | Right it's the decode part where you will crash. |
| [14:27:24] | jya: | what you would be passing on to the hlstranscoder is yuv/pcm yes |
| [14:27:44] | jya: | well, say it crashes |
| [14:27:53] | jya: | how hard is it to respawn it |
| [14:27:55] | danielk22: | Ok, once it is in YUV/PCM I think it is going to be safe. |
| [14:28:14] | jya: | i mean, there are so many things that could crash the backend |
| [14:28:19] | jya: | and it still does.. |
| [14:28:27] | danielk22: | The backend? Not so hard, but you will have ruined all the recordings that were in progress. |
| [14:28:30] | jya: | and 0.25 more regularly that I've seen in a while |
| [14:28:45] | jya: | danielk22: sure, but they would restart immediately |
| [14:28:48] | danielk22: | jya: Well we want to reduce the crashing not increase it :) |
| [14:29:17] | jya: | IMHO, it's in the same line of saying you don't want mythbackend to run in linux, because the linux kernel can crash |
| [14:30:02] | danielk22: | jya: It's based on real-world experience with ffmpeg being the crashiest library we use. |
| [14:31:08] | jya: | i still think that limiting our capabilities, simply because it has the potential to make it crash more is a tad ludicrous… if you want it robust, don't use the feature increasing the likelihood |
| [14:31:34] | jya: | now I guess, mythtranscode could spawn it's own server |
| [14:31:45] | jya: | and start processing request directly |
| [14:31:47] | danielk22: | jya: It's not limiting capabilities at all. You just spawn a process instead of a thread. IPC is a little more difficult, but not much. |
| [14:32:09] | jya: | danielk22: there are many things you can't do simply starting an external program |
| [14:32:28] | danielk22: | Really? |
| [14:34:30] | danielk22: | I think we must be speaking past each other. If we create the program I can't think of anything we can't do in that program that we could do in a thread. |
| [14:35:46] | jya: | it would be far more complicated, especially when it comes to network services |
| [14:36:12] | jya: | unless you want to start a process listening on a given port, and as such becomes a server running constantly |
| [14:37:09] | danielk22: | jya: There is nothing wrong with segmenting it that way if it makes the code simpler. |
| [14:39:39] | danielk22: | It's just ffmpeg decoding in the same process as the recorders that concerns me. |
| [14:41:28] | jya: | wagnerrp: Qt has started working on the bug affecting ipv6 link-local on the mac |
| [14:41:29] | jya: | https://codereview.qt-project.org/#change,25770 |
| [14:42:32] | stichnot: | I agree with danielk22 — almost all the crashes I see in mythfrontend/mythcommflag/mythtranscode are in the ffmpeg code. I wouldn't like that happening in the backend and ruining my recordings. |
| [14:42:33] | jya: | looks like the bug was on windows too |
| [14:42:52] | jya: | well, let's rephrase my original suggestion then.. |
| [14:43:05] | jya: | it would be nice of encoding the HLS stream was done on the fly |
| [14:43:17] | jya: | and only as required |
| [14:43:36] | danielk22: | Yeah, that would be awesome! :) |
| [14:44:19] | danielk22: | Not having looked at HLS streaming yet, I actually thought that is what we did. |
| [14:49:52] | danielk22: | stichnot: did you try the avfringbuffer -eagain patch #10658? Did it give you any trouble? |
| [14:55:33] | danielk22: | sphery: For the reworked schema wizard we might want to put the whole schema upgrade in the wizard, and just pass it a function pointer to the upgrade function. That way all that code is in one place and we can also inform the user that we're waiting for the schema lock in the GUI and allow them to give up on the effort. |
| [14:57:52] | stichnot: | danielk22: no I forgot about that. I'll try to look sometime in the next 24 hours. |
| [14:58:48] | jya: | danielk22: what it does is start encoding the whole stream… |
| [14:59:20] | jya: | but Captain_Murdoch thought that trying to outsmart and guess what the client could be doing was too dangerous |
| [14:59:34] | danielk22: | jya: Ah, so if you stop watching the program or FF/REW it just keeps chugging along.. |
| [14:59:41] | jya: | yep |
| [14:59:55] | jya: | it starts the stream, and you can come later to watch it |
| [15:00:06] | jya: | not sure how long it stays on the server |
| [15:00:20] | jya: | I beleive it's until you send a command via the API asking to delete it |
| [15:05:23] | jya: | ahh.. what an idiot… I misread all the QString::toInt(&error), when it it &ok … have dozens of place to change |
| [15:05:53] | amessina (amessina!~amessina@2001:470:1f11:a4:d6be:d9ff:fe8d:7c1e) has quit (Ping timeout: 245 seconds) | |
| [15:07:58] | stichnot (stichnot!~chatzilla@mythtv/developer/stichnot) has quit (Ping timeout: 245 seconds) | |
| [15:14:56] | stoffel (stoffel!~quassel@pD9E42DAB.dip.t-dialin.net) has joined #mythtv | |
| [15:19:44] | wagnerrp: | jya: good to hear |
| [15:20:19] | wagnerrp: | you dont happen to use a proxy for anything do you? |
| [15:20:29] | jya: | wagnerrp: I'm not sure I understand the fix, they set the scopeid before sending, but the address I first provided already contained the scopeid |
| [15:21:08] | wagnerrp: | theres another ticket open on trac ill need to look into |
| [15:21:23] | wagnerrp: | qt doing something funky with listen sockets when you have an http proxy set |
| [15:21:56] | jya: | ah |
| [15:21:59] | wagnerrp: | to be honest, ive never actually used a proxy, or really understood why one would want to use a proxy |
| [15:22:05] | jya: | surprising… |
| [15:22:32] | Captain_Murdoch: | we can't encode HLS on demand. no one wants to wait 4–5 seconds whenever they seek or change bitrate streams, etc.. |
| [15:23:56] | Captain_Murdoch: | the HLS code does support only keeping a certain number of segments, but I definitely do not agree with trying to encode segments as they are requested by the client. |
| [15:24:32] | jya: | Captain_Murdoch: I'm pretty certain that's what the AirVideo server does... |
| [15:24:51] | danielk22: | Captain_Murdoch: Isn't encoding quite a bit faster than real-time for lower 'mobile' resolutions? |
| [15:24:53] | jya: | as soon as I pause, I see the CPU usage down |
| [15:24:59] | jya: | when I play, it jumps back up |
| [15:25:02] | Captain_Murdoch: | danielk22, yeah, encoding is but decoding may not be |
| [15:25:23] | Captain_Murdoch: | decoding a 1080i recording is the slowest part since encoding can be sliced in multiple threads |
| [15:25:31] | jya: | playing a stream from airvideo has never missed a bit |
| [15:26:16] | jya: | Captain_Murdoch: can decoding take more time than encoding? |
| [15:26:27] | danielk22: | Captain_Murdoch: hmmm, VPDAU might help with that. I assume this really only affects H.264, my MPEG-2 OTA content decodes very quickly... |
| [15:26:45] | Captain_Murdoch: | so you are saying there is 0 delay when you seek backwards? then it has to be keeping old segments around or else it limits where you can seek. MythTV's HLS currently keeps the whole video which allows more things like multiple viewers, seeking backwards/forwards further without delay, etc.. |
| [15:28:28] | Captain_Murdoch: | danielk22, maybe so. we are using multiple threads doing the encoding, so I found in my testing that decoding was actually the bottleneck. that's why I implemented the decoding thread/buffer in mythtranscode so it could decode in parallel instead of having to have the encoder waiting on the decoder. |
| [15:31:23] | Captain_Murdoch: | mythtranscode doesn't use multiple threads in MythPlayer for decoding and didn't need the complexity so it was easier to have a buffer in mythtranscode itself. |
| [15:32:36] | Captain_Murdoch: | on a 4 or 8 way box, encoding a low-res frame in multiple slices can easily outpace single threaded decode of large video. |
| [15:32:45] | rhpot1991: | Captain_Murdoch: any chance we can get an option create a stream with a single video file instead of 10 second chunks? |
| [15:33:13] | jya: | rhpot1991: that's not how hls is defined |
| [15:33:31] | jya: | and you wouldn't want that |
| [15:33:31] | stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has quit (Remote host closed the connection) | |
| [15:33:35] | rhpot1991: | maybe a separate api call then? |
| [15:33:40] | tgm4883: | jya, why not? |
| [15:33:52] | jya: | you would be enable to seek or do anything before the segment has finished loading |
| [15:33:54] | rhpot1991: | jya: I'd like to see it for offline downloading, encode it and pull it with getfile |
| [15:34:00] | rhpot1991: | errr offline viewing |
| [15:34:06] | jya: | if you want the whole file, encode it as mp4 or m4v and play that |
| [15:34:28] | tgm4883: | jya, right, but there isn't anything internal that does that right now is there? |
| [15:34:41] | jya: | rhpot1991: playing a HLS with a 40 minutes segment would make it unplayable on your iphone |
| [15:35:01] | rhpot1991: | ya it would be beneficial to be able to have myth do the transcoding |
| [15:35:03] | jya: | hls is just not the right format for that… |
| [15:35:30] | rhpot1991: | jya: agreed this wouldn't be hls, but having the ability in the apis would be good |
| [15:35:33] | jya: | what if you can mythtranscode without the --hls flag? |
| [15:35:41] | jya: | s/can/call |
| [15:36:04] | tgm4883: | jya, untested AFAIK, but that seems like it would work |
| [15:36:16] | jya: | you'll get a .ts file though |
| [15:36:18] | tgm4883: | the question is can we get a services API for that |
| [15:36:27] | jya: | not the best format |
| [15:36:39] | tgm4883: | which is why we asked about HLS in the first place, as it seemed related |
| [15:37:12] | Captain_Murdoch: | rhpot1991, the code I added for HLS does support creating a single mpeg-ts file with h264 video and mp3 audio. the segmentation is an option used for HLS. |
| [15:37:13] | jya: | tgm4883: lodge a ticket in trac. I agree it would be nice.. Having said that… transcoding to something else than nuv and in a more popular format has been on the table for years |
| [15:38:00] | Captain_Murdoch: | I didn't want to try to tackle making that the default for 0.25, but it might be a possibility for 0.26 depending on the timeframe for release. |
| [15:38:27] | jya: | weird… I'm stuck in RingBuffer::GetSubtitleFilename, on rwlock.lockForRead.. I never touch that lock |
| [15:39:00] | jya: | Captain_Murdoch: earlier we talked about using ffmpeg default AAC encoder that is now working in the new ffmpeg |
| [15:39:06] | Captain_Murdoch: | rhpot1991, also, the code I added in support of HLS does support specifying the container format as well, so .mp4 is a possibility but needs testing. |
| [15:39:37] | Captain_Murdoch: | jya, yeah, I made notes but didnt' get a chance to respond. I'll test with native AAC and plan on adding an option to allow the user to specify mp3 or aac audio. |
| [15:39:49] | tgm4883: | Captain_Murdoch, that sounds like something we can test :) |
| [15:39:53] | rhpot1991: | Captain_Murdoch: so is that available via the service apis then or just in code now? |
| [15:40:02] | Captain_Murdoch: | just via command line. |
| [15:40:02] | jya: | aac as default would be nice, would allow to bump the bitrate a bit |
| [15:40:23] | tgm4883: | rhpot1991, I assume we need a way to check via the services API when the file is done transcoding so it isn't downloaded early? |
| [15:40:24] | ** Captain_Murdoch is afk for a short while ** | |
| [15:40:27] | tgm4883: | or is that already available |
| [15:45:51] | jya: | danielk22: is there something like a QMutextLocker equivalent for QReadWriteLock ? |
| [15:47:35] | jya: | can someone explain to me the subtleties, of locking for write vs locking for read in the RingBuffer classes? |
| [15:49:27] | danielk22: | jya: QReadLocker & QWriteLocker |
| [15:50:23] | jya: | danielk22: thanks... |
| [15:50:26] | jya: | excellent |
| [15:51:15] | jya: | i don't understand some stuff.. looking at the streamingringbuffer.cpp code |
| [15:51:24] | jya: | so it locks for write for OpenFile |
| [15:51:54] | jya: | same for seek, and destructor |
| [15:52:08] | jya: | but lock for read for seek and getrealfilesize |
| [15:52:14] | danielk22: | jya: ringbuffer.h shows what lock protects what, anything that updates those needs a write lock, anything that reads them needs a read lock. |
| [15:52:36] | jya: | ahhhh |
| [15:52:39] | jya: | cool |
| [15:54:15] | danielk22: | There is also a locking order, explained in the first big comment in ringbuffer.cpp. |
| [15:54:40] | jya: | yes, I read that one.. not sure i understand what that actually means though :) |
| [15:54:52] | danielk22: | If you follow the locking order rules an A->B,B->A deadlock is impossible... |
| [15:55:55] | danielk22: | Basically if you need both rwlock and poslock, you need to get rwlock first then poslock.. this avoids some code getting poslock first and then rwlock and deadlocking when another thread does it the other way around at the same time. |
| [15:56:22] | jya: | ok |
| [15:56:26] | danielk22: | If you only need one lock for any bit of code you don't need to care about locking order. |
| [15:56:58] | jya: | still… looking at GetRealFileSize |
| [15:57:13] | jya: | it takes the read lock |
| [15:57:34] | jya: | my understanding is that should my code lock, it first needs to lock the parent (rwlock) |
| [15:58:43] | jya: | GetRealFileSize takes the read lock ; i don't know why… it's called from AVFD, which doesn't lock anything at all |
| [15:59:27] | jya: | I can of course copy the logic takes in streamingringbuffer, but I would actually prefer to understand why it does things that way |
| [16:00:20] | danielk22: | jya: It looks like m_context is protected by rwlock. It looks like the locking policy is to take a read lock on rwlock whenever using m_context, and a write lock whenever it is modified. |
| [16:01:28] | jya: | interesting… i can see that too… doesn't mean i understand the why though |
| [16:01:39] | danielk22: | So in OpenFile we get a write lock since we're setting m_context and in GetRealFileSize() we get a read lock so this code doesn't run while OpenFile() is still running. |
| [16:02:08] | jya: | ?? |
| [16:02:24] | jya: | if you didn't want them to run at the same time, shouldn't they use the same lock? |
| [16:02:46] | danielk22: | They do rwlock. |
| [16:02:56] | joki (joki!~joki@p54863432.dip.t-dialin.net) has quit (Read error: Operation timed out) | |
| [16:03:06] | jya: | yes.. "LockForWrite" |
| [16:03:17] | danielk22: | You can't get a read lock while a write lock is held. |
| [16:03:22] | jya: | ahhhh |
| [16:03:28] | jya: | knowing that details help :) |
| [16:04:34] | joki (joki!~joki@p54862B45.dip.t-dialin.net) has joined #mythtv | |
| [16:04:50] | danielk22: | Yeah, that's really the key. With read/write locks you can have many read locks at the same time, but a write lock trumps all read locks and is fully exclusive. |
| [16:09:46] | jya: | QWriteLocker lock(&rwlock); -> error: ‘rwlock’ declared as reference but not initialized |
| [16:09:55] | jya: | I love when I don't get the error message |
| [16:14:10] | jya: | interesting… dvdringbuffer, takes a different approach in its locking order |
| [16:14:35] | danielk22: | jya: Probably a bug.. :) |
| [16:15:04] | jya: | streamingringbuffer also doesn't use the "has_lock" parameter |
| [16:15:14] | jya: | when dvdringbuffer only locks if it dosn't already have it |
| [16:15:51] | danielk22: | jya: Well if you try to lock a lock that is already locked that's an immediate deadlock unless it's a recursive lock. |
| [16:16:21] | jya: | i'm just comparing the logic between the dvd one and the streaming one |
| [16:16:51] | jya: | and I certainly have seen cases where when trying to watch a streaming video, it get stuck forever in the "Please Wait…" starting playback |
| [16:16:58] | jya: | wonder if that would explain |
| [16:18:01] | danielk22: | I don't think so. StreamingRingBuffer::Seek() should be locking rwlock if has_lock is false, but you wouldn't see a deadlock. |
| [16:18:13] | jya: | ok |
| [16:18:49] | danielk22: | If you do so a deadlock in StreamingRingBuffer my guess would be one of the ffurl_* methods is blocking. |
| [16:19:05] | jya: | actually no... |
| [16:19:26] | jya: | it was when trying to read a hls file before I added the small m3u8 work around |
| [16:19:36] | danielk22: | jya: The best thing to do is get a backtrace. Deadlocks are usually easy to spot in a backtrace.. |
| [16:19:41] | jya: | in the lock you would see: trying to read 8 file, but getting 0 |
| [16:19:57] | jya: | lots of time.. then ou get waiting to stop or something similar, but it never gets out |
| [16:20:19] | jya: | actually, I should be looking into it more, debugging in XCode is dead easy |
| [16:20:31] | jya: | I have a nice view on all the threads and what they are doing |
| [16:27:01] | jya: | danielk22: I just made an attempt.. locking wrlock for write in Seek all the time |
| [16:27:11] | jya: | and I certainly am in a deadlock |
| [16:27:50] | jya: | I think the reason it wasn't obvious, is that seeking was almost always disallowed when using streamingringbuffer |
| [16:28:20] | jya: | and I enabled it not long ago, allowing seek if avio tells me it can seek |
| [16:30:17] | danielk22: | I don't see any rwlock locking in StreamingRingBuffer::Seek() (I'm looking at the rtp branch, but this isn't something touched there). |
| [16:30:20] | jya: | it's called in RingBuffer::ReadDirect which takes poslock and then call Seek |
| [16:30:39] | jya: | ah sorry |
| [16:30:42] | jya: | I misread... |
| [16:30:48] | jya: | it was poslock |
| [16:30:52] | jya: | ah… my bad |
| [16:30:57] | jya: | 2:30AM… that explains |
| [16:30:59] | danielk22: | Ah, yep that would cause a deadlock. |
| [16:31:26] | jya: | but still. locking poslock |
| [16:31:35] | jya: | and locking poslock again in Seek |
| [16:31:40] | jya: | would also cause a deadlock |
| [16:31:58] | jya: | it needs that if (!has_lock) test |
| [16:32:12] | danielk22: | Ouch, remotefile::Seek() ... |
| [16:33:00] | danielk22: | The assumption in all the Seek methods is that poslock isn't locked and has_lock is only for rwlock. |
| [16:33:22] | jya: | but it is locked |
| [16:33:35] | jya: | jeez |
| [16:33:44] | jya: | I have crap in my eyes |
| [16:33:57] | jya: | poslock is unlocked just a few lines before in RingBuffer |
| [16:34:30] | stuarta: | is that because it's 2.30am? |
| [16:34:37] | jya: | probably |
| [16:34:39] | jya: | :) |
| [16:34:44] | stuarta: | :) |
| [16:34:49] | jya: | I do want to play my apple test stream… i'm so close |
| [16:35:10] | jya: | danielk22: ok.. so I can take poslock whenever in Seek |
| [16:35:15] | stuarta: | btw. i'll find some time next week to sit down and sort the osx buildbot |
| [16:35:20] | danielk22: | jya: right |
| [16:35:23] | jya: | but can only take rwlock if has_lock is false |
| [16:35:30] | danielk22: | right |
| [16:35:36] | jya: | getting there... |
| [16:38:29] | jya: | danielk22: reading the message, shouldn't you revert partially the bump in protocol version? |
| [16:39:01] | danielk22: | Anyone here a multicast expert? Esp on windows? Assuming a IP_ADD_MEMBERSHIP is still called is it safe to bind to the multicast address? |
| [16:39:46] | danielk22: | jya: That can cause problems when we do need to bump, we don't want to have two 64 versions.. |
| [16:40:06] | danielk22: | I could revert but leave a note that the next version should be 65.. |
| [16:41:13] | jya: | i would guess that due to how short that version has been, and how unstable it's been with the ffmpeg bump, it's unlikely it would ever happen |
| [16:42:09] | stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has joined #mythtv | |
| [16:46:50] | jya: | danielk22: why would you want to bind to a multicast address? |
| [16:46:59] | stichnot (stichnot!~chatzilla@mythtv/developer/stichnot) has joined #mythtv | |
| [16:50:17] | danielk22: | See #10667. He is saying that all the data is being sent to the first interface. |
| [16:50:17] | ** MythLogBot http://code.mythtv.org/trac/ticket/10667 ** | |
| [16:50:43] | jya: | I mean, biding to one interface, you will receive multicast data |
| [16:51:07] | jya: | so binding a multicast address should make no difference |
| [16:51:28] | Captain_Murdoch: | tgm4883, rhpot1991, you can test the generic output libav* container/codec support in mythtranscode by using a few undocumented command line options. mythtranscode -i INFILE -o OUTFILE --avf --container mpegts --acodec libmp3lame --vcodec libx264 where the container name, acodec, and vcodec are all the names that ffmpeg uses internally. |
| [16:51:42] | Captain_Murdoch: | tgm4883, when using HLS, the segments aren't listed in the playlist until they're available for download. |
| [16:52:00] | jya: | is iptvstreamhandler a serverpool? |
| [16:52:47] | jya: | danielk22: if it is using ServerPool, I know what the problem could be |
| [16:53:00] | danielk22: | I should be more clear.. There are multiple multicast streams. Each one uses the same port but different multicast addresses. We bind multiple sockets to ANY and join the appropriate multicast group. But apparently get data for the multiple multicast streams on one socket and no data on the other sockets. |
| [16:53:16] | danielk22: | It's not using ServerPool, just QUdpSocket. |
| [16:53:32] | jya: | ok… so my reasoning for the error wouldn't apply. |
| [16:53:42] | jya: | though, I would expect to fail in a similar manner |
| [16:53:58] | jya: | actually.. no |
| [16:54:11] | jya: | it's the exact same issue I've seen with serverpool |
| [16:54:19] | danielk22: | Which is? |
| [16:54:27] | jya: | danielk22: here is the issue I've seen in ServerPool |
| [16:54:46] | jya: | we were binding to several addresses, simulating QHostAddress::Any |
| [16:55:34] | jya: | when sending the UDP packet, it was using an unbound udp socket (that it's unbound isn't much the problem) |
| [16:56:02] | jya: | if I was using a bound qudpsocket, that wasn't the one that was supposed to get the data |
| [16:56:07] | jya: | no answer would be received |
| [16:56:35] | jya: | I have found with QUdpSocket, that to receive data, it must be the socket sending it in the first place |
| [16:56:53] | jya: | otherwise the signal read() is never emitted |
| [16:57:19] | danielk22: | oh, so you are saying qudpsocket is doing it's own filtering? |
| [16:57:32] | jya: | so what I did to get around this, is loop through the list of QUdpSocket before sending, find which one is able to receive an answer from the host, and send with that one |
| [16:57:45] | jya: | normally it shouldn't matter |
| [16:58:13] | danielk22: | but with multicast or broadcast... |
| [16:58:17] | jya: | at the time, my interpretation of it, is that the AirPlay client was answering to the origin/port contained in the UDP packet |
| [16:59:13] | jya: | https://github.com/MythTV/mythtv/commit/34c46 . . . 6f5058c85e5e |
| [16:59:20] | jya: | it's the 2nd big part of the patch |
| [16:59:31] | jya: | so I don't know if QUdpSocket is doing its own filtering |
| [16:59:46] | jya: | that would also explain the behaviour I was seeing with AirPlay |
| [16:59:51] | danielk22: | In that case I may have a case for upgrading to Qt 4.8... it supports multicast itself.. so presumably doesn't filter it out... |
| [17:00:08] | danielk22: | I'll look at the QUdpSocket implementation before drawing any conclusions.. |
| [17:00:22] | stichnot: | Has there been any talk yet about a target release date for 0.26? |
| [17:00:23] | jya: | for me it was easier, I store the netmask of each udp socket, and search one with the right netmask |
| [17:01:06] | danielk22: | stichnot: No date has been named, but I think a number of devs want to make it a short cycle. |
| [17:03:52] | kormoc (kormoc!~kormoc@mythtv/developer/kormoc) has joined #mythtv | |
| [17:04:04] | stichnot: | yeah, I heard that, and was wondering how short people were thinking. |
| [17:06:10] | danielk22: | stichnot: I was thinking freeze late June. I don't know what others were thinking... |
| [17:07:06] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
| [17:09:59] | amejia_ (amejia_!~andres@xbmc/staff/amejia) has joined #mythtv | |
| [17:11:18] | stichnot: | ok, I'll keep that as my expectation for now... |
| [17:11:30] | jya: | I play the apple test stream !!! |
| [17:12:11] | stuartm: | the plan early on was for a short cycle, although that was before we lost two devs and I've lost momentum on my own feature list so I'm less certain about it now |
| [17:13:00] | jya: | hum… lots of "waiting for video buffers"... |
| [17:13:18] | stuartm: | however given the reception to mythmusic in 0.25 and the fact that there are some other feature branches close to completion, a quick 0.26 would probably be welcomed by users |
| [17:13:35] | stuartm: | the iptv breakage in 0.25 too |
| [17:14:27] | natanojl: | wagnerrp: Can you explain why you add 1 to m_default/m_stored for ints in CommandLineArg::Set(QString opt)? |
| [17:14:36] | stuartm: | still some good reasons for keeping to the target date for 0.26 |
| [17:18:18] | amejia_ (amejia_!~andres@xbmc/staff/amejia) has quit (Read error: Connection reset by peer) | |
| [17:18:33] | wagnerrp: | natanojl: it operates as a counter |
| [17:18:34] | amejia_ (amejia_!~andres@129.174.97.130) has joined #mythtv | |
| [17:18:34] | amejia_ (amejia_!~andres@xbmc/staff/amejia) has joined #mythtv | |
| [17:18:34] | amejia_ (amejia_!~andres@129.174.97.130) has quit (Changing host) | |
| [17:18:46] | wagnerrp: | so you can do something like --quiet --quiet to make it more quiet |
| [17:19:21] | wagnerrp: | or if provided directly, it will accept --quiet=<n> |
| [17:21:31] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Read error: Connection timed out) | |
| [17:22:15] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv | |
| [17:22:42] | amejia_ (amejia_!~andres@129.174.97.130) has joined #mythtv | |
| [17:22:42] | amejia_ (amejia_!~andres@xbmc/staff/amejia) has joined #mythtv | |
| [17:22:42] | amejia_ (amejia_!~andres@129.174.97.130) has quit (Changing host) | |
| [17:23:53] | natanojl: | wagnerrp: ok |
| [17:27:17] | natanojl: | I looked at it because of a post on the users list about mythshutdown. Turns out that calling mythshutdown with --check gives cmdline.toInt("check") == 2 even though the default value is 1 |
| [17:27:41] | natanojl: | Using --check 1 still works though |
| [17:28:10] | rhpot1991: | Captain_Murdoch: assuming that change is in trunk and not in 0.25 fixes? |
| [17:30:14] | natanojl: | wagnerrp: ^^ |
| [17:32:33] | luyang (luyang!~Jan@c80-216-248-196.bredband.comhem.se) has joined #mythtv | |
| [17:32:41] | luyang: | hi all… |
| [17:32:50] | luyang: | great that there are >100 people in here |
| [17:33:26] | luyang: | I just bough an EyeTV hybrid and wonder if I can use MythTV to record tv shows via script/command line |
| [17:34:26] | luyang: | anybody here |
| [17:36:38] | sphery: | luyang: /topic (you want #mythtv-users ) |
| [17:37:11] | luyang: | ok thanks |
| [17:42:44] | luyang (luyang!~Jan@c80-216-248-196.bredband.comhem.se) has left #mythtv () | |
| [17:45:35] | luyang (luyang!~Jan@c80-216-248-196.bredband.comhem.se) has joined #mythtv | |
| [17:57:57] | luyang (luyang!~Jan@c80-216-248-196.bredband.comhem.se) has left #mythtv () | |
| [18:06:51] | wagnerrp: | natanojl: oh, youre saying it increments from the default, rather than from zero |
| [18:07:31] | wagnerrp: | and since default is 1, it hits 2, and so checkOKShutdown gets fed a False |
| [18:08:08] | natanojl: | yup, that's it |
| [18:11:06] | amejia_ (amejia_!~andres@xbmc/staff/amejia) has joined #mythtv | |
| [18:13:01] | amejia_ (amejia_!~andres@xbmc/staff/amejia) has quit (Remote host closed the connection) | |
| [18:13:06] | amejia_ (amejia_!~andres@129.174.97.130) has joined #mythtv | |
| [18:13:25] | amejia_ (amejia_!~andres@129.174.97.130) has quit (Changing host) | |
| [18:13:25] | amejia_ (amejia_!~andres@xbmc/staff/amejia) has joined #mythtv | |
| [18:16:08] | Dr{Who} (Dr{Who}!~mathewss@npv.nutech.com) has quit (Read error: Connection reset by peer) | |
| [18:17:51] | gregL (gregL!~greg@cpe-74-76-125-87.nycap.res.rr.com) has quit (Quit: Leaving) | |
| [18:21:44] | ChanServ!ChanServ@services. changes topic to MythTV development channel. For user support, please /join #mythtv-users . Use http://pastebin.com/. #mythtv-commits to monitor commits. This channel is logged. | |
| [18:23:27] | amejia_ (amejia_!~andres@xbmc/staff/amejia) has quit (Quit: Konversation terminated!) | |
| [18:23:48] | amejia_ (amejia_!~andres@xbmc/staff/amejia) has joined #mythtv | |
| [18:24:07] | wagnerrp: | natanojl: sorry, phone call |
| [18:24:23] | wagnerrp: | im looking through this, and wondering why i had it increment off the default rather than 0 |
| [18:24:36] | natanojl: | wagnerrp: no worries |
| [18:25:52] | wagnerrp: | quick fix would just be to change that test/cast in mythtv/programs/mythshutdown/main.cpp be "... >= 1", rather than " == 1" |
| [18:26:18] | wagnerrp: | ill have to skim through other uses of integers to see if changing the commandlineparser behavior would cause problems elsewhere |
| [18:26:25] | stuartm: | stuarta: /msg ChanServ SET #mythtv url http://www.mythtv.org |
| [18:27:42] | amejia_ (amejia_!~andres@xbmc/staff/amejia) has quit (Client Quit) | |
| [18:30:31] | stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has left #mythtv ("Gone") | |
| [18:30:40] | stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has joined #mythtv | |
| [18:32:36] | amejia_ (amejia_!~andres@129.174.97.130) has joined #mythtv | |
| [18:32:36] | amejia_ (amejia_!~andres@xbmc/staff/amejia) has joined #mythtv | |
| [18:32:36] | amejia_ (amejia_!~andres@129.174.97.130) has quit (Changing host) | |
| [18:37:11] | Captain_Murdoch: | rhpot1991, the --avf mode should work in 0.25-fixes and master. I think I just disabled the help output for it. I was using it during the HLS testing before I had the services code hooked up. |
| [18:42:44] | amejia_ (amejia_!~andres@xbmc/staff/amejia) has joined #mythtv | |
| [18:43:51] | danielk22 (danielk22!~danielk@96.57.9.142) has quit (Ping timeout: 260 seconds) | |
| [18:45:13] | Captain_Murdoch: | jya, if you can playback multiple airplay sessions on multiple mythfrontends in sync, then I wonder if we could actually make mythfrontend a client as well so you could have one mythfrontend playing video as well as sending it to other frontends to play simultaneously and in sync. thinking large sports events, etc.. I toyed around with making a 'slave' mythfrontend player a while back allowing you to have one master mythfronten |
| [18:45:13] | Captain_Murdoch: | ling other slaves but got sidetracked while working on the sync code and never revisited it. don't think I even kept the patches. |
| [19:28:48] | Vernon_at_work_ (Vernon_at_work_!~singv003@lightcloud.verns.net) has joined #mythtv | |
| [19:38:45] | danielk22 (danielk22!~danielk@96.57.9.142) has joined #mythtv | |
| [19:41:11] | gregorcy (gregorcy!~gregorcy@strongbad.chemeng.utah.edu) has quit (Remote host closed the connection) | |
| [19:57:13] | kth (kth!~kai@dyndsl-080-228-180-014.ewe-ip-backbone.de) has joined #mythtv | |
| [19:58:48] | kth: | hi – i've got a simple question – can anybody tell me how to establish a connection using the python bindings when a security pin is set on mythtv-backend? (i know the pin – but i don't know where to set in the python bindings) |
| [20:02:03] | sphery: | in the config.xml? |
| [20:02:23] | kth: | sphery: well okay in which config.xml ? |
| [20:02:36] | sphery: | $HOME/.mythtv/config.xml of the user running the script |
| [20:03:03] | sphery: | (technically of the environment in which the script is run, since HOME could be re-set to something different) |
| [20:03:54] | Vernon_at_work_: | pre-built mythtv boxes? ... anyone? |
| [20:04:22] | Vernon_at_work_: | or at least a link to a page explaining why there is no answer to the "pre-built mythtv box" question ... |
| [20:04:36] | sphery: | Vernon_at_work_: not much/anything available for that, these days |
| [20:05:37] | sphery: | http://www.mythtv.org/wiki/Commercial_MythTV_System has some info, but, in general, most of the companies who have tried encountered legal difficulties |
| [20:05:51] | sphery: | (i.e. with patents, like those for mpeg and mp3 and ...) |
| [20:06:05] | sphery: | and/or figured out it's basically impossible to provide support for mythtv |
| [20:06:15] | sphery: | meaning http://www.mythtv.org/wiki/Packages is likely your best bet |
| [20:06:49] | sphery: | generic PC hardware + tuner supported by V4L/DVB + either a mythtv-centric distro or a distro with good mythtv packages |
| [20:06:54] | sphery: | !url tuners |
| [20:06:54] | MythLogBot: | No match for keyword tuners |
| [20:06:57] | kth: | sphery: thx – it seems that all config.xml's my system contains are empty ;) |
| [20:07:00] | sphery: | !url tuner |
| [20:07:00] | MythLogBot: | No match for keyword tuner |
| [20:07:23] | sphery: | Vernon_at_work_: oh, and now I see we're in the wrong channel :) |
| [20:07:33] | sphery: | (which explains why it can't find the tuner url :) |
| [20:08:18] | sphery: | kth: you'll need to create valid config.xml files to use the bindings properly |
| [20:09:20] | Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit () | |
| [20:13:04] | kth: | sphery: is there a example config.xml available? or do i only have to set |
| [20:13:05] | kth: | <SecurityPin>0000</SecurityPin> (with zeros substituted) |
| [20:14:28] | sphery: | kth: generally you want to let mythtv-setup or mythfrontend create one for you |
| [20:16:13] | kth: | sphery: okay and how do i have to tell mythfrontend /mythtv-setup to create one for me ? ;) |
| [20:17:46] | gregorcy (gregorcy!~gregorcy@harley.chemeng.utah.edu) has joined #mythtv | |
| [20:18:27] | stichnot: | Any thoughts on how I might speed up execution of MythPlayer::GetScreenGrabAtFrame()? This is for the cutlist editor, generating say 5–10 thumbnails around the current frame. |
| [20:20:11] | stichnot: | For example, the most time is spent in myth_sws_img_convert for converting from YUV420P to RGB32. Could I arrange for the decoder to deliver frames already in RGB32 format? |
| [20:21:44] | andreax (andreax!~andreaz@p54BF1A35.dip.t-dialin.net) has joined #mythtv | |
| [20:22:23] | stoffel (stoffel!~quassel@pD9E42DAB.dip.t-dialin.net) has quit (Remote host closed the connection) | |
| [20:24:29] | sphery: | kth: in theory, it should create one each time you run it... you can force it to ask/re-create with mythfrontend -p , but shouldn't be necessary (likely problems with your existing ones--and if they're empty, they should probably be deleted)... followup is probably best in #-users (though I'll be out running, so someone else will likely be able to help) |
| [20:25:44] | Beirdo: | stichnot: I've found it to be incredibly fast for MPEG2 |
| [20:25:54] | Beirdo: | what is your source material? |
| [20:26:02] | stichnot: | MPEG2, OTA |
| [20:26:19] | kth: | sphery: thanks i'll try that out ;) |
| [20:26:22] | Beirdo: | well, I have logs of mythpreviewgen taking like 150ms total |
| [20:26:39] | Beirdo: | mind you, that IS with the newfangled logging changes I'm testing |
| [20:26:48] | stichnot: | you're probably not running on an ION :) |
| [20:26:58] | Beirdo: | no, on an i7 |
| [20:27:06] | Beirdo: | get a real processor :) |
| [20:27:07] | Beirdo: | hehe |
| [20:27:18] | stichnot: | I have a nice i7 on the backend |
| [20:27:26] | Beirdo: | how long is it actually taking? |
| [20:27:27] | stichnot: | so a preview server would be useful |
| [20:27:34] | stichnot: | let me check... |
| [20:27:50] | Beirdo: | ummm, we have that already in the backend to be able to request a preview at arbitrary points |
| [20:28:06] | dmfrey (dmfrey!~dmfrey@64-121-93-243.c3-0.smt-ubr1.atw-smt.pa.cable.rcn.com) has quit (Quit: Ex-Chat) | |
| [20:29:38] | stichnot: | what's the API to get the preview from the backend? |
| [20:29:55] | Beirdo: | you send it over the backend protocol |
| [20:30:02] | Beirdo: | I think there's an API call too |
| [20:30:15] | Beirdo: | I haven't bothered to look into the API much |
| [20:30:20] | stichnot: | yeah, there's an API wrapper. |
| [20:30:35] | stichnot: | no problem, I'll find it |
| [20:31:17] | stichnot: | The myth_sws_img_convert portion is taking about 25ms |
| [20:31:25] | Beirdo: | not bad |
| [20:31:44] | Beirdo: | I wouldn't expect much better on an Atom processor |
| [20:33:18] | kth: | sphery: well okay it creates a configuration with db pass instead of security key ;) but it creates one ^ – thanks |
| [20:33:40] | Captain_Murdoch: | stichnot, are we scaling or converting first? |
| [20:33:47] | Captain_Murdoch: | s/we/you/ :) |
| [20:34:59] | stichnot: | converting first, then creating a (possibly) 1920x1088 QImage, then MythUI / Qt do the scaling |
| [20:35:12] | stichnot: | which is something I tried to fix, but ended up with garbage thumbnails... |
| [20:35:36] | stichnot: | though later I realized my mistake but haven't had a chance to retry |
| [20:36:38] | stichnot: | so the total time for MythPlayer::GetScreenGrabAtFrame() seems to be 31ms per image, times 6 thumbnails I'm generating, does not add up to the 2–3 seconds it takes for all the thumbnails to display |
| [20:37:10] | stichnot: | I guess I ought to be looking for other culprits, like possibly RingBuffer |
| [20:37:54] | stichnot: | but the first order of business is to see about backend thumbnail generation |
| [20:38:14] | Captain_Murdoch: | are you grabbing frames in order from earliest to latest? |
| [20:38:23] | stichnot: | yes |
| [20:38:29] | Beirdo: | Hardcore Forking Action..... |
| [20:39:26] | Beirdo: | being a good net citizen and providing an upstream patch :) |
| [20:39:39] | stichnot: | though when it takes several seconds for all the thumbnails to show up, I would prefer an intelligent reordering based on what I'm most likely to look at |
| [20:40:36] | danielk22: | stichnot: It's surprising to me that the color conversion is taking more time than the scaling. I'd expect the scaling to be much slower. |
| [20:43:35] | stichnot: | danielk22: MythPlayer::GetScreenGrabAtFrame() is not doing scaling. I bet my scaling is being done in Qt, which would explain the discrepancies between the timings in my log and the user experience |
| [20:43:56] | Captain_Murdoch: | isn't myth_sws_img_convert scaling? |
| [20:44:11] | Captain_Murdoch: | it calls sws_scale. |
| [20:44:39] | stichnot: | I don't think MythPlayer::GetScreenGrabAtFrame() is asking it to scale |
| [20:44:42] | Captain_Murdoch: | might be nice if GetScreenGrabAtFrame() would allow specifying a desired output size. |
| [20:45:26] | Captain_Murdoch: | also, am I reading that wrong or are we converting to RGB32 and then back to YUV420P |
| [20:45:50] | Steve-Goodey (Steve-Goodey!~steve@host86-182-4-91.range86-182.btcentralplus.com) has joined #mythtv | |
| [20:46:05] | Beirdo: | https://github.com/jonnydee/nzmqt/pull/5 |
| [20:46:06] | stichnot: | QImage wants RGB32, so I don't think it's being converted back, at least not for me |
| [20:46:08] | Beirdo: | :) |
| [20:46:47] | kth (kth!~kai@dyndsl-080-228-180-014.ewe-ip-backbone.de) has left #mythtv () | |
| [20:47:20] | Captain_Murdoch: | ok, nevermind. read that wrong on the call to myth_sws_img_convert |
| [20:50:24] | danielk22: | stichnot: QImage will I think do bicubic scaling by default. Which is pretty and also expensive. Also if we use sws_scale, even with the same algorithm I'd expect it to be faster due to MMX/SSE use. |
| [20:50:50] | danielk22: | stichnot: For previews in the editor maybe a cheaper scaler like bilinear would be acceptable. |
| [20:51:10] | stichnot: | danielk22: exactly what I was thinking – ugly but fast is fine |
| [20:51:57] | danielk22: | stichnot: the only thing is you probably do want to deinterlace first (even if just by throwing out half the fields). |
| [20:52:00] | stichnot: | so I'll try again to have GetScreenGrabAtFrame to do scaling before handing it off to MythUI/Qt |
| [20:52:42] | stichnot: | also, I'm locally caching the thumbnails which would be much nicer if I don't have to cache 1920x1088x4 bytes per thumbnail... |
| [20:53:33] | stichnot: | "top" shows CPU usage at >100% while thumbnails are showing up, which points another finger at Qt |
| [20:53:48] | Beirdo: | OK, I really think reinventing mythpreviewgen is not really a good use of time :) |
| [20:54:11] | Beirdo: | we already have solved all of that once, and we should use a common code path for all uses if we can |
| [20:54:25] | Beirdo: | it IS your time, of course, though :) |
| [20:55:16] | Beirdo: | it already does this with a user definable framenumber (IIRC) and resolution, giving PNG or JPG output |
| [20:55:17] | stuartm: | well, ultimately the maintenance burden of multiple versions of the same code eats into everyone's time |
| [20:55:51] | Beirdo: | or was it screen cap that let you get either format... well it can be added there if needed |
| [20:56:04] | Beirdo: | not sure why we'd want to do the exact same thing all over. |
| [20:56:17] | Captain_Murdoch: | isn't this the method used by mythpreviewgen, so adding scaling here could benefit mythpreviewgen |
| [20:56:26] | stichnot: | Beirdo: I suspect mythpreviewgen needs some extensions for this usage model, like a bulk mode. I'll think more and make sure I do the right thing |
| [20:56:34] | stichnot: | meeting to go to now... |
| [20:57:16] | Beirdo: | we can extend :) |
| [20:58:55] | ** Captain_Murdoch cringes at the thought that he has seen some systems which would just have something like mythpreviewgen stuff the images into blobs in a table for consumption by the editor. ** | |
| [21:07:09] | XChatMav (XChatMav!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv | |
| [21:07:56] | stichnot (stichnot!~chatzilla@mythtv/developer/stichnot) has quit (Ping timeout: 260 seconds) | |
| [21:09:03] | ** stuartm throws the suggestion for a very similar implementation into the bin ** | |
| [21:12:53] | stichnot (stichnot!~chatzilla@mythtv/developer/stichnot) has joined #mythtv | |
| [21:16:53] | danielk22 (danielk22!~danielk@96.57.9.142) has quit (Quit: Leaving.) | |
| [21:21:14] | Seeker` (Seeker`!~cjo20@unaffiliated/seeker) has quit (Ping timeout: 272 seconds) | |
| [21:22:17] | Seeker` (Seeker`!~cjo20@unaffiliated/seeker) has joined #mythtv | |
| [21:32:27] | Steve-Goodey (Steve-Goodey!~steve@host86-182-4-91.range86-182.btcentralplus.com) has quit (Remote host closed the connection) | |
| [21:49:50] | stichnot_ (stichnot_!~chatzilla@mythtv/developer/stichnot) has joined #mythtv | |
| [21:50:20] | stichnot_: | so am I right that the backend mechanism for generating previews is to proxy the request off to a mythpreviewgen instance? |
| [21:51:33] | stichnot (stichnot!~chatzilla@mythtv/developer/stichnot) has quit (Ping timeout: 252 seconds) | |
| [21:51:46] | stichnot_ is now known as stichnot | |
| [21:52:08] | stichnot: | because I assume the backend isn't directly involved in segfault-inducing ffmpeg code |
| [21:53:21] | stichnot: | so far, the set of changes related to existing preview generation that I'm looking at is very small. see the mythplayer.cpp diffs at the end of http://code.mythtv.org/trac/attachment/ticket . . . mbs_v1.patch |
| [21:55:14] | stichnot: | I had also added a mechanism for making the vh and vw arguments to MythPlayer::GetScreenGrabAtFrame into inout args instead of out args so that an explicit height and/or width could be passed in, but I backed it out when I couldn't get the scaling to work correctly |
| [21:56:28] | stichnot: | I'm pointing this out to try to convince people that I'm not really trying to reinvent mythpreviewgen... :) |
| [21:58:23] | Beirdo: | yes, the requests are served by mythpreviewgen |
| [22:00:27] | stichnot: | ok. So the useful enhancements I can think of would be to support a batch mode (generate previews for several frames in the same recording, using a single ringbuffer/player), and control the explosion of preview files on disk. |
| [22:00:52] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Remote host closed the connection) | |
| [22:01:52] | stichnot: | also, the user needs very low latency between a batch request and the result, so it may pay to keep the player/ringbuffer open for a while |
| [22:03:07] | Beirdo: | hmm |
| [22:03:23] | Beirdo: | there's a very good reason this is done in a separate process, BTW |
| [22:03:34] | sphery: | stichnot: I think you can specify where to write the output, so could write to some other-than-recording-directory location (temp sg? some cache dir? new SG that's auto-cleaned up by housekeeping?) |
| [22:03:51] | Beirdo: | and sphery beat me to it, I was just typing that :) |
| [22:04:47] | sphery: | I've actually thought a previewgen daemon would be nice--maybe auto-spawned, like Beirdo's new log daemon, or even started/monitored/restarted by mythtvd (that I need to finish) |
| [22:04:57] | Beirdo: | we used to have the previews generated right in the backend (and the frontend too?) and it would crap out badly |
| [22:04:58] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [22:05:26] | Beirdo: | yeah, we could easily use that mechanism |
| [22:05:42] | sphery: | though with the speed Beirdo is seeing on his previewgens, perhaps it's all the stuff he's fixing with the new logging that was slowing down new-process creation |
| [22:06:18] | stichnot: | keeping in mind that so far, I have no evidence that "batch mode" would be a substantial win over single requests |
| [22:06:19] | Beirdo: | the H.264 ones still are a bit slow |
| [22:06:41] | stichnot: | especially on an Atom :) |
| [22:07:14] | Beirdo: | I'd bet |
| [22:07:24] | Beirdo: | all the more reason not to do it on the frontend |
| [22:07:25] | Beirdo: | :) |
| [22:08:29] | stichnot: | the possibility of running 8 concurrent mythpreviewgen jobs on my i7 backend is pretty appealing, compared to sequentially on the Atom |
| [22:09:51] | Beirdo: | I do that a lot... like when reloading the All Recordings screen in mythweb :) |
| [22:10:15] | XChatMav (XChatMav!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 252 seconds) | |
| [22:10:40] | Beirdo: | that's actually one of my stress tests for the logging stuff I'm working on |
| [22:10:52] | Beirdo: | hit it with many clients in parallel |
| [22:22:36] | MaverickTech (MaverickTech!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv | |
| [22:34:41] | zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [22:51:34] | stichnot: | Is it believable that in a 1080i NBC OTA recording, two adjacent keyframes could be 49 frames apart? |
| [22:52:58] | stichnot: | if so, then thumbnail performance mystery is probably solved. it's taking about 30ms to decode each intermediate frame in getting from the keyframe to the target frame. nothing to do with the scaling/conversion at the end. |
| [22:58:04] | wagnerrp: | its almost always every 30 frames for me |
| [22:58:17] | wagnerrp: | the only time its different, its closer, due to some kind of splicing between feeds |
| [22:59:41] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [23:00:43] | stichnot: | ok. Where does DecoderBase::FindPosition() get the position map from? (I believe this is the mapping between keyframes and frame numbers) |
| [23:01:02] | stichnot: | I'm wondering if this is a complete list of keyframes, or a subset |
| [23:02:17] | zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [23:03:07] | stichnot: | I suppose the specific encoding is up to the local station? and this NBC station could be inserting fewer keyframes? I've always found that skipping around in the editor is much more sluggish on NBC recordings compared to (also 1080i) CBS recordings |
| [23:12:51] | amessina (amessina!~amessina@2001:470:1f11:a4:d6be:d9ff:fe8d:7c1e) has joined #mythtv | |
| [23:19:30] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [23:22:48] | stichnot: | stuartm: I'd especially like to get your comments on the MythUI aspect of http://code.mythtv.org/trac/ticket/9556#comment:5 . It's a hack to indicate a preview image via the "thumbnail_" prefix to the name attribute (or is it?), and another hack to indicate the relative frame offset in the suffix. |
| [23:28:31] | stichnot: | btw stuartm, I noticed that if you use MythUIImage::SetImage() to set the preview image, and later call Reset() in preparation for loading a new preview, and you didn't specify a backup <filename> for the imagetype, the Reset() call doesn't actually change/erase the old preview image. |
| [23:43:06] | solars (solars!~solars@194.208.132.118) has quit (Ping timeout: 260 seconds) | |
| [23:48:10] | stichnot (stichnot!~chatzilla@mythtv/developer/stichnot) has quit (Ping timeout: 272 seconds) | |
| [23:48:24] | cocoa117 (cocoa117!~cocoa117@188-222-31-239.zone13.bethere.co.uk) has quit (Quit: Leaving) | |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.