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] Hard link cutter [was: Suggestion: High speed cutting]
Udo Richter wrote: This has been in my mind for over two years, and now I just wanted to see it working: Using hard file system links to speed up editing whenever a 00x.vdr file is copied from source to destination recording without modification. This has crossed my mind several times as well, thanks for implementing it! Future plans To solve the file size vs. recording size conflict, dynamic file sizes could be implemented, so that a recording starts with small file sizes, and increases the file size at some point to ensure enough space for huge recordings before 255.vdr is reached. For example, using 32Mb up to 192.vdr and 2000mb from 193.vdr on will give a total of 128 Gb or 84 hours, while using small files for up to 4 hours. Why not just change the naming of video files to four, five or even eight digits? /Richard ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Re: vdr doesn't recognise some remote keys when using LIRC
On 6 Mar 2007, at 11:44, Torgeir Veimo wrote: I'm using a lirc setup with inputlircd daemon with a hauppauge remote on a dvb card. Everything works with the remote plugins using /dev/input/eventX, but I'm trying to share the remote with several applications. For some reason when trying to learn keys with LIRC, when I'm running the inputlircd daemon, VDR refuses to react to them. I can see the keys being interpreted properly with irw. Does anyone know why this can be? The keycodes that vdr doesn't recognize (as output by irw) are: 2 0 KEY_1 event1 3 0 KEY_2 event1 4 0 KEY_3 event1 5 0 KEY_4 event1 6 0 KEY_5 event1 6 0 KEY_5 event1 7 0 KEY_6 event1 8 0 KEY_7 event1 9 0 KEY_8 event1 a 0 KEY_9 event1 a 0 KEY_9 event1 b 0 KEY_0 event1 8b 0 KEY_MENU event1 ae 0 KEY_EXIT event1 18e 0 KEY_RED event1 71 0 KEY_MUTE event1 cf 0 KEY_PLAY event1 80 0 KEY_STOP event1 Any idea? Is there any mask of some sort in VDR that prevents certain keycodes to be recognized? (I'm using inputlircd daemon). -- Torgeir Veimo [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 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
Re: [vdr] Hard link cutter [was: Suggestion: High speed cutting]
Hi, Richard Lithvall wrote: Why not just change the naming of video files to four, five or even eight digits? The problem is not the file name, it's the index file. An index entry stores the file number as uchar, which allows 256 recording files. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
