| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| mort | https://cloud.mort.coffee/s/grz3pLJ2AdMQNnj/preview - my decoder occasionally produces frames like that. Does that look like something I'm doing wrong, or an issue with the hardware or driver, or maybe something caused by a corrupted bitstream? | [07:54] |
| svarbanov | mort: wrong coded resolution? can you analyze the stream | [08:08] |
| mort | I'll check - and I should probably test with other decoders too, don't know why I didn't think about that | [08:09] |
| sailus | mchehab: Could you check out this one, please?
https://patchwork.linuxtv.org/patch/52198/ | [08:17] |
| mort | pic_width_in_mbs_minus1 starts out as 39, then suddenly switches to 29 around where the issues tarts, and then goes to 39 again when the issue stops, that's odd | [08:19] |
| svarbanov | mort: yes, then the result is expected. the decoder doesn't support dynamic resolution change
mort: what is the userspace, webrtc? | [08:21] |
| mort | yeah
I don't think I get a "resolution changed" callback, and the "encodedWidth" and "encodedHeight" values it gives me is just 0, but I can parse each SPS and see if the resolution changed and restart the decoder | [08:23] |
| svarbanov | mort: DRC is a cooperation between the v4l2 driver and userspace
mort: could you point me to the code with this callback mort: did you see Dynamic resolution change paragraph from https://lkml.org/lkml/2018/7/24/539 | [08:26] |
| mort | oh, I just noticed that _encodedWidth and _encodedHeight is occasionally an actual resolution; I assume that's whenever I get a key frame
I didn't see that paragraph no, I'll read through it svarbanov: what do you mean by "the code with this callback"? Do you mean the code in webrtc which calls the decoder's Decode function or my implementation of a webrtc video decoder? | [08:29] |
| svarbanov | mort: yes, the implementation in webrtc
mort: i.e. how dynamic resolution change is detected, or by who? | [08:32] |
| mort | svarbanov: well, my decoder is an instance of VideoDecoder (https://cs.chromium.org/chromium/src/third_party/webrtc/api/video_codecs/video_decoder.h), and the component which calls my Decode function is VMCGenericDecoder::Decode (https://cs.chromium.org/chromium/src/third_party/webrtc/modules/video_coding/generic_decoder.cc?l=212)
that's not the component which sets _encodedWidth and _encodedHeight, but I haven't looked deep enough to know where that is set | [08:35] |
| svarbanov | mort: I see | [08:37] |
| mort | https://cs.chromium.org/chromium/src/third_party/webrtc/modules/video_coding/video_receiver.cc?g=0&l=268 - that's the function which creates the VMCEncodedFrame which is passed to VMCGenericDecoder::Decode | [08:39] |
| svarbanov | mort: ok, I'm lost in the code. But from kernel driver the userspace should expect a v4l2 event with the new resolution (at least for statefull type of decoders) | [08:41] |
| mort | svarbanov: is there any chance the qualcomm venus decoder in 4.9.39 supports that?
I would assume it doesn't because the dynamic resolution change stuff looks pretty new | [08:43] |
| svarbanov | mort: yes, there is a chance. I'm currently work on that
mort: here is the event handling code https://cs.chromium.org/chromium/src/media/gpu/v4l2/v4l2_video_decode_accelerator.cc?type=cs&q=V4L2_EVENT_SOURCE_CHANGE&g=0&l=1365 mort: but I don't know how webrtc is connected with chromium-browser though | [08:44] |
| mort | the code which interacts with v4l2 in this case isn't in the webrtc library though, I'm using webrtc and passing in my own video decoder (and video encoder) which webrtc is using | [08:48] |
| svarbanov | mort: in that case you have to implement that resolution change handling, right? | [08:50] |
| mort | yeah, I thought you were asking where/how WebRTC parses the resolution and passes it to me
that isn't particularly difficult, but I had no idea WebRTC would just change resolution on me like that; when it wants me to change resolution while I'm decoding, it just shuts down the encoder and starts up a new one, so I assumed it would do the same with decoding | [08:51] |
| ................................................... (idle for 4h10mn) | ||
| sailus | mchehab: Ping? | [13:03] |
| ......................... (idle for 2h0mn) | ||
| *** | benjiG has left
prabhakarlad has left | [15:03] |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |