分析camera，发现framework和bufferqueue出现有如下错误log打印，这种log是否会导致request被丢掉，下发不到hal，该如何进行排查修复这种问题？
E BufferQueueProducer: SurfaceTexture-0-7135-2 dequeueBuffer: attempting to exceed the max dequeued buffer count (14)
E Camera3-OutputStream: getBufferLockedCommon: Stream 6: Can’t dequeue next output buffer: Function not implemented (-38)
拿不到buffer，会导致新的CaptureRequest无法下发给HAL，HAL会丢帧。
这种问题，要看当前的14个Buffer在谁头上，是HAL没还，还是SurfaceTexture没有取走。
那应该如何排查这 14 个 buffer 是 hal 持有，还是 app，是否有通用点的 log 可以确认，现在问题是 mtk 平台出现的
方法1. 可以抓Perfetto，能看出来buffer在哪里
方法2. 打开BQ debug log
/frameworks/native/libs/gui/文件夹下，BufferQueueConsumer.cpp，BufferQueueProducer.cpp，BLASTBufferQueue.cpp，Surface.cpp
把//#define LOG_NDEBUG 0注释拿掉，即改成#define LOG_NDEBUG 0
log 打印 这个Stream 6: 如何是预览的流，那是否会影响到拍照 request 下到 hal？
有可能会的，要看App的逻辑，如果App在拍照CaptureRequest里面同时带了预览和拍照的Surface，那么就会影响拍照。
预览流拿不到 buffer，会影响拍照 request 下发 hal， 这部分代码 framework 是在哪怎么判断的？app 的设计是拍照时候，预览不会停止的
有一个前提拍照request里面带了预览surface，这样prepareHalRequest时，因拿不到预览buffer就无法下发拍照request，后面我们在framework课程里面会介绍
比如camera应用的预览使用surfaceview，拍照使用ImageReader做surface，APP消费完buffer后，是要camera app自己调用releasebuffer，才能把buffer归还给BQ吗？对APP应用这块不是很熟悉
SurfaceView：consumer是SurfaceFlinger，SurfaceFlinger会负责将buffer还给BufferQueue。
ImageReader：consumer是App，需要App主动release Image来将buffer还给BufferQueue。