Idea for transport (and other) stream support

[Guest]

I have fast working code for converting transport streams to program streams that DVD2AVI can already read. What I am thinking is to launch the converter as a thread and have it write the stream into a named pipe that DVD2AVI opens and reads as if it is a normal file open. Of course, MPEG2DEC3 would do the same thing.

The advantages of this approach are that 1) it avoids messy stream-specific modifications of DVD2AVI parsing, 2) it allows for easy implementation and encapsulation of other input stream conversions (without making DVD2AVI a massive parsing spaghetti bowl), and 3) it simplifies adding transport stream support to DVD2AVIdg/MPEG2DEC3dg/VFAPIdg (because the basic idea is easy and because the same code can be used for all three).

The data rate of named pipes is about 150MBytes per second in XP and much higher in Win2000. It is more than adequate for this application.

The only downside I can see is that Win95/98/ME do not have named pipe support. But it's doubtful anyone working with transport streams is still using these defunct operating systems.

What do people think of this approach?

[Cyberia]

Sounds good but, what else could this be used for? MPEG1?

[Guest]

Originally posted by Cyberia
Sounds good but, what else could this be used for? MPEG1? You're a clever chap, Cyb. :)

It will also allow for future transport streams, and in fact inputting of any audio/video stream that one could write the converter for.

How about on-the-fly requantization?

Now I'm thinking of input plugins and chains. :)

[Guest]

Ah, yet another beautiful idea dies on the rocks of reality...

DVD2AVI issues fseek() calls. They can be passed back to the converter, but the converter has no efficient way to implement that because there is no a priori mapping between LBAs and transport stream contents. So sad. :(

[Cyberia]

I take it this is bad, but I am not sure I understand why.

[Guest]

When MPEG2DEC3 wants to jump to a given frame, he gets the LBA of the GOP from the D2V file. The LBA is an address within the VOB file (program stream). But how do we map back to the correct point in the transport stream file? It's just not as conceptually clean as I hoped.

I suppose that during "Save Project" the converter could generate an index of LBAs to transport stream offsets. Maybe all is not lost.

[Guest]

Actually it's feasible after all!

The converter needs to be able to support this API to DVD2AVIdg/MPEG2DEC3dg:

Seek to position in transport file
Tell position in transport file
Read parsed data from transport file

DVD2AVIdg would store the transport file position in the D2V and MPEG2DEC3dg would use it by means of Seeks to the converter.

If I decide to implement this, I'll make a NULL converter for normal program streams so that all decode types use the same framework.

The question is whether it has enough real advantages over integrated parsing to justify doing it this way.

[trbarry]

I still run Win/Me. Am I the last one? ;)

- Tom

[Zep]

Originally posted by neuron2
I have fast working code for converting transport streams to program streams that DVD2AVI can already read. What I am thinking is to launch the converter as a thread and have it write the stream into a named pipe that DVD2AVI opens and reads as if it is a normal file open. Of course, MPEG2DEC3 would do the same thing.

The advantages of this approach are that 1) it avoids messy stream-specific modifications of DVD2AVI parsing, 2) it allows for easy implementation and encapsulation of other input stream conversions (without making DVD2AVI a massive parsing spaghetti bowl), and 3) it simplifies adding transport stream support to DVD2AVIdg/MPEG2DEC3dg/VFAPIdg (because the basic idea is easy and because the same code can be used for all three).

The data rate of named pipes is about 150MBytes per second in XP and much higher in Win2000. It is more than adequate for this application.

The only downside I can see is that Win95/98/ME do not have named pipe support. But it's doubtful anyone working with transport streams is still using these defunct operating systems.

What do people think of this approach?


this is what i wanted for a LONG time. In fact we talked abut this
6 months ago before you left on your sabatical :D


Back then we talked about MPEG2DEC3dg reading the .ts file directly
so we didn't have do

1) DVDtoavi on .ts to make d2v
2) mpeg2source to read d2v in

but would instead be just

