Re: [Freevo-users] Better DVB support (C programmers needed)
On Sat 03.07.2004 at 02:16:33PM +0200, Dirk Meyer wrote: > Hi, > > same subject, different content. Besides timeshift, I want to watch a > show when it starts. Sounds simple, but programs don't start at the > given second. So I record 5 min earlier and stop 5 minutes after the > end. But I want to start watching when the show starts, or even > better, auto skip commercials. I wrote a filter for mplayer that detects black frames, and makes and EDL so that when watching the show after recording, the commercials are skipped automatically. It doesn't skip the commercial at the beginning of the show since it cannot tell if it is show or commercial, but after that it works pretty well. Provided that your TV channels insert black frames (or at least something that can be recognized easily), it should work also for you. The EDL can then easily be converted to a transcode command line parameter, for editing the video before archiving it. > I did some digging on a recorded ts from mplayer and xine. Both > contain only the two streams from video and audio. The TS IS don't > change (and shouldn't). The PES (or PS?) inside it also has an id, PES. Individual ES are packetized into PES, and then PES are multiplexed either into a PS or a TS. DVD uses PS, DVB uses TS. > also no change. The mpeg video and audio also has an id and -- no > change. So the recorded stream is useless to get this information. Not true, but it requires some heuristics. People have also implemented this kind of feature based on the sound level, which is higher during commercials (although it is forbidden by law, at least in France) and more uniform (loud all the time, whereas in the show it's louder sometimes). > There is meta information (PSI) on the channel, tools like tv_grab_dvb > use them to get the epg. Again, some digging: the epg has a status > field: running, running in some secs, running later, pause. Great. But > the information is wrong :-( Don't count on TV channels living from commercials to tell you when to skip the commercials :) > > Next try: there is a VPS field in the VB__data_descriptor in the > Program Map Table (PMT). Sounds great, but how to get this table? AFAIK, you have to tell the DVB driver to include this table. It has a specific PID (something between 0x01 and 0x10, and this ID can be found in the I-don't-remember-its-name packet type whose PID is 0x00. > So, if someone has some time to dig deeper into this, please let me > know. I con provide some docs about TS and PSI, but there are many > more docs free on www.etsi.org. > > Anyone? Would be a cool feature! I'll stick to my heuristic filter, it worked well on at least one movie I recorded some time ago. The only thing is that the PTS is reset in the middle of the movie, and my TS seek functions doesn't work well after that. PTS resets suck, they are trouble :( Matthieu -- (~._.~)Matthieu Weber - Université de Jyväskylä (~._.~) ( ? )email : [EMAIL PROTECTED] ( ? ) ()- -() public key id : 452AE0AD ()- -() (_)-(_) "Humor ist, wenn man trotzdem lacht (Germain Muller)" (_)-(_) --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freevo-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-users
[Freevo-users] Better DVB support (C programmers needed)
Hi, same subject, different content. Besides timeshift, I want to watch a show when it starts. Sounds simple, but programs don't start at the given second. So I record 5 min earlier and stop 5 minutes after the end. But I want to start watching when the show starts, or even better, auto skip commercials. I did some digging on a recorded ts from mplayer and xine. Both contain only the two streams from video and audio. The TS IS don't change (and shouldn't). The PES (or PS?) inside it also has an id, also no change. The mpeg video and audio also has an id and -- no change. So the recorded stream is useless to get this information. There is meta information (PSI) on the channel, tools like tv_grab_dvb use them to get the epg. Again, some digging: the epg has a status field: running, running in some secs, running later, pause. Great. But the information is wrong :-( Next try: there is a VPS field in the VB__data_descriptor in the Program Map Table (PMT). Sounds great, but how to get this table? So, if someone has some time to dig deeper into this, please let me know. I con provide some docs about TS and PSI, but there are many more docs free on www.etsi.org. Anyone? Would be a cool feature! Dischi -- The Second Law of Thermodynamics: If you think things are in a mess now, just wait! -- Jim Warner --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freevo-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-users
Re: [Freevo-users] Better DVB support (C programmers needed)
On Fri, 2004-06-25 at 11:31, Dirk Meyer wrote: > Hi, > > yesterday I played with three tv players supporting dvb to find the > right one for Freevo. All players have problems I want to have > removed. So here a list of what I found out: > > 1. mplayer >+ good output (many vo modules) >+ support to add infos on the screen with bmovl >- no channel switching during runtime >- no live pause >- no seek back while watching > > 2. xine >+ also a wide range of output >- bad channel switching during runtime >- no live pause >- no seek back while watching > > 3. vdr >+ good channel switching during runtime >+ live pause >- hard to control from inside Freevo >- no seek back while watching >- doesn't work with our recordserver > Not knowing exactly what i'm talking about, i'd like to make a suggestion/question. Sorry if this is totally irrelevant. But how about using libsoftmpeg (http://linuxtv.org/libsoftmpeg/)? It seems like it's designed as a library for this use and although as i understand it's still very much alpha code, couldn't it be useful/used? just a thought, juhis --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freevo-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-users
Re: [Freevo-users] Better DVB support (C programmers needed)
On Mon 28.06.2004 at 11:55:09AM +0300, Matthieu Weber wrote: > Besides, I played with the seek function for TS streams, and now I can > seek to precisely whatever position I want. The same modifications can > be applied to the PS stream seek function in mplayer. And the patch is here: http://www.mit.jyu.fi/~mweber/leffakone/software/mplayer/MPlayer-1.0pre4-TS_seek.patch It should apply correctly, but I'm not sure, since I ripped it off another, bigger one. Use patch -p1 < blablabla.patch inside the MPlayer-1.0pre4 directory. > And I also managed to get DVB SPU subtitles displayed in mplayer (but > only when the source stream is a TS, because I haven't implemented any > autodetect of subtitle type for PS streams). It's there, if you care to test: http://www.mit.jyu.fi/~mweber/leffakone/software/mplayer/MPlayer-1.0pre4-DVB_subtitles+TS_seek/ It contais the above one, same command applies to install it. It's probably useful only to Finnish people, since it is the only country having DVB-T and using subtitles extensively. Matthieu -- (~._.~)Matthieu Weber - Université de Jyväskylä (~._.~) ( ? )email : [EMAIL PROTECTED] ( ? ) ()- -() public key id : 452AE0AD ()- -() (_)-(_) "Humor ist, wenn man trotzdem lacht (Germain Muller)" (_)-(_) --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freevo-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-users
Re: [Freevo-users] Better DVB support (C programmers needed)
On Fri 25.06.2004 at 10:31:16AM +0200, Dirk Meyer wrote: > yesterday I played with three tv players supporting dvb to find the > right one for Freevo. All players have problems I want to have > removed. So here a list of what I found out: > > 1. mplayer >+ good output (many vo modules) >+ support to add infos on the screen with bmovl >- no channel switching during runtime not true. It crashes my box sometimes, it is slow like hell, but it works (read mplayer's manual, the input section about slave mode). Btw, I wonder why Freevo is (was?) using a v4lzap (or whatever the name) program to change the channel, rather than mplayer's own function?) >- no live pause I played with Thomas' patch, and it works great (except when the thingy crashes, but that can be fixed :) I use a modified version of tzap to record either to a file, or to the timeshift buffer. >- no seek back while watching Works with Thomas' patch. Besides, I played with the seek function for TS streams, and now I can seek to precisely whatever position I want. The same modifications can be applied to the PS stream seek function in mplayer. And I also managed to get DVB SPU subtitles displayed in mplayer (but only when the source stream is a TS, because I haven't implemented any autodetect of subtitle type for PS streams). > So we have too many '-' in all players and no one can seek backwards. > One idea would be to hack some support of the missing features in the > player. I looked at the code and adding live pause to xine shouldn't > be too hard. Adding anything to mplayer doesn't look easy. And vdr > isn't written to be controlled by Freevo at all. Adding things to mplayer is not that hard either (once you have spent several hours tearing your hair off wondering wtf... :) > Some people wrote that they use tzap in combination with ts2pes to do > the recording. These tools are very small and maybe we can reuse the > source to build some tv app on our own. That isn't too hard if we use > mplayer or xine to do the real work. I suppose you mean PS, not PES? PES is not a multiplexed stream, PS and TS are. Is there really a need to convert the TS to a PS ? I've read that someone here is allergic to TS, but is there any real reason for that? It is not much bigger than PS (1% or something). The one thing which is annoying, is the timestamps that don't start at 0, but this could be changed also maybe. > My design: > > o We merge tzap (and it's brothers szap and czap) with ts2pes. The > result should be an application that get's a channel, converts the > ts into ps and put it into a fifo. Or a file, or the timeshift buffer. > o We use mplayer to read from that fifo. By that, we have complete > control over the ts and don't have to care about displaying. > > o The new app (let's call it tzap2pes for now) starts mplayer in slave > mode and has slave mode on it's own. Now the new app can control > mplayer and can be controlled itself by Freevo. I have thought about such a design already. This could be actually implemented in Freevo, Freevo being the glue between tzap2ps and mplayer. The same tzap2ps could then be used for recording digital TV to the disk (instead of mencoder). > o Now the fun part: > - if we press PAUSE, tzap2pes starts dumping the steam to a file and > also pauses mplayer. > - on resume, tzap2pes still dumps the stream to a file, but also > sends the recorded stream to mplayer > - on channel change, tzap2pes switches the channel and mplayer > doesn't even have to know Why not use live TV all the time, with a fixed-size buffer? OK, we are limited in time, but it would be easier than your design. > o The advanced setup: > If we have an application like the one above, we have fast channel > switching, complete control and live pause. To make an even better > app, we could add the following stuff: > - On PAUSE, don't pause mplayer, just send a still image to the fifo. Doesn't work: the fifo contains a video packet (made of 12 images), not one single image. mplayer will not comply. Pausing mplayer is the only solution. Your solution requires video decoding inside tzap2ps. > - Always save the stream and on seeking, send the needed stuff into > the fifo for mplayer. Maybe we have to rewrite some timestamps for > that. No *need* to rewrite the timestamps, but it would be nice to have the movie starting at 0:00 instead of whatever else. However, mplayer has an inside timer that starts at 0, I planned to hack mplayer so that this timer is displayed instead of the pts while watching a TS. > - Scan the ts while getting it for more information like EPG Support subtitles (done already). > - Support recording streams > - Do not use one file for live pause, use a set of files. E.g. start > writing to dump0001 and when this file is 50 MB, move on the > dump0002. When dump0003 is the one tzap2pes sends to mplayer, we > could remove dump0001. That
Re: [Freevo-users] Better DVB support (C programmers needed)
On Fri 25.06.2004 at 11:25:09AM -0400, Chris Griffiths wrote: > > > > I am working on a streamdev-client plugin for Freevo to talk to > > streamdev-server of VDR. Even without this I can watch TV from VDR > > through Freevo using mplayer and a URL for each channel. The only > > problem here is slow channel switching because mplayer wants to buffer > > the new stream. > > Maybe I'm being too simplistic here, but won't a 'mplayer --nocache' or > at least a very small cache stop mplayer from buffering? >From my experience, mplayer -nocache dvb://whatever fails after some time. -cache 1024 helped a lot. The problem is that it reads a bit of the stream to detect what is in the stream (audio and video, subtitles are dynamic). Matthieu -- (~._.~)Matthieu Weber - Université de Jyväskylä (~._.~) ( ? )email : [EMAIL PROTECTED] ( ? ) ()- -() public key id : 452AE0AD ()- -() (_)-(_) "Humor ist, wenn man trotzdem lacht (Germain Muller)" (_)-(_) --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freevo-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-users
Re: [Freevo-users] Better DVB support (C programmers needed)
Chris Griffiths wrote: I am working on a streamdev-client plugin for Freevo to talk to streamdev-server of VDR. Even without this I can watch TV from VDR through Freevo using mplayer and a URL for each channel. The only problem here is slow channel switching because mplayer wants to buffer the new stream. Maybe I'm being too simplistic here, but won't a 'mplayer --nocache' or at least a very small cache stop mplayer from buffering? The thing is I think mplayer needs a decent amount of cache to acheive smooth playback here, at least I have seen this in the past. I will test with no cache and see how it does. -Rob --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freevo-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-users
Re: [Freevo-users] Better DVB support (C programmers needed)
> > I am working on a streamdev-client plugin for Freevo to talk to > streamdev-server of VDR. Even without this I can watch TV from VDR > through Freevo using mplayer and a URL for each channel. The only > problem here is slow channel switching because mplayer wants to buffer > the new stream. Maybe I'm being too simplistic here, but won't a 'mplayer --nocache' or at least a very small cache stop mplayer from buffering? - Chris --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freevo-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-users
Re: [Freevo-users] Better DVB support (C programmers needed)
Dirk Meyer wrote: Hi, Hi Dischi, yesterday I played with three tv players supporting dvb to find the right one for Freevo. All players have problems I want to have removed. So here a list of what I found out: 1. mplayer + good output (many vo modules) + support to add infos on the screen with bmovl - no channel switching during runtime - no live pause - no seek back while watching Thomas Schueppel made a patch for mplayer that let you to live pause. We could update it and work on that. 2. xine + also a wide range of output - bad channel switching during runtime - no live pause - no seek back while watching Actually the input_pvr plugin in xine-lib does live pause and timeshifting. More on that later... 3. vdr + good channel switching during runtime + live pause - hard to control from inside Freevo - no seek back while watching - doesn't work with our recordserver I am working on a streamdev-client plugin for Freevo to talk to streamdev-server of VDR. Even without this I can watch TV from VDR through Freevo using mplayer and a URL for each channel. The only problem here is slow channel switching because mplayer wants to buffer the new stream. I am hoping to work around this with a VTP (Video Transfer Protocol) streamdev-client in Freevo (as oposed to HTTP). So we have too many '-' in all players and no one can seek backwards. One idea would be to hack some support of the missing features in the player. I looked at the code and adding live pause to xine shouldn't be too hard. Adding anything to mplayer doesn't look easy. And vdr isn't written to be controlled by Freevo at all. Ok, about xine. One of my beefs about xine is how input_pvr is implimented. Using a ivtv or wintv pvr-2/350 card you can timeshift live tv in xine with a pretty OSD and it works. The problem here is they put this timeshifting layer right in the pvr plugin insted of having it as a seperate plugin available for ALL incomming streams. It would be wonderful to timeshift any stream comming from stdin, a fifo, a url, etc. Some people wrote that they use tzap in combination with ts2pes to do the recording. These tools are very small and maybe we can reuse the source to build some tv app on our own. That isn't too hard if we use mplayer or xine to do the real work. My design: o We merge tzap (and it's brothers szap and czap) with ts2pes. The result should be an application that get's a channel, converts the ts into pes and put it into a fifo. o We use mplayer to read from that fifo. By that, we have complete control over the ts and don't have to care about displaying. I like this design of having at least two layers, one to gather the input and feed it somewhere, another to pick it up and timeshift it. o The new app (let's call it tzap2pes for now) starts mplayer in slave mode and has slave mode on it's own. Now the new app can control mplayer and can be controlled itself by Freevo. o Now the fun part: - if we press PAUSE, tzap2pes starts dumping the steam to a file and also pauses mplayer. - on resume, tzap2pes still dumps the stream to a file, but also sends the recorded stream to mplayer - on channel change, tzap2pes switches the channel and mplayer doesn't even have to know o The advanced setup: If we have an application like the one above, we have fast channel switching, complete control and live pause. To make an even better app, we could add the following stuff: - On PAUSE, don't pause mplayer, just send a still image to the fifo. - Always save the stream and on seeking, send the needed stuff into the fifo for mplayer. Maybe we have to rewrite some timestamps for that. - Scan the ts while getting it for more information like EPG - Support recording streams - Do not use one file for live pause, use a set of files. E.g. start writing to dump0001 and when this file is 50 MB, move on the dump0002. When dump0003 is the one tzap2pes sends to mplayer, we could remove dump0001. This is where I disagree slightly. I think the player side should handle all aspects of timeshifting. Perhaps we use a ringbuffer and the stream collecting portion (tzap, mplayer -dumpstream, mp1e, cat /dev/video |, whtever) just sits there dumping its input to a pipe or fifo. The player (or 3rd layer for buffer) collects the data and puts it into the buffer, expiring old data as the buffer fills, It knows the start/end/reading positions of the buffer. The player layer reads from the buffer and knows about the different positions so it doesn't go past either end and knows its own pause position, etc. Having these layers means timeshifting support in Freevo is not tied to only one type of television and can be used with multiple streams from DVB, pvr-250, URLs, mp1e or ffmpeg for analoge tv. I think this is where xine went wrong. I mentioned that Thomas made a patch for mplayer to to this wort of thing but we could also
[Freevo-users] Better DVB support (C programmers needed)
Hi, yesterday I played with three tv players supporting dvb to find the right one for Freevo. All players have problems I want to have removed. So here a list of what I found out: 1. mplayer + good output (many vo modules) + support to add infos on the screen with bmovl - no channel switching during runtime - no live pause - no seek back while watching 2. xine + also a wide range of output - bad channel switching during runtime - no live pause - no seek back while watching 3. vdr + good channel switching during runtime + live pause - hard to control from inside Freevo - no seek back while watching - doesn't work with our recordserver So we have too many '-' in all players and no one can seek backwards. One idea would be to hack some support of the missing features in the player. I looked at the code and adding live pause to xine shouldn't be too hard. Adding anything to mplayer doesn't look easy. And vdr isn't written to be controlled by Freevo at all. Some people wrote that they use tzap in combination with ts2pes to do the recording. These tools are very small and maybe we can reuse the source to build some tv app on our own. That isn't too hard if we use mplayer or xine to do the real work. My design: o We merge tzap (and it's brothers szap and czap) with ts2pes. The result should be an application that get's a channel, converts the ts into pes and put it into a fifo. o We use mplayer to read from that fifo. By that, we have complete control over the ts and don't have to care about displaying. o The new app (let's call it tzap2pes for now) starts mplayer in slave mode and has slave mode on it's own. Now the new app can control mplayer and can be controlled itself by Freevo. o Now the fun part: - if we press PAUSE, tzap2pes starts dumping the steam to a file and also pauses mplayer. - on resume, tzap2pes still dumps the stream to a file, but also sends the recorded stream to mplayer - on channel change, tzap2pes switches the channel and mplayer doesn't even have to know o The advanced setup: If we have an application like the one above, we have fast channel switching, complete control and live pause. To make an even better app, we could add the following stuff: - On PAUSE, don't pause mplayer, just send a still image to the fifo. - Always save the stream and on seeking, send the needed stuff into the fifo for mplayer. Maybe we have to rewrite some timestamps for that. - Scan the ts while getting it for more information like EPG - Support recording streams - Do not use one file for live pause, use a set of files. E.g. start writing to dump0001 and when this file is 50 MB, move on the dump0002. When dump0003 is the one tzap2pes sends to mplayer, we could remove dump0001. I want to spend most of my free hacking time on Freevo. So I need some people (maybe two) to do this. The people need to have some C programming skills and should not be afraid of stupid protocols like ts. As doc I have a pdf about TS and PES and we should use the sources of tzap and ts2pes. For cool stuff like EPG and teletext, we could read some vdr source. Comments? Questions? Better ideas? Volunteers? Dischi -- None of the ideas expressed above are actually mine. They are told to me by Luthor and Ferdinand, the five inch tall space aliens who live under my desk. In return for these ideas, I have given them permission to eat any dust bunnies they may find under there. --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freevo-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-users
