| Sunday, February 10th, 2013, 00:14 UTC | ||
| [00:14:44] | knightr: | jhall_, what ticket is that? Nobody except the translators are supposed to submit translation patches... |
| [00:16:04] | knightr: | s/are/is |
| [00:28:12] | jhall_: | ticket 11300 |
| [00:28:17] | jhall_: | maybe i am misreading it |
| [00:28:55] | jhall_: | probably am, I've been working with linux for years and don't understand i18n and all the new ways of locale etc |
| [00:29:41] | jhall_: | what is the Ceton recorder? |
| [00:29:58] | jhall_: | I must admit there are many things that mythtv supports I have never seen before |
| [00:30:54] | jhall_: | oh |
| [00:30:57] | jhall_: | DOH there's a wiki :P |
| [00:33:45] | sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Remote host closed the connection) | |
| [00:35:42] | sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv | |
| [00:43:15] | knightr: | jhall_, looks like he made some diffs to apply the content of one branch (deve/rtp) into master... The i18n part of that patch *should not* be applied into master and I'll add a comment on that ticket about ths.. The reason why it doesn't apply is because that translation was updated in master and the patch try to update an older version of it... As for the ceton recorder I believe it is a cablecard tuner AFAIK... |
| [00:54:47] | jhall_: | yeah just reading hte wiki |
| [00:55:03] | jhall_: | seems like a nice card |
| [00:55:08] | jhall_: | I wonder does it work well? |
| [00:55:14] | jhall_: | I wonder how much it is, I might need to get one |
| [00:56:15] | jhall_: | and as a bonus it uses that PCIE slot that I have nothing to go in |
| [01:07:15] | mad_enz (mad_enz!~Enz@dsl-173-206-174-151.tor.primus.ca) has joined #mythtv | |
| [01:09:23] | jhall_: | ok |
| [01:09:28] | jhall_: | since I do not have one of these cards |
| [01:09:37] | jhall_: | I have stripped out the i18n patch and applied the rest |
| [01:09:41] | jhall_: | in my local tree |
| [01:10:09] | jhall_: | Please let me know if some or all of the suggested patchset is merged so that I can sync my sources |
| [01:10:23] | jhall_: | Any patches I come up with will be based off this |
| [01:10:43] | jhall_: | since the work will likely be in iptv code, which (I don't think) is effected by the Ceton recorder? |
| [01:11:33] | jhall_: | hmm |
| [01:11:48] | jhall_: | I should have looked at this more closely |
| [01:11:56] | jhall_: | it appears there are merge errors |
| [01:12:04] | jhall_: | the patchset does not build |
| [01:24:34] | jhall_: | but I think because of the way these patches are constructed I can keep the iptv patches and not the recorder patches |
| [01:35:34] | jhall_: | yep I'm going to keep patches 2 .. 5 |
| [01:35:54] | jhall_: | and reading through these patches I do not see SSM |
| [01:37:11] | jhall_: | Is there time before feature freeze of 0.27 to get both http targets in m3u (IPTV) and SSM multicast? |
| [01:37:29] | jhall_: | I'm guessing SSM would be more popular than http, but I am willing to help out with both. |
| [01:56:54] | joki (joki!~joki@p54862386.dip.t-dialin.net) has quit (Ping timeout: 276 seconds) | |
| [01:57:50] | joki (joki!~joki@p548644D8.dip.t-dialin.net) has joined #mythtv | |
| [02:07:41] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 252 seconds) | |
| [02:58:49] | DouglasK (DouglasK!~douglask@2001:470:1d:2fa:64d5:e9a2:9928:7bb) has joined #mythtv | |
| [02:59:02] | DouglasK (DouglasK!~douglask@2001:470:1d:2fa:64d5:e9a2:9928:7bb) has left #mythtv ("Leaving") | |
| [03:03:08] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 244 seconds) | |
| [04:37:56] | Goga777 (Goga777!~Goga777@128-71-57-165.broadband.corbina.ru) has joined #mythtv | |
| [04:39:22] | jason1 (jason1!~jason@222-154-53-253.jetstream.xtra.co.nz) has joined #mythtv | |
| [04:46:05] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 260 seconds) | |
| [04:47:21] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv | |
| [04:48:11] | jason1 (jason1!~jason@222-154-53-253.jetstream.xtra.co.nz) has left #mythtv ("WeeChat 0.4.0") | |
| [04:50:50] | jason1 (jason1!~jason@222-154-53-253.jetstream.xtra.co.nz) has joined #mythtv | |
| [05:21:06] | Goga777 (Goga777!~Goga777@128-71-57-165.broadband.corbina.ru) has quit (Read error: Connection reset by peer) | |
| [05:21:51] | Goga777 (Goga777!~Goga777@128-71-57-165.broadband.corbina.ru) has joined #mythtv | |
| [06:04:05] | Goga777 (Goga777!~Goga777@128-71-57-165.broadband.corbina.ru) has quit (Read error: Connection reset by peer) | |
| [06:04:55] | Goga777 (Goga777!~Goga777@128-71-57-165.broadband.corbina.ru) has joined #mythtv | |
| [06:10:52] | stichnot (stichnot!~stichnot@adsl-68-127-102-161.dsl.pltn13.pacbell.net) has joined #mythtv | |
| [06:10:52] | stichnot (stichnot!~stichnot@adsl-68-127-102-161.dsl.pltn13.pacbell.net) has quit (Changing host) | |
| [06:10:53] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [06:22:26] | jason1 (jason1!~jason@222-154-53-253.jetstream.xtra.co.nz) has quit (Quit: WeeChat 0.4.0) | |
| [07:22:07] | rsiebert_ (rsiebert_!~quassel@g229055229.adsl.alicedsl.de) has joined #mythtv | |
| [07:25:08] | rsiebert (rsiebert!~quassel@g231187008.adsl.alicedsl.de) has quit (Ping timeout: 248 seconds) | |
| [08:24:13] | stoffel (stoffel!~quassel@pD9E41699.dip.t-dialin.net) has joined #mythtv | |
| [09:01:23] | dekarl (dekarl!~dekarl@p4FCEE7FA.dip.t-dialin.net) has quit (Ping timeout: 256 seconds) | |
| [09:01:37] | Tobbe5178 (Tobbe5178!~asdf@h186n5-sv-a13.ias.bredband.telia.com) has joined #mythtv | |
| [09:02:03] | dekarl (dekarl!~dekarl@p4FCEED23.dip.t-dialin.net) has joined #mythtv | |
| [09:30:37] | Goga777 (Goga777!~Goga777@128-71-57-165.broadband.corbina.ru) has quit (Read error: Connection reset by peer) | |
| [09:31:19] | Goga777 (Goga777!~Goga777@128-71-57-165.broadband.corbina.ru) has joined #mythtv | |
| [10:01:49] | SteveGoodey (SteveGoodey!~steve@host86-144-3-137.range86-144.btcentralplus.com) has joined #mythtv | |
| [10:28:08] | SteveGoodey (SteveGoodey!~steve@host86-144-3-137.range86-144.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [10:42:19] | stoffel (stoffel!~quassel@pD9E41699.dip.t-dialin.net) has quit (Ping timeout: 246 seconds) | |
| [10:54:11] | stoffel (stoffel!~quassel@pD9E4285E.dip.t-dialin.net) has joined #mythtv | |
| [11:22:23] | SteveGoodey (SteveGoodey!~steve@host86-144-3-137.range86-144.btcentralplus.com) has joined #mythtv | |
| [11:41:20] | stoffel (stoffel!~quassel@pD9E4285E.dip.t-dialin.net) has quit (Ping timeout: 252 seconds) | |
| [11:41:25] | stoffel_ (stoffel_!~quassel@pD9E41273.dip.t-dialin.net) has joined #mythtv | |
| [11:59:24] | IReboot (IReboot!~doug@CPE10bf48e67915-CM78cd8e7e342d.cpe.net.cable.rogers.com) has quit (Remote host closed the connection) | |
| [12:00:46] | 16SAAXQJ0 (16SAAXQJ0!~doug@CPE10bf48e67915-CM78cd8e7e342d.cpe.net.cable.rogers.com) has joined #mythtv | |
| [12:03:43] | Sharky112065 is now known as Sharky-Sleep | |
| [12:06:55] | stoffel_ (stoffel_!~quassel@pD9E41273.dip.t-dialin.net) has quit (Ping timeout: 260 seconds) | |
| [12:16:39] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv | |
| [12:28:06] | Steve-Goodey (Steve-Goodey!~steve@host86-144-3-137.range86-144.btcentralplus.com) has joined #mythtv | |
| [12:29:56] | Steve-Goodey (Steve-Goodey!~steve@host86-144-3-137.range86-144.btcentralplus.com) has quit (Client Quit) | |
| [12:30:09] | Steve-Goodey (Steve-Goodey!~steve@host86-144-3-137.range86-144.btcentralplus.com) has joined #mythtv | |
| [12:46:33] | stoffel (stoffel!~quassel@pD9E41273.dip.t-dialin.net) has joined #mythtv | |
| [13:17:25] | 16SAAXQJ0 (16SAAXQJ0!~doug@CPE10bf48e67915-CM78cd8e7e342d.cpe.net.cable.rogers.com) has quit (Quit: Ex-Chat) | |
| [13:49:35] | stoffel (stoffel!~quassel@pD9E41273.dip.t-dialin.net) has quit (Ping timeout: 260 seconds) | |
| [13:50:43] | Steve-Goodey (Steve-Goodey!~steve@host86-144-3-137.range86-144.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [15:36:22] | sl1ce (sl1ce!~johnathan@pool-100-0-73-123.bstnma.fios.verizon.net) has quit (Quit: Konversation terminated!) | |
| [15:38:25] | sl1ce (sl1ce!~johnathan@pool-100-0-73-123.bstnma.fios.verizon.net) has joined #mythtv | |
| [15:39:20] | sl1ce (sl1ce!~johnathan@pool-100-0-73-123.bstnma.fios.verizon.net) has quit (Client Quit) | |
| [15:49:19] | sl1ce (sl1ce!~johnathan@pool-100-0-73-123.bstnma.fios.verizon.net) has joined #mythtv | |
| [15:50:23] | b0ef (b0ef!~user@183.190.249.62.customer.cdi.no) has quit (Ping timeout: 244 seconds) | |
| [15:59:54] | IReboot_ (IReboot_!~doug@CPE10bf48e67915-CM78cd8e7e342d.cpe.net.cable.rogers.com) has joined #mythtv | |
| [16:33:14] | mad_enz (mad_enz!~Enz@dsl-173-206-174-151.tor.primus.ca) has quit (Quit: Leaving) | |
| [16:44:09] | mad_enz (mad_enz!~Enz@dsl-173-206-174-151.tor.primus.ca) has joined #mythtv | |
| [16:55:09] | Goga777 (Goga777!~Goga777@128-71-57-165.broadband.corbina.ru) has quit (Remote host closed the connection) | |
| [17:11:59] | peper03 (peper03!~richard@port-92-203-107-96.dynamic.qsc.de) has joined #mythtv | |
| [17:26:36] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 264 seconds) | |
| [17:45:45] | stichnot (stichnot!~stichnot@32.153.105.142) has joined #mythtv | |
| [17:45:45] | stichnot (stichnot!~stichnot@32.153.105.142) has quit (Changing host) | |
| [17:45:46] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [17:49:22] | stichnot: | I've committed a fix to master for #11358 (green line at bottom of HDPVR 1080i recordings). I could only test it for VDPAU and XVideo, and I'd appreciate testing on other video output methods such as OpenGL and whatever OS X uses, including non-HDPVR 1080i sources. |
| [17:49:22] | ** MythLogBot http://code.mythtv.org/trac/ticket/11358 ** | |
| [17:50:15] | stichnot: | jya: fyi, I reverted the scaling stuff and replaced it with a simple crop filter on the source material. |
| [18:00:12] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 264 seconds) | |
| [18:01:17] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [18:30:31] | Chutt: | really shouldn't hardcode the 1088->1080 |
| [18:30:49] | Chutt: | there are a number of other resolutions where there'll be padding to 16 |
| [18:32:55] | Chutt: | and unless you're cropping with the display calls (which it looks like you're not, given that you're blacking out the pixels), there'll be reduced quality due to unnecessary scaling |
| [18:53:59] | Steve-Goodey (Steve-Goodey!~Steve-Goo@host86-144-3-137.range86-144.btcentralplus.com) has joined #mythtv | |
| [18:55:40] | Steve-Goodey (Steve-Goodey!~Steve-Goo@host86-144-3-137.range86-144.btcentralplus.com) has quit (Client Quit) | |
| [18:57:19] | Steve-Goodey (Steve-Goodey!~Steve-Goo@host86-144-3-137.range86-144.btcentralplus.com) has joined #mythtv | |
| [19:06:22] | manners (manners!manners@cpc6-stav13-2-0-cust672.aztw.cable.virginmedia.com) has left #mythtv () | |
| [19:09:20] | tonsofpcs: | what Chutt said. Also, when 1088 exists shouldn't it be flagging as "I'm really 1080" ? |
| [19:40:32] | Steve-Goodey (Steve-Goodey!~Steve-Goo@host86-144-3-137.range86-144.btcentralplus.com) has quit (Remote host closed the connection) | |
| [19:44:28] | Steve-Goodey (Steve-Goodey!~Steve-Goo@host86-144-3-137.range86-144.btcentralplus.com) has joined #mythtv | |
| [19:54:19] | peper03: | danielk22: Looks like the cleanest way to handle a DVD state class in AVFD would be to create a dummy data stream and have AvFormatDecoderDVD create a data AVPacket containing the DVD state information when it updates, and then feed that packet to AVFD::GetFrame. |
| [19:55:48] | peper03: | danielk22: The main issues I see with that are: |
| [19:55:58] | peper03: | 1. Where to create the dummy stream? |
| [19:56:08] | peper03: | 2. Which codec ID to use? |
| [19:56:56] | peper03: | 3. This packet should be stored in the 'storedPackets' like to keep things synchronized, but then so should subpicture packets. Timecode discontinuities can cause problems with when a subpicture gets displayed. |
| [19:57:19] | peper03: | My initial approach would be: |
| [19:57:48] | peper03: | 1. Override FindStreamInfo and add a new ScanDataStream method to be called from ScanStreams to keep track of the stream index. |
| [19:58:13] | peper03: | 2. AV_CODEC_ID_NONE – There doesn't seem to be anything else and defining a new enum isn't feasible – or is there another way? |
| [19:59:34] | peper03: | 3. Is storing subpicture/subtitle packets in 'storedPackets' going to cause issues with other video sources? What about other data packets? |
| [19:59:37] | peper03: | Would a new method like 'canStorePacket' (overridden in AvFormatDecoderDVD) be best to allow us to only store the packets that need to be synchronized? |
| [20:00:51] | peper03: | Do you see any issues using one of the 'priv' fields in VideoFrame to pass the state info to the player class or would it be better to define a new 'metadata' field? Maybe as a pointer to a base interface class to allow us to determine the type of data? |
| [20:01:48] | peper03: | A separate field would avoid the issue of collision. |
| [20:03:24] | peper03: | All the changes in AVFD would be purely to add support for the additional requirements. Any new functionality would go into AvFormatDecoderDVD. Calling 'isDVD' in AVFD is a bit icky, particularly when there's a derived class anyway. |
| [20:30:42] | jpabq_ (jpabq_!~quassel@mythtv/developer/jpabq) has quit (Remote host closed the connection) | |
| [20:30:43] | jpabq (jpabq!~quassel@mythtv/developer/jpabq) has quit (Read error: Connection reset by peer) | |
| [21:00:10] | stoffel (stoffel!~quassel@pD9E4202C.dip.t-dialin.net) has joined #mythtv | |
| [21:08:23] | stoffel (stoffel!~quassel@pD9E4202C.dip.t-dialin.net) has quit (Ping timeout: 252 seconds) | |
| [21:10:32] | stoffel (stoffel!~quassel@pD9E42D1E.dip.t-dialin.net) has joined #mythtv | |
| [21:18:38] | gigem (gigem!~david@mythtv/developer/gigem) has quit (Quit: WeeChat 0.3.8) | |
| [21:20:03] | gigem (gigem!~david@pool-71-123-128-124.dllstx.fios.verizon.net) has joined #mythtv | |
| [21:20:03] | gigem (gigem!~david@pool-71-123-128-124.dllstx.fios.verizon.net) has quit (Changing host) | |
| [21:20:04] | gigem (gigem!~david@mythtv/developer/gigem) has joined #mythtv | |
| [21:22:29] | gigem (gigem!~david@mythtv/developer/gigem) has quit (Client Quit) | |
| [21:23:51] | gigem (gigem!~david@pool-71-123-128-124.dllstx.fios.verizon.net) has joined #mythtv | |
| [21:23:51] | gigem (gigem!~david@pool-71-123-128-124.dllstx.fios.verizon.net) has quit (Changing host) | |
| [21:23:52] | gigem (gigem!~david@mythtv/developer/gigem) has joined #mythtv | |
| [21:25:17] | SteveGoodey (SteveGoodey!~steve@host86-144-3-137.range86-144.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [21:36:49] | SmallR2002 (SmallR2002!~quassel@c-98-253-173-240.hsd1.il.comcast.net) has quit (Ping timeout: 246 seconds) | |
| [21:39:50] | tonsofpcs: | peper03: I'm still a bit unsure of what you're trying. Are you trying to pass DVD structures inside a TS/PS or is this for some other purpose? |
| [21:41:51] | tonsofpcs: | I thought DVD data could already be transported in a TS... |
| [21:45:12] | stoffel (stoffel!~quassel@pD9E42D1E.dip.t-dialin.net) has quit (Remote host closed the connection) | |
| [21:46:06] | jpabq (jpabq!~quassel@75-161-90-147.albq.qwest.net) has joined #mythtv | |
| [21:46:06] | jpabq (jpabq!~quassel@75-161-90-147.albq.qwest.net) has quit (Changing host) | |
| [21:46:07] | jpabq (jpabq!~quassel@mythtv/developer/jpabq) has joined #mythtv | |
| [21:46:09] | jpabq_ (jpabq_!~quassel@mythtv/developer/jpabq) has joined #mythtv | |
| [21:47:24] | jpabq_ (jpabq_!~quassel@mythtv/developer/jpabq) has quit (Remote host closed the connection) | |
| [21:47:25] | jpabq (jpabq!~quassel@mythtv/developer/jpabq) has quit (Read error: Connection reset by peer) | |
| [21:50:34] | Steve-Goodey (Steve-Goodey!~Steve-Goo@host86-144-3-137.range86-144.btcentralplus.com) has quit (Remote host closed the connection) | |
| [22:05:20] | peper03: | tonsofpcs: AvFormatDecoder reads a frame (be it audio, video or subpicture) and the underlying buffer provides as many PS packets as needed to make that frame. There are also 'navigation packets', which provide all sorts of additional data. Unfortunately the ffmpeg library that implements the 'read packets until we have a complete frame' loop filters out anything that isn't video, audio or subpicture. |
| [22:07:15] | tonsofpcs: | is it an ffmpeg issue or an issue with the options being passed? |
| [22:07:21] | peper03: | At the moment, all the information in the navigation packets in processed in the bit of code that provides the individual packets to ffmpeg. The problem is that there is a delay between reading the normal frames (audio/video/subpicture) in, processing them and displaying them. |
| [22:08:26] | peper03: | A few tests I made shows this to sometimes be up to 1.5 seconds (depends on things like the video profile used and how the DVD is mastered – GOP size etc.) |
| [22:10:13] | peper03: | The way the code is at the moment, we have code that determines how to process/display the DVD data making decisions based on the 'current' state of the DVD processor. That's things like 'are we showing a still image?' or 'are we in a menu?'. |
| [22:10:55] | tonsofpcs: | is there a way to make the ffmpeg lib pass them through? |
| [22:12:32] | peper03: | That data is currently only available from the class that is reading the data in from the DVD, which means we're making decisions on how to display video (for example) based on what the DVD state *will* be in e.g. 1.5 seconds time, not what it was when the current video frame was read. |
| [22:13:21] | peper03: | I don't think so. I've looked at the ffmpeg code and it explicitly filters out anything that isn't video, audio or subpicture. |
| [22:14:02] | skd5aner: | peper03: btw... wanted to say thanks for all the work you've been doing lately! it's been great to have someone put that much focus on the DVD stuff :) |
| [22:14:53] | peper03: | What I'm trying to do is work round that and provide the same information via a different route. |
| [22:16:37] | peper03: | skd5aner: Thanks! It all started with stuttering menus and now I know more about DVD internals than I probably want to :) Once you've fixed one problem, you start to think 'if I've looked at that, I could look at this' and one thing leads to another! |
| [22:17:21] | skd5aner: | Glad to hear you were willing to stick with it... new blood in the dev ranks is a good thing :) |
| [22:17:22] | peper03: | skd5aner: I don't actually watch *that* many DVDs but the WAF tends to take a nose-dive when you *do* want to watch something together and find it doesn't work! |
| [22:17:57] | skd5aner: | yea, we didn't watch a lot either until my daughter was born – now we watch as many ISOs as we do recordings |
| [22:19:33] | peper03: | Heh, finding a new DVD that I've got the kids all excited about doesn't play is even worse for the stress levels :) Thankfully, I think that has only happened once :) |
| [22:21:49] | peper03: | I'm quite happy to keep at it for as long as I keep finding issues (even small ones) and my patches are accepted, which hasn't been much of an issue so far, I'm pleased to say :) |
| [22:22:43] | tonsofpcs: | peper03: hmm, any way to abstract the ffmpeg code so it doesn't filter? or maybe buffer and map the packets to PTS/DTS and rematch them on the output of ffmpeg? |
| [22:23:23] | Sharky-Sleep is now known as Sharky112065 | |
| [22:26:45] | peper03: | tonsofpcs: Not that I'm aware of. I'm not too clear on the internals of the ffmpeg code, which is why I need danielk22's input, but as far as I can tell, we point ffmpeg at the raw data and it determines what sort of a data stream it is (mpeg ts/ps, wmv, etc.). For DVDs it determines it's mpeg PS and 'helpfully' filters it. I don't know why but there's presumably a reason for adding code to do that. |
| [22:28:13] | jpabq (jpabq!~quassel@75-161-90-147.albq.qwest.net) has joined #mythtv | |
| [22:28:13] | jpabq (jpabq!~quassel@75-161-90-147.albq.qwest.net) has quit (Changing host) | |
| [22:28:13] | jpabq (jpabq!~quassel@mythtv/developer/jpabq) has joined #mythtv | |
| [22:28:45] | peper03: | tonsofpcs: It *might* be possible to force ffmpeg to assume an mpeg TS stream but then you've also got to give it the additional stuff like PAT and whatnot (this is where I really start treading on thin ice as far as my knowledge is concerned). |
| [22:29:15] | jpabq_ (jpabq_!~quassel@mythtv/developer/jpabq) has joined #mythtv | |
| [22:30:24] | peper03: | The route I'm taking sort of your other suggestions, map the packets up later. The problem is the you can get timecode discontinuities and that's one of the things you can use the navigation packets for – to tell you that there's a discontinuity. |
| [22:31:22] | peper03: | At the moment, we don't do anything about discontinuities. Possibly (probably?) we should. I've not found much information on what *should* be done when one is determined, only *how* to determine one. |
| [22:33:59] | tonsofpcs: | are you thinking discontinuities in the original or in the output relative to the input? |
| [22:36:51] | MythBuild (MythBuild!~MythBuild@alcor.mythtv.org) has quit (Remote host closed the connection) | |
| [22:37:07] | MythBuild (MythBuild!~MythBuild@alcor.mythtv.org) has joined #mythtv | |
| [22:39:59] | peper03: | tonsofpcs: In the original. There are two fields in the nav packet that tell you the start and end timecodes of that VOBU (basically a GOP if I've understood everything). If the start timecode doesn't match the previous end timecode, you've got a discontinuity. It doesn't seem to affect too much at the moment but any time you're trying to compare timecodes, you'll hit a problem if you don't know about it (which is probably the cause |
| [22:40:01] | peper03: | of #11371). |
| [22:40:01] | ** MythLogBot http://code.mythtv.org/trac/ticket/11371 ** | |
| [22:42:32] | peper03: | I've looked at the XBMC code a little bit. The way they seem to handle it is by noting any discontinuity and applying that difference to all following packets. That presumably removes the discontiuity before the decoder gets to work. |
| [22:48:30] | peper03: | That seems to make sense but it would be nice to have some specific cases and the problems you get if that isn't done. Since we don't do it, and DVD playback is not *that* bad, it's presumably only an issue under certain circumstances. |
| [22:51:26] | tonsofpcs: | how do the vlc folks do it? maybe the xbmc or vlc folks will have input? |
| [23:00:41] | jya: | stichnot: I read Mark post on the distribution list… thanks for that |
| [23:04:55] | peper03: | tonsofpcs: Don't know. I find the VLC code quite hard to follow (although that's probably just down to trying to jump in and find stuff without spending much time doing so). |
| [23:08:13] | tonsofpcs: | there is #videolan ... |
| [23:08:21] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 245 seconds) | |
| [23:17:42] | peper03: | The other thing to bear in mind is that it's not the case that VLC and XBMC play everything perfectly. When I first started looking at the DVD code, you could think from some people that XBMC was the be-all, end-all and played everything, perfectly. The first DVD I tried with XBMC locked it up solid! That's not to put XBMC down. The 2nd attempt worked fine. |
| [23:18:03] | peper03: | There are people working on XBMC and VLC that know their stuff far better than I do (they've been doing it for years, I've only just started) but the official DVD specifications are not public. I could imagine that membership of the DVD consortium gets you a lot more information and presumably plenty of test images. For the rest of us, it's a case of reading between the lines and happening to have some DVD that exhibits a certain |
| [23:18:04] | peper03: | behaviour, that you can use. |
| [23:24:19] | peper03: | That shouldn't be interpreted as "I'm not interested in how other applications do it", just that sometimes they've implemented something in a certain way "because it seems to work". Maybe there are cases when it won't and if you're not careful, everyone has more the less the same implementation that "must be right, because that's how everyone does it". |
| [23:25:58] | peper03: | But this is starting to sound like I think I'm better than they are, which isn't the case, so I'll stop :) |
| [23:26:28] | stichnot: | Chutt: (I have to post and run off again.) What other common resolutions are falsely reported to give padding to 16? There are several instances of 1088->1080 in the code that I modeled after. |
| [23:28:42] | stichnot: | Chutt: I'll take another look at the unnecessary scaling issue. I think it may currently be different depending on the video output method. |
| [23:29:17] | tonsofpcs: | oh, VLC definitely doesn't handle DVDs properly. |
| [23:29:24] | tonsofpcs: | (sorry for delay, my PC froze) |
| [23:29:52] | tonsofpcs: | but bouncing ideas off each other can definitely help realize things that aren't immediately obvious for one reason or another |
| [23:30:14] | tonsofpcs: | and I just managed devices to keep a TS running 24/7 so DVDs are a bit out of my realm :) |
| [23:30:17] | tonsofpcs: | *manage* |
| [23:30:59] | stichnot: | tonsofpcs: I'm pretty sure 1088 is always an alias for 1080. It would be nice to have a reliable way of figuring that out in general, instead of having a hard-coded list of aliases. |
| [23:31:19] | tonsofpcs: | stichnot: what's to say I won't build a file that is actually 1088 tall? |
| [23:32:55] | tonsofpcs: | I'm pretty sure that 1080-in-1088 is supposed to be flagged somehow as actually being 1080 tall... I suppose I should check a TS at my desk one of these days... |
| [23:34:54] | tonsofpcs: | google seems to suggest that there is such metadata |
| [23:37:34] | tonsofpcs: | http://www.avsforum.com/t/705146/the-official . . . vd-authoring < there's an app linked there called "HDPatch" that supposedly fixes bad 1088 headers... would be interesting to diff a file that it 'patches' |
| [23:38:04] | tonsofpcs: | also, any such alias should be a user configurable option that defaults off, imo. |
| [23:45:59] | tonsofpcs: | stichnot: 18:45:09 <@kierank> mpeg-2 just sets display resolution. mpeg-4 has cropping flags |
| [23:46:16] | tonsofpcs: | so yes, there's clearly metadata. |
| [23:50:11] | danielk22: | peper03: It might be worth pinging the Xine DVD player's development list. One of their developers mentioned on mythtv-dev that they push things through the stream. |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.