Musings on DGMPGDec 2.0.0

[foxyshadis]

How hard would it be to set ctrl-z to a "revert last change" and ctrl-y as "redo last revert" (like many text editors) so that you could easy step back and forth through cut changes if an accident occurs?

[reefshark]

How about the ability to demux subtuitles and produce a celltimes.txt list of chapters. That produces all of the assets needed to do a basic backup of a DVD.

[nnigam]

I see most users prefer the vdub method, but the problem I have with it is that apparent frame numbers then change and getting the original number incase I want to trim in vdub becomes useless. I use hdtv2mpg2 to cut and then dgindex to process. Having both on one app would be a time saver. How about a cut list like projectX that was mentioned in one post. If order of cut points could be changed that would be even greater. I had a problem with one of my home videos from two different sources. I had to save several d2v project files to be able to re-arrange them on the final output. This may not be used much for HDTV capture, but would be great for editing and shuffling home videos.

[jfcarbel]

I like having a list of cut points (in/out of stuff to be removed) in a list as I go along making cuts. This way I have the option to go back and edit the cut points, say maybe extending the out frame of the third cut in my list. I also favor the VDub way of editing, ie cut points are for removal.

Here is an example screen shot of how a Tivo MPEG2 stream editor called TYTools does a cut list in the GUI.

Scroll down the page to step 7 here to see a screen shot (notice the cut list in the upper right):
http://www.weethet.nl/english/tivo_extract_videos.php

I really look forward to a frame accurate VOB and MPEG2 editor that can keep audio in sync and not have to recode the MPEG2 because of edits. The best app I have seen that can do this now is VideoReDo, which I currently own and love. Prior to that it was Womble MPG2VCR. But I would love to see something open source so we can all learn the magic of how its done and build other tools upon it.

Keep in mind there is lots of quirks to the way other formats use the MPEG2 container (i.e Tivo with there irregular GOP lengths, HDTV captures, etc). Bitstream dropouts in TV streams because of bad weather or other issues causes the stream to be "polluted". Also I would like the development to keep in mind MPEG4 as it seems Tivo and other companies are moving this way for their HDTV streams.

[mrcorbo]

On issue #1, I also like the multi-select timeline as used in HDTV2MPEG.

And on issue#2, I would like to see the current functionality be preserved and then have the extra indexing done only if the user goes into cut mode. I think that gives the best of both worlds (and the code would be in there for the programs that access DGIndex via CLI).

[Inventive Software]

I'd like to see more use of multi-threads, if that's possible. It might make the indexing even faster!

[trolltuning]

One of the things that is a problem when building a video by making trims in AviSynth is that if you have a particular frame in mind for say a chapter starting point, the frame number will change after you make other trims. It would be nice if some one could build a plug-in so that you could enter the original frame number and get the new one. I don't know whether the choice in gui architecture you are talking about would affect the difficulty of doing this?

[levi]

I prefer the vdub interface and like the idea of dgindex including the ability to multi-cut.

I don't mind the scanning, but I would like the option to cancel or disable as I see fit.

I do also cast a vote for incorporating more (selectable) automatic error checking & correcting IE Trictical's TFM d2v correction(illegal transitions), mpeg2repair, projectx, etc

[berrinam]

I don't know why this thread died, and I'm sorry to bump it if there's a reason it stopped, but I just wanted to bring attention back to AviSynth cutting.