1) mpeg2source to read .ts in directly saving a huge step
and time waster.

[Zep]

Originally posted by trbarry
I still run Win/Me. Am I the last one? ;)

- Tom

haha too funny coming from you Tom because
as long as I have been in doom9 ( a few years
but in lurk mode mainly) you have always been
bleeding edge on apps and HDTV and the lead
dev on many things that others like myself
were scratching our heads on for the longest time :)




my guess most have moved to XP so... :D




BTW - I am surprised your HDTV card drivers work with
older OSes. Mine works only with XP.

[Guest]

Originally posted by Zep
1) mpeg2source to read .ts in directly saving a huge step
and time waster. Unless you do the indexing it becomes impossible to move around on the timeline in Vdub.

[Zep]

Originally posted by neuron2
Unless you do the indexing it becomes impossible to move around on the timeline in Vdub.

hmmm... Maybe you could take a look at the HDTVtoMPEG source code?


it moves around fine in the .ts and you can edit right in the app directly on the .ts file. You can then save it as a .ts
without the commerials you edited out ( or convert mpeg2 in stead of .ts) and delete the old .ts and save a ton of disk space but
still have the original HDTV episode stream


http://www.derangedkiwi.net/index.php?view=hdtvtompeg2

[Guest]

Originally posted by Zep
hmmm... Maybe you could take a look at the HDTVtoMPEG source code? I know that program very well. It is NOT frame accurate; it is GOP accurate, just like DVD2AVIdg. Step forward with it -- you don't see every frame. MPEG2DEC3dg must be frame accurate to allow seeking to any frame in VirtualDub. To allow that you have to index the locations of all the individual frames.

[Zep]

Originally posted by neuron2
I know that program very well. It is NOT frame accurate; it is GOP accurate, just like DVD2AVIdg. Step forward with it -- you don't see every frame. MPEG2DEC3dg must be frame accurate to allow seeking to any frame in VirtualDub. To allow that you have to index the locations of all the individual frames.

darn. I never noticed it was GOP level cause I do all mine in VDub
and only quick disk saver stuff in HDTVtoMPEG.

geez that is very disappointing.


Oh well your auto pid detection makes up for it :D

[Zep]

Originally posted by neuron2
I know that program very well. It is NOT frame accurate; it is GOP accurate, just like DVD2AVIdg. Step forward with it -- you don't see every frame. MPEG2DEC3dg must be frame accurate to allow seeking to any frame in VirtualDub. To allow that you have to index the locations of all the individual frames.

no way to stay GOP level but mini index from start of that GOP
too the end of that gop and send that for single frame movement?


Hmmm... how about if there is no "d:\thefile.index" when

mpeg2source("d:\thefile.ts")

is called then it creates one once and saves it to same dir
and then uses it? I'm just dreaming out loud now :D

[Guest]

If you load the file and want to jump to frame 23624, how do you do that without playing or indexing all the frames leading up to it? That is the essence of the problem. If you know of a way, let us all know. :)

>how about if there is no "d:\thefile.index" when
>is called then it creates one once and saves it to same dir
>and then uses it? I'm just dreaming out loud now

Helloooo?! That is the same thing as doing Save Project, which is what you were trying to avoid in the first place.

[Zep]

Originally posted by neuron2
If you load the file and want to jump to frame 23624, how do you do that without playing or indexing all the frames leading up to it? That is the essence of the problem. If you know of a way, let us all know. :)

>how about if there is no "d:\thefile.index" when
>is called then it creates one once and saves it to same dir
>and then uses it? I'm just dreaming out loud now

Helloooo?! That is the same thing as doing Save Project, which is what you were trying to avoid in the first place.

no it is not the same because it means i do not have to launch dvdtoavi
It saves ***ME*** a step and is less complicated to new users.

I never said i wanted to save YOU a step :D


IMHO it is about the user front being less complicated and easier for new users
trying to get into HDTV. When i got into it i remember the confusion i had
at first because i didn't understand WHY dec3 couldn't read the .ts directly
and WHY the heck did i have to do all these extra passes and what settings to do
in dvdtoavi also made me scratch my head. Now with stuff like Auto PID detection
you are taking steps to make it easier on the users so don't stop now :)

