tyremux a GPLed TyStream demuxer and to be remuxer

[olaf_sc]

tydemux/demux - the future and present

Demuxing, transcoding and remuxing and external muxing

This is to be a place where we can all trade ideas, discuss the tydemux code base (and the up comming tyremux) and MPEG coding in general. It's GPLed application so you are all welcomed to partisipate/develop or just look at the code in general. Let it inspire so that ideas, code and every thing flows freely.

NOTE: There is however some rules for this thread. The rules are for this thread, not the forum. If you want to discuss things deemed off limits here make your own threads and set your own rules. But if you decide to participate here then please follow the guidelines.

The rules for this thread:

1- Leave the flames and arguments elsewhere... Again I am interested in getting things working better and moving forward

2- While we discuss any tools dealing with mux'ing or viewing or editing MPEG2 files or TyStreams... but lets keep the focus on tydemux/remux and things that are that are built for TiVo.

3- No discussion of extraction. This thread is about demuxing, remuxing, transcoding and external muxing of Tivo TyStreams files to MPEG-2.

4- Feel free to discuss various OS wishes/desires. At some point we should support all of them or at least as many as is possible. However be moderate and if you can code please help out - download the source code and send patches.

5- It's a technical/coding and to some extent usage thread - hence if you want to just talk in general think twice before posting.

6- Don't post applications without the source, this thread is following the Open Source guide lines.

Cheers Olaf

[olaf_sc]

LATEST VERSION IS 0.4.2

Get it here (http://www.dealdatabase.com/forum/showthread.php?s=&postid=79714&highlight=tydemuxW0.4.2.zip#post79714).


It's time for a new release of tydemux - I hope you will find it useful!

It's a nearly complete rewrite and it should be much more robust now. It also has a lot more functionality that I think you will find very handy.

The current features of tydemux is:
---------------------------------------

Extraction of video and audio (both MPEG and AC3/a52) from all Tivo types made - SA Tivo Series 1, SA TIVO Series 2, DTivo Series 1 and UK Tivo - using software revision 1.3 and up. NOTE: DTivo Series 2 should in principle be supported but I have not yet be able to obtain a TyStream from it.

Tivo Type/Series probe you don't need to worry about what type your TyStream is. tydemux will detect it and use the right engine to demux the audio and video.

Audio probe, you don't need to worry about what type of audio a recordings has. tydemux will probe the whole TyStream, determine audio type and skip to the first chunk that has that type of audio.

TyStream will repair the TyStream if it detects holes/gaps in the TyStream. Up on detection of a hole/gap tydemux it will align video and audio in such way that there is no or very ittle loss of sync. Further more tydemux will fix the start and end of the hole/gap in such way that Video and Audio doesn't deteriorate in quality.

tydemux is minimizing the Audio/Video sync offset. At the end of the execution it will tell you the offset in milli seconds.


The tydemux_W_0.3.0.zip holds Windows binaries and sources/project files from MS Visual Studio 6.x.

The tydemux_L_0.3.0.zip holds Linux_x86 binaries and source/make files for gcc.

While both has the exact same codebase I still think it's easier to post to different packages.

NOTE: I'm using the latest as in CVS version of mplex from mjpeg-tools as a reference muxer for my streams.

Mplayer is my std mpeg video and mpeg program stream player. While I use mpg123 as reference player for mpeg audio files and a52dec as reference player for ac3 audio files.


Cheers Olaf

[olaf_sc]

Linux binaries and sources

[olaf_sc]

To make this thread as useful as possible we need documentation. Hence I have gatherered some docs that I hope you will find useful. It's MPEG, AC3 and TyStream documentation. The latter one is a write in progress by me in StarOffice and Word format. It's currently describing the TyStream syntax.


tystream.zip == tystream docs
mpeg-1.zip == MPEG-1 part 1, 2 and 3
mpeg-2.zip == MPEG-2 part , 2, 3 and 4
a52.zip == AC3 specs

[olaf_sc]

MPEG-1 part 1, 2 and 3

[olaf_sc]

MPEG-2 part 1, 2, 3 and 4

[olaf_sc]

AC3 specs

[racingclub]

I've tried your Windows Binary with a ty stream extracted from a UK SA TiVo.

With a 2.5gb stream I get the error as soon as I run the commandline - 'TyStream is to small to demux We need at least 40 chunks'

With a 400mb stream the process gets so far as to start the demux process but then crashes with a Windows GPF

[olaf_sc]

Hello

Originally posted by racingclub
I've tried your Windows Binary with a ty stream extracted from a UK SA TiVo.

With a 2.5gb stream I get the error as soon as I run the commandline - 'TyStream is to small to demux We need at least 40 chunks'


tydemux doesn't yet support filesizes over 2GB, it's pretty trivial but I thought we better get it working 100% before we enable it.


With a 400mb stream the process gets so far as to start the demux process but then crashes with a Windows GPF

It would be really nice if you could upload this stream to my ftp server.
ftp://66.121.15.34/UK/ so I can see why it makes tydemux crash.

I have been testing a lot of streams but the fact is that I only have a few very small UK streams.


Cheers Olof

[laserfan]

I tried this quickly on a 340Mb ty this a.m. and while I only did a demux, both the audio and the video seemed to play OK separately. My Win Media Player crashed right away on the video, but maybe I have an old version (7.01). But it appeared to play fine w/CyberDVD though there was a strange loop it went into at the end (it didn't just stop playing, it looped around the last few frames continuously).

Anyway I will play some more as it worked pretty well for me at least on the surface.

US SA Tivo v3.0

I will upload a file to your ftp site if you want one this big? It's a 1/2 hour program.

[olaf_sc]

Hello

Thanks for your reply, please go a head and upload it to ftp://66.121.15.34/SA_3x/ so I can see what is going wrong. It might be a Windows only error. I'm doing more or less every thing under Linux so I need bug testing under Windows.

Anyways I will try to solve this problem and the one with the UK stream as quickly as possible.

Cheers Olaf



Originally posted by laserfan
I tried this quickly on a 340Mb ty this a.m. and while I only did a demux, both the audio and the video seemed to play OK separately. My Win Media Player crashed right away on the video, but maybe I have an old version (7.01). But it appeared to play fine w/CyberDVD though there was a strange loop it went into at the end (it didn't just stop playing, it looped around the last few frames continuously).

Anyway I will play some more as it worked pretty well for me at least on the surface.

US SA Tivo v3.0

I will upload a file to your ftp site if you want one this big? It's a 1/2 hour program.

[AlphaWolf]

Olaf_SC: I would like to see converting an mpeg file to a tystream in the far future todo list, as this would be the other step necessary to be able to put whatever you want into your tivo.

Of course there would probably need to be a better understanding of tystream files first, so this would probably be a post 1.0 feature :)

[racingclub]

It would be really nice if you could upload this stream to my ftp server.

OK Olof - am uploading 'm.ty' to your UK dir :)

If I can be of help by providing more UK streams then I will more than happy to up them to you. :)

Keep up the great work!

[olaf_sc]

Hello,

Thanks for your feedback - the main problem coverting a mpeg to a TyStream is that we don't have all the data about the master chunk (Chunk 0) and that we don't understand the all of the data present in the record header.

If you have any further knowledge about the subject I very much welcome you to edit the TyStream document - it's currently doesn't cover the master chunk.

Cheers Olaf

PS: Yes, if I get the knowledge needed I will definitly implement it :)

Originally posted by AlphaWolf
Olaf_SC: I would like to see converting an mpeg file to a tystream in the far future todo list, as this would be the other step necessary to be able to put whatever you want into your tivo.

Of course there would probably need to be a better understanding of tystream files first, so this would probably be a post 1.0 feature :)

[olaf_sc]

Hello

Thanks and YES, please - I definitly need more UK streams!! Please go a head and upload the once you have or create new once :).

There is currently 19GB of free space in the ftp area so I don't think we will run out of space at once :).

Cheers Olaf

Originally posted by racingclub
OK Olof - am uploading 'm.ty' to your UK dir :)

If I can be of help by providing more UK streams then I will more than happy to up them to you. :)

Keep up the great work!

[artships]

Hey, Olaf!

Glad to see this tool right about now. For the last two weeks everything I've extracted from my SA tivo vsplits just fine, but the resulting audio contains stuff that makes TMPGEnc act like it's suffered a buffer overflow problem - Miscellaneous errors that don't make sense and occasionally even cause a TMPGEnc window to become an immovable black square on the screen. I think it's the audio because it also causes toolame and ssrc (optionally invoked from within TMPGEnc) to abort with something like "exception error".

I very much look forward to seeing how tydemux copes with my thus afflicted Andromeda episodes. And to seeing how they take to editing in TMPGEnc, too. I'll edit this with my findings tonight.

See results a few posts down.

John

[olaf_sc]

Hi,

Thanks for your support - it would be very nice if you upload one of those streams to my ftp server ftp://66.121.15.34/SA_3x/

This is no matter if it works or not, since it can be a particular way your Tivo is encoding this and it can be nice to have a look at the TyStream.


Cheers Olaf

Originally posted by artships
Hey, Olaf!

Glad to see this tool right about now. For the last two weeks everything I've extracted from my SA tivo vsplits just fine, but the resulting audio contains stuff that makes TMPGEnc act like it's suffered a buffer overflow problem - Miscellaneous errors that don't make sense and occasionally even cause a TMPGEnc window to become an immovable black square on the screen. I think it's the audio because it also causes toolame and ssrc (optionally invoked from within TMPGEnc) to abort with something like "exception error".

I very much look forward to seeing how tydemux copes with my thus afflicted Andromeda episodes. And to seeing how they take to editing in TMPGEnc, too. I'll edit this with my findings tonight.

John

[FreydNot]

My one and only short term feature request is inline audio frequency resampeling. This is a very important step in getting from an SA tystream (32k audio) to DVD compliant (48k audio).

Since the tystreams are very sensitive to being de-muxed and re-muxed, its hard to convert the audio externaly while keeping the sync.

[olaf_sc]

Hello FreydNot

It's on the Todo list for 0.4.0 (see todo list in the README). I allready had this working in an internal version of tydemux 0.2.1.

When 0.4.0 hits the streets you will both have internal remuxing and internal audio transcoding. The audio transcoding will handle all types of trancodings - e.g. AC3 to MPEG, MPEG to AC3, 32k to 48k, 48k to 44.1k etc...

Cheers Olaf

Originally posted by FreydNot
My one and only short term feature request is inline audio frequency resampeling. This is a very important step in getting from an SA tystream (32k audio) to DVD compliant (48k audio).

Since the tystreams are very sensitive to being de-muxed and re-muxed, its hard to convert the audio externaly while keeping the sync.

[AlphaWolf]

