| Wednesday, February 27th, 2013, 00:21 UTC | ||
| [00:21:29] | Seeker`: | stichnot: stuttering, about 0.2 seconds of playback, then a pause, repeat. |
| [00:22:42] | Seeker`: | I upgraded to head, got the stuttering, reverted to the commit stuartm is on and the recordings work again |
| [00:24:43] | taylorr: | jpabq: do you think it's ok for ticket #11328 to be backported to 0.25-fixes as well? you can't cherry-pick it though. I have it running on my machines so I could commit if you want |
| [00:24:43] | ** MythLogBot http://code.mythtv.org/trac/ticket/11328 ** | |
| [00:26:06] | jpabq: | taylorr: *I* was not going to, just because it is not as simple as a cherry-pick. However, if you want to, that is fine with me. I don't run 0.25 myself... |
| [00:26:35] | taylorr: | jpabq: ok, I'll try to get it in tonight then |
| [00:26:40] | stichnot: | Seeker`: that's odd, the seektable shouldn't affect normal playback. |
| [00:26:56] | taylorr: | jpabq: does it require a binary bump? |
| [00:27:38] | jpabq: | taylorr: shouldn't. Doesn't touch the DB or API. |
| [00:27:46] | Seeker`: | stichnot: I'll do some more investigation, but it probably won't be until tomorrow |
| [00:28:00] | taylorr: | jpabq: ok, didn't think it did |
| [00:28:48] | Seeker`: | stichnot: the commit I mentioned wasn't to do with the seektable, was it? |
| [00:29:31] | stichnot: | Seeker`: it was all about duration calculation for the seektable. |
| [00:30:29] | stichnot: | Seeker`: this one, right? https://github.com/MythTV/mythtv/commit/5ccedb61dd |
| [00:31:13] | Seeker`: | yeah |
| [00:31:20] | taylorr: | stichnot: have you been able to test the recorder's duration code with repeat_pict present in the stream |
| [00:32:24] | stichnot: | Seeker`: It would be good to know the results of the 4 combinations of recordings made before/after the commit combined with pre and post commit player. |
| [00:32:45] | stichnot: | Also whether "mythcommflag --rebuild" changes the post-commit results. |
| [00:34:20] | Seeker`: | pre-commit recording + pre-commit player works. I should bea ble to re-test pre-commit recording and post-commit player in an hour or so |
| [00:34:20] | stichnot: | taylorr: repeat_pict has been tested but not thoroughly. I have a PBS station that sometimes uses repeat_pict for some shows, but it's hard to predict. I guess I should just record a whole day of programming and see what I get... |
| [00:35:07] | taylorr: | stichnot: are you using the duration from the DB for the player yet? |
| [00:35:52] | stichnot: | taylorr: yes, the per-keyframe duration values are used for position, duration, and seeking. |
| [00:36:19] | taylorr: | awesome, I'm sure gigem will be happy |
| [00:37:16] | stichnot: | yes, he was my early tester :) |
| [00:44:30] | danielk221: | stichnot: Cool stuff! Out of curiosity how much inaccuracy was the double frame rate causing vs using the exact ratio? |
| [00:50:47] | stichnot: | danielk221: I think the first-order effect was that a 59.94fps frame interval was represented in the player as 1501/90000 seconds instead of 1501.5/90000. That causes a drift of 1.2 seconds/hour. |
| [00:51:18] | stichnot: | Beyond that, we're talking about maybe <10 ms per hour. |
| [00:51:51] | nephyrin (nephyrin!~neph@nat/mozilla/x-ljrzpqbaajuobbim) has joined #mythtv | |
| [00:52:04] | stichnot: | In the 59.94fps example, the recorder used a value of 59940 which is off by a tiny amount |
| [00:52:06] | danielk221: | 1.2 seconds is pretty significant. I was thinking it would be something in the ms range. |
| [00:52:26] | danielk221: | Ah, so it was worse than just 60000/1001.0 ... |
| [00:55:07] | danielk221: | stuarta: in 32b0546e "iff" i.e. "if and only if" is "corrected" to "if" — maybe we should be writing out 'if and only if' since it is sort of logic geek terminology? |
| [00:55:39] | stichnot: | Near the end, I decided it was silly to be multiplying things by 1000, dividing into 5.0e8, etc, and I tried to represent durations as just seconds in double format before converting to milliseconds in the DB. That didn't work out so well. E.g., 0.5005 cannot be represented precisely as a double, so it would round down to 500ms instead of rounding up to 501ms. |
| [00:57:10] | danielk221: | stichnot: I think using a ratio is better if you are trying to be very accurate. All the common framerates can be represented accurately in 2 16 bit integers... |
| [00:57:26] | danielk221: | vs being inaccurate in a 64 bit float.. |
| [00:57:50] | danielk221: | not that I'm recommending using 16 bit ints, just that a float is the wrong representation. |
| [01:00:26] | danielk221: | I'm just amazed you got the flaggers to agree so well :) |
| [01:01:47] | stichnot: | iirc, this specific problem was that I tried to use something like "1000 * av_q2d(dur) + 0.5" to compute the value for the DB. Problem is, if dur.num=45045 and dur.den=90000, av_q2d returns something like 0.50049999999999994 and the expression result is 500 instead of 501. |
| [01:02:18] | stichnot: | the answer was to compute 1000.0 * dur.num / dur.den + 0.5 |
| [01:02:55] | stichnot: | but yeah, it took a *lot* of 30-minute test recordings to work through all the details... |
| [01:04:15] | danielk221: | Why use truncation rather than a nearbyint() ? (Not that it really matters, I use truncation out of habit myself) |
| [01:05:21] | danielk221: | I guess I'll answer my own question, using nearbyint() requires knowing/setting the rounding direction... so easier just to truncate. |
| [01:05:28] | stichnot: | I didn't know about nearbyint() until now :) |
| [01:06:16] | danielk221: | heh, round() will round to the nearest integer regardless of direction. |
| [01:06:25] | stichnot: | what's now more interesting is that the player sometimes misses a keyframe that the recorder identifies (this is very clear when the keyframe distance is otherwise constant), and the rarer vice versa situation. |
| [01:08:44] | danielk221: | I'd have expected the opposite. I recall there are some conditions where there recorder can theoretically miss a frame, but I can't imagine the decoder working properly if it misses a frame. A missing frame might be reference by a B or P frame. |
| [01:11:31] | stichnot: | The local stations I tested with are CBS (1080i with a constant keyframe distance of 15), NBC (1080i but with long non-constant keyframe distance), ABC (720p with non-constant keyframe distance), a PBS sub-channel (1080i, fixed keyframe distance, but sometimes repHeat_pict frames), and HDPVR (STB locked to 720p). |
| [01:12:47] | stichnot: | I may come back to this and investigate what edge case is causing the player to miss the keyframe. As usual, it is probably our misuse of the ffmpeg libraries. |
| [01:17:45] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
| [02:44:16] | amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Quit: Konversation terminated!) | |
| [02:56:04] | cesman (cesman!~cesman@pdpc/supporter/professional/cesman) has quit (Quit: Konversation terminated!) | |
| [02:59:50] | cesman (cesman!~cesman@pool-108-23-186-248.lsanca.fios.verizon.net) has joined #mythtv | |
| [02:59:50] | cesman (cesman!~cesman@pool-108-23-186-248.lsanca.fios.verizon.net) has quit (Changing host) | |
| [02:59:50] | cesman (cesman!~cesman@pdpc/supporter/professional/cesman) has joined #mythtv | |
| [03:03:46] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 245 seconds) | |
| [03:09:14] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Quit: Body blow! Body blow!) | |
| [03:16:42] | kwmonroe` (kwmonroe`!kwmonroe@nat/ibm/x-cydoepeabmvlmxra) has joined #mythtv | |
| [03:16:57] | kwmonro`` (kwmonro``!~kwmonroe@32.97.110.60) has joined #mythtv | |
| [03:19:20] | kwmonroe (kwmonroe!~kwmonroe@32.97.110.60) has quit (Ping timeout: 244 seconds) | |
| [03:20:54] | kwmonroe` (kwmonroe`!kwmonroe@nat/ibm/x-cydoepeabmvlmxra) has quit (Ping timeout: 240 seconds) | |
| [03:24:35] | kwmonroe (kwmonroe!~kwmonroe@32.97.110.60) has joined #mythtv | |
| [03:26:54] | kwmonro`` (kwmonro``!~kwmonroe@32.97.110.60) has quit (Ping timeout: 240 seconds) | |
| [03:42:14] | stichnot (stichnot!~stichnot@adsl-68-127-102-161.dsl.pltn13.pacbell.net) has joined #mythtv | |
| [03:42:14] | stichnot (stichnot!~stichnot@adsl-68-127-102-161.dsl.pltn13.pacbell.net) has quit (Changing host) | |
| [03:42:15] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [03:53:37] | anykey_ (anykey_!~anykey@84-73-161-59.dclient.hispeed.ch) has quit (*.net *.split) | |
| [03:53:37] | stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has quit (*.net *.split) | |
| [03:55:42] | anykey_ (anykey_!~anykey@84-73-161-59.dclient.hispeed.ch) has joined #mythtv | |
| [03:55:43] | stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has joined #mythtv | |
| [03:56:12] | DJDan (DJDan!~djdan@115-64-177-188.static.tpgi.com.au) has quit (Remote host closed the connection) | |
| [04:17:36] | taylorr: | jpabq: I think I've got the backport for 0.25-fixes ready – just one question – are these changes to iptvrecorder safe -> http://pastebin.com/djYavnkJ |
| [04:18:09] | pitz (pitz!~pitz@71-17-53-178.msjw.hsdb.sasknet.sk.ca) has joined #mythtv | |
| [04:48:35] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 260 seconds) | |
| [04:49:51] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv | |
| [04:50:46] | jpabq: | taylorr: no, leave that bit out. |
| [07:00:42] | FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has joined #mythtv | |
| [07:07:24] | Sharky112065 is now known as Sharky-Sleep | |
| [07:48:06] | dekarl (dekarl!~dekarl@p4FCEF16B.dip.t-dialin.net) has quit (Ping timeout: 256 seconds) | |
| [07:56:35] | dekarl (dekarl!~dekarl@p4FE855D9.dip.t-dialin.net) has joined #mythtv | |
| [08:09:17] | MaverickTech (MaverickTech!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv | |
| [08:24:58] | jvcleave (jvcleave!~jvcleave@WS1-DSL-208-102-254-80.fuse.net) has quit (Quit: jvcleave) | |
| [08:34:49] | Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:580a:c140:4379:2dec) has joined #mythtv | |
| [08:48:08] | stuarta: | danielk221: i understand iff = if and only if |
| [09:09:54] | knightr (knightr!~knightr@mythtv/developer/knightr) has quit (Ping timeout: 240 seconds) | |
| [09:42:31] | Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:580a:c140:4379:2dec) has quit (Ping timeout: 246 seconds) | |
| [09:44:44] | Merlin83b (Merlin83b!~Daniel@office.34sp.com) has joined #mythtv | |
| [10:20:09] | SteveGoodey (SteveGoodey!~steve@host86-147-183-135.range86-147.btcentralplus.com) has joined #mythtv | |
| [11:26:22] | bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has joined #mythtv | |
| [11:41:35] | IReboot_ (IReboot_!~doug@99.234.145.236) has quit (Remote host closed the connection) | |
| [11:45:22] | IReboot (IReboot!~doug@CPE10bf48e67915-CM78cd8e7e342d.cpe.net.cable.rogers.com) has joined #mythtv | |
| [11:57:32] | MythBuild (MythBuild!~MythBuild@alcor.mythtv.org) has quit (Remote host closed the connection) | |
| [11:57:41] | MythBuild (MythBuild!~MythBuild@alcor.mythtv.org) has joined #mythtv | |
| [12:28:58] | knightr (knightr!~knightr@69-165-170-178.dsl.teksavvy.com) has joined #mythtv | |
| [12:28:58] | knightr (knightr!~knightr@69-165-170-178.dsl.teksavvy.com) has quit (Changing host) | |
| [12:28:59] | knightr (knightr!~knightr@mythtv/developer/knightr) has joined #mythtv | |
| [13:17:19] | danielk221: | stuarta: The ticket submitter didn't, and he isn't the first one to make that "correction". |
| [13:18:59] | stuarta: | i however overlooked that |
| [13:19:08] | stuarta: | me-- for not reading the comment correctly |
| [14:30:29] | neufeld (neufeld!~user@69-165-173-139.dsl.teksavvy.com) has joined #mythtv | |
| [15:27:35] | peper03 (peper03!~peper03@port-92-203-92-253.dynamic.qsc.de) has joined #mythtv | |
| [15:33:01] | peper03: | Are there any known issues caused by timecode discontinuities during normal playback? I created a ticket (#11371) a while back to fix discontinuity issues with DVDs that caused the video to freeze. I think I have a better (cleaner) solution but I don't know whether it should all stay in AvFormatDecoderDVD or whether it's better to move part of it into AvFormatDecoder. |
| [15:33:01] | ** MythLogBot http://code.mythtv.org/trac/ticket/11371 ** | |
| [15:33:36] | amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv | |
| [15:34:59] | Steve-Goodey (Steve-Goodey!~steve@host86-147-183-135.range86-147.btcentralplus.com) has joined #mythtv | |
| [15:36:07] | peper03: | Basically, it just detects the discontinuity and adjusts the timecodes of all subsequent incoming packets so that the discontinuity is hidden. If there are sometimes issues during normal playback, I'd move the timecode adjustment into AFD and sort out some way of overriding the calculation/detection of a discontinuity. |
| [15:36:43] | peper03: | The main question would be how to detect a discontinuity for sources other than DVD? |
| [15:45:48] | Steve_Goodey (Steve_Goodey!~steve@host86-147-183-135.range86-147.btcentralplus.com) has joined #mythtv | |
| [15:45:48] | Steve-Goodey (Steve-Goodey!~steve@host86-147-183-135.range86-147.btcentralplus.com) has quit (Read error: Connection reset by peer) | |
| [15:46:37] | Steve_Goodey (Steve_Goodey!~steve@host86-147-183-135.range86-147.btcentralplus.com) has quit (Client Quit) | |
| [15:46:48] | Steve_Goodey (Steve_Goodey!~steve@host86-147-183-135.range86-147.btcentralplus.com) has joined #mythtv | |
| [15:57:48] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 264 seconds) | |
| [16:28:10] | Sharky-Sleep is now known as Sharky112065 | |
| [16:33:51] | stichnot (stichnot!~stichnot@67.218.110.93) has joined #mythtv | |
| [16:33:51] | stichnot (stichnot!~stichnot@67.218.110.93) has quit (Changing host) | |
| [16:33:51] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [16:39:43] | IReboot (IReboot!~doug@CPE10bf48e67915-CM78cd8e7e342d.cpe.net.cable.rogers.com) has quit (Quit: Ex-Chat) | |
| [16:40:09] | IReboot (IReboot!~doug@CPE10bf48e67915-CM78cd8e7e342d.cpe.net.cable.rogers.com) has joined #mythtv | |
| [16:42:28] | FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has quit (Quit: FabriceMG) | |
| [16:42:36] | IReboot (IReboot!~doug@CPE10bf48e67915-CM78cd8e7e342d.cpe.net.cable.rogers.com) has quit (Client Quit) | |
| [16:45:14] | IReboot (IReboot!~doug@CPE10bf48e67915-CM78cd8e7e342d.cpe.net.cable.rogers.com) has joined #mythtv | |
| [16:45:43] | IReboot (IReboot!~doug@CPE10bf48e67915-CM78cd8e7e342d.cpe.net.cable.rogers.com) has quit (Client Quit) | |
| [16:48:20] | IReboot (IReboot!~doug@CPE10bf48e67915-CM78cd8e7e342d.cpe.net.cable.rogers.com) has joined #mythtv | |
| [16:52:15] | stichnot: | peper03: the non-monotonic timestamp problem in #11371 sounds similar to the noisy caption timecode problem in #7861 |
| [16:52:15] | ** MythLogBot http://code.mythtv.org/trac/ticket/11371 ** | |
| [16:52:15] | ** MythLogBot http://code.mythtv.org/trac/ticket/7861 ** | |
| [16:53:28] | stichnot: | peper03: but to answer your question about discontinuities. I don't think the player normally cares about the timestamps, but when there is no seektable, it will use them for position/duration/seeking. |
| [16:55:05] | stichnot: | The plan for 0.27 is to use the seektable only for formats that allow discontinuities, like mpeg-ts (I don't know how DVD fits in), and otherwise to use ffmpeg's timestamp-based capabilities. |
| [16:59:37] | peper03: | stichnot: The problem I was getting with DVD playback was due to the timecode jumping backwards. This fouled up the logic in AVFormatDecoder::GetFrame that decides whether to add a video frame to the 'storedpackets' list, causing all video frames to be buffered rather than played. |
| [16:59:42] | peper03: | https://github.com/MythTV/mythtv/blob/master/ . . . er.cpp#L4603 |
| [17:00:58] | peper03: | That scenario could theoretically occur with 'normal' files too, I expect. Particularly if someone concatenates a couple of MPEGs together. |
| [17:01:59] | peper03: | I wouldn't expect it to happen often, but possible. |
| [17:03:48] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 264 seconds) | |
| [17:14:19] | stichnot (stichnot!~stichnot@216.239.45.79) has joined #mythtv | |
| [17:14:19] | stichnot (stichnot!~stichnot@216.239.45.79) has quit (Changing host) | |
| [17:14:19] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [17:16:39] | stichnot: | peper03: Some cable companies are known to splice in commercials, leading to discontinuities at the boundaries. This may also lead to changing resolutions and frame rates (e.g. 720p <==> 1080i). gigem has given me a few of these for testing frame rate changes, but I never looked at them for timecode discontinuities. |
| [17:17:07] | stuarta: | i think it's best to assume discontinuities _will_ occur |
| [17:24:24] | peper03: | If I get this code cleaned up, I don't think it would be a big deal to split the 'adjustment' part out from the bit that determines how much to adjust by. The adjustment code could go in AVFD with default behaviour of 'do nothing' and the adjustment value could be set in AVFormatDecoderDVD. |
| [17:26:25] | peper03: | That way, the flexibility is there to handle discontinuities as required in future in AVFD but the changes for DVDs could take effect immediately. |
| [17:27:59] | peper03: | Just got to work out if there's a way to get the adjustment value without having to call a virtual method for every packet. Not sure there is at the moment. |
| [17:32:28] | gigem: | stichnot: peper03: On some channels, those local commercials do include timestamp discontinuities. Strangely, the local commercials on other channels don't have them. |
| [17:34:16] | bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has quit (Quit: Leaving) | |
| [17:39:35] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv | |
| [17:56:35] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
| [18:00:44] | amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Quit: Konversation terminated!) | |
| [18:05:33] | jpabq: | gigem: I turned on "-v schedule" while trying something on an older version of myth. At one point my log ended up getting FLOODED with Scheduler (run) – sleeping for 0ms (s2n: 30 sr: 724) type messages. I have not tried to reproduce this scenario with master, but was curious if that was intentional, or if there should be some protection from calling usleep(0) there. |
| [18:06:20] | pitz (pitz!~pitz@71-17-53-178.msjw.hsdb.sasknet.sk.ca) has quit (Quit: Leaving) | |
| [18:10:30] | tonsofpcs: | stuarta: they'll have TC discontinuities. They might even have PTS discontinuities... and *gulp* PCR discontinuities. |
| [18:10:41] | tonsofpcs: | err, stichnot ^ |
| [18:11:20] | Merlin83b (Merlin83b!~Daniel@office.34sp.com) has quit (Read error: Connection reset by peer) | |
| [18:11:28] | stuarta: | :) |
| [18:11:31] | tonsofpcs: | I mean, I imagine if you take two TSs, cut them at arbirtrary bytes, then splice them together, you're probably emulating the cable company :) |
| [18:11:57] | tonsofpcs: | and by :), I mean <insert face with head on desk and hands pulling hair out here> of course |
| [18:12:58] | stuarta: | not to mention if you transcode to remove the ads.... |
| [18:14:17] | tonsofpcs: | well, your ad removal will happen on frame boundaries. Not necessarily the ones 'outside' the splice. |
| [18:14:41] | tonsofpcs: | although I imagine that the discontinuities might make detection more friendly... |
| [18:15:01] | ** tonsofpcs still needs to figure out how to get ad-removal-transcode and dvd-burn set up on his myth boxen ** | |
| [18:26:17] | stuarta: | i've had it working before. i'm currently annoyed by the lack of progress information back from the iso generating part, so i think i'm going to rewrite it to use some of the new infrastructure provided by the zeromq loggin |
| [18:31:27] | wagnerrp: | eew... dvd burning |
| [18:32:31] | wagnerrp: | i used to archive stuff to DVDs |
| [18:32:56] | wagnerrp: | one hard drive failure, and a day spent doing nothing but cycling DVDs in and out of drives, cured me of that |
| [18:35:18] | stuarta: | i only use the feature to make recordings portable to take on holiday etc |
| [18:35:46] | wagnerrp: | on a physical DVD player? |
| [18:43:19] | jheizer: | Those still exist? lol |
| [18:43:40] | jheizer: | Slightly on topic, props to Lossless cut. Set it up last night and it works great. |
| [18:43:59] | wagnerrp: | mythtranscode is working again? |
| [18:44:54] | jheizer: | I was refering to the external lossless cut py script |
| [18:44:59] | wagnerrp: | ah |
| [18:45:31] | IReboot: | jheizer: thanks |
| [18:45:37] | jheizer: | Applied it to my go find some movies recording rule and it is workign great, |
| [18:46:08] | IReboot: | happy it works for you just wished it worked for more recording devices |
| [18:46:41] | jheizer: | Yeah, it did fail on my HDHR recordings but most the movies that end up getting recorded are via the HDPVR anyway. |
| [18:47:39] | jheizer: | Titles list in FE was getting filled up with the movies and wanted the easiest way to get them into videos automaticalls. No commercials made it even better. I am just trusting the commflag as I don't really care. |
| [18:47:57] | IReboot: | For me the lack of HDHR support is the most disappointing as I wanted to help with general h.264 support. |
| [18:49:33] | jheizer: | Understandable. If there are every any logs or anything I could provide to help just let me know. Old school dual ATSC here. So not like it is rare or anything but the offer still stands. |
| [18:49:48] | stuarta: | wagnerrp: i fixed some stuff on that in the last few days |
| [18:50:49] | wagnerrp: | stuarta: ok, i'll give it a try here in a bit. transferring stuff around at the momemnt |
| [18:51:06] | jheizer: | I need to get back to work on MobileMyth before what little interest I did have goes away. Just been too busy with the baby lately. Pretty functional as is though. |
| [19:23:15] | peper03: | Going back to timecodes (sorry, was away for a bit): If it's that common for the timecodes to jump about, I'm surprised more people aren't having issues with that bit of code in AvFormatDecoder. I would expect that any time the timecode jumps backwards, the problem would rear its ugly head. |
| [19:24:28] | peper03: | If I remember correctly, the video freezes whilst audio continues. This lasts until 'max_video_queue_size' video packets have been buffered, then Myth suddenly realizes that audio and video are way out and starts dropping frames like mad until they sync up. |
| [19:24:46] | peper03: | By timecodes, I mean PTS. |
| [19:36:07] | taylorr: | peper03: if the video queuing is incompatible with DVD playback then we should be able to bypass it (I doubt it's necessary anyways) |
| [19:40:22] | peper03: | taylorr: It's not incompatible. It doesn't make life easier, certainly, but one of the main problems I'm hoping to solve is the fact that under too many circumstances the latency between reading a sector from the DVD to displaying a frame on screen is ignored. The video queuing adds to that latency but it isn't the only place. |
| [19:43:12] | peper03: | It seems like PTS discontinuities are just a bigger issue with DVDs than normal videos. It very much depends on how the DVD was authored. Most probably play without problem and there is code that tries to wait for playback empty its buffers at certain points before continuing. It feels a bit hit-and-miss though at times. |
| [20:19:11] | alan` (alan`!alan@abacus.kwzs.be) has quit (Ping timeout: 260 seconds) | |
| [20:19:13] | Kevin` (Kevin`!~kevin@router.kwzs.be) has quit (Ping timeout: 248 seconds) | |
| [20:19:52] | alan` (alan`!alan@abacus.kwzs.be) has joined #mythtv | |
| [20:20:53] | Kevin` (Kevin`!~kevin@router.kwzs.be) has joined #mythtv | |
| [20:25:49] | neufeld (neufeld!~user@69-165-173-139.dsl.teksavvy.com) has quit (Quit: ERC Version 5.3 (IRC client for Emacs)) | |
| [20:29:58] | gigem: | jpabq: The sleep calculation is danielk221's work. It shouldn't repeatedly sleep for 0 ms, though. I've never seen that myself. FWIW, I took a stab at simplifying the sleep calculation and request queue handling a few weeks ago, but gave up. Let me know if you can reproduce the problem and I'll take another stab at it. |
| [20:44:05] | jpabq: | gigem: I will see what I can come up with. Thanks. |
| [20:47:11] | dekarl: | jpabq, you're a native speaker, right? |
| [20:50:58] | bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has joined #mythtv | |
| [20:57:52] | Wolfgang (Wolfgang!~Thunderbi@178-27-144-160-dynip.superkabel.de) has joined #mythtv | |
| [20:59:58] | jpabq: | dekarl: yeah. |
| [21:00:32] | jpabq: | I can see where iff is probably not used outside of the english language. |
| [21:01:07] | rsiebert_ (rsiebert_!~quassel@g231187238.adsl.alicedsl.de) has joined #mythtv | |
| [21:04:03] | rsiebert (rsiebert!~quassel@g225062082.adsl.alicedsl.de) has quit (Ping timeout: 248 seconds) | |
| [21:19:51] | neufeld (neufeld!~user@69-165-173-139.dsl.teksavvy.com) has joined #mythtv | |
| [22:03:11] | SteveGoodey (SteveGoodey!~steve@host86-147-183-135.range86-147.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [22:08:54] | Steve_Goodey (Steve_Goodey!~steve@host86-147-183-135.range86-147.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [22:15:07] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Quit: Body blow! Body blow!) | |
| [22:19:31] | natanojl: | jpabq: dekarl: Whe have omm as in "om och endast om" in Swedish so I knew about iff :) |
| [22:36:09] | amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv | |
| [22:38:05] | bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has quit (Quit: Leaving) | |
| [22:40:23] | joki (joki!~joki@p54861BD7.dip.t-dialin.net) has quit (Ping timeout: 240 seconds) | |
| [22:40:27] | joki- (joki-!~joki@p548620FB.dip.t-dialin.net) has joined #mythtv | |
| [22:40:38] | joki- is now known as joki | |
| [22:45:50] | jheizer (jheizer!~jheizer@c-98-226-220-178.hsd1.il.comcast.net) has quit (Quit: Leaving) | |
| [22:46:07] | jheizer (jheizer!~jheizer@c-98-226-220-178.hsd1.il.comcast.net) has joined #mythtv | |
| [23:04:17] | dekarl: | thanks natanojl, jpabq. I've not heard the german equivalent (the word, not the concept) before tonight (gdw. = genau dann, wenn) |
| [23:08:08] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 255 seconds) | |
| [23:21:33] | stuartm: | it's not a word, but notation, it's similar to nand, nor, etc |
| [23:27:07] | dekarl: | aye, but it can be spoken like a word (is an acronym) in english/swedish but not in german. Either way, I like the concept of a simplified english language that reduces the chance of misunderstanding. We have lots of people at work who only just started to learn english (due to having learned russian instead when we still had the cold war :) so I have another use for that |
| [23:29:33] | dekarl: | does anybody know this transport stream analyser? http://wiki.videolan.org/TSinfo I'm having a hard time to locate the projects website |
| [23:38:21] | dekarl: | http://www.digitalekabeltelevisie.nl/dvb_inspector/ sounds like it might be useful, too (I'm mentioning it because it is relatively new) |
| [23:50:25] | tonsofpcs: | dekarl: I cheat. I have a Tektronix MTS 200 on my desk. |
| [23:51:27] | tonsofpcs: | also, I don't think tsinfo ever did anything... ask in #videolan |
| [23:52:57] | tonsofpcs: | correction: http://tstools.berlios.de/ |
| [23:58:45] | amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Quit: Konversation terminated!) | |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.