Quantcast New Tool Kutter - Page 2 - digitalFAQ.com Forums [Archives]
  #21  
09-03-2005, 07:42 PM
rds_correia rds_correia is offline
Free Member
 
Join Date: Apr 2003
Location: Chinese Democracy starts now!
Posts: 2,563
Thanks: 1
Thanked 0 Times in 0 Posts
Quote:
Originally Posted by kwag
I'll look into adding 64 bit file size support, and then you can feed it your whole hard drive
Cool
Quote:
Originally Posted by kwag
Until then, please don't use files larger that 2GB
No problem
__________________
Rui
Reply With Quote
Someday, 12:01 PM
admin's Avatar
Site Staff / Ad Manager
 
Join Date: Dec 2002
Posts: 42
Thanks: ∞
Thanked 42 Times in 42 Posts
  #22  
09-03-2005, 07:47 PM
rds_correia rds_correia is offline
Free Member
 
Join Date: Apr 2003
Location: Chinese Democracy starts now!
Posts: 2,563
Thanks: 1
Thanked 0 Times in 0 Posts
Quote:
Originally Posted by kwag
Did you try feeding the original VOB to DVDLab, and see if you get the same message
Yep, it seems they are identical to the source because all VOB sources on my disk produce such a message when I try to load them .
Let me tell you that I have never ever tried to add a VOBfile to a DVDLab project.
Usually I only do M2Vs and AC3s and have DVDLab mux them and I never get such a message.
__________________
Rui
Reply With Quote
  #23  
09-03-2005, 07:54 PM
kwag kwag is offline
Free Member
 
Join Date: Apr 2002
Location: Puerto Rico, USA
Posts: 13,537
Thanks: 0
Thanked 0 Times in 0 Posts
Quote:
Originally Posted by rds_correia
Could this be a DVDLab vs Noob problem at 1h38am
Or is DVDLab having difficulty in accepting the chunks?
May very well be a DVDLab bug
Have you tried using MPEG Validator to analyze your source, and then the chunks
http://sr2.mytempdir.com/144314

-kwag
Reply With Quote
  #24  
09-03-2005, 08:03 PM
kwag kwag is offline
Free Member
 
Join Date: Apr 2002
Location: Puerto Rico, USA
Posts: 13,537
Thanks: 0
Thanked 0 Times in 0 Posts
Or make a quick test Rui

After you chop all your pieces (I post three VOBs on the example), and assuming your original VOB is named VTS_01_2.VOB, do this on a command prompt:

copy /B VTS_01_2.VOB.kutter.1.VOB + VTS_01_2.VOB.kutter.1.VOB + VTS_01_2.VOB.kutter.1.VOB joined.vob

Now the file "joined.vob" should be an identical bit by bit to the file VTS_01_2.VOB

-kwag
Reply With Quote
  #25  
09-03-2005, 08:03 PM
rds_correia rds_correia is offline
Free Member
 
Join Date: Apr 2003
Location: Chinese Democracy starts now!
Posts: 2,563
Thanks: 1
Thanked 0 Times in 0 Posts
Stand by.
Working on many tests to see if it has to do with the chunks or with DVDLab.
I'll be back in '5.
Cheers
__________________
Rui
Reply With Quote
  #26  
09-03-2005, 08:27 PM
rds_correia rds_correia is offline
Free Member
 
Join Date: Apr 2003
Location: Chinese Democracy starts now!
Posts: 2,563
Thanks: 1
Thanked 0 Times in 0 Posts
I did many tests but none suited my needs.
So I went for one last and very long test.
I added 2 vobfiles with 2 full movies that I just extracted to my HDD with DVDDecrypter.
And this time there were no messages and the muxing went well from the begining until the end.
I just burnt it to a DVD-RW and it's playing fine in the living room.
So the issues that I had earlier must come from the chunks done by Kutter.
Or maybe I'm missing something...
__________________
Rui
Reply With Quote
  #27  
09-03-2005, 09:49 PM
kwag kwag is offline
Free Member
 
Join Date: Apr 2002
Location: Puerto Rico, USA
Posts: 13,537
Thanks: 0
Thanked 0 Times in 0 Posts
Hmm, I just did the copy test, and the final joined VOB is identical to the source

Code:
C:\kutter>fc joined.vob h:\RED_PLANET\VIDEO_TS\VTS_01_2.VOB
Comparing files joined.vob and H:\RED_PLANET\VIDEO_TS\VTS_01_2.VOB
FC: no differences encountered


