Demux

[GZZ]

I currently working on a demuxer for Ac3 streams, from Vob files and I got Ac3 demuxing working, well sort of. Because my file plays fine, but I use scenarist to check it and it reject the file and other programs except powerDVD and windvd plays it. But I have this little 40 mb vob file and I have used vobedit alot and I have demux the ac3 file with this program, but it seems my Ac3 file is a little bit bigger then the one Vobedit demux. So if anyone can tell me what I´m doing wrong or there are maybe something in the vob file I don't want to demux with my ac3 file.

Please advise me. Thanks.

GZZ

[mpucoder]

Since we don't know what your files look like it would just be a guess. Why not do a binary compare of yours and Vobedit's?
Most likely, though, is that you are leaving in the DVD header, which is not part of the AC3 stream. This is the three bytes following the substream header.
This might help http://www.mpucoder.com/DVD/ass-hdr.html

[GZZ]

I got it working now and it works fine in scenarist and my file has the same size as the one vobedit produce. But I´m now trying to find info on how to read the audio bitrate from the vob file. Its located inside the sync-word. But I don't know if your site have the info(its not the most user friendly site I have seen). So if you got it, please provide me with a link or tell me how to read it. Thanks.


GZZ

[mpucoder]

If you want to find the bitrate purely from the vob then you need to decode the AC3 stream itself. You can get the AC3 standard over at ATSC (standard A52) http://www.atsc.org/standards.html

[GZZ]

I have been reading alot on this PDF from the link you gave me and came across this:

bit_rate_code ¡V This is a 6-bit field. The lower 5 bits indicate a nominal bit rate. The MSB
indicates whether the indicated bit rate is exact (MSB = ƒn0) or an upper limit (MSB = ƒn1) (see Table A4).

http://www.atsc.org/standards/a_52a.pdf

If you open it up and look a page: 121 you can se table telling what bit represent the bitrate. But I can't find what byte its looking at in the ac3 stream. Maybe you can help me out here ?

GZZ

[Tsui]

I tell you how you will get your bitrate out of an ac3 audio stream :

-----

Look at the beginning of the extracted ac3-file.
The counting of the bytes begins at 0 (zero).

Example : '3000 Miles to Graceland'
the first 8 bytes of the extracted english ac3 stream look like this :
0B 77 49 0A 1C 40 E1 DF

Data[4] is the fifth (5.) byte : 1c (hex)

look at position 1c (hex) = 28 (decimal) and you will see, that the bitrate of your file is 384 kbps


hex decimal Bitrate in kbps
0 0 32
1 1 32
2 2 40
3 3 40
4 4 48
5 5 48
6 6 56
7 7 56
8 8 64
9 9 64
a 10 80
b 11 80
c 12 96
d 13 96
e 14 112
f 15 112
10 16 128
11 17 128
12 18 160
13 19 160
14 20 192
15 21 192
16 22 224
17 23 224
18 24 256
19 25 256
1a 26 320
1b 27 320
1c 28 384
1d 29 384
1e 30 448
1f 31 448
20 32 512
21 33 512
22 34 576
23 35 576
24 36 640
25 37 640

-----


Greetings
Tsunami


P.S.
do me a favour and write a demuxer not only for vob2ac3, but also for avi2ac3 (with support for dual ac3 language as well)

[GZZ]

Thanks Tsui. Great help and it also worked. I was wondering if this also works on DTS sound and maybe, LPCM and MPA ?

I tested it on DTS sound and byte 4 is always 252 for me. But the DTS standards are not official avaliable I think.


Thanks.


GZZ

[Chatwalker]

Hi

For DTS use the code below.

Regards
Chatwalker


'DTS Bitrate
Select Case ((Header(9) Mod 4) * 8) + Int(Header(10) / 32)
Case 0: .Bitrate = 32
Case 1: .Bitrate = 56
Case 2: .Bitrate = 64
Case 3: .Bitrate = 96
Case 4: .Bitrate = 112
Case 5: .Bitrate = 128
Case 6: .Bitrate = 192
Case 7: .Bitrate = 224
Case 8: .Bitrate = 256
Case 9: .Bitrate = 320
Case 10: .Bitrate = 384
Case 11: .Bitrate = 448
Case 12: .Bitrate = 512
Case 13: .Bitrate = 576
Case 14: .Bitrate = 640
Case 15: .Bitrate = 768
Case 16: .Bitrate = 896
Case 17: .Bitrate = 1024
Case 18: .Bitrate = 1152
Case 19: .Bitrate = 1280
Case 20: .Bitrate = 1344
Case 21: .Bitrate = 1408
Case 22: .Bitrate = 1411.2
Case 23: .Bitrate = 1472
Case 24: .Bitrate = 1536
Case 25: .Bitrate = 1920
Case 26: .Bitrate = 2048
Case 27: .Bitrate = 3072
Case 28: .Bitrate = 3840
Case 29: .Bitrate = 4096
End Select