[Guest]

You originally wrote:

"1) mpeg2source to read .ts in directly saving a huge step
and time waster."

My point was simply that the huge time step cannot be eliminated as you suggested.

[Cyberia]

But if MPEG2DEC3 generated the project automatically, they could skip manually using DVD2AVI. It wouldn't save any time, but it would save a user step.

But that enhancement was already on the list.

[Zep]

Originally posted by neuron2
You originally wrote:

"1) mpeg2source to read .ts in directly saving a huge step
and time waster."

My point was simply that the huge time step cannot be eliminated as you suggested.

yes
.


Now of course I still want that index worked out in real time :)


but getting rid of the dvdtoavi step was also on my list and would save time for the user set up and multi app launch etc...

Sure a full index would have to be still done I guess but you
would still save some time VS the 2 step way, just not any
time on the index (darn)

[Zep]

Originally posted by Cyberia
But if MPEG2DEC3 generated the project automatically, they could skip manually using DVD2AVI. It wouldn't save any time, but it would save a user step.

But that enhancement was already on the list.


really you feel it would save no time?

i feel it would save some. I mean typing in PIDS
and launching dvdtoavi and all the other little things.

The auto pid has helped a ton though. Used to have to go into the
.ini now with dg's I do not.

[Cyberia]

I meant that you would still have to generate the project, but could skip the GUI. Obviously this would save time, but the project generation would still take the same time.

Conversly, the GUI would offer finer control for tough cases or perfectionists, but at the cost of a few moments setup time.

---

