| Wednesday, February 13th, 2013, 00:14 UTC | ||
| [00:14:01] | wagnerrp: | nephyrin: what cable company is that? it's rare to ever see anything more than 16Mbps, and ATSC doesn't even support more than 19.4 for the whole mux |
| [00:14:46] | nephyrin: | wagnerrp: 20 was a rough estimate, I was just writing a transcoding script and the test recording I grabbed ffmpeg estimated at 18.4 |
| [00:14:58] | nephyrin: | wagnerrp: So that may likely be a high end |
| [00:15:10] | wagnerrp: | as for the fsync loop, it's intended to resolve an issue with the default linux CFQ scheduler |
| [00:15:39] | wagnerrp: | where if the disk cache grows too large on its own, linux can decide to flush it all at once, and stall the system until it is finished |
| [00:15:46] | wagnerrp: | danielk222 would know more |
| [00:16:35] | wagnerrp: | are you sure that was actually the bitrate, and not just some arbitrary value set by the encoder? |
| [00:16:56] | wagnerrp: | a number of mine claim 25Mbps or so, but average around 14Mbps |
| [00:17:11] | nephyrin: | wagnerrp: ffmpeg grabs some arbitrary sized buffer and estimates from there – I can do some math though, one second |
| [00:18:08] | wagnerrp: | is this on an older 10/100 network? |
| [00:18:25] | nephyrin: | wagnerrp: Grabbing my biggest recording, it's at 7.6GiB for 1h length |
| [00:18:30] | wagnerrp: | be aware that the HDHR streams over UDP, so if you're anywhere near saturation on your network, you're going to run into trouble |
| [00:18:41] | nephyrin: | wagnerrp: So that's about 18.1mbps, less audio |
| [00:18:50] | nephyrin: | (and mux overhead) |
| [00:18:55] | wagnerrp: | yeah, 7.6GB is awfully large. much lager than i've ever seen |
| [00:19:37] | nephyrin: | wagnerrp: I thankfully have a good deal of spare CPU on this system, so I rigged up a script to transcode finished recordings to h264 |
| [00:21:57] | wagnerrp: | ugh... i really need to fix this segfault in the autoexpirer... |
| [00:22:11] | nephyrin: | wagnerrp: And yeah, this is a gigabit network. I've increased network buffer sizes and tried continuous pinging/etc., but it seems to be a myth issue. Streaming straight to VLC never has issues |
| [00:22:45] | wagnerrp: | is the recording actually damaged, or is it just stuttering streaming the recording to the frontend? |
| [00:23:02] | nephyrin: | wagnerrp: The recording is actually damaged, digital static and dropout |
| [00:23:46] | nephyrin: | mythcommflag barfs if it opens it, I often have to re-open and skip past the bad part to continue watching |
| [00:26:59] | danielk222: | nephyrin: The fsync's are a workaround for CFQ problems as wagnerrp described. It's really only required on machines that function as both frontends and backends and are using CFQ or a similar disk scheduler for the recording volume; but this is a very common setup and it rarely causes any problems (easily verified by commenting out the fsync). |
| [00:27:59] | wagnerrp: | what's with all these distros switching to init systems that can't manage to bring the network up before applications that rely on it? |
| [00:28:38] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 252 seconds) | |
| [00:30:55] | nephyrin: | danielk222: I think the issue in my specific case is that I'm using a consumer-y raid 5 that has other obligations. The fsync's essentially require it keep up and don't allow it to fall back to caching as much as it could otherwise |
| [00:32:27] | wagnerrp: | the fsync just requires the data be flushed to something non-volatile |
| [00:32:40] | wagnerrp: | usually with RAID, you only need to go to the memory cache |
| [00:32:47] | nephyrin: | wagnerrp: Software raid :-P |
| [00:35:21] | stichnot (stichnot!~stichnot@66.109.105.51) has joined #mythtv | |
| [00:35:21] | stichnot (stichnot!~stichnot@66.109.105.51) has quit (Changing host) | |
| [00:35:21] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [00:40:03] | gigem (gigem!~david@mythtv/developer/gigem) has quit (Quit: WeeChat 0.3.8) | |
| [00:40:33] | gigem (gigem!~david@mythtv/developer/gigem) has joined #mythtv | |
| [00:44:18] | mad_enz (mad_enz!~Enz@173.206.174.151) has quit (Ping timeout: 245 seconds) | |
| [00:46:16] | stichnot: | wagnerrp: I have a number of 62-minute OTA CBS recordings that mythweb reports as 7.8GB. This is presumably because this station has only one subchannel. |
| [01:00:53] | mad_enz (mad_enz!~Enz@dsl-173-206-174-151.tor.primus.ca) has joined #mythtv | |
| [01:11:55] | neufeld: | My OTA channels with HDHomerun3 are all roughly 7.7 GB/hour. Occasionally as low as 7.3, but never lower. |
| [01:15:05] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 260 seconds) | |
| [01:23:03] | sl1ce (sl1ce!~johnathan@pool-100-0-73-123.bstnma.fios.verizon.net) has quit (Quit: Konversation terminated!) | |
| [01:42:34] | sl1ce (sl1ce!~johnathan@pool-100-0-73-123.bstnma.fios.verizon.net) has joined #mythtv | |
| [01:59:46] | joki (joki!~joki@p54864467.dip.t-dialin.net) has quit (Ping timeout: 252 seconds) | |
| [02:00:05] | joki- (joki-!~joki@p548643E3.dip.t-dialin.net) has joined #mythtv | |
| [02:00:14] | joki- is now known as joki | |
| [02:15:20] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Quit: Body blow! Body blow!) | |
| [02:29:35] | nephyrin: | Is it normal that RingBuffer::UpdateRawBitrate never be called? |
| [02:43:25] | jhall_: | hi all |
| [02:43:35] | jhall_: | is QList thread-safe or do I need to protect it with a mutex? |
| [02:43:41] | jhall_: | I'm thinking a mutex |
| [02:46:23] | wagnerrp: | if you're concerned about simultaneous multithreaded access, consider a QReadWriteLock rather than a simple QMutex |
| [02:48:59] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [02:49:19] | wagnerrp: | gigem: oddly timed... just 25 minutes after you asked that... http://www.spinics.net/lists/linux-media/msg60040.html |
| [03:03:43] | jhall_: | hmm |
| [03:04:13] | jhall_: | yo uadvise then |
| [03:04:17] | jhall_: | if you don't mind |
| [03:04:26] | jhall_: | there is a packet buffer UDPPacketBVuffer() |
| [03:04:39] | jhall_: | the read handler dumps data into it |
| [03:04:57] | jhall_: | then pushes it onto a list |
| [03:05:09] | jhall_: | the write handler pops packets off and then injests them |
| [03:07:06] | jhall_: | if the read and write handlers get too close together htye will collide |
| [03:07:21] | jhall_: | and I'm not on the ml, so I have no idea somebody asked a similar question :) |
| [03:30:44] | jhall_: | danielk22: please let me know when you want to merge your changes into mainline, I'd liek you to consider evaluating my work because I have found some misses regarding signal management, destructors, and thread-safe checks. |
| [03:47:52] | Goga777 (Goga777!~Goga777@95-30-60-161.broadband.corbina.ru) has joined #mythtv | |
| [04:01:54] | gigem: | wagnerrp: Bummer! I'm on that list, but don't read it too closely any more and missed that. Perhaps stuarta can ping him and make sure he knows what's going on. |
| [04:42:09] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 248 seconds) | |
| [04:43:17] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv | |
| [05:17:31] | knightr (knightr!~knightr@mythtv/developer/knightr) has quit (Ping timeout: 245 seconds) | |
| [05:24:04] | ashes (ashes!~ashes@mtl.secondfloor.ca) has joined #mythtv | |
| [05:24:07] | ashes: | hello |
| [05:26:42] | ashes (ashes!~ashes@mtl.secondfloor.ca) has left #mythtv () | |
| [05:30:11] | knightr (knightr!~knightr@69-165-170-178.dsl.teksavvy.com) has joined #mythtv | |
| [05:30:12] | knightr (knightr!~knightr@69-165-170-178.dsl.teksavvy.com) has quit (Changing host) | |
| [05:30:12] | knightr (knightr!~knightr@mythtv/developer/knightr) has joined #mythtv | |
| [05:58:47] | Goga777 (Goga777!~Goga777@95-30-60-161.broadband.corbina.ru) has quit (Remote host closed the connection) | |
| [08:14:42] | SteveGoodey (SteveGoodey!~steve@host86-144-3-137.range86-144.btcentralplus.com) has joined #mythtv | |
| [08:24:37] | Steve_Goodey (Steve_Goodey!~steve@host86-144-3-137.range86-144.btcentralplus.com) has joined #mythtv | |
| [08:29:20] | Steve_Goodey (Steve_Goodey!~steve@host86-144-3-137.range86-144.btcentralplus.com) has quit (Client Quit) | |
| [08:29:53] | Steve_Goodey (Steve_Goodey!~steve@host86-144-3-137.range86-144.btcentralplus.com) has joined #mythtv | |
| [08:34:40] | Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:dd5b:a9fb:706d:8bc2) has joined #mythtv | |
| [08:46:53] | Lomion0815 (Lomion0815!~androirc@213-33-22-228.adsl.highway.telekom.at) has joined #mythtv | |
| [08:49:04] | Steve_Goodey (Steve_Goodey!~steve@host86-144-3-137.range86-144.btcentralplus.com) has quit (Ping timeout: 272 seconds) | |
| [08:52:12] | SteveGoodey (SteveGoodey!~steve@host86-144-3-137.range86-144.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [08:52:26] | SteveGoodey (SteveGoodey!~steve@host86-144-3-137.range86-144.btcentralplus.com) has joined #mythtv | |
| [08:54:16] | Steve_Goodey (Steve_Goodey!~steve@host86-144-3-137.range86-144.btcentralplus.com) has joined #mythtv | |
| [09:01:40] | SteveGoodey (SteveGoodey!~steve@host86-144-3-137.range86-144.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [09:04:20] | SteveGoodey (SteveGoodey!~steve@host86-144-3-137.range86-144.btcentralplus.com) has joined #mythtv | |
| [09:21:23] | Sharky112065 is now known as Sharky-Sleep | |
| [11:22:34] | Steve_Goodey (Steve_Goodey!~steve@host86-144-3-137.range86-144.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [12:16:21] | knightr (knightr!~knightr@mythtv/developer/knightr) has quit (Read error: Connection reset by peer) | |
| [12:36:47] | bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has joined #mythtv | |
| [12:40:33] | danielk222: | jhall_: You might want to just work on a github fork and create a ticket pointing to that with text describing your concerns. If you're not comfortable enough with git for that a ticket with a patch set + a description on the concerns will work too. |
| [12:44:36] | danielk222: | nephyrin: Software RAID 5 will have really atrocious performance under Linux because it waits for data to make it to disk fairly often, I don't think we can really make MythTV run acceptably under those conditions. I have a hard time working with emacs and firefox under those conditions, a soft realtime system has no chance really. |
| [12:47:22] | danielk222: | LSI makes some not ridiculously expensive RAID controllers, with flash cache, that will work well with MythTV. |
| [12:48:07] | IReboot_ (IReboot_!~doug@CPE10bf48e67915-CM78cd8e7e342d.cpe.net.cable.rogers.com) has quit (Remote host closed the connection) | |
| [12:51:17] | IReboot (IReboot!~doug@CPE10bf48e67915-CM78cd8e7e342d.cpe.net.cable.rogers.com) has joined #mythtv | |
| [13:00:23] | sl1ce (sl1ce!~johnathan@pool-100-0-73-123.bstnma.fios.verizon.net) has quit (Quit: Konversation terminated!) | |
| [13:01:30] | sl1ce (sl1ce!~johnathan@pool-100-0-73-123.bstnma.fios.verizon.net) has joined #mythtv | |
| [13:09:21] | sl1ce (sl1ce!~johnathan@pool-100-0-73-123.bstnma.fios.verizon.net) has quit (Quit: Konversation terminated!) | |
| [13:11:18] | sl1ce (sl1ce!~johnathan@pool-100-0-73-123.bstnma.fios.verizon.net) has joined #mythtv | |
| [13:33:01] | sl1ce (sl1ce!~johnathan@pool-100-0-73-123.bstnma.fios.verizon.net) has quit (Quit: Konversation terminated!) | |
| [13:35:09] | sl1ce (sl1ce!~johnathan@pool-100-0-73-123.bstnma.fios.verizon.net) has joined #mythtv | |
| [13:40:21] | sl1ce (sl1ce!~johnathan@pool-100-0-73-123.bstnma.fios.verizon.net) has quit (Quit: Konversation terminated!) | |
| [13:40:54] | Cougar (Cougar!~cougar@2a03:5880:104:10:2045:8f19:ee2c:53ee) has quit (Ping timeout: 264 seconds) | |
| [13:41:31] | sl1ce (sl1ce!~johnathan@pool-100-0-73-123.bstnma.fios.verizon.net) has joined #mythtv | |
| [13:43:13] | sl1ce (sl1ce!~johnathan@pool-100-0-73-123.bstnma.fios.verizon.net) has quit (Client Quit) | |
| [13:44:16] | sl1ce (sl1ce!~johnathan@pool-100-0-73-123.bstnma.fios.verizon.net) has joined #mythtv | |
| [13:44:20] | Cougar (Cougar!~cougar@2a03:5880:104:10:34a5:35e:2a25:b96d) has joined #mythtv | |
| [13:48:14] | SteveGoodey: | #11110 |
| [13:48:14] | ** MythLogBot http://code.mythtv.org/trac/ticket/11110 ** | |
| [13:48:50] | SteveGoodey: | Sorry, just getting the url for trac. |
| [14:17:43] | sl1ce (sl1ce!~johnathan@pool-100-0-73-123.bstnma.fios.verizon.net) has quit (Quit: Konversation terminated!) | |
| [14:19:18] | sl1ce (sl1ce!~johnathan@pool-100-0-73-123.bstnma.fios.verizon.net) has joined #mythtv | |
| [14:25:37] | jhall_: | danielk222: I can create a fork. Since I am based on the changes from # how would you like me to best proceed? I think I can easily strip out just my patches, the changes in that patchset do not conflict with mine modulo a variable name rewrite here or there. |
| [14:25:56] | jhall_: | sorry #11300 |
| [14:25:56] | ** MythLogBot http://code.mythtv.org/trac/ticket/11300 ** | |
| [15:02:00] | Goga777 (Goga777!~Goga777@95-30-60-161.broadband.corbina.ru) has joined #mythtv | |
| [15:20:13] | kth (kth!~kth@unaffiliated/kth) has joined #mythtv | |
| [15:20:39] | kth (kth!~kth@unaffiliated/kth) has quit (Client Quit) | |
| [15:22:01] | kth (kth!~kth@unaffiliated/kth) has joined #mythtv | |
| [15:29:22] | MythBuild (MythBuild!~MythBuild@alcor.mythtv.org) has quit (Remote host closed the connection) | |
| [15:29:38] | MythBuild (MythBuild!~MythBuild@alcor.mythtv.org) has joined #mythtv | |
| [15:54:22] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 244 seconds) | |
| [15:55:22] | danielk221 (danielk221!~danielk@exchange.wgen.net) has joined #mythtv | |
| [16:07:27] | Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv | |
| [16:11:30] | canthus13 (canthus13!~canthus13@shellium/member/canthus13) has joined #mythtv | |
| [16:12:45] | canthus13: | Anyone know why HDMI output would be stuck at 1024x768? When the system boots, the TV briefly reports the correct 720p resolution, but switches to 1024x768 as X starts up. |
| [16:13:12] | canthus13: | the only resolution option in the display settings is 1024x768, no refresh rates listed. |
| [16:15:47] | danielk221 (danielk221!~danielk@exchange.wgen.net) has quit (Quit: Leaving.) | |
| [16:28:07] | skd5aner: | canthus13: you want #mythtv-users |
| [16:35:58] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [16:38:40] | stichnot: | I have an interesting puzzle. I have a 10-minute sample from a user, a transcode from DVD source material with mpeg4/DIVX video and mp3lame audio. ffprobe and mythtv agree that the framerate is 29.97 and the length is 10 minutes. The mythtv playback info OSD screen indicates 24fps during playback. When mythtv plays the sample, wall-clock time is 10 minutes but the status bar shows 8... |
| [16:38:42] | stichnot: | ...minutes at the end (this is based on frame count and framerate in the absence of a seektable). Playback is smooth without indication of dropped frames. mythcommflag --rebuild calculates the duration as 8 minutes. Of course vlc gets the position/duration right during playback. |
| [16:38:58] | stichnot: | There don't seem to be any frames with the repeat_pict flag |
| [16:39:38] | stichnot: | The user says that using mp3lame audio seems to be the key factor that creates the discrepancy. |
| [16:45:14] | canthus13: | skd5aner: thanks. |
| [16:46:57] | kth (kth!~kth@unaffiliated/kth) has quit (Ping timeout: 248 seconds) | |
| [16:47:26] | kth (kth!~kth@unaffiliated/kth) has joined #mythtv | |
| [16:48:23] | canthus13 (canthus13!~canthus13@shellium/member/canthus13) has left #mythtv () | |
| [16:48:25] | stichnot: | So I'm wondering how (presumably) MythPlayer::AVSync() is figuring out to play 24fps instead of 30fps. |
| [16:49:50] | IReboot (IReboot!~doug@CPE10bf48e67915-CM78cd8e7e342d.cpe.net.cable.rogers.com) has quit (Read error: Connection reset by peer) | |
| [16:50:08] | stichnot: | ^^^ This may be a question for jpabq or taylorr. |
| [16:54:06] | IReboot_ (IReboot_!~doug@CPE10bf48e67915-CM78cd8e7e342d.cpe.net.cable.rogers.com) has joined #mythtv | |
| [17:03:46] | kth (kth!~kth@unaffiliated/kth) has quit (Read error: Connection reset by peer) | |
| [17:05:09] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 244 seconds) | |
| [17:05:57] | Goga777 (Goga777!~Goga777@95-30-60-161.broadband.corbina.ru) has quit (Remote host closed the connection) | |
| [17:07:53] | kth (kth!~kth@unaffiliated/kth) has joined #mythtv | |
| [17:11:40] | bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has quit (Quit: Ex-Chat) | |
| [17:35:02] | Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:dd5b:a9fb:706d:8bc2) has quit (Read error: Connection reset by peer) | |
| [17:43:36] | stichnot (stichnot!~stichnot@216.239.45.73) has joined #mythtv | |
| [17:43:37] | stichnot (stichnot!~stichnot@216.239.45.73) has quit (Changing host) | |
| [17:43:37] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [17:45:33] | toeb (toeb!~tob@HSI-KBW-37-49-118-160.hsi14.kabel-badenwuerttemberg.de) has quit (Ping timeout: 252 seconds) | |
| [18:04:49] | XDS2010_ (XDS2010_!uid1218@gateway/web/irccloud.com/x-knknyavrdypkrlro) has quit (Read error: Operation timed out) | |
| [18:05:05] | superm1 (superm1!uid4318@ubuntu/member/superm1) has quit (Ping timeout: 252 seconds) | |
| [18:05:50] | superm1 (superm1!uid4318@ubuntu/member/superm1) has joined #mythtv | |
| [18:08:48] | danielk22 (danielk22!~danielk@exchange.wgen.net) has joined #mythtv | |
| [18:11:37] | dekarl (dekarl!~dekarl@p4FCEEFA1.dip.t-dialin.net) has quit (Ping timeout: 256 seconds) | |
| [18:14:48] | dekarl (dekarl!~dekarl@p4FCEF760.dip.t-dialin.net) has joined #mythtv | |
| [18:17:55] | taylorr: | stichnot: AVSync is based on the frame interval (1/fps) to display each frame and looks at the A/V timestamps to make adjustments (frame drop or delay) |
| [18:19:55] | danielk22 (danielk22!~danielk@exchange.wgen.net) has quit (Quit: Leaving.) | |
| [18:21:22] | danielk22 (danielk22!~danielk@exchange.wgen.net) has joined #mythtv | |
| [18:21:55] | taylorr: | stichnot: sounds like the video was detelecined to 23.976 fps but reports 29.97 fps... the AV sync code will handle this quite gracefully... it basically starts adding extra frame delay to compensate |
| [18:22:12] | Steve_Goodey (Steve_Goodey!~steve@host86-144-3-137.range86-144.btcentralplus.com) has joined #mythtv | |
| [18:23:04] | taylorr: | stichnot: either a bug in the conversion program or the user forced the fps to the wrong value in the container |
| [18:24:17] | taylorr: | stichnot: if you get the log for the mythtv fps detection it may show the stream report 23.976 and the container report 29.97 |
| [18:26:09] | stichnot: | taylorr: the container definitely reports 29.97. Do you know where to look for fps detection? is it the jitterometer? |
| [18:26:57] | toeb (toeb!~tob@HSI-KBW-37-49-118-160.hsi14.kabel-badenwuerttemberg.de) has joined #mythtv | |
| [18:27:17] | taylorr: | it's in the AVSync code |
| [18:27:32] | taylorr: | no, wait a minute... |
| [18:28:42] | taylorr: | I think it's in avformatdecoder.cpp in the normalize_fps function |
| [18:29:24] | stichnot: | AFD: Selected FPS is 29.97 (avg 0 codec 29.97 container 29.97 estimated 29.97) |
| [18:29:52] | stichnot: | but later from jitterometer – Player(0): FPS: 24.02 Mean: 41640 Std.Dev: 14510 CPUs: 25% 12% 15% 12% |
| [18:33:23] | stichnot: | as I understand it, the jitterometer doesn't influence framerate, it just reports what is happening based on wall-clock time between frame presentations |
| [18:33:46] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
| [18:34:03] | stichnot: | so I assume MythPlayer::AVSync() is where the actual control / delay is happening |
| [18:34:23] | stichnot: | I just don't see where the discrepancy from 29.97fps is coming from |
| [18:39:52] | taylorr: | stichnot: it's in the timestamps in the video stream |
| [18:40:42] | taylorr: | if you do -v timestamps you should see them increase by a little over 40ms each frame |
| [18:41:06] | taylorr: | stichnot: what does mediainfo report? |
| [18:43:49] | stichnot: | taylorr: http://pastebin.com/NtwAcnCP for mediainfo output |
| [18:50:34] | stichnot: | taylorr: it is generating this log message every few frames: "A/V delay %1" |
| [18:51:37] | stichnot: | so I guess it is dropping video frames to synchronize with audio, I just didn't recognize that from the logs |
| [18:52:31] | stichnot: | actually, not dropping a frame, just delaying by one frame interval |
| [18:56:04] | stichnot: | which would explain the jerkiness that this video shows (and the same jerkiness shows up in vlc) |
| [19:16:36] | natanojl_ (natanojl_!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv | |
| [19:19:01] | taylorr: | stichnot: since mediainfo reports 29.97 also and it's apparent that it's 23.976 film rate when playing back there is nothing more we can do except change the way we calculate frame_interval to be next_timestamp – current_timestamp instead of 1 / fps |
| [19:19:40] | taylorr: | but then you'll have videos that have missing or broken timestamps and that'll have it's own set of issues |
| [19:23:07] | stichnot: | taylorr: the code with the comment "// wait an extra frame interval" would be executed as a result of A/V timecode drift, right? which w |
| [19:23:29] | stichnot: | which would be a function of the video itself, and not system issues during playback? |
| [19:23:55] | taylorr: | most likely due to video issue and not system |
| [19:24:42] | stichnot: | so if we could express to the player that repeat_pict+=2 then we might have consistency? |
| [19:25:40] | taylorr: | we already take into account repeat_pict |
| [19:27:16] | stichnot: | What I'm saying is that all frames of this video have repeat_pict=0, but if we were to fake repeat_pict=2 for the frames where we consistently delay an extra frame interval, then the timing could become correct. |
| [19:27:41] | taylorr: | yes, it would. |
| [19:28:45] | stichnot: | This could work for mythcommflag --rebuild where we play from start to finish without any seeking, but I would need something else for position information during playback. |
| [19:29:22] | mad_enz (mad_enz!~Enz@dsl-173-206-174-151.tor.primus.ca) has quit (Ping timeout: 272 seconds) | |
| [19:29:40] | stichnot: | I don't want to go to a lot of work to handle this corner case, but it would be nice if there were a simple solution. |
| [19:30:54] | taylorr: | I can't think of a simple solution and I don't like kludges for a broken video... the real solution is for the avi to be converted and the fps forced to 23.976... very easy to do |
| [19:31:45] | taylorr: | it's also a chance to teach people about the benefits of moving to more modern and well supported formats like mkv, mkv, etc |
| [19:32:01] | taylorr: | mp4 |
| [19:32:50] | stichnot: | I don't like it when vlc can handle it but we don't :) |
| [19:33:27] | taylorr: | you said vlc plays with stutter too? |
| [19:33:40] | stichnot: | yes, but its position information is accurate |
| [19:33:57] | taylorr: | stichnot: that's easily fixed |
| [19:34:31] | stichnot: | perhaps vlc is just using ffmpeg data for position, where my current code is using framecount / framerate in the absence of a seektable |
| [19:34:51] | taylorr: | for formats that don't support discontinuities then you used the pts_time for the position and use the ffmpeg reported duration |
| [19:35:26] | taylorr: | stichnot: ^^^ I intended to do this but never got around to it... should be simple to implement |
| [19:36:09] | stichnot: | ok. What's the best way in MythPlayer to determine such a format? |
| [19:36:30] | taylorr: | I already pass the timecode <ms> in the frame struct so you should just need to check if discontinuities are supported |
| [19:36:43] | taylorr: | stichnot: I believe ffplay does this check |
| [19:37:18] | taylorr: | stichnot: you could also just not allow seektabled for formats that don't need them :) |
| [19:37:50] | taylorr: | lemme check ffplay.... |
| [19:39:19] | taylorr: | stichnot: ic->iformat->flags & AVFMT_TS_DISCONT |
| [19:39:33] | stichnot: | good, I was just going to ask if that's it |
| [19:39:45] | taylorr: | sorry I forgot to mention this to you... it's the right way to handle these videos |
| [19:41:14] | stichnot: | taylorr: You suggested that before (only use/allow seektables if necessary). I have to think about how to support cutlists in those cases. |
| [19:41:34] | taylorr: | stichnot: I pass the display time in avformatdecoder here -> picframe->disp_timecode = NormalizeVideoTimecode(stream, temppts); |
| [19:42:06] | stichnot: | ok |
| [19:42:11] | taylorr: | stichnot: I think it's fine to just base the position/duration on the discontinuity support check |
| [19:42:41] | taylorr: | don't worry about seektables, etc because even with a seektable it might be wrong |
| [19:43:13] | taylorr: | apparently for that video you are looking at the frame duration is being calculated as 1/29.97 in ffmpeg which is wrong |
| [19:44:26] | taylorr: | and mythcommflag --rebuild uses the frame->duration to accumulate the total duration |
| [19:45:27] | stichnot: | If there is a cutlist, I would want to deal with it by computing at start of playback the timecode for each cutpoint frame, which would involve a bunch of seeks at startup |
| [19:47:57] | stichnot: | taylorr: so do you think this is in part an ffmpeg bug? |
| [19:48:01] | taylorr: | stichnot: if you want to make the seek table correct for this video you could calculate position based on disp_timecode and duration based off last_pts_timecode – first_pts_timecode |
| [19:48:29] | taylorr: | stichnot: not really, they are just computing using frame rate and not timestamp deltas |
| [19:50:39] | taylorr: | and if you are going to support seek tables for all these formats which don't support discontinuities you should probably use the timecode info instead for frame duration since it can be misreported |
| [19:51:24] | taylorr: | of course, you may need to support missing/broken timestamps which is handled in avformatdecoder |
| [19:51:44] | taylorr: | at any rate, you can go mad trying to support every broken video out in the wild :) |
| [20:04:21] | peper03 (peper03!~richard@port-92-203-64-67.dynamic.qsc.de) has joined #mythtv | |
| [20:06:04] | taylorr: | stichnot: do you have a grasp how to fix the position/duration for non-discontinuous videos? it should just be a few lines of code hopefully |
| [20:06:13] | XDS2010_ (XDS2010_!uid1218@gateway/web/irccloud.com/x-pqnlsejrkbkqooso) has joined #mythtv | |
| [20:14:35] | jhall_: | so I installed mingw32 on my linux box and ran the mythbuild.sh script found in packagin/Win32 |
| [20:14:53] | jhall_: | when it got to compiling xslt, it would not build |
| [20:15:14] | jhall_: | I'm thinking the packages are old and/or outdated or whatever. Has anybody built it for windows lately |
| [20:16:12] | jhall_: | can I try to find a newer version of xslt and install it or is everything in here version-specific in the hopes of building something? |
| [20:22:24] | kth (kth!~kth@unaffiliated/kth) has quit (Quit: Leaving.) | |
| [20:24:03] | jhall_: | WOW this is not for the faint of heart |
| [20:27:39] | jpabq: | jhall_: sorry I didn't get back to you. I had a hardware failure yesterday. Still catching up. |
| [20:39:23] | kth (kth!~kth@unaffiliated/kth) has joined #mythtv | |
| [20:41:08] | jhall_: | is ok |
| [20:41:13] | jhall_: | I figured out part of my problems |
| [20:41:29] | jhall_: | my function was trying to join a signal with no args |
| [20:41:43] | jhall_: | but the signal wants to pass QObject* |
| [20:42:07] | jhall_: | got all that sorted, now it runs for about 20 or so minutes, then crashes spactacularly with an unhandled exception |
| [20:42:28] | jhall_: | haven't looked yet but it probably has some memory management problem |
| [20:42:38] | jhall_: | probably doesn't free resourdces or something |
| [20:43:22] | jhall_: | There's still some sort of race condition going on, but it's crazy |
| [20:47:30] | IReboot_ (IReboot_!~doug@CPE10bf48e67915-CM78cd8e7e342d.cpe.net.cable.rogers.com) has quit (Quit: Ex-Chat) | |
| [20:48:17] | RDV_Linux (RDV_Linux!~doug@CPE10bf48e67915-CM78cd8e7e342d.cpe.net.cable.rogers.com) has joined #mythtv | |
| [20:48:44] | RDV_Linux (RDV_Linux!~doug@CPE10bf48e67915-CM78cd8e7e342d.cpe.net.cable.rogers.com) has quit (Client Quit) | |
| [20:50:49] | stichnot: | taylorr: yeah, I think the two snippets you posted should be sufficient |
| [20:51:25] | stichnot: | And I agree that I don't want to chase after every broken video |
| [20:58:25] | Sharky-Sleep is now known as Sharky112065 | |
| [21:00:36] | rsiebert_ (rsiebert_!~quassel@e179128168.adsl.alicedsl.de) has joined #mythtv | |
| [21:00:58] | James2 (James2!~James@office.tandyukservers.co.uk) has joined #mythtv | |
| [21:01:25] | James2: | hey guys, anyone use eclipse for working on myth? |
| [21:03:31] | rsiebert (rsiebert!~quassel@g226061013.adsl.alicedsl.de) has quit (Ping timeout: 260 seconds) | |
| [21:15:44] | Lomion0815 (Lomion0815!~androirc@213-33-22-228.adsl.highway.telekom.at) has quit (Ping timeout: 244 seconds) | |
| [21:18:32] | natanojl_ (natanojl_!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 252 seconds) | |
| [21:44:36] | Tobbe5178 (Tobbe5178!~asdf@h186n5-sv-a13.ias.bredband.telia.com) has quit (Read error: Connection reset by peer) | |
| [21:45:02] | Mousey (Mousey!~r0dent_@ross154.net) has joined #mythtv | |
| [21:50:12] | SteveGoodey (SteveGoodey!~steve@host86-144-3-137.range86-144.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [21:55:13] | Tobbe5178 (Tobbe5178!~asdf@h186n5-sv-a13.ias.bredband.telia.com) has joined #mythtv | |
| [22:09:55] | kth (kth!~kth@unaffiliated/kth) has quit (Quit: Leaving.) | |
| [22:29:25] | Steve_Goodey (Steve_Goodey!~steve@host86-144-3-137.range86-144.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [22:44:54] | peper03 (peper03!~richard@port-92-203-64-67.dynamic.qsc.de) has quit (Quit: Konversation terminated!) | |
| [22:49:50] | IReboot (IReboot!~doug@CPE10bf48e67915-CM78cd8e7e342d.cpe.net.cable.rogers.com) has joined #mythtv | |
| [23:08:51] | Mousey (Mousey!~r0dent_@ross154.net) has quit (Quit: Read Error: Connection reset by beer) | |
| [23:32:44] | Tobbe5178 (Tobbe5178!~asdf@h186n5-sv-a13.ias.bredband.telia.com) has quit (Read error: Connection reset by peer) | |
| [23:42:07] | danielk222: | James2: AFAIK No one uses it currently; but someone mentioned using it a couple few years ago. |
| [23:42:58] | taylorr: | skd5aner: did you ever get playback fixed for the recordings that caused video buffer loss? |
| [23:43:25] | skd5aner: | taylorr: yes, but I'm running -fixes with the patch that JYA provided |
| [23:43:34] | skd5aner: | ... that was later reverted |
| [23:43:51] | skd5aner: | I haven't updated since to see if it's still an issue in current -fixes or not |
| [23:46:09] | taylorr: | skd5aner: did you confirm that the video buffers didn't get lost at all? |
| [23:46:29] | skd5aner: | taylorr: you know, I don't think I turned on the OSD and looked to be honest... |
| [23:46:34] | skd5aner: | I can do that perhaps a little later tonight |
| [23:47:03] | skd5aner: | Pretty much every one of my recordings has the issue after a commerical break especially |
| [23:47:06] | taylorr: | skd5aner: I was just curious |
| [23:47:13] | skd5aner: | taylorr: yea, it's a good question |
| [23:47:27] | taylorr: | so looks like a resolution change that causes it? |
| [23:48:15] | taylorr: | skd5aner: do you have a link to the change that fixes it? |
| [23:48:48] | Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit () | |
| [23:55:17] | skd5aner: | Should be referenced on the ticket |
| [23:55:21] | skd5aner: | let me look |
| [23:56:16] | skd5aner: | #11159 |
| [23:56:16] | ** MythLogBot http://code.mythtv.org/trac/ticket/11159 ** | |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.