popcornmix / omxplayer

omxplayer
GNU General Public License v2.0
1.01k stars 334 forks source link

COMXAudio::Decode timeout, but --audio_queue and/or --audio_fifo doesnt solve; #230

Open brunogm0 opened 10 years ago

brunogm0 commented 10 years ago

First 512MB RPi archlinux latest GPU_mem=64;

I tried different fifo e queue sizes : --audio_queue 1 --audio_fifo 1 FAIL; --audio_queue 16 --audio_fifo 16 FAIL; or even --video_queue 192 or --video_queue 1 or --threshold 1..128 doesnt solve; it SOLVES and plays correctly if --video_fifo 2 in some cases. Others it doesnt matter big or small.

GPU_mem=72+ solves but as the amount of content i threw at it shows is a problem of defaults and ALLOCATION ORDER. Its clear that audio buffers not only are 64k versus 80k, but the allocation order has to prioritize audio. Even with big buffers for video or really small one like 0.1. Audio timeout was triggered. So If audio buffers are allocated first even if video buffers are reduced the situation is better. It appears the dataflow between buffers is broken in some place. Also from ALSA and Pulseaudio its generally good to match hardware buffers in the lowest granularity but Pulse total buffer depends on the latency requirements of the applications. Like a music player can buffer 10s to improve sleep time and reduce wakeups. And VOIP will set to minimum buffer. (https://wiki.archlinux.org/index.php/PulseAudio#Setting_the_default_fragment_number_and_buffer_size_in_PulseAudio) 3 fragments of 48ms in my IntelHDA for example. Maybe video_queue can be dynamic matched to (free ARM memory)/2. Or more preciselly follow VideoBufferVerifier rules, maxbitrate = 2X(averagebitrate)+current_freeBuffer. Also vcgencmd cache_flush frees some occupied memory even after omxplayer exits, so besides Deinitialize a cache_flush at exit? Sometimes even without decode timeout and stats pacing correctly, video doesnt start, but if i change to a sample that plays and back the other works normal (Leak somewhere?). In these situations vcdbg free memory even is higher than after boot by 6MB. Then most samples work but a few just dies with :

DEBUG: COMXCoreComponent::Initialize OMX.broadcom.video_decode input port 130 output port 131 m_handle 0x15409f0 T:1734050167 DEBUG: Keyboard: Process() m_bStop 0 T:1734053082 DEBUG: COMXCoreComponent::AllocInputBuffers component(OMX.broadcom.video_decode) - port(130), nBufferCountMin(1), nBufferCountActual(60), nBufferSize(81920), nBufferAlignmen(16) T:1734070641 DEBUG: Keyboard: Process() m_bStop 0 T:1734085519 ERROR: COMXCoreComponent::DecoderEventHandler OMX.broadcom.video_decode - OMX_ErrorStreamCorrupt, Bitstream corrupt T:1734091114 DEBUG: Keyboard: Process() m_bStop 0 T:1734110824 ERROR: COMXCoreComponent::FreeInputBuffers WaitForCommand:OMX_CommandPortDisable failed on OMX.broadcom.video_decode omx_err(0x8000100b) T:1734111699 DEBUG: Keyboard: Process() m_bStop 0 T:1734113596 DEBUG: COMXCoreComponent::Deinitialize : OMX.broadcom.video_decode handle 0x15409f0 T:1734121071 DEBUG: OMXClock::OMXStop T:1734132115 DEBUG: OMXThread::Run - Exited thread with id -1317014448 T:1734133378 DEBUG: OMXThread::StopThread - Thread stopped T:1734138939 DEBUG: COMXCoreComponent::Deinitialize : OMX.broadcom.clock handle 0x16f1450

 sudo /opt/vc/bin/vcdbg reloc stats

Relocatable heap version 4 found at 0x1c000000 total space allocated is 44M, with 44M relocatable, 0 legacy and 0 offline 0 legacy blocks of size 2359296

small_allocs : 2 allocs : 9120 alloc_fails : 283 legacy_block_fails : 0 compactions : 21 discard_compactions : 0 aggressive_compactions : 0 aggressive_compaction_waits : 0 aggressive_compaction_timeouts: 0 locks : 0 small_locks : 0

free list at 0x1c317a60 [ 1] 0x1c000000: used 4.0K (refcount 1 lock count 0, size 0, align 4096, data 0x1c001000, d1rual) 'camera fast alloc arena' [ 2] 0x1c001000: used 1.1M (refcount 1 lock count 0, size 1128448, align 32, data 0x1c001020, d1rual) 'HDMI overlay' [ 3] 0x1c114820: used 16K (refcount 1 lock count 0, size 16384, align 32, data 0x1c114840, d0ruAl) 'audioplus_tmp_buf' [ 4] 0x1c118840: used 2.0M (refcount 1 lock count 8, size 2088960, align 4096, data 0x1c119000, d3rual) 'ARM FB' 0x1c317840: free 544 [ 226] 0x1c317a60: used 544 (refcount 1 lock count 0, size 512, align 4, data 0x1c317a80, d0rual) 'ILCS VC buffer pool' 41M free memory in 1 free block(s)
largest free block is 41M bytes (OBS.: after boot is 35M)

Some SAMPLES: nostro.fr/amv-distant-echo/ (High10P 60fps, but others also good to use) ketsuryu.com/dl/en/jagdmeister-by-cenit.mp4/ ( mostly fine -video_fifo 1.5 -video_queue1.5) http://www.mmnt.net/db/0/0/helpedia.com/pub/multimedia/x264/testvideos (especially kenross and 7.Vortexx)

brunogm0 commented 9 years ago

Sorry, too much life problems. After some considerable tests and updating a few times the firmware and retesting. The current buffering is too big so the cpu starves and even if successfully cached to much time passed and part of this buffer has to be discarded.

Audio_buffer_seconds = 1 audio_queue = 3MB OMXAudio.cpp bufferCountActual = 4U input and 7u output. May increase output buffering to 16 but only helps in multichannel AC3 , when the cpu is occupied with other task like g++. In these config most samples have reduced cpu usage and contention. If the sample is easier buffered amount reaches 4seconds (mp3). Sometimes in KZSF sample and 4U buffer for both input and output, audio is faster than video so sync suffers.

AC3, Vorbis, Opus are the most problematic formats, dont buffer more than 1.15s with more than 45% cpu

Obs.: some vobs from NMT_DVD5_Test_Disc.5095351 with DD-EX dont play. vobs are supported?