DVD2AVIdg and Nic's mpegdecoder

[bond]

hi guys!

as i didnt find anything when searching for this issue, i wanted to ask how mpegdecoder fits with donald grafts new dvd2avi?

if nobody looked into it, can neuron2 plz also update mpegdecoder to work fine with the new version? i think many people use mpegdecoder as its simply much faster

thanks a lot :)

[Nic]

I'd prefer MPEGDecoder didn't get used as it still causes problems. I will update it one day to work correctly with NTSC. Once I've done ReJig though...Which may take some time ;)

-Nic

[bond]

:( i always used mpegdecoder as its faster than mpeg2dec3

are there any other issues than seeking and ntsc (which i both dont need)?

if no, can i safely use mpegdecoder with dvd2avidg?

[Nic]

Nope those are the issues.lol....pretty big ones though. ;) LoL...I once added NTSC support, but it made it the same speed as mpeg2dec3 so there was no point (this would have been due to my bad hurried coding though lol)

-Nic

[archimage]

Originally posted by bond
if nobody looked into it, can neuron2 plz also update mpegdecoder to work fine with the new version?

Just in case you did not know , DG`s on another sabbattical (http://neuron2.net/ipw-web/bulletin/bb/viewtopic.php?t=246)

[bond]

ok ic, thanks guys :)

[bond]

NIIIIICCC!!!

plz update mpegdecoder to work with dvd2avidg :)
its really great and fast and i dont need seeking or ntsc...

pleeeeaaaassseee :D

[jdobbs]

Nic,

I may be covering old ground... but how does MPEGDECODER differ from MPEG2DEC3? The reason I ask is, as I recall it just delivers frames and doesn't play with the original (depending upon RFF etc...) -- is that right? I was thinking that might come in handy for transcoding NTSC that alternates between telecined and not telecined -- as long as the original structure is recorded somewhere ahead of time.

Am I in the ballpark on this?

Thanks,
jdobbs

[Nic]

Yes you are....
MPEGDecoder - Unfinished Project #23231 ;)

It uses libmpeg2 which only delivers the frames and pays no attention to the repeat first field flag.

If it will be useful or not is for you to decide...

-Nic

[jdobbs]

Here's what I was thinking. In DVD-RB I scan the source myself to create the D2Vs. If, when scanning, I recorded the TFF and RFF state, framerate, and picture type data etc for every frame I should then be able to reencode with CCE or QuEnc (at some fixed framerate) and then reflag everything correctly when rebuilding... That way those pesky switches between telecining and not that has been plaguing us for so long might go away. Do you see any pitfalls in doing it that way?

[RB]

I'm a PAL user so my knowledge with NTSC is limited, but that sounds like an excellent idea.

Hmmm... I don't think you can choose some fixed frame rate when the stream is partially truly interlaced and partially telecined. What you want to do is get rid of the "false" frames generated by 2:3 pulldown so the encoder doesn't have to process them and keep the frame rate at 29.97 fps. I think DeleteFrame() in the AVISynth script could be a solution for this. IOW:
[list=1]
Create D2V, record frames generated from 2:3 pulldown, don't force film
Create AVS, use DeleteFrame() to delete recorded frames (maybe have to SeperateFields() first, I don't really know much about 2:3 pulldown :) )
Encode
Remux and add RFF flags where necessary using recorded information
[/list=1]
Am I making any sense?

EDIT:
Maybe even simpler than that: since you are in control of the D2V file, simply ignore the RFF flags and only ever write 0 and 2 to the D2V (depending on TFF flag), record the flags elsewhere. This way Mpeg2Dec will only return the "real" frames in the first place. Then add flags back during remuxing.

[jdobbs]

Originally posted by RB
Maybe even simpler than that: since you are in control of the D2V file, simply ignore the RFF flags and only ever write 0 and 2 to the D2V (depending on TFF flag), record the flags elsewhere. This way Mpeg2Dec will only return the "real" frames in the first place. Then add flags back during remuxing. Will that work???? Hmmm...

[jdobbs]

Hmmm... I don't think you can choose some fixed frame rate when the stream is partially truly interlaced and partially telecined. Mixing interlaced and telecined almost never happens.

[RB]

Originally posted by jdobbs
Will that work???? Hmmm...
I don't have any NTSC sources at hand, but just give it a try. I know Neuron2 is back from his sabbatical, I'm sure he knows better about this.
Originally posted by jdobbs
Mixing interlaced and telecined almost never happens
Never or almost never? :)

[RB]

Originally posted by RB
EDIT:
Maybe even simpler than that: since you are in control of the D2V file, simply ignore the RFF flags and only ever write 0 and 2 to the D2V (depending on TFF flag), record the flags elsewhere. This way Mpeg2Dec will only return the "real" frames in the first place. Then add flags back during remuxing.
Just occured to that this of course depends on whether Mpeg2Dec3Dg uses the flags in the D2V at all or does it's own interpretation of the decoded pictures...

[jdobbs]

Originally posted by RB
Just occured to that this of course depends on whether Mpeg2Dec3Dg uses the flags in the D2V at all or does it's own interpretation of the decoded pictures... I'm experimenting with this right now. It appears that I can get a good unprocessed stream of pictures from mpeg2dec3db.dll by setting all the .D2V file entries to "0" and setting field_operation=0. The frame rate output really doesn't matter... then you can apply the progressive, TFF, and RFF fields back at rebuild time... I ran it last night on an NTSC stream just to test.

[RB]

Hmm, '0' means BFF... doesn't this screw up the field order?

[jdobbs]

Just experimenting... I can make it match the source when it's interlaced ("0" or "2") -- and for progressive it doesn't seem to matter. The beauty is I get the exact number of frames as the original (no losing frames when telecining). I've looked back and I think some of the stuttering people are reporting are areas where the original was only telecined at some percentage so occasionally a frame gets dropped in the non-telecined areas. At least that's the only stuttering I can find...

[neuron2]

I just read this briefly but have a few comments.

In NTSC land, it is common to have VOBS with mixed 3:2 and non-3:2 sections.

You can strip all the repeat flags and get exactly only the encoded frames if you want that. If there are mixed sections, you won't be able to set a rational frame rate for the resulting clip however. If you want to re-apply pulldown later, sure why not, as long as you remember which sections need it. But why would that be better than doing it the normal way?

[jdobbs]

Because there are a lot of NTSC discs that switch back and forth repeatedly between telecined and not. If you try to use FORCE FILM, the non-telecined portions have frame loss and errors. By taking the frames one-by-one but logging the state of progressive_flag, TFF, and RFF (and frame_rate) -- you can reapply it after encoding for an exact duplicate.

[neuron2]

I guess I'm still confused. What do you mean by "after encoding"?

Please give a complete scenario telling me what tools you are applying at each stage so I can see why it is useful to you.

You must be doing some processing that requires to act on all the progressive frames before pulldown.

[jdobbs]

Here's what I do when rebuilding a DVD:

1. Scan the file and record flags while creating a .D2V. The D2V is all 0's, 2's, or a mixture of the two (if I want to keep the TFF in the D2V) -- also field_operation is set to 0 and I fix the frame rate (could be anything as long as it is legal to DVD) - I set it to 23976.

2. I then use AVISYNTH and MPEG2DEC3DG.DLL to present the resulting frames to CCE, which thinks it is encoding a 23.976fps frame based source.

3. After encoding, as I am rebuilding I apply, frame-for-frame the progressive_flag, TFF, and RFF that were recorded from the original and set the frame_rate back to what it should be.

In the end I get three advantages:

- First the processing goes a lot faster than if I were using FORCE_FILM (somewhere in the neighborhood of 15% faster). It also appears to go faster on the 29.97 parts, but that's a deception because of the "pretend" frame rate used in .D2V.

- No frames are lost in the full NTSC sections of the source material as would happen if using FORCE_FILM (converting it to 23.976).

- The output product matches the original exactly in terms of flags and video frames. If the original is switching back-and-forth between full-framerate and telecined, so is the copy.

[neuron2]

Originally posted by jdobbs
2. I then use AVISYNTH and MPEG2DEC3DG.DLL to present the resulting frames to CCE, which thinks it is encoding a 23.976fps frame based source. And the output of this stage is an MPEG2 file?

3. After encoding, as I am rebuilding I apply, frame-for-frame the progressive_flag, TFF, and RFF that were recorded from the original and set the frame_rate back to what it should be. What do you mean by rebuilding, and how do you do it?

- The output product matches the original exactly in terms of flags and video frames. Umm, then what is the point of the whole exercise??? Wouldn't a simple copy operation be a lot simpler? :devil:

Sorry for being dumb. I just don't see what you are trying to accomplish overall. :confused:

[jdobbs]

Originally posted by neuron2
And the output of this stage is an MPEG2 file?

What do you mean by rebuilding, and how do you do it?

Umm, then what is the point of the whole exercise??? Wouldn't a simple copy operation be a lot simpler? :devil:

Sorry for being dumb. I just don't see what you are trying to accomplish overall. :confused:

1. Yes the output is an MPEG-2 file that uses a smaller bitrate than the original.

2. By rebuilding I am reauthoring the original DVD structure using the output of the CCE encode.

3. This is a process used to recompress DVD video (~8GB) using CCE to make it fit on a DVD-5 (4.38GB).

If you look over at the DVD Rebuilder forum -- these are the methods I'm using in the DVD-RB software to make CCE backups of DVDs. It works like a champ.

The process requires your version of MPEG2DEC3DG.DLL to work because I'm creating a .D2V that also ensures no frames are lost (I followed your famous "missing frames" thread very closely).

[neuron2]

OK, it is all clear now. Thank you for your patience. :cool:

So you've made your own tools to support this (presumably that operate on the D2V file). Do you see any benefit in having me support it directly? If so, exactly what do you specify?