olaf_sc: sorry, I am not very advanced when it comes to all of this (my only knowledge about computers comes from tinkering I do, I haven't taken any programming courses or whatnot ever, in fact I am actualy working on a law degree :) ), so I can't help you much other than to come up with ideas. That said, I did have a thought, since its possible to extract the master chunk from MFS while the recording is in progress, wouldn't it help you guys further understand the master chunk by logging the changes to it every minute or so during the recording process? Or something like that?

[olaf_sc]

Hello,

That would be a good idea (extracting it while it's recording) - what would be even better is if you could extract it each time a new chunk is created along with that chunk. Then we could see exactly how it comes together.

Cheers Olaf

Originally posted by AlphaWolf
olaf_sc: sorry, I am not very advanced when it comes to all of this (my only knowledge about computers comes from tinkering I do, I haven't taken any programming courses or whatnot ever, in fact I am actualy working on a law degree :) ), so I can't help you much other than to come up with ideas. That said, I did have a thought, since its possible to extract the master chunk from MFS while the recording is in progress, wouldn't it help you guys further understand the master chunk by logging the changes to it every minute or so during the recording process? Or something like that?

[AlphaWolf]

hmm...you know, if you can get a PPC debugger of some sort that allows you to step through an already compiled programs operation, and use it on ele2pestripple, which creates tystreams from regular mpeg files, couldn't you do something like that?

[olaf_sc]

Yes, actually been thinking about doing that - however when I coded tydemux 0.3.0 I simply didn't have the time. The master chunk was in my view not a essential for a sucessful demux/remux.

On the subject of converting mpeg to tystream, I must say it's something I will do if I get help with at least the knowledge - specs for the tyrecord and tystream master chunk. If not then it's definitly beyond version 1.0 of tydemux/remux.

Cheers Olaf



Originally posted by AlphaWolf
hmm...you know, if you can get a PPC debugger of some sort that allows you to step through an already compiled programs operation, and use it on ele2pestripple, which creates tystreams from regular mpeg files, couldn't you do something like that?

[laserfan]

Originally posted by laserfan
I tried this quickly on a 340Mb ty this a.m...I had posted problems w/my SA version 1 stream, but I forgot the key issue: tydemux exited (crashed) at the end so I got no info about the audio offset. So the files appeared to demux OK but tydemux crashed.

I reported also a problem at the end w/the video part--I'm convinced it is a player problem only as it ran OK using DVD Station (w/my Hollywood Plus card).

I'm uploading my SA ty now & hope it gets up there OK as the connection is really slow.

[olaf_sc]

Hello Folks

Found the bug that made tydemux core dump at the end of the TyStream. Basically if the TyStream wasn't properly extracted and the last chunk has parts of it missing. Tydemux countinued to read out in thin air, not good :)

Anyways it's corrected and I have prepared a new release I just wait for laserfan to finish his upload so I can make a last test with his file. If nothing bad happes I will release 0.3.1 by the end of the evening.

Cheers Olaf

[artships]

Originally posted by olaf_sc Thanks for your support - it would be very nice if you upload one of those streams to my ftp server ftp://66.121.15.34/SA_3x/

This is no matter if it works or not
Alas, Olaf, it didn't work.
tydemux.exe -j 500 -i nw.ty -v nw2.m2v -a nw2.m2a > nw2.log resulted in a usage message.

tydemux.exe -i nw.ty -v nw2.m2v -a nw2.m2a resulted in, "Warning: Probe faild - specify audio type".

tydemux.exe -t2 -i nw.ty -v nw2.m2v -a nw2.m2a resulted in that grossly annoying WinXP message, "tydemux.exe has encountered a problem and needs to close."

Oh, and my copy bannered as "tydemux 0.2.1".

Running in an rxvt window courtesy cygwin and at a dos prompt, WinXP Home. I may have uploaded the first 450000 bytes of nw.ty - I can't tell, as a "150 directory listing" message is followed by "226 Tranfer done(but failed to open directory) (probably because I'm not supposed to be able to read anything there).

HTH

John

[olaf_sc]

Hello

If it banner as 0.2.1 then you are using a old and out dated version of tydemux please download the latest version of tydemux.

You will find it in the second post from the start in this thread.

Cheers Olaf


Originally posted by artships
Originally posted by olaf_sc Thanks for your support - it would be very nice if you upload one of those streams to my ftp server ftp://66.121.15.34/SA_3x/

This is no matter if it works or not
Alas, Olaf, it didn't work.
tydemux.exe -j 500 -i nw.ty -v nw2.m2v -a nw2.m2a > nw2.log resulted in a usage message.

tydemux.exe -i nw.ty -v nw2.m2v -a nw2.m2a resulted in, "Warning: Probe faild - specify audio type".

tydemux.exe -t2 -i nw.ty -v nw2.m2v -a nw2.m2a resulted in that grossly annoying WinXP message, "tydemux.exe has encountered a problem and needs to close."

Oh, and my copy bannered as "tydemux 0.2.1".

Running in an rxvt window courtesy cygwin and at a dos prompt, WinXP Home. I may have uploaded the first 450000 bytes of nw.ty - I can't tell, as a "150 directory listing" message is followed by "226 Tranfer done(but failed to open directory) (probably because I'm not supposed to be able to read anything there).

HTH

John

[artships]

Originally posted by olaf_sc
If it banner as 0.2.1 then you are using a old and out dated version of tydemux

Vexing, as that's what was in "tydemux_w_0.3.0.zip".

I uploaded part of the offending tystream to http://artships.com/nw.ty

Luck!

John

[olaf_sc]

Hmm, strange I just downloaded the tydemux_W_0.3.0.zip and execed it.

The banner says :

tydemux 0.3.0 usage:
tydemux [option] -i infile -a outfile_audio -v outfile_video
[snip]

Another indication that you use a old version is that you use the -j switch which isn't there in 0.3.0. Please try to download it again. Before you do the test make sure that you don't have a the old version in your path.

Cheers Olaf

PS: The uploaded file is a bit to small I need around 6MB to test it. Although your upload to my ftp did go just fine - you aren't supposed to see whats in there :).


Originally posted by artships
Originally posted by olaf_sc
If it banner as 0.2.1 then you are using a old and out dated version of tydemux

Vexing, as that's what was in "tydemux_w_0.3.0.zip".

I uploaded part of the offending tystream to http://artships.com/nw.ty

Luck!

John

[olaf_sc]

Hello Folks

- Tydemux 0.3.1 -

The example streams you send to me (thanks laserfan and racingclub) highlighted two minor bugs that can make tydemux crash.

1: Turncated chunks at the end of the TyStream
2: I was printing data from a released chunk hence I was reading data that was unavalible, not good.

Anyways it's fixed now and as usuall I will post two packages one for Windows and one for Linux.

Cheers Olaf

tydemux_W_0.3.1.zip == Windows
tydemux_L_0.3.1.zip == Linux

[olaf_sc]

The Linux version

(By misstake I uploaded a version with extensive debug output it's corrected now - one person downloaded that version - please download the updated zip)

[artships]

Originally posted by olaf_sc
Hmm, strange I just downloaded the tydemux_W_0.3.0.zip and execed it.

The banner says :

tydemux 0.3.0 usage:
Oops. You're right, it sure sounds like a PATH problem on my part. I should have checked that. I plead insanity, to which all the friends in my head can readily atest.

I'm looking forward to trying 0.3.1 tonight, Olaf. And so am I. And I'll upload a longer clip. Or, I will.

John

[racingclub]

0.31 seems to work on streams that crashed 0.30 - the resulting files muxed up OK & kept in sync (something I've never managed with vsplit) - nice one Olof!!!!

now just need to remove the 2gb limit & up the release to 1.0? :)

[olaf_sc]

Hello

Thanks for your (and others) feedback and support, the demuxing engine should be pretty solid in 0.3.x I habe been feeding it pretty nasty TyStreams that it still will manage to demux.

However we will most probably bump in to bugs that makes it crash. I'm talking about programming glitches not logical errors. I try to run tydemux in valgrind (a programing tool telling me when I do something ilegal) the problem is that it takes x10 as long to run tydemux in valgrind than stand alone. Hence I only run tydemux with valgrind on a half of my test streams.

The engine it self; does the demuxing by seeking start and end of all components, it will not assume that anything is aligned. Instead it takes the record type e.g. GOP header and does a seek for the start of it and a seek for the end of it. The in it extracts the the GOP header.

Doing it like this makes the engine much more rubust than a engine taking advantage of the fact that e.g. all video PES Headers in a TyStream are starting a byte zero in a TyRecord. See sometimes those assumtions aren't working and a "static" engine will fail. For those how are interested, take a look at the get_video.c file and you will see how my engine is working.

0.3.2 will be released shortly removing the 2GB limit on systems supporting it. However I will not jump to 1.0 :) it's still a lot of things to do.

I have started to code what will become tydemux/remux 0.4.0, the feature set planned for 0.4.0 is as follows:

Internal audio transcoding:
You will be able to transcode from AC3 to MPEG-II and vice versa. You will also be able to change the sample rate so it complies to either SVCD 44.1kHz or DVD 48kHz.

Internal remuxing:
Intrenal remuxing from TyStream to a std MPEG-2 program stream. This is the first step towards making DVD and SVCD compliant MPEG files. The MPEG file that 0.4.0 will make will play in any MPEG-2 player but it will not be something you can burn to a DVD or SVCD. tydemux/remux 0.5.0 will take care of that.

Cheers Olaf

Originally posted by racingclub
0.31 seems to work on streams that crashed 0.30 - the resulting files muxed up OK & kept in sync (something I've never managed with vsplit) - nice one Olof!!!!

now just need to remove the 2gb limit & up the release to 1.0? :)

[fredisdead]

Olaf:

I tried the new version (Under windows xp) and had 2 problems.

1) Abnormal termination. After completing the split, the program crashed.

2) The split video portion of the ty file could not be imported into DVD Maestro due to a Temporal Reference Error, which as I understand is a backward time reference in a gop. Jdiner does not like these errors (see his posts) blaming them on 'shuffeled' frames from the dtivo. HOWEVER, when split with vsplit13c, there is no Temporal Reference error so I must assume it is either repaired by vsplit or introduced by tydemux. Perhaps when you pad out a hole, there are incorrect time stamps in the created frames?

Anyway, keep up the good work, I will try and ftp the file (VG 03x21 Before & After.ty 840mg) to your ftp site..

[laserfan]

Originally posted by fredisdead
...The split video portion of the ty file could not be imported into DVD Maestro due to a Temporal Reference Error...I should add that I tried to import my split (SA) video file into SpruceUp (same mfr) and got the same error.

I like SU but at least jdiner (whom I respect of course) has called it a "steaming pile of crap" so maybe I need to be able to switch horses e.g. IfoEdit or something...

[olaf_sc]

Hello

Thanks for your feedback, let us see what we can do with it :).

Originally posted by fredisdead
1) Abnormal termination. After completing the split, the program crashed.


First what version are you running? Version 0.3.0 has a bug making it crash at the end of the mux if the tystream has been abnormaly turncated.

If you are running 0.3.1 well then we have another bug :(. The good thing is that we find them, what I need from you is the last 6MB of your stream. The error has to do with the ending of the muxing. My ftp server is as always 66.121.15.34.


2) The split video portion of the ty file could not be imported into DVD Maestro due to a Temporal Reference Error, which as I understand is a backward time reference in a gop. Jdiner does not like these errors (see his posts) blaming them on 'shuffeled' frames from the dtivo. HOWEVER, when split with vsplit13c, there is no Temporal Reference error so I must assume it is either repaired by vsplit or introduced by tydemux. Perhaps when you pad out a hole, there are incorrect time stamps in the created frames?


Well I dunno if vsplit13c is fixing "Temporal Reference Errors", and I haven't read what jdiner has to say about it. Maybe you can give me specific URL to the post so I don't need to search around for it.

