[MPlayer-dev-eng] .TiVo file support

[Jeremy Drake]

Sorry, my email alias is broken so I am having to work off the archive.  I
am not getting emails from the list anymore and have to poll the archive.
Darn hosting provider broke something...

I rewrote my hack to use dp->pos vs dp->flags.  I did not feel bad about
using that tho, as I reset it to 0 before calling ds_add_packet...

On Thu, 14 Dec 2006, Nico Sabbi wrote:

> Jeremy Drake wrote:
>
> > 4 of what?  I don't understand.
>
> 4 tivo signatures in a row (spread among N tivo packets).
> I assume the signature repeats, doesn't it?

No, the signature is at the beginning of the file.  Other than the header,
it looks exactly the same as an MPEG file.  Could I call the probe func
for mpeg too?  Is that a good idea?

>   There are not 4 FOURCC values in a row.
> > I could try reading in the file header completely and see if it makes
> > sense, but I'm not sure how much of it I can verify because the entire
> > format is reverse engineered, so I don't know exactly what values where
> > are normal...
> >
> >
> >>I didn't notice this 1-byte stuff. It sucks indeed.
> >>buffer the byte read in dp->buf+dp->pos until you don't have
> >>any more space
> >
> >
> > So did I misinterpret the meaning of dp->pos?  I thought it was for the
> > position of the packet in the stream.
>
> dp->pos is the position of the last written byte in the demux_packet,
> but it must never exceed dp->len-8

That does not agree with the comment in demuxer.h.  And from the code, the
+8 size you are talking about is not included in dp->len, only in the size
allocated.

> dp->pos is set in new_demux_packet()

I don't like to trust initialization, but I took that out... ;)

> >  foreach byte while dp->pos < dp->len
>
> dp->len-8

Don't think so, see above and code for resize_demux_packet

> it's fine
> >
> > With the handled parts put in packets by themselves already, when I find
> > one put in the buffered data and start over after, or should I try to
> > concat it into the same packet with the buffered stuff?
>
> demux_mpg will see a stream of bytes in any case (that's why
> you call new_ds_stream() in your open() function), thus it's
> indifferent, especially in this case where 2 demuxers are piped;
> better choose the easiest way
>
> ignore the packet boundaries and avoid resize_demux_packet() as much
> as you can

I did it the easier way, which was to tack any of the stuff I would have
done the 1 byte stuff with at the beginning of the packets that were
handled.  Turns out the stuff that was not handled was just the 00 00 01
at the beginning of the mpeg packets and the 0xba packets (what are those
for again?).

> >>>Good.  Now I need some help with the seek and control functions.  They
> >>>should be able to behave like the MPEG ones, at least at first.
> >>
> >>seek() should already work with piped demuxers, but control() ones don't. It
> >>needs to be implemented from scratch, but you can leave them
> >>alone for the time being
> >
> >
> > As written, I cannot seek().  Is there something I need to do?  Do I need
> > to put in a seek function in the info struct, and hand off to the MPEG
> > seek somehow?
>
> I'll recheck the code

Please let me know, this would be nice at least to seek forward.  And to
get the progress bar to know where we are in the stream and where the end
is.  This would make this little endeavour provide more features than
'./tivodecode | mplayer -' already did.

-- 
One is not superior merely because one sees the world as odious.
		-- Chateaubriand (1768-1848)