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.

 

Go Back   Doom9's Forum > Video Encoding > MPEG-4 AVC / H.264

Reply
 
Thread Tools Search this Thread Display Modes
Old 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?
dmk is offline   Reply With Quote
Old 14th February 2014, 13:46   #2  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,146
Quote:
Originally Posted by dmk View Post
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!
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.



Last edited by LoRd_MuldeR; 14th February 2014 at 15:10.
LoRd_MuldeR is offline   Reply With Quote
Old 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!
dmk is offline   Reply With Quote
Old 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
dmk is offline   Reply With Quote
Old 14th February 2014, 17:07   #5  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,146
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?
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.



Last edited by LoRd_MuldeR; 14th February 2014 at 23:36.
LoRd_MuldeR is offline   Reply With Quote
Old 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 :\
dmk is offline   Reply With Quote
Reply

Tags
atoms, mpeg-4, quicktime

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 12:18.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.