C:\kutter>
That means there's a perfect match bit for bit between the files.
Unless the headers are buggy, and I'm not correctly tagging the cuts on the individual pieces.
I'll do more tests.

-kwag
Reply With Quote
  #28  
09-04-2005, 02:16 AM
Zyphon Zyphon is offline
Free Member
 
Join Date: Oct 2003
Location: London, England (UK)
Posts: 1,035
Thanks: 0
Thanked 0 Times in 0 Posts
@rds_correia & Kwag

Thanks guys for the extensive testing you have both done, I am sorry I haven't had time to test myself but I was backing up one of my DVD's

It is a shame about the 2Gb limitation of PB, I wish the developer of this programming language would fix this issuse as it holds back the excellent developers here who use it such as Karl and Andrej.

Hopefully that 64bit binary Inc supplied will come in use.

I hope to run some tests myself today.

About the Open GOPs in DVD-Lab, I get this notification also when adding a .mpv stream made by CCE from my DVD sources but it doesn't affect the authoring and I have no probs when I watch the backups on my SAP.

I just thought that info might come in useful.
__________________
Regards.

Michael.
Reply With Quote
  #29  
09-04-2005, 05:10 AM
Prodater64 Prodater64 is offline
Free Member
 
Join Date: Mar 2003
Location: Palma de Mallorca - España
Posts: 2,925
Thanks: 0
Thanked 0 Times in 0 Posts
Quote:
Originally Posted by kwag
Or make a quick test Rui

After you chop all your pieces (I post three VOBs on the example), and assuming your original VOB is named VTS_01_2.VOB, do this on a command prompt:

copy /B VTS_01_2.VOB.kutter.1.VOB + VTS_01_2.VOB.kutter.1.VOB + VTS_01_2.VOB.kutter.1.VOB joined.vob

Now the file "joined.vob" should be an identical bit by bit to the file VTS_01_2.VOB

-kwag
When you apply this copy /b command, files are joined but headers are not rewrited, then you will have a file that plays fine but time info will be wrong. Later when you reencode a such video, a-v will be async.
It was my experience a time ago while programed a tool.
I dont know if in this case it could be important.

Edited: I worked with mpgs and not with vobs.
Reply With Quote
  #30  
09-04-2005, 07:47 AM
Boulder Boulder is offline
Free Member
 
Join Date: Sep 2002
Location: Lahti, Finland
Posts: 1,652
Thanks: 0
Thanked 0 Times in 0 Posts
Quote:
Originally Posted by kwag
Hmm, I just did the copy test, and the final joined VOB is identical to the source

Code:
C:\kutter>fc joined.vob h:\RED_PLANET\VIDEO_TS\VTS_01_2.VOB
Comparing files joined.vob and H:\RED_PLANET\VIDEO_TS\VTS_01_2.VOB
FC: no differences encountered


C:\kutter>
That means there's a perfect match bit for bit between the files.
Unless the headers are buggy, and I'm not correctly tagging the cuts on the individual pieces.
I'll do more tests.

-kwag
Did you try fc /B ?
Reply With Quote
  #31  
09-04-2005, 10:07 AM
rds_correia rds_correia is offline
Free Member
 
Join Date: Apr 2003
Location: Chinese Democracy starts now!
Posts: 2,563
Thanks: 1
Thanked 0 Times in 0 Posts
Quote:
Originally Posted by kwag
That means there's a perfect match bit for bit between the files.
Unless the headers are buggy, and I'm not correctly tagging the cuts on the individual pieces.
I'll do more tests.
Just let me know if I can help
Cheers
__________________
Rui
Reply With Quote
  #32  
09-04-2005, 11:52 AM
kwag kwag is offline
Free Member
 
Join Date: Apr 2002
Location: Puerto Rico, USA
Posts: 13,537
Thanks: 0
Thanked 0 Times in 0 Posts
@Boulder,

I also tried the FC /B. Result
C:\kutter>fc /B joined.vob h:\RED_PLANET\VIDEO_TS\VTS_01_2.VOB
Comparing files joined.vob and H:\RED_PLANET\VIDEO_TS\VTS_01_2.VOB
FC: no differences encountered


