[Freevo-users] dvb support in xine (was: Better DVB support)

[Dirk Meyer]

Note: added Cc to Daniel. Maybe forward to xine-devel?

Rob Shortt wrote:
 Dirk Meyer wrote:
 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...

[...]

 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.

Do the xine people know about this design problem? You are right,
instead of adding timeshift to input_dvb.c, it should be added as
extra layer. 

[...]

   - 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 fix xines
 behaviour here. Xine also has some cool features like saving what you
 just watched (as long as its still in your buffer).

So what do we need from a player, e.g. xine?

o Read from fifo to bypass dvb://, pvr:// or whatever. We could
  also use dvb://, but I like to 'see' the stream before xine gets it
  to read EPG and other fun stuff.

o The player needs read the fifo and save it into a tmp file (or set
  of tmp files) when playing is behind the stream (live pause). Auto
  remove the tmp files when not needed anymore.

o Save some MB of the just played stream to seek backward at least 1
  min. Make it possible to seek forward until we are in realtime
  again. 


Dischi

-- 
To know recursion, you must first know recursion


---
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] dvb support in xine

[Rob Shortt]

Dirk Meyer wrote:
Rob Shortt wrote:
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.

Do the xine people know about this design problem? You are right,
instead of adding timeshift to input_dvb.c, it should be added as
extra layer. 
James Courtier-Dutton touches on this here:
http://sourceforge.net/mailarchive/message.php?msg_id=5879255
http://sourceforge.net/mailarchive/message.php?msg_id=5394185  (Item #5)
I have seen the occaisional request similar to mine on their mailing 
lists as well.  I think they would be receptive to changes here but 
someone else may have to do the bulk of the work.

So what do we need from a player, e.g. xine?
o Read from fifo to bypass dvb://, pvr:// or whatever. We could
  also use dvb://, but I like to 'see' the stream before xine gets it
  to read EPG and other fun stuff.
Well for xine we wouldn't have to impliment the timeshift buffer in 
Freevo but instead:

xine_input_plugin - xine_timeshift_plugin - xine_internals - 
xine_output_plugin

The xine_input_plugin part could take care of regular V4L, dvb://, 
pvr://, stdin, rtsp, http, etc.  We could select from one of these input 
methods or use a pipe or fifo to a stdin type input plugin.

I think changing xine-lib would save us much hassle in Freevo.
BTW, as for seeing the DVB stream before another app gets it isn't 
(shouldn't be) a problem.  I think an outside app or Freevo daemon 
plugin could attach a filter to the EIT PID getting any infos it needs 
for EPG, now/next.  We can display this info using a player's OSD interface.

-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