Re: [vdr] softdevice audio problem. audio repacker issue?
On 3/18/07, Martin Wache [EMAIL PROTECTED] wrote: I switched the repacking of in my vdr... I don't think that it is necessary. Bye, Martin Hi, I would like to disable the repacker in my VDR implementation as I think it might be responsible for sync problems in transfer mode between my budget Nova-T and FF DVB-S. Could you let me know how you turned it off and if possible post a patch to do it? Kind Regards, Morfsta ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] softdevice audio problem. audio repacker issue?
Hi, Martin Wache wrote: I agree that it is cleaner to have an index file which points to complete frames, but I never experienced any problems without repacking. So it seems to me that only xine's libmpeg2 has the problem to drop incomplete frames. This was annoying when moving cutting marks and I first solved this issue by patching GetNextIFrame() to deliver the missing tail too. But Klaus didn't like this hack and asked for a cleaner approach. The solution sounds quite simple: just start a new PES packet for each video frame and everything is fine. But the actual solution is quite complex: cVideoRepacker. I switched the repacking off in my vdr... I don't think that it is necessary. Maybe you are right. The benefit of avoiding memcpys when repacking is done already during the TS to PES transformation is void as long as one cannot rely on getting repacked packets all the time. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] softdevice audio problem. audio repacker issue?
On Sun, Mar 18, 2007 at 01:26:03PM +0100, Reinhard Nissl wrote: I switched the repacking off in my vdr... I don't think that it is necessary. Maybe you are right. The benefit of avoiding memcpys when repacking is done already during the TS to PES transformation is void as long as one cannot rely on getting repacked packets all the time. Due to the limited power of the Geode with 300MHz of the Reelbox, I've analyzed the TS-path in the vdr with gprof/oprofile and re-wrote the repacker from scratch and changed some of the related TS code in device/dvbdevice. It has a lot of optimizations: - The ringbuffer works with packet granularity (no single bytes), no extra sync checks are needed. Multiple memcpy of the same data is avoided as much as possible, especially for the video part. - The MPEG-sequence code search (ScanVideoPacket) is optimized for simple CPUs where the raw number of memory accesses and instructions is important (no memchr, that's slower on the Geode) - The video packer detects if the PES-flag in the TS header actually starts a new PES packet with I, P and B-frames at the TS beginning. After this detection, the search for start-of-picture is no longer done and the PES-flag only determines the separation. Since a lot of broadcasters are using the flag this way (especially the hingh bandwidth ones like ARD and ZDF in Germany) this saves a lot of CPU time. Services which don't allow this usually have low bandwidth anyway and are IMO not that important anyway (CNBC, Gods Channel, etc ;-) )... - There's one ringbuffer (and thus one data copying) eliminated in the way from the DVB-device to the TS receivers. Multiple ringbuffers in a row only give the illusion of better buffering... - The TS-dispatcher in cDevice::Action looks for bursts of TS-packets with the same PID and only does one Lock() and one Receive()-call for this burst instead for each single packet. Video data usually comes in bursts, so this saves a lot of unnecessary overhead. As the receiver function allows multiple packets (length parameter) this is perfectly legal. Unfortunately, some plugins don't respect the length parameter (older femon comes to mind, I don't know about the latest version). But that is easily fixed... The new repacker may have some issues with AC3 or some audio-only channels, but maybe it's worth to have a look at its code... svn co svn://[EMAIL PROTECTED]/testing/src/vdr-1.4/ -- Georg Acher, [EMAIL PROTECTED] http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] softdevice audio problem. audio repacker issue?
Hi, Is there a patch available with your modifications? Thanks Halim On So, Mär 18, 2007 at 04:30:02 +0100, Georg Acher wrote: On Sun, Mar 18, 2007 at 01:26:03PM +0100, Reinhard Nissl wrote: I switched the repacking off in my vdr... I don't think that it is necessary. Maybe you are right. The benefit of avoiding memcpys when repacking is done already during the TS to PES transformation is void as long as one cannot rely on getting repacked packets all the time. Due to the limited power of the Geode with 300MHz of the Reelbox, I've analyzed the TS-path in the vdr with gprof/oprofile and re-wrote the repacker from scratch and changed some of the related TS code in device/dvbdevice. It has a lot of optimizations: - The ringbuffer works with packet granularity (no single bytes), no extra sync checks are needed. Multiple memcpy of the same data is avoided as much as possible, especially for the video part. - The MPEG-sequence code search (ScanVideoPacket) is optimized for simple CPUs where the raw number of memory accesses and instructions is important (no memchr, that's slower on the Geode) - The video packer detects if the PES-flag in the TS header actually starts a new PES packet with I, P and B-frames at the TS beginning. After this detection, the search for start-of-picture is no longer done and the PES-flag only determines the separation. Since a lot of broadcasters are using the flag this way (especially the hingh bandwidth ones like ARD and ZDF in Germany) this saves a lot of CPU time. Services which don't allow this usually have low bandwidth anyway and are IMO not that important anyway (CNBC, Gods Channel, etc ;-) )... - There's one ringbuffer (and thus one data copying) eliminated in the way from the DVB-device to the TS receivers. Multiple ringbuffers in a row only give the illusion of better buffering... - The TS-dispatcher in cDevice::Action looks for bursts of TS-packets with the same PID and only does one Lock() and one Receive()-call for this burst instead for each single packet. Video data usually comes in bursts, so this saves a lot of unnecessary overhead. As the receiver function allows multiple packets (length parameter) this is perfectly legal. Unfortunately, some plugins don't respect the length parameter (older femon comes to mind, I don't know about the latest version). But that is easily fixed... The new repacker may have some issues with AC3 or some audio-only channels, but maybe it's worth to have a look at its code... svn co svn://[EMAIL PROTECTED]/testing/src/vdr-1.4/ -- Georg Acher, [EMAIL PROTECTED] http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr -- Halim Sahin E-Mail: halim.sahin (at) t-online.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] softdevice audio problem. audio repacker issue?
On Sun, Mar 18, 2007 at 05:25:00PM +0100, Halim Sahin wrote: Hi, Is there a patch available with your modifications? That's a bit difficult, since our vdr has no exact mainline equivalent. It may contain parts from different vdr versions. But as I've heard, it should work also on a full featured card without any modifications. Maybe you need to tweak the makefile... The remuxer itself should be API compatible, so exchanging the file and using tools.c/h from the svn should also work. -- Georg Acher, [EMAIL PROTECTED] http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] softdevice audio problem. audio repacker issue?
Hi, Georg Acher wrote: The new repacker may have some issues with AC3 or some audio-only channels, but maybe it's worth to have a look at its code... svn co svn://[EMAIL PROTECTED]/testing/src/vdr-1.4/ I'll have a look at it the next days. I must admit, that the repacker classes were designed to be integrated into the existing TS/PES remux code at almost no changes (at least no complex changes). I thought about rewriting the whole chain too but didn't find time so far respectively didn't have the need to do it. Thanks for your work in this area. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] softdevice audio problem. audio repacker issue?
Reinhard Nissl schrieb:
Hi,
Stefan Lucke wrote:
Dumping the first 16 bytes of audio packets we get, shows the following:
ff fc a4 0d b6 64 88 55 33 65 56 54 44 21 33 33
ff fc a4 0d 54 6a 88 65 33 44 56 54 33 33 33 33
ff fc a4 0d 02 a4 88 55 33 54 66 44 43 33 33 33
99 77 1b e6 34 b2 5f 41 e8 5b 90 a9 d2 04 24 5e
ff fc c4 04 7c c4 dd 44 44 66 57 55 55 55 33 33
ff fc c4 04 1d 61 dd 46 44 66 55 55 55 55 33 33
68 6a 60 18 d8 52 92 4f 54 98 0b 93 27 22 4e 74
ff fc c4 04 94 01 dd 44 56 66 55 55 55 55 33 33
Is audio repacker active even for old recording ?
When I deactivate audio repacker, sound is garbled allways.
cAudioRepacker was introduced after VDR-1.3.26 and it is only active in
transfer mode or while recording. It is not active while replaying a
recording, so it has no influence on recordings taken with VDR-1.2.1.
But when cAudioRepacker was not active, an audio PES packet may contain,
multiple audio frames and/or just a fragment of an audio frame at the
beginning or at the end of the PES packet.
So if ffmpeg can only work on single and/or complete audio frames,
you'll have to break the PES packet apart and assemble the fragments at
the end and the beginning of the next PES packet.
FFmpeg can handle handle packets with multiple audio frames well, one
just has to use the av_read_frame() interface instead of
av_read_packet() like the softdevice currently does. There has been a
change in the audio decode some time ago, before the decoder could also
split the packets, that is why it worked before...
I attached a patch with make the softdevice use av_read_frame(), it has
still some issues, but it solves the problems Stefan reports.
Is there a reason why the cAudioRepacker is used in transfer mode and
during recordings, but not while replaying?
Bye,
Martin
Index: mpeg2decoder.c
===
RCS file: /cvsroot/softdevice/softdevice/mpeg2decoder.c,v
retrieving revision 1.72
diff -u -r1.72 mpeg2decoder.c
--- mpeg2decoder.c 26 Feb 2007 23:00:34 - 1.72
+++ mpeg2decoder.c 17 Mar 2007 20:51:17 -
@@ -174,7 +174,7 @@
freezeMode=false;
AVPacket *pkt;
- while ( PacketQueue.Available() 7 active) {
+ while ( PacketQueue.Available() 3 active) {
BUFDEB(wait while loop packets %d StreamDecoder pid:%d type %d\n,
PacketQueue.Available(),getpid(),context-codec_type );
usleep(1);
@@ -1115,20 +1115,31 @@
usleep(5);
BUFDEB(av_read_frame start\n);
-//ret = av_read_frame(ic, pkt);
-ret = av_read_packet(ic, pkt);
+ret = av_read_frame(ic, pkt);
+//ret = av_read_packet(ic, pkt);
if (ret 0) {
BUFDEB(cMpeg2Decoder Stream Error!\n);
if (ThreadActive)
usleep(1);
continue;
}
-//av_dup_packet(pkt);
+av_dup_packet(pkt);
PacketCount++;
BUFDEB(got packet from av_read_frame!\n);
+#if LIBAVFORMAT_BUILD 4623
+AVRational time_base;
+time_base=ic-streams[pkt.stream_index]-time_base;
+if ( pkt.pts != (int64_t) AV_NOPTS_VALUE ) {
+pkt.pts=av_rescale(pkt.pts, AV_TIME_BASE*
(int64_t)time_base.num, time_base.den)/100 ;
+};
+
+//printf(PTS: %lld new %lld num %d den %d\n,PTS,pkt.pts,
+//time_base.num,time_base.den);
+#else
if ( pkt.pts != (int64_t) AV_NOPTS_VALUE )
pkt.pts/=9;
+#endif
QueuePacket(ic,pkt,packetMode);
@@ -1184,9 +1195,6 @@
void cMpeg2Decoder::QueuePacket(const AVFormatContext *ic, AVPacket pkt,
bool PacketMode)
{
- BUFDEB(QueuePacket AudioIdx: %d VideoIdx %d pkt.stream_index: %d\n,
-AudioIdx,VideoIdx,pkt.stream_index);
-
if (!ic) {
fprintf(stderr,Error: ic is null!\n);
av_free_packet(pkt);
@@ -1212,6 +1220,8 @@
BUFDEB(Unknown packet type! Return;\n);
return;
};
+ BUFDEB(QueuePacket AudioIdx: %d VideoIdx %d pkt.stream_index: %d,
packet_type: %d\n,
+AudioIdx,VideoIdx,pkt.stream_index,packet_type);
// check if there are new streams
if ( AudioIdx != DONT_PLAY packet_type == CODEC_TYPE_AUDIO
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] softdevice audio problem. audio repacker issue?
Hi, Reinhard Nissl schrieb: Hi, Martin Wache wrote: Is there a reason why the cAudioRepacker is used in transfer mode and during recordings, but not while replaying? Well, when cAudioRepacker was active while recording, then there is no need for it when replaying such a recording. Wouldn't it make more sense to use the repacker only when replaying and in transfer mode and not while recording? Like it is now, it is possible that the device gets either repacked audio frames (transfer mode and new recordings) or not repacked frames. If the device needs repacked frames the device has to find out if it is replaying an old recording to play and if so, split the packets. I guess in most cases it is a lot simpler just to repack everything. Which means in most cases to do the repacking twice... And old recordings will vanish as time passes by. I don't buy this argument. I know that there are VDR users with large archives of recordings, do you want to tell them that they can't use them any more? But anyway, actually I think the best would be only to repack audio and video if the replaying device needs it. As far as I know FF cards don't need it, the softdevice doesn't need it (ok, it depends on the ffmpeg version one uses, but the patch I send fixes this). So why not let the device choose if repacking is needed or not? It should now if repacking is needed, and in most cases it should be able to do it by itself. Bye, Martin ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] softdevice audio problem. audio repacker issue?
On Saturday 17 March 2007 23:11, Martin Wache wrote: Hi, Reinhard Nissl schrieb: And old recordings will vanish as time passes by. I don't buy this argument. I know that there are VDR users with large archives of recordings, do you want to tell them that they can't use them any more? Second that. Lifetime 99. Won't tell my son, that his favorit recordings of Die Sendung mit der Maus won't be accessible after the next software upgrade :-) . -- Stefan Lucke ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] softdevice audio problem. audio repacker issue?
On Saturday 17 March 2007 22:05, Martin Wache wrote: I attached a patch with make the softdevice use av_read_frame(), it has still some issues, but it solves the problems Stefan reports. Martin, thats really great. Thank you. This solves the issue I had with playback of some old recordings. But there is still one drawback. It is still not playable with softplay. Neither audio nor video. There are only some accustic fragments and no video frame. -- Stefan Lucke ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] softdevice audio problem. audio repacker issue?
Hi, Martin Wache wrote: Is there a reason why the cAudioRepacker is used in transfer mode and during recordings, but not while replaying? Well, when cAudioRepacker was active while recording, then there is no need for it when replaying such a recording. Wouldn't it make more sense to use the repacker only when replaying and in transfer mode and not while recording? Like it is now, it is possible that the device gets either repacked audio frames (transfer mode and new recordings) or not repacked frames. If the device needs repacked frames the device has to find out if it is replaying an old recording to play and if so, split the packets. I guess in most cases it is a lot simpler just to repack everything. Which means in most cases to do the repacking twice... Fiddling around with repacking at that late stage is quite a mess especially in trickspeed mode. And cVideoRepacker causes high CPU load because there is no length information in the video stream so the whole stream has to be scanned for the 00 00 01 pattern. Furthermore, consider the memcpying involved in this process. That's why we have chosen the earliest stage possible (cRemux) to do this complex stuff just once. And old recordings will vanish as time passes by. I don't buy this argument. I know that there are VDR users with large archives of recordings, do you want to tell them that they can't use them any more? No, I don't, as there is no need to. VDR's device interface specification doesn't state any relationship between PES packets and their content, so a device implementation shouldn't rely on that. But anyway, actually I think the best would be only to repack audio and video if the replaying device needs it. As far as I know FF cards don't need it, the softdevice doesn't need it (ok, it depends on the ffmpeg version one uses, but the patch I send fixes this). So why not let the device choose if repacking is needed or not? It should now if repacking is needed, and in most cases it should be able to do it by itself. Well, it isn't just a matter of the output device. cVideoRepacker takes care that VDR's index file contains valid entries. Before cVideoRepacker, the index file could address incomplete frames or even miss some frames. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
