vdr xine-lib eac3

  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


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
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > vdr mailing list
> > > > > > > vdr@linuxtv.org
> > > > > > > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
> > > > >
> > > > > _______________________________________________
> > > > > vdr mailing list
> > > > > vdr@linuxtv.org
> > > > > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
> > > > >
> > > > >
> > > > > __________ Information provenant d'ESET Smart Security, version de
> > > > > la base des signatures de virus 5488 (20100929) __________
> > > > >
> > > > > Le message a été vérifié par ESET Smart Security.
> > > > >
> > > > > http://www.eset.com
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > vdr mailing list
> > > > > vdr@linuxtv.org
> > > > > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
> > > >
> > > > _______________________________________________
> > > > vdr mailing list
> > > > vdr@linuxtv.org
> > > > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
> > >
> > > _______________________________________________
> > > vdr mailing list
> > > vdr@linuxtv.org
> > > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>
> _______________________________________________
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
  

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
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > vdr mailing list
> > > > > > > > vdr@linuxtv.org
> > > > > > > > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
> > > > > >
> > > > > > _______________________________________________
> > > > > > vdr mailing list
> > > > > > vdr@linuxtv.org
> > > > > > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
> > > > > >
> > > > > >
> > > > > > __________ Information provenant d'ESET Smart Security, version
> > > > > > de la base des signatures de virus 5488 (20100929) __________
> > > > > >
> > > > > > Le message a été vérifié par ESET Smart Security.
> > > > > >
> > > > > > http://www.eset.com
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > vdr mailing list
> > > > > > vdr@linuxtv.org
> > > > > > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
> > > > >
> > > > > _______________________________________________
> > > > > vdr mailing list
> > > > > vdr@linuxtv.org
> > > > > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
> > > >
> > > > _______________________________________________
> > > > vdr mailing list
> > > > vdr@linuxtv.org
> > > > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
> >
> > _______________________________________________
> > vdr mailing list
> > vdr@linuxtv.org
> > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>
> _______________________________________________
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
  

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
> > > > > > > > > 
> > > > > > > > > _______________________________________________
> > > > > > > > > vdr mailing list
> > > > > > > > > vdr@linuxtv.org
> > > > > > > > > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
> > > > > > > 
> > > > > > > _______________________________________________
> > > > > > > vdr mailing list
> > > > > > > vdr@linuxtv.org
> > > > > > > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
> > > > > > > 
> > > > > > > 
> > > > > > > __________ Information provenant d'ESET Smart Security, version
> > > > > > > de la base des signatures de virus 5488 (20100929) __________
> > > > > > > 
> > > > > > > Le message a été vérifié par ESET Smart Security.
> > > > > > > 
> > > > > > > http://www.eset.com
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > _______________________________________________
> > > > > > > vdr mailing list
> > > > > > > vdr@linuxtv.org
> > > > > > > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
> > > > > > 
> > > > > > _______________________________________________
> > > > > > vdr mailing list
> > > > > > vdr@linuxtv.org
> > > > > > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
> > > > > 
> > > > > _______________________________________________
> > > > > vdr mailing list
> > > > > vdr@linuxtv.org
> > > > > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
> > > 
> > > _______________________________________________
> > > vdr mailing list
> > > vdr@linuxtv.org
> > > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
> > 
> > _______________________________________________
> > vdr mailing list
> > vdr@linuxtv.org
> > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
> 
> _______________________________________________
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
  

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
  

Playing with xine-ui and demux ts don't work well. You must play it with vdr-
xine.

Jose Alberto

El Sábado 02 Octubre 2010, dplu escribió:
> 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
> 
> _______________________________________________
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr