Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
20th September 2002, 09:11 | #61 | Link |
Registered User
Join Date: Feb 2002
Location: Madrid (Spain)
Posts: 94
|
[QUOTE]Originally posted by Mosu
[B] My current implementation sets it to 1 for the first video frame, because Xiph's documentation clearly states that a page's granulepos (and therefore the packet's granulepos as well) corresponds to the end position. The text from the Ogg docu is "The position specified is the total samples encoded after including all packets finished on this page". As the Ogg framing can only take the granulepos from the packets this means that "granulepos" of the packets also must also reflect the total number of sample, i.e. 1 for the video packet. In case of vorbis the behavior is a little bit different: the first packet has a granulepos of 0 but this still fits in the rules because a single packet can't be decoded. You will need at least two packets. I will change that in the next release and reflect the new behaviour with a different identifier in the header packet. I thought it in something like "videoV2" to maintain backward compatibility to all streams allready created. Anyway you can easily update them by just demultiplexing and multiplexing them again. (E.g. with my DS-based OggCut example just open them and save them again without any further action). Concerning the subtitles the unit used for granulepos is in ms. I would suggest to interpret samples as "ms" and therefore to put the end time in ms as granulepos. Currently I'm treating subtitles as "one" sample but now I think it would be more natural to interpret samples as ms. I.e. a subtitle which starts at 00:00:01.000 and ends at 00:00:02.799 would have granulepos 2s + 799ms + 1 (because we start 0) = 2800 and with length (inside the packet) set to 1800 I will add this in the next version of the filters and give you all the details to adapt you tools accordingly. I'm sorry for any inconvinience this may cause. Kind regards, Tobias |
20th September 2002, 09:21 | #62 | Link |
Registered User
Join Date: Feb 2002
Location: Madrid (Spain)
Posts: 94
|
Some more changes
I'm also going to change the architecture of the filters. I currently creating some libraries which will be load dynamically according to the streamtype. The idea behind is to make it easier to adapt other formats like flac and speex and to make it easier to develop new tools (outside DS).
The functions are desgined to be called without knowledge of the stream contents. These librariese will provide the following functions: For Splitting: - translate page granulespos to a reference time (100ns units) - translate packet granulepos to a reference time (100ns units) For Multiplexing: - translate reference time to packet granulepos For Decoding: - deliver the header packets to the library - return mediatype - PacketIn - BufferOut For Encoding - Return the header packets - return the mediatype - BuferIn - PacketOut I will give some more details in the next days. Kind regards, Tobias |
20th September 2002, 09:25 | #63 | Link |
MKVToolNix author
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,278
|
I still agree that your proposition looks better than the current implementation. I'll follow your lead as soon as you've got something working with the new scheme. If you want to change the identifier to 'videoV2' or whatever then by all means do so
__________________
Latest MKVToolNix is v83.0 If I ever ask you to upload something, please use my file server. |
20th September 2002, 09:32 | #64 | Link | |
Registered User
Join Date: Oct 2001
Location: France
Posts: 517
|
Quote:
If the subtitle end @ 2s799, there have been 2799 ms (samples) till the beginning (0->1, 1->2, ..., 2798->2799). This mean the granulepos of the last sample is 2798 (ms). So if we start counting granulepos from 0, then we should set the Packet's granulepos to 2798, and if we start counting granulepos from 1 then it is 2799 (which correspond to the Xiph's documentation : granulepos = total samples encoded and fully decodable). Maybe you made a shortcut and your "ends at 00:00:02.799" meant "last sample of the subtitle starts @ 00:00:02.799", or maybe I should go back to school and learn some math again (). |
|
20th September 2002, 09:53 | #65 | Link | |
Registered User
Join Date: Feb 2002
Location: Madrid (Spain)
Posts: 94
|
Quote:
Kind regards, Tobias |
|
20th September 2002, 09:59 | #66 | Link |
Registered User
Join Date: Oct 2001
Location: France
Posts: 517
|
Question concerning data included in the stream_header structure.
Here is what I "think" : - time_unit is the unit time expressed in a 100ns time reference (100ns is the reference time for Windows' DirectShow) So the real time unit is time_unit / 10000000 - samples_per_unit is the number of samples per unit of time So the number of samples per second is : samples_per_second = samples_per_unit / (time_unit / 10000000) Code:
samples_per_second 10000000 Or : -------------------- = ----------- samples_per_unit time_unit - for a video stream there is only 1 sample per unit, so samples_per_second = fps = 10000000 / time_unit - for an audio stream the unit is 1s, so time_unit = 10000000 and samples_per_unit = samples_per_second - for a text stream, the unit is 1ms, so time_unit = 10000. As one sample lasts 1ms, samples_per_second = 1000 => samples_per_unit = 1 This made me think about this formula (I put it in my sources) : granulepos = sample number (since the beginning) (if start @ 1) 1000000 : to get microseconds from seconds 10000000 : reference of the time_unit (100 ns) So samples_per_unit * (10000000 / time_unit) = samples_per_second And then timestamp (in s) = (granulepos-1) / samples_per_second Or timestamp (in micros) = 1000000 * (granulepos-1) / samples_per_unit This give : (sh is the stream_header) Code:
(granulepos-1) * 1000000 * sh.time_unit timestamp = ----------------------------------------- micros 10000000 * sh.samples_per_unit Code:
(granulepos-1) * sh.time_unit timestamp = -------------------------------- micros 10 * sh.samples_per_unit If yes, does the precedent applications (for video, audio and text) are the unique ones (i.e. we cannot use other values)? Thanks Last edited by Suiryc; 20th September 2002 at 10:01. |
20th September 2002, 10:03 | #67 | Link | ||
Registered User
Join Date: Oct 2001
Location: France
Posts: 517
|
Quote:
Quote:
|
||
20th September 2002, 10:38 | #68 | Link |
Registered User
Join Date: Feb 2002
Location: Madrid (Spain)
Posts: 94
|
The formula for the current timestamps (from the packets) is just
Code:
granulepos * sh.time_unit timestamp = -------------------------------- micros 10 * sh.samples_per_unit Code:
(granulepos-packet_len) * sh.time_unit timestamp = -------------------------------- micros 10 * sh.samples_per_unit Code:
// Returns the length of a packet in media time (not for vorbis packets) extern ogg_int32_t stream_packet_len(stream_header* sh, ogg_packet* op) { if (op->packet[0] & PACKET_TYPE_HEADER) return E_NOTDATA; ogg_int16_t lenbytes; lenbytes = (*op->packet & PACKET_LEN_BITS01)>>6; lenbytes |= (*op->packet & PACKET_LEN_BITS2) <<1; if (lenbytes == 0) return sh->default_len; ogg_int32_t len = 0; while (lenbytes) { (len) <<= 8; (len) |= op->packet[lenbytes]; lenbytes--; } return len; } Tobias Last edited by TobiasWaldvogel; 20th September 2002 at 10:42. |
20th September 2002, 10:50 | #69 | Link |
Moderator
Join Date: Oct 2001
Location: Germany
Posts: 4,454
|
Uh, nice to see that the development is going on again!
While you're at timestamps/granulepos here, is it possible to get a more keyframe accurate jump/cut behaviour implemented? My idea was to fetch an avi-parser like from mplayer or from aviplay and allow the oggmuxer DSF to directly open an avi file... is that possible/desireable? Regards, Koepi
__________________
Koepi's new media development site |
20th September 2002, 11:08 | #70 | Link | |
Registered User
Join Date: Oct 2001
Location: France
Posts: 517
|
Quote:
This is what I presently use - in another way - for sorting Pages before writing them to file. |
|
20th September 2002, 11:21 | #71 | Link |
Registered User
Join Date: Oct 2001
Location: France
Posts: 517
|
@Koepi & Tobias
Well I saw that some guys are trying to activate the delay feature in OggMux using TimeLine objects. I have restricted knowledge in DShow, but I think that maybe there is another thing to do : add a delay possibility directly within OggDS (if possible of course). Why ? Because I once tried to manually insert delay with my muxer (i.e. I "delayed" the granulepos of the data Packets), and the result was not so good : For small delays this seem to work but I am not sure the real delay in audio is the one I wanted. For big delays (for example 2s) the clip doesn't start by itself and I have to seek a little in the clip. So with my restricted knowledge I think that the problem may be (unless I did something wrong of course ) : the audio decoder after OggDS expect data since the very beginning, and if OggDS doesn't feed it (or tell it to wait a certain time) it gets angry. Maybe Tobias can enlighten us here : do you think that just delaying the granulepos - manually in my muxer or using TimeLine objects in OggMux - is OK ? |
20th September 2002, 11:53 | #73 | Link | ||||||
Registered User
Join Date: Nov 2001
Location: Germany
Posts: 31
|
Quote:
Quote:
Quote:
Quote:
Quote:
So are there more options? btw: I'm using Windows XP SP1 if that matters. Quote:
Is there a possibility to keep the Window open so I can read the message, which probably shows up in there? |
||||||
20th September 2002, 12:00 | #74 | Link |
Registered User
Join Date: Nov 2001
Location: Germany
Posts: 31
|
eclipsedvd and Suiryc: I just found and fixed the problem with the shell extensions. The %1 in the commandline, which gets replaced by the filename was not enclosed in "" - and because my filename had spaces in it, it wouldn't work. Now, after fixing this, everything works fine for me
|
20th September 2002, 15:06 | #75 | Link |
Registered User
Join Date: Oct 2001
Location: were people always get wet feet
Posts: 328
|
Ahem, back to present.
Suiryc, I tested your tool and it worked fluently. Great! Nevertheless, I have a suggestion: Could you implement a function to just restrict one part to the desired size? Yesterday I had the case that your tool cut my ~1.35GB stream with size preset 700MB into 3 pieces with the last one being 1,3MB. I think in most cases people want to cut for 2CDs, so if one is slightly oversized... most recorders can overburn nowadays. Still it takes some time to process such a stream again. I admit that it is in addition a personal problem but my DVD-Rom, preferably as "first drive", is unable to read overburned CD, though it's quality fabrique Pioneer DVD-116, while my Lite-on recorder is able to. So in my "personal" case one (normally the first) CD mustfit the size. I hate to ask for such things like: "hey mastermind, can you put together a personal solution for me, which is totally useless to other people except myself?" But rethinking, I find that with the very tight and exact file size prediction of todays codecs in use (XVID, DIVX, RM9 what else?) there's little chance that the second part will surpass a plus of 10 MB if cut size preset is set to 700-702MB? What do you think ? So far there is no tool to join OGM steams, right?
__________________
I'm probably misconfused... |
20th September 2002, 15:13 | #76 | Link |
MKVToolNix author
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,278
|
My Linux tools implement a '-n' switch that tells ogmsplit how many files it should create at most - even if the last one is bigger than the intended size. This is rather trivial to implement so I'd think suiryc will do that. This is a feature that greatly eases the splitting in a lot of cases - simply split at 700 and go for 2 files max. Several people are very happy with this feature, so it won't be useless
__________________
Latest MKVToolNix is v83.0 If I ever ask you to upload something, please use my file server. |
20th September 2002, 15:20 | #77 | Link |
MKVToolNix author
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,278
|
Oh btw, Tobias - I hope you don't take too long with your new version. I'm eager to adjust my tools
__________________
Latest MKVToolNix is v83.0 If I ever ask you to upload something, please use my file server. |
20th September 2002, 16:48 | #78 | Link | |||||
Registered User
Join Date: Oct 2001
Location: France
Posts: 517
|
Quote:
Quote:
but ... Quote:
Quote:
No problem here. You know sometimes you think that what you want is totally useless for other people but it's generally not the case (at least I am sure that other people would like a workaround here). Quote:
I could give this a try, but with the options I added in my splitter (concerning chapters) I will have a lot of things to verify before the merged file looks like the original one (or at least is not too far) |
|||||
20th September 2002, 16:52 | #79 | Link | |
Registered User
Join Date: Oct 2001
Location: France
Posts: 517
|
Quote:
|
|
20th September 2002, 16:55 | #80 | Link |
AC3 5.1 Addict
Join Date: Nov 2001
Location: Big Blue Nation_USA
Posts: 2,036
|
Seems to work great for splitting and info. Great work!
Any chance of a GUI or did I miss the link somewhere in this thread?
__________________
Need AC3 & SPDIF setup info? |
Thread Tools | Search this Thread |
Display Modes | |
|
|