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 0x341 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
[vdr] cSdtFIlter and LinkChannels
Hello, I'm trying to understand cSdtFilter in order to write a channel scanner. I see that when it finds a SI::NVODReferenceDescriptorTag it will add it to the previously found channel with channel-SetLinkChannels, but it only does if it is in the current section (channel is a local variable) while the sdt could span several sections. From the specifications here http://neuron2.net/library/mpeg2/iso13818-1.pdf and here http://www.dvb.org/technology/standards/a005r5.tm1324r13.tr101211.v1.10.1.pdf I don't understand if this mechanism is correct, shouldn't the time_shifted_services link to the NVOD_reference? Besides, I don't see that the relation between a channels and its linkchannels is preserved in channels.conf (though I don't really care). I also see that cSdtFilter starts processing with the first section, and that shouldn't really be necessary as long as one processes all sections. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr xine-lib eac3
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-boun...@linuxtv.org [mailto:vdr-boun...@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 0x341 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] Recordings Numbering
Hi all, I was wondering about the recording numbers associated with recordings in the LSTR output. There doesn't seem to be any obvious pattern, is the numbering just random? It'd be preferable if recordings kept a unique number, that didn't change when every time a recording gets deleted, or a new recording is started. Cheers, Dom ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] .TS recordings
For reason, when playing back 1 out of every 10 .ts recordings (from vdr 1.7.x) in XBMC, it is unable to skip forwards through the recording, instead it just jumps back to the start of the recording (00:00). Any idea why this might be? Cheers, Dom ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] .TS recordings
Ah. After sending this I spotted https://roundup.ffmpeg.org/issue1128 It seems timestamp wrapping is to blame? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
