Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

What is the input format for mpi_enc #1

Closed
dalmatele opened this issue Sep 20, 2017 · 15 comments
Closed

What is the input format for mpi_enc #1

dalmatele opened this issue Sep 20, 2017 · 15 comments

Comments

@dalmatele
Copy link

Hi, I've a problem when using MPP lib.
I can not understand what type of data to input for MPP encode.
When I feed data to mpi task, I always got the packet with same size.
@HermanChen
Copy link
Owner

mpi task is a container of MppFrame and MppPacket. You can refer to mpi_enc_test. There is sample of how to attach frame to task and send to mpp. Then output task will carry a packet with its length as its valid data size. The packet size is the fix buffer total length.

@dalmatele
Copy link
Author

dalmatele commented Sep 21, 2017 •
edited

@HermanChen:
Thanks for your reply.
When I tried mpi_enc_test, I've given it an input file and I've outputed the value of input buffer and output data of packet but I've had the same problem:

  • Input buffer: It already has had data.
  • Output packet: data has had same size with "0 0 0 0 .." value.
    And the mpi_enc_test has not reported any problem.
    The output video is unuseable.
    As I think, maybe:
  • mpi_enc_test needs a specific input format.
  • Encode module auto recognizes that the input buffer is incorrect format and it gives me the wrong result, doesn't it?

@dalmatele
Copy link
Author

dalmatele commented Sep 21, 2017 •
edited

And this is output I've dumped:

0000000 0000 2000 7466 7079 7369 6d6f 0000 0002
0000010 7369 6d6f 7369 326f 7661 3163 706d 3134
0000020 0000 0800 7266 6565 0700 a817 646d 7461
0000030 0000 0000 0000 0000 0000 0000 0000 0000
*
00717d0 0000 c502 6f6d 766f 0000 6c00 766d 6468
00717e0 0000 0000 0000 0000 0000 0000 0000 e803
00717f0 0000 9e15 0100 0000 0001 0000 0000 0000
0071800 0000 0000 0100 0000 0000 0000 0000 0000
*
0071820 0000 0000 0040 0000 0000 0000 0000 0000
0071830 0000 0000 0000 0000 0000 0000 0000 0000
0071840 0000 0200 0000 ef01 7274 6b61 0000 5c00
0071850 6b74 6468 0000 0300 0000 0000 0000 0000
0071860 0000 0100 0000 0000 0000 9e15 0000 0000
0071870 0000 0000 0000 0000 0000 0000 0100 0000
*
0071890 0000 0000 0000 0000 0000 0000 0040 0000
00718a0 3002 0000 4001 0000 0000 2400 6465 7374
00718b0 0000 1c00 6c65 7473 0000 0000 0000 0100
00718c0 0000 9e15 0000 0000 0100 0000 0000 6701
00718d0 646d 6169 0000 2000 646d 6468 0000 0000
00718e0 0000 0000 0000 0000 0000 003c 0100 004c
00718f0 c455 0000 0000 2d00 6468 726c 0000 0000
0071900 0000 0000 6976 6564 0000 0000 0000 0000
0071910 0000 0000 6956 6564 486f 6e61 6c64 7265
0071920 0000 0100 6d12 6e69 0066 0000 7614 686d
0071930 0064 0000 0001 0000 0000 0000 0000 0000
0071940 6424 6e69 0066 0000 641c 6572 0066 0000
0071950 0000 0000 0001 0000 750c 6c72 0020 0000
0071960 0001 0000 73d2 6274 006c 0000 736e 7374
0071970 0064 0000 0000 0000 0001 0000 615e 6376
0071980 0031 0000 0000 0000 0001 0000 0000 0000
0071990 0000 0000 0000 0000 0200 0130 0040 0048
00719a0 0000 0048 0000 0000 0000 0001 0000 0000
00719b0 0000 0000 0000 0000 0000 0000 0000 0000
00719c0 0000 0000 0000 0000 0000 0000 ff18 00ff
00719d0 0000 6108 6376 0043 0000 7318 7474 0073
00719e0 0000 0000 0000 0001 0000 00a6 0200 0000
00719f0 0000 731c 7374 0063 0000 0000 0000 0001
0071a00 0000 0001 0000 00a6 0000 0001 0000 7314
0071a10 7374 007a 0000 0000 0a00 00f0 0000 00a6
0071a20 0000 7314 6374 006f 0000 0000 0000 0001
0071a30 0000 0030 0000 7562 7464 0061 0000 6d5a
0071a40 7465 0061 0000 0000 0000 6821 6c64 0072
0071a50 0000 0000 0000 6d00 6964 6172 7070 006c
0071a60 0000 0000 0000 0000 0000 2d00 6c69 7473
0071a70 0000 2500 74a9 6f6f 0000 1d00 6164 6174
0071a80 0000 0100 0000 0000 614c 6676 3735 372e
0071a90 2e38 3031 0030
0071a95

