calculating SCR

[CMatt]

Hi mpeg-freaks, i need ur help :D
I code atm on some mpeg-tools.. one prog is a demuxer/muxer. The demuxer was no problem, but the muxer is the hell.. :rolleyes:
How i can calculate the SCR value !?!? I looked into some other codes (DVDx, bbmpeg,..) and i understood the main princip, but my code produced only shi*.. I tried to demux a stream and then to mux the same with my code. The result should be the same, but it isn't :( The SCR in the first pack is nearly the same like in the orginal (with some little differences in the SCR_ex value ) but as soon as the first soundpack gets muxed, the values run apart.
Can somebody explain me, or give me a link to description who this SCR gets calculated. I searched now allready 6h on net i found nothing... :( I hope someone of u has an idea

big thx :)

[CMatt]

:(

[LnxPeng]

You know that if you look on VobEdit, the SCR looks like a floating point number, but is not. The first digit before the decimal place is the number of 90 kHz clock ticks that should have passed when the VOB is read (i have heard that software players ignore the SCR). The digit after the clock is the remaning 27 MHz clock ticks. To find the SCR for any LBA,:

(LBA number)*(size of each LBA in bytes)*(90000) / ( Mux rate in bytes per second)

This will give a floating point number of 90 kHz clock ticks. Take whatever is to the right of the decimal point and multiply it by 300 to get the number of 27 MHz clock ticks. Again there will be a decimal number. Just use the part left of the decimal.

It's been a while since I have done this, and I am just working from memory. I'll check it out when I have a chance to.

LnxPeng

P.s. you do know that at a low level the SCR is slightly encoded, don't you? You MUST use bit manipulation to decode it from disk. I was programming a muxer but ran out of time trying to sort through the mess caused by bit manipulation in little-endian. I'm still working on it though. If you come up with some code let me know, please.

[CMatt]

I also had no time last days... but i will try ur formula next days. The only thing which I do not understand:
(LBA number)*(size of each LBA in bytes)*(90000) / ( Mux rate in bytes per second)
LBA number: constant increment
size of each LBA in bytes: constant value
Mux rate in bytes per second: are that the 25200 (programm mux rate?) -> constat value?
The result (SCR) would have to be a linear rising value, but it isn't. I have big jumps as soon as the first sound-packs are in the stream... :confused:

btw. What kind of source u need? Only this bit manipulation things? no problem =)


// bits is a pointer to the start of the pack
__int64 GetSystemClock(unsigned char* bits)
{
// prase SCR
unsigned long iHighBits = bits[4] & 0x38;
unsigned long iMiddleBits = ((unsigned long)(U32_AT(&bits[4])) & 0x03FFF800);
unsigned long iLowBits = ((unsigned long)(U32_AT(&bits[4+2])) & 0x03FFF800);
__int64 iSCR=iHighBits << 27 | iMiddleBits << 4 | iLowBits >> 11;
unsigned long extBits = 0;
extBits |= ((bits[4+4]&0x3)<<7);
extBits |= ((bits[4+5]&0xFE)>>1);

return iSCR*300 + extBits;
}


For the writer-code take a look at the DVDx source - file timecode.cpp, there is a function named buffer_timecode ;)

[LnxPeng]

Originally posted by CMatt
The result (SCR) would have to be a linear rising value, but it isn't. I have big jumps as soon as the first sound-packs are in the stream... :confused:


I believe that the code is linear when you put it in base ten (ie (number of SCR ticks / 90000) + (remainder clock ticks / 27000000) ). I muxed with IFOEdit, which may do it differently than other muxers.

http://www.pxh.de/fs/svcd/DVB2SVCD/dts_pts_underflows_explanation.pdf

This link is a good one. PDF of the writer of bbMPEG talking

LnxPeng

P.s. thx for the code

[CMatt]

wow :) big thx for the pdf.

and to the code.. been seen that i forgot some lines.. without this u should have a some problems to compile this =)


#include <Winsock2.h>
#define ntoh32 ntohl
#define U32_AT(p) ntoh32 (*((unsigned __int32*)p))

^^ the U32_AT function ;)
I use atm the ntohl-function form the winsock-libs to move the bytes in the readet 4 bit integers in the right sequence. I don't know how fast is this, but it's a socket function -> verry slow :D
As soon i have time i write a little ASM-routine to do this ;)
I post the new function the here in the thread.