Anyways I guess that you mean when frames comes out of order or frames has been dropped. The whole thing pretty well described in this page (http://www.zvon.org/tmRFC/RFC2250/Output/chapter5.html). Frames comeing out order is actually leagal in the MPEG std (it's not in DVD). However droped frames are naturally not legal unless you make the cut it in the GOP boundaries and take care of it in the GOP header.

My guess is that Maestro DVD wants MPEG video that is complies to the DVD std. Hence it will complain about frames that comes in the wrong order.

Now I could include a Temporal Reference counter in tydemux and correct the problem when it happens. It's a little work but it not that hard. I.e. let me hack it over the weekend and you will have a working version on Monday.


Anyway, keep up the good work, I will try and ftp the file (VG 03x21 Before & After.ty 840mg) to your ftp site..

Yes, please it's a bit hard to fix the problem if I don't have example streams with it :). Hence I need a stream that is covering the part that has the "error".

Cheers Olaf

[fredisdead]

Olaf:

I was using 0.3.0 so I guess that the abend is not an issue.

As to the Temporal Reference Error, Most of us look to burning the video to DVD.

IFOEDIT does not care about the errors, but sometimes loses synch. Maestro appears to be the most robust (never burned a coaster) tool available, Spruceup (which is a piece of S**T) if you can live through the constant crashes, actually uses Maestro's multiplexing engine (same author) and also chokes on the Error.

Anyway, correcting the Errors would be very useful to those of us burning DVD's.

Thx, will be watching for your next release....

[olaf_sc]

Hello Folks,

Started coding the algo to preform the "temporal reference" check in all GOP present on in TyStream.

Now this problem is parsially my own fault - I'm by default making a closed GOP as the start of the video stream. This is how it supposed to be. However what I don't do is fix the temporal refernece in all the frames in that start GOP.