@sliver-chen
Copy link
Contributor

sliver-chen commented Sep 25, 2017 •
edited

@dalmatele

  1. you should specify input data format in cmd line when use mpi_enc_test
  2. can you describe how you use it? such as how do you use mpi_enc_test like
    ./mpi_enc_test -i xxx -o xxx -f x -t x -w x -h x
  3. can you upload a input file and dump file?

the above may help us to deal your problem

@dalmatele
Copy link
Author

This is my command:
sudo ./mpi_enc_test -i ../../data/small.mp4 -w 560 -h 320 -f 4 -t 7 -d 2 -o output_enc.mp4
But, now I saw in kern.log:
mpp_dev_ioctl:545: unknown mpp ioctl cmd 40086c03
Maybe we have something wrong in kernel?

@sliver-chen
Copy link
Contributor

@dalmatele
i see your cmd line
sudo ./mpi_enc_test -i ../../data/small.mp4 -w 560 -h 320 -f 4 -t 7 -d 2 -o output_enc.mp4

  1. you specify the input file as small.mp4
    so small.mp4 is a mp4 file? maybe you need to specify as a yuv file accroding to choosed format

@dalmatele
Copy link
Author

@sliver-chen no, the extension is only my file's name. In fact that it's a YUV file. But my output_enc.mp4 is unusable.
As I said above, maybe we have bug in kernel VPU driver.

@sliver-chen
Copy link
Contributor

sliver-chen commented Sep 25, 2017 •
edited

@dalmatele
ok let we get more message from the error log
you can set proc debug option to get more about it.
just do like tihis,
echo 0xffff > /sys/module/vcodec_service/parameters/debug
it is a kernel debug switch,then wo can get more about error

and i suggest you test source file with ffmpeg
using ffmpeg tools to identify it.
ffmpeg -s 560x320 -i small.yuv output_enc.h264
then play it with vlc or elecard tools

Because i can get correctly compress stream by using mpi_enc_test
So maybe we need above operating to check it.

Or you can provide your souce yuv file to me? i think it is the best method to resolve it.
In addition to that，tell me your chip type.

@dalmatele
Copy link
Author

dalmatele commented Sep 26, 2017 •
edited

screen shot 2017-09-26 at 3 21 15 pm

Sorry, but I can not find this file. I've tried to change /sys/module/rk_vcodec/parameters/debug instead. But output is the same. I've attached my list of files in /sys/module directory. My chip is RK3328.

@dalmatele
Copy link
Author

dalmatele commented Sep 26, 2017 •
edited

@sliver-chen
Maybe I've known problem.
In mpp_device.c we had:
#define VPU_IOC_MAGIC 'l'

