[MPlayer-users] .TY+ parsing / junk data not skipped over

[Mike Hodson]

On 9/13/07, Reimar Döffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de> wrote:

> Actually, with ty you have to split at a 128kB boundary...

Ah ok.  I split on a 1 meg boundary, so by default that should be 128KB aligned.
(dd bs=1m skip=998 count=5)

> Well, rewrite the demuxer to make it less of a mess?
> You could help with this by
> 1) providing also the first 4 MB or so of a .ty file
> 2) Do the same for a .tmf file
> because currently our samples server doesn't seem to contain even a
> single sample, which makes it near impossible to fix things without
> having it break left and right.

I had interesting difficulties with capturing a "short" clip to test.
As I wanted to provide you guys with an entire .ty+ file, so as to
give an example of XML appended to it, I decided to record a small
clip to provide a file that was complete.

The issue I ran into: It appears that doing a manual "live tv"
recording of the current show produces a different file than a
"scheduled" recording.

I tried multiple times to do a "record live tv" and then stop after a
few seconds, upto 1 minute.  The files produced were between 8 and 36
megs in size.  None of them played properly. On the smaller end, it
wouldnt find anything, but in the 36 meg file it was able to find the
audio.

Doing some investigation, I noticed in tivoweb plus' info for the
recordings that there was a status of "Converted from live."  Based on
my inability to get a 1 minute 'live' recording to even play back, I
tried scheduling a 1 minute recording.  This produced a 'normal' file
that is instantly picked up / playable, albeit with the telltale audio
desync for the first 10 seconds and possibly more when skipping back
and forth.

"Converted from live" verbose output: http://pastebin.com/f7ab16137
"Scheduled" verbose output: http://pastebin.com/f64618fa5

The 36 meg "audio only" playback output, and files i tried, have been
cleared out by more of my testing but if you would like me to
reproduce, I would be able to.

Note, these are coming from a DirecTV Tivo not a standalone, so the
mpeg bitstream was originally encoded by DTV.  I am not certain, but
inferring from posts on the tivo discussion forums standalone
recordings differ slightly, possibly with regard to AC3 streams on D*
premium movie channels, but it may be other things too; I simply don't
know for certain.

I tried going to ftp.mplayerhq.hu and didn't see an incoming dir  as
normal, but trying ftp1.mplayerhq.hu showed the .  If you want them
somewhere else, let me know.

The files were uploaded as "scheduled.ty+" "liverec.ty+" and also
included is the scheduled.tmf file

Within the .tmf file (which is basically a .tar archive) you get a
video stream .ty file and metadata as separate xml file. The extracted
.ty from this archive will -not- contain the "ty+" medatada embedded
into the end of the file. (diff -a confirms that the footer is all
that has changed)

Also, unless you extract the stream file from the .tmf archive,
mfs_ftp does not actually serve up different files when it comes to
the "ty" vs "ty+" extensions; they are all ty+ format with metadata.
However, other tools, like 'tytool' produce simple .ty files without
metadata.

Mike