Now instead of just fixing that small error which is relativly easy I will instead fix the whole TyStream hopefully I will have something working either later (real late) today or tomorrow evening (if I don't go and see the new Harry Potter).

Cheers Olaf



Originally posted by fredisdead
Olaf:

I was using 0.3.0 so I guess that the abend is not an issue.

As to the Temporal Reference Error, Most of us look to burning the video to DVD.

IFOEDIT does not care about the errors, but sometimes loses synch. Maestro appears to be the most robust (never burned a coaster) tool available, Spruceup (which is a piece of S**T) if you can live through the constant crashes, actually uses Maestro's multiplexing engine (same author) and also chokes on the Error.

Anyway, correcting the Errors would be very useful to those of us burning DVD's.

Thx, will be watching for your next release....

[laserfan]

Olaf, I have now tried v0.3.1 on another SA ty stream (1.3Gb music program) and it has impressively re-muxed w/full sync (I'm using MPEG-VCR 3.13 to mux & off set audio). This was on streams that refused to sync under vsplit.

A couple comments:

1. The audio offset reported by 0.3.1 has not been useful. The last stream I remuxed was reported to be 7ms early, and MPEG-VCR needed -230ms to achieve perfect sync. Note I've never found vsplit to be any good either FWIW

2. The remuxed program has frequent "freeze frame" (pauses) which seem to occur precisely at scene changes. That is, the video frame pauses for perhaps 4 frames or so, then resumes with a new scene. Audio remains in sync of course

I don't know if both of these issues are with MPEG-VCR muxing process and not the mpv and mpa that tydemux produces. In any case I am very impressed with what you have accomplished in what seems to be an extremely short period of time! Please keep up the great work! Looking forward to your remuxing version with audio resample.

Thanks Olaf!!!

[laserfan]

And now I've tried re-muxing with IfoEdit, and it again maintains perfect sync to the end! The "end of scene" freezes that I experienced w/MPEG-VCR muxing are now Start of scene freezes (though fewer in frequency), so apparently this is a muxer issue of some sort.

But this is pretty darn good. Except that you are moving so fast w/updates, I might be inclined to burn some DVDs already (yes, I converted the audio to 48kHz using MPEG-VCR). But I am going to tinker some more instead for now.

[olaf_sc]

Hello Laserfan,

Thanks for your feedback and encouragements - I have now implemented a algo for checking temporal reference. I'm continuing hacking along on a algo actually fixing the problem.

Anyways I think it's worth while to mention that there is a lot of things that makes a Tivo stream not DVD compliant besideds the obvious once.

E.g. it has more frames per GOP than allowed (seen up to 48 frames while DVD only allows 18/15 depening if it's NTSC or PAL). There is alot of those small details that makes DVD creation of TyStreams a bit hard.

My goal for 0.4.0 is to make internal muxing work but not having it comply to DVD. In 0.5.0 I will make it comply except for the fact that it will remain at it's present resolution and frame rate.

Ahh! It would be really nice if you could upload your test stream laserfan so I could take a look at those frame freez.

Cheers Olaf


Originally posted by laserfan
And now I've tried re-muxing with IfoEdit, and it again maintains perfect sync to the end! The "end of scene" freezes that I experienced w/MPEG-VCR muxing are now Start of scene freezes (though fewer in frequency), so apparently this is a muxer issue of some sort.

But this is pretty darn good. Except that you are moving so fast w/updates, I might be inclined to burn some DVDs already (yes, I converted the audio to 48kHz using MPEG-VCR). But I am going to tinker some more instead for now.

[olaf_sc]

Hmm the algo used to detect temp ref error as described at http://www.zvon.org/tmRFC/RFC2250/Output/chapter5.html.
Is actually flawed bummer after implementing it but on the flip side I made my own - it avalible here (ftp://66.121.15.34/tydemux/temp_ref_algo.txt).

Anyways it will handle both closed and open GOPs and more funcy GOPs that e.g. has P-Frame B-Frame P-Frame instead of the more usuall P B B P.

Back to implementing it.

Cheers Olaf

[racingclub]

Hi again.... :)

I tried 031 with a 30min show - the program executed fine and gave me the relevant audio & video files. Muxing these up with IfoEdit with the appropriate audio offset settings gave me a video thats starts off sync'd but seems to progressively lose audio sync over the course of the show (something I always seem to get from vsplit).

I have uploaded the file 'royle.ty' to your FTP.......

Cheers :D

BTW - I'm more interested in SVCD creation (rather than DVD).

[artships]

Olaf,

I extracted an fsid from the middle of a Nero Wolfe episode. tydemux worked great, indicating a mere -001ms offset. Fed the resulting m2v to DVD2AVI, fed that d2v to TMPGEnc along with the m2a, cut the adverts from either end, transcoded/muxed it to DVD-standards, played the resulting mpg in PowerDVD.

Perfect. Thank you!

I'll try it with the whole episode and edit this with the results. Um, it sure would be handy to be able to do a whole hour show as one tystream, instead of breaking it in two to get around the 2G limit. Just a thought.

John

[laserfan]

Originally posted by olaf_sc
...It would be really nice if you could upload your test stream laserfan so I could take a look at those frame freez...I can send you an mpg file with the frame freezing in it, but as I said it appears the freezing varies depending on what method I use to mux the mpv and mpa back together again. So I'm not sure how it will help you, but in any case if you want such a thing I am inclined to make a small program for you from scratch (versus the 1.3Gb file which would take a day or two to upload!), i.e. record a short SA Tivo program (a music video perhaps), apply tydemux to it, remake (remux) these files as an mpg file using any of a number of muxers I have here, observe that it shows the freeze frame problem, and send it to you. Is this what you want?

As I re-read my post, I would probably send you both the original ty and the new mpg file?

[olaf_sc]

Hello

Yes, a 1.3G is a bit to big to send if you have a dedicated pip :). It would be really nice if you could send me a small exampel (i.e a smaller recording) as you say.

Cheers Olaf

Originally posted by laserfan
I can send you an mpg file with the frame freezing in it, but as I said it appears the freezing varies depending on what method I use to mux the mpv and mpa back together again. So I'm not sure how it will help you, but in any case if you want such a thing I am inclined to make a small program for you from scratch (versus the 1.3Gb file which would take a day or two to upload!), i.e. record a short SA Tivo program (a music video perhaps), apply tydemux to it, remake (remux) these files as an mpg file using any of a number of muxers I have here, observe that it shows the freeze frame problem, and send it to you. Is this what you want?

As I re-read my post, I would probably send you both the original ty and the new mpg file?

[olaf_sc]

Hello

Thanks for your feedback and also for uploading the file. I will check it out later today.

Why loosing sync gradually? Well sync is dependant on relationship between specified framerate and actual framerate. If e.g. the specified one is 30/s and the actual is 31/s well then you will gradually loose sync since the muxer will count frames when it does the mux.

There is two ways to get around this problem - either we do an internal mux or we tweak the mpeg stream to actually specified framerate (there is several ways to do that).

Anyways I will as said before make a internal muxer but I will also thinking about fixing the framerate.

As for SVCD yes 0.5.0 will have both SVCD and DVD support.

Cheers Olaf


Originally posted by racingclub
Hi again.... :)

I tried 031 with a 30min show - the program executed fine and gave me the relevant audio & video files. Muxing these up with IfoEdit with the appropriate audio offset settings gave me a video thats starts off sync'd but seems to progressively lose audio sync over the course of the show (something I always seem to get from vsplit).

I have uploaded the file 'royle.ty' to your FTP.......

Cheers :D

BTW - I'm more interested in SVCD creation (rather than DVD).

[olaf_sc]

Hello John,

Thanks for your feedback I'm glad that it works so fine for you.

I will remove the 2GB limit in 0.3.2 but before I release 0.3.2 I want to implment a temporal reference check and fix functionality so we don't get those pesky Temporal Reference errors.

Cheers Olaf

PS: If it wasn't for the fact that the inital check algo was flawed it would been released this evening now it looks more like Saturday.

Originally posted by artships
Olaf,

I extracted an fsid from the middle of a Nero Wolfe episode. tydemux worked great, indicating a mere -001ms offset. Fed the resulting m2v to DVD2AVI, fed that d2v to TMPGEnc along with the m2a, cut the adverts from either end, transcoded/muxed it to DVD-standards, played the resulting mpg in PowerDVD.

Perfect. Thank you!

I'll try it with the whole episode and edit this with the results. Um, it sure would be handy to be able to do a whole hour show as one tystream, instead of breaking it in two to get around the 2G limit. Just a thought.

John

[artships]

Olaf,

The first half of a Nero Wolfe episode has, I'm guessing, some bad data in it. This is the kind of bad data I've been seeing the last two weeks with stuff that's been vsplited, too.

Edit:
The problem I think was that I was extracting using tserver_mfs3, instead of tserver_mfs5 with the lower scheduling priority, consequently, the tystream was getting intermittant errors in it.

I fetched a fresh tystream. There's still a glitch in it, but a subtle one. About a third of the way into the show, it starts losing sync. The offset grows as the show progresses. I don't see the sync problem until after I burn it to DVD. PowerDVD plays each section between adverts (separate files) just fine. Muxing with TMPGEnc, the resulting file plays just fine. Ulead DVD Movie Factory made VOBs that have the sync drift.

Why this process started messing-up two weeks ago I've no idea, but it is very, very annoying. All of a sudden tivo-to-dvd has stopped being an automatic. Major disappointment.

TMGEnc uses either it's own audio conversion routines, or toolame. At point 39000 (of 69000) the audio contains something that kills toolame. I fixed it by running it through winamp and creating a wav file, and feeding that to TMPGEnc and toolame.

I can't fix the video error:
Read error occured at address 1000636B of modle 'DVD2AVI.vfp' with 01faaf3c

It occured 2.21 minutes into the show (which would be 3 or 4 minutes into the tystream). I'm uploading to your site emmm.ty

Edit:
To get you a too-small clip took my modem two hours, so I doubt I'll be able to send you the offending stream.

[olaf_sc]

Hello John,

Will take a look at the TyStream as soon as your upload is finished. It will be interesting to see what is really going on.

Cheers Olaf


Originally posted by artships
Olaf,

The first half of a Nero Wolfe episode has, I'm guessing, some bad data in it. This is the kind of bad data I've been seeing the last two weeks with stuff that's been vsplited, too.

TMGEnc uses either it's own audio conversion routines, or toolame. At point 39000 (of 69000) the audio contains something that kills toolame. I fixed it by running it through winamp and creating a wav file, and feeding that to TMPGEnc and toolame.

I can't fix the video error:
Read error occured at address 1000636B of modle 'DVD2AVI.vfp' with 01faaf3c

It occured 2.21 minutes into the show (which would be 3 or 4 minutes into the tystream). I'm uploading to your site emmm.ty

Sorry!

John

[olaf_sc]

Hi Riley,

Thanks for your post and also for the intersting observation. Please see my inline comments.


Originally posted by rc3105
I have serveral clips that have intact audio but missing video. (my tivo compiler runs natively in the tivo & video gets dropped because of excessive disk activity when I'm compiling) same sort of thing happens with the original (slow) quantum with some scripts on db opens or even a fast drive with excessive insert/extract activity

these clips split/mux fine until they hit one of these dropouts, then the sync is lost. audio is continous but video gets shifted (vsplit has the same problems only more pronounced)

A--A--A--A--A--A--A-- --A--A--A--A-- --A--A--A--A--A--
V--V--V--V--V--V-- --V-- --V-- -- -- -- --V--V--V--V--

becomes

A--A--A--A--A--A--A--A--A--A--A--A--A--A--A--A--
V--V--V--V--V--V--V--V--V--V--V--V--


Hmm, so what you are saying is that Tivo is dropping frames internally on high loads. In other words the TyPackets (Chunks) are okay but the content isn't. The sync from one TyPacket to another is also okay/within bounderies. What needs to be done is to check if all frames are present in the mpeg stream that we demux/extract.

Anyhow my new temporal reference check will detect those kind missing frames. The problem is what to do about it.

Normally when we have a error in the temporal reference we can seach for the correct frame and correct the order of the frame.

Say that the frames are comming like this (very simplyfied*).

1 2 3 4 5 6 9 7 8 10
| error

All what is needed here is to search for frame 7 and when you find it (in this case the next frame) you just shift them around. Sure there is more effective algos how to do this but I want to compicate it more than nessesary.

Anyhow the probelm with missing frames is that they are missing :).

1 2 3 5 6 7 8 9 10

Now we can either throw away the whole GOP and realign the audio - this natrually a very ugly solution but effective.

Now if we have a MPEG stream like this (M == missing frame)

I B B P B M P B B P ......

then I can just copy the B frame next to the missing B frame (make some small adjust to the header of the picture) and voiala we are home free.

The problem is when we have a P frame or several B frames missing.

* If a P frame is missing I need to recreate it or do the ugly one where I throw away to whole GOP.
* If all B frames are missing between P frames then I can use P frames to cover the gap.

What ever we do will make the video a bit funky (repeated frames) but it's probably better than audio out of sync.


--A--A--A--A--
--V--V--V--V--

stays

--A--A--A--A--
--V--V--V--V--

as much as I hate to suggest discarding packets, is it feasable to continouisly verify sync & discard/resync if necessary by comparing timestamps? I know some packets arrive out of order but if it's off by more than a few chunks or outside the gop it I doubt it's ever going to arrive.


It's actually not such a good idea to check timestamps in this case it's easier and faster to check the temporal reference. However this is naturally dependant on the fact that that the temporal reference is written correctrly by Tivo. Hence that tivo when skipping frames under heavy load is updating the temp ref but not writing the frame.

We will see if it's like that when I get your segments - Ahh, yes when you upload please make each segment 6MB or more. tydemux need that amount of space to probe the tystream.

Cheers Olaf

* Yes, mpeg frames doesn't come in that order but like this (open gop) 2 0 1 5 3 4 8 6 7 .......

[olaf_sc]

Hello John,

I tested your tystream emmm.ty but it doesn't hold the Nero Wolfe, just a preview.

Both demuxed video and audio is normal in the TyStream you sent me. I think I need more of your stream so I get at least to the beginning of your problem.

Cheers Olaf


Originally posted by artships
Olaf,

The first half of a Nero Wolfe episode has, I'm guessing, some bad data in It occured 2.21 minutes into the show (which would be 3 or 4 minutes into the tystream). I'm uploading to your site emmm.ty
[snip]
Sorry!

John

[du1jec]

Olaf,

I attempted to compile tydemux in MacOS 10.2 (Jaguar) and here is what I got. It gives me a compiled binary, but when I try to run it against a tyfile I get bus error.

See below for compiler output and subsequent error.

Thanks,

Jojo


[du1jec-powermac:~/Documents/tydemux] du1jec% gcc -v
Reading specs from /usr/libexec/gcc/darwin/ppc/3.1/specs
Thread model: posix
Apple Computer, Inc. GCC version 1151, based on gcc version 3.1 20020420 (prerelease)

[du1jec-powermac:~/Documents/tydemux] du1jec% make all
rm -f *.o
gcc -g -Wall -W -c check_audio_sync.c -o check_audio_sync.o
gcc -g -Wall -W -c find_start_code_offset.c -o find_start_code_offset.o
find_start_code_offset.c: In function `find_start_code_offset':
find_start_code_offset.c:55: warning: implicit declaration of function `memcpy'
find_start_code_offset.c:133: warning: implicit declaration of function `memcmp'
gcc -g -Wall -W -c get_audio.c -o get_audio.o
get_audio.c: In function `get_audio':
get_audio.c:163: warning: implicit declaration of function `memcpy'
gcc -g -Wall -W -c get_next_record.c -o get_next_record.o
get_next_record.c: In function `get_next_record':
get_next_record.c:59: warning: implicit declaration of function `memcpy'
gcc -g -Wall -W -c get_time_X.c -o get_time_X.o
get_time_X.c: In function `get_time_X':
get_time_X.c:131: warning: implicit declaration of function `memcpy'
gcc -g -Wall -W -c get_video.c -o get_video.o
get_video.c: In function `get_video':
get_video.c:190: warning: implicit declaration of function `memcpy'
gcc -g -Wall -W -c chunk.c -o chunk.o
gcc -g -Wall -W -c check_chunk.c -o check_chunk.o
gcc -g -Wall -W -c check_junk_chunks.c -o check_junk_chunks.o
gcc -g -Wall -W -c probe_audio.c -o probe_audio.o
probe_audio.c: In function `copy_chunk':
probe_audio.c:60: warning: implicit declaration of function `memcpy'
gcc -g -Wall -W -c misc.c -o misc.o
gcc -g -Wall -W -c tystream.c -o tystream.o
gcc -g -Wall -W -c pes_holder.c -o pes_holder.o
gcc -g -Wall -W -c parse_chunk.c -o parse_chunk.o
parse_chunk.c: In function `parse_chunk_video_remainder_S1':
parse_chunk.c:152: warning: implicit declaration of function `memcpy'
gcc -g -Wall -W -c tydemux.c -o tydemux.o
gcc -g -Wall -W -c tystream_repair.c -o tystream_repair.o
tystream_repair.c: In function `repair_audio':
tystream_repair.c:228: warning: unused parameter `audio_times'
gcc -g -Wall -W -c mpeg.c -o mpeg.o
gcc -g -Wall -W -c tystream_init.c -o tystream_init.o
gcc -o tydemux check_audio_sync.o find_start_code_offset.o get_audio.o get_next_record.o get_time_X.o get_video.o chunk.o check_chunk.o check_junk_chunks.o probe_audio.o misc.o tystream.o pes_holder.o parse_chunk.o tydemux.o tystream_repair.o mpeg.o tystream_init.o

[du1jec-powermac:~/Documents/tydemux] du1jec% ./tydemux -i ../mpeg/808865-Andromeda-Slipfighter_the_Dogs_of_War.ty -a ../mpeg/slip.mpa -v ../mpeg/slip.mpv
Probing TyStream .....
Bus error

[pbar]

Originally posted by rc3105
Olaf:
I have serveral clips that have intact audio but missing video. these clips split/mux fine until they hit one of these dropouts, then the sync is lost. audio is continous but video gets shifted (vsplit has the same problems only more pronounced)

A--A--A--A--A--A--A-- --A--A--A--A-- --A--A--A--A--A--
V--V--V--V--V--V-- --V-- --V-- -- -- -- --V--V--V--V--

becomes

A--A--A--A--A--A--A--A--A--A--A--A--A--A--A--A--
V--V--V--V--V--V--V--V--V--V--V--V--

I have this problem with pretty much every recording from my UK TiVo ... even when my TiVo isn't doing anything else! A graph of the video frame number (i.e. count of MPEG2 PICTURE start codes) against TiVo video PTS drifts by about a second over a 1-hour recording! This makes both vsplit and tydemux unusable for me.

Even if I use vsplit -m to produce an MPEG with the correct A/V timestamps, it plays in sync on the PC, but as soon as you transcode or feed the file into a DVD authoring package the above problem happens and you end up losing sync again!

The only way I have found to work around this is to split the tystream into lots of small-ish chunks, demux them individually and add them as separate chapters when building a DVD.

Originally posted by rc3105
Olaf:
as much as I hate to suggest discarding packets, is it feasable to continouisly verify sync & discard/resync if necessary by comparing timestamps? I know some packets arrive out of order but if it's off by more than a few chunks or outside the gop it I doubt it's ever going to arrive.


Surely it's *much* easier to drop one or more audio segments to keep the timestamps approximately in step? Audio frames have no forwards or backwards dependencies, and a small 36ms glitch in the audio is way preferable to throwing away a 2-3 second GOP.

Ideally you'd like to drop only 40ms of audio samples (or 33.3ms for NTSC) - but I'm not sure how easy it is to change the size of an MPEG audio frame?

Now that there's a well-written open-source splitting tool, I've been thinking about having a go at coding this up (assuming I ever get the time) but I expect it wouldn't be a very big job for somebody familiar with the source?

This would make such a big difference to my TiVo experience that I'd be off to paypal like a shot!


Paul

[olaf_sc]

Hello du1jec,

Great :) well great that you have a Mac I mean, porting it to Mac is pretty trivial.

What I need from you is what include files that memcmp and memcpy needs. Normally you get that by typing man memcpy and man memcmp. In the SYNOPSIS it will tell you what files to include.

Now don't think that just by including those files it will run just fine under Mac - the app is currently little endian only! However if you give me the include I will make the small changes that is needed to make it bigendian/littleendian independant in the next release.

Cheers Olaf


Originally posted by du1jec

[du1jec-powermac:~/Documents/tydemux] du1jec% gcc -v
find_start_code_offset.c:55: warning: implicit declaration of function `memcpy'
find_start_code_offset.c:133: warning: implicit declaration of function `memcmp'

[du1jec]

Olaf,

Here are the man pages for memcmp and memcpy.

I have also attached the string.h include file. It is called stringh.txt so the board would take it.

Thanks,

Jojo


MEMCMP(3) System Library Functions Manual MEMCMP(3)

NAME
memcmp - compare byte string

LIBRARY
Standard C Library (libc, -lc)


SYNOPSIS
#include <string.h>

int
memcmp(const void *b1, const void *b2, size_t len);

DESCRIPTION
The memcmp() function compares byte string b1 against byte string b2.
Both strings are assumed to be len bytes long.

RETURN VALUES
The memcmp() function returns zero if the two strings are identical, oth-
erwise returns the difference between the first two differing bytes
(treated as unsigned char values, so that `\200' is greater than `\0',
for example). Zero-length strings are always identical.

