VidHack
24th May 2004, 20:13
To All,
I am copying a thread from the DVDreMake Forum below. I am specifically looking for technical responses to this problem. Keep in mind DVDreMake will export a complete VOBU when cutting. Thanks to all that understand what I am trying to do and take the time to respond.
------------------------------------------
Dimad,
Hoping to start a dialog about "Still Image Creation".
This idea is based off a thread in this very Forum on, Converting a Motion Menu to a Still Image. To most readers of this thread, this sounds like a simple idea, and DVDremake should be able to handle this Feature Request. Well, guess again. To understand the complexities of this simple idea you have to understand GOPs (I-Frame, P-Frame, B-Frame) and the dreaded Temperal encoding sequence. Not to mention Subpicture RLE encoding, multiplexed into the GOP, which can be spread over multiple Frames withing the GOP. So, I read up on all this stuff, and I swear the same idiot who invented Calculus and quantum mechanics, invented the MPEG2 encoder. Currently it appears as though DVDreMake cuts VOBS at VOBU boundries, scans the NAV Pack for various info (Buttons, pointers, etc) and groups the VOBS into Blocks. DVDremake has very strick rules for keeping the cut segment of VOB to DVD spec. Also, audio and subtitle packets are multiplexed within the VOBU. So, if you have used DVDremake to CUT FROM HERE on a motion menu, you often get a few frames of video with a chunk of audio. You would then change the Time to show this Video to Infinite. BUT, the menu when played will have a jitter effect and a small audio sound clip --> This is the problem I am trying to Fix.
So, let the hacking begin. My first attempt to solve the problem was to cut the small VOB block at the next P-Frame or B-Frame following the initial I-Frame. So, in a nutshell, to reduce the potential 16 Frame GOP to a Single frame. This would automatically remove the audio. Well, even without redirecting the NAV Pack pointers, this approach works...sort-of. Though the pointers to the First, Second, and Third RefEndBlock (vobu_Xstref_ea) are now wrong, the DVD player will show the single Frame of video, but with one problem. The Subpicture packets have now been severed. You will NOT get button highlights. This is not good.
Now keep in mind my goal is to modify just bytes of the original VOB, or modify the IFO, not to demultiplex this VOB and ReAuthor it, this way I can provide a in memory solution to be rolled into DVDreMake. So, then I used IFOedit to do some of the work. I changed the Menu VOB filename to VTS_01_1.VOB, created an IFO, stripped the Audio streams, then IFOedit changed all the pointers for me. Not, a total solution, but at least the audio is gone. So, for the in-memory solution for DVDremake, instead of stripping streams, just null them out. Just find the Audio pack header, read the pointer to the audio packets, and change them to 0x00. This is the preferred solution, the NAV pointers are still correct. Now you still have audio, but its just a second of silence. OK, one problem complete, and DVDremake can handle it. Actually Dimad, just keep a silent AC3 packet in your Data pool memory and exchange it out in the VOB, then all the CRC bytes are correct. DONE with audio.
Back to the Video jitter problem. My next attempt was to simply redirect the First, Second, Third RefEndBlock (vobu_Xstref_ea) pointers to the LBA of the last P-Frame within the GOP. In simple terms to jump the video to the last frame of this VOBU. So, fire up a Hex-Editor, or even VOBedit and change them. Well, DVDremakes VOB parser that checks a VOB for replacing is killing me. It sees the modified pointers as some kind of incompatible VOB segment and WONT let me use the Replace Block feature. HHmmm, Dimad could you release TO ME a special version of DVDremake, that this parser is disabled so I can manual hack the bytes and exchange the VOB? I can then continue this approach until I figure this out. I think this approach will fail, due to the skipping of critical subpicture packets?
So then I figured a new approach is needed. Modify the IFO to point to the last frame, but the granuality of the IFO is to the CELL level. So, I am still stuck. I have pondered yet another solution, to copy the bytes from the first MPEG I-Frame, into the following P/B frames, but this also has problems, the Frames within the GOP are not a standard length, depending if its a high action seen or not, they vary (stupid Temperal Encoding). So, still stumped.
Well Dimad, got any ideas on this? Perhaps to move this question over to Doom9 and have MPUcoder chew on it? I think giving DVDremake the ability to convert a Motion Menu to a Still WITHOUT Transcoding/ReEncoding would be awsum. I have also pondered creating a fake button with an Auto-Action to Fast-Forward you to the End Frame, but the Jitter still exists. I am trolling threw the NAV/PCI-DSI/PES packets trying to find some simple solution to this, is there a byte that will Flag the internal MPEG2 decoder to NOT show the decoded frame until we turn it back on at the EndFrame? That would supress the jitter. Can we some how change the P-Frame headers to B-Frame and have the decoders ignore the B-Frames? It appears that your internal MPEG2 decoder only renders I-Frames and P-Frames, is this correct? Do you just dump B-Frames? Anyway, need some USEFULL feedback on this. I know we can get this to work, just need a bit more caffine and perhaps a new approach to the problem. Oh yea, found a ton of code on the net to render the subpicture overlay, could eventually roll that feature in to DVDremake, to supplement your X/Y bounding boxes.
Thanks for any technical replies to this......
PS. Please dont move this POST, I realize its a discussion on a Feature Request/Suggestion, and there is a thread about this already, but I really need Dimad's reponse on this and I want it to stay in the Beta Forum - Thanks -.
VidHack
Back to top
DimadSoft
DvdReMake Official support
Posted: Sat May 22, 2004 9:00 pm Post subject:
--------------------------------------------------------
Sorry, VidHack, I still need to learn about the details of how things are multiplexed in vob, probably posting this on doom9 and asking wise people ( ) there would make sense.
But I think your initial approach is almost what should be done to do the task. The only difference: don't cut the rest of the cell after the part with I-frame. Just construct a new cell by putting together:
first navpack (first cell sector - 2048 bytes);
all sectors with I-frame;
all sctors with sub-pictures;
change references in navpack (zero offsets to audio, corect offsets to subpictures, set to corresponding FFs vobu search values,...)
voila.
Most probably this will work, but... there are few buts here:
it is possible to have start of the next frame in the same sector with the end of I-frame;
probably it is necessary to set some flags that GOP is ending or something like this;
it might be necessary to change SCR values in each sector.
_________________
DimadSoft
Support Team
http://www.dimadsoft.com - home of DvdReMake and MenuEdit tools
----------------------------------------------------------------
I am copying a thread from the DVDreMake Forum below. I am specifically looking for technical responses to this problem. Keep in mind DVDreMake will export a complete VOBU when cutting. Thanks to all that understand what I am trying to do and take the time to respond.
------------------------------------------
Dimad,
Hoping to start a dialog about "Still Image Creation".
This idea is based off a thread in this very Forum on, Converting a Motion Menu to a Still Image. To most readers of this thread, this sounds like a simple idea, and DVDremake should be able to handle this Feature Request. Well, guess again. To understand the complexities of this simple idea you have to understand GOPs (I-Frame, P-Frame, B-Frame) and the dreaded Temperal encoding sequence. Not to mention Subpicture RLE encoding, multiplexed into the GOP, which can be spread over multiple Frames withing the GOP. So, I read up on all this stuff, and I swear the same idiot who invented Calculus and quantum mechanics, invented the MPEG2 encoder. Currently it appears as though DVDreMake cuts VOBS at VOBU boundries, scans the NAV Pack for various info (Buttons, pointers, etc) and groups the VOBS into Blocks. DVDremake has very strick rules for keeping the cut segment of VOB to DVD spec. Also, audio and subtitle packets are multiplexed within the VOBU. So, if you have used DVDremake to CUT FROM HERE on a motion menu, you often get a few frames of video with a chunk of audio. You would then change the Time to show this Video to Infinite. BUT, the menu when played will have a jitter effect and a small audio sound clip --> This is the problem I am trying to Fix.
So, let the hacking begin. My first attempt to solve the problem was to cut the small VOB block at the next P-Frame or B-Frame following the initial I-Frame. So, in a nutshell, to reduce the potential 16 Frame GOP to a Single frame. This would automatically remove the audio. Well, even without redirecting the NAV Pack pointers, this approach works...sort-of. Though the pointers to the First, Second, and Third RefEndBlock (vobu_Xstref_ea) are now wrong, the DVD player will show the single Frame of video, but with one problem. The Subpicture packets have now been severed. You will NOT get button highlights. This is not good.
Now keep in mind my goal is to modify just bytes of the original VOB, or modify the IFO, not to demultiplex this VOB and ReAuthor it, this way I can provide a in memory solution to be rolled into DVDreMake. So, then I used IFOedit to do some of the work. I changed the Menu VOB filename to VTS_01_1.VOB, created an IFO, stripped the Audio streams, then IFOedit changed all the pointers for me. Not, a total solution, but at least the audio is gone. So, for the in-memory solution for DVDremake, instead of stripping streams, just null them out. Just find the Audio pack header, read the pointer to the audio packets, and change them to 0x00. This is the preferred solution, the NAV pointers are still correct. Now you still have audio, but its just a second of silence. OK, one problem complete, and DVDremake can handle it. Actually Dimad, just keep a silent AC3 packet in your Data pool memory and exchange it out in the VOB, then all the CRC bytes are correct. DONE with audio.
Back to the Video jitter problem. My next attempt was to simply redirect the First, Second, Third RefEndBlock (vobu_Xstref_ea) pointers to the LBA of the last P-Frame within the GOP. In simple terms to jump the video to the last frame of this VOBU. So, fire up a Hex-Editor, or even VOBedit and change them. Well, DVDremakes VOB parser that checks a VOB for replacing is killing me. It sees the modified pointers as some kind of incompatible VOB segment and WONT let me use the Replace Block feature. HHmmm, Dimad could you release TO ME a special version of DVDremake, that this parser is disabled so I can manual hack the bytes and exchange the VOB? I can then continue this approach until I figure this out. I think this approach will fail, due to the skipping of critical subpicture packets?
So then I figured a new approach is needed. Modify the IFO to point to the last frame, but the granuality of the IFO is to the CELL level. So, I am still stuck. I have pondered yet another solution, to copy the bytes from the first MPEG I-Frame, into the following P/B frames, but this also has problems, the Frames within the GOP are not a standard length, depending if its a high action seen or not, they vary (stupid Temperal Encoding). So, still stumped.
Well Dimad, got any ideas on this? Perhaps to move this question over to Doom9 and have MPUcoder chew on it? I think giving DVDremake the ability to convert a Motion Menu to a Still WITHOUT Transcoding/ReEncoding would be awsum. I have also pondered creating a fake button with an Auto-Action to Fast-Forward you to the End Frame, but the Jitter still exists. I am trolling threw the NAV/PCI-DSI/PES packets trying to find some simple solution to this, is there a byte that will Flag the internal MPEG2 decoder to NOT show the decoded frame until we turn it back on at the EndFrame? That would supress the jitter. Can we some how change the P-Frame headers to B-Frame and have the decoders ignore the B-Frames? It appears that your internal MPEG2 decoder only renders I-Frames and P-Frames, is this correct? Do you just dump B-Frames? Anyway, need some USEFULL feedback on this. I know we can get this to work, just need a bit more caffine and perhaps a new approach to the problem. Oh yea, found a ton of code on the net to render the subpicture overlay, could eventually roll that feature in to DVDremake, to supplement your X/Y bounding boxes.
Thanks for any technical replies to this......
PS. Please dont move this POST, I realize its a discussion on a Feature Request/Suggestion, and there is a thread about this already, but I really need Dimad's reponse on this and I want it to stay in the Beta Forum - Thanks -.
VidHack
Back to top
DimadSoft
DvdReMake Official support
Posted: Sat May 22, 2004 9:00 pm Post subject:
--------------------------------------------------------
Sorry, VidHack, I still need to learn about the details of how things are multiplexed in vob, probably posting this on doom9 and asking wise people ( ) there would make sense.
But I think your initial approach is almost what should be done to do the task. The only difference: don't cut the rest of the cell after the part with I-frame. Just construct a new cell by putting together:
first navpack (first cell sector - 2048 bytes);
all sectors with I-frame;
all sctors with sub-pictures;
change references in navpack (zero offsets to audio, corect offsets to subpictures, set to corresponding FFs vobu search values,...)
voila.
Most probably this will work, but... there are few buts here:
it is possible to have start of the next frame in the same sector with the end of I-frame;
probably it is necessary to set some flags that GOP is ending or something like this;
it might be necessary to change SCR values in each sector.
_________________
DimadSoft
Support Team
http://www.dimadsoft.com - home of DvdReMake and MenuEdit tools
----------------------------------------------------------------