CVideoPlayerAudio::Process - stream stalled

morfik · April 4, 2024 at 11:07 AM

I'm using LibreELEC 11.0.6 on my RPI4 (2GiB RAM). Basically everything works well -- all of my movies/tv series play well (x264/x265, mostly mkv, but also mp4 and avi containers), except for one TV series which can't be watched for unknown reasons. So when I play any of the episodes of that TV series, it plays for a short period of time 1-2min, and then it stops altogether (audio and video) -- it simply hangs. The same thing is when I want to start playing from some point in time -- it hangs instantly.

In the log I just have the following line when the video stops:

info <general>: CVideoPlayerAudio::Process - stream stalled

This is the mediainfo output for an example video:

General
Complete name : /path/to/dotted.mp4
Format : MPEG-4
Format profile : Base Media
Codec ID : isom (isom/iso2/avc1/mp41)
File size : 760 MiB
Duration : 46 min 35 s
Overall bit rate mode : Variable
Overall bit rate : 2 281 kb/s
Frame rate : 23.976 FPS
Movie name : dotted
Album : dotted
Writing application : Lavf58.33.100
Comment : dotted

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L3.1
Format settings : CABAC / 4 Ref Frames
Format settings, CABAC : Yes
Format settings, Reference frames : 4 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 46 min 32 s
Bit rate mode : Variable
Bit rate : 1 637 kb/s
Maximum bit rate : 14.0 Mb/s
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Variable
Frame rate : 23.976 (23976/1000) FPS
Minimum frame rate : 11.987 FPS
Maximum frame rate : 90 000.000 FPS
Original frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.074
Stream size : 545 MiB (72%)
Writing library : x264 core 148 r2715 7e75228
Encoding settings : cabac=1 / ref=4 / deblock=1:0:0 / analyse=0x3:0x111 / me=umh / subme=10 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=120 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / stitchable=1 / constrained_intra=0 / bframes=16 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=240 / keyint_min=121 / scenecut=0 / intra_refresh=0 / rc_lookahead=240 / rc=crf / mbtree=1 / crf=24.0 / qcomp=0.50 / qpmin=6 / qpmax=51 / qpstep=4 / vbv_maxrate=14000 / vbv_bufsize=14000 / crf_max=0.0 / nal_hrd=vbr / filler=0 / ip_ratio=1.40 / aq=1:0.80
Codec configuration box : avcC

Audio
ID : 2
Format : E-AC-3
Format/Info : Enhanced AC-3
Commercial name : Dolby Digital Plus
Codec ID : ec-3
Duration : 46 min 35 s
Bit rate mode : Constant
Bit rate : 640 kb/s
Channel(s) : 6 channels
Channel layout : L R C LFE Ls Rs
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Compression mode : Lossy
Stream size : 213 MiB (28%)
Language : Polish
Service kind : Complete Main
Default : Yes
Alternate group : 1

The files play well on my desktop/laptop computer (linux/mpv). They also work well when I stream them from RPI to my phone using the Kore app and VLC as a player.

What could be wrong with the video?

**chewitt** · April 4, 2024 at 2:01 PM

Can you upload/share a sample file somewhere?

If you disable hardware decoding, does the file play normally?

morfik · April 5, 2024 at 4:28 PM

Here's the example movie.

Quote from chewitt

If you disable hardware decoding, does the file play normally?

I try to test that later.

morfik · April 5, 2024 at 4:59 PM

It looks like that disabling "Allow hardware acceleration with DRM PRIME" fixed the issue. Is there any explanation for it? I mean, why all other videos work just fine with this option turned on, except for the aforementioned tv series?

**chewitt** · April 7, 2024 at 10:16 AM

Code

2024-04-07 13:05:18.389 T:1107    debug <general>: OnPlayBackStarted: CApplication::OnPlayBackStarted
...
2024-04-07 13:05:29.383 T:1473    debug <general>: CPtsTracker: pattern lost on diff 83389.000000, number of losses 1
...
2024-04-07 13:07:28.544 T:1473    debug <general>: CPtsTracker: detected pattern of length 1: 41708.24, frameduration: 41708.333333

It might be odd timestamps in the file. I see ^ logged which matches the "couple of minutes" theory. The file plays fine here on RPi5, but that's because RPi5 doesn't hardware decode H264 media (so it's the same workaround as disabling DRMPRIME).

popcornmix HiassofT might be able to explain more. I don't have an RPi4 around in current location.

**popcornmix** · April 8, 2024 at 1:42 PM

I can reproduce - I've asked our codec guy to take a look.

**popcornmix** · April 11, 2024 at 11:45 AM

We've had a look. The unusual feature of the file is the SPS/PPS headers initially report the aspect ratio, then at ~2mins stop reporting it. While that is not illegal, it is strange and it triggers a bug in the firmware processing (it repeatedly reports "aspect ratio has changed", but as there is no aspect ratio to update to, that condition never stops).

I've had a go at fixing firmware. The guy show needs to sign off on this is on holiday, but you could test it from here.

Extract start4x.elf and fixup4x.dat and replace the files start.elf and fixup.dat on the first partition of your sdcard.

(Keep a copy of the original versions just in case).

morfik · April 11, 2024 at 1:52 PM

I can confirm that the fix works well.

**popcornmix** · April 19, 2024 at 11:45 AM

The firmware fix is in rpi-update firmware. It should be picked up by LE in the near future.

**HiassofT** · April 19, 2024 at 12:17 PM

The fix is in our latest nightly build: https://test.libreelec.tv/12.0/RPi/RPi4/…-dd2ecfa.img.gz

morfikcould you please test it?

so long,

Hias

morfik · April 19, 2024 at 6:48 PM

I just tested. It looks like it works well.