SEE ALSO
bcmp(3), strcasecmp(3), strcmp(3), strcoll(3), strxfrm(3)

STANDARDS
The memcmp() function conforms to ISO/IEC 9899:1990 (``ISO C89'').

BSD June 4, 1993 BSD

[du1jec-powermac:~/Documents/tydemux] du1jec% man memcpy
MEMCPY(3) System Library Functions Manual MEMCPY(3)

NAME
memcpy - copy byte string

LIBRARY
Standard C Library (libc, -lc)

SYNOPSIS
#include <string.h>

void *
memcpy(void *dst, const void *src, size_t len);

DESCRIPTION
The memcpy() function copies len bytes from string src to string dst.

RETURN VALUES
The memcpy() function returns the original value of dst.

SEE ALSO
bcopy(3), memccpy(3), memmove(3), strcpy(3)

STANDARDS
The memcpy() function conforms to ISO/IEC 9899:1990 (``ISO C89'').

BUGS
In this implementation memcpy() is implemented using bcopy(3), and there-
fore the strings may overlap. On other systems, copying overlapping
strings may produce surprises. A simpler solution is to not use
memcpy().

BCOPY(3) System Library Functions Manual BCOPY(3)

NAME
bcopy - copy byte string

LIBRARY
Standard C Library (libc, -lc)

SYNOPSIS
#include <string.h>

void
bcopy(const void *src, void *dst, size_t len);

DESCRIPTION
The bcopy() function copies len bytes from string src to string dst. The
two strings may overlap. If len is zero, no bytes are copied.

SEE ALSO
memccpy(3), memcpy(3), memmove(3), strcpy(3), strncpy(3)

HISTORY
A bcopy() function appeared in 4.2BSD.

BSD June 4, 1993 BSD

[olaf_sc]

Hello Paul,

Originally posted by pbar
I have this problem with pretty much every recording from my UK TiVo ... even when my TiVo isn't doing anything else! A graph of the video frame number (i.e. count of MPEG2 PICTURE start codes) against TiVo video PTS drifts by about a second over a 1-hour recording! This makes both vsplit and tydemux unusable for me.

Hmm, not sure if I get you here. Let me assume that what you are talking about is: You count frames and give them a "virtual PTS" based on the frame rate specified in the video stream. Now you compare that to the actuall PTS given in the video stream and you find that they drift 1 second over an hour recording. Right?

Now this is how it supposed to be:) - well not but in the Tivo case it is like this due to the fact that they have a variable frame rate (not allowed in the MPEG std).


Even if I use vsplit -m to produce an MPEG with the correct A/V timestamps, it plays in sync on the PC, but as soon as you transcode or feed the file into a DVD authoring package the above problem happens and you end up losing sync again!


Naturally the whole idea with internal muxing is to force sync, by using the PTS present in the video/audio stream in the TyStream. vsplit -m doesn't do any magic to fix the video stream. Which means that when you trancode it (which includes a demux) you will end up with the same problem. Too few or too may frames per second compared to what the video stream specifies it to be.


The only way I have found to work around this is to split the tystream into lots of small-ish chunks, demux them individually and add them as separate chapters when building a DVD.


Ugh, bulky but workable work around. The thing is that the muxer is counting frames and it simply doesn't get enough of them to produce out of sync video/audio.


Surely it's *much* easier to drop one or more audio segments to keep the timestamps approximately in step? Audio frames have no forwards or backwards dependencies, and a small 36ms glitch in the audio is way preferable to throwing away a 2-3 second GOP.


Firstly what I assume RC3105 was talking about was when we actually had missing frames due to heavy load not that we have "missing"/"too many" frames due to variable frame rate.


Secondly this is actually easier to do in the video stream.

1: We need to count frames in the video stream in order to detect when we have under/over run in frames.

2: As soon as we detect a over/under run we can simply add or delete a B-Frame.

This is much simpler than seeking and removing audio frames.

Just for the sake of it I actually made an experiment this moring.

I removed every 7:th B-Frame and I added a B-Frame every 25:th B-Frame. An as I suspected the video clip is playing just perfectly

Well it's a bit jerky but considering that we removed such an amout of frames and added quite a bit of frames it's totally understandable.

The key is that B-Frames has bidirectional dependencies to the previous P-Frame and the P-Frame a head of it. But it doesn't care as long as if "finds" the P-Frames that it depends up on

I naturally need to check this in more detail (don't have that deep knowledge of the mpeg video stream - mostly been working with the program stream (muxed audio/video).

Now if I fix the frame rate problem which I intend to do. Then we will have a video/audio stream that will keep in sync even if you edit it, transcode it etc..

Cheers Olaf

[pbar]

Olaf,

Thanks for the reply.

Originally posted by olaf_sc
Hmm, not sure if I get you here. Let me assume that what you are talking about is: You count frames and give them a "virtual PTS" based on the frame rate specified in the video stream. Now you compare that to the actuall PTS given in the video stream and you find that they drift 1 second over an hour recording. Right?

Yep, exactly. I was trying to work out if the sync drifted gradually or if there were 2 or 3 sudden jumps where video or audio was dropped.


Now this is how it supposed to be:) - well not but in the Tivo case it is like this due to the fact that they have a variable frame rate (not allowed in the MPEG std).

I thought this was just a DTivo issue... but I've written firmware for a motion-jpeg video/audio compression board before and it's easy to imagine numerous reasons why you might occasionally miss a frame-sync if a scene is a bit complex!


Naturally the whole idea with internal muxing is to force sync, by using the PTS present in the video/audio stream in the TyStream. vsplit -m doesn't do any magic to fix the video stream. Which means that when you trancode it (which includes a demux) you will end up with the same problem. Too few or too may frames per second compared to what the video stream specifies it to be.

True... but I'd been hoping (perhaps a bit naively) that any DVD authoring package which accepted MPEG2 transport streams directly would be capable of recoding the video frames without discarding the presentation timestamps. Certainly you'd expect to lose sync if you demuxed to audio and video elementary streams... ho hum. Spose most of the video tools out there are used to dealing with MPEG2 from DVDs :D


Ugh, bulky but workable work around. The thing is that the muxer is counting frames and it simply doesn't get enough of them to produce out of sync video/audio.

Not ideal... but necessity is the mother of invention.



... this is actually easier to do in the video stream.
I removed every 7:th B-Frame and I added a B-Frame every 25:th B-Frame. An as I suspected the video clip is playing just perfectly

I naturally need to check this in more detail (don't have that deep knowledge of the mpeg video stream - mostly been working with the program stream (muxed audio/video).

Now if I fix the frame rate problem which I intend to do. Then we will have a video/audio stream that will keep in sync even if you edit it, transcode it etc..


That'll do very nicely... :cool:

Inserting/deleting B frames has the big advantage that duplicate video frames are almost impossible to notice, whereas an audio glitch is sometimes quite irritating... just thought it seemed a lot more fiddly and 'stateful' than binning a single independent audio packet every so often.

Nice work, nice tool. Looking forward to cutting some nice DVDs!

Thanks for all the hard work,

Paul

[OS X]

Originally posted by du1jec
Olaf,

I attempted to compile tydemux in MacOS 10.2 (Jaguar) and here is what I got. It gives me a compiled binary, but when I try to run it against a tyfile I get bus error.


Nice to hear there's another Mac OS X user playing with this stuff. I'm a newbie but so far I've managed to extract to my PC using Tytool5. My ultimate goal is to edit and burn commercial free DVD's with Final Cut Pro and DVD Studio Pro.

I've never tried to compile source. I'll be watching to see how this works out for you guys. Any suggestions for me to come up to speed to participate in getting this working on OS X would be appreciated.

Keep up the good work! :)

[rd001]

Originally posted by racingclub

I tried 031 with a 30min show - the program executed fine and gave me the relevant audio & video files. Muxing these up with IfoEdit with the appropriate audio offset settings gave me a video thats starts off sync'd but seems to progressively lose audio sync over the course of the show (something I always seem to get from vsplit). You may have noticed that some programs played directly on the DTivo live have sync problems too.

DTV doesn't always maintain perfectly A/V. I've noticed it in the last few years. It even happens with early runs of hot PPVs (channels 100-110) where they typically allocate a lot of bandwidth but it does happen much less often with those.

I think that there is no way to make absolutely perfect A/V sync with the DTV streams as they are currently. You can get close enough that it isn't distracting.

I assume that you're talking about a drift problem that gets progressively worse. That is a different problem but I was trying to point out that it's unlikely that any muxing program is going to produce completely perfect A/V sync.

[olaf_sc]

Hello Folks,

After doing some analyze of streams from DTivo 1* and I found some intersting facts.

Now as said before the frame rate is variable but that is not entierly true. A more correct term should be that it shifts.

MPEG specifies - seven std framerates. From a quick glance Tivo uses two 23.976 frames per sec and 29.97 frames per sec 2*.

Now MPEG "specifies" time in ticks and when it comes to the presentation time of a video frame then MPEG says that there will be 90 000 ticks per second.

If we combine the ticks with the frame rates we find that a 29.97 f/s will have 3003 ticks between each frame and 23.97 f/s will have 3753 ticks between each frame.

Now lets take a look at the actual diff between frames,


Starting demux process
.Checking tmp ref
First closed gop
SEQ Header Frame rate: 29.97 frames/sec
[snip 1]
Diff is 3003
Diff is 3003
Diff is 3003
Diff is 3003
Diff is 3003
Diff is 3003
Diff is 3003
Diff is 3003
SEQ Header Frame rate: 29.97 frames/sec
Diff is 3003
[snip 2]
Diff is 3003
Diff is 4505
Diff is 3003
Diff is 4504
Diff is 3003
Diff is 4505
Diff is 3003
Diff is 4504
Diff is 3003
[snip 3]
Diff is 4504
Diff is 3003
Diff is 4505
Diff is 3003
Diff is 4504
Diff is 3003
Diff is 3003
Diff is 3003
Diff is 3003
Diff is 3003
Diff is 3003
Diff is 3003
Diff is 3003
[snip-4]
Diff is 3003
Diff is 3003
Diff is 3003
Diff is 4505
Diff is 3003
Diff is 4504
Diff is 3003
Diff is 4505
Diff is 3003
Diff is 4504
Diff is 3003
Diff is 4505
Diff is 3003
Diff is 4504
[snip -5]
Diff is 4505
Diff is 3003
Diff is 3003
Diff is 3003
Diff is 3003
Diff is 3003
Diff is 3003
Diff is 3003
Diff is 3003
Diff is 3003
Diff is 3003
Diff is 3003
Diff is 3003
Diff is 3003
Diff is 3003

Demux process finished

A/V Sync Offset: -014ms (i.e. audio plays 014ms late use -O 014 in mplex)

(Sorry for the flood :) )

Anyways what we see here is 29.97 f/s (normal NTSC) in the begining then it shifts to 24.97 f/s (normal NTSC from film 3-2 downpulled effect 3*) then it makes a shift to 29.97 and the it shifts back and so on.

Now what is happening in the movie when it shifts/each snip?

1: HBO Intro
2: Film entry
3: My guess movie into
4: Normal movie (this and to the last snip is around 1h 50 min of film)
5: Ending and so on

Now since the SEQ header is specifiying 29.97 f/s we will most defitly get sync issues.

If it was so simple as changeing the frame rate in the SEQ header this would be a piece of cake. However most muxer will take a look at the first seq header and then start muxing (e.g. mplex is doing this). Hence they will mux the video as 29.97 f/s which is wrong.

Now how do we detect the right frame rate? Well we have to probe the stream, at regular interval and there by determine what frame rate we have.

Then what can we do about it? We have a mix of frame rates after all. Well we can open for suggestion what you folks think is best:


Remove video of unwanted frame rate, a side effect of this is that we for sure will remove comersials, previews etc 4*. There might however be side effects that we loose a bit of the start/end in each break.

Adjust the minority frame rate to the major frame rate of the TyStream. Pretty easy just add and remove B-Frames.


As you might have notice 3003 + 4505 is not == 2*3753 we have so on top of the shifting of frame rate we have a slight drift in frames small but over 3753/2 frames it will make a hole frame (around 300ms) and over a whole 2h movie it will make 45 frames in difference i.e a lot of diff. Now you shold now that there every now and then come a 3001 and maybe a 4503 so the drift is not as big as I state but it's large enough to be iritated over :).

Ahh, yes I naturally hacking on correcting this junk. However it will take a little time it's not as trival as it might look.

Hence the next version will be 0.4.0 and the the other features will be bumped up one notch in versioning.

Cheers Olaf


*1: Will examine SA Tivos too but the algo is slightly different. However the nice thing is that the algo I use to examine is the one I will use to repair the mpeg stream.

*2: No worries I will cover UK/PAL Tivo to :)

*3 Yes, the number of ticks is not 3753 but 3003 + 4505 is nearly 2 * 3753

*4 I'm allready doing this to some extent on recordings that has a mix of MPEG and AC3 sound - the clips with AC3 will be keept while I ditch the MPEG sound. All comersials are sent in MPEG.

[AlphaWolf]

I would be concerned about what video we might be losing if we did the first option, but then, that would be nice to remove the unneeded portions of the stream just like that. I can't decide myself!

But then, what about having our own special *modified* version of mplex which is designed to detect changes in the frame rate? (mplex is OSS isn't it?) That way, when you edit the tystreams, then remux em, they are in sync.

hell...I dunno :)

[rd001]

Originally posted by olaf_sc

If it was so simple as changeing the frame rate in the SEQ header this would be a piece of cake. However most muxer will take a look at the first seq header and then start muxing (e.g. mplex is doing this). Hence they will mux the video as 29.97 f/s which is wrong.

Now how do we detect the right frame rate? Well we have to probe the stream, at regular interval and there by determine what frame rate we have.
I would think that you'd want to add/remove the B-frames and leave the stream intact. Maybe you can offer the option of removing these segments in other frame rates later.

You know, this matter of detecting stream changes by frame rates is very interesting as it might relate to automated commercial-cutting during extraction or automated commercial- skipping like ReplayTV. Any comments, Riley (over on your own thread)?

You can't do anything except make a best-guess, what-works-most-often solution. Maybe you could later offer the user the option of a preliminary scan of the tystream and allow them to adjust the offsets manually at the key points. Tytool seems to just use a single best-fit approach which has worked well enough but still isn't always perfect. There are times I wish I could see and manually adjust the A/V sync at key points. I am in no way criticizing Tytool but it's just an inherent problem given the stream defects. GIGO, like always.

[dlang]

the problem with adding frames is that you distort the timing of the ones that are already there.

if you want the frame to be timed like this
1 1 1 1 1 1 1 1 1 1
but they are timed like this
1 1.2 1 1.5 1.5 1 1.3 1.5
(note that both of these streams cover the same time, even though one has 8 frmaaes and the other 10)

exactly what timestamps will you put on your new frames and where in the stream will you put them?

[olaf_sc]

Hello,

Yes,the observation is both right and wrong however it's a interesting observation that needs to be delt with.

If we talk about a demux to ES streams
(raw audio/video) well then there is no time stamps hence the matter is of no interest.

If we talk about a internal mux or an demux to PES streams (ES streams with PES headers). Well then there will be a issue. However my intensions is that when we detect a framerate shift we will adjust all PTS time stamps until we shift back to the correct framerate again.


Originally posted by dlang
if you want the frame to be timed like this
1 1 1 1 1 1 1 1 1 1
but they are timed like this
1 1.2 1 1.5 1.5 1 1.3 1.5
(note that both of these streams cover the same time, even though one has 8 frmaaes and the other 10)


Nope you are wrong, they will cover different time unless you change the frame rate in the SEQ header. It's only when you have PTS time stamp present that they will cover the same time. However having the wrong amount of frames compared to the frame rate and forcing sync with PTS time stamps is simply not a good thing (tm).

Cheers and thanks for the feedback

Olaf

[olaf_sc]

Hello RC

Originally posted by rc3105
the same info needed to maintain sync on-the-fly is tremendously usefull for auto detecting commercials. by combining that with info about the cc data, frame rates, ratio of I vs P & B frames & AC3/mpeg - video aspect ratio shifts we can probably get it automated quite nicely.


Hmm, have not yet probed a SA stream for framerates but since they aren't aware of what the content is - well I think they will not shift in frame rate hence no detection. Well SA probably drift in sync although but thats another problem however delt with in the same fashion.


olaf has said he also intends to release his utils as a set of libraries. that will make writing these sort of utils SO much easier.


Yes, it's even in the TODO-README, anyways the c file holding the main loop is just 100 lines or so the rest is "library" functions. All I need to do is to clean it up and have some values in private data access holders so you don't thinker with them without knowing what you do.

Cheers Olaf

[dlang]

Originally posted by olaf_sc
Nope you are wrong, they will cover different time unless you change the frame rate in the SEQ header. It's only when you have PTS time stamp present that they will cover the same time. However having the wrong amount of frames compared to the frame rate and forcing sync with PTS time stamps is simply not a good thing (tm).

Cheers and thanks for the feedback

Olaf [/B]

however the VFR of the dtivo means that in case #2 these are the only frames that you have, and these 8 frames are played in the same 1/3 of a second that the 10 frames of case #1 are played in.

yes this is in violation of the MPEG specs, but VFR is in violation of the MPEG specs and it's reality in the dtivos.

the headers claim 29.97 frames/sec, but the reality is something less then that, changing without notice. unless the result of your muxing is a mpeg stream that contains a timestamp for each frame you have no chance of keeping the sync through playback.

now if you want to move the frames around and add additional frames to make it CFR instead of VFR then my question is valid

the two cases stated another way both take 1/3 of a second to play

frames should be displayed at
case #1
.03 .06 .1 .13 .16 .2 .23 .26 .3 .33 seconds

case #2
.03 .07 .11 .16 .21 .24 .28 .33 seconds

if you just duplicate frames and sorten the display time of the existing frames to make room for them you will end up with the video stuttering

[olaf_sc]

Hello Folks,

Let me clarify MPEG and the sync issues we have in regards to it.


First there is no such thing a VFR!!!
Instead we have a shift it the frame rate from e.g. 29.97 to 23.976, period!
This is totally leagal and in compliance with the MPEG std for Transport Streams (which DTivo is derivate of). 1*
The only thing Dtivo is breaking is that they

Don't end the video sequence when they shift frame rate
Don't specifiy it in the seq header
Shift frame rate in the middle of a GOP/SEQ



Now over to the details about adding removing frames in order to comply with the frame rate.

Let me give an example, let us say that we have probed the stream and found out that the stream is mostly has a frame rate of 29.72f/s. For one reason or the other DTivo mixing in small portions that has a frame rate of 23.976 f/s.

Now let us first think that we a frame rate of 29.72 f/s how the heck is that displayed on your TV that has a frame rate of 59.94f/s?

Simple answer every frame is duplicated i.e. showed twise.

Now how is 23.976 f/s encoded mpeg showed on your TV which has a frame rate of 59.94 f/s (by a good mpeg decorder)?

Simple two film frames will be down pulled to 5 frames this is called 3-2 down pull. This is done every time you e.g. watch a DVD on your TV (unless the source is of the film is TV and not film).

See this is common stuff and has been done over and over again and there is no reason what so ever that we can't do it :). Allthough we will do it between 29.97 and 23.976 ane we do it both up and down so to say. We will simply up/down pull 5 to 4 and 4 to 5.

The bottom line is that if you don't use PTS timestams i.e. you do a simple demux you will never have to worry about frame rates, duplicated frames and so forth, period!

Tydemux will produce a perfect MPEG Video stream and audio stream (MPEG or AC3).

Tydemux will check and repair every thing, gaps/holes, temporal reference, video drift, frame rate and so forth.

Yes, internally I have taken care of adjusting the PTS time stamps but that's for the reason that I want to do an internal mux later on in version 0.5.0.

Now the advantage of having a perfect MPEG stream instead of one that forcefully is muxed with help of PTS time stamps is:


You will be able to use your favorite muxer
You will be able to transcode, edit, alter etc as much as you want and still have sync.
It will be a legal MPEG program stream - shifting anything (beside the bitrate) is not allowed in a MPEG Program Stream!! 2*



Cheers Olaf

PS: Yes version 0.4.0 will have a switch which makes you able to choose if you want to fix the frame rate or drop segments with faulty frame rate.

PS: MPEG Program Streams are e.g. used in a DVD, MPEG video file, VSCD etc..., MPEG Transport Streams are used in DSS/DVB, HDTV, ATM video networks, i.e. in places where we can have loss of data! (Yes, DSS/DirecTV is not really MPEG Transport Stream there are small differences).


PS:Hmm, just a small side note. calculating the frame rate by counting frames over one second in a BIG no no. Since the frame rate is not even i.e. 29.97 (or 23.976). Counting over one second will make it drift! Some seconds simply must have 29, 30, or 31 frames per second it will not add up other wise.


1* The std says for a decoder to be in compliance with a Transport Stream it must be able to allow some discontinuites at the video sequence boundery. Namely any parameter set in the sequence header which e.g. includes the frame rate!

2* Most of us want to produce a DVD or SVCD of our Tivo recording. Having a invalid program stream is not a good thing even if most players will play it just fine. No, let us instead fix the stream and produce valid program streams!

[rd001]

Originally posted by olaf_sc


The only thing Dtivo is breaking is that they[list=1] Don't end the video sequence when they shift frame rate
Don't specifiy it in the seq header
Shifts framerate in the middle of a GOP/SEQ[/list=1]So, it's all perfectly legal except for these horrible little omissions that break the MPEG standard in much the same sense that a roadmap is a perfectly good map even if it omits those portions of the road that lead the driver straight over a cliff.

You are really too kind to those DTV MPEG perverts. Olaf, you should be canonized as the patron saint of long-suffering charity toward infidels.

