Re: [vdr] vdr --genindex fails on radio recording
Hi Thomas, The patch is a tiny bit different for VDR 2.2.0 - in remux.c - see below There's a small issue with audio types also: Here, AAC (ADTS) per ISO/IEC 13818-7 or AAC (LATM) per ISO/IEC 14496-3 is regularly used for audio in HD broadcasts - my suggestion is that these streams should be handled too. For example, I transcode radio/audio to AAC in m4a or AAC_LATM in .ts files. Arguably the newer ATSC, DTS, Dolby true HD... streams should be added too ( https://en.wikipedia.org/wiki/Program-specific_information#Elementary_stream_types ) For now my audioparser line looks like this, which works for both flavours of AAC, and they play on Kodi and VLC. else if (type == 0x03 || type == 0x04 || type == 0x06 || type == 0x0F || type == 0x11) // MPEG2,4 AAC, AC3 audio The original audio-only .ts (MP2 codec) actually doesn't play in VLC, but plays in ffplay. Patch: --- remux.c.orig 2016-06-30 14:16:52.530155071 +0100 +++ remux.c 2016-06-30 14:36:09.028232179 +0100 @@ -604,6 +604,7 @@ void cPatPmtParser::Reset(void) { + completed = false; pmtSize = 0; patVersion = pmtVersion = -1; pmtPids[0] = 0; @@ -893,6 +894,7 @@ } } pmtVersion = Pmt.getVersionNumber(); + completed = true; } else esyslog("ERROR: can't parse PMT"); @@ -1464,7 +1466,7 @@ parser = new cMpeg2Parser; else if (type == 0x1B) parser = new cH264Parser; - else if (type == 0x04 || type == 0x06) // MPEG audio or AC3 audio + else if (type == 0x03 || type == 0x04 || type == 0x06 || type == 0x0F || type == 0x11) // MPEG2,4 AAC, AC3 audio parser = new cAudioParser; else if (type != 0) esyslog("ERROR: unknown stream type %d (PID %d) in frame detector", type, pid); On 27/06/2016 06:46, Thomas Reufer wrote: Hi Richard I observed the same behavior two weeks ago when I wanted to replay an edited radio recording. Please find my proposed fix attached, maybe Klaus will take it into the next VDR developer release. Regards, Thomas Quoting Richard F : ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr --genindex fails on radio recording
Thanks both - I'll give it a try - let you know how it goes against 2.2.0 Richard On 26/06/2016 16:31, Klaus Schmidinger wrote: > >> On 26 Jun 2016, at 04:23, Richard F wrote: >> >> Hi Klaus, >> >> In my testing, (VDR 2.20) the command vdr --genindex fails on an audio-only >> recording from a radio station for example. >> >> The index file is generated during a recording, but if deleted, vdr itself >> cannot regenerate it, nor can the command line command. Kodi for example >> tries to regenerate it when playing, if it's missing, and fails. If the >> index is already there, it gets deleted. Is this by design, or a bug ? > It’s a bug, and a fix (provided by Thomas Reufer) will be coming to > VDR 2.2.1 soon (after I return from my summer vacation ;-). > > I’m attaching Thomas’ suggested patch, which I haven’t tested myself, yet. > It’s against VDR version 3.3.1, so I can’t guarantee it will apply easily > to version 2.2.0. > > Klaus > > ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr --genindex fails on radio recording
Hi Richard I observed the same behavior two weeks ago when I wanted to replay an edited radio recording. Please find my proposed fix attached, maybe Klaus will take it into the next VDR developer release. Regards, Thomas Quoting Richard F : Hi Klaus, In my testing, (VDR 2.20) the command vdr --genindex fails on an audio-only recording from a radio station for example. The index file is generated during a recording, but if deleted, vdr itself cannot regenerate it, nor can the command line command. Kodi for example tries to regenerate it when playing, if it's missing, and fails. If the index is already there, it gets deleted. Is this by design, or a bug ? Thanks Richard >From ecfdf422cb4d7e88088cfb740197e684adb69966 Mon Sep 17 00:00:00 2001 From: Thomas Reufer Date: Mon, 13 Jun 2016 16:42:03 +0200 Subject: [PATCH 9/9] proposal to fix index generation for radio recordings --- recording.c | 8 remux.c | 4 +++- remux.h | 3 +++ 3 files changed, 10 insertions(+), 5 deletions(-) diff --git a/recording.c b/recording.c index a847c7d..b1b7c81 100644 --- a/recording.c +++ b/recording.c @@ -2324,7 +2324,7 @@ void cIndexFileGenerator::Action(void) Buffer.Del(Processed); } } - else if (PatPmtParser.Vpid()) { + else if (PatPmtParser.Completed()) { // Step 2 - sync FrameDetector: int Processed = FrameDetector.Analyze(Data, Length); if (Processed > 0) { @@ -2346,9 +2346,9 @@ void cIndexFileGenerator::Action(void) PatPmtParser.ParsePmt(p, TS_SIZE); Length -= TS_SIZE; p += TS_SIZE; -if (PatPmtParser.Vpid()) { - // Found Vpid, so rewind to sync FrameDetector: - FrameDetector.SetPid(PatPmtParser.Vpid(), PatPmtParser.Vtype()); +if (PatPmtParser.Completed()) { + // Found pid, so rewind to sync FrameDetector: + FrameDetector.SetPid(PatPmtParser.Vpid() ? PatPmtParser.Vpid() : PatPmtParser.Apid(0), PatPmtParser.Vpid() ? PatPmtParser.Vtype() : PatPmtParser.Atype(0)); BufferChunks = IFG_BUFFER_SIZE; Rewind = true; break; diff --git a/remux.c b/remux.c index cfb6ae3..df38add 100644 --- a/remux.c +++ b/remux.c @@ -603,6 +603,7 @@ cPatPmtParser::cPatPmtParser(bool UpdatePrimaryDevice) void cPatPmtParser::Reset(void) { + completed = false; pmtSize = 0; patVersion = pmtVersion = -1; pmtPids[0] = 0; @@ -893,6 +894,7 @@ void cPatPmtParser::ParsePmt(const uchar *Data, int Length) } } pmtVersion = Pmt.getVersionNumber(); + completed = true; } else esyslog("ERROR: can't parse PMT"); @@ -1541,7 +1543,7 @@ void cFrameDetector::SetPid(int Pid, int Type) parser = new cH264Parser; else if (type == 0x24) parser = new cH265Parser; - else if (type == 0x04 || type == 0x06) // MPEG audio or AC3 audio + else if (type == 0x03 || type == 0x04 || type == 0x06) // MPEG audio or AC3 audio parser = new cAudioParser; else if (type != 0) esyslog("ERROR: unknown stream type %d (PID %d) in frame detector", type, pid); diff --git a/remux.h b/remux.h index bd0d145..80528bd 100644 --- a/remux.h +++ b/remux.h @@ -361,6 +361,7 @@ private: uint16_t compositionPageIds[MAXSPIDS]; uint16_t ancillaryPageIds[MAXSPIDS]; bool updatePrimaryDevice; + bool completed; protected: int SectionLength(const uchar *Data, int Length) { return (Length >= 3) ? ((int(Data[1]) & 0x0F) << 8)| Data[2] : 0; } public: @@ -397,6 +398,8 @@ public: int Vtype(void) const { return vtype; } ///< Returns the video stream type as defined by the current PMT, or 0 if no video ///< stream type has been detected, yet. + bool Completed(void) { return completed; } + ///< Returns true if the PMT has been completely parsed const int *Apids(void) const { return apids; } const int *Dpids(void) const { return dpids; } const int *Spids(void) const { return spids; } -- 2.4.9 ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr --genindex fails on radio recording
> On 26 Jun 2016, at 04:23, Richard F wrote: > > Hi Klaus, > > In my testing, (VDR 2.20) the command vdr --genindex fails on an audio-only > recording from a radio station for example. > > The index file is generated during a recording, but if deleted, vdr itself > cannot regenerate it, nor can the command line command. Kodi for example > tries to regenerate it when playing, if it's missing, and fails. If the index > is already there, it gets deleted. Is this by design, or a bug ? It’s a bug, and a fix (provided by Thomas Reufer) will be coming to VDR 2.2.1 soon (after I return from my summer vacation ;-). I’m attaching Thomas’ suggested patch, which I haven’t tested myself, yet. It’s against VDR version 3.3.1, so I can’t guarantee it will apply easily to version 2.2.0. Klaus 0009-proposal-to-fix-index-generation-for-radio-recording.patch Description: Binary data ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr --genindex fails on radio recording
Hi Klaus, In my testing, (VDR 2.20) the command vdr --genindex fails on an audio-only recording from a radio station for example. The index file is generated during a recording, but if deleted, vdr itself cannot regenerate it, nor can the command line command. Kodi for example tries to regenerate it when playing, if it's missing, and fails. If the index is already there, it gets deleted. Is this by design, or a bug ? Thanks Richard ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr