TIVO_PART_LENGTH in demux_ty.c needs to be variable

[mplayer@…]

I own a DirecTiVo, and the ty files that come from it have PART sizes
of 0x10000000 instead of the 0x20000000 #define in demux_ty.c. This
means that files that are smaller than two PARTs (which play correctly
since the logic for reading those doesn't work correctly so it just
goes by the overall file size) end up being shown only up to the end
of the first PART, i.e, demux_ty.c's logic believes that only the first
0x10000000 bytes of the file have anything in it. Obviously the
0x20000000 value works for other people, so perhaps either a flag
needs to be added to opt for a different PART size, or something. I've
modified my local copy and things work fine now for me. I'm mostly
leaving this note as full disclosure of changes made.

[mplayer@…]

Additional details: My device is a DirecTV Series 2 DSR 704 running
OS revision 6.3e-01-2-101. I use TyTool10r4 but that should matter
since I believe the PART size is a function of the MFS.

[reimar]

To improve TiVo support we most of all need samples. This also applies to the known problem (a few broken frames in the middle) with files longer than ca. 2 hours.

[mplayer@…]

Hunt for chained PES headers at the end of non-TMF ty files

[mplayer@…]

Let me know where you want sample files put. It turns out that things are
a little more straightforward, and doesn't need the wholesale change I
previously mentioned. It's okay if you start looking at for a PART header
0x20000000. If you don't find one, the current code seems to do something
rational anyway. If you DO find one, however, you'll get a number of
chunks from the PES header. All the code needs to do is realize that
there might be another PES header at offset (AV_RB24(chunk + 12) * CHUNKSIZE) + CHUNKSIZE. If there is, that also needs to be added to tivo->size. This needs to be repeated onwards to the end of the file. I don't see a downside to doing
this check.

[reimar]

Samples go to ​ftp://upload.mplayerhq.hu/MPlayer/incoming
Note: this is write-only, so do not be surprised that it always seems to be empty.
I do not like all this size calculation stuff at all, and esp. seeking through the whole file is a rather bad thing to do if it can be avoided.
I still have hopes that someone will soon implement a nice, clean demuxer for those files as part of FFmpeg, but I fear those are false hopes :-)

[mplayer@…]

Well, good luck with not seeking to find the real file size. Personally,
I don't really see the point in using anything other than the real file
size. Perhaps that's a problem with ty files created by other recorders.
For sure though, the code as it stands now just exits with "end of file"
early on my ty files. I'm uploading "Top Gear-02-25-08-1.ty" as we speak.