Back from Maui. :(
Kaha-boo

[Zep]

Originally posted by Cyberia
I meant that you would still have to generate the project, but could skip the GUI. Obviously this would save time, but the project generation would still take the same time.

Conversly, the GUI would offer finer control for tough cases or perfectionists, but at the cost of a few moments setup time.

---

Back from Maui. :(
Kaha-boo

right that is what DG and i were talking about. Having to still index
since you can only go GOP accuracy until you do. (I hope there is a
way to work around this. If one could be found it would be great)

[holden]

Thanks much, neuron2, for the DGMPGDec 1.06 package! It's noticeably improved over 1.04, too, crashing less.

Clipping and cropping have moved backwards a bit for me, however. With DVD2AVI, I understood that AviSynth's crop was faster than the clipping within DVD2AVI, but does that still hold true for DGIndex? Since DVD2AVI .d2v output was compatible with GKnot, I would use that for visually clipping the image. Now that DGIndex .d2v's are no longer GK compatible, I have to go back and forth more laboriously with hand-encoded tests from AviSynth scripts and VirtualDub to come up with proper clip/crop values.

DGIndex clipping has been coarse for me, too, typically jumping 8 pixels at a time. Finer would be nicer, with two pixels/keypress being adequate. Is there a way to toggle the squeezed visual? I like it squeezed down (e.g, from 1920x1088 to about quarter that (or whatever it is)), except for the feedback during clipping.

BTW, what does your typical relevant portion of AviSynth script look like for for a .ts that might be ~80% Film BFF? I'm partial to KernelDeInt(order=0,sharp=true).decimate(), but some of mind definitely need help. In what cases should FieldDeinterlace() be preferred over KernelDeint()?

Thank goodness I'll never have to step through another SeparateFields() pass, now that we have DGParse!

For the de-interlace panning jerkies, do you have a special AviSynth fragment that can do something to smooth out those?

What is the typical source of the illegal transitions? Can that be introduced by lousy post processing, or is it more likely introduced by faulty/too-slow capture? Thank God and neuron2 for DGFix!

HF

[Guest]

Originally posted by holden
Thanks much, neuron2, for the DGMPGDec 1.06 package! It's noticeably improved over 1.04, too, crashing less. FYI, today I am addressing what I hope to be the last of the crashing issues (when VirtualDub crashes on exit with a stream with an incomplete last frame).

Clipping and cropping have moved backwards a bit for me, however. The only change was to remove non-functioning menu items, so I don't understand this claim.

With DVD2AVI, I understood that AviSynth's crop was faster than the clipping within DVD2AVI, but does that still hold true for DGIndex? It was never true. DGIndex cropping just sets numbers in the D2V file. Then DGDecode internally invokes Crop() with those numbers. So there should be no difference in performance.

Since DVD2AVI .d2v output was compatible with GKnot, I would use that for visually clipping the image. Now that DGIndex .d2v's are no longer GK compatible, I have to go back and forth more laboriously with hand-encoded tests from AviSynth scripts and VirtualDub to come up with proper clip/crop values.? That's an issue for GKnot. I just serve the clip into VirtualDub, set a null filter and play with the cropping on that (you can visully see the results) and then take the numbers back to the AVS script.

DGIndex clipping has been coarse for me, too, typically jumping 8 pixels at a time. Finer would be nicer, with two pixels/keypress being adequate. That I can do. I've added it to the work list. Thank you for suggesting it.

Is there a way to toggle the squeezed visual? I like it squeezed down (e.g, from 1920x1088 to about quarter that (or whatever it is)), except for the feedback during clipping. A 1920x1088 frame already gets squeezed automatically, so I don't understand you. Unless there is a compelling reason, I'd rather leave it automatic.

BTW, what does your typical relevant portion of AviSynth script look like for for a .ts that might be ~80% Film BFF? I'm partial to KernelDeInt(order=0,sharp=true).decimate(), but some of mine definitely need help. Assuming there really are 80% progressive frames (the FILM % cannot always be relied on), I would use Telecide with postprocessing followed by Decimate with mode=3:

Telecide(guide=1)
Decimate(mode=3,threshold=1.0)

You may have to tweak thresholds.

In what cases should FieldDeinterlace() be preferred over KernelDeint()? KD is designed for true interlaced video and can do some funny things when applied to progressive material. FD is good on everything. Also, FD has the full=false mode that is absent from KD, so it's better suited to use as a post-processor.

Thank goodness I'll never have to step through another SeparateFields() pass, now that we have DGParse! Unless, of course, your source is not MPEG.

For the de-interlace panning jerkies, do you have a special AviSynth fragment that can do something to smooth out those? There are too many possible causes to make a universal prescription.

What is the typical source of the illegal transitions? Can that be introduced by lousy post processing, or is it more likely introduced by faulty/too-slow capture? The ones I have seen are bad right there on the DVD, so that has to be a mastering issue.

[holden]

Thanks for your helpful reply.

In that there are too many causes for jerkiness to offer a universal prescription, where could you direct me to read about the list of possibilities and what can be done about them? (Thanks in advance.)

It's certainly good to know that the clipping done in DGIndex is no more computationally expensive than an AviSynth crop, but that they are in fact done in the same way. If you get to the more finely granular clipping, I'll happily use DGIndex's clipping, but it only makes sense to do that operation one place, not twice. In the meantime, making adjustments text-parameter adjustments in my AviSynth script, save/click/dragging to VDub to view the results.

BTW, DVD2AVI would often report a 1088 tall video as being 816 pixels tall. Of course the crop parameter needed to presume it was 1088. What was that about? (DGIndex now seems to do them right.)

Your use of telecide(guide=1) complained on my machine as not having the order parameter specified. I'm using decomb521. Is there another version I should be using which is not tied to order?

As I tried to say earlier, I like the automatically-squeezed larger windows (e.g., 1920x1088) except when placing those clipping values. Maybe I just need new glasses.

I wasn't able to get sequential files to load automagically, as DVD2avi did. I thought perhaps the Open/auto-add was going to do it, but no. I hate to take up your time with such nits, but I did look pretty closely at all the .html that came with it (mostly very helpful, of course).

BTW, "conversion" is spelled that way unlike the 'convertion' on your DGDecode.html page. (Just trying to return your favors, here.)

I almost always get the complaint that my .ts had an unclosed opening GOP. I cut most of my starts with HDTVtoMPEG v1.10b (I think). I guess there's nothing I can do about that, or do you have a suggestion?

Could you put the TFF/BBF as an output to the Information dialog box? And what does "Info V.E.!" mean?

Wouldn't it make sense to have a preference checkbox for doing DGFix automatically, or perhaps on two levels, 1) to be prompted of illegal transitions with a question of whether or not to fix 'em, or 2) always just fix 'em and get it over with? I'm an old assembler guy from way back, but a CLI is still such a pain.

Muchas gracias,
HF

[Guest]

I prefer all feature requests to go into Cyberia's "Development List" thread, as your requests can get lost elsewhere:

http://forum.doom9.org/showthread.php?s=&threadid=74081&perpage=40&pagenumber=1

Originally posted by holden
In that there are too many causes for jerkiness to offer a universal prescription, where could you direct me to read about the list of possibilities and what can be done about them? (Thanks in advance.) Nowhere, but if you post a link to a source clip, I'll have a look at it for you.

BTW, DVD2AVI would often report a 1088 tall video as being 816 pixels tall. Of course the crop parameter needed to presume it was 1088. What was that about? (DGIndex now seems to do them right.) Sorry, but I am not interested in bug reports for other people's software. :)

Your use of telecide(guide=1) complained on my machine as not having the order parameter specified. I'm using decomb521. Is there another version I should be using which is not tied to order? You need to specify the order parameter. Refer to the Decomb tutorial if you don't know how to determine the field order.

I wasn't able to get sequential files to load automagically, as DVD2avi did. I thought perhaps the Open/auto-add was going to do it, but no. I hate to take up your time with such nits, but I did look pretty closely at all the .html that came with it (mostly very helpful, of course). Please exactly state the file name that you are opening and for which you are expecting auto add.

BTW, "conversion" is spelled that way unlike the 'convertion' on your DGDecode.html page. I know how to spell English words, but marcFD sometimes does not. :)

