Hi there, I am a long term user of mplayer, and my "custom" usage is to reencode audio streams to ac3 to feed my "old" amplifier. Since version 1.5, it seems that the audio chain having: -af lavcac3enc 1:x:y is broken as soon as the stream is not ac3 (it used to work with any stream pre-version 1.5). Here the errors popping out, for instance from an eac3 audio channel: [ac3_fixed @ 0x7f72fd553760]Specified sample format s16p is invalid or not supported Couldn't open codec ac3, br=448000. [libaf] Reinitialization did not work, audio filter 'lavcac3enc' returned error code -2 Error at audio filter chain pre-init! Same error reading from an audio channel in aac: [ac3_fixed @ 0x7fd154b53760]Specified sample format s16p is invalid or not supported Couldn't open codec ac3, br=448000. [libaf] Reinitialization did not work, audio filter 'lavcac3enc' returned error code -2 Error at audio filter chain pre-init! I am happy to give more information or test patches. PS: tested mpv (which also has the lavac3enc filter, and it works fine for those very same audio streams). Cheers, chris.
On 27 Mar 2023, at 17:37, eatdirt <eatdirt@protonmail.com> wrote:
Hi there, I am a long term user of mplayer, and my "custom" usage is to reencode audio streams to ac3 to feed my "old" amplifier.
Since version 1.5, it seems that the audio chain having:
-af lavcac3enc 1:x:y
is broken as soon as the stream is not ac3 (it used to work with any stream pre-version 1.5).
Here the errors popping out, for instance from an eac3 audio channel:
[ac3_fixed @ 0x7f72fd553760]Specified sample format s16p is invalid or not supported
Seems there was a FFmpeg change making the ac3 encoder only support 32-bit input. So the lavcac3enc code would need to be changed to take that instead of 16-bit inputs. It should not be hard, but might take a bit of time to do.
On 29 Mar 2023, at 12:51, Reimar Döffinger <Reimar.Doeffinger@gmx.de> wrote:
On 27 Mar 2023, at 17:37, eatdirt <eatdirt@protonmail.com> wrote:
Hi there, I am a long term user of mplayer, and my "custom" usage is to reencode audio streams to ac3 to feed my "old" amplifier.
Since version 1.5, it seems that the audio chain having:
-af lavcac3enc 1:x:y
is broken as soon as the stream is not ac3 (it used to work with any stream pre-version 1.5).
Here the errors popping out, for instance from an eac3 audio channel:
[ac3_fixed @ 0x7f72fd553760]Specified sample format s16p is invalid or not supported
Seems there was a FFmpeg change making the ac3 encoder only support 32-bit input. So the lavcac3enc code would need to be changed to take that instead of 16-bit inputs. It should not be hard, but might take a bit of time to do.
Unfortunately I can't test it, but I have a patch attached...
Woo! Thanks for looking at it. Ok, it segfaults in av_helpers now In gdb: Starting playback... Program received signal SIGFPE, Arithmetic exception. 0x0000555555744f2b in lavc_encode_audio (ctx=0x555555b78a40, src=0x555555d9f570, src_len=36864, dst=dst@entry=0x555555dbf528, dst_len=dst_len@entry=18432) at av_helpers.c:136 136 frame->nb_samples = src_len / ctx->channels / bps; (gdb) bt #0 0x0000555555744f2b in lavc_encode_audio (ctx=0x555555b78a40, src=0x555555d9f570, src_len=36864, dst=dst@entry=0x555555dbf528, dst_len=dst_len@entry=18432) at av_helpers.c:136 #1 0x0000555555745802 in play (af=<optimized out>, data=<optimized out>) at libaf/af_lavcac3enc.c:244 #2 0x000055555567f416 in af_play (s=<optimized out>, data=<optimized out>, data@entry=0x7fffffffc630) at libaf/af.c:584 #3 0x000055555569161b in filter_n_bytes (len=130944, sh=0x555555b8c020) at libmpcodecs/dec_audio.c:423 #4 mp_decode_audio (sh_audio=sh_audio@entry=0x555555b8c020, minlen=minlen@entry=96000) at libmpcodecs/dec_audio.c:493 #5 0x00005555555e3a4a in fill_audio_out_buffers () at mplayer.c:2164 #6 main (argc=<optimized out>, argv=<optimized out>) at mplayer.c:3777 On 29/03/2023 19:38, Reimar Döffinger wrote:
On 29 Mar 2023, at 12:51, Reimar Döffinger <Reimar.Doeffinger@gmx.de> wrote:
On 27 Mar 2023, at 17:37, eatdirt <eatdirt@protonmail.com> wrote:
Hi there, I am a long term user of mplayer, and my "custom" usage is to reencode audio streams to ac3 to feed my "old" amplifier.
Since version 1.5, it seems that the audio chain having:
-af lavcac3enc 1:x:y
is broken as soon as the stream is not ac3 (it used to work with any stream pre-version 1.5).
Here the errors popping out, for instance from an eac3 audio channel:
[ac3_fixed @ 0x7f72fd553760]Specified sample format s16p is invalid or not supported
Seems there was a FFmpeg change making the ac3 encoder only support 32-bit input. So the lavcac3enc code would need to be changed to take that instead of 16-bit inputs. It should not be hard, but might take a bit of time to do.
Unfortunately I can't test it, but I have a patch attached...
_______________________________________________ MPlayer-dev-eng mailing list MPlayer-dev-eng@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
On 29 Mar 2023, at 21:20, eatdirt <eatdirt@protonmail.com> wrote:
Woo! Thanks for looking at it.
Ok, it segfaults in av_helpers now
SIGFPE, division by 0 actually, not segfault. Obviously my testing was testing even less than I hoped. Maybe this one on top will help? I'll probably have to see if I can find a system where I can actually test this.
Indeed, that was a SIGFPE! That second patch on top on the first works, well done! Well, it "almost" works :) It seems to trigger a SIGSEGV when -lavdopts threads=n is set, but if this option is not set, the audio stream is well converted to ac3 with the proper number of channels! Sorry to have found that, it was on the chain of my default options. With -lavdopts threads=something Thread 1 "mplayer" received signal SIGSEGV, Segmentation fault. 0x00007ffff6352dbf in ff_ac3_validate_metadata () from /lib64/libavcodec.so.59 #0 0x00007ffff6352dbf in ff_ac3_validate_metadata () at /lib64/libavcodec.so.59 #1 0x00007ffff6354f62 in ff_ac3_fixed_encode_frame () at /lib64/libavcodec.so.59 #2 0x00007ffff64abcfa in encode_receive_packet_internal () at /lib64/libavcodec.so.59 #3 0x00007ffff64ac324 in avcodec_send_frame () at /lib64/libavcodec.so.59 #4 0x000055555574518d in lavc_encode_audio (ctx=0x555556701040, src=0x55555677a700, src_len=36864, dst=dst@entry=0x5555567746f8, dst_len=dst_len@entry=24576) at av_helpers.c:157 #5 0x0000555555745822 in play (af=<optimized out>, data=<optimized out>) at libaf/af_lavcac3enc.c:244 #6 0x000055555567f416 in af_play (s=<optimized out>, data=<optimized out>, data@entry=0x7fffffffc600) at libaf/af.c:584 #7 0x000055555569161b in filter_n_bytes (len=130944, sh=0x555555b80da0) at libmpcodecs/dec_audio.c:423 #8 mp_decode_audio (sh_audio=sh_audio@entry=0x555555b80da0, minlen=minlen@entry=96000) at libmpcodecs/dec_audio.c:493 #9 0x00005555555e3a4a in fill_audio_out_buffers () at mplayer.c:2164 #10 main (argc=<optimized out>, argv=<optimized out>) at mplayer.c:3777 On 30/03/2023 19:48, Reimar Döffinger wrote:
On 29 Mar 2023, at 21:20, eatdirt <eatdirt@protonmail.com> wrote:
Woo! Thanks for looking at it.
Ok, it segfaults in av_helpers now
SIGFPE, division by 0 actually, not segfault. Obviously my testing was testing even less than I hoped. Maybe this one on top will help? I'll probably have to see if I can find a system where I can actually test this.
_______________________________________________ MPlayer-dev-eng mailing list MPlayer-dev-eng@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
On 4 Apr 2023, at 22:09, eatdirt <eatdirt@protonmail.com> wrote:
Indeed, that was a SIGFPE!
That second patch on top on the first works, well done! Well, it "almost" works :)
It seems to trigger a SIGSEGV when -lavdopts threads=n is set, but if this option is not set, the audio stream is well converted to ac3 with the proper number of channels! Sorry to have found that, it was on the chain of my default options.
With -lavdopts threads=something
I don't really see how that would be related, it's for decoding and SHOULD not affect this part. Can you try to get debug symbols for your FFmpeg and run in valgrind?
Thread 1 "mplayer" received signal SIGSEGV, Segmentation fault. 0x00007ffff6352dbf in ff_ac3_validate_metadata () from /lib64/libavcodec.so.59
#0 0x00007ffff6352dbf in ff_ac3_validate_metadata () at /lib64/libavcodec.so.59 #1 0x00007ffff6354f62 in ff_ac3_fixed_encode_frame () at /lib64/libavcodec.so.59 #2 0x00007ffff64abcfa in encode_receive_packet_internal () at /lib64/libavcodec.so.59 #3 0x00007ffff64ac324 in avcodec_send_frame () at /lib64/libavcodec.so.59 #4 0x000055555574518d in lavc_encode_audio (ctx=0x555556701040, src=0x55555677a700, src_len=36864, dst=dst@entry=0x5555567746f8, dst_len=dst_len@entry=24576) at av_helpers.c:157 #5 0x0000555555745822 in play (af=<optimized out>, data=<optimized out>) at libaf/af_lavcac3enc.c:244 #6 0x000055555567f416 in af_play (s=<optimized out>, data=<optimized out>, data@entry=0x7fffffffc600) at libaf/af.c:584 #7 0x000055555569161b in filter_n_bytes (len=130944, sh=0x555555b80da0) at libmpcodecs/dec_audio.c:423 #8 mp_decode_audio (sh_audio=sh_audio@entry=0x555555b80da0, minlen=minlen@entry=96000) at libmpcodecs/dec_audio.c:493 #9 0x00005555555e3a4a in fill_audio_out_buffers () at mplayer.c:2164 #10 main (argc=<optimized out>, argv=<optimized out>) at mplayer.c:3777
I will, and also try to inquire the code. But, in the meanwhile, to confirm it is coming from the patches, I actually tested without, and no sigsegv in that case. I've also found another issue with the patches, tested with an eac3 stream, the ac3 output sound is actually slightly corrupted. There is a noise sounding like a "cricket" in the background of the actual sound track. The volume of that "cricket" is at about something like 5-10% of the track's volume, and seems to be louder when the audio is dominated by low frequencies. Cheers, Chris. On 05/04/2023 20:47, Reimar Döffinger wrote:
On 4 Apr 2023, at 22:09, eatdirt <eatdirt@protonmail.com> wrote:
Indeed, that was a SIGFPE!
That second patch on top on the first works, well done! Well, it "almost" works :)
It seems to trigger a SIGSEGV when -lavdopts threads=n is set, but if this option is not set, the audio stream is well converted to ac3 with the proper number of channels! Sorry to have found that, it was on the chain of my default options.
With -lavdopts threads=something
I don't really see how that would be related, it's for decoding and SHOULD not affect this part. Can you try to get debug symbols for your FFmpeg and run in valgrind?
Thread 1 "mplayer" received signal SIGSEGV, Segmentation fault. 0x00007ffff6352dbf in ff_ac3_validate_metadata () from /lib64/libavcodec.so.59
#0 0x00007ffff6352dbf in ff_ac3_validate_metadata () at /lib64/libavcodec.so.59 #1 0x00007ffff6354f62 in ff_ac3_fixed_encode_frame () at /lib64/libavcodec.so.59 #2 0x00007ffff64abcfa in encode_receive_packet_internal () at /lib64/libavcodec.so.59 #3 0x00007ffff64ac324 in avcodec_send_frame () at /lib64/libavcodec.so.59 #4 0x000055555574518d in lavc_encode_audio (ctx=0x555556701040, src=0x55555677a700, src_len=36864, dst=dst@entry=0x5555567746f8, dst_len=dst_len@entry=24576) at av_helpers.c:157 #5 0x0000555555745822 in play (af=<optimized out>, data=<optimized out>) at libaf/af_lavcac3enc.c:244 #6 0x000055555567f416 in af_play (s=<optimized out>, data=<optimized out>, data@entry=0x7fffffffc600) at libaf/af.c:584 #7 0x000055555569161b in filter_n_bytes (len=130944, sh=0x555555b80da0) at libmpcodecs/dec_audio.c:423 #8 mp_decode_audio (sh_audio=sh_audio@entry=0x555555b80da0, minlen=minlen@entry=96000) at libmpcodecs/dec_audio.c:493 #9 0x00005555555e3a4a in fill_audio_out_buffers () at mplayer.c:2164 #10 main (argc=<optimized out>, argv=<optimized out>) at mplayer.c:3777
participants (2)
-
eatdirt -
Reimar Döffinger