#define VPU_IOC_SET_CLIENT_TYPE _IOW(VPU_IOC_MAGIC, 1, unsigned long)
#define VPU_IOC_GET_HW_FUSE_STATUS _IOW(VPU_IOC_MAGIC, 2, unsigned long)
#define VPU_IOC_SET_REG _IOW(VPU_IOC_MAGIC, 3, unsigned long)
#define VPU_IOC_GET_REG _IOW(VPU_IOC_MAGIC, 4, unsigned long)
#define VPU_IOC_PROBE_IOMMU_STATUS _IOR(VPU_IOC_MAGIC, 5, unsigned long)
#define VPU_IOC_WRITE(nr, size) _IOC(_IOC_WRITE, VPU_IOC_MAGIC, (nr), (size))

But in kernel we defined, mpp_dev_common.h:

#define MPP_IOC_MAGIC 'l'
#define MPP_IOC_SET_CLIENT_TYPE _IOW(MPP_IOC_MAGIC, 1, u32)
#define MPP_IOC_GET_HW_FUSE_STATUS _IOW(MPP_IOC_MAGIC, 2, u32)
#define MPP_IOC_SET_REG _IOW(MPP_IOC_MAGIC, 3, u32)
#define MPP_IOC_GET_REG _IOW(MPP_IOC_MAGIC, 4, u32)
#define MPP_IOC_PROBE_IOMMU_STATUS _IOR(MPP_IOC_MAGIC, 5, u32)

@sliver-chen
Copy link
Contributor

@dalmatele
please send your source file to my email to recurrence problem
my email is sliver.chen@rock-chips.com

@dalmatele
Copy link
Author

@sliver-chen
I've sent you sample file.
Please check it.
Thank you.

@sliver-chen
Copy link
Contributor

sliver-chen commented Sep 27, 2017 •
edited

@dalmatele
I get the correctly result in my board.
With these check,i think maybe your kernel version is too late
You had better to update it.

@dalmatele
Copy link
Author

I've used this kernel:
Linux rock64 4.4.77-rockchip-ayufan-93 #1 SMP Tue Aug 29 09:35:00 UTC 2017 aarch64 GNU/Linux
I think it's the newest version.
Can you show me your kernel version?

HermanChen pushed a commit that referenced this issue Sep 5, 2018
@HermanChen
Fix buffer overflow scanning soc_name.
621dd85 
The soc_name we read from device-tree is NUL-separated so we need to
replace intervening NUL chars, but we don't want to replace the last
one, or the next call to strstr() will overflow the buffer.

