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. |
14th February 2014, 11:28 | #1 | Link |
Registered User
Join Date: Feb 2014
Posts: 15
|
switching stco atom to co64
I am trying to switch the stco atom to co64 in a mpeg4
Problem is when I do so, the video won't play. Can't tell what's going wrong... here's what I've done: 1) deleted stco atom 2) re-wrote stco atom as co64, except that type is now "co64" and each chunk is written as 64-bit, and the value of each chunk is increased by 4 3) Updated all affected sizes (i.e. stbl, trak, moov...) As a test, I also tried without increasing the value of each chunk (the reason for the increase is to account for extra bytes in going from 32-bit to 64-bit) I also tried setting size of co64 to extended, 64-bit type but that didn't do anything (I don't think that's the issue since inspecting other >4GB files that use co64 didn't do that) For what it's worth- running my generated output and original and test file headers all reveal the same sort of data (i.e. there's nothing getting corrupted in my implementation of the above, as far as I can tell) For an example for the math to add up- the total header size for two traks with 24 chunks each has increased by 192 bytes (I think this makes sense- (24x2) = 48. 48 * 4 = 192) Anything I'm missing? |
14th February 2014, 13:46 | #2 | Link | |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
Quote:
If the MOOV atom is located before the MDAT atom, doesn't this shift every chunk by 4 * entry_count bytes when every entry in the "stco" table is increased from 4 to 8 bytes? http://s15.postimg.org/64z23thsb/co64.png And if the MOOV atom is located after the MDAT atom, which is quite possible, then chunk positions shouldn't change at all, right? Anyway, if the size of the "stco" (co64) atom changes, then the size of each enclosing atom (stbl, minf, mdia, trak and moov) changes too, so these need to be updated as well!
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ Last edited by LoRd_MuldeR; 14th February 2014 at 15:10. |
|
14th February 2014, 15:50 | #3 | Link |
Registered User
Join Date: Feb 2014
Posts: 15
|
Thanks for the pointer! Feeling silly I missed that
But still, not working :\ here is my rough trace... for now assume all atom sizes are correct for the entire chain: CHUNK TO OFFSET TYPE: stco HEADER SIZE 8 DATA SIZE 104 VERSION 0 FLAGS 0 0 0 NUMBER OF ENTRIES: 24 ----BEGIN ENTRIES------- CHUNK 10421 CHUNK 61488 CHUNK 86476 CHUNK 114941 CHUNK 140029 CHUNK 168129 CHUNK 193326 CHUNK 217886 CHUNK 268335 CHUNK 292980 CHUNK 322979 CHUNK 347883 CHUNK 372769 CHUNK 402186 CHUNK 426528 CHUNK 478735 CHUNK 503827 CHUNK 533121 CHUNK 558362 CHUNK 583951 INCREASING BY 96 ( 24 * 4) NEW CHUNK TO OFFSET TYPE: co64 HEADER SIZE 8 DATA SIZE 200 VERSION 0 FLAGS 0 0 0 NUMBER OF ENTRIES: 24 ----BEGIN ENTRIES------- CHUNK 10517 CHUNK 61584 CHUNK 86572 CHUNK 115037 CHUNK 140125 CHUNK 168225 CHUNK 193422 CHUNK 217982 CHUNK 268431 CHUNK 293076 CHUNK 323075 CHUNK 347979 CHUNK 372865 CHUNK 402282 CHUNK 426624 CHUNK 478831 CHUNK 503923 CHUNK 533217 CHUNK 558458 CHUNK 584047 -------------------------------------------------------- CHUNK TO OFFSET TYPE: stco HEADER SIZE 8 DATA SIZE 104 VERSION 0 FLAGS 0 0 0 NUMBER OF ENTRIES: 24 ----BEGIN ENTRIES------- CHUNK 53094 CHUNK 78083 CHUNK 106967 CHUNK 131636 CHUNK 160155 CHUNK 184933 CHUNK 209912 CHUNK 259942 CHUNK 285006 CHUNK 314586 CHUNK 339490 CHUNK 364795 CHUNK 393793 CHUNK 418554 CHUNK 470342 CHUNK 495853 CHUNK 524728 CHUNK 550388 CHUNK 575558 CHUNK 605345 INCREASING BY 96 ( 24 * 4) NEW CHUNK TO OFFSET TYPE: co64 HEADER SIZE 8 DATA SIZE 200 VERSION 0 FLAGS 0 0 0 NUMBER OF ENTRIES: 24 ----BEGIN ENTRIES------- CHUNK 53190 CHUNK 78179 CHUNK 107063 CHUNK 131732 CHUNK 160251 CHUNK 185029 CHUNK 210008 CHUNK 260038 CHUNK 285102 CHUNK 314682 CHUNK 339586 CHUNK 364891 CHUNK 393889 CHUNK 418650 CHUNK 470438 CHUNK 495949 CHUNK 524824 CHUNK 550484 CHUNK 575654 CHUNK 605441 Gotta run, will be back on Sunday... hope you have more ideas up your sleeves Thanks again! |
14th February 2014, 15:59 | #4 | Link |
Registered User
Join Date: Feb 2014
Posts: 15
|
Oh wait a second... I see another problem, they need to be offseted by the number of *total entries* that will change * 4
i.e. to take into account both traks... Will try that when I'm back at it Thanks for the heads up |
14th February 2014, 17:07 | #5 | Link |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
Sure, if you are doing this with multiple tracks, the data will be shifted by 4 * (entry_count[track_1] + entry_count[track_2] + ... + entry_count[track_N])
But why are you trying to do this "by hand" anyway? Why not use one of the various MP4 muxing tools (or MP4 muxing libraries) that are available? Don't those generate "co64" tables automatically fore LARGE files?
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ Last edited by LoRd_MuldeR; 14th February 2014 at 23:36. |
Tags |
atoms, mpeg-4, quicktime |
|
|