Re: [vdr] [ANNOUNCE] naludump 0.0.1
Am 01.01.2011 22:29, schrieb Udo Richter: Later versions will also integrate into VDR as a patch, and will filter out these fillers while recording. I've released an quick early naludump patch for vdr-1.7.16, you can get it at VDR portal: http://www.vdr-portal.de/board/thread.php?postid=979062#post979062 To activate the patch, you have to add 'NALUDUMP' to the recording name. An more polished official patch and the corresponding command line tool will follow next weekend. Oh, and @Rolf: The patch hijacks the stream right before the disk write, always processes the whole buffer, and just needs an 188 byte temp buffer for TS packet fragments. This in-buffer rewrite was really annoying complicated! Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] naludump 0.0.1
Has anyone here every used or seen an STB's rotor support? The one I have is a first gen Neusat SP-6000. Maybe those of you with the interest in doing it and programing skill to tackle it have a sat store near by where you can see one and get a look at the setup functions. OR find a cheap one on ebay. Ask in the forum at http://www.satelliteguys.us/ for which units are good examples or for recomendations of options/functions that are useful. Might even be able to get some screen shots for ref design. Combine the best of has been done. A lot of those guys have several STB's and have seen/tried many more. On 1/22/2011 6:18 AM, Rolf Ahrenberg wrote: On Fri, 21 Jan 2011, Udo Richter wrote: On 01.01.2011 22:29, Udo Richter wrote: Later versions will also integrate into VDR as a patch, and will filter out these fillers while recording. I had some issues integrating it properly into the recording function of VDR, and then ran out of time. But I think I'll find some time this weekend. Howabout just adding a filter API and do the actual job in a plugin - I have some ideas where I could reuse such a mechanism. BR, -- rofa ___ 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
Re: [vdr] [ANNOUNCE] naludump 0.0.1
On Sat, 22 Jan 2011, Udo Richter wrote: Thought of that too, for a longer perspective. However, what do you think where to add such a hook ideally? My original idea was to hook in cDevice::Action() as it would bring most flexible setup to blacklist/rewrite pids. However, I forgot the current section mechanism and pat/pmt parsing. Adding a hook to cDevice::Action would affect all streams, including transfer mode and streaming etc., but has no known relation between PID and stream type. Also, there may be several video streams in parallel here. And I wouldn't consider it good style to provide just filtered streams for all in any case. Wouldn't stripping NALU fill data help to reduce the required network bandwidth for streamdev, xineliboutput, and vnsi plugins? I do see many benefits using filtered streams everywhere. You could also transcode only certain video/audio pids as the device class know its' transponder/channel parameters. Adding a hook to cRecorder::Receive() would be nice, as (although not explicitly specified) the data is received as single TS packets, which would allow packet dropping easily. Also, the packets can easily be checked for the (one and only) video PID and video type. However, Receive() is supposed to return immediately, esp. since its called within a Lock() of the device. You could simply hook up into the ringbuffer methods used in cRecorder. A more flexible way would be to add yet another ring buffer between the receiving buffer and the frame detector, and do the hook between the buffers. But another buffer will be additional overhead... ..and you already thought about it. :) Anyway, it's up to the plugin how big the overhead will be and it wouldn't hurt when recording. It's up to the user how many recording filters she's going to chain... BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] naludump 0.0.1
On Sat, 22 Jan 2011, Timothy D. Lenz wrote: Has anyone here every used or seen an STB's rotor support? The one I have is a first gen Neusat SP-6000. Maybe those of you with the interest in doing it and programing skill to tackle it have a sat store near by where you can see one and get a look at the setup functions. OR find a cheap one on ebay. Ask in the forum at http://www.satelliteguys.us/ for which units are good examples or for recomendations of options/functions that are useful. Might even be able to get some screen shots for ref design. Combine the best of has been done. A lot of those guys have several STB's and have seen/tried many more. Well, this looks like hijacking a thread, but I'll give my 2 cents anyway. Howabout just polising the current GotoX patch and convince Klaus to merge it into upcoming developer versions. IMO, it should be simple enough for a core feature in both feature and setup wise. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] naludump 0.0.1
Am 22.01.2011 20:21, schrieb Rolf Ahrenberg: And I wouldn't consider it good style to provide just filtered streams for all in any case. Wouldn't stripping NALU fill data help to reduce the required network bandwidth for streamdev, xineliboutput, and vnsi plugins? I do see many benefits using filtered streams everywhere. Receivers like streamdev and vnsi are free to filter their streams too, if they want. An output device on the other hand will decode the TS stream to PES stream and then to nalu stream anyway (ignoring the fill), so it doesn't make much sense to do deep packet analysis and TS rewriting and filtering right before that. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] naludump 0.0.1
Hi Udo, On 01.01.2011 22:29, Udo Richter wrote: Later versions will also integrate into VDR as a patch, and will filter out these fillers while recording. Is there any progress on this topic? For me that’s the most useful use case and I’d like to beta-test any VDR patch on this topic. – Matthias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] naludump 0.0.1
On Sat, Jan 1, 2011 at 1:29 PM, Udo Richter udo_rich...@gmx.de wrote: Hi list, This is the test version 0.0.1 of my h.264 nalu fill data removal tool. The tool deletes NALU fill data from h.264 streams embedded into TS files, like VDR recordings. The overall file structure isn't modified, only complete TS packets of NALU fill data are removed. On HD TV channels that use fixed video bandwidth, this can save 40-60% file size without loosing any data. I tried this on 3 different HD h264 recordings from 3 different channels. In all cases no packets were dropped. However, I don't believe my provider wastes bandwidth with fill data so that would explain it. Best regards, Derek ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] naludump 0.0.1
Am 21.01.2011 12:40, schrieb Matthias Wächter: On 01.01.2011 22:29, Udo Richter wrote: Later versions will also integrate into VDR as a patch, and will filter out these fillers while recording. Is there any progress on this topic? For me that’s the most useful use case and I’d like to beta-test any VDR patch on this topic. I had some issues integrating it properly into the recording function of VDR, and then ran out of time. But I think I'll find some time this weekend. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] naludump 0.0.1
Hi list, This is the test version 0.0.1 of my h.264 nalu fill data removal tool. The tool deletes NALU fill data from h.264 streams embedded into TS files, like VDR recordings. The overall file structure isn't modified, only complete TS packets of NALU fill data are removed. On HD TV channels that use fixed video bandwidth, this can save 40-60% file size without loosing any data. Version 0.0.1 is a standalone tool to process single files, and is mainly for compatibility tests and verification. Please use it on recordings, then check whether these recordings seem un-modified, and if you have, use stream verification tools like ts-doctor for verification. Later versions will also integrate into VDR as a patch, and will filter out these fillers while recording. For backgrounds, and for the Nalustripper tool of MartenR, see http://www.vdr-portal.de/board/thread.php?threadid=98948 For vdrportal topic, see: http://www.vdr-portal.de/board/thread.php?threadid=102634 Source code available here: http://www.udo-richter.de/vdr/naludump.html(de) http://www.udo-richter.de/vdr/naludump.en.html (en) For code readers: Most files are stripped-down versions of VDR code. New code is in naludump.c (basic file processing) and remux.c (class cNaluDumper and some helper functions). Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