Detected with address-sanitizer:

    ==3271==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7f940026a0 at pc 0x7f97df7160 bp 0x7fee1fa8e0 sp 0x7fee1fa958
    READ of size 97 at 0x7f940026a0 thread T0
        #0 0x7f97df715f  (/usr/lib/libasan.so.3+0x4215f)
        #1 0x7f97df745b in __interceptor_strstr (/usr/lib/libasan.so.3+0x4245b)
        #2 0x7f97d6b27b in MppPlatformService::MppPlatformService() (/usr/lib/librockchip_mpp.so.1+0x8727b)
        #3 0x7f97d6b64f in mpp_get_vcodec_type (/usr/lib/librockchip_mpp.so.1+0x8764f)
        #4 0x7f97d38da3 in hal_h264d_init (/usr/lib/librockchip_mpp.so.1+0x54da3)

    0x7f940026a0 is located 0 bytes to the right of 96-byte region [0x7f94002640,0x7f940026a0)
    allocated by thread T0 here:
        #0 0x7f97e6445b in __interceptor_posix_memalign (/usr/lib/libasan.so.3+0xaf45b)
        #1 0x7f97d6ed13 in os_malloc (/usr/lib/librockchip_mpp.so.1+0x8ad13)
        #2 0x7f97d6e54b in mpp_osal_malloc (/usr/lib/librockchip_mpp.so.1+0x8a54b)
        #3 0x7f97d6b1d7 in MppPlatformService::MppPlatformService() (/usr/lib/librockchip_mpp.so.1+0x871d7)
        #4 0x7f97d6b64f in mpp_get_vcodec_type (/usr/lib/librockchip_mpp.so.1+0x8764f)
        #5 0x7f97d38da3 in hal_h264d_init (/usr/lib/librockchip_mpp.so.1+0x54da3)
        #6 0x7f97d387c7 in mpp_hal_init (/usr/lib/librockchip_mpp.so.1+0x547c7)
        #7 0x7f97d02ad3 in mpp_dec_init (/usr/lib/librockchip_mpp.so.1+0x1ead3)
        #8 0x7f97cfda3f in Mpp::init(MppCtxType, MppCodingType) (/usr/lib/librockchip_mpp.so.1+0x19a3f)
        #9 0x7f97d0056f in mpp_init (/usr/lib/librockchip_mpp.so.1+0x1c56f)
        #10 0x404347 in mpi_dec_test_decode (/home/root/rockchip-mpp-test/mpi_dec_test+0x404347)
        #11 0x4057b3 in main (/home/root/rockchip-mpp-test/mpi_dec_test+0x4057b3)
        #12 0x7f97bba563 in __libc_start_main (/lib/libc.so.6+0x1f563)
        #13 0x402217  (/home/root/rockchip-mpp-test/mpi_dec_test+0x402217)

    SUMMARY: AddressSanitizer: heap-buffer-overflow (/usr/lib/libasan.so.3+0x4215f)
    Shadow bytes around the buggy address:
      0x1ff2800480: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x1ff2800490: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x1ff28004a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x1ff28004b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x1ff28004c0: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
    =>0x1ff28004d0: 00 00 00 00[fa]fa fa fa fa fa fa fa 00 00 00 00
      0x1ff28004e0: 00 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa
      0x1ff28004f0: 00 00 00 00 00 00 00 00 00 00 00 00 fa fa fa fa
      0x1ff2800500: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x1ff2800510: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x1ff2800520: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
    Shadow byte legend (one shadow byte represents 8 application bytes):
      Addressable:           00
      Partially addressable: 01 02 03 04 05 06 07
      Heap left redzone:       fa

Change-Id: Ia529035847cc23c612e4039e3d445db9d014d31f
Signed-off-by: Yann Dirson <yann@blade-group.com>
@ethancwchen
Copy link

firefly@firefly:~/mpp-release/build/linux/aarch64/test$ sudo mpi_enc_test -t 7 -w 640 -h 2
72 -i sintel_480x272_yuv420p.yuv -o t.h264 -f 4
mpi_enc_test: cmd parse result:
mpi_enc_test: input file name: sintel_480x272_yuv420p.yuv
mpi_enc_test: output file name: t.h264
mpi_enc_test: width : 640
mpi_enc_test: height : 272
mpi_enc_test: format : 4
mpi_enc_test: type : 7
mpi_enc_test: debug flag : 0
mpi_enc_test: mpi_enc_test start
mpp_rt: NOT found ion allocator
mpp_rt: found drm allocator
mpi_enc_test: mpi_enc_test encoder test start w 640 h 272 type 7
mpi: mpp version: Without VCS info
mpi_enc_test: mpi_enc_test bps 652800 fps 30 gop 60
h264e_api: h264e_config MPP_ENC_SET_RC_CFG bps 652800 [612000 : 693600]
mpi_enc_test: test_mpp_run encoded frame 0 size 0
mpi_enc_test: test_mpp_run encoded frame 1 size 0
mpi_enc_test: test_mpp_run encoded frame 2 size 0
mpi_enc_test: test_mpp_run encoded frame 3 size 0
mpi_enc_test: test_mpp_run encoded frame 4 size 0
mpi_enc_test: test_mpp_run encoded frame 5 size 0
mpi_enc_test: test_mpp_run encoded frame 6 size 0
mpi_enc_test: test_mpp_run encoded frame 7 size 0
mpi_enc_test: test_mpp_run encoded frame 8 size 0
mpi_enc_test: test_mpp_run encoded frame 9 size 0
mpi_enc_test: test_mpp_run encoded frame 10 size 0
mpi_enc_test: test_mpp_run encoded frame 11 size 0
mpi_enc_test: test_mpp_run encoded frame 12 size 0
mpi_enc_test: test_mpp_run encoded frame 13 size 0

@Justa-Cai Justa-Cai mentioned this issue Nov 18, 2020
Closed
HermanChen pushed a commit that referenced this issue Feb 25, 2022
@Caesar-github @HermanChen
[mpp_service]: Fix error on reg offset setup
5c0859c 
Fix error in commit fb3390c
Error log:

[   60.923201] rk_vcodec: reg[-2080222496] + offset 127
[   60.923216] Unable to handle kernel paging request at virtual address ffffff83263859f4
[   61.004607] Mem abort info:
[   61.004877]   ESR = 0x96000005
[   61.005154]   EC = 0x25: DABT (current EL), IL = 32 bits
[   61.005623]   SET = 0, FnV = 0
[   61.005898]   EA = 0, S1PTW = 0
[   61.006172] Data abort info:
[   61.006425]   ISV = 0, ISS = 0x00000005
[   61.006764]   CM = 0, WnR = 0
[   61.007031] swapper pgtable: 4k pages, 39-bit VAs, pgdp=00000000017e5000
[   61.007621] [ffffff83263859f4] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000
[   61.008407] Internal error: Oops: 96000005 [#1] SMP
[   61.008835] Modules linked in: rk_vcodec
[   61.009194] CPU: 1 PID: 1537 Comm: mpp_dec_parser Not tainted 5.10.66 #10
[   61.009793] Hardware name: Rockchip RK3588 EVB3 LP5 V10 Board (DT)
[   61.010340] pstate: 60400009 (nZCv daif +PAN -UAO -TCO BTYPE=--)
[   61.010900] pc : mpp_translate_reg_offset_info+0xec/0xfc [rk_vcodec]
[   61.011469] lr : mpp_translate_reg_offset_info+0xdc/0xfc [rk_vcodec]
[   61.012025] sp : ffffffc013f33a90

Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Signed-off-by: Herman Chen <herman.chen@rock-chips.com>
Change-Id: I023db0c7c930ec54bfbc1141bef3543a295b165a
HermanChen pushed a commit that referenced this issue Jul 22, 2022
@HermanChen
[allocator]: fix dma_heap allocator
652e18f 
segment fault happened in mpp_allocator_put.
 #00 pc 00102e14  /vendor/lib/libmpp.so (mpp_allocator_put+272)
 #1 pc 0004705c  /vendor/lib/libmpp.so (MppBufferService::~MppBufferService()+536)

Signed-off-by: xueman.ruan <xueman.ruan@rock-chips.com>
Change-Id: Ia4f9a3b4823bf6a5d8f3fdfd85055630222c0b43
@jiale-gdyd jiale-gdyd mentioned this issue Aug 2, 2022
Closed
HermanChen pushed a commit that referenced this issue Dec 9, 2022
@qvoid
[iep2]:fix crash on mv update
2c93f73 
backtrace:
      #00 pc 00071fa4  /vendor/lib/libmpp.so (iep2_is_subt_mv+40)
      #1 pc 00072290  /vendor/lib/libmpp.so (iep2_update_gmv+548)
      #2 pc 0007056c  /vendor/lib/libmpp.so (iep2_done+176)

Change-Id: I0d8cd49a3df87150273216ac0110baae4918c14a
Signed-off-by: Johnson Ding <johnson.ding@rock-chips.com>
HermanChen pushed a commit that referenced this issue Dec 27, 2022
@HermanChen
[mpp_buffer]: fix group callback crash
5d3623a 
thread1:
  1)control(MPP_DEC_SET_EXT_BUF_GROUP)
  2)mpp_buffer_group_set_callback
    p->callback = callback;