But thank you for that explanation. It reminds me very much of some earlier discussion of these broken streams.

The real question I always have after reading explanations like this from you or jdiner is this: how the hell does a DTivo or any other DTV box decode this stream as well as it does given the state of the input stream? After all, they can't be using much in the way of stream look-ahead scanning. Somewhere in those DTivo boxen and other lesser IRDs, there's a simple and nasty kludge to make all this MPEG confusion work without gross visible effect.

[dlang]

for playback it's simple, instead of having the playback code look at the framerate and calculate when to show each frame they just have it look at the timestamp of each frame and display it then (in relative terms that is, when you switch to a steam the first timestamp you find is 'now')

in many ways it's a simpler job to do, and since they control the streams and can therefor be sure that there will always be timestamps in it this will always work

[dlang]

If the framerate is as consistant as olaf thinks it is it should be very useful for spotting commercials at least during movies where the programe frame rate is 24 fps

olaf can you have your program print timestamps of when the frame rate shift happens so we can compare that to the commercial slots?

[olaf_sc]

Hello dlang

You nailed it :). Thats just how they do it.

Cheers Olaf


Originally posted by dlang
for playback it's simple, instead of having the playback code look at the framerate and calculate when to show each frame they just have it look at the timestamp of each frame and display it then (in relative terms that is, when you switch to a steam the first timestamp you find is 'now')

in many ways it's a simpler job to do, and since they control the streams and can therefor be sure that there will always be timestamps in it this will always work

[olaf_sc]

Hello Dlang

Yes, thats a walk in the park to implement (will provide a switch to turn it on and off).

I will make tydemux print the first time stamp and then print a time stamp every time the frame rate shifts.

Cheers Olaf


Originally posted by dlang
If the framerate is as consistant as olaf thinks it is it should be very useful for spotting commercials at least during movies where the programe frame rate is 24 fps

olaf can you have your program print timestamps of when the frame rate shift happens so we can compare that to the commercial slots?

[AlphaWolf]

olaf_sc: I'm not a coder but heres my contribution, I fixed a big amount of spelling and grammatical errors in both your code and the documentation as requested per the README, without interfering with the program itself. Heres the diff -u output dumped for all files that were changed, and then .bzipped, just whack off the .txt extension of course.

Also not being rude, just it looks like English isn't your first language, and two words you commonly misspell are commercial and twice. ;)

Enjoy :D

[olaf_sc]

Hello AlphaWolf,

BIG thanks for the patch it was really needed. I didn't prioritized spelling, grammar for five seconds. Hence a check/fix was badly needed.

To you all this is the kind of help I really need besided bug reports. It's really helpful and offloads me quite a lot.

Originally posted by AlphaWolf
Also not being rude, just it looks like English isn't your first language


No shit Sherlock :D, besidedes I'm also slightly dyslectic.

Cheers Olaf

[AlphaWolf]

Didn't thoroughly fix all of the grammatical errors mind you though :P

Just fixed the ones I noticed while looking for spelling errors. I'll probably take a deeper look after the next release, b/c the changes there were big enough already :D

[BillyZ]

olaf -- Kudos on Tydemux -- ive been waiting months for a program like this -- now im starting to extract/burn gigs and gigs of .ty files ive saved and archived that couldn't be split with the older apps.


Question: I have run into several anomolies with various .ty files that you may want to look at, what would be the best way to get these to you....posting a snippit of the out put or uploading a 1.5gb .ty file to an FTP site?

any timeline for the 0.32 release? Im eager to break the 2gb barrier (i have 4 'Taken' Eps that need to be demuxed ;) )


Cheers

=-BillyZ

[rd001]

Originally posted by olaf_sc
[Olaf responding to dlang's inquiry about outputting a list of frame rate changes to aid commerical detection]: Yes, thats a walk in the park to implement (will provide a switch to turn it on and off).

I will make tydemux print the first time stamp and then print a time stamp every time the frame rate shifts. Given the relatively uniform practice of upping the volume of commercials, sometimes to ridiculous levels, would monitoring the audio stream and calculating its relative volume be of any help in confirming where commercials are placed?

If you found a place where the frame rates change and the volume suddenly surges, that would be a pretty strong indicator. Maybe it would be of limited usefulness though. I just keep thinking that ReplayTV seems to have a pretty good way to detect commericals and it can hardly be rocket science.

[olaf_sc]

Hello BillyZ

In regards to a time line for 0.3.2, there will be no 0.3.2 :). There will be a 0.4.0.

The version bump is due to the large amount of new functionality. Hence next version will be 0.4.0, which means that 0.5.0 will have internal MPEG muxer and internal audio transcoding and 0.6.0 will have muxed DVD/SVCD compliant MPEG program streams.

I expect to release 0.4.0 before the 14 of Dec. Now what will 0.4.0 bring us?


Check and fix of temporal reference
Check and fix of frame rate
Check and fix of drift in audio/video sync
Check and fix of missing frames
Check and fix of max bit rate
Port to Mac OS 10.x, Solaris etc..
Removed 2GB barrier







Originally posted by BillyZ
olaf -- Kudos on Tydemux -- ive been

Thanks :)

Question: I have run into several anomolies with various .ty files that you may want to look at, what would be the best way to get these to you....posting a snippit of the out put or uploading a 1.5gb .ty file to an FTP site?


May I ask what kind of anomolies? Then I think we can figure out how to get those anomolies to me :). I have a ftp site 66.121.15.34 but before we start uploading it might be good to figure out what is happening and then start upload.

Cheers Olaf

[olaf_sc]

There is several ways of detecting commercials, volume, frame rate change, closed captions, channel log on/off, black frames, etc...

Taken all of those together and you will be able to detect and remove commercials with high precision. Now this is something for past 0.7.0 or soo since I better get other things going. However I preparing for it by 1: writing the code in such way that it's possible 2: Allready providing hocks for some of the info in the present code base.

Cheers Olaf

Originally posted by rd001
Given the relatively uniform practice of upping the volume of commercials, sometimes to ridiculous levels, would monitoring the audio stream and calculating its relative volume be of any help in confirming where commercials are placed?

If you found a place where the frame rates change and the volume suddenly surges, that would be a pretty strong indicator. Maybe it would be of limited usefulness though. I just keep thinking that ReplayTV seems to have a pretty good way to detect commericals and it can hardly be rocket science.

[und420_247]

Wow, can't believe the progress being made here. Incredible job, Olaf!

Also, the news of a MacOSX port really makes me happy. Just got a Mac and I'd love to start using it for this purpose.

[racingclub]

I expect to release 0.4.0 before the 14 of Dec. Now what will 0.4.0 bring us?

Check and fix of temporal reference

Check and fix of frame rate

Check and fix of drift in audio/video sync

Check and fix of missing frames

Check and fix of max bit rate

Port to Mac OS 10.x, Solaris etc..

Removed 2GB barrier


roll on the 14th :) - great work Olaf! :D

[saltydog4791]

The port for OS X will make my life so much simpler. The 14th can't come fast enough. I think I might be able to finally ditch my windoze box. :)

saltydog4791

[AlphaWolf]

Hopefuly we can finaly edit our resulting mpegs with any editor, without losing sync as well :D. Sounds like we are upon it.

[icculus]

Originally posted by AlphaWolf
Hopefuly we can finaly edit our resulting mpegs with any editor, without losing sync as well :D. Sounds like we are upon it.

I'm not sure how this tool helps that. Do any editing tools support mpeg input? I've been converting to .avi with DVD2AVI and VFAPIConv. What would you be using to, say, edit commercials out?

Olaf - been lurking for a while. I'm very excited to see the end product!

[BillyZ]

I already got a jump-start on a decent front-end, just waiting to include the new "Oh Four Oh" code....

What do you suppose are the odds of programs like SonicFoundry's VideoFactory and TMPGenc having the abillity to open and read .ty files....


then my life would be complete.


god i need a life.

[AlphaWolf]

icculus: womble mpeg vcr does

[olaf_sc]

Hello BillyZ,

You should wait with building a frontend until tydemux is modularized, i.e. when it's a lib and a small frontend (tydemux). Then you (and others) can start making really cool frontends. I will try to make the clean up after the 14:th so that it's a lib in version 0.4.1.

Cheers Olof


Originally posted by BillyZ
I already got a jump-start on a decent front-end, just waiting to include the new "Oh Four Oh" code....

What do you suppose are the odds of programs like SonicFoundry's VideoFactory and TMPGenc having the abillity to open and read .ty files....


then my life would be complete.


god i need a life.

[BillyZ]

Sounds like a plan...im going to wait until .4 to see if any of those anomolies dissapear -- Most of them are GOP errors anyway.



Originally posted by olaf_sc
Hello BillyZ,

You should wait with building a frontend until tydemux is modularized, i.e. when it's a lib and a small frontend (tydemux). Then you (and others) can start making really cool frontends. I will try to make the clean up after the 14:th so that it's a lib in version 0.4.1.

Cheers Olof

[Pr.Sinister]

Originally posted by icculus
I'm not sure how this tool helps that. Do any editing tools support mpeg input? I've been converting to .avi with DVD2AVI and VFAPIConv. What would you be using to, say, edit commercials out?

Olaf - been lurking for a while. I'm very excited to see the end product!

MediaWare Solutions' M2-Edit does it,
Womble's MPEG2VCR does it,
Honestech's MPEG Editor does it,
Adobe's Premiere does it,
Sound Foundry's Vegas Video & Video Factory do it,

etc...

There are a LOT of editing tools for MPEG out there...
MPEG is the most widely used format for video
(actually that just speculation on my part) ;)

-Pr.

[icculus]

Originally posted by Pr.Sinister
MediaWare Solutions' M2-Edit does it,
Womble's MPEG2VCR does it,
Honestech's MPEG Editor does it,
Adobe's Premiere does it,
Sound Foundry's Vegas Video & Video Factory do it,
-Pr.

Thanks for the info. I'm sorry to drag this more off topic, but are any of these freeware?

I don't really want to invest hundereds of dollars in such a package. I did pony up for Pinnacle Studio for my DV work, and otherwise use Virtualdub/TMPGenc, and the other motley crew of (free/cheap) tools for other work.

thanks!

[artships]

Originally posted by Pr.Sinister
MediaWare Solutions' M2-Edit does it,
Womble's MPEG2VCR does it,
Honestech's MPEG Editor does it,
Adobe's Premiere does it,
Sound Foundry's Vegas Video & Video Factory do it


Um, I think TMPGEnc, when frame-served by DVD2AVI, and even by itself, does it, too. And it is an editor. I've removed many an advert with it.
Here's how I do it. (http://tivo.30below.com/jdouglass/)

John,
Much anticipating .0.4.0...

[icculus]

Originally posted by artships
Um, I think TMPGEnc, when frame-served by DVD2AVI, and even by itself, does it, too.


Right, but TMPGenc is not, AFAIK, an editor. This was in regards to editing the MPEG2 file (to edit out commercials). I'm looking for something with the functionality of Virtualdub (an awesome app once you get used to the interface)

[BillyZ]

Womble has many issues when it comes to Muxing with out drivting the audio too much...i noticed that it does not do a good job of calculating the filesize properly...a 800MB video + a 70KB audio <> 6149GB...

Sonic Foundry's (both vegas video and Video factory) will NOT import Mpeg2 videos right from the tivo...they have to be processed which either A.) takes too much time or B.) loses quality.

