From: Jose A. R. <jar...@te...> - 2012-06-18 15:24:40
Attachments:
ff_audio_decoder.diff
|
This patch fix audio problems whith ffmpeg EAC3 audio. Jose Alberto |
From: Petri H. <phi...@us...> - 2012-07-18 19:34:17
|
On ma, 2012-06-18 at 17:24 +0200, Jose Alberto Reguero wrote: > This patch fix audio problems whith ffmpeg EAC3 audio. Maybe this could be fixed by enabling parser for EAC3 ? Parser is used to fix similar problems with MPEG and AAC audio (from ff_audio_decoder.c): /* Use parser for AAC LATM and MPEG. * Fixes: * - DVB streams where multiple AAC LATM frames are packed to single PES * - DVB streams where MPEG audio frames do not follow PES packet boundaries */ - Petri |
From: Chris R. <ran...@ya...> - 2012-07-18 21:49:24
|
Hmm, speaking of "fixing" audio problems, I recently tried to play one of my old MPEG-TS streams recorded from a local HD channel. This particular stream's audio config changes at a program boundary, and now the audio plays at "half speed". Xine logs the following message: [aac_latm @ 0x7f5c80018a80] audio config changed Cheers, Chris ________________________________ From: Petri Hintukainen <phi...@us...> To: Jose Alberto Reguero <jar...@te...> Cc: xin...@li... Sent: Wednesday, 18 July 2012, 13:07 Subject: Re: [xine-devel] Fix problem with EAC3 audio On ma, 2012-06-18 at 17:24 +0200, Jose Alberto Reguero wrote: > This patch fix audio problems whith ffmpeg EAC3 audio. Maybe this could be fixed by enabling parser for EAC3 ? Parser is used to fix similar problems with MPEG and AAC audio (from ff_audio_decoder.c): /* Use parser for AAC LATM and MPEG. * Fixes: * - DVB streams where multiple AAC LATM frames are packed to single PES * - DVB streams where MPEG audio frames do not follow PES packet boundaries */ - Petri ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ xine-devel mailing list xin...@li... https://lists.sourceforge.net/lists/listinfo/xine-devel |
From: Jose A. R. <jar...@te...> - 2012-07-20 23:58:07
|
On Miércoles, 18 de julio de 2012 15:07:46 Petri Hintukainen escribió: > On ma, 2012-06-18 at 17:24 +0200, Jose Alberto Reguero wrote: > > This patch fix audio problems whith ffmpeg EAC3 audio. > > Maybe this could be fixed by enabling parser for EAC3 ? > Parser is used to fix similar problems with MPEG and AAC audio > (from ff_audio_decoder.c): > /* Use parser for AAC LATM and MPEG. > * Fixes: > * - DVB streams where multiple AAC LATM frames are packed to single PES > * - DVB streams where MPEG audio frames do not follow PES packet > boundaries */ > > > - Petri I try with parser, but the problem persist. I think that ffmpeg eac3 only works with completes frames. Jose Alberto |
From: Jose A. R. <jar...@te...> - 2012-08-08 23:14:05
Attachments:
ff_audio_decoder_2.diff
|
On Sábado, 21 de julio de 2012 01:57:49 Jose Alberto Reguero escribió: > On Miércoles, 18 de julio de 2012 15:07:46 Petri Hintukainen escribió: > > On ma, 2012-06-18 at 17:24 +0200, Jose Alberto Reguero wrote: > > > This patch fix audio problems whith ffmpeg EAC3 audio. > > > > Maybe this could be fixed by enabling parser for EAC3 ? > > Parser is used to fix similar problems with MPEG and AAC audio > > > > (from ff_audio_decoder.c): > > /* Use parser for AAC LATM and MPEG. > > > > * Fixes: > > * - DVB streams where multiple AAC LATM frames are packed to single > > PES > > * - DVB streams where MPEG audio frames do not follow PES packet > > > > boundaries */ > > > > > > - Petri > > I try with parser, but the problem persist. I think that ffmpeg eac3 only > works with completes frames. > > Jose Alberto > It works with the patch attached. Jose Alberto |
From: Petri H. <phi...@us...> - 2012-08-14 18:47:49
|
On ke, 2012-07-18 at 14:49 -0700, Chris Rankin wrote: > Hmm, speaking of "fixing" audio problems, I recently tried to play one > of my old MPEG-TS streams recorded from a local HD channel. This > particular stream's audio config changes at a program boundary, and > now the audio plays at "half speed". Xine logs the following message: > [aac_latm @ 0x7f5c80018a80] audio config changed Are the values in codec context also changed (bits_per_sample, sample_rate or channels) ? If yes, maybe this could be fixed by re-opening audio output when parameters change ? - Petri |
From: Chris R. <ran...@ya...> - 2012-08-14 23:14:52
|
> Are the values in codec context also changed (bits_per_sample, > sample_rate or channels) ? If yes, maybe this could be fixed by > re-opening audio output when parameters change ? We know that ffmpeg notices the audio config has changed because it logs a message to tell us. And ffplay handles this change OK. More interesting is that it's only the number of audio channels that changes, from 2 to 6. The bits_per_sample and sample_rate remain constant at 16 and 48000 respectively. Cheers, Chris |
From: Chris R. <ran...@ya...> - 2012-08-15 08:04:47
|
----- Original Message ----- > If yes, maybe this could be fixed by re-opening audio output when parameters change ? I should mention that xine does indeed play the stream correctly if I start playback *after* the point where the number of audio channels increases from 2 to 6. However, I haven't yet found any *programmatic* way of getting FFMPEG to inform me that the audio config has changed. Without that, how could I possibly know when I would need to reopen the audio output? Cheers, Chris |
From: Petri H. <phi...@us...> - 2012-08-15 20:05:17
Attachments:
ffmpeg_codec_params_check.diff
|
On ke, 2012-08-15 at 01:04 -0700, Chris Rankin wrote: > ----- Original Message ----- > > If yes, maybe this could be fixed by re-opening audio output when parameters change ? > > > I should mention that xine does indeed play the stream correctly if I start playback *after* the > point where the number of audio channels increases from 2 to 6. However, I haven't yet found any > *programmatic* way of getting FFMPEG to inform me that the audio config has changed. Without that, > how could I possibly know when I would need to reopen the audio output? I was thinking something like this (completely untested). - Petri |
From: Chris R. <ran...@ya...> - 2012-08-15 23:53:30
|
Hi, Yes, that patch is definitely a step in the right direction. However, it looks as if ALSA isn't prepared to swap the stereo device for the down-mixed surround51 device as easily as that. Xine now complains that the audio device is unavailable when the audio switches to 6 channel mode. (No hardware sound mixing on this particular machine...) This looks like an old problem - the ALSA plugin already deliberately waits 0.8 seconds in a vain effort to avoid this! Cheers, Chris ----- Original Message ----- From: Petri Hintukainen <phi...@us...> To: Chris Rankin <ran...@ya...> Cc: "xin...@li..." <xin...@li...> Sent: Wednesday, 15 August 2012, 21:04 Subject: Re: [xine-devel] Fix problem with EAC3 audio On ke, 2012-08-15 at 01:04 -0700, Chris Rankin wrote: > ----- Original Message ----- > > If yes, maybe this could be fixed by re-opening audio output when parameters change ? > > > I should mention that xine does indeed play the stream correctly if I start playback *after* the > point where the number of audio channels increases from 2 to 6. However, I haven't yet found any > *programmatic* way of getting FFMPEG to inform me that the audio config has changed. Without that, > how could I possibly know when I would need to reopen the audio output? I was thinking something like this (completely untested). - Petri |
From: Chris R. <ran...@ya...> - 2012-08-18 22:50:05
|
From: Petri Hintukainen <phi...@us...> > I was thinking something like this (completely untested). And it works fine on my PC with the Audigy2 sound card (which supports hardware mixing). Cheers, Chris |
From: Chris R. <ran...@ya...> - 2012-08-21 21:46:09
|
Hi, I've managed to get xine to switch ALSA devices without increasing the "open" timeout in audio_out_alsa.c. Basically, the problem was that my "default" ALSA device was PulseAudio, which meant that I needed a PulseAudio 5.1 device too: pcm.51to21 { type route slave { pcm "plug:pulse" channels 3 } ttable.0.0 0.58 # These values probably all need tweaking... ttable.1.1 0.58 ttable.2.0 0.58 ttable.3.1 0.58 ttable.4.0 0.57 ttable.4.1 0.57 ttable.5.2 1 } And finally, in .xine/config: audio.device.alsa_front_device:default audio.device.alsa_surround51_device:51to21 So patching xineplug_decode_ff.so to reopen the audio device seems OK to me. Cheers, Chris |
From: Chris R. <ran...@ya...> - 2012-08-17 07:55:26
|
As I've already mentioned in other emails, xine + VDR + xineliboutput is currently *broken* for me, for other reasons. xine-ui receives neither picture nor sound, although I do sometimes (briefly) see some of the OSD before xine-ui closes the connection again. Fedora is using VDR 1.7.27, I believe. And I compiled xineliboutput myself from git. And since only the HD DVB-T2 channels broadcast 5.1 sound (occasionally), and I have not yet been able to watch an HD channel via VDR, I would suggest that it's too soon to be suggesting that the audio delay is no longer needed... Especially since my experiments with "speaker-test" suggest that it still is. To be clear: I have been seeing this problem with a stream that I captured to my hard drive last year. IIRC, xine stopped playing the audio completely when I originally captured it. Cheers, Chris ----- Original Message ----- From: Petri Hintukainen <phi...@us...> To: Chris Rankin <ran...@ya...> Cc: Sent: Friday, 17 August 2012, 7:22 Subject: Re: [xine-devel] Fix problem with EAC3 audio On ke, 2012-08-15 at 16:53 -0700, Chris Rankin wrote: > Hi, > > Yes, that patch is definitely a step in the right direction. However, it looks as > if ALSA isn't prepared to swap the stereo device for the down-mixed surround51 device > as easily as that. Xine now complains that the audio device is unavailable when the audio > switches to 6 channel mode. (No hardware sound mixing on this particular machine...) > This looks like an old problem - the ALSA plugin already deliberately waits 0.8 seconds > in a vain effort to avoid this! But changing channel configuration works when you switch DVB channels with vdr ? That would indicate the delay needs to be longer ? Example: you're watching this channel. Audio configuration changes and you get slow etc. audio. If you now change to another channel and back, you get working audio ? - Petri |