[MPlayer-dev-eng] .TiVo file support

[Nico Sabbi]

Jeremy Drake wrote:

> 
> 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?

no

>>>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. 

it's a very misleading and false comment

  And from the code, the
> +8 size you are talking about is not included in dp->len, only in the size
> allocated.
> 

this is true; you can fill the packet while(n<dp->len)

> 
>>dp->pos is set in new_demux_packet()
> 
> 
> I don't like to trust initialization, but I took that out... ;)

you had better trust it

> 
> 
>>> foreach byte while dp->pos < dp->len
>>
>>dp->len-8
> 
> 
> Don't think so, see above and code for resize_demux_packet
> 
as above

> 
>>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?).

mpeg pack header



-- 
"Without a frontend, mplayer is useless" - someone in mplayer-users