so far the best one ive used that causes the least headaches is TMPgenc plus -- but still it doesn't always work correctly...which is why i gave up re-encoding all together, and just Author DVDs and 'blank' out the comercials by using chapters.



Originally posted by Pr.Sinister
MediaWare Solutions' M2-Edit does it,
Womble's MPEG2VCR does it,
Honestech's MPEG Editor does it,
Adobe's Premiere does it,
Sound Foundry's Vegas Video & Video Factory do it,

etc...

There are a LOT of editing tools for MPEG out there...
MPEG is the most widely used format for video
(actually that just speculation on my part) ;)

-Pr.

[BillyZ]

Excellent site -- its good to know that other ppl are suffering thru this as I -- I use DVD Maestro to author the movies -- only because i can tell it to skip over the chapters that are commercials -- but I will try using TMPGENc with the DVD2AVI part in it -- that would be nice to speed up that specific step.

-BillyZ

Originally posted by artships
Um, I think TMPGEnc, when frame-served by DVD2AVI, and even by itself, does it, too. And it is an editor. I've removed many an advert with it.
Here's how I do it. (http://tivo.30below.com/jdouglass/)

John,
Much anticipating .0.4.0...

[icculus]

Originally posted by BillyZ
Sonic Foundry's (both vegas video and Video factory) will NOT import Mpeg2 videos right from the tivo...they have to be processed which either A.) takes too much time or B.) loses quality.


Yes, but do they import an MPEG that has been muxed by vsplit or tyremux? Neither of those takes much time, and I wouldn't see how that would lose quality, either.


so far the best one ive used that causes the least headaches is TMPgenc plus -- but still it doesn't always work correctly...

Right, but again, TMPgenc is just an encoder, it's not an editor, so how would you edit out commercials with it??

(I posted just as BillyZ was above; ignore me) =)

[olaf_sc]

Hello Folks,

Okay a little update :) and reminders.

I just bought a Mac G3 400MHz box and MacOS X (jaguar) to go with it. Hence I should now be able not just to port tydemux but also test and develop under Mac.

I already have a Sun box so the next release will have binaries for Windows Linux, Solaris and Mac. Anybody using AIX?? If there is then I will start up my RS6000 after X-mas and make a port :).

Code updata is that all temporal reference checks and fix functions are in place - and that I'm now finishing of the frame rate and frame drift functions. As I said before I really want to have this out the door before the 14th.

Now, a small reminder I know it's easy to start talking about all kinds of apps and what they are capable of. However this thread is about tydemux, I therefore in a very soft and mild tone say "please keep it to a minimum" :). NOTE: that it's very!! okay to discuss such things as this app does or doesn't work with tydemux and why it is like that!.

Cheers Olaf

[OS X]

Originally posted by olaf_sc
Hello Folks,

Okay a little update :) and reminders.

I just bought a Mac G3 400MHz box and MacOS X (jaguar) to go with it. Hence I should now be able not just to port tydemux but also test and develop under Mac.



Great news!

You've got about the lowest end hardware that's still capable of running Jaguar. I have a Dual G4 800 with 1G RAM. I'm a bit of a newbie with TiVo and *nix, but I'll help however I can if you need anything.

[BillyZ]

Yes, and im thinking because they re-write the header which is what VideoFactory is looking for, but you can import some split mpegs because you are able to import seperate audio and video.

Originally posted by icculus


Yes, but do they import an MPEG that has been muxed by vsplit or tyremux? Neither of those takes much time, and I wouldn't see how that would lose quality, either.

[/B]

Originally posted by icculus


Right, but again, TMPgenc is just an encoder, it's not an editor, so how would you edit out commercials with it??

(I posted just as BillyZ was above; ignore me) =) [/B]

because Mpegvcr can read the file and can scan through it very fast, i use it to mark the times for the comercial start & stop.

then i either A.) use tmpgenc to merge and cut the mpeg (after muxing) or i import it into DVD maestro and import the list as a chapter file.

[olaf_sc]

Maybe you have better connections but I can't pickup a Blue & White G3 400MHz / 256 MB / 9GB SCSI - for that kind of a price. At least not when I need it the same day as I did in this case (test and compile tydemux for mac). Maybe I paid to much for it ($460)? In all with a visit to CompUSA to get Jaguar and new keyboard/mouse the whole thing costed me $720. Anyways I'm happy needed to learn MacUnix anyway, and it's nice to get tydemux running on Mac since there are some Mac users out there :).

Hmm, inorder to write something about tydemux - functions for fixing 29.97 f/s frame rate in a 23.97 f/s movie is now ready. Over to the other way around. Ahh, UK folks this is only DTivo - SA and SA UK only have problem with sync drift which is a whole lot easier - walk in a park compared to frame rate altering.

Cheers Olaf

Originally posted by rc3105
well, not quite the lowest end

but why the heck not when you can pick one up for less than a turbonet card

:D

--
Riley

[salfter]

Originally posted by icculus

I don't really want to invest hundereds of dollars in such a package. I did pony up for Pinnacle Studio for my DV work, and otherwise use Virtualdub/TMPGenc, and the other motley crew of (free/cheap) tools for other work.


Lately, I've been using Avisynth (http://www.avisynth.org/) with an MPEG-2 decoder plugin (http://www.avisynth.org/index.php?page=Section+3%3A+Filters+and+colorspaces#q34). You use DVD2AVI to create a .d2v from an .m2v or .mpg file, use LAME to convert from .m2a to .wav, then create a script that looks something like this:


LoadPlugin("c:\path\to\mpeg2dec.dll")
DelayAudio(AudioDub(MPEG2Source("c:\foo.d2v"),WAVSource("c:\foo.wav")),delay)


Save this to foo.avs, then load that into VirtualDub, TMPGEnc, Windows Media Player, etc. (Note that you'll need to disable the "DirectShow Multimedia File Reader" VFAPI plugin in TMPGEnc for this to work.)

Avisynth also provides editing capabilities of its own that are comparable to VirtualDub (better in some ways, such as its non-linear editing capabilities). Nowadays, I mainly use VirtualDub just to find the cutpoints for some ripped video and to verify that the audio and video are synced. I do all of the editing with Avisynth and create a script that's ready to encode with TMPGEnc with no additional processing.

[rc3105]

Originally posted by olaf_sc
Maybe you have better connections but I can't pickup a Blue & White G3 400MHz / 256 MB / 9GB SCSI - for that kind of a price...
Cheers Olaf

I hit the computer shows ocassionally. (halfway tween a trade show and a swap meet) I used to make that circuit as part of my computer business but the last couple of years I'm mostly just a spectator.

last fall I picked up 5 beige g3-333 tower servers for $225 for the whole lot. (installing X on an 8500 was a nuisance) they're a notch down from the blue & white but I like them because they were the last model with motherboard scsi, com ports and a floppy drive.

there's a show here in san antonio tomorrow, I'll let ya know what stuff's goin for. I'm trolling for a g4 notebook or an emac.

--
Riley

[olaf_sc]

Update:

Will not be able to release tydemux on the 14:th :( , well well not the end of the day I hope. It will just be delayed a couple of days good estimate is probably around the 16:th to 19:th of December. My kids are coming over and I want to spend some time with them, hence my eager try to make it until the 14:th :).

After releasing I will spend a couple of days fixing bug reports (sure they will come) then it's time to clean up tydemux. So it can be a library (libtydemux) and a small frontend app (i.e. tydemux it self). Will try to provide both a cli frontend app and a GUI (QT) one as examples for you how want to make your own cool frontends.

Cheers Olof

[rd001]

Go do the family thing. No need to explain anything, Olaf.

It's not like anyone is paying you a salary or something. It's just a hobby. We'll be happy with anything you distribute, whenever you get around to it. If people are too impatient, they can work on your source code, can't they?

[FredThompson]

Originally posted by salfter
Lately, I've been using Avisynth (http://www.avisynth.org/) with an MPEG-2 decoder plugin (http://www.avisynth.org/index.php?page=Section+3%3A+Filters+and+colorspaces#q34).

There are better MPEG2DEC routines. Try this one: http://nic.dnsalias.com/ It doesn't need the whole d2v aspect.

[salfter]

Originally posted by FredThompson
There are better MPEG2DEC routines. Try this one: http://nic.dnsalias.com/ It doesn't need the whole d2v aspect.

I think I tried that before and found that it didn't work as well. With some sources, you still need DVD2AVI to separate the audio and video anyway. I'm not sure where I got the DLL that I'm using...it's 108K and is dated 25 Sep 02, if that narrows it down any. (I've put it up at http://alfter.us/files/mpeg2dec_pp_mod_b3.zip, if anybody's interested.)

[FredThompson]

Different DLL. Try Nic's and see if it works better. He's one of the tech guys involved in developing XviD. It's just possible he might know what he's doing.

The nice thing about his is you don't need DVD2AVI.

Take a look at this stuff also, it's an offshoot of what has become a very active doom9 focus on adding proper MPEG2 to VirtualDub/AVISynth:

http://smokeslikeapoet.d2g.com/

There's also this little gem that's not that visible. The code is GPL'ed so I'm wondering if it would be helpful making a Windows client for editing.

http://www.flaskmpeg.net/

VirtualDub code is also available but both editing panes are in the same window. That's really awkward with large source.

Personally, I'd like a version of VirtualDub that works in MPEG2 non-destructively but maintains everything else. Basically, if there are no filters applied and the source is MPEG-2, it stays MPEG-2 with the exception of truncated GOPs being converted to I frames. Oh, and with a few other GUI changes (floating windows, user-defined crop bar color, etc.)

That really shouldn't be too hard. It needs a flag to denote processing (other than cutting) and an alternate path for the save routine.

Oh, keep an eye on this thread:

http://forum.doom9.org/showthread.php?threadid=39941

neuron2 is Donald Graft. He runs the VirtualDub/AVISynth board that hosts my link lists. Uh...he's also very knowledgable about commercial MPEG-2 streams in North America. trbarry and Marc FD are also quite experienced with this stuff. It's a good thread.

And, while I'm at it, here's the Tektronic MPEG reference:

http://www.tek.com/Measurement/App_Notes/mpegfund/

[laserfan]

Olaf gently suggested some time back that posters should kindly stay on-topic. Remember please that Olaf is forced to read every one of these looking for some relevance to tydemux.

If you want to start another thread by all means do it! And now I have contributed to the "noise" myself! Sigh.

[FredThompson]

What should be obvious if you follow the links:

Two Open source GUIs for video editing
Open source MPEG-2 stream debugging and cleaning of buggy streams
Commercial MPEG-2 streams in North America. Gee, what might I be implying?

The non-TiVo-specific community working on MPEG-2 is far greater than just a few people hanging out on this board.

You could look at post #1 in this thread:

This is to be a place where we can all trade ideas, discuss the tydemux code base (and the up comming tyremux) and MPEG coding in general. It's GPLed application so you are all welcomed to partisipate/develop or just look at the code in general. Let it inspire so that ideas, code and every thing flows freely.

[AlphaWolf]

hmmmph...I took one of the videos coming from the menu background on a series 1 directivo with s/w version 3.1, and I looked at it with a hex editor, and the magic number for a tystream header is there, as well what appears to be a very basic master chunk. Look what happens when you have tydemux process it:


Probing TyStream .....

Tystream recorded on: