[MPlayer-dev-eng] .TiVo file support

[Nico Sabbi]

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?

  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

Does it really mean where I am in
> the buffer, and as such its value is irrelevant to whomever gets the
> packet?
> 
> So in a pseudo-code kind of thing,
> while not eof
>  make new packet
>  dp->pos = 0;

dp->pos is set in new_demux_packet()

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

dp->len-8

>   dp->buf[dp->pos++] = byte;
>  ds_add_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

  In other words,
> should I try to keep MPEG packets in one piece in a packet, or should I
> try to optimize filling the mplayer packet to 2k ignoring the MPEG packet
> boundaries?

ignore the packet boundaries and avoid resize_demux_packet() as much 
as you can
> 
> 
> 
>>>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
-- 
"Without a frontend, mplayer is useless" - someone in mplayer-users