Linux: Add camera support for P1P #1189
Comments
|
thanks for doing this~ we already verified here, it works on both X1 series and P1P |
|
@spuiuk is this the same on your side? |
|
No. The camera works fine. It is a low number of frames as expected for the P1P. I'll try rebuilding for the latest v1.4.2 branch and retry. |
|
I found the pts is wrong on my side anyway, it is strange it works well on your side |
|
Could it be because some versions of libraries could be different because of the Fedora build? I've uploaded a screen cast. |
|
thanks just submitted a patch to fix it on v1.4.2 branch |
|
Interesting. I wonder if we should just do this for h.264 also. It's not like we have a particularly steady frame rate anyway, and the two clocks could in theory diverge in such a way that it makes trouble later. |
|
oops it seems related to the jpeg decoder: 0:00:21.986561795 754446 0x55d2c0e56de0 INFO GST_PLUGIN_LOADING gstplugin.c:987:_priv_gst_plugin_load_file_for_registry: plugin "/usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgsttypefindfunctions.so" loaded |
|
I have no idea on the core stacks(core dump thread is 754446): |
|
@jwise any ideas？ |
|
That's strange. I would be much more inclined to believe that the That said, I have found that with the size of the slicer built in debug mode (1.5GB+ of debug symbols!), I don't have a P1P to reproduce this on my own but if it comes down to it, I guess I don't actually need one of my own, I only need one to be paired to my account. So if you have one on the US cloud somewhere we can figure out how to pair it to my account so I can reproduce it, I suppose. |
yes, you are correct Thread 708 "source:src" received signal SIGSEGV, Segmentation fault. |
|
Very dismaying. Yes, I would try using There might be other ways to use the processor trace functionality that are less slow. This one probably works... eventually... |
|
Oh, good news. It 'only' seemed to take three minutes to decode the instruction trace (on my puny i7-10510U). And once it decoded it, it seemed like it was happy. So only a cup of coffee, maybe not all of lunch. If you want an instruction-by-instruction trace of what happened, try |
|
found some decode error, maybe I need to use the debug library of gstreamer? |
|
@jwise and found it will find /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstnvcodec.so instead so it seems the libgstjpeg.so on ubuntu doesn't work well with our jpeg stream |
|
Very interesting. I think the message Maybe try
|
|
after using 'record btrace bts' Thread 711 "source:src" received signal SIGSEGV, Segmentation fault. |
|
it seems when decoding the jpeg data by using libjpeg I will dump the frame data to try a decompress by libjpeg |
|
the jpeg decoder in my gstreamer: Plugin Details: GObject Pad Templates: SRC template: 'src' Element has no clocking capabilities. Pads: Element Properties: |
|
Ohhhhh, I bet I know what is going on. I wonder if the libjpeg that Gstreamer is linking against is incompatible with the libjpeg built into Bambu Studio. The libjpeg built into Bambu Studio is rather old; my system has libjpeg.so.8.2.2 (jconfig.h header says 2.1.2), but Bambu Studio links against, apparently, "JPEG/2.0.6.zip". I wonder if we're mixing symbols or something, and the internals of the libjpegs are different. Should we instead dynamically link against the system libjpeg? |
|
but the libjpeg in bambu_studio is not used in this cases currently we use static linking for all these libraries included, especially on windows&&mac |
|
I suspect that is what is happening, but I don't know for sure. (You could probably find out with In my build of So, I guess, if you hit the |
|
I dumped a jpeg from gstbambusrc.c:gst_bambusrc_create so it seems you are right I also tried to build the libjpeg.a in deps of bambu_studio I will try to change the libjpeg to dynamic for a try |
|
oops, just missed one flag(WITH_JPEG8) when building 2.1.5 so I just checked my libjpeg.so on ubuntu maybe we need to add a detect logic of jpeg version before building the deps BTW: even using 2.0.6, with -DWITH_JPEG8=ON, it also can work. |
|
Oh, I see why that works: So I guess that is, in theory, ABI compatible. I dunno. It still makes me uneasy :) It seems like it solves the problem for this system, but could break on other systems in the other direction (i.e., if a system gstreamer links against jpeg6, then this breaks). I think I continue to advocate for using a dynamically linked libjpeg, if possible. |
Great~ thank you very much |
|
Included in v1.5.0 Public Beta |
PR #1045 adds camera support for X1 series of printers. This however doesn't work on a P1P since the stream on the P1P uses mjpeg stream instead of H264 for the X1 series.
A change was proposed by @jwise in that PR which would also make it work for the P1P. . I have gone ahead and tested the proposed change and can confirm that it works for the P1P.
The patch I used on the latest v1.4.2 branch as mentioned in a comment to PR #1045 is as follows
My repo with this patch is at https://github.com/spuiuk/BambuStudio/tree/test_pip_video
and a test Appimage available at www.spui.uk/BambuStudio/BambuStudio_F37_v01.04.02.13-5-g5bd2b114.AppImage
(The Appimage is built slightly differently for my Fedora 37 system)
I have been unable to test if this still works with the X1 series as I do not have the hardware with me.
The text was updated successfully, but these errors were encountered: