majstang Posted August 23, 2011 Posted August 23, 2011 I'm using my automatic commercial removal script as an after recording task in order to remove commercials from my recordings. VideoReDo edits the ts recording through the batcheditor. Sometimes VideoReDo calls for re-encoding of the audio and when this happens things fails and crashes. It's quite perculiar cuz there is no logical reason for VideReDo to call for an auido re-encode cuz the audio is in the common MPEG audio format. From the example today one recording got successfully stripped from commercials. Next show recorded some hours later, from the very same channel and still MPEG audio (and MPEG2 video), suddenly fails. I don't know if there is a problem with the RS recorded audio in the ts stream and i can't figure out the underlying problem. Didn't see this issue before as far as i know. The only thing changed is RS version. Still using the same script and same VideoReDo version. When analyzing the failing ts recording in TransEdit it is identical if comparing with the earlier successful ts recording. Here's a screendump of the stats for the failing ts: LogFile: TV3 2011-08-23 D:\TV\Recording Service\20110823_21-09-02_TV3_Hell s kitchen.ts Device: FireDTV BDA Tuner DVBC (2) 21:09:02 / 00:00:00 (~ 0,00 MB) Start 21:09:04 / 00:00:01 (~ 0,29 MB) PID 4104: MPEG2 Video, 16:9, 720x576, 25 fps 21:09:04 / 00:00:01 (~ 0,29 MB) PID 4360: MPEG Audio Stereo, 48 khz, 192 kbps 22:11:03 / 01:02:00 (~ 1928,04 MB) Stop Average Data Rate: 0,518 MB/s Total Size: 1928,0 MB (2021694096 Bytes) When recording the failing file there was no discontinuities at all. This is a mystery to me and I wondering if somebody have any ideas or pointers on how to solve the problem? Quote
Griga Posted August 24, 2011 Posted August 24, 2011 Next show recorded some hours later, from the very same channel and still MPEG audio (and MPEG2 video), suddenly fails. Both with teletext? Looks like VideoReDo occasionally gets confused by something. Does it detect MPEG Audio as such? Quote
majstang Posted August 24, 2011 Author Posted August 24, 2011 (edited) Both with teletext? Looks like VideoReDo occasionally gets confused by something. Does it detect MPEG Audio as such? Hi Griga! The subs is hardcoded. When playing both the successful and failing files with DVBViewer, subtitle menu says "None". Why this teletext container shows up in TransEdit in the first place i don't know. After more analyzing one can conclude this teletext container does play a big role whether VideoReDo stripping of commercials fails or not. If looking at the Comskip generated Vprj files for the successful one and comparing it with the failing one this is the result: Successful strip <Version>2<Filename>D:\TV\Saved Recordings\20110823_17-54-01_TV3_Hell s kitchen.ts <VideoStreamPID>4104 <AudioStreamPID>4360 <Cut>0:617200000 <Cut>7568000000:11750000000 <Cut>25055200000:28059600000 <Cut>34320800000:37160000000 Failing strip <Version>2<Filename>D:\TV\Saved Recordings\20110823_21-09-02_TV3_Hell s kitchen.ts <VideoStreamPID>4104 <AudioStreamPID>7944 <Cut>0:801200000 <Cut>9815600000:14331200000 <Cut>24869600000:29409200000 <Cut>34685200000:37168400000 As you see the PID for the failing one does not add up. Audio PID should have been somewhere in the 4000 range and not in the 7000 range. It is definitely so that when Comskip analyzes the failing recording it seem to mistaken the Audio PID with the Teletext PID. Since VideReDo just acts upon the Vprj result, that is why VideReDo calls for the audio recode. Why this happens and what is triggering the problem i have no idea about. Do you think the Teletext parser add you did earlier with the language labeling of teletext subs could have anything to do with it? If so it adds up timewise, cuz I haven't been using my commercial removal script at all since the teletext parser release and i have no memories of this issue before. ADD: In RS I do have "Teletext" checked in Output Format Options. Maybe that explains the teletext occurance in TransEdit even if there's no actual teletext sub in the recording. Edited August 24, 2011 by majstang Quote
Griga Posted August 24, 2011 Posted August 24, 2011 (edited) Do you think the Teletext parser add you did earlier with the language labeling of teletext subs could have anything to do with it? Definitely not. That's just a UI thing, but doesn't affect the stored/recorded teletext content whatsoever. The main problem seems to be that the Comskip stream detection doesn't read the PMT. As you can see in TransEdit it specifies unambiguously which PIDs are assigned to which streams. I know from experience that examining streams only and applying heuristics can lead to wrong conclusions. Random byte patterns may look like audio headers. Particularly teletext may be mistaken as AC3, because both share the same PES startcode (00 00 01 BD, private stream 1), and if AC3 sync words (0B 77) plus other characteristics are coincidentally appearing in the right order... that's why DVBViewer and TSPlayer are using a double strategy when dealing with TS files. They examine the PMT and the streams. Looks like the Comskip stream detection needs some enhancement. If there is an option like "Prefer AC3 audio if available" I would try to switch it off. Edited August 25, 2011 by Griga Quote
majstang Posted August 24, 2011 Author Posted August 24, 2011 Thanks for your thoughts on the matter I definitely have some serious debugging to do here Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.