| 00:48 | bencoh | changing image resolution on te fly usually means crashing most of the decoders/stb out there, so, yeah, they hardly do that in the IPTV world |
| 00:48 | bencoh | (well, not most, but a lot of them) |
| 00:54 | _rmk_ | hmm. does that include aspect ratio too? |
| 01:20 | bencoh | nope, they handle aspect ratio changes well |
| 01:20 | bencoh | (since it has no real effect on the decoder settings itself) |
| 01:23 | dv_ | Yeah, stb graphics APIs usually can handle nonuniform scaling well (and that's what the aspect ratio is all about in the end) |
| 01:24 | dv_ | Also, o |
| 01:25 | dv_ | Also, I suspect actually changing resolution might pose problems with the image quality and required processing power |
| 01:45 | _rmk_ | bencoh: I've been wondering why my PVR writes mpeg2 4:3 files and stores the aspect ratio entirely separately from the stream. |
| 01:46 | _rmk_ | my guess is so it can switch the output aspect ratio on the exact frame without having to involve the mpeg decoder hardware in that |
| 01:47 | _rmk_ | though... I haven't figured out how it knows which frame to switch on |
| 01:50 | _rmk_ | (I investigated that because a mess-up one weekend with the broadcast services was crashing every machine of this type and related types in the country, and everyone was believing their machines had died |
| 01:51 | _rmk_ | and all because of one wrong character in the EPG data ! |
| 01:53 | _rmk_ | http://www.sony.co.uk/support/en/product/RDR-HXD870/news/RDR_HN |
| 10:25 | dv_ | _rmk_: I've had access to codebases of several stb's in the past. I gotta say, bugs like these do not surprise me :) |
| 10:26 | dv_ | some of these codebases look like the company threw third-rate and very junior programmers at it, thinking that consumers are used to buggy stb's anyway |
| 10:44 | jnettlet_ | hurray my 50/5 internet connection is now working properly. No more 22Mbps downloads for me. |
| 10:44 | jnettlet_ | you have to love getting an upgrade in speed while lowering you monthly bill. |
| 10:46 | dv_ | so your DSL connection is stable? |
| 10:46 | jnettlet_ | hopefully. ;-) |
| 10:46 | dv_ | jnettlet_: would it be possible to add some kind of extension string to the dovefb x11 driver? |
| 10:47 | dv_ | to be able to detect whether or not the bmm hack is in there? |
| 10:47 | jnettlet_ | You want that so the gstreamer plugin can detect it at pipeline construction? |
| 10:48 | dv_ | yes |
| 10:48 | dv_ | so I can write a new sink from scratch that works only with vmeta buffers |
| 10:48 | dv_ | the current solution is pretty ugly and hard to maintain |
| 10:50 | jnettlet_ | dv_, I am thinking we could add a property to the XVideo port as a pretty simple solution. |
| 10:52 | dv_ | hmm yes sounds good |
| 10:53 | dv_ | this way, xvimagesink is used if no support for this exists |
| 10:53 | dv_ | vmetaxvsink would fail, and gstreamer's autovideosink would automatically pick xvimagesink instead |
| 10:55 | _rmk_ | A better solution is to follow the idea I did: also pass inside the xshm buffer the fourcc, and give the passing mechanism its own fourcc code |
| 10:55 | _rmk_ | that means you can pass a bmm buffer containing any image type |
| 10:57 | _rmk_ | plus you can detect whether its supported by the presence of the fourcc code in the list of supported formats |
| 10:57 | jnettlet_ | _rmk_, but that will only work if you are using your userspace graphics stack. dv_ wants his plugin to be able to know if userspace has the functionality or not and adjust accordingly. |
| 10:57 | jnettlet_ | ah okay |
| 11:00 | jnettlet_ | doesn't vMeta always output the same decoded image type? |
| 11:30 | dv_ | I think that it could output other types as well, but in practice, UYVY is used |
| 11:31 | dv_ | so, xvideo could report something like "VMTA" as a supported format |
| 11:32 | dv_ | and my plugin can check for it and report failure if it isnt there |
| 11:57 | jnettlet_ | dv_, yeah you could use XvListImageFormats() to check for it |
| 12:03 | _rmk_ | jnettlet: no - I'm suggesting a way to fix the current setup in a manner which _is_ detectable. At the moment, it's totally undetectable and that can't be fixed without changing the way the whole thing works. |
| 12:07 | _rmk_ | any attempt to detect it by passing a bmm-formatted buffer will result in the contents of the xshm buffer being displayed on non-supporting implementations |
| 12:08 | _rmk_ | so the choices are: either put up with having a frame possibly displayed at the beginning of every video clip, or change the protocol |
| 12:19 | dv_ | well, adding the fourcc would be the second option |
| 12:19 | dv_ | I'm fine with that |
| 12:19 | dv_ | I can even use the first one as a fallback |
| 12:20 | jnettlet_ | _rmk_, just to refresh my mind on the problem I revisited the XV code in the current xorg ddx driver. As best as I can tell the code does fall back gracefully for SHM buffers. It looks at the end of the buffer for MAGIC1, if it doesn't find that it checks the beginning of the buffer for MAGIC2. If it finds any of those markers it sets SHM_VMETA and moves along, otherwise it creates a custom buffer the size of the expected frame and copies the source |
| 12:20 | jnettlet_ | into it taking into account offsets and such. |
| 12:22 | _rmk_ | looks at the start of the buffer for MAGIC1, not the end |
| 12:23 | jnettlet_ | sorry start yes. |
| 12:23 | dv_ | true. jnettlet_, look here https://github.com/dv1/gst-vmeta/blob/master/src/vmetaxvsink/vmetaxvsink.c#L458 |
| 12:23 | _rmk_ | but the point here is - it's not detectable from the application side of the X protocol without ending up with a frame being displayed on non-supporting hardware |
| 12:24 | _rmk_ | consider what happens if you pass a buffer with MAGIC1 at the start to the X server and it doesn't have this code |
| 12:25 | dv_ | btw. does the driver overwrite MAGIC1 with MAGIC2 ? or can it place MAGIC2 anywhere within the shm buffer? |
| 12:25 | _rmk_ | former |
| 12:25 | dv_ | I ask, because the marvell patches run a loop over the buffer until they find a null value |
| 12:25 | jnettlet_ | well then wouldn't it make more sense to just have the gstreamer vmeta xvimagesink to require the gstreamer vmeta decoder to be in the pipeline? |
| 12:25 | dv_ | ah no, nevermind |
| 12:26 | dv_ | confused it with something else |
| 12:26 | _rmk_ | jnettlet: so what if you have the vmeta decoder but you're running an X server without this hack? |
| 12:26 | _rmk_ | like... my X server |
| 12:26 | dv_ | jnettlet_: also, this is considered a bad approach in gstreamer |
| 12:26 | _rmk_ | dv: that's because it is :) |
| 12:27 | dv_ | jnettlet_: what if someone else provides a different decoder? all it has to do is to use the same metadata on the buffers |
| 12:28 | dv_ | the only code I have seen that does this is the marvell gst one. it checks upstream if certain demuxers are used, and if so, applies some workarounds. |
| 12:28 | dv_ | either way, I think the fourcc approach is fine. |
| 12:29 | dv_ | _rmk_: how do you pass on the dma buffers atm? |
| 12:29 | dv_ | I thought the DRM bit isnt working yet |
| 12:32 | _rmk_ | I ended up exporting them in BMM as a dmabuf, importing them into DRM (which gives me an object id), making a global name from it, and passing that name to the X server via a 'XVBO' image type |
| 12:33 | dv_ | and all you need for this is the physical address? |
| 12:33 | _rmk_ | http://ftp.arm.linux.org.uk/cgit/xf86-video-armada.git/tree/src/armada_drm_xv.c is the Xv side of my X server driver |
| 12:34 | _rmk_ | dv_: I need to mod the kernel side interface to use a phys address because at the moment I stupidly fell into the marvell trap of using the virtual address |
| 12:35 | dv_ | at least they used the physical address in the BMM hack response :) |
| 12:35 | _rmk_ | but all the construction of the DRM buffer object is on the app side |
| 12:36 | _rmk_ | basically this on the app side: |
| 12:36 | _rmk_ | fd = bmm_get_dmabuf_fd(GST_BUFFER_DATA(buf)); |
| 12:36 | _rmk_ | ret = drmPrimeFDToHandle(xvimagesink->drm->fd, fd, &handle); |
| 12:37 | _rmk_ | ret = drm_handle_flink(xvimagesink->drm, handle, &name); |
| 12:37 | _rmk_ | /* XvBO passing - pass the real image format and DRM buffer object |
| 12:37 | _rmk_ | global name to the X server */ |
| 12:37 | _rmk_ | p = (uint32_t *)xvbuf->xvbo_xvimage->data; |
| 12:37 | _rmk_ | p[0] = xvbuf->im_format; |
| 12:37 | _rmk_ | p[1] = name; |
| 12:37 | _rmk_ | (error checking omitted in that paste) |
| 12:38 | dv_ | you put a file descriptor in the gstbuffer? |
| 12:38 | _rmk_ | no - p[1] is the global drm name for the buffer |
| 12:38 | dv_ | fd = bmm_get_dmabuf_fd(GST_BUFFER_DATA(buf)); because of this I mean |
| 12:39 | dv_ | hmm |
| 12:39 | _rmk_ | dmabufs are passed to userspace as file descriptors |
| 12:39 | _rmk_ | anonymous file descriptors |
| 12:39 | dv_ | so if I were to use your modifications, I'd have to modify the decoder as well |
| 12:39 | _rmk_ | drmPrimeFDToHandle takes that file descriptor and converts it back to a dmabuf internally, allowing DRM to get access to the buffer contents |
| 12:40 | _rmk_ | the above is all in my bmmxvimagesink component |
| 12:40 | dv_ | or do you add the fd in the sink? |
| 12:40 | dv_ | hmm |
| 12:40 | _rmk_ | I missed a close(fd) after the drmPrimeFDToHandle() |
| 12:40 | dv_ | oh wait. misread something |
| 12:41 | dv_ | bmm_get_dmabuf_fd() I understood this as something that pulls the fd from the buffer data |
| 12:41 | _rmk_ | ok, I'm away now... might be around again in maybe 8 hours or so |
| 12:41 | dv_ | instead, it _creates_ an fd for the given pointer |
| 12:42 | _rmk_ | yep |
| 12:42 | dv_ | ah, now thats fine |
| 12:42 | dv_ | and I take it you'd rather want to pass a physical address to this function |
| 12:42 | dv_ | anyway, gotta continue with some other work here too. later |
| 12:42 | jnettlet_ | later |
| 13:33 | dv_ | jnettlet__: I updated the plugin . now you should be able to watch transport streams with totem as well |
| 13:34 | jnettlet__ | dv_, just saw that excellent |
| 13:35 | dv_ | I wanna try something nice with it. I will connect my dvb-t stick to the cubox, and see if I can watch TV with gstreamer and vmeta :) |
| 13:35 | jnettlet__ | good luck |
| 13:35 | dv_ | oh, speaking of dvb-t : are you aware of any vmeta deinterlacing features? |
| 13:37 | jnettlet | I know that the gstreamer 0.10 plugin has code in it to handle interlaced frames |
| 13:43 | dv_ | from what I've seen, it just stores flags to forward the information to the sink |
| 13:49 | jnettlet | yes, that is right. Then we handle the deinterlacing in the xvideo extension |
| 13:50 | dv_ | can the vmetafb driver do that? |
| 13:50 | jnettlet | there is a vmetafb driver? |
| 13:51 | dv_ | err |
| 13:51 | dv_ | dovefb |
| 13:52 | jnettlet | oh to draw directly to overlay framebuffer device |
| 13:52 | dv_ | I think the x11 driver is called "dovefb", isnt it? |
| 13:54 | jnettlet | yeah because it was originally written for the dove platforms. The Armada naming for the drm driver is really the proper classification. |
| 13:55 | jnettlet | the hardware is more similar than different between the different devices. |
| 13:56 | jnettlet | Yes the xorg dovefb driver does handle interlaced video properly. For both the overlay and textured adapters |
| 13:56 | dv_ | I wonder if the interlacing flag is passed on already |
| 13:59 | jnettlet | oh, actually we are only handling interlacing in the xorg driver for the textured adapter. Wait I know why we do that. Probably the overlay adapter gets set to the interlaced mode and the framebuffer hardware does the deinterlacing |
| 13:59 | jnettle | 13:59 * jnettlet will need to test this. |
| 14:01 | dv_ | interlacing is one of these things that I wished it would have died off a long time ago |
| 14:03 | jnettlet | dv_, it is very possible that it is not handled properly. I will add it to my list. If you test before I get to it and find out differently I would be interested in logs. |
| 14:04 | dv_ | okay |
| 14:07 | dv_ | one more thing I can check is whether or not vmeta has deblocking support for formats other than h264, as a value added feature |
| 15:32 | ralix | morning |
| 15:53 | rabeeh | hi ralix |
| 15:58 | ralix | Hi sorry, now I'm working circuit. I'll come back tomorrow I have to configure the mpd problems, so it outputs me the sound on the hdmi devices. Have a nice day! |
| 15:59 | ralix | First...Hi rabeeh ! |
| 15:59 | ralix | ;) |
| 15:59 | dv_ | ralix: if noise is the problem, try 48 kHz instead of 44.1 |
| 15:59 | ralix | ok ich try this... thx |
| 15:59 | ralix | s/ich/i |
| 16:00 | rabeeh | ralix: which distro? which kernel? |
| 16:00 | ralix | Otherwise I'm back tomorrow;) |
| 16:00 | ralix | archlinux |
| 16:00 | ralix | Linux version 3.5.7-12-ARCH+ |
| 20:09 | dv_ | jnettlet: please inform me when you have added the fourcc to the driver |
| 21:18 | _rmk_ | dv_: "and I take it you'd rather want to pass a physical address to this function" -- yes. |
| 21:19 | _rmk_ | that's something I'll look at fixing soon |
| 21:22 | dv_ | okay |
| 21:22 | dv_ | btw, looking at daniel stone's x11-wayland presentation, I hope wayland gets better support for stuff like this |
| 21:24 | _rmk_ | I think I've convinced Mark to take that driver now... it seems basically that Mark didn't bother to understand the structure of the DPCM stuff before he complained that I was abusing the ASoC internals. |
| 21:24 | _rmk_ | ... because the structure I've implemented in the CPU side of the driver is conformant with the DPCM example I have. |
| 21:25 | _rmk_ | and which he also has and finally read through yesterday |
| 21:26 | _rmk | 21:26 * _rmk_ wonders where that extra "and" crept in from |
| 21:27 | dv_ | perhaps he noticed later, and was trying to save face? |
| 21:43 | _rmk_ | hmm, think I'm slightly sunburnt on the head :( |
| 23:29 | unicorn | Hey there |
| 23:29 | unicorn | I've got a "small" problem with my cubox |
| 23:30 | unicorn | I can't get a boot anymore... |
| 23:32 | unicorn | I was having a Boostrat 2.33> prompt, and tried to reset holding the reset button, but now I can't get anymore any shell :/ |
| 23:39 | unicorn | anyone for some help? |