thread2:
  1)mpp_buffer_commit
  2)mpp_buffer_create
    group->callback(group->arg, group);
    But arg is NULL now.

backtrace:
  #00 (Mpp::notify(void*))
  #1 (mpp_buffer_create+712)
  #2 (mpp_buffer_import_with_tag+212)
  #3 (commit_memory_handle+116)

Signed-off-by: Grey Li <grey.li@rock-chips.com>
Change-Id: Id50e2f1b46d127c8bf0fe8080751949fcccc6e25
HermanChen pushed a commit that referenced this issue Nov 1, 2023
@HermanChen
fix[mpp_dec]:fix mpp_destroy crash
09e859a 
Fixed a crash issue in mpp_destroy stage caused by calling members of a recycled parser thread.

crash backtrace:
#00 pc 00084882  /apex/com.android.runtime/lib/bionic/libc.so (pthread_mutex_lock+6)
#1 pc 00081434  /vendor/lib/libmpp.so (mpp_dec_notify_normal(MppDecImpl_t*, unsigned int)+32)
#2 pc 0007d6cc  /vendor/lib/libmpp.so (mpp_dec_callback_slot(char const*, void*, int, void*)+112)
#3 pc 000937f0  /vendor/lib/libmpp.so (mpp_buf_slot_clr_flag+944)
#4 pc 000da960  /vendor/lib/libmpp.so (mpp_hevc_unref_frame+168)
#5 pc 000d1c50  /vendor/lib/libmpp.so (h265d_deinit+32)
#6 pc 00081908  /vendor/lib/libmpp.so (mpp_parser_deinit+40)
#7 pc 0007e24c  /vendor/lib/libmpp.so (mpp_dec_deinit+548)
#8 pc 0006b4f0  /vendor/lib/libmpp.so (Mpp::clear()+104)
#9 pc 0006b61c  /vendor/lib/libmpp.so (Mpp::~Mpp()+12)
#10 pc 0006f7e0  /vendor/lib/libmpp.so (mpp_destroy+152)
#11 pc 00003d1c  /vendor/bin/mpi_dec_test (dec_decode+984)


Change-Id: I985168aa6ef30a265fce17c2d9765c17a24075c8
Signed-off-by: Yanjun Liao <yanjun.liao@rock-chips.com>
HermanChen pushed a commit that referenced this issue Feb 6, 2024
@qvoid
fix[h265e_vepu580]: fix SIGSEGV when reencoding
aa92148 
Hal buffer one_used marking will be wrong when reencoding.

Error log:
    "hal_bufs: hal_bufs_get_buf invalid input impl 0xf3500a60 buf_idx 4"
backtrace:
  #00 pc 0023e39c  /vendor/lib/libmpp.so (vepu580_h265_set_hw_address+328)
  #1 pc 0023f344  /vendor/lib/libmpp.so (hal_h265e_v580_gen_regs+2432)
  #2 pc 00233980  /vendor/lib/libmpp.so (hal_h265ev2_gen_regs+132)
  #3 pc 0008de04  /vendor/lib/libmpp.so (mpp_enc_hal_gen_regs+200)
  #4 pc 000805f0  /vendor/lib/libmpp.so (mpp_enc_normal(Mpp*, EncAsyncTaskInfo_t*)+1988)
  #5 pc 0007b380  /vendor/lib/libmpp.so (try_proc_normal_task(MppEncImpl_t*, EncAsyncTaskInfo_t*)+128)
  #6 pc 00078e50  /vendor/lib/libmpp.so (mpp_enc_thread+1340)

Change-Id: I5137a3db0ff63ee55a83c2d63da4430d2fc362b1
Signed-off-by: Johnson Ding <johnson.ding@rock-chips.com>
HermanChen added a commit that referenced this issue Feb 6, 2024
@HermanChen
fix[vproc]: Fix deadlock in vproc thread
9431bbc 
BUG is reported from https://redmine.rock-chips.com/issues/464206