Just a quick revision of what people said about it earlier in this thread:
I am against full cutting support in version 2.0.0. The main reason is this:There are already GUI programs that will generate lists of trims for AVISynth. Is there some reason why MPEG-2 cutting needs special support?
which was countered by Doom9 saying that audio cutting in AviSynth is the problem:
It's not so much about the video as it is about the audio.. keeping the audio in synch when cutting is the really complex part. If it were just about the video, I agree with you that AviSynth would suffice, but since video generally goes with audio and there's no adequate solution for audio in case of cutting (no, decoding to wav and using in AviSynth doesn't count.. for starters audio encoders generally don't support AviSynth input, and there's no solution for 5.1 audio plus BeSweet is simply the best audio encoding tool and the audio functionality in AviSynth just cannot compete), cutting support in dgindex does make a lot of sense.
As a result, this line of thought was abandoned.

However, there have recently been changes to this situation. Namely, dimzon made a new tool called BeHappy (http://forum.doom9.org/showthread.php?t=104686), which manages audio encoding via AviSynth. This actually completely avoids BeSweet and instead uses separate commandline encoders. I believe that most popular encoders are already supported, and it is very simple to support new ones (if they take stdin input). This allows for AviSynth cutting, and I agree with mg262 that this is the best approach, as it allows cutting of anything that can be put into AviSynth as opposed to just MPEG2. Of course, I can't stop neuron2 adding cutting, but I would like it if I could still use DGIndex just for indexing without any additional complications.

My current approach for TV caps is to decode with DGIndex, then create an AVS file and cut with VDubMod and use BeHappy and MeGUI to encode audio and video respectively.

As to the cutting GUI: I've tried ProjectX, VDubMod and Mpeg2Schnitt. I really don't mind whether multiselect is used or not. I find VDubMod the best because:
-it previews much faster than ProjectX or Mpeg2Schnitt (this is probably because it is using an already-indexed source and it is written C++, not Java)
-it jumps by frames of 50 when pressing the seek bar. This may not seem like much, but it certainly speeds up finding the correct frame, because the accuracy of the slider is very low, so making big jumps makes it easy to get where you want.
-it has the scene change detection buttons, which are great for finding the exact frame, and they run very fast.

With VDubMod, I can cut out all the commercials very quickly, and I think an automated detection would actually be slower for me, because I would have to wait for the computer's analysis, and then I would have to check whether it was correct.

A summary of what I said:
-I use AviSynth for cutting, and I don't think it's necessary to have cutting in DGIndex
-audio in AviSynth is now completely feasible
-I don't have a preference for multiselect or not. The real issue is the speed of previewing, jump size, and tools like scene change detection.

[Zep]

A summary of what I said:
-I use AviSynth for cutting, and I don't think it's necessary to have cutting in DGIndex


yes it is necessary if you value your time. Why index parts of a file
that are gonna be cut? Why demux those parts? total waste.

The idea is that since you are in DGindex anyway you might as well
edit there but more importantly have DGindex FIX the streams and sync
audio like projectx does but better and faster (java is just so slow)
basically make sure it is good to go before avisynth ever sees it.

[berrinam]

yes it is necessary if you value your time. Why index parts of a file
that are gonna be cut? Why demux those parts? total waste.
When DGIndexing only takes about 5 minutes, cutting 20% off before the indexing only saves one minute. The difference is really not that much. And since I run my DGIndex jobs from MeGUI, I can queue them all up and run them all at once, so I don't even have to be at my computer waiting for them to finish.

On the other hand, if I used DGIndex to do my cutting, then I would have to load up DGIndex, wait for it to index the video so that I could have frame-accurate cutting, and then wait for it to process the rest (audio, and redoing the indexes). Look at the way people are currently suggesting that this might work:
The first step is DGIndex opens the file and does an index of the whole thing, so that you can seek and cut with frame accuracy. So, even if I used DGIndex, it would still have to index the whole thing anyway.

The idea is that since you are in DGindex anyway you might as well
edit there'Might as well'? Why not use the more powerful and more versatile AviSynth to do the cutting. That's what AviSynth is designed for? Since all of my DGIndexed projects go through AviSynth, I 'might as well' cut in AviSynth.

but more importantly have DGindex FIX the streams and sync
audio like projectx does but better and faster (java is just so slow)
basically make sure it is good to go before avisynth ever sees it.
I agree with you there. It should be DGIndex's job to handle all the MPEG-2 issues, and pass a completely in-sync, error-free video and/or audio stream to AviSynth. But this is not relevant to cutting, because if AviSynth has an in-sync audio stream, any cutting of both the video and audio will still keep it in sync, and the accuracy of AviSynth cutting should be higher than DGIndex audio cutting, because cutting AC3 is limited to the AC3 frame size, whereas AviSynth cutting is limited by the sample size, which is much smaller.

[mg262]

DGIndex, wait for it to index the video so that I could have frame-accurate cutting, and then wait for it to process the rest (audio, and redoing the indexes)Does that mean that it is possible to have frame accurate MPEG2 cutting without reencoding cut sections? I didn't realise that was possible.

I find cutting in GUIs to be tedious because of the difficulty of making fine adjustments. One suggestion to help with this would be to have both A) the main scrollbar for the video and a B) second scrollbar/slider to make fine adjustments. (So dragging B by a large amount would move A by a small amount. B would have to snap back to the centre when the mouse button was released, without affecting the position of A.)

I also like the replicability gained by using AVISynth -- the script is a precise record of what you have done to the video, including any trims. Of course, an intelligent cutting GUI could generate a short script including the relevant trims.

[berrinam]

Does that mean that it is possible to have frame accurate MPEG2 cutting without reencoding cut sections? I didn't realise that was possible. Not what I meant. From what I gathered from this thread, a lot of the cutting talked about wasn't actually MPEG-2 cutting, just cutting of the d2v file, so when decoding, it just skips a few frames -- exactly like AviSynth's trims.

I find cutting in GUIs to be tedious because of the difficulty of making fine adjustments. One suggestion to help with this would be to have both A) the main scrollbar for the video and a B) second scrollbar/slider to make fine adjustments. (So dragging B by a large amount would move A by a small amount. B would have to snap back to the centre when the mouse button was released, without affecting the position of A.) I think this is an interesting idea.

I also like the replicability gained by using AVISynth -- the script is a precise record of what you have done to the video, including any trims. Of course, an intelligent cutting GUI could generate a short script including the relevant trims.Tried VirtualDubMod? It can do that, and the cutting is very good (as I described earlier).