Hi
I play with your sample , it has only one audio track and strictly no sound on it ...
So I decide to replace my recent xine-ui by the very latest here http://hg.debian.org/hg/xine-lib/xine-ui/
xine-lib is latest one with only your patch in mpeg-pes ffmpeg is the full latest git with absolutely no patch
the result is the same ..
So I destroy the /.xine/config file and I can open the ts file and play with audio track .. if I play too hard, I have the message saying :
-load_plugins: plugin vdpau_h264 will be used for video streamtype 4d. -Broken NAL, skip it. -ffmpeg_audio_dec: augmentation du buffer à 98304 pour éviter sa saturation. -load_plugins: plugin ffmpegaudio will be used for audio streamtype 41. -ffmpeg_audio_dec: trying to open null codec -audio_decoder: no plugin available to handle 'E-AC-3'
no more sound available ... so it's better
Back to vdr, I try to play with sound track and crash immediatly I remark that when crashing, and running xine-ui to reconnect to vdr playing my records, it has stop replay and fall back to live TV .. strange !!!
I was focusing on xine but on vdr log there is a message I didn't saw :
-SetPlayMode: 0 -SetPlayMode: 1 -SetPlayMode: 0 -SetPlayMode: 1 -SetDigitalAudioDevice: 1 -::write(2048) returned -1, error 32: Broken pipe -vdr-xine: Client disconnected! -SetPlayMode: 0 -SetPlayMode: 1 -SetDigitalAudioDevice: 0
I will report on our forum this event and ask my colleague to check also this part if they have time. In a short way does it means that vdr-xine ask xine-ui to break itself and stop replaying ?
For myself, I will break for one week hoping somebody will continue to test or find what can be wrong in our basis config
Thanks for your help and sorry to not have enough skills to debug or understand the source code
Best regards
Le Saturday 02 October 2010 12:54:07 Jose Alberto Reguero, vous avez écrit :
I use latsest xine-ui hg. The problem may be ffmpeg or xine-lib or xine-ui. Are you sure that you have the latest versions and no aditional patches? You can do hg diff o svn diff to see the changes you have in the repositories. Here is a sample: http://dl.free.fr/pByrnmYwZ
Jose Alberto
El Viernes 01 Octubre 2010, dplu escribió:
Hi
I continue to search why it fail ... with no luck, hope other people will have time to make test
basis test setup : vdr 1.7.15 extention patch + patch e-ac3 for vdr-xine xine-ui 0.99.6 latest git ffmpeg latest xine 1.2 with basic e-ac3 patch for only
From vdr : crash every time I change audio track as described previously
Second test Try opening the TS file from xine-ui directly, same behaviour
op mode :
At startup sound track is "0" (should be "fra"), play nice track -- display track "off" , no crash track ++ display "0" instead of "fra" , no crash track ++ display "qaa" , it's real name .. crash in couple of seconds
Here is the log with high verbosity http://pastebin.com/BvGKDk0v
Hope this help you, I underline in yellow some strange thing
By the way, if you have time, can you post a sample of recording made at home so we can also test your sample with our configuration
Many thanks for your help and have a nice week end
Best regards
Le Thursday 30 September 2010 22:51:34 dplu, vous avez écrit :
Here is the result of my colleague using vdr-sxfe verbose and changing the audio track
[9665] [demux_vdr] audio stream changed: 03410000 -> 03410001 Erreur de segmentation (=segfault error)
As you can see this is the same error , he use this patch
diff -r cb99a1abe986 src/combined/ffmpeg/ff_audio_decoder.c --- a/src/combined/ffmpeg/ff_audio_decoder.c Fri Apr 09 18:55:47 2010 +0200 +++ b/src/combined/ffmpeg/ff_audio_decoder.c Sat Apr 10 16:23:14 2010 +0200 @@ -219,6 +219,12 @@ this->context->extradata_size); break; }
- case BUF_AUDIO_EAC3:
- case BUF_AUDIO_A52:
- {
- this->context->request_channels = 2;
- break;
- }
default: xprintf(this->stream->xine, XINE_VERBOSITY_LOG, "ffmpeg_audio_dec: unknown header with buf type 0x%X\n", codec_type);
We continue to investigate
thanks for your help
Le Thursday 30 September 2010 22:40:34 dplu, vous avez écrit :
I will add this patch to my xine-lib and rebuild all
Here are two more samples to test given by colleague, I will also wait the answer from Karim Afifi to have comparative tests
http://dl.free.fr/mE6yTLPnx http://dl.free.fr/u2dWSU5R8
Other idea : may it comes from my xine-ui version ? did you use a fresh one from http://hg.debian.org/hg/xine-lib/xine-ui/
Many thanks for your help and have a nice evening
Le Thursday 30 September 2010 22:27:52 Jose Alberto Reguero, vous avez
écrit :
The error you report doesn't matter. It is because there is no case for EAC3. I have an additional patch to use only two channels, and I don't have this error. You can use the patch and comment the line: this->context->request_channels = 2; and then you don't have the error. I try with the sample you give to me. If you want you can give me another sample.
Jose Alberto
El Jueves 30 Septiembre 2010, dplu escribió:
Hi
In fact, I use a very recent ffmpeg (less than one month) and the very latest xine-lib 1.2 with no patch except yours
I found my error message in combined/ffmpeg/ff_audio_decoder.c
This is strange that you cannot reproduce as long we (my colleague + me) are able to have it every time and other user report this problem using xlo plugin + sxfe (on French DVB forum)
I can update my ffmpeg to the very latest release but not sure it will change something (ffplay or mplayer works fine)
Nobody else can test our sample please ?
Have a nive evening
Le Thursday 30 September 2010 20:10:54 Jose Alberto Reguero, vous avez
écrit :
> I can change eac3 audio channel without problem. Perhaps you > have additional patches that cause that. > > Jose Alberto > > El Miércoles 29 Septiembre 2010, Karim Afifi escribió: > > Hello, > > > > Just to confirm that I've the same crash that dplu is talking > > about, with xineliboutput here. It occurs : > > - **Every time** I try to change audio track on "HD e-ac3" > > channel. - Many time when I zap from "SD" to on "HD e-ac3" > > channel. - Many time when I zap from HD "e-ac3" to on HD > > "e-ac3" channel. - No problem when using "SD" and "HD no > > e-ac3" channels. > > > > Guys, many thanks for your job, I hope vdr will soon remain > > as stable on "HD e-ac3" that with "SD" and "HD non e-ac3" > > channels. > > > > > > Karim > > > > -----Message d'origine----- > > De : vdr-bounces@linuxtv.org [mailto:vdr-bounces@linuxtv.org] > > De la part de dplu > > Envoyé : mercredi 29 septembre 2010 15:05 > > À : VDR Mailing List > > Objet : Re: [vdr] vdr xine-lib eac3 > > > > > > Hi > > > > Thanks for the patch, works nice now. Did you try to change > > audio channel ? I > > have a strange error reported also by french colleague : > > > > ffmpeg_audio_dec: augmentation du buffer à 98304 pour éviter > > sa saturation. (translation) => Increasing buffer size to > > 98304 to prevent overflow ffmpeg_audio_dec: unknown header > > with buf type 0x3410000 > > > > and xine-ui crash ... error in xiTK > > > > It happen when switching from fra to qaa (both e-ac3) and > > also when switching > > from ac3 live channels (like Einfestival HD or ITV HD) to > > records having e-ac3 tracks. It is Ok when coming from a mpeg > > audio channel (SD broadcast) > > > > I don't know if it is a xine problem sending bad information > > to ffmpeg or a bug in ffmpeg ... changing audio track (with # > > key) do not crash mplayer when > > playing the TS file > > > > By the way, many thanks for your work ;o)) > > > > Best regards > > > > > > Le Wednesday 29 September 2010 02:07:11 Jose Alberto Reguero, > > vous avez > > > > écrit : > > > Here is a new version of the patch. Now it works with the > > > sample. There > > > > was > > > > > a bug in the last patch. > > > > > > Jose Alberto > > > > > > El Lunes 27 Septiembre 2010, dplu escribió: > > > > Thanks for the test, In fact I am not in covered area so > > > > I work with sample given by a colleague who live in good > > > > area on our forum > > > > > > > > The sample is very fresh and works perfectly with > > > > xineliboutput + vdr-sxfe with patch > > > > xineliboutputeac3_4.diff plus patch ff_audio_decoder to > > > > downmix 5.1 to 2.0 > > > > > > > > Maybe is there "something" in TS who is different from > > > > your country. It should be also interesting to have > > > > report from Italian users who experiment this audio > > > > encoding (not all are xbmc user I hope) > > > > > > > > Have a nice evening > > > > > > > > Best regards > > > > > > > > Le Monday 27 September 2010 22:42:06 Jose Alberto > > > > Reguero, vous avez > > > > écrit : > > > > > I try the sample and don't work. I look into it. But > > > > > you must try live tv or samples made with the patches, > > > > > to see if it work. I try here > > > > with > > > > > > > a channel whith eac3 with spectral extention and it > > > > > work well. > > > > > > > > > > Jose Alberto