Thread 18 (LWP 2440):
#0  __lll_lock_wait (futex=0x7f34000d48, private=0) at lowlevellock.c:52
#1  0x0000007fab5b1540 in __GI___pthread_mutex_lock (mutex=0x7f34000d48) at pthread_mutex_lock.c:115
#2  0x0000007fa9e0299c in dec_vproc_signal (ctx=0x7f34001260) at ../git/mpp/vproc/mpp_dec_vproc.cpp:929
#3  0x0000007fa9df5bdc in mpp_dec_notify (ctx=0x7f602be600, flag=1088) at ../git/mpp/codec/mpp_dec.cpp:956
#4  0x0000007fa9e0ef30 in mpp_buffer_ref_dec (buffer=0x7f6403f6c8, caller=caller@entry=0x7fa9ee300c "mpp_frame_deinit") at ../git/mpp/base/mpp_buffer_impl.cpp:509
#5  0x0000007fa9e0fb84 in mpp_buffer_put_with_caller (buffer=<optimized out>, caller=caller@entry=0x7fa9ee300c "mpp_frame_deinit") at ../git/mpp/base/mpp_buffer.cpp:105
#6  0x0000007fa9e11820 in mpp_frame_deinit (frame=frame@entry=0x7f602ec340) at ../git/mpp/base/mpp_frame.cpp:85
#7  0x0000007fabd6bf4c in rkmpp_release_frame (opaque=<optimized out>, data=0x7f602ba600 <error: Cannot access memory at address 0x7f602ba600>) at src/libavcodec/rkmppdec.c:339
#8  0x0000007fab9547dc in buffer_replace (src=0x0, dst=<optimized out>) at src/libavutil/buffer.c:133
#9  av_buffer_unref (buf=<optimized out>) at src/libavutil/buffer.c:144
#10 0x0000007fac714bb8 in mp_image_destructor (ptr=0x7f60252c80) at ../../../../../../sources/mpv/video/mp_image.c:209
#11 0x0000007fac748d40 in ta_free (ptr=0x7f60252c80) at ../../../../../../sources/mpv/ta/ta.c:244
#12 0x0000007fac715178 in mp_image_unrefp (p_img=p_img@entry=0x7f4c00bfc0) at ../../../../../../sources/mpv/video/mp_image.c:472
#13 0x0000007fac73396c in wlbuf_pool_entry_release (data=0x7f4c00bfa0, wl_buffer=<optimized out>) at ../../../../../../sources/mpv/video/out/wlbuf_pool.c:132
#14 0x0000007fb4cfe328 in ffi_call_SYSV () at ../libffi-3.3/src/aarch64/sysv.S:114
#15 0x0000007fb4cfdb44 in ffi_call_int (cif=cif@entry=0x7f70fdec80, fn=0x7f70fdeca0, orig_rvalue=orig_rvalue@entry=0x0, avalue=0x10, avalue@entry=0x7f70fded50, closure=0x200000001, closure@entry=0x0) at ../libffi-3.3/src/aarch64/ffi.c:747
#16 0x0000007fb4cfdf24 in ffi_call (cif=cif@entry=0x7f70fdec80, fn=<optimized out>, rvalue=rvalue@entry=0x0, avalue=avalue@entry=0x7f70fded50) at ../libffi-3.3/src/aarch64/ffi.c:756
#17 0x0000007faa49c7c0 in wl_closure_invoke (closure=0x7f4c00bff0, flags=<optimized out>, target=<optimized out>, opcode=0, data=<optimized out>) at ../wayland-1.22.0/src/connection.c:1025
#18 0x0000007faa499df0 in dispatch_event (display=display@entry=0x7f4c001d40, queue=<optimized out>) at ../wayland-1.22.0/src/wayland-client.c:1644
#19 0x0000007faa49b2c8 in dispatch_queue (queue=0x7f4c001e30, display=0x7f4c001d40) at ../wayland-1.22.0/src/wayland-client.c:1790
#20 wl_display_dispatch_queue_pending (display=0x7f4c001d40, queue=0x7f4c001e30) at ../wayland-1.22.0/src/wayland-client.c:2032
#21 0x0000007faa49b2f4 in wl_display_dispatch_pending (display=<optimized out>) at ../wayland-1.22.0/src/wayland-client.c:2095
#22 0x0000007fac73e2cc in vo_wayland_dispatch_events (wl=0x7f4c000e40, nfds=nfds@entry=2, timeout=timeout@entry=100) at ../../../../../../sources/mpv/video/out/wayland_common.c:1933
#23 0x0000007fac741d7c in vo_wayland_wait_events_timeout (vo=vo@entry=0x7f600abed0, timeout_ms=timeout_ms@entry=100) at ../../../../../../sources/mpv/video/out/wayland_common.c:2594
#24 0x0000007fac73baf4 in draw_frame (vo=0x7f600abed0, frame=0x7f302063b0) at ../../../../../../sources/mpv/video/out/vo_dmabuf_wayland.c:1113
#25 0x0000007fac7360c4 in render_frame (vo=0x7f600abed0) at ../../../../../../sources/mpv/video/out/vo.c:984
#26 vo_thread (ptr=0x7f600abed0) at ../../../../../../sources/mpv/video/out/vo.c:1123
#27 0x0000007fab5af370 in start_thread (arg=0x7f72ffbe06) at pthread_create.c:477
#28 0x0000007fab51bedc in thread_start () at ../sysdeps/unix/sysv/linux/aarch64/clone.S:78

