| 00:52 | shesselba | _rmk_: kind of did. Have X running on DT-enabled Armada DRM, but on fbdev only. Compiled libdrm-armada but xorg driver depends on galcore includes |
| 00:53 | shesselba | and on galcore.ko also? |
| 00:53 | _rmk_ | yea but its not quite the standard galcore kernel side |
| 00:53 | _rmk_ | because I had to add dmabuf support there too |
| 00:54 | shesselba | Wanted to run a bunch of tests for tda sync fixes w/ audio on HDMI first |
| 00:54 | _rmk_ | I'll dig out a megapatch for galcore tomorrow for you. |
| 00:54 | bencoh | _rmk_: one of the reasons I'm working on a multimedia pipeline framework is that we don't want gstreamer :) |
| 00:54 | shesselba | _rmk_: take your time |
| 00:56 | shesselba | I'll be busy with fixing kirkwood-i2s first. IIRC you cannot register more than one snd_soc_x on the same pdev, they all overwrite some .data pointers |
| 00:56 | _rmk_ | did you see my patch which gets rid of the kirkwood_dma_priv stuff? |
| 00:57 | shesselba | will test on original kirkwood-i2s with self-registered pdevs first |
| 00:57 | shesselba | did that go into J-F's patches? |
| 00:57 | _rmk_ | I think JF did adopt it |
| 00:58 | _rmk_ | I sent Mark Brown the delta between my tree and mainline too as a "for information" |
| 01:02 | shesselba | found it, but it didn't go into his last patches |
| 01:03 | shesselba | Will apply your patches and see if it helps |
| 01:04 | shesselba | otherwise, I will to have to start over. |
| 01:04 | _rmk_ | or hand it back to me to do :) |
| 01:05 | shesselba | _rmk_: Also, for the TDA sync stuff. Were you referring to v4 patches? Those changes sync back to sync-before-active. |
| 01:05 | _rmk_ | the one I have is from 10 June |
| 01:07 | shesselba | ok, v4 is from 20 June.. after you complained about data islands in active video ;) |
| 01:08 | shesselba | If I get audio working in time, will also test with audio playing this time |
| 01:09 | _rmk_ | well, if you send me the updated patch, I'll replace that one in my git |
| 01:09 | shesselba | you insist on also reverting sync calculation to simpler formulas? |
| 01:09 | _rmk_ | and kill my follow-on patch |
| 01:09 | shesselba | I'll send v5 asap but most likely not before next week |
| 01:10 | _rmk_ | ok |
| 02:32 | steev | Vooloo: for the record, i'm using Geexbox on my CuBox currently, and it streams videos from my *cough* media collection PC *cough* just fine over wireless |
| 09:29 | dv_ | _rmk_: true, vmeta has the 1-frame delay |
| 09:29 | dv_ | _rmk_: sometimes it also reports a complete frame to me, and that complete frame is a NULL pointer.. |
| 09:30 | dv_ | which means I have to continue feeding it input frames until it actually spits out a picture |
| 09:30 | dv_ | I have seen this happen with wmv3 and mpeg1. not with h264 though |
| 09:32 | dv_ | bencoh: one of the main problems with vmeta is that its undocumented. finding out how to decode with it isnt that hard. its the corner cases that are a problem. |
| 09:33 | dv_ | sure, there is marvell's gstreamer 0.10 plugin, but there are several bits in it that are there for no apparent reason. was it a fix for a hardware bug? was it a leftover from refactoring and/or repository merging? no one knows. |
| 09:54 | bencoh | documentation is the new unicorn :? |
| 12:24 | _rmk_ | dv_: try guessing the codec IDs btw. |
| 14:00 | dv_ | _rmk_: ? |
| 14:00 | dv_ | ah, you mean, for the direct vmeta API |
| 14:01 | dv_ | hmm right now things are working well with the IPP layer. I think I will leave it at that until there is a pressing need to ditch it |
| 21:38 | dv_ | jnettlet: https://github.com/dv1/gst-vmeta |
| 22:08 | rmull | dv_: Is this ready for use? |
| 22:09 | dv_ | I'd say so. I didnt test it with lots of videos yet, but I did test it with all supported formats, and it worked |
| 22:09 | rmull | oh, cool |
| 22:09 | rmull | I will bookmark it for when I get a chance to play |
| 22:09 | rmull | Thanks! |
| 22:09 | dv_ | there is one limiting factor at the moment: there is no modified xvimagesink for it |
| 22:09 | dv_ | I am working on it |
| 22:09 | dv_ | so, it plays etc. but its CPU usage could be better |
| 22:10 | dv_ | thats not a decoder problem, it is simply because the regular xvimagesink copies the output frame. marvell's modified xvimagesink passes the buffer's physical pointer to the driver instead, through a hack |
| 22:10 | dv_ | I hope I will have a modified sink in a few days |
| 22:12 | rmull | Does this replace the gst-plugins-marvell stuff, or does it work alongside? |
| 22:13 | dv_ | work alongside. gst-plugins-marvell is for 0.10, mine is for 1.0 |
| 22:14 | rmull | okay, thanks. |
| 22:14 | rmull | I have a hard time keeping all the gst stuff straight in my head |
| 22:15 | dv_ | yeah, it is especially confusing together with the random marvell code drops |
| 22:16 | dv_ | there are two marvell gst packages: gst-plugins-marvell , containing vmetadec and several software decoders for AAC etc. and gst-plugins-bmmxv , contains the modified imagesink |
| 22:16 | dv_ | there is a newer version of the second one, which is called gst-plugins-vmetaxv |
| 22:17 | dv_ | add to that the whole hard/softfp thing, and you get headaches :) |
| 22:17 | rmull | yes indeed |
| 22:18 | rmull | Is gst-plugins-vmetaxv running on the cubox? I haven't touched all the stuff in a while but I don't recall seeing that name |
| 22:18 | dv_ | this one is pretty new, and originally comes from the OLPC repos |
| 22:19 | dv_ | (OLPC and Cubox both use Marvell Armada SoCs) |
| 22:20 | dv_ | main change is the library used for getting physical buffer addresses out of virtual ones |
| 22:20 | rmull | I see |
| 22:20 | rmull | Thank you for the updates |
| 22:22 | rmull | Full disclosure though, I got one of those EOMA68 A20 cards to play with |
| 22:24 | dv_ | what are these? |
| 22:25 | rmull | http://elinux.org/Embedded_Open_Modular_Architecture/EOMA-68 |
| 22:26 | rmull | It's an ARM board in a PCMCIA form factor with a standardized connector interface - it's meant to be modular, so that one could swap the same CPU card in to different devices like TVs, tablets, laptops, etc |
| 22:26 | rmull | And upgrade the CPU card keeping the host system the same is also possible |
| 22:26 | rmull | It's an open hardware design |
| 22:26 | rmull | The first engineering samples that went out use Allwinner A20 CPUs |
| 22:28 | dv_ | oh cool idea |
| 23:04 | jnettlet | dv_, cool I will take a look at it in the morning |