| Wednesday, February 20th, 2013, 00:19 UTC | ||
| [00:19:10] | petres (petres!~petre@scheie.homedns.org) has joined #mythtv | |
| [00:30:08] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 252 seconds) | |
| [00:34:55] | stichnot (stichnot!~stichnot@67.218.110.93) has joined #mythtv | |
| [00:34:55] | stichnot (stichnot!~stichnot@67.218.110.93) has quit (Changing host) | |
| [00:34:55] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [01:13:54] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 264 seconds) | |
| [01:15:47] | jpabq is now known as jpabq_afk | |
| [02:12:04] | joki (joki!~joki@p548640A2.dip.t-dialin.net) has quit (Ping timeout: 252 seconds) | |
| [02:12:25] | joki- (joki-!~joki@p54863DD5.dip.t-dialin.net) has joined #mythtv | |
| [02:12:32] | joki- is now known as joki | |
| [02:24:28] | petres (petres!~petre@scheie.homedns.org) has quit (Quit: Leaving) | |
| [02:43:35] | stichnot (stichnot!~stichnot@adsl-68-127-102-161.dsl.pltn13.pacbell.net) has joined #mythtv | |
| [02:43:36] | stichnot (stichnot!~stichnot@adsl-68-127-102-161.dsl.pltn13.pacbell.net) has quit (Changing host) | |
| [02:43:36] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [03:19:28] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Quit: Body blow! Body blow!) | |
| [03:45:53] | J-e-f-f-A (J-e-f-f-A!~J-e-f-f-A@pool-173-48-113-147.bstnma.fios.verizon.net) has quit (Quit: Oh No!!!! ;-)) | |
| [03:48:17] | J-e-f-f-A (J-e-f-f-A!~J-e-f-f-A@pool-173-48-113-147.bstnma.fios.verizon.net) has joined #mythtv | |
| [03:50:00] | danielk222: | peper03: Just looking at svn blame latency seems to date back to ffmpeg revision 1813 from 2003. |
| [03:56:01] | danielk222: | The reparse was last touched by Janne Grunau who is a libav developer these days. |
| [03:58:55] | danielk222: | Interestingly, if you look at the code from 2010 when Janne touched it the private decoder side decoded 5 times whenever dealing with a still frame & these days there is a comment stating that private decoders shouldn't be allowed for DVD playback. Which I assume covers VDPAU decoding too. |
| [03:59:32] | mad_enz (mad_enz!~Enz@dsl-173-206-174-151.tor.primus.ca) has quit (Ping timeout: 248 seconds) | |
| [04:00:37] | mad_enz (mad_enz!~Enz@dsl-173-206-174-151.tor.primus.ca) has joined #mythtv | |
| [04:02:06] | danielk222: | peper03: I'd conclude that the delay is normal, it's been there for at least a decade & the workaround seems to pretty old too. Only the folks in the libav or ffmpeg mailing lists could really tell you if this is the best workaround for the delay issue. |
| [04:09:44] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
| [04:18:11] | mad_enz (mad_enz!~Enz@dsl-173-206-174-151.tor.primus.ca) has quit (Ping timeout: 248 seconds) | |
| [04:18:40] | mad_enz (mad_enz!~Enz@dsl-173-206-174-151.tor.primus.ca) has joined #mythtv | |
| [04:26:59] | monkeypet69 (monkeypet69!~quassel@c-24-6-135-62.hsd1.ca.comcast.net) has quit (Remote host closed the connection) | |
| [04:32:29] | aloril (aloril!~aloril@dsl-tkubrasgw3-54f97e-153.dhcp.inet.fi) has quit (Ping timeout: 276 seconds) | |
| [04:44:14] | aloril (aloril!~aloril@dsl-tkubrasgw3-54f97e-153.dhcp.inet.fi) has joined #mythtv | |
| [05:01:21] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 248 seconds) | |
| [05:02:42] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv | |
| [05:13:59] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Quit: Body blow! Body blow!) | |
| [06:00:10] | Sharky112065 is now known as Sharky-Sleep | |
| [06:10:20] | Chutt_ (Chutt_!~ijr@cpe-24-29-225-175.neo.res.rr.com) has joined #mythtv | |
| [06:13:30] | Chutt (Chutt!~ijr@cpe-24-29-225-175.neo.res.rr.com) has quit (Ping timeout: 252 seconds) | |
| [06:19:18] | Cougar (Cougar!~cougar@2a03:5880:104:10:34a5:35e:2a25:b96d) has quit (Ping timeout: 264 seconds) | |
| [06:30:22] | Cougar (Cougar!~cougar@2a03:5880:104:10:29d0:84:a6c6:a9a2) has joined #mythtv | |
| [06:43:00] | Chutt (Chutt!~ijr@cpe-24-29-225-175.neo.res.rr.com) has joined #mythtv | |
| [06:45:11] | SteveGoodey (SteveGoodey!~steve@host86-147-183-135.range86-147.btcentralplus.com) has joined #mythtv | |
| [06:45:24] | Chutt_ (Chutt_!~ijr@cpe-24-29-225-175.neo.res.rr.com) has quit (Ping timeout: 252 seconds) | |
| [07:05:34] | FabriceMG (FabriceMG!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has joined #mythtv | |
| [07:19:13] | SteveGoodey (SteveGoodey!~steve@host86-147-183-135.range86-147.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [16:15:33] | MythBuild (MythBuild!~MythBuild@alcor.mythtv.org) has joined #mythtv | |
| [16:20:16] | jams: | wagnerrp & danielk22 supermicro h8da8 |
| [16:21:01] | jams: | or supermicro h8dar the system reports both those models for alcors MB |
| [16:23:15] | jams: | i suggest contacting silicon mechanics as they are the company that provided the system. |
| [16:25:37] | wagnerrp: | danielk22: http://serversdirect.com/product.asp?pf_id=IO . . . je4AoddDkAXA |
| [16:26:21] | wagnerrp: | that actually might be a better idea, only sites i could find carrying that hardware through google were semi-shady sites like the above |
| [16:44:49] | Wolfgang2 (Wolfgang2!~Thunderbi@178-27-144-160-dynip.superkabel.de) has joined #mythtv | |
| [16:45:44] | danielk22: | I think xris was our contact there when he worked there many moons ago... we should probably ping him for who to talk to... |
| [16:46:41] | wagnerrp: | didn't capt'm work there as well? |
| [16:47:10] | jams: | it was kormoc |
| [16:48:46] | jams: | at one point I had a contact there..let me see if it's still in my email |
| [16:57:51] | Steve-Goodey (Steve-Goodey!~steve@host86-147-183-135.range86-147.btcentralplus.com) has joined #mythtv | |
| [17:03:34] | stuarta: | it's alive \o/ |
| [17:04:02] | stuarta: | "Machine wasn't responding so I rebooted it." |
| [17:04:06] | stuarta: | i've asked for more information |
| [17:06:22] | Steve-Goodey (Steve-Goodey!~steve@host86-147-183-135.range86-147.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [17:06:29] | Steve-Goodey (Steve-Goodey!~steve@host86-147-183-135.range86-147.btcentralplus.com) has joined #mythtv | |
| [17:07:26] | stuarta: | grrr. no messages in /var/log/messages |
| [17:07:36] | Steve-Goodey: | stuarta: Good job someone knows how to report it. |
| [17:08:06] | ** stuarta knows how to diagnose it if the info is available ** | |
| [17:08:43] | wagnerrp: | yeah, i didn't see any indication of what might have caused the problem |
| [17:09:36] | Steve-Goodey: | Seems a long time down for a simple reboot. Did they have to go far? |
| [17:12:24] | wagnerrp: | well they rebooted it around 8:15 local time |
| [17:12:52] | wagnerrp: | apparently there was just no one active in the irc channel to contact overnight |
| [17:12:55] | XDS2010 (XDS2010!uid1218@gateway/web/irccloud.com/x-vqsspfnsmhpbwnif) has joined #mythtv | |
| [17:19:28] | Goga777 (Goga777!~Goga777@128-71-138-210.broadband.corbina.ru) has quit (Ping timeout: 256 seconds) | |
| [17:26:08] | Wolfgang2 (Wolfgang2!~Thunderbi@178-27-144-160-dynip.superkabel.de) has quit (Quit: Wolfgang2) | |
| [17:30:33] | stuarta: | hmm, that's disappointing. nothing in the sar data to suggest we load spiked. it was just ticking along and then stopped |
| [17:41:05] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv | |
| [17:45:37] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
| [17:46:04] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Read error: Connection reset by peer) | |
| [17:48:02] | wagnerrp: | stuartm: you around? |
| [17:56:32] | xris: | someone mentioned me / silicon mechanics? |
| [17:56:35] | xris: | I still have contacts there. |
| [17:56:46] | xris: | jams, wagnerrp ^^ |
| [17:57:09] | wagnerrp: | yeah, wondering if you could see if they carry an AOC-LPIPMI card in stock |
| [17:57:29] | xris: | you might as well contact the normal sales number for that. |
| [17:57:29] | wagnerrp: | old IPMI card for alcor |
| [17:57:39] | xris: | thought we bought that. |
| [17:57:46] | xris: | ipmi from that era was REALLY flakey, though |
| [17:58:06] | stuarta: | how old is it? |
| [17:58:06] | wagnerrp: | even just remote reboot would be worthwhile |
| [17:58:22] | xris: | 6+ years |
| [17:58:25] | wagnerrp: | late 2004? |
| [17:58:35] | xris: | 8 wouldn't surprise me |
| [17:58:58] | Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:c5cb:a8d4:1d79:a378) has quit (Read error: Connection reset by peer) | |
| [18:01:07] | wagnerrp: | well the board is from late 2005, chips are from 2006 |
| [18:02:06] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Quit: Reconnecting…) | |
| [18:02:20] | stichnot (stichnot!~stichnot@adsl-68-127-102-161.dsl.pltn13.pacbell.net) has joined #mythtv | |
| [18:02:24] | stichnot (stichnot!~stichnot@adsl-68-127-102-161.dsl.pltn13.pacbell.net) has quit (Changing host) | |
| [18:02:24] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [18:02:45] | stichnot: | jpabq_: jpabq_afk: H264Parser.cpp is basically your code, right? I may have found the problem with the player not recognizing certain frames. |
| [18:02:53] | stichnot: | taylorr: ^^^ you're probably interested too |
| [18:04:22] | stichnot: | H264Parser::addBytes() calls processRBSP(found_start_code) which is where new frames and keyframes are identified. |
| [18:05:44] | FabriceMG (FabriceMG!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has quit (Quit: FabriceMG) | |
| [18:06:23] | stichnot: | If this NAL and RBSP are at the end of the packet, then found_start_code=false and processRBSP() will return before dropping into the code that sets on_frame and on_key_frame. |
| [18:07:38] | stichnot: | For mpeg-ts, this presumably works itself out with the next TS packet. |
| [18:08:38] | stichnot: | But for the player, the packets are fully assembled and this is essentially ignored. |
| [18:11:03] | dekarl (dekarl!~dekarl@p4FE85FC9.dip.t-dialin.net) has quit (Ping timeout: 257 seconds) | |
| [18:14:06] | Sharky-Sleep is now known as Sharky112065 | |
| [18:16:06] | dekarl (dekarl!~dekarl@p4FCEF157.dip.t-dialin.net) has joined #mythtv | |
| [18:20:09] | MythBuild: | build #9 of master-f18–64bit is complete: Failure [4failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . bit/builds/9 blamelist: Raymond Wagner <rwagner@mythtv.org > |
| [18:20:43] | MythBuild: | build #323 of master-debian-wheezy-64bit is complete: Failure [4failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . t/builds/323 blamelist: Raymond Wagner <rwagner@mythtv.org > |
| [18:20:47] | wagnerrp: | bah... |
| [18:21:06] | MythBuild: | build #186 of master-linux-64bit-clang is complete: Failure [4failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . g/builds/186 blamelist: Raymond Wagner <rwagner@mythtv.org > |
| [18:21:31] | MythBuild: | build #4 of 0.26-f18–64bit is complete: Failure [4failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/0.26-f18-64bit/builds/4 blamelist: Raymond Wagner <rwagner@mythtv.org > |
| [18:22:45] | MythBuild: | build #3423 of master-freebsd-64bit is complete: Failure [4failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/3423 blamelist: Raymond Wagner <rwagner@mythtv.org > |
| [18:22:58] | MythBuild: | build #79 of 0.26-freebsd-64bit is complete: Failure [4failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/0.26 . . . it/builds/79 blamelist: Raymond Wagner <rwagner@mythtv.org > |
| [18:22:59] | MythBuild: | build #33 of master-ubuntu-12_10–64bit is complete: Failure [4failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . it/builds/33 blamelist: Raymond Wagner <rwagner@mythtv.org > |
| [18:23:04] | MythBuild: | build #75 of 0.26-debian-wheezy-64bit is complete: Failure [4failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/0.26 . . . it/builds/75 blamelist: Raymond Wagner <rwagner@mythtv.org > |
| [18:23:55] | MythBuild: | build #7 of 0.26-ubuntu-12_10–64bit is complete: Failure [4failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/0.26 . . . bit/builds/7 blamelist: Raymond Wagner <rwagner@mythtv.org > |
| [18:24:06] | MythBuild: | build #10 of master-ubuntu-12_04-lts-64bit is complete: Failure [4failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . it/builds/10 blamelist: Raymond Wagner <rwagner@mythtv.org > |
| [18:24:23] | ** tgm4883 blames wagnerrp too ** | |
| [18:24:43] | MythBuild: | build #81 of 0.26-debian-stable-64bit is complete: Failure [4failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/0.26 . . . it/builds/81 blamelist: Raymond Wagner <rwagner@mythtv.org > |
| [18:24:54] | wagnerrp: | it just keeps going... |
| [18:25:34] | stuarta: | you can't stop it |
| [18:25:57] | wagnerrp: | and i had to push it against 0.26 and master too... |
| [18:26:03] | MythBuild: | build #4 of 0.26-ubuntu-12_04-lts-64bit is complete: Failure [4failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/0.26 . . . bit/builds/4 blamelist: Raymond Wagner <rwagner@mythtv.org > |
| [18:26:09] | wagnerrp: | double the fun |
| [18:27:14] | wagnerrp: | stuartm: i'm actually surprised that issue didn't come up sooner |
| [18:27:19] | stuartm: | in the past they've had people on duty, but whether they've scaled back or they simply fell asleep we'll never know, stuarta opened a ticket at 9 AM GMT, or 7 hours before we eventually got a response by pestering them in IRC |
| [18:27:36] | wagnerrp: | looks like it would occur any time you had a mythnetvision grabber run over 15 minutes |
| [18:27:41] | stuartm: | wagnerrp: ? |
| [18:27:41] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
| [18:27:52] | stuartm: | the mythsystem segfault? |
| [18:27:56] | MythBuild: | build #76 of 0.26-linux-32bit is complete: Failure [4failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/0.26 . . . it/builds/76 blamelist: Raymond Wagner <rwagner@mythtv.org > |
| [18:27:56] | wagnerrp: | #11412 |
| [18:27:56] | ** MythLogBot http://code.mythtv.org/trac/ticket/11412 ** | |
| [18:28:59] | stuartm: | wagnerrp: ah ok, sorry, just catching up with the backlog |
| [18:29:15] | MythBuild: | build #608 of master-linux-64bit-icc is complete: Failure [4failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . c/builds/608 blamelist: Raymond Wagner <rwagner@mythtv.org > |
| [18:29:17] | stuartm: | in this case it was triggered by mythweather, but similar situation I guess |
| [18:30:04] | stuartm: | I meant to mention that in the ticket, but I'd been sitting on it all day unable to create the ticket and I just forgot :) |
| [18:31:36] | wagnerrp: | yeah, i don't see anywhere in mythweather that could cause that scenario |
| [18:32:16] | wagnerrp: | well, maybe... |
| [18:33:33] | stuartm: | we explicitly delete an MS instance at one point, seems like that's the most likely one? |
| [18:34:41] | wagnerrp: | you have to explicitly delete an MS instance |
| [18:34:46] | MythBuild: | build #5 of 0.26-f18–64bit is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/0.26-f18-64bit/builds/5 |
| [18:34:47] | MythBuild: | build #10 of master-f18–64bit is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . it/builds/10 |
| [18:34:53] | wagnerrp: | the issue is if you do that without waiting for it to complete |
| [18:34:55] | stuartm: | WeatherSource destructor? Can't be certain since there's nothing in the backtrace |
| [18:35:33] | stuartm: | wagnerrp: i.e. you exit mythweather before it's finished doing a foreground update |
| [18:35:45] | wagnerrp: | now mythplugins/mythweather/mythweather/weatherSource.cpp:495 has it being run with a timeout |
| [18:35:50] | stuartm: | something like that anyway |
| [18:35:59] | wagnerrp: | but the timeout is in Run(), which should mean it is being terminated if it runs beyond that limit |
| [18:36:20] | MythBuild: | build #187 of master-linux-64bit-clang is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . g/builds/187 |
| [18:36:28] | wagnerrp: | yeah, the destructor could be doing it |
| [18:36:42] | wagnerrp: | it kills the process, but it doesn't wait for the signal to come through |
| [18:36:52] | stuartm: | yeah |
| [18:37:05] | wagnerrp: | that's probably i |
| [18:37:06] | wagnerrp: | t |
| [18:37:32] | MythBuild: | build #393 of master-f17–32bit is complete: Failure [4failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . t/builds/393 blamelist: Raymond Wagner <rwagner@mythtv.org > |
| [18:38:00] | MythBuild: | build #82 of 0.26-debian-stable-64bit is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/0.26 . . . it/builds/82 |
| [18:39:40] | MythBuild: | build #324 of master-debian-wheezy-64bit is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . t/builds/324 |
| [18:39:41] | MythBuild: | build #76 of 0.26-debian-wheezy-64bit is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/0.26 . . . it/builds/76 |
| [18:39:44] | MythBuild: | build #3424 of master-freebsd-64bit is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/3424 |
| [18:40:43] | MythBuild: | build #80 of 0.26-freebsd-64bit is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/0.26 . . . it/builds/80 |
| [18:41:09] | MythBuild: | build #34 of master-ubuntu-12_10–64bit is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . it/builds/34 |
| [18:41:22] | MythBuild: | build #8 of 0.26-ubuntu-12_10–64bit is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/0.26 . . . bit/builds/8 |
| [18:45:46] | MythBuild: | build #11 of master-ubuntu-12_04-lts-64bit is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . it/builds/11 |
| [18:46:41] | MythBuild: | build #77 of 0.26-linux-32bit is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/0.26 . . . it/builds/77 |
| [18:52:11] | MythBuild: | build #5 of 0.26-ubuntu-12_04-lts-64bit is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/0.26 . . . bit/builds/5 |
| [18:52:51] | MythBuild: | build #609 of master-linux-64bit-icc is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . c/builds/609 |
| [19:05:36] | SteveGoodey (SteveGoodey!~steve@host86-147-183-135.range86-147.btcentralplus.com) has joined #mythtv | |
| [19:16:52] | wahrhaft (wahrhaft!~quassel@cpe-24-210-69-143.columbus.res.rr.com) has joined #mythtv | |
| [19:28:29] | z3mark (z3mark!~z3mark@ns1.exchangesolutions.net) has joined #mythtv | |
| [19:35:32] | mrand (mrand!~mrand@ubuntu/member/mrand) has joined #mythtv | |
| [20:07:03] | peper03: | danielk22: I've done a bit more digging on the still frame issue. XBMC uses libmpeg2 for DVDs (apparently due to issues with still frames). I must have been looking at something other than VLC because that does call it twice (with an almost identical comment), although interestingly the logic seems inverted. |
| [20:07:31] | peper03: | danielk22: Anyway, looking at line 417 in the example here http://ffmpeg.org/doxygen/trunk/api-example_8c-source.html it would appear (and that makes sense) that at the moment, Myth will not show the last frame of an MPEG stream because the decoded stream is always one frame behind. |
| [20:07:58] | peper03: | It's unlikely anyone would notice when playing back normal files but obviously it matters when you need to 'pause' a particular frame in the middle of a stream. |
| [20:08:32] | peper03: | I'm wondering then whether this bit of AVFD couldn't be re-written to handle 'end of stream' more generically so that AvFormatDecoderDVD could use the same structure when a still frame is required? |
| [20:09:16] | peper03: | I'm not advocating changing it for the sake of changing it but since I'm working on improving the way Myth handles still frames in general during DVD playback, I think it might make life easier. |
| [20:09:36] | peper03: | It should also make it possible to move the handling of stills (at least this part) out of AVFD and into AvFormatDecoderDVD. |
| [20:22:59] | bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has quit (Quit: Leaving) | |
| [20:25:04] | MythBuild: | build #394 of master-f17–32bit is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . t/builds/394 |
| [20:33:37] | stichnot: | jpabq_: taylorr: here's a better explanation. AvFormatDecoder::H264PreProcessPkt() may actually identify more than one frame – delayed processing of the RBSP at the end of the previous packet, plus a fully identified frame in the current packet – but the function returns a bool so framesRead is only incremented once. |
| [20:34:24] | stichnot: | If I change the function from bool to int and do the right thing with the result, the keyframe numbers seem to match up, at least on the one-minute sample. |
| [20:37:39] | Tobbe5178 (Tobbe5178!~asdf@h186n5-sv-a13.ias.bredband.telia.com) has joined #mythtv | |
| [20:38:21] | ghoti (ghoti!~paul@205.233.216.25) has quit (Ping timeout: 245 seconds) | |
| [20:45:29] | ghoti (ghoti!~paul@205.233.216.25) has joined #mythtv | |
| [20:50:03] | danielk22: | stichnot: So this isn't a problem in the recorder only because it is impossible to see two video frames in a 188 byte packet, but in the frontend we're sending in much bigger chunks of data... |
| [20:53:39] | stichnot: | danielk22: is it really impossible? In my sample, there is a 68-byte video frame followed by a 64-byte video frame, both of which ffmpeg identifies as frames. |
| [20:54:40] | danielk22: | stichnot: AFAIK a TS packet can contain at most one PES packet. |
| [20:58:16] | stichnot: | ok. So if the TS packet containing this small frame has a NAL start code between the end of the frame and the end of the TS packet, then it should work out. I don't know if that's happening though. |
| [20:59:57] | stichnot: | danielk22: do you know how a TS packet is padded to the full 188 bytes? |
| [21:00:12] | danielk22: | 0xff |
| [21:00:52] | rsiebert (rsiebert!~quassel@g224250215.adsl.alicedsl.de) has joined #mythtv | |
| [21:01:03] | stichnot: | hmm |
| [21:04:03] | stichnot: | danielk22: so if I have a 68-byte video frame (PES packet) in one TS packet, the TS packet should consist of the TS header, followed by the 68-byte frame, followed by a string of 0xff? |
| [21:04:33] | rsiebert_ (rsiebert_!~quassel@g225055240.adsl.alicedsl.de) has quit (Ping timeout: 276 seconds) | |
| [21:04:47] | danielk22: | That is what I would expect. |
| [21:06:11] | stichnot: | In that case, I would expect DTVRecorder::FindH264Keyframes() to have a similar problem. |
| [21:06:48] | stichnot: | because of "bool hasFrame" |
| [21:08:47] | z3mark (z3mark!~z3mark@ns1.exchangesolutions.net) has quit (Ping timeout: 255 seconds) | |
| [21:09:05] | stichnot: | Is it possible to "dd if=/dev/hdpvr of=..." and use that as a repeatable input to the hdpvr recorder? |
| [21:14:33] | stichnot: | The issue here is that H264Parser::addBytes() calls avpriv_mpv_find_start_code() to determine whether the next NAL unit is within the packet, and if not, defers processing to the next packet. avpriv_mpv_find_start_code() searches for the sequence 0x000001nn. If the last NAL unit in the packet is the one that determines a new frame, the determination is actually made at the very start of... |
| [21:14:35] | stichnot: | ...the next packet, and if that next packet determines a frame from a NAL unit not at the end of the packet, then that new frame will be "lost". |
| [21:15:14] | stichnot: | So if the TS padding had 0x000001 somewhere inside, we would be OK. |
| [21:16:33] | stichnot: | (unless there are two or fewer bytes left over at the end of the TS packet) |
| [21:21:17] | danielk22: | stichnot: for the dd question.. yes.. instead of specifying a /dev/devicename as the device use file:///path/to/debug/file.mpg |
| [21:21:35] | stichnot: | Cool. |
| [21:21:39] | peper03: | stichnot: Admittedly, I've not done anything with H264 or TS packets but if only one PES packet is allowed per TS packet, wouldn't any startcode have to be at the beginning of the TS packet? If the video frame is smaller than the TS packet, padding is added and the next TS packet will have the next startcode? |
| [21:22:10] | danielk22: | stichnot: It's been a while since I used that, so there may be some detail I'm forgetting. |
| [21:24:35] | stichnot: | peper03: there is one start code per NAL unit, so a PES packet may have many NAL unit start codes. Only some of the NAL unit types determine a frame start. If that happens to be the last NAL unit of the frame, then frame start determination is deferred until the next packet, which may contain its own frame start NAL unit not at the end of the packet. |
| [21:26:08] | stichnot: | Any chance the TS packet ends with end_of_seq_rbsp() and that is stripped from the assembled PES packet? |
| [21:27:44] | peper03: | stichnot: Ok, I definitely know too little about it to make any decent suggestions, so I'll shut up now :) |
| [21:29:46] | stichnot: | peper03: yesterday I probably knew less than you :) |
| [21:30:17] | danielk22: | stichnot: I highly doubt anything like that is stripped. |
| [21:30:36] | peper03: | stichnot: It's frightening sometimes how quickly you learn things you never intended to :) |
| [21:31:27] | stichnot: | actually, decode_nal_units() in FFmpeg/libavcodec/h264.c appears on the surface to be explicitly ignoring several NAL unit types, including NAL_END_SEQUENCE |
| [21:32:22] | stichnot: | so it could be that it is helpfully stripped by ffmpeg in the process of building the fully assembled packet, while still being present in the recording file |
| [21:32:51] | peper03: | That sounds familiar... |
| [21:33:11] | stichnot: | peper03: NAL_SPS_EXT perhaps? |
| [21:37:32] | peper03: | stichnot: I wouldn't know. The same problem as I've been having with DVD NAV packets – ffmpeg explicitly filters them out. |
| [21:41:20] | Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit () | |
| [21:48:58] | stichnot: | danielk22: I managed to find this 68-byte sequence within the mpg file. Before the 68 bytes are 20 bytes of legitimate looking data (perhaps TS header), and before that are a lot of 0xff padding bytes. After the 68 bytes are 4 more bytes of data followed by 0x000001fd (which would presumably be recognized in the recorder as a NAL unit start code), followed by a lot of non-0xff bytes. This... |
| [21:49:00] | stichnot: | ...would explain to me why the recorder gets it right but the player fails. |
| [21:50:45] | SteveGoodey (SteveGoodey!~steve@host86-147-183-135.range86-147.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [21:51:53] | stichnot: | In any case, I think it's safe enough to commit the player fix to Master. (and then fix the precision problem so that the recorder and mythcommflag --rebuild also agree on durations) |
| [21:51:54] | danielk22: | TS header is only 4 bytes, so probably a PES header. |
| [21:52:02] | danielk22: | yup |
| [21:55:09] | Steve-Goodey (Steve-Goodey!~steve@host86-147-183-135.range86-147.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [22:01:28] | stichnot: | One thing is a little puzzling though. Why can't AvFormatDecoder::PreProcessVideoPacket() just assume that AvFormatDecoder::H264PreProcessPkt() will always process exactly one frame? That seems to be the assumption for the call to AvFormatDecoder::MpegPreProcessPkt(). |
| [22:03:05] | stichnot: | I wonder if this is why there are sometimes minor discrepancies in the file offsets for the keyframes, between the recorder and the player. |
| [22:04:13] | taylorr: | stichnot: the file offsets are because the recorder might have some audio packets before the video keyframe packet |
| [22:06:41] | stichnot: | taylorr: I was thinking that if frame identification is postponed to the next video packet, an intervening audio packet could make the difference. You think this is specifically related to keyframes? |
| [22:14:28] | danielk22 (danielk22!~danielk@exchange.wgen.net) has left #mythtv () | |
| [22:22:14] | wahrhaft (wahrhaft!~quassel@cpe-24-210-69-143.columbus.res.rr.com) has quit (Ping timeout: 255 seconds) | |
| [22:22:48] | skd5aner (skd5aner!~skd5aner@50.90.30.141) has quit (Read error: Connection reset by peer) | |
| [22:27:40] | Wolfgang2 (Wolfgang2!~Thunderbi@178-27-144-160-dynip.superkabel.de) has joined #mythtv | |
| [22:29:37] | jpabq_afk: | stichnot: I actually was the original author of the H264Parser. Before then, we were using something that Mark Kendall wrote, but his version didn't handle interlaced video. After trying to make Mark's version work, I ended up re-writing the whole class from scratch, and H264Parser is the result. It has been tweaked by other people over the last few years, but it is likely that any bugs in there are mine. |
| [22:29:42] | jpabq_afk is now known as jpabq | |
| [22:30:46] | stichnot: | jpabq: It looks like the issue is at the avfd layer, not H264Parser, so you're off the hook :) |
| [22:31:06] | jpabq: | :) |
| [22:40:05] | stichnot: | stuartm: and any other BBC HD / h.264 users. I'd like to know if, after my latest commit to Master, the recorder and "mythcommflag --rebuild" agree on the keyframe numbers in the recordedseek table where type=9. (There's still some cumulative floating point error that make the durations (type=33) different, which I'll work on next.) |
| [22:41:21] | stuartm: | stichnot: I'll test that tomorrow sometime |
| [22:42:19] | stichnot: | stuartm: thanks. |
| [22:42:30] | stichnot: | also check that I didn't break playback :) |
| [22:51:33] | kwmonroe (kwmonroe!~kwmonroe@32.97.110.60) has quit (Quit: Coyote finally caught me) | |
| [22:52:48] | kwmonroe (kwmonroe!~kwmonroe@32.97.110.60) has joined #mythtv | |
| [22:57:14] | taylorr: | stichnot: you'll have to ask jpabq about why the file offset is different for the recorder |
| [23:02:02] | jpabq: | stichnot: The recorder will include audio frames that show up just before the video frame, in the keyframe offset. The HD-PVR spits out some audio frames which go with video frames, *before* the video frames. It is possible to pick up an audio frame that does not actually go with the subsequent video frame, but not including those audio frames seemed to cause more problems in my testing. |
| [23:06:35] | gregL (gregL!~greg@cpe-74-76-105-205.nycap.res.rr.com) has joined #mythtv | |
| [23:17:10] | kwmonroe (kwmonroe!~kwmonroe@32.97.110.60) has quit (Quit: Coyote finally caught me) | |
| [23:26:08] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 255 seconds) | |
| [23:30:45] | sckssssss (sckssssss!~echosyp@75.111.74.37) has joined #mythtv | |
| [23:51:30] | kwmonroe (kwmonroe!~kwmonroe@32.97.110.60) has joined #mythtv | |
| [23:54:43] | kwmonroe (kwmonroe!~kwmonroe@32.97.110.60) has quit (Client Quit) | |
| [23:57:20] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Remote host closed the connection) | |
| [23:57:22] | kwmonroe (kwmonroe!~kwmonroe@32.97.110.60) has joined #mythtv | |
| [23:59:24] | kwmonroe (kwmonroe!~kwmonroe@32.97.110.60) has quit (Client Quit) | |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.