switching stco atom to co64

dmk · 14th February 2014, 11:28

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?

LoRd_MuldeR · 14th February 2014, 13:46

Quote:

Originally Posted by dmk

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

Don't quite understand why you increase each value by 4 exactly

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!

dmk · 14th February 2014, 15:50

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!

dmk · 14th February 2014, 15:59

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

LoRd_MuldeR · 14th February 2014, 17:07

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?

dmk · 16th February 2014, 08:57

Thanks- that did the trick

Need to do all this atom shifting stuff by hand since I'm writing a pseudostreaming server in Flash/Actionscript. No libs available for that I'm afraid :\

14th February 2014, 11:28	#1 \| Link
dmk 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, 17:07	#5 \| Link
LoRd_MuldeR 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.

14th February 2014, 15:50	#3 \| Link
dmk 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
dmk 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

16th February 2014, 08:57	#6 \| Link
dmk Registered User Join Date: Feb 2014 Posts: 15	Thanks- that did the trick Need to do all this atom shifting stuff by hand since I'm writing a pseudostreaming server in Flash/Actionscript. No libs available for that I'm afraid :\