Arch Linux

dontbugme

Banned

Registered: 2011-11-04

Posts: 166

Website

[SEMI-SOLVED]Mplayer2/Smplayer + 96khz audio too fast

Hi, sorry if this problem has already been covered(I couldn't find it with the search function). I installed arch on my main Desktop PC a few days ago (been using arch for 2 years on my notebook). Since then, some media files with the following encoding:

Video
Resolution
1920 x 1080
Aspect ratio
1.7778
Format
avc1
Bitrate
0 kbps
Frames per second
23.976
Selected codec
ffh264

Initial Audio Stream
Format
MP4A
Bitrate
128 kbps
Rate
96000 Hz
Channels
2
Selected codec
ffaac

Audio Streams
#
Language
Name
ID
0
und
<empty>
0

Subtitles
#
Type
Language
Name
ID
0
SUB
und
<empty>
0

play too fast. It's like pressing the 2x/3x speed button on your remote, except the video runs in normal speed. The most likely culprit is the 96khz sampling rate. I checked through a few videos that ran fine, and none of them use a 96khz sampling rate.
I found a 3 or so years old bug report on some ubuntu forum with similar symptoms, but I can't use the workaround -> according to them, it's some bug with ffmpeg and aac 96khz files - uninstalling ffmpeg forces mplayer to use another aac decoder.
I can't apply this workaround, since ffmpeg is one of mplayers dependencies.
I initially thought that its a problem with pulseaudio, but the same symptoms manifest with alsa. I'm a bit at a loss right now.

Last edited by dontbugme (2012-06-04 22:10:01)

ZekeSulastin

Member

Registered: 2010-09-20

Posts: 266

Re: [SEMI-SOLVED]Mplayer2/Smplayer + 96khz audio too fast

You can try rebuilding mplayer without ffmpeg via the ABS and see if that helps?

dontbugme

Banned

Registered: 2011-11-04

Posts: 166

Website

Re: [SEMI-SOLVED]Mplayer2/Smplayer + 96khz audio too fast

Hoped you wouldn't say that. Don't have the time for that right now (yeah, except watching animu all the time ^_^). Well, yeah I could try that some time. As I've already said, I installed arch just a few days ago, and I spent the whole afternoon yesterday to compile a patched wine version, since Diablo 3 is a bit buggy without the patches. Downloading all the missing wine dependencies, when you just installed arch, is the horror ( so much stuff missing).
Suffice it to say, my desktop boots so much faster than with fedora, I can't believe it. It's booting even faster than win7 (and win7 boots pretty fast on my rig).
Update: For starters, I will test the files on my notebook.
Update2: Ok, its mplayer2. On my notebook was still mplayer installed and it worked with that; switched to mplayer2 to on my notebook .. same fast forward bug.
...
Ok, this is strange. It seems like mplayer2 wrongly reports the file to ffmpeg with a sampling rate of 96khz instead of 44.1khz. mplayer reports it as 44.1khz  (according to the media info in mplayer).
Update3: I kinda semi-fixed it. Don't know how they did it, but extracting the streams with mkvextract and merging them again with mkvmerge fixed the problem (the aac file worked on its own in mplayer2 as expected after extracting.... dafuq).
However this is possible that the only player having problems with this file was mplayer2.

Last edited by dontbugme (2012-06-03 21:52:33)

Tieren

Member

Registered: 2012-09-07

Posts: 1

Re: [SEMI-SOLVED]Mplayer2/Smplayer + 96khz audio too fast

tl;dr - Thanks for finding the fix, I think this is an issue with the group encoding, not mplayer2.

--

I was running into the same issue in Gentoo and an extract -> remerge cycle fixed it for me as well.

mkvinfo testfile.mkv :
...
|  + Audio track
|   + Sampling frequency: 44100
|   + Channels: 2
|   + Output sampling frequency: 96000
...

In mplayer:
AUDIO: 44100 Hz, 2 ch, s16le, 0.0 kbit/0.00% (ratio: 0->176400)

In mplayer2:
AUDIO: 96000 Hz, 2 ch, s16le, 128.0 kbit/4.17% (ratio: 16000->384000)

But after extracting and re-merging the audio:
|  + Audio track
|   + Sampling frequency: 44100
|   + Channels: 2
AUDIO: 44100 Hz, 2 ch, s16le, 0.0 kbit/0.00% (ratio: 0->176400)
AUDIO: 44100 Hz, 2 ch, s16le, 128.0 kbit/9.07% (ratio: 16000->176400)

The difference seems to be that mplayer is ignoring the output sampling frequency, which is possibly an invalid number. From some skimming through other bug reports about similar issues I'd guess whoever encoded these files did something incorrectly and the output sampling frequency should be double the sample frequency (so 88200 instead of 96000) for SBR AAC and the like. If I merge the audio back in with --aac-is-sbr 0 set, I get an output sampling frequency of 88200 and it plays at normal speed.

Edit - after --aac-is-sbr:
|  + Audio track
|   + Sampling frequency: 44100
|   + Channels: 2
|   + Output sampling frequency: 88200
AUDIO: 88200 Hz, 2 ch, s16le, 128.0 kbit/4.54% (ratio: 16000->352800)

Thanks!

Last edited by Tieren (2012-09-07 09:23:47)