Audio Problems with Raspberry Pi 4 and MMAL (Full logs and demofile included)
#1
I posted this already on LibreELEC forums (https://forum.libreelec.tv/thread/20854-...s-streams/) but I guess it belongs better here.

I recently switched from an Intel NUC to a Raspberry Pi 4. In general it is working fine but with videos recorded with my Vu+ cable receiver I get distorted/broken sound. It also happens with Live TV streaming from that Vu+. My previous box (Intel Atom) was able to stream/play those videos without problems so I guess it is specific to RPi4 hardware decoding.

Also this problems only happens when MMAL hardware acceleration is enabled. When disabling MMAL then audio is ok.

I recorded a video here to show the problem (best to hear at the end of the video):
https://www.dropbox.com/s/e9ehjhl69n16fz...7.mp4?dl=0

The videos in question are TS-files using H.264 video with AC-3 sound. This is a short clip that shows the problem on my RPi 4:
https://www.dropbox.com/s/822v31wpjqpupxi/test_copy.ts?dl=1

I fiddled around with ffmpeg to find out what the problem is and found out that the problem disappears when reencoding video (also with H.264 (!)). When I reencode to H.264 video using this command:
ffmpeg -i "recorded_video.ts" -acodec copy -vcodec h264 -ss 00:00:00 -t 00:00:40 test_h264.ts
This is the result:
https://www.dropbox.com/s/ac36n10lbobzub...64.ts?dl=0

Then that video plays fine. So maybe it is somehow related to the encoded video that also affects audio playback?

Here is a Kodi debug log file from playing the problem video:
http://ix.io/236g
(The first file I was trying to play in the log "jaun.mkv" was a misclick. The file in question is "test_copy.ts")

Can anyone help? Thanks!
Reply
#2
Are you sure test_h264.ts that you uploaded here https://www.dropbox.com/s/822v31wpjqpupx...py.ts?dl=1 isn't a re-encode?  
Quote:Video
ID                                       : 256 (0x100)
Menu ID                                  : 1 (0x1)
Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format profile                           : [email protected]
Format settings                          : CABAC / 4 Ref Frames
Format settings, CABAC                   : Yes
Format settings, ReFrames                : 4 frames
Codec ID                                 : 27
Duration                                 : 38s 400ms
Bit rate                                 : 5 598 Kbps
Width                                    : 1 920 pixels
Height                                   : 1 080 pixels
Display aspect ratio                     : 16:9
Frame rate mode                          : Variable
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Scan type                                : Progressive
Stream size                              : 25.6 MiB (89%)
Writing library                          : x264 core 148 r2694 3b70645
Encoding settings                        : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / lookahead_threads=2 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=23.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00


The MediaInfo for it is quite odd - 1920x1080 variable frame rate progressive written with the x264 core encoder? That's quite unusual for a broadcaster like RTL to use over-the-air?

I'd expect 1920x1080 interlaced at 25frames/50fields per second - unless RTL are doing Freeview HD dynamic GOP switching between 1080i25 and 1080p25 encoder modes - and even then the x264 is an odd thing to see (unless they are using something like Open Broadcast Encoder to do their encoding)
Reply
#3
(2019-12-04, 12:11)noggin Wrote: Are you sure test_h264.ts that you uploaded here https://www.dropbox.com/s/822v31wpjqpupx...py.ts?dl=1 isn't a re-encode?  

The test_h264.ts is the reencoded file. But the link you quoted points to "test_copy.ts" which is a cut from the original TS file (done with "-acodec copy -vcodec copy"). I assume "vcodec copy" should not alter the points you mentioned.

Which command did you use to get the video info you posted?
Reply
#4
(2019-12-04, 12:55)devkid Wrote:
(2019-12-04, 12:11)noggin Wrote: Are you sure test_h264.ts that you uploaded here https://www.dropbox.com/s/822v31wpjqpupx...py.ts?dl=1 isn't a re-encode?  

The test_h264.ts is the reencoded file. But the link you quoted points to "test_copy.ts" which is a cut from the original TS file (done with "-acodec copy -vcodec copy"). I assume "vcodec copy" should not alter the points you mentioned.

Which command did you use to get the video info you posted?    

I used MediaInfo - for some reason the DropBox link gave me test_h264.ts - must be my fault. 

I'd use -c copy to preserve all streams in a transport stream I think, though I think ffmpeg will still remux the transport stream and renumber the Video and Audio PIDs.  To be honest - just cutting a transport stream file usually works as player software has to be able to cope with corrupt beginning and ends of streams?  The h.264 re-encode has done some very odd things though - so the more original stream is useful.

HOWEVER  - looking at the test_copy.ts
Quote:Video
ID                                       : 256 (0x100)
Menu ID                                  : 1 (0x1)
Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format profile                           : [email protected]
Format settings                          : CABAC / 4 Ref Frames
Format settings, CABAC                   : Yes
Format settings, ReFrames                : 4 frames
Format settings, GOP                     : M=4, N=32
Codec ID                                 : 27
Duration                                 : 38s 600ms
Bit rate                                 : 8 831 Kbps
Width                                    : 1 920 pixels
Height                                   : 1 080 pixels
Display aspect ratio                     : 16:9
Frame rate                               : 25.000 fps
Standard                                 : Component
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Scan type                                : Interlaced
Scan type, store method                  : Separated fields
Scan order                               : Top Field First
Bits/(Pixel*Frame)                       : 0.170
Stream size                              : 40.6 MiB (91%)
Color range                              : Limited
Color primaries                          : BT.709
Transfer characteristics                 : BT.709
Matrix coefficients                      : BT.709

That's a very old form of interlaced encoding - I've not seen 'Separated Fields' like that used with h.264/AVC since the very early days of 1080i25 Blu-ray releases and 2006 HD tests... Almost all interlaced h.264 encoding used now is MBAFF - not separated fields, as MBAFF is more efficient (it looks at both fields together rather than treating the two fields separately). Rockchip devices originally had major issues with separated field AVC/h.264 - I wonder if the Pi4 MMAL has similar issues - there isn't that much separate field stuff around these days to generate bug reports.  I supect that may be related to this.  (My first series Wallander Blu-rays are separate fields - if I get a chance over the weekend I'll see how they play on the 4B)

For comparison - BBC One HD DSat 1080i25 interlaced h.264/AVC looks like this - note the different interlaced encoding :
Quote:Video
ID                                       : 5100 (0x13EC)
Menu ID                                  : 8901 (0x22C5)
Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format profile                           : [email protected]
Format settings                          : CABAC / 4 Ref Frames
Format settings, CABAC                   : Yes
Format settings, ReFrames                : 4 frames
Codec ID                                 : 27
Duration                                 : 1h 59mn
Bit rate                                 : 6 730 Kbps
Width                                    : 1 920 pixels
Height                                   : 1 080 pixels
Display aspect ratio                     : 16:9
Frame rate                               : 25.000 fps
Standard                                 : Component
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Scan type                                : MBAFF
Scan type, store method                  : Interleaved fields
Scan order                               : Top Field First
Bits/(Pixel*Frame)                       : 0.130
Stream size                              : 5.64 GiB (92%)
Color range                              : Limited
Color primaries                          : BT.709
Transfer characteristics                 : BT.709
Matrix coefficients                      : BT.709
Reply
#5
Okay thanks, that's intereting. I did a plain cut without ffmpeg from the file so that should be as original as it can get ("test_cut.ts"):
https://www.dropbox.com/s/ac36n10lbobzub...64.ts?dl=0

Another interesting thing: I am using the analog audio output of the RPi4. I thought it didn't matter since some days ago I could swear I had the problem also using HDMI-Audio. Nevertheless today I cannot reproduce it anymore playing it over HDMI. So HDMI sound is fine (with passthrough disabled). I think it is strange since the Pi seems okay with decoding the audio in general and playing it via HDMI. But when playing it via analog output I get that distortion. Isn't that unexpected?

Any chance to get it fixed by Kodi? Would it be better to create an issue on GitHub?
Reply
#6
Try adding audio_pwm_mode=1 to config.txt. Not sure if RPi4 is also affected by that, but earlier RPis had issues with the advanced analog audio output (that's enabled by default in firmware since a while). See also here https://www.raspberrypi.org/forums/viewt...0#p1421259

so long,

Hias
Reply
#7
Thanks, "audio_pwm_mode=1" actually fixes it .... but I really feel the sound quality is much worse Sad I am not a Hifi guy and I usually do listen to audio books but it sounds really bad. Also when starting audio it produces quite loud "bang" sounds from the speakers. Thanks for the good hint but I am afraid it cannot stick to this Sad
Reply
 
Thread Rating:
  • 0 Vote(s) - 0 Average



Logout Mark Read Team Forum Stats Members Help
Audio Problems with Raspberry Pi 4 and MMAL (Full logs and demofile included)00