好奇的猫

> 请问楼主，你使用mjpeg硬件解码正常吗，我使用mpi_dec_test.c修改用来解码，解出来的yuv422sp有的能正常渲染，有的花屏，检查过mjepg源都能正常渲染 @circlefangzm 能解码，但是drm显示我没弄成。其他drm显示正常。你用什么显示的？

谢谢您的及时回复。文档除了https://github.com/rockchip-linux/mpp/tree/develop/doc，还有别的吗？这里感觉还不不够详细。我的目的就是把解码后的帧通过网络发送出去（相当于只读），也得先sync出来是吧，这个sync_begin只是这对解码buffer吧？要在packet放入之前做吗？ 另外我这个目的直接用mpp_buffer_read不行吗？

那默认情况下，半内部分配的buffer是cached还是uncached的呢？直接拷贝可以memcpy或者mpp_buffer_read都可以是吧? 还有如果需要sync那么什么时候begin什么时候end呢？

另外解码出来第一帧也没有info change帧，正常吗？除了显示有撕裂感，画面倒是很正常，延迟也很低很稳定

> 码流 buffer cache 问题，MppBuffer 送解码之加一个 mpp_buffer_sync_end 感谢大神的及时回复，抱歉不是特别明白，搜了一下只看到编码时有用到这两个函数，就是frame加载图片之前是个begin，加载之后用end。但是解码您说加这个是针对送给解码器的packet来说的，还是从解码器拿到的frame来说的。比如下面的流程，大概加到什么地方呢？ mpi->poll(ctx, MPP_PORT_INPUT, MPP_POLL_BLOCK); mpi->dequeue(ctx, MPP_PORT_INPUT, &task); /* input queue */ ret = mpp_task_meta_set_packet(task, KEY_INPUT_PACKET, packet); ret = mpp_task_meta_set_frame(task, KEY_OUTPUT_FRAME, frame); mpi->enqueue(ctx, MPP_PORT_INPUT,...

> 说的是要把解码输入的 packet 的 MppBuffer 给 sync_end 一下 sync_end 函数是把 cpu 写的数据确实地写入到 ddr 里去给硬件访问 > > 在这个之前 ret = mpp_task_meta_set_packet(task, KEY_INPUT_PACKET, packet); 试了不行。无论mpp_packet_init_with_buffer前加不加sync_begin都一样。 我感觉对mppbuffer的使用可能还存在着一些误解，主要有两个疑问： 1. [当我拿到摄像头的数据地址和大小的时候，应该怎么给packet？mjpeg给packet的时候一定需要再拷贝一次吗？这个packet一定需要关联一个mppbuffer吗？我现在参考的是这个](https://github.com/rockchip-linux/mpp/issues/592)。因为我试过别的方法都不太好使，所以我的做法就是偷偷从frame的buffergroup里分了一个mppbuffer专门给这个packet用（永久的，或每解完一帧释放还给buffergroup都没区别），再把摄像头数据memcpy到这个buffer里，最后mpp_packet_init_with_bufer初始化packet，然后packet再设一下pos和length就给input task。 2. framebuffer里目前也是初始化的时候拿到了一个mppbuffer给frame用(mpp_frame_set_buffer)，永久的，没有解完一帧还给buffergroup（试过每帧都还回去也没区别）。 不知道这里做有没有什么问题，我用的是libuvc，uvc回调里拿到data后就调用decode（准备packet，inputtask），那解码后的帧是另一个线程。

> 区分两个东西，cpu malloc 出来的 buffer 和硬件使用的 buffer，cpu malloc 出来的 buffer 是给 cpu 用的，无法直接给硬件使用，因为硬件的 mmu 和 cpu 的不同，使用的是不同的映射方式，所以硬件使用的 buffer 是单独配和建 mmu 表的。一般情况下都需要拷贝。 给硬件用的 buffer 抽象成 MppBuffer，MppPacket 可以认为是通用的 cpu buffer 和硬件 buffer...

> 把摄像头数据memcpy到这个buffer里——之后再做 sync_enc 应该是可以的 可以把异常的图像贴上来看看是什么样的 https://github.com/user-attachments/assets/a37d268d-5f11-4b59-aa14-9b1710b21687 麻烦大神看看，右边是字典，没有波纹，左边快速变化的地方有。如果变化的区域大，会更明显。但实际上源头一同录的视频完全没问题

谢谢您的及时回复。 解码拿到帧后，就是取出fd，转成handle，用这个handle申请drmmodeaddfb2，然后就drmmodesetplane了（2个primary，4个overlay都能支持nv12，但只有一个plane有显示）。addfb2和setplane我看延时也不大（1ms左右）。

应该没有释放回。因为最早我只有一个线程，在uvc的回调里拿到帧给input_task，out_task拿到解码NV12给DRM，显示完uvc回调才结束，然后才是下一帧。跟现在做成两个线程没有看到任何明显区别。 而且我现在的做法是packet用的buffer和frame用的buffer，就是初始化时以及固定了，没有在buffergroup里轮转，每帧都是固定的两个buffer，也没有任何的put back或deinit。