diff mbox

vdr xine-lib eac3

Message ID 201009290207.11408.jareguero@telefonica.net
State New
Headers

Commit Message

Jose Alberto Reguero Sept. 29, 2010, 12:07 a.m. UTC 
  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

Comments

dplu Sept. 29, 2010, 1:04 p.m. UTC | #1 
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
Karim AFIFI Sept. 29, 2010, 7:50 p.m. UTC | #2 
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
Jose Alberto Reguero Sept. 30, 2010, 6:10 p.m. UTC | #3 
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
dplu Sept. 30, 2010, 7:37 p.m. UTC | #4 
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
Karim AFIFI Sept. 30, 2010, 7:46 p.m. UTC | #5 
Jose,
Sorry, I was related the issue *before* your last patches. 
I will test them this week-end.

Regards.
Karim




-----Message d'origine-----
De : vdr-bounces@linuxtv.org [mailto:vdr-bounces@linuxtv.org] De la part de
Jose Alberto Reguero
Envoyé : jeudi 30 septembre 2010 20:11
À : VDR Mailing List
Objet : Re: [vdr] vdr xine-lib eac3


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
diff mbox

Patch

diff -ur xine-0.9.3/vdr172remux.c xine-0.9.3.new/vdr172remux.c
--- xine-0.9.3/vdr172remux.c	2009-04-12 13:52:32.000000000 +0200
+++ xine-0.9.3.new/vdr172remux.c	2010-09-29 01:58:34.798000003 +0200
@@ -1703,8 +1703,20 @@ 
 
   const uchar *Payload = Data + PesPayloadOffset;
   const int PayloadCount = Count - PesPayloadOffset;
+  bool ac3;
+  int framesize;
+  unsigned short size;
 
-  if (Data[3] == 0xBD && PayloadCount >= 9 && ((Payload[0] & 0xF0) == 0x80) && Payload[4] == 0x0B && Payload[5] == 0x77 && frameSizes[Payload[8]] > 0) {
+  if (PayloadCount < 10)
+     return -1;
+  ac3 = ((Payload[9] >> 3) & 0x1f) <= 10; 
+  if ( ac3)
+     framesize = frameSizes[Payload[8]];
+  else {
+     size = Payload[7] + Payload[6] * 256;
+     framesize = ((size & 0x07FF) + 1) << 1;
+  }
+  if (Data[3] == 0xBD && ((Payload[0] & 0xF0) == 0x80) && Payload[4] == 0x0B && Payload[5] == 0x77 && framesize > 0) {
      if (TrackIndex)
         *TrackIndex = Payload[0] - 0x80;
 
@@ -1860,6 +1872,7 @@ 
   int done = 6 + 3 + Data[8];
   int todo = Count - done;
   const uchar *data = Data + done;
+  unsigned short size;
 
   // look for 0x0B 0x77 <chk1> <chk2> <frameSize>
   while (todo > 0) {
@@ -1906,7 +1919,12 @@ 
                state++;
                continue;
           case get_length:
-               ac3todo = 2 * frameSizes[*data];
+               if (((*(data + 1) >> 3) & 0x1f) <= 10)
+                  ac3todo = 2 * frameSizes[*data];
+               else {
+                  size = chk2 + chk1 * 256;
+                  ac3todo = ((size & 0x07FF) + 1) << 1;
+               }  
                // frameSizeCode was invalid => restart searching
                if (ac3todo <= 0) {
                   // reset PES header instead of using a wrong one
@@ -1971,6 +1989,10 @@ 
 
 int cDolbyRepacker::BreakAt(const uchar *Data, int Count)
 {
+  bool ac3;
+  int framesize;
+  unsigned short size;
+
   if (initiallySyncing)
      return -1; // fill the packet buffer completely until we have synced once
   // enough data for test?
@@ -1984,12 +2006,20 @@ 
   if (ac3todo > 0)
      return headerLen + ac3todo;
   // enough data for test?
-  if (Count < headerLen + 5)
+  if (Count < headerLen + 6)
      return -1;
   const uchar *data = Data + headerLen;
   // break after ac3 frame?
-  if (data[0] == 0x0B && data[1] == 0x77 && frameSizes[data[4]] > 0)
-     return headerLen + 2 * frameSizes[data[4]];
+  ac3 = ((data[5] >> 3) & 0x1f) <= 10; 
+  if ( ac3)
+     framesize = 2 * frameSizes[data[4]];
+  else {
+     size = data[3] + data[2] * 256;
+     framesize = ((size & 0x07FF) + 1) << 1;
+  }
+ if (data[0] == 0x0B && data[1] == 0x77 && framesize > 0)
+     return headerLen + framesize;
+
   return -1;
 }