hello
your second patch doesn't work : no sound on eac3 channel
if you want there is a sample of vdr hd-eac3 recording here:
http://dl.free.fr/ew4rJddM8 103mo
else , i don't know what mailing-list is the more indicate for debuging
the vdr or xine-dev mailing-list ?
Hi
I have made previous test with the version release by Petri Hintukainen
And I notice this part is not working like it should
- if((m->descriptor_tag == STREAM_AUDIO_AC3) || /* ac3 - raw */ + if(m->descriptor_tag == HDMV_AUDIO_84_EAC3) { + m->content = p; + m->size = packet_len; + m->type |= BUF_AUDIO_EAC3; + return 1; + + } else if((m->descriptor_tag == STREAM_AUDIO_AC3) || /* ac3 - raw */
unfortunaletly, in AC3 or E-AC3 , the descriptor tag is STREAM_AUDIO_AC3, so the program never run the first if (installed a debug printf here)
It seems that your first approach (at least what I understood) by forcing the decoding of all AC-3 stream by ffmepg instead of internal lib was nice but generate violent segfault on libavcodec
Hope this help you
Best regards
PS : Sorry to pollute the vdr mailing list (not subscribed to ffmpeg or xine-lib....)
Le Wednesday 24 March 2010 18:41:14 zaverel, vous avez écrit :
hello
your second patch doesn't work : no sound on eac3 channel
if you want there is a sample of vdr hd-eac3 recording here:
http://dl.free.fr/ew4rJddM8 103mo
else , i don't know what mailing-list is the more indicate for debuging
the vdr or xine-dev mailing-list ?
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
It works here with a old sample of tdt with eac3. Have you patch also remux.c? You need to change in line 533:
case SI::AC3DescriptorTag: +case SI:EnhancedAC3DescriptorTag:
and in line 191:
-Target[i++] = SI::AC3DescriptorTag; +Target[i++] = SI::EnhancedAC3DescriptorTag
Jose Alberto
El Miércoles, 24 de Marzo de 2010, dplu escribió:
Hi
I have made previous test with the version release by Petri Hintukainen
And I notice this part is not working like it should
- if((m->descriptor_tag == STREAM_AUDIO_AC3) || /* ac3 - raw */
- if(m->descriptor_tag == HDMV_AUDIO_84_EAC3) {
m->content = p;m->size = packet_len;m->type |= BUF_AUDIO_EAC3;return 1;- } else if((m->descriptor_tag == STREAM_AUDIO_AC3) || /* ac3 - raw
*/
unfortunaletly, in AC3 or E-AC3 , the descriptor tag is STREAM_AUDIO_AC3, so the program never run the first if (installed a debug printf here)
It seems that your first approach (at least what I understood) by forcing the decoding of all AC-3 stream by ffmepg instead of internal lib was nice but generate violent segfault on libavcodec
Hope this help you
Best regards
PS : Sorry to pollute the vdr mailing list (not subscribed to ffmpeg or xine-lib....)
Le Wednesday 24 March 2010 18:41:14 zaverel, vous avez écrit :
hello
your second patch doesn't work : no sound on eac3 channel
if you want there is a sample of vdr hd-eac3 recording here:
103mo
else , i don't know what mailing-list is the more indicate for debuging
the vdr or xine-dev mailing-list ?
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
Ok I do not have this line, I better understand now, the type ID in file was not correct so system don't know how to route it ...
int cPatPmtGenerator::MakeAC3Descriptor(uchar *Target) { int i = 0; Target[i++] = SI::AC3DescriptorTag; Target[i++] = 0x01; // length Target[i++] = 0x00; IncEsInfoLength(i); return i; }
Of course, the question is now : what about real and normal ac3 stream like in German SD/HD channels ? (Sat1 /prosieben) are they "transtyped" to e-ac3 also ?
I am not able to recompile now, but will try this week end or one of my colleague will try earlier if available
Thanks for your help
Best regards
Le Wednesday 24 March 2010 19:41:43 Jose Alberto Reguero, vous avez écrit :
It works here with a old sample of tdt with eac3. Have you patch also remux.c? You need to change in line 533:
case SI::AC3DescriptorTag: +case SI:EnhancedAC3DescriptorTag:
and in line 191:
-Target[i++] = SI::AC3DescriptorTag; +Target[i++] = SI::EnhancedAC3DescriptorTag
Jose Alberto
El Miércoles, 24 de Marzo de 2010, dplu escribió:
Hi
I have made previous test with the version release by Petri Hintukainen
And I notice this part is not working like it should
- if((m->descriptor_tag == STREAM_AUDIO_AC3) || /* ac3 - raw */
- if(m->descriptor_tag == HDMV_AUDIO_84_EAC3) {
m->content = p;m->size = packet_len;m->type |= BUF_AUDIO_EAC3;return 1;- } else if((m->descriptor_tag == STREAM_AUDIO_AC3) || /* ac3 - raw
*/
unfortunaletly, in AC3 or E-AC3 , the descriptor tag is STREAM_AUDIO_AC3, so the program never run the first if (installed a debug printf here)
It seems that your first approach (at least what I understood) by forcing the decoding of all AC-3 stream by ffmepg instead of internal lib was nice but generate violent segfault on libavcodec
Hope this help you
Best regards
PS : Sorry to pollute the vdr mailing list (not subscribed to ffmpeg or xine-lib....)
Le Wednesday 24 March 2010 18:41:14 zaverel, vous avez écrit :
hello
your second patch doesn't work : no sound on eac3 channel
if you want there is a sample of vdr hd-eac3 recording here:
103mo
else , i don't know what mailing-list is the more indicate for debuging
the vdr or xine-dev mailing-list ?
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 've patched pat.c and now remux.c and with use xine-lib-1.2 with your second patch (who has typo error) and that doesn't work.
corrected remux.c
line 533 case SI::AC3DescriptorTag: +case SI::EnhancedAC3DescriptorTag:
and in line 191:
-Target[i++] = SI::AC3DescriptorTag; +Target[i++] = SI::EnhancedAC3DescriptorTag;
with your previously patch and just pat.c patched with line 402
case SI::AC3DescriptorTag: +case SI:EnhancedAC3DescriptorTag:
that worked but not stable.
Is your sample eac3 has |"Spectral extension" ? because in france dvb-t with eac3 has it and need a ffmpeg patched for that. And i test with that sound. |
Le 24/03/2010 19:41, Jose Alberto Reguero a écrit :
It works here with a old sample of tdt with eac3. Have you patch also remux.c? You need to change in line 533:
case SI::AC3DescriptorTag: +case SI:EnhancedAC3DescriptorTag:
and in line 191:
-Target[i++] = SI::AC3DescriptorTag; +Target[i++] = SI::EnhancedAC3DescriptorTag
Jose Alberto
El Miércoles, 24 de Marzo de 2010, dplu escribió:
Hi
I have made previous test with the version release by Petri Hintukainen
And I notice this part is not working like it should
- if((m->descriptor_tag == STREAM_AUDIO_AC3) || /* ac3 - raw */
- if(m->descriptor_tag == HDMV_AUDIO_84_EAC3) {
m->content = p;m->size = packet_len;m->type |= BUF_AUDIO_EAC3;return 1;- } else if((m->descriptor_tag == STREAM_AUDIO_AC3) || /* ac3 - raw
*/
unfortunaletly, in AC3 or E-AC3 , the descriptor tag is STREAM_AUDIO_AC3, so the program never run the first if (installed a debug printf here)
It seems that your first approach (at least what I understood) by forcing the decoding of all AC-3 stream by ffmepg instead of internal lib was nice but generate violent segfault on libavcodec
Hope this help you
Best regards
PS : Sorry to pollute the vdr mailing list (not subscribed to ffmpeg or xine-lib....)
Le Wednesday 24 March 2010 18:41:14 zaverel, vous avez écrit :
hello
your second patch doesn't work : no sound on eac3 channel
if you want there is a sample of vdr hd-eac3 recording here:
103mo
else , i don't know what mailing-list is the more indicate for debuging
the vdr or xine-dev mailing-list ?
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 attached a second version of the first patch. I make the same changes that in the second patch, but maintaining the logic of the first patch. Also I commented the line: +// this->context->request_channels = 2; because your example has 5 channels. If you have trouble with that you can comment the line again. Which typo error has the second patch?
Jose Alberto
El Miércoles, 24 de Marzo de 2010, zaverel escribió:
i 've patched pat.c and now remux.c and with use xine-lib-1.2 with your second patch (who has typo error) and that doesn't work.
corrected remux.c
line 533 case SI::AC3DescriptorTag: +case SI::EnhancedAC3DescriptorTag:
and in line 191:
-Target[i++] = SI::AC3DescriptorTag; +Target[i++] = SI::EnhancedAC3DescriptorTag;
with your previously patch and just pat.c patched with line 402
case SI::AC3DescriptorTag: +case SI:EnhancedAC3DescriptorTag:
that worked but not stable.
Is your sample eac3 has |"Spectral extension" ? because in france dvb-t with eac3 has it and need a ffmpeg patched for that. And i test with that sound.
Le 24/03/2010 19:41, Jose Alberto Reguero a écrit :
It works here with a old sample of tdt with eac3. Have you patch also remux.c? You need to change in line 533:
case SI::AC3DescriptorTag: +case SI:EnhancedAC3DescriptorTag:
and in line 191:
-Target[i++] = SI::AC3DescriptorTag; +Target[i++] = SI::EnhancedAC3DescriptorTag
Jose Alberto
El Miércoles, 24 de Marzo de 2010, dplu escribió:
Hi
I have made previous test with the version release by Petri Hintukainen
And I notice this part is not working like it should
- if((m->descriptor_tag == STREAM_AUDIO_AC3) || /* ac3 - raw */
- if(m->descriptor_tag == HDMV_AUDIO_84_EAC3) {
m->content = p;m->size = packet_len;m->type |= BUF_AUDIO_EAC3;return 1;- } else if((m->descriptor_tag == STREAM_AUDIO_AC3) || /* ac3 -
raw */
unfortunaletly, in AC3 or E-AC3 , the descriptor tag is STREAM_AUDIO_AC3, so the program never run the first if (installed a debug printf here)
It seems that your first approach (at least what I understood) by forcing the decoding of all AC-3 stream by ffmepg instead of internal lib was nice but generate violent segfault on libavcodec
Hope this help you
Best regards
PS : Sorry to pollute the vdr mailing list (not subscribed to ffmpeg or xine-lib....)
Le Wednesday 24 March 2010 18:41:14 zaverel, vous avez écrit :
hello
your second patch doesn't work : no sound on eac3 channel
if you want there is a sample of vdr hd-eac3 recording here:
103mo
else , i don't know what mailing-list is the more indicate for debuging
the vdr or xine-dev mailing-list ?
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
The typo was on remux.c => lost : and ;
Anyway xine-lib has been updated and your patch don't apply.
Update is for eac3 with mkv
i don't test it yet
corrected remux.c
line 533 case SI::AC3DescriptorTag: +case SI::EnhancedAC3DescriptorTag:
and in line 191:
-Target[i++] = SI::AC3DescriptorTag; +Target[i++] = SI::EnhancedAC3DescriptorTag;
Le 24/03/2010 22:58, Jose Alberto Reguero a écrit :
I attached a second version of the first patch. I make the same changes that in the second patch, but maintaining the logic of the first patch. Also I commented the line: +// this->context->request_channels = 2; because your example has 5 channels. If you have trouble with that you can comment the line again. Which typo error has the second patch?
Jose Alberto
El Miércoles, 24 de Marzo de 2010, zaverel escribió:
i 've patched pat.c and now remux.c and with use xine-lib-1.2 with your second patch (who has typo error) and that doesn't work.
corrected remux.c
line 533 case SI::AC3DescriptorTag: +case SI::EnhancedAC3DescriptorTag:
and in line 191:
-Target[i++] = SI::AC3DescriptorTag; +Target[i++] = SI::EnhancedAC3DescriptorTag;
with your previously patch and just pat.c patched with line 402
case SI::AC3DescriptorTag: +case SI:EnhancedAC3DescriptorTag:
that worked but not stable.
Is your sample eac3 has |"Spectral extension" ? because in france dvb-t with eac3 has it and need a ffmpeg patched for that. And i test with that sound.
Le 24/03/2010 19:41, Jose Alberto Reguero a écrit :
It works here with a old sample of tdt with eac3. Have you patch also remux.c? You need to change in line 533:
case SI::AC3DescriptorTag: +case SI:EnhancedAC3DescriptorTag:
and in line 191:
-Target[i++] = SI::AC3DescriptorTag; +Target[i++] = SI::EnhancedAC3DescriptorTag
Jose Alberto
El Miércoles, 24 de Marzo de 2010, dplu escribió:
Hi
I have made previous test with the version release by Petri Hintukainen
And I notice this part is not working like it should
- if((m->descriptor_tag == STREAM_AUDIO_AC3) || /* ac3 - raw */
- if(m->descriptor_tag == HDMV_AUDIO_84_EAC3) {
m->content = p;m->size = packet_len;m->type |= BUF_AUDIO_EAC3;return 1;- } else if((m->descriptor_tag == STREAM_AUDIO_AC3) || /* ac3 -
raw */
unfortunaletly, in AC3 or E-AC3 , the descriptor tag is STREAM_AUDIO_AC3, so the program never run the first if (installed a debug printf here)
It seems that your first approach (at least what I understood) by forcing the decoding of all AC-3 stream by ffmepg instead of internal lib was nice but generate violent segfault on libavcodec
Hope this help you
Best regards
PS : Sorry to pollute the vdr mailing list (not subscribed to ffmpeg or xine-lib....)
Le Wednesday 24 March 2010 18:41:14 zaverel, vous avez écrit :
hello
your second patch doesn't work : no sound on eac3 channel
if you want there is a sample of vdr hd-eac3 recording here:
103mo
else , i don't know what mailing-list is the more indicate for debuging
the vdr or xine-dev mailing-list ?
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
Patch against latest xine-lib-1.2. New patch for xineliboutput. Now must work if you patch remux.c. You must have the latest xine-lib and xineliboutput. Yesterday both have changes about eac3.
Jose Alberto
El Jueves, 25 de Marzo de 2010, zaverel escribió:
The typo was on remux.c => lost : and ;
Anyway xine-lib has been updated and your patch don't apply.
Update is for eac3 with mkv
i don't test it yet
corrected remux.c
line 533 case SI::AC3DescriptorTag: +case SI::EnhancedAC3DescriptorTag:
and in line 191:
-Target[i++] = SI::AC3DescriptorTag; +Target[i++] = SI::EnhancedAC3DescriptorTag;
Le 24/03/2010 22:58, Jose Alberto Reguero a écrit :
I attached a second version of the first patch. I make the same changes that in the second patch, but maintaining the logic of the first patch. Also I commented the line: +// this->context->request_channels = 2; because your example has 5 channels. If you have trouble with that you can comment the line again. Which typo error has the second patch?
Jose Alberto
El Miércoles, 24 de Marzo de 2010, zaverel escribió:
i 've patched pat.c and now remux.c and with use xine-lib-1.2 with your second patch (who has typo error) and that doesn't work.
corrected remux.c
line 533 case SI::AC3DescriptorTag: +case SI::EnhancedAC3DescriptorTag:
and in line 191:
-Target[i++] = SI::AC3DescriptorTag; +Target[i++] = SI::EnhancedAC3DescriptorTag;
with your previously patch and just pat.c patched with line 402
case SI::AC3DescriptorTag: +case SI:EnhancedAC3DescriptorTag:
that worked but not stable.
Is your sample eac3 has |"Spectral extension" ? because in france dvb-t with eac3 has it and need a ffmpeg patched for that. And i test with that sound.
Le 24/03/2010 19:41, Jose Alberto Reguero a écrit :
It works here with a old sample of tdt with eac3. Have you patch also remux.c? You need to change in line 533:
case SI::AC3DescriptorTag: +case SI:EnhancedAC3DescriptorTag:
and in line 191:
-Target[i++] = SI::AC3DescriptorTag; +Target[i++] = SI::EnhancedAC3DescriptorTag
Jose Alberto
El Miércoles, 24 de Marzo de 2010, dplu escribió:
Hi
I have made previous test with the version release by Petri Hintukainen
And I notice this part is not working like it should
- if((m->descriptor_tag == STREAM_AUDIO_AC3) || /* ac3 - raw */
- if(m->descriptor_tag == HDMV_AUDIO_84_EAC3) {
m->content = p;m->size = packet_len;m->type |= BUF_AUDIO_EAC3;return 1;- } else if((m->descriptor_tag == STREAM_AUDIO_AC3) || /* ac3 -
raw */
unfortunaletly, in AC3 or E-AC3 , the descriptor tag is STREAM_AUDIO_AC3, so the program never run the first if (installed a debug printf here)
It seems that your first approach (at least what I understood) by forcing the decoding of all AC-3 stream by ffmepg instead of internal lib was nice but generate violent segfault on libavcodec
Hope this help you
Best regards
PS : Sorry to pollute the vdr mailing list (not subscribed to ffmpeg or xine-lib....)
Le Wednesday 24 March 2010 18:41:14 zaverel, vous avez écrit :
hello
your second patch doesn't work : no sound on eac3 channel
if you want there is a sample of vdr hd-eac3 recording here:
103mo
else , i don't know what mailing-list is the more indicate for debuging
the vdr or xine-dev mailing-list ?
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
Patch for xine-lib that don't need to patch remux.c to work.
Jose Alberto
El Jueves, 25 de Marzo de 2010, Jose Alberto Reguero escribió:
Patch against latest xine-lib-1.2. New patch for xineliboutput. Now must work if you patch remux.c. You must have the latest xine-lib and xineliboutput. Yesterday both have changes about eac3.
Jose Alberto
El Jueves, 25 de Marzo de 2010, zaverel escribió:
The typo was on remux.c => lost : and ;
Anyway xine-lib has been updated and your patch don't apply.
Update is for eac3 with mkv
i don't test it yet
corrected remux.c
line 533 case SI::AC3DescriptorTag: +case SI::EnhancedAC3DescriptorTag:
and in line 191:
-Target[i++] = SI::AC3DescriptorTag; +Target[i++] = SI::EnhancedAC3DescriptorTag;
Le 24/03/2010 22:58, Jose Alberto Reguero a écrit :
I attached a second version of the first patch. I make the same changes that in the second patch, but maintaining the logic of the first patch. Also I commented the line: +// this->context->request_channels = 2; because your example has 5 channels. If you have trouble with that you can comment the line again. Which typo error has the second patch?
Jose Alberto
El Miércoles, 24 de Marzo de 2010, zaverel escribió:
i 've patched pat.c and now remux.c and with use xine-lib-1.2 with your second patch (who has typo error) and that doesn't work.
corrected remux.c
line 533 case SI::AC3DescriptorTag: +case SI::EnhancedAC3DescriptorTag:
and in line 191:
-Target[i++] = SI::AC3DescriptorTag; +Target[i++] = SI::EnhancedAC3DescriptorTag;
with your previously patch and just pat.c patched with line 402
case SI::AC3DescriptorTag: +case SI:EnhancedAC3DescriptorTag:
that worked but not stable.
Is your sample eac3 has |"Spectral extension" ? because in france dvb-t with eac3 has it and need a ffmpeg patched for that. And i test with that sound.
Le 24/03/2010 19:41, Jose Alberto Reguero a écrit :
It works here with a old sample of tdt with eac3. Have you patch also remux.c? You need to change in line 533:
case SI::AC3DescriptorTag: +case SI:EnhancedAC3DescriptorTag:
and in line 191:
-Target[i++] = SI::AC3DescriptorTag; +Target[i++] = SI::EnhancedAC3DescriptorTag
Jose Alberto
El Miércoles, 24 de Marzo de 2010, dplu escribió:
Hi
I have made previous test with the version release by Petri Hintukainen
And I notice this part is not working like it should
- if((m->descriptor_tag == STREAM_AUDIO_AC3) || /* ac3 - raw
*/ + if(m->descriptor_tag == HDMV_AUDIO_84_EAC3) {
m->content = p;m->size = packet_len;m->type |= BUF_AUDIO_EAC3;return 1;- } else if((m->descriptor_tag == STREAM_AUDIO_AC3) || /* ac3
- raw */
unfortunaletly, in AC3 or E-AC3 , the descriptor tag is STREAM_AUDIO_AC3, so the program never run the first if (installed a debug printf here)
It seems that your first approach (at least what I understood) by forcing the decoding of all AC-3 stream by ffmepg instead of internal lib was nice but generate violent segfault on libavcodec
Hope this help you
Best regards
PS : Sorry to pollute the vdr mailing list (not subscribed to ffmpeg or xine-lib....)
Le Wednesday 24 March 2010 18:41:14 zaverel, vous avez écrit : > hello > > your second patch doesn't work : no sound on eac3 channel > > if you want there is a sample of vdr hd-eac3 recording here: > > http://dl.free.fr/ew4rJddM8 > > 103mo > > else , i don't know what mailing-list is the more indicate for > debuging > > the vdr or xine-dev mailing-list ? > > _______________________________________________ > 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
Yes ! that work just with your last patch xine-eac3_5.diff and without had to patch xineliboutput.
i do my last test with vdr-1.7.14 and patch pat.c
line 402
case SI::AC3DescriptorTag: +case SI:EnhancedAC3DescriptorTag:
just don't forget to activate "dolby digital" in vdr settings
Thank you for your work.
now remains to see if it's stable
Le 25/03/2010 16:08, Jose Alberto Reguero a écrit :
Patch for xine-lib that don't need to patch remux.c to work.
Jose Alberto
El Jueves, 25 de Marzo de 2010, Jose Alberto Reguero escribió:
Patch against latest xine-lib-1.2. New patch for xineliboutput. Now must work if you patch remux.c. You must have the latest xine-lib and xineliboutput. Yesterday both have changes about eac3.
Jose Alberto
El Jueves, 25 de Marzo de 2010, zaverel escribió:
The typo was on remux.c => lost : and ;
Anyway xine-lib has been updated and your patch don't apply.
Update is for eac3 with mkv
i don't test it yet
corrected remux.c
line 533 case SI::AC3DescriptorTag: +case SI::EnhancedAC3DescriptorTag:
and in line 191:
-Target[i++] = SI::AC3DescriptorTag; +Target[i++] = SI::EnhancedAC3DescriptorTag;
Le 24/03/2010 22:58, Jose Alberto Reguero a écrit :
I attached a second version of the first patch. I make the same changes that in the second patch, but maintaining the logic of the first patch. Also I commented the line: +// this->context->request_channels = 2; because your example has 5 channels. If you have trouble with that you can comment the line again. Which typo error has the second patch?
Jose Alberto
El Miércoles, 24 de Marzo de 2010, zaverel escribió:
i 've patched pat.c and now remux.c and with use xine-lib-1.2 with your second patch (who has typo error) and that doesn't work.
corrected remux.c
line 533 case SI::AC3DescriptorTag: +case SI::EnhancedAC3DescriptorTag:
and in line 191:
-Target[i++] = SI::AC3DescriptorTag; +Target[i++] = SI::EnhancedAC3DescriptorTag;
with your previously patch and just pat.c patched with line 402
case SI::AC3DescriptorTag: +case SI:EnhancedAC3DescriptorTag:
that worked but not stable.
Is your sample eac3 has |"Spectral extension" ? because in france dvb-t with eac3 has it and need a ffmpeg patched for that. And i test with that sound.
Le 24/03/2010 19:41, Jose Alberto Reguero a écrit :
It works here with a old sample of tdt with eac3. Have you patch also remux.c? You need to change in line 533:
case SI::AC3DescriptorTag: +case SI:EnhancedAC3DescriptorTag:
and in line 191:
-Target[i++] = SI::AC3DescriptorTag; +Target[i++] = SI::EnhancedAC3DescriptorTag
Jose Alberto
El Miércoles, 24 de Marzo de 2010, dplu escribió:
> Hi > > I have made previous test with the version release by Petri > Hintukainen > > And I notice this part is not working like it should > > - if((m->descriptor_tag == STREAM_AUDIO_AC3) || /* ac3 - raw > */ + if(m->descriptor_tag == HDMV_AUDIO_84_EAC3) { > + m->content = p; > + m->size = packet_len; > + m->type |= BUF_AUDIO_EAC3; > + return 1; > + > + } else if((m->descriptor_tag == STREAM_AUDIO_AC3) || /* ac3 > - raw */ > > unfortunaletly, in AC3 or E-AC3 , the descriptor tag is > STREAM_AUDIO_AC3, so the program never run the first if (installed a > debug printf here) > > It seems that your first approach (at least what I understood) by > forcing the decoding of all AC-3 stream by ffmepg instead of > internal lib was nice but generate violent segfault on libavcodec > > Hope this help you > > Best regards > > PS : Sorry to pollute the vdr mailing list (not subscribed to ffmpeg > or xine-lib....) > > Le Wednesday 24 March 2010 18:41:14 zaverel, vous avez écrit : > >> hello >> >> your second patch doesn't work : no sound on eac3 channel >> >> if you want there is a sample of vdr hd-eac3 recording here: >> >> http://dl.free.fr/ew4rJddM8 >> >> 103mo >> >> else , i don't know what mailing-list is the more indicate for >> debuging >> >> the vdr or xine-dev mailing-list ? >> >> _______________________________________________ >> 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
After some test there are some issue: ramdom crash at start up or without sound. But the real probleme i think is with 5.0 sound.
In the sample the 2.0 audio out is good but the 5.0 has low volume and metallic sound
just try xine fra piste 5.0 ffmpeg_audio_dec: unknown header with buf type 0x3000000
qaa 2.0 is good
ffmpeg -i 00001.ts ... Input #0, mpegts, from '00001.ts': Duration: 00:02:10.51, start: 10461.634989, bitrate: 6905 kb/s Program 132 Stream #0.0[0x78]: Video: h264, yuv420p, 1440x1080 [PAR 4:3 DAR 16:9], 50 fps, 50 tbr, 90k tbn, 50 tbc Stream #0.1[0x82](fra): Audio: eac3, 48000 Hz, 5.0, s16, 256 kb/s Stream #0.2[0x83](qaa): Audio: eac3, 48000 Hz, stereo, s16, 128 kb/s Stream #0.3[0x8c](fra): Subtitle: dvbsub Stream #0.4[0x8d](fra): Subtitle: dvbsub
Le 25/03/2010 16:08, Jose Alberto Reguero a écrit :
Patch for xine-lib that don't need to patch remux.c to work.
Jose Alberto
El Jueves, 25 de Marzo de 2010, Jose Alberto Reguero escribió:
Patch against latest xine-lib-1.2. New patch for xineliboutput. Now must work if you patch remux.c. You must have the latest xine-lib and xineliboutput. Yesterday both have changes about eac3.
Jose Alberto
El Jueves, 25 de Marzo de 2010, zaverel escribió:
The typo was on remux.c => lost : and ;
Anyway xine-lib has been updated and your patch don't apply.
Update is for eac3 with mkv
i don't test it yet
corrected remux.c
line 533 case SI::AC3DescriptorTag: +case SI::EnhancedAC3DescriptorTag:
and in line 191:
-Target[i++] = SI::AC3DescriptorTag; +Target[i++] = SI::EnhancedAC3DescriptorTag;
Le 24/03/2010 22:58, Jose Alberto Reguero a écrit :
I attached a second version of the first patch. I make the same changes that in the second patch, but maintaining the logic of the first patch. Also I commented the line: +// this->context->request_channels = 2; because your example has 5 channels. If you have trouble with that you can comment the line again. Which typo error has the second patch?
Jose Alberto
El Miércoles, 24 de Marzo de 2010, zaverel escribió:
i 've patched pat.c and now remux.c and with use xine-lib-1.2 with your second patch (who has typo error) and that doesn't work.
corrected remux.c
line 533 case SI::AC3DescriptorTag: +case SI::EnhancedAC3DescriptorTag:
and in line 191:
-Target[i++] = SI::AC3DescriptorTag; +Target[i++] = SI::EnhancedAC3DescriptorTag;
with your previously patch and just pat.c patched with line 402
case SI::AC3DescriptorTag: +case SI:EnhancedAC3DescriptorTag:
that worked but not stable.
Is your sample eac3 has |"Spectral extension" ? because in france dvb-t with eac3 has it and need a ffmpeg patched for that. And i test with that sound.
Le 24/03/2010 19:41, Jose Alberto Reguero a écrit :
It works here with a old sample of tdt with eac3. Have you patch also remux.c? You need to change in line 533:
case SI::AC3DescriptorTag: +case SI:EnhancedAC3DescriptorTag:
and in line 191:
-Target[i++] = SI::AC3DescriptorTag; +Target[i++] = SI::EnhancedAC3DescriptorTag
Jose Alberto
El Miércoles, 24 de Marzo de 2010, dplu escribió:
> Hi > > I have made previous test with the version release by Petri > Hintukainen > > And I notice this part is not working like it should > > - if((m->descriptor_tag == STREAM_AUDIO_AC3) || /* ac3 - raw > */ + if(m->descriptor_tag == HDMV_AUDIO_84_EAC3) { > + m->content = p; > + m->size = packet_len; > + m->type |= BUF_AUDIO_EAC3; > + return 1; > + > + } else if((m->descriptor_tag == STREAM_AUDIO_AC3) || /* ac3 > - raw */ > > unfortunaletly, in AC3 or E-AC3 , the descriptor tag is > STREAM_AUDIO_AC3, so the program never run the first if (installed a > debug printf here) > > It seems that your first approach (at least what I understood) by > forcing the decoding of all AC-3 stream by ffmepg instead of > internal lib was nice but generate violent segfault on libavcodec > > Hope this help you > > Best regards > > PS : Sorry to pollute the vdr mailing list (not subscribed to ffmpeg > or xine-lib....) > > Le Wednesday 24 March 2010 18:41:14 zaverel, vous avez écrit : > >> hello >> >> your second patch doesn't work : no sound on eac3 channel >> >> if you want there is a sample of vdr hd-eac3 recording here: >> >> http://dl.free.fr/ew4rJddM8 >> >> 103mo >> >> else , i don't know what mailing-list is the more indicate for >> debuging >> >> the vdr or xine-dev mailing-list ? >> >> _______________________________________________ >> 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
You can add the line:
this->context->request_channels = 2;
in line 247 and 295.
Then you have stereo sound.
Joae Alberto
El Viernes, 26 de Marzo de 2010, zaverel escribió:
After some test there are some issue: ramdom crash at start up or without sound. But the real probleme i think is with 5.0 sound.
In the sample the 2.0 audio out is good but the 5.0 has low volume and metallic sound
just try xine fra piste 5.0 ffmpeg_audio_dec: unknown header with buf type 0x3000000
qaa 2.0 is good
ffmpeg -i 00001.ts ... Input #0, mpegts, from '00001.ts': Duration: 00:02:10.51, start: 10461.634989, bitrate: 6905 kb/s Program 132 Stream #0.0[0x78]: Video: h264, yuv420p, 1440x1080 [PAR 4:3 DAR 16:9], 50 fps, 50 tbr, 90k tbn, 50 tbc Stream #0.1[0x82](fra): Audio: eac3, 48000 Hz, 5.0, s16, 256 kb/s Stream #0.2[0x83](qaa): Audio: eac3, 48000 Hz, stereo, s16, 128 kb/s Stream #0.3[0x8c](fra): Subtitle: dvbsub Stream #0.4[0x8d](fra): Subtitle: dvbsub
Le 25/03/2010 16:08, Jose Alberto Reguero a écrit :
Patch for xine-lib that don't need to patch remux.c to work.
Jose Alberto
El Jueves, 25 de Marzo de 2010, Jose Alberto Reguero escribió:
Patch against latest xine-lib-1.2. New patch for xineliboutput. Now must work if you patch remux.c. You must have the latest xine-lib and xineliboutput. Yesterday both have changes about eac3.
Jose Alberto
El Jueves, 25 de Marzo de 2010, zaverel escribió:
The typo was on remux.c => lost : and ;
Anyway xine-lib has been updated and your patch don't apply.
Update is for eac3 with mkv
i don't test it yet
corrected remux.c
line 533 case SI::AC3DescriptorTag: +case SI::EnhancedAC3DescriptorTag:
and in line 191:
-Target[i++] = SI::AC3DescriptorTag; +Target[i++] = SI::EnhancedAC3DescriptorTag;
Le 24/03/2010 22:58, Jose Alberto Reguero a écrit :
I attached a second version of the first patch. I make the same changes that in the second patch, but maintaining the logic of the first patch. Also I commented the line: +// this->context->request_channels = 2; because your example has 5 channels. If you have trouble with that you can comment the line again. Which typo error has the second patch?
Jose Alberto
El Miércoles, 24 de Marzo de 2010, zaverel escribió:
i 've patched pat.c and now remux.c and with use xine-lib-1.2 with your second patch (who has typo error) and that doesn't work.
corrected remux.c
line 533 case SI::AC3DescriptorTag: +case SI::EnhancedAC3DescriptorTag:
and in line 191:
-Target[i++] = SI::AC3DescriptorTag; +Target[i++] = SI::EnhancedAC3DescriptorTag;
with your previously patch and just pat.c patched with line 402
case SI::AC3DescriptorTag: +case SI:EnhancedAC3DescriptorTag:
that worked but not stable.
Is your sample eac3 has |"Spectral extension" ? because in france dvb-t with eac3 has it and need a ffmpeg patched for that. And i test with that sound.
Le 24/03/2010 19:41, Jose Alberto Reguero a écrit : > It works here with a old sample of tdt with eac3. Have you patch > also remux.c? You need to change in line 533: > > case SI::AC3DescriptorTag: > +case SI:EnhancedAC3DescriptorTag: > > and in line 191: > > -Target[i++] = SI::AC3DescriptorTag; > +Target[i++] = SI::EnhancedAC3DescriptorTag > > Jose Alberto > > El Miércoles, 24 de Marzo de 2010, dplu escribió: >> Hi >> >> I have made previous test with the version release by Petri >> Hintukainen >> >> And I notice this part is not working like it should >> >> - if((m->descriptor_tag == STREAM_AUDIO_AC3) || /* ac3 - raw >> */ + if(m->descriptor_tag == HDMV_AUDIO_84_EAC3) { >> + m->content = p; >> + m->size = packet_len; >> + m->type |= BUF_AUDIO_EAC3; >> + return 1; >> + >> + } else if((m->descriptor_tag == STREAM_AUDIO_AC3) || /* ac3 >> - raw */ >> >> unfortunaletly, in AC3 or E-AC3 , the descriptor tag is >> STREAM_AUDIO_AC3, so the program never run the first if (installed >> a debug printf here) >> >> It seems that your first approach (at least what I understood) by >> forcing the decoding of all AC-3 stream by ffmepg instead of >> internal lib was nice but generate violent segfault on libavcodec >> >> Hope this help you >> >> Best regards >> >> PS : Sorry to pollute the vdr mailing list (not subscribed to >> ffmpeg or xine-lib....) >> >> Le Wednesday 24 March 2010 18:41:14 zaverel, vous avez écrit : >>> hello >>> >>> your second patch doesn't work : no sound on eac3 channel >>> >>> if you want there is a sample of vdr hd-eac3 recording here: >>> >>> http://dl.free.fr/ew4rJddM8 >>> >>> 103mo >>> >>> else , i don't know what mailing-list is the more indicate for >>> debuging >>> >>> the vdr or xine-dev mailing-list ? >>> >>> _______________________________________________ >>> 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
Is ff_audio_decoder.c to patch ? I try but that change nothing.
Le 26/03/2010 13:12, Jose Alberto Reguero a écrit :
You can add the line:
this->context->request_channels = 2;
in line 247 and 295.
Then you have stereo sound.
Joae Alberto
El Viernes, 26 de Marzo de 2010, zaverel escribió:
After some test there are some issue: ramdom crash at start up or without sound. But the real probleme i think is with 5.0 sound.
In the sample the 2.0 audio out is good but the 5.0 has low volume and metallic sound
just try xine fra piste 5.0 ffmpeg_audio_dec: unknown header with buf type 0x3000000
qaa 2.0 is good
ffmpeg -i 00001.ts ... Input #0, mpegts, from '00001.ts': Duration: 00:02:10.51, start: 10461.634989, bitrate: 6905 kb/s Program 132 Stream #0.0[0x78]: Video: h264, yuv420p, 1440x1080 [PAR 4:3 DAR 16:9], 50 fps, 50 tbr, 90k tbn, 50 tbc Stream #0.1[0x82](fra): Audio: eac3, 48000 Hz, 5.0, s16, 256 kb/s Stream #0.2[0x83](qaa): Audio: eac3, 48000 Hz, stereo, s16, 128 kb/s Stream #0.3[0x8c](fra): Subtitle: dvbsub Stream #0.4[0x8d](fra): Subtitle: dvbsub
Le 25/03/2010 16:08, Jose Alberto Reguero a écrit :
Patch for xine-lib that don't need to patch remux.c to work.
Jose Alberto
El Jueves, 25 de Marzo de 2010, Jose Alberto Reguero escribió:
Patch against latest xine-lib-1.2. New patch for xineliboutput. Now must work if you patch remux.c. You must have the latest xine-lib and xineliboutput. Yesterday both have changes about eac3.
Jose Alberto
El Jueves, 25 de Marzo de 2010, zaverel escribió:
The typo was on remux.c => lost : and ;
Anyway xine-lib has been updated and your patch don't apply.
Update is for eac3 with mkv
i don't test it yet
corrected remux.c
line 533 case SI::AC3DescriptorTag: +case SI::EnhancedAC3DescriptorTag:
and in line 191:
-Target[i++] = SI::AC3DescriptorTag; +Target[i++] = SI::EnhancedAC3DescriptorTag;
Le 24/03/2010 22:58, Jose Alberto Reguero a écrit :
I attached a second version of the first patch. I make the same changes that in the second patch, but maintaining the logic of the first patch. Also I commented the line: +// this->context->request_channels = 2; because your example has 5 channels. If you have trouble with that you can comment the line again. Which typo error has the second patch?
Jose Alberto
El Miércoles, 24 de Marzo de 2010, zaverel escribió:
> i 've patched pat.c and now remux.c > and with use xine-lib-1.2 with your second patch (who has typo error) > and that doesn't work. > > corrected remux.c > > line 533 > case SI::AC3DescriptorTag: > +case SI::EnhancedAC3DescriptorTag: > > > and in line 191: > > -Target[i++] = SI::AC3DescriptorTag; > +Target[i++] = SI::EnhancedAC3DescriptorTag; > > > > with your previously patch and just pat.c patched with > line 402 > > case SI::AC3DescriptorTag: > +case SI:EnhancedAC3DescriptorTag: > > that worked but not stable. > > Is your sample eac3 has |"Spectral extension" ? > because in france dvb-t with eac3 has it > and need a ffmpeg patched for that. > And i test with that sound. > > Le 24/03/2010 19:41, Jose Alberto Reguero a écrit : > >> It works here with a old sample of tdt with eac3. Have you patch >> also remux.c? You need to change in line 533: >> >> case SI::AC3DescriptorTag: >> +case SI:EnhancedAC3DescriptorTag: >> >> and in line 191: >> >> -Target[i++] = SI::AC3DescriptorTag; >> +Target[i++] = SI::EnhancedAC3DescriptorTag >> >> Jose Alberto >> >> El Miércoles, 24 de Marzo de 2010, dplu escribió: >> >>> Hi >>> >>> I have made previous test with the version release by Petri >>> Hintukainen >>> >>> And I notice this part is not working like it should >>> >>> - if((m->descriptor_tag == STREAM_AUDIO_AC3) || /* ac3 - raw >>> */ + if(m->descriptor_tag == HDMV_AUDIO_84_EAC3) { >>> + m->content = p; >>> + m->size = packet_len; >>> + m->type |= BUF_AUDIO_EAC3; >>> + return 1; >>> + >>> + } else if((m->descriptor_tag == STREAM_AUDIO_AC3) || /* ac3 >>> - raw */ >>> >>> unfortunaletly, in AC3 or E-AC3 , the descriptor tag is >>> STREAM_AUDIO_AC3, so the program never run the first if (installed >>> a debug printf here) >>> >>> It seems that your first approach (at least what I understood) by >>> forcing the decoding of all AC-3 stream by ffmepg instead of >>> internal lib was nice but generate violent segfault on libavcodec >>> >>> Hope this help you >>> >>> Best regards >>> >>> PS : Sorry to pollute the vdr mailing list (not subscribed to >>> ffmpeg or xine-lib....) >>> >>> Le Wednesday 24 March 2010 18:41:14 zaverel, vous avez écrit : >>> >>>> hello >>>> >>>> your second patch doesn't work : no sound on eac3 channel >>>> >>>> if you want there is a sample of vdr hd-eac3 recording here: >>>> >>>> http://dl.free.fr/ew4rJddM8 >>>> >>>> 103mo >>>> >>>> else , i don't know what mailing-list is the more indicate for >>>> debuging >>>> >>>> the vdr or xine-dev mailing-list ? >>>> >>>> _______________________________________________ >>>> 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
Yes, the file is ff_audio_decoder.c You must put the line this->context->request_channels = 2; after this->context->codec_tag = _x_stream_info_get(this->stream, XINE_STREAM_INFO_AUDIO_FOURCC);
Jose Alberto
El Sábado, 27 de Marzo de 2010, zaverel escribió:
Is ff_audio_decoder.c to patch ? I try but that change nothing.
Le 26/03/2010 13:12, Jose Alberto Reguero a écrit :
You can add the line:
this->context->request_channels = 2;
in line 247 and 295.
Then you have stereo sound.
Joae Alberto
El Viernes, 26 de Marzo de 2010, zaverel escribió:
After some test there are some issue: ramdom crash at start up or without sound. But the real probleme i think is with 5.0 sound.
In the sample the 2.0 audio out is good but the 5.0 has low volume and metallic sound
just try xine fra piste 5.0 ffmpeg_audio_dec: unknown header with buf type 0x3000000
qaa 2.0 is good
ffmpeg -i 00001.ts ...
Input #0, mpegts, from '00001.ts': Duration: 00:02:10.51, start: 10461.634989, bitrate: 6905 kb/s Program 132
Stream #0.0[0x78]: Video: h264, yuv420p, 1440x1080 [PAR 4:3 DAR16:9], 50 fps, 50 tbr, 90k tbn, 50 tbc
Stream #0.1[0x82](fra): Audio: eac3, 48000 Hz, 5.0, s16, 256 kb/s Stream #0.2[0x83](qaa): Audio: eac3, 48000 Hz, stereo, s16, 128 kb/s Stream #0.3[0x8c](fra): Subtitle: dvbsub Stream #0.4[0x8d](fra): Subtitle: dvbsubLe 25/03/2010 16:08, Jose Alberto Reguero a écrit :
Patch for xine-lib that don't need to patch remux.c to work.
Jose Alberto
El Jueves, 25 de Marzo de 2010, Jose Alberto Reguero escribió:
Patch against latest xine-lib-1.2. New patch for xineliboutput. Now must work if you patch remux.c. You must have the latest xine-lib and xineliboutput. Yesterday both have changes about eac3.
Jose Alberto
El Jueves, 25 de Marzo de 2010, zaverel escribió:
The typo was on remux.c => lost : and ;
Anyway xine-lib has been updated and your patch don't apply.
Update is for eac3 with mkv
i don't test it yet
corrected remux.c
line 533 case SI::AC3DescriptorTag: +case SI::EnhancedAC3DescriptorTag:
and in line 191:
-Target[i++] = SI::AC3DescriptorTag; +Target[i++] = SI::EnhancedAC3DescriptorTag;
Le 24/03/2010 22:58, Jose Alberto Reguero a écrit : > I attached a second version of the first patch. > I make the same changes that in the second patch, but maintaining > the logic of the first patch. Also I commented the line: > +// this->context->request_channels = 2; > because your example has 5 channels. If you have trouble with that > you can comment the line again. > Which typo error has the second patch? > > Jose Alberto > > El Miércoles, 24 de Marzo de 2010, zaverel escribió: >> i 've patched pat.c and now remux.c >> and with use xine-lib-1.2 with your second patch (who has typo >> error) and that doesn't work. >> >> corrected remux.c >> >> line 533 >> case SI::AC3DescriptorTag: >> +case SI::EnhancedAC3DescriptorTag: >> >> >> and in line 191: >> >> -Target[i++] = SI::AC3DescriptorTag; >> +Target[i++] = SI::EnhancedAC3DescriptorTag; >> >> >> >> with your previously patch and just pat.c patched with >> line 402 >> >> case SI::AC3DescriptorTag: >> +case SI:EnhancedAC3DescriptorTag: >> >> that worked but not stable. >> >> Is your sample eac3 has |"Spectral extension" ? >> because in france dvb-t with eac3 has it >> and need a ffmpeg patched for that. >> And i test with that sound. >> >> Le 24/03/2010 19:41, Jose Alberto Reguero a écrit : >>> It works here with a old sample of tdt with eac3. Have you patch >>> also remux.c? You need to change in line 533: >>> >>> case SI::AC3DescriptorTag: >>> +case SI:EnhancedAC3DescriptorTag: >>> >>> and in line 191: >>> >>> -Target[i++] = SI::AC3DescriptorTag; >>> +Target[i++] = SI::EnhancedAC3DescriptorTag >>> >>> Jose Alberto >>> >>> El Miércoles, 24 de Marzo de 2010, dplu escribió: >>>> Hi >>>> >>>> I have made previous test with the version release by Petri >>>> Hintukainen >>>> >>>> And I notice this part is not working like it should >>>> >>>> - if((m->descriptor_tag == STREAM_AUDIO_AC3) || /* ac3 - >>>> raw */ + if(m->descriptor_tag == HDMV_AUDIO_84_EAC3) { >>>> + m->content = p; >>>> + m->size = packet_len; >>>> + m->type |= BUF_AUDIO_EAC3; >>>> + return 1; >>>> + >>>> + } else if((m->descriptor_tag == STREAM_AUDIO_AC3) || /* >>>> ac3 - raw */ >>>> >>>> unfortunaletly, in AC3 or E-AC3 , the descriptor tag is >>>> STREAM_AUDIO_AC3, so the program never run the first if >>>> (installed a debug printf here) >>>> >>>> It seems that your first approach (at least what I understood) by >>>> forcing the decoding of all AC-3 stream by ffmepg instead of >>>> internal lib was nice but generate violent segfault on libavcodec >>>> >>>> Hope this help you >>>> >>>> Best regards >>>> >>>> PS : Sorry to pollute the vdr mailing list (not subscribed to >>>> ffmpeg or xine-lib....) >>>> >>>> Le Wednesday 24 March 2010 18:41:14 zaverel, vous avez écrit : >>>>> hello >>>>> >>>>> your second patch doesn't work : no sound on eac3 channel >>>>> >>>>> if you want there is a sample of vdr hd-eac3 recording here: >>>>> >>>>> http://dl.free.fr/ew4rJddM8 >>>>> >>>>> 103mo >>>>> >>>>> else , i don't know what mailing-list is the more indicate for >>>>> debuging >>>>> >>>>> the vdr or xine-dev mailing-list ? >>>>> >>>>> _______________________________________________ >>>>> 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
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
hello, i do that but no change. I try another thing: i convert the sample ts of vdr recording to mkv and rebuild xine-lib without your patch to test and it's the same: stereo is good but 5.0 is bad.
I think xine-lib eac3 only support stereo at this time.
see you.
Selon Jose Alberto Reguero jareguero@telefonica.net:
Yes, the file is ff_audio_decoder.c You must put the line this->context->request_channels = 2; after this->context->codec_tag = _x_stream_info_get(this->stream, XINE_STREAM_INFO_AUDIO_FOURCC);
Jose Alberto
El Sábado, 27 de Marzo de 2010, zaverel escribió:
Is ff_audio_decoder.c to patch ? I try but that change nothing.
Le 26/03/2010 13:12, Jose Alberto Reguero a écrit :
You can add the line:
this->context->request_channels = 2;
in line 247 and 295.
Then you have stereo sound.
Joae Alberto
El Viernes, 26 de Marzo de 2010, zaverel escribió:
After some test there are some issue: ramdom crash at start up or without sound. But the real probleme i think is with 5.0 sound.
In the sample the 2.0 audio out is good but the 5.0 has low volume and metallic sound
just try xine fra piste 5.0 ffmpeg_audio_dec: unknown header with buf type 0x3000000
qaa 2.0 is good
ffmpeg -i 00001.ts ...
Input #0, mpegts, from '00001.ts': Duration: 00:02:10.51, start: 10461.634989, bitrate: 6905 kb/s Program 132
Stream #0.0[0x78]: Video: h264, yuv420p, 1440x1080 [PAR 4:3 DAR16:9], 50 fps, 50 tbr, 90k tbn, 50 tbc
Stream #0.1[0x82](fra): Audio: eac3, 48000 Hz, 5.0, s16, 256 kb/s Stream #0.2[0x83](qaa): Audio: eac3, 48000 Hz, stereo, s16, 128 kb/s Stream #0.3[0x8c](fra): Subtitle: dvbsub Stream #0.4[0x8d](fra): Subtitle: dvbsubLe 25/03/2010 16:08, Jose Alberto Reguero a écrit :
Patch for xine-lib that don't need to patch remux.c to work.
Jose Alberto
El Jueves, 25 de Marzo de 2010, Jose Alberto Reguero escribió:
Patch against latest xine-lib-1.2. New patch for xineliboutput. Now must work if you patch remux.c. You must have the latest xine-lib and xineliboutput. Yesterday both have changes about eac3.
Jose Alberto
El Jueves, 25 de Marzo de 2010, zaverel escribió: > The typo was on remux.c => lost : and ; > > Anyway xine-lib has been updated and your patch don't apply. > > Update is for eac3 with mkv > > i don't test it yet > > > > corrected remux.c > > line 533 > case SI::AC3DescriptorTag: > +case SI::EnhancedAC3DescriptorTag: > > > and in line 191: > > -Target[i++] = SI::AC3DescriptorTag; > +Target[i++] = SI::EnhancedAC3DescriptorTag; > > Le 24/03/2010 22:58, Jose Alberto Reguero a écrit : >> I attached a second version of the first patch. >> I make the same changes that in the second patch, but maintaining >> the logic of the first patch. Also I commented the line: >> +// this->context->request_channels = 2; >> because your example has 5 channels. If you have trouble with that >> you can comment the line again. >> Which typo error has the second patch? >> >> Jose Alberto >> >> El Miércoles, 24 de Marzo de 2010, zaverel escribió: >>> i 've patched pat.c and now remux.c >>> and with use xine-lib-1.2 with your second patch (who has typo >>> error) and that doesn't work. >>> >>> corrected remux.c >>> >>> line 533 >>> case SI::AC3DescriptorTag: >>> +case SI::EnhancedAC3DescriptorTag: >>> >>> >>> and in line 191: >>> >>> -Target[i++] = SI::AC3DescriptorTag; >>> +Target[i++] = SI::EnhancedAC3DescriptorTag; >>> >>> >>> >>> with your previously patch and just pat.c patched with >>> line 402 >>> >>> case SI::AC3DescriptorTag: >>> +case SI:EnhancedAC3DescriptorTag: >>> >>> that worked but not stable. >>> >>> Is your sample eac3 has |"Spectral extension" ? >>> because in france dvb-t with eac3 has it >>> and need a ffmpeg patched for that. >>> And i test with that sound. >>> >>> Le 24/03/2010 19:41, Jose Alberto Reguero a écrit : >>>> It works here with a old sample of tdt with eac3. Have you patch >>>> also remux.c? You need to change in line 533: >>>> >>>> case SI::AC3DescriptorTag: >>>> +case SI:EnhancedAC3DescriptorTag: >>>> >>>> and in line 191: >>>> >>>> -Target[i++] = SI::AC3DescriptorTag; >>>> +Target[i++] = SI::EnhancedAC3DescriptorTag >>>> >>>> Jose Alberto >>>> >>>> El Miércoles, 24 de Marzo de 2010, dplu escribió: >>>>> Hi >>>>> >>>>> I have made previous test with the version release by Petri >>>>> Hintukainen >>>>> >>>>> And I notice this part is not working like it should >>>>> >>>>> - if((m->descriptor_tag == STREAM_AUDIO_AC3) || /* ac3 - >>>>> raw */ + if(m->descriptor_tag == HDMV_AUDIO_84_EAC3) { >>>>> + m->content = p; >>>>> + m->size = packet_len; >>>>> + m->type |= BUF_AUDIO_EAC3; >>>>> + return 1; >>>>> + >>>>> + } else if((m->descriptor_tag == STREAM_AUDIO_AC3) || /* >>>>> ac3 - raw */ >>>>> >>>>> unfortunaletly, in AC3 or E-AC3 , the descriptor tag is >>>>> STREAM_AUDIO_AC3, so the program never run the first if >>>>> (installed a debug printf here) >>>>> >>>>> It seems that your first approach (at least what I understood) by >>>>> forcing the decoding of all AC-3 stream by ffmepg instead of >>>>> internal lib was nice but generate violent segfault on libavcodec >>>>> >>>>> Hope this help you >>>>> >>>>> Best regards >>>>> >>>>> PS : Sorry to pollute the vdr mailing list (not subscribed to >>>>> ffmpeg or xine-lib....) >>>>> >>>>> Le Wednesday 24 March 2010 18:41:14 zaverel, vous avez écrit : >>>>>> hello >>>>>> >>>>>> your second patch doesn't work : no sound on eac3 channel >>>>>> >>>>>> if you want there is a sample of vdr hd-eac3 recording here: >>>>>> >>>>>> http://dl.free.fr/ew4rJddM8 >>>>>> >>>>>> 103mo >>>>>> >>>>>> else , i don't know what mailing-list is the more indicate for >>>>>> debuging >>>>>> >>>>>> the vdr or xine-dev mailing-list ? >>>>>> >>>>>> _______________________________________________ >>>>>> 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
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
Al 25/03/10 16:08, En/na Jose Alberto Reguero ha escrit:
Patch for xine-lib that don't need to patch remux.c to work.
Today I applied this patch (strange it isn't in xine-lib-1.2 yet) but there's still no sound on tvehd (vdr 1.7.15, vdr-xine and playing the ts directly through xine). Do I need some special options to configure xine-lib for this patch to take effect?
Bye
El Domingo, 13 de Junio de 2010, Luca Olivetti escribió:
Al 25/03/10 16:08, En/na Jose Alberto Reguero ha escrit:
Patch for xine-lib that don't need to patch remux.c to work.
Today I applied this patch (strange it isn't in xine-lib-1.2 yet) but there's still no sound on tvehd (vdr 1.7.15, vdr-xine and playing the ts directly through xine). Do I need some special options to configure xine-lib for this patch to take effect?
Bye
I use the latest xine-lib hg without patches and xineliboutput with the attached patch. Live TV are ok, but the recordings have drop outs. vdr-xine don't work with eac3.
Jose Alberto
El Domingo, 13 de Junio de 2010, Luca Olivetti escribió:
Al 25/03/10 16:08, En/na Jose Alberto Reguero ha escrit:
Patch for xine-lib that don't need to patch remux.c to work.
Today I applied this patch (strange it isn't in xine-lib-1.2 yet) but there's still no sound on tvehd (vdr 1.7.15, vdr-xine and playing the ts directly through xine). Do I need some special options to configure xine-lib for this patch to take effect?
Bye
With this two patches vdr-xine work with eac3. I can't test if it still work with normal ac3. One patch is for the plugin, and the other is for xine-lib 1.2.
Jose Alberto
Hi
I Just test your patch, thanks for it, it applied well but seems not working, no e-ac3 sound on sample e-ac3 record for French DVB-T but AC3 sound is still OK
Which xine-lib 1.2 did you use ? this one : http://hg.debian.org/hg/xine-lib/xine-lib-1.2/ is not allways well synchronized, for example the patch for demux_ts on 1.1.18 changeset a1ba73e0b475 (april 9) is not on 1.2
I will check another time to see if I made no error on patching
Regards
Le Tuesday 21 September 2010 00:57:39 Jose Alberto Reguero, vous avez écrit :
El Domingo, 13 de Junio de 2010, Luca Olivetti escribió:
Al 25/03/10 16:08, En/na Jose Alberto Reguero ha escrit:
Patch for xine-lib that don't need to patch remux.c to work.
Today I applied this patch (strange it isn't in xine-lib-1.2 yet) but there's still no sound on tvehd (vdr 1.7.15, vdr-xine and playing the ts directly through xine). Do I need some special options to configure xine-lib for this patch to take effect?
Bye
With this two patches vdr-xine work with eac3. I can't test if it still work with normal ac3. One patch is for the plugin, and the other is for xine-lib 1.2.
Jose Alberto
El Domingo 26 Septiembre 2010, dplu escribió:
Hi
I Just test your patch, thanks for it, it applied well but seems not working, no e-ac3 sound on sample e-ac3 record for French DVB-T but AC3 sound is still OK
Which xine-lib 1.2 did you use ? this one : http://hg.debian.org/hg/xine-lib/xine-lib-1.2/ is not allways well synchronized, for example the patch for demux_ts on 1.1.18 changeset a1ba73e0b475 (april 9) is not on 1.2
I will check another time to see if I made no error on patching
Regards
You need a recent ffmpeg. I use latest hg xine-lib-1.2, and latest ffmpeg svn.
Jose Alberto.
Le Tuesday 21 September 2010 00:57:39 Jose Alberto Reguero, vous avez
écrit :
El Domingo, 13 de Junio de 2010, Luca Olivetti escribió:
Al 25/03/10 16:08, En/na Jose Alberto Reguero ha escrit:
Patch for xine-lib that don't need to patch remux.c to work.
Today I applied this patch (strange it isn't in xine-lib-1.2 yet) but there's still no sound on tvehd (vdr 1.7.15, vdr-xine and playing the ts directly through xine). Do I need some special options to configure xine-lib for this patch to take effect?
Bye
With this two patches vdr-xine work with eac3. I can't test if it still work with normal ac3. One patch is for the plugin, and the other is for xine-lib 1.2.
Jose Alberto
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
I demand that dplu may or may not have written...
[snip]
http://hg.debian.org/hg/xine-lib/xine-lib-1.2/ is not allways well synchronized, for example the patch for demux_ts on 1.1.18 changeset a1ba73e0b475 (april 9) is not on 1.2
It is...
[snip]
Hi
@Darren Salt Oupss you're right, I had another old patch for e-ac3 support auto applied I clean all now
@Jose Alberto By the way, we are two person having made same test : not working with this sample of french DVB-T HD , here is detail given by ffplay
sample : http://dl.free.fr/cMNuFuG8X
Stream #0.0[0xdc]: Video: h264, yuv420p, 1440x1080 [PAR 4:3 DAR 16:9], 50 fps, 50 tbr, 90k tbn, 50 tbc Stream #0.1[0xe7](qaa): Audio: eac3, 48000 Hz, 5.1, s16, 256 kb/s Stream #0.2[0xe6](fra): Audio: eac3, 48000 Hz, stereo, s16, 128 kb/s Stream #0.3[0xf0](fra): Subtitle: dvbsub
Can you please test this small file (48 Mo) and tell us if OK or not, this should be a good direction to go. I will rebuild a full new dev env on my machine
Many thanks for your help
Best regards
Le Sunday 26 September 2010 20:56:32 Darren Salt, vous avez écrit :
I demand that dplu may or may not have written...
[snip]
http://hg.debian.org/hg/xine-lib/xine-lib-1.2/ is not allways well synchronized, for example the patch for demux_ts on 1.1.18 changeset a1ba73e0b475 (april 9) is not on 1.2
It is...
[snip]
El Lunes 27 Septiembre 2010, dplu escribió:
Hi
@Darren Salt Oupss you're right, I had another old patch for e-ac3 support auto applied I clean all now
@Jose Alberto By the way, we are two person having made same test : not working with this sample of french DVB-T HD , here is detail given by ffplay
sample : http://dl.free.fr/cMNuFuG8X
Stream #0.0[0xdc]: Video: h264, yuv420p, 1440x1080 [PAR 4:3 DAR 16:9],50 fps, 50 tbr, 90k tbn, 50 tbc Stream #0.1[0xe7](qaa): Audio: eac3, 48000 Hz, 5.1, s16, 256 kb/s Stream #0.2[0xe6](fra): Audio: eac3, 48000 Hz, stereo, s16, 128 kb/s Stream #0.3[0xf0](fra): Subtitle: dvbsub
Can you please test this small file (48 Mo) and tell us if OK or not, this should be a good direction to go. I will rebuild a full new dev env on my machine
Many thanks for your help
Best regards
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
Le Sunday 26 September 2010 20:56:32 Darren Salt, vous avez écrit :
I demand that dplu may or may not have written...
[snip]
http://hg.debian.org/hg/xine-lib/xine-lib-1.2/ is not allways well synchronized, for example the patch for demux_ts on 1.1.18 changeset a1ba73e0b475 (april 9) is not on 1.2
It is...
[snip]
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
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
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
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
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.
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.
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
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.
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
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.
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 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.
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
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.
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.
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
Attached is a patch to fix xine-lib ts work with eac3. With this patch you can use xine-ui to play the records.
Jose Alberto
El Domingo 03 Octubre 2010, Jose Alberto Reguero escribió:
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
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On Martes, 10 de julio de 2012 22:53:44 Karim Afifi escribió:
Up please :-)
Karim
-----Message d'origine----- De : vdr-bounces@linuxtv.org [mailto:vdr-bounces@linuxtv.org] De la part de Karim Afifi Envoyé : vendredi 18 mai 2012 21:32 À : 'VDR Mailing List' Objet : Re: [vdr] vdr xine-lib eac3
Hello,
I am using vdr-1.7.27 and xineliboutput (with xine-lib from january 2012 and José Alberto's patch). All HD dvb-t french channels are deliver "eac3", but vdr delivers only stereo pcm on the spdif output (instead of 5.1).
Is it the normal behaviour, or did I miss something ? Is there a way to convert eac3 => ac3 for delivering 5.1 stream through the spdif output ?
Regards. Karim
You can try latest vdr and latest xine-lib-1.2 without patches. I use also a patch(attached) for xine-lib-1.2 but perhaps you don't need it. But I don't know if spdif works because decoding eac3 is done via ffmpeg.
Jose Alberto
-----Message d'origine----- De : vdr-bounces@linuxtv.org [mailto:vdr-bounces@linuxtv.org] De la part de Jose Alberto Reguero Envoyé : dimanche 3 octobre 2010 23:56 À : VDR Mailing List Objet : Re: [vdr] vdr xine-lib eac3
Attached is a patch to fix xine-lib ts work with eac3. With this patch you can use xine-ui to play the records.
Jose Alberto
El Domingo 03 Octubre 2010, Jose Alberto Reguero escribió:
Playing with xine-ui and demux ts don't work well. You must play it with vdr- xine.
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
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.
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 5493 (20100930) __________
Le message a été vérifié par ESET Smart Security.
-
Darren Salt -
dplu -
Jose Alberto Reguero -
Karim Afifi -
Luca Olivetti -
zaverel -
zaverel＠free.fr