I suspect I might have a bug in the end header on the chunks.
As a matter of fact, this has to be the problem, because the way it's suppposed to work is that each chunk is a valid MPEG file with start and end headers. So a join of all chunks shouldn't be the same as the original, because each chunk has to have added ending headers.
I'll fix this today

@All,
Thanks for all the feedback

-kwag
Reply With Quote
  #33  
09-04-2005, 12:12 PM
incredible incredible is offline
Free Member
 
Join Date: May 2003
Location: Germany
Posts: 3,189
Thanks: 0
Thanked 0 Times in 0 Posts
Send a message via ICQ to incredible
You won't loose informations by cutting if encoding the mpegs using SEQ Header at every Gop. Thats normally the "default" as mpeg was also meant to be a streaming format.
And here Kutter should ONLY cut at SeqHeaders.

That header can be easely parsed as it begins using .....

Code:
If ReadFile(#File_Temp, p_filename) ; open file for read-only
    tempL = ReadLong() ; read in the first 32 bit
    If p_forceHeaderSearch = #False And tempL <> $B3010000 And tempL <> $BA010000
      ProcedureReturn #False ; return if not a common MPEG-file and no forceHeaderSearch is set
    ElseIf tempL <> $B3010000
      Repeat ; search bytealigned for a (possible) sequence-header (simply straight forward, no chunk-jumps here)
        tempL = ReadLong()
        FileSeek(Loc()-3)
      Until Eof(#File_Temp) Or tempL = $B3010000 ; until fileend reached or sequenceheader found
      If tempL = $B3010000
        FileSeek(Loc() + 3) ; set the filepointer back
      Else
        ProcedureReturn #False ; there's no sequence header in this file
      EndIf
    EndIf
Endif
I used that in Packshot and Mencalc to get the needed Stream Infos when importing mpeg2/1 Files.
The "Parser" searches in the opened file till he founds a sequence header, then do a FileSeek(Loc()-3) so you get again in front of the $B3010000 Long value and THERE you do your cuts!

If only ONE Seq Header at the beginning of the source is found then you MUST parse it completely and add it to your cutted target chunks at their very beginnings!

I Missed something:
You cant cut mpegs just by bytes! You have to cut at an I Frame startpoint.
Do look at the (if available) mpeg2schnitt sources, there you can see how its being done
Reply With Quote
  #34  
09-04-2005, 02:09 PM
kwag kwag is offline
Free Member
 
Join Date: Apr 2002
Location: Puerto Rico, USA
Posts: 13,537
Thanks: 0
Thanked 0 Times in 0 Posts
Quote:
Originally Posted by incredible
You won't loose informations by cutting if encoding the mpegs using SEQ Header at every Gop. Thats normally the "default" as mpeg was also meant to be a streaming format.
That's exactly what I'm doing, Andrej
Quote:
And here Kutter should ONLY cut at SeqHeaders.
It does
Quote:

That header can be easely parsed as it begins using .....

Code:
If ReadFile(#File_Temp, p_filename) ; open file for read-only
    tempL = ReadLong() ; read in the first 32 bit
    If p_forceHeaderSearch = #False And tempL <> $B3010000 And tempL <> $BA010000
      ProcedureReturn #False ; return if not a common MPEG-file and no forceHeaderSearch is set
    ElseIf tempL <> $B3010000
      Repeat ; search bytealigned for a (possible) sequence-header (simply straight forward, no chunk-jumps here)
        tempL = ReadLong()
        FileSeek(Loc()-3)
      Until Eof(#File_Temp) Or tempL = $B3010000 ; until fileend reached or sequenceheader found
      If tempL = $B3010000
        FileSeek(Loc() + 3) ; set the filepointer back
      Else
        ProcedureReturn #False ; there's no sequence header in this file
      EndIf
    EndIf
Endif
I used that in Packshot and Mencalc to get the needed Stream Infos when importing mpeg2/1 Files.
The "Parser" searches in the opened file till he founds a sequence header, then do a FileSeek(Loc()-3) so you get again in front of the $B3010000 Long value and THERE you do your cuts!

If only ONE Seq Header at the beginning of the source is found then you MUST parse it completely and add it to your cutted target chunks at their very beginnings!

I Missed something:
You cant cut mpegs just by bytes! You have to cut at an I Frame startpoint.
Do look at the (if available) mpeg2schnitt sources, there you can see how its being done
Very good code, although I already had my implementation, which is completely different
Actually this one you posted is a little simpler than the one I had, but if it ain't broke, don't fix it

Now there's something that just came to my mind. What happens if an actual header sequence pattern shows up in the data (video) part
What I mean is, in standard data communications, if a control/command pattern is part of the data, it's usualy preceded by some escape sequence.
This way, you can differentiate from actual headers or from data.
So what happens in an MPEG stream, when a header byte pattern is part of the data
If it's not preceeded by some escape sequence, this can (and will!) throw off any decoder, because it thinks it's a start of a sequence header, when in fact it's actual data
Anyone ever thought about this, or did I miss something in the MPEG protocol

-kwag
Reply With Quote
  #35  
09-04-2005, 02:48 PM
rds_correia rds_correia is offline
Free Member
 
Join Date: Apr 2003
Location: Chinese Democracy starts now!
Posts: 2,563
Thanks: 1
Thanked 0 Times in 0 Posts
Man!!
I know you're probably right but I'm affraid I didn't catch up a word of what you wrote in the last paragraph .
Cheers
__________________
Rui
Reply With Quote
  #36  
09-04-2005, 03:03 PM
kwag kwag is offline
Free Member
 
Join Date: Apr 2002
Location: Puerto Rico, USA
Posts: 13,537
Thanks: 0
Thanked 0 Times in 0 Posts
Don't worry about it Rui

-kwag
Reply With Quote
  #37  
09-04-2005, 03:18 PM
incredible incredible is offline
Free Member
 
Join Date: May 2003
Location: Germany
Posts: 3,189
Thanks: 0
Thanked 0 Times in 0 Posts
Send a message via ICQ to incredible
I do think these 4 bytes in their count are something like protected!?

Cause if not, such a parser would sometimes put out garbage - and that never happened to me.
Reply With Quote
  #38  
09-04-2005, 04:45 PM
kwag kwag is offline
Free Member
 
Join Date: Apr 2002
Location: Puerto Rico, USA
Posts: 13,537
Thanks: 0
Thanked 0 Times in 0 Posts
Quote:
Originally Posted by incredible
I do think these 4 bytes in their count are something like protected!?
But it CAN be a valid four bytes in a video stream, so there must be some identification bytes (escape sequence) to differentiate commands vs. data.
Quote:

Cause if not, such a parser would sometimes put out garbage - and that never happened to me.
Maybe all decoders are depending on the following couple of bytes after the start header, which are 0x2d, 0x01.
That would make the pattern 00, 00 ,01, B3, 2D, 01 much more difficult to produce in actual data, but it still CAN happen

-kwag
Reply With Quote
  #39  
09-04-2005, 05:40 PM
kwag kwag is offline
Free Member
 
Join Date: Apr 2002
Location: Puerto Rico, USA
Posts: 13,537
Thanks: 0
Thanked 0 Times in 0 Posts
@Rui,

Did you try importing .M2V file chunks into DVDLab
I just tried importing several .M2V chunks into TMPGEnc DVD Author, and there were no errors.
The original VOB file was demuxed to .M2V with TMPGEnc tools to produce the file, which I then chopped up with Kutter.


-kwag
Reply With Quote
  #40  
09-04-2005, 06:11 PM
rds_correia rds_correia is offline
Free Member
 
Join Date: Apr 2003
Location: Chinese Democracy starts now!
Posts: 2,563
Thanks: 1
Thanked 0 Times in 0 Posts
No Karl, unfortunately I didn't try that.
I only tried it on VOBfiles.
Today I'm encoding.
Tomorrow I may find time to test it on M2Vs .
Cheers
__________________
Rui
Reply With Quote
Reply




Similar Threads
Thread Thread Starter Forum Replies Last Post
Kutter: Cut MPEG by time code dvdreasy Video Encoding and Conversion 1 11-24-2005 10:30 PM
Kutter: Bad stream time Prodater64 Video Encoding and Conversion 4 09-10-2005 05:54 PM
Announcing Kutter! - Fastest MPEG cutter around kwag Video Encoding and Conversion 0 09-03-2005 04:08 PM
DVD2AVI: What's the best tool? Encoder Master Video Encoding and Conversion 5 05-24-2005 05:41 AM
Video CD 2.0 tool kit ovg64 Authoring VCD, DVD, Blu-ray 2 04-28-2003 01:06 PM

Thread Tools



 
All times are GMT -5. The time now is 01:53 AM  —  vBulletin © Jelsoft Enterprises Ltd