[GZZ]

Thanks alot Chatwalker

I got it working. Very nice, just at little Q: Are this bitrate valid or did you just type wrong:


Case 22: .Bitrate = 1411.2 <-- Never heard of this bitrate ?



GZZ

[GZZ]

I have been working on the PTS for the last few hours and search this forum and I haven't found anything on this.

I got these 5 bytes:

33 - 00100001
0 - 00000000
1 - 00000001
201 - 11001001
253 - 11111101


and I know from Vobedit that it report it to have a PTS value of:

25854


but I can't find out how it gets to this value, from Mpucoder http:

http://www.mpucoder.com/DVD/pes-hdr.html

I can see what bits are what but I don't understand what PTS 29..15 and PTS 14..00 means. Any one can explain it to me and maybe tell me how to calculate the pts value.


Thanks.

GZZ

[mpucoder]

Those are the bit numbers, put the three fields together to get the 33 bit value. The values in blue are fixed bit values. Since this is a stream that will resync if 23 zero bits are encountered it is necessary to embed "marker bits".

[GZZ]

don't think I get it mpucoder

If I take the 4 byte 33, 0, 1, 201, 253 and add there binary code together

1 (fixed value from the last digit in 33) + 00000000 + 00000001 + 11001001 + 11111101 =

100000000000000011100100111111101 (33 bit value), but its in decimal number = 4295084541


and thats not correct.


or maybe I just don't get, please make an example out of the numbers I have provide. Thanks for your patience on proberly a bad coder who don't understand it good enough. :)


GZZ

[mpucoder]

byte 0 = 0010 0001
byte 1 = 0000 0000
byte 2 = 0000 0001
byte 3 = 1100 1001
byte 4 = 1111 1101
string it all together and it's 000 0000 0000 0000 000 1100 1001 1111 110, regrouped for hex it's 0 0000 0000 0000 0000 0110 0100 1111 1110, 0x64FE = 25854

[GZZ]

Yea - I found out just after I posted my reply. But then I got the eat my chrismas dinner. HEHE


Happy X-mas and thanks for the help. :D


GZZ

[GZZ]

2 Questions:

1. Does the audio delay also work for DTS, LPCM and MPA streams ?

2. I normally take the PTS value from the first GOP, but what if the first GOP comes AFTER the audio and not before, how do I then calculate the delay ?



GZZ

[GZZ]

MPUCoder I was reading one of your other post in de development forum and came across a place (I can't find it anymore) where you said that the best way to count number of frames in a vob file was to read the SCR value.


But I don't understand how you can turn the SCR value into frames ? and then count it or whatever you have in mind ??.

Thanks.


GZZ

[mpucoder]

I remember that thread, but I didn't make or agree with that assertion. The SCR is a time code, from which you can determine the elapsed time of the video, but that only gives you an approximate number of frames.
The only way to count frames is to count them, using the Picture Header (0100) for source frames, and Picture Coding Extension of the Extension Header (01B5) to account for NTSC pulldown.
There are many ways the SCR can steer you wrong, especially if the vob is mixed camera/film.

[GZZ]

I looked into it using Vobedit and it seems that the picture Start Code never starts at a fixed offset, but always variats. The only place I can see it starts at a fixed offset is if its a GOP then it starts at: 009E.


So do you have a easy way I can find the piture start code position?



GZZ

[mpucoder]

That's correct, only the system level headers will be nicely positioned within each pack (sector). After that you're handling an elementary stream, which gets broken up over many packs. In VobEdit you'll also notice there are video packs with no picture start (have no IPB designation), these hold more data belonging to the previous start code.
The stream will finally end with filler data.
There was another thread on this, and this was one post http://forum.doom9.org/showthread.php?s=&postid=167387&highlight=start#post167387
In that thread bbinfo is mentioned as a source that counts frames.

[GZZ]

Can any please test my new frame counter, I use good among of time on it and I still don't know how precise its counting, for my own test its about 100-200 frames off, but I might be more. But please test it out and compare the result with DVD2AVI and other program which count frames from vob files.


I´m not the greatest programmer, so I migth have forgot something.


GZZ


The program should be attach to this post.

[redeemer-dk]

the first vob file form panic room:

DVD2AVI: 29529
Framecounter: 29416

Where did you find the information about vob files to write this program?

-Rune Svendsen

[GZZ]

Its made in delphi and I got the source, but something is missing, because i never get the same framenumber as in DVD2AVI. I have been working alot on it, But you are DK like me (I can see from your nick). PM me on ICQ if you want futher help or maybe you can help me. ? (ICQ: 40376054).


Btw - I use Vobedit (I think its in the download section) to look at the vob file and then I use blockread in delphi to read a block of byte in (2048) and then I can analyse it out from vobedit. But its not easy and I don't get the correct number of frames, its always a bit off.


GZZ