| T42 | <elros34> maybe because they are listed twice and still with old url instead 3.2.1.20. It would be probably faster build image based on 3.4.0.24 repositories | 09:10 |
|---|---|---|
| T42 | <elros34> btw try with http instead https | 09:11 |
| T42 | <b100dian> gst-droid question: I have a symptom that a <droidbufferpool0> turns into a <videobufferpool0> | 19:43 |
| T42 | <b100dian> And I try posting a recording from 0:00:01.225898915 to 0:00:01.629376457 (because I stripped the timestamps to get smaller message) | 19:43 |
| T42 | <b100dian> The log is here https://pastebin.ubuntu.com/p/rhVfkhSGBp/ | 19:43 |
| T42 | <b100dian> It is GST_DEBUG=5 between "Contains media_queue_buffer, count 1" and "Contains media_queue_buffer, count 0" | 19:44 |
| T42 | <b100dian> Those messages are logged in a fork https://github.com/sailfishos/gst-droid/compare/master...b100dian:gst-droid:master | 19:44 |
| T42 | <b100dian> Some notable things I get from the logs are: | 19:45 |
| T42 | <b100dian> `gstbufferpool.c:726:gst_buffer_pool_set_config:<droidbufferpool0> can't change config, we are active` | 19:45 |
| T42 | <b100dian> `gst_base_parse_chain:<h264parse0> not enough data available (only 0 bytes)` | 19:45 |
| T42 | <b100dian> `gsth264parser.c:1571:gst_h264_parser_identify_nalu_avc: Can't parse, buffer has too small size 944, offset 944` | 19:45 |
| T42 | <b100dian> `multiqueue gstmultiqueue.c:3190:single_queue_overrun_cb:<multiqueue0> Queue 1 is filled, signalling overrun` | 19:45 |
| T42 | <b100dian> `gstvideodecoder.c:4343:gst_video_decoder_negotiate_pool:<droidvdec0> didn't get downstream ALLOCATION hints` | 19:46 |
| T42 | <b100dian> Sorry for the noise, the log is much more noisier:) | 19:46 |
| T42 | <b100dian> mal: got a hunch how to debug what seems like a missing deallocation since some "queue" is filled? | 19:48 |
| mal | hmm, not right now, so much log that it takes some time to figure out what is happening | 19:51 |
| T42 | <b100dian> Of course, not asking for a fast solution here. Maybe you spot something in the log. Or maybe you have a suggestion where to look / what else to log. Any or the two would help. | 19:53 |
| mal | I wonder if that "The HAL codec format 0x7f000789 is unrecognized" is bad or not | 19:54 |
| mal | looking at the code it might not be bad | 19:56 |
| mal | probably needs some comparison to a working device, need to grab some logs at some point, maybe not today | 19:57 |
| T42 | <b100dian> that format is OMX_COLOR_FormatAndroidOpaque | 19:58 |
| T42 | <b100dian> mal: that's a good idea, I'll try to do a working device log | 19:59 |
| mal | that way we can rule out non-critical issues | 20:00 |
| T42 | <b100dian> building that gst-droid fork on OBS be like - oh no there's a chum build going on:) | 20:07 |
| mal | heh | 20:16 |
| mal | chum builds do take quite a while | 20:16 |
| mal | I hope we can at some point figure out if there is a way to make alias targets, like all 4.x.0.* would be just one target | 20:17 |
| mal | @b100dian it's always possible to build gst-droid locally | 20:19 |
| T42 | <b100dian> mm yes, but I figured since the env for that target device is on a hard drive I have in another place,.. just use obs. But the package for gst-droid should be 100% portable, you're right | 20:21 |
| T42 | <b100dian> portable = same SFOS version, but different base is ok | 20:22 |
| T42 | <Umeaman> I think I shouldn't have upgraded to 3.4.0.24. It destroyed the opportunity to use WLAN. | 23:22 |
| T42 | <Umeaman> It won't connect now. | 23:22 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!