Thread 14 (LWP 3455):
#0  __lll_lock_wait (futex=0x7f60208040, private=0) at lowlevellock.c:52
#1  0x0000007fab5b1540 in __GI___pthread_mutex_lock (mutex=mutex@entry=0x7f60208040) at pthread_mutex_lock.c:115
#2  0x0000007fa9e0ef48 in mpp_buffer_ref_dec (buffer=0x7f6406fee8, caller=caller@entry=0x7fa9ee1ae7 "check_entry_unused") at ../git/mpp/base/mpp_buffer_impl.cpp:503
#3  0x0000007fa9e0fb84 in mpp_buffer_put_with_caller (buffer=<optimized out>, caller=caller@entry=0x7fa9ee1ae7 "check_entry_unused") at ../git/mpp/base/mpp_buffer.cpp:105
#4  0x0000007fa9e0bf1c in check_entry_unused (entry=0x7f601ef530, impl=0x7f60263ec0) at ../git/mpp/base/mpp_buf_slot.cpp:627
#5  mpp_buf_slot_clr_flag (slots=0x7f60263ec0, index=<optimized out>, type=type@entry=SLOT_QUEUE_USE) at ../git/mpp/base/mpp_buf_slot.cpp:919
#6  0x0000007fa9e00eb0 in dec_vproc_clr_prev0 (ctx=ctx@entry=0x7f34001260) at ../git/mpp/vproc/mpp_dec_vproc.cpp:149
#7  0x0000007fa9e00fd0 in dec_vproc_clr_prev (ctx=ctx@entry=0x7f34001260) at ../git/mpp/vproc/mpp_dec_vproc.cpp:180
#8  0x0000007fa9e012b8 in dec_vproc_thread (data=0x7f34001260) at ../git/mpp/vproc/mpp_dec_vproc.cpp:631
#9  0x0000007fab5af370 in start_thread (arg=0x7f47ffdf16) at pthread_create.c:477
#10 0x0000007fab51bedc in thread_start () at ../sysdeps/unix/sysv/linux/aarch64/clone.S:78

Signed-off-by: Herman Chen <herman.chen@rock-chips.com>
Change-Id: I742e55e745c46a4adb229e2f6f0e2a2c3498e369
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@HermanChen @dalmatele @ethancwchen @sliver-chen