I almost always get the complaint that my .ts had an unclosed opening GOP. I cut most of my starts with HDTVtoMPEG v1.10b (I think). I guess there's nothing I can do about that, or do you have a suggestion? Be happy that my software isn't giving you macroblocks. Or frames that say "B-frame lag". :)

Could you put the TFF/BBF as an output to the Information dialog box? And what does "Info V.E.!" mean? I can do that. I've added it to the work list. "V.E.!" means "Video (decoding) Error". A bad coefficient for a macroblock, incomplete slice, etc.

Wouldn't it make sense to have a preference checkbox for doing DGFix automatically, or perhaps on two levels, 1) to be prompted of illegal transitions with a question of whether or not to fix 'em, or 2) always just fix 'em and get it over with? I'm an old assembler guy from way back, but a CLI is still such a pain. It's already on my work list.

You ask more questions than my pet cat. Keep 'em coming!

[holden]

Please exactly state the file name that you are opening and for which you are expecting auto add.
filename.0.ts
filename.1.ts
filename.2.ts

When you've got those exact file names hardwired in, I'd also like it to do:
LOTR3.0.ts
LOTR3.1.ts

...and just load up the proper video from Hollywood directly. :)

HF
You ask more questions than my pet cat. Keep 'em coming!
Holden the Feline is what I have my human do, too. I dictate, he types.

[Guest]

You need an underscore, i.e., filename_0.ts

What software is generating those filenames?

[holden]

'filename.n.ts', etc. is what rolls out of HDTVtoMPEG cuts.
It really wants to put such filenames out there, but as familiar
as you are with that program, I guess you knew that.

HF

[Guest]

I wouldn't have asked you had I known that.

[holden]

My bad. Even though HDTVtoMPEG apparently
does the '.n.ts' by default, I've discovered
it's trivial to make it do the '_n.ts', so
it should be smooth sailin' from here.
Thanks,
HF