fur-q / mp4v2

Automatically exported from code.google.com/p/mp4v2
Other
0 stars 0 forks source link

Hinf atom incorrectly created - RTP hint track name (null) #90

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
There is  a problem retreiving the name of the hinted track via 
MP4GetHintTrackRtpPayload, it is allways returned as null.

 The output of mp4info on a hinted file confirms the problem: 
./mp4info version -r0 
/tmp/test2.mp4: 
Track   Type    Info 
2       video   H264 Basel...@1.3, 30.063 secs, 379 kbps, 352x288 @ 
29.970396 fps 
3       hint    Payload (null) for track 2 
 Encoded with: mp4creator 1.5.0.1 

Using old mpeg4ip the output on the same file was correct. 

The dump  info shows that the hinf atom is handled as an array of bytes

tmp/test2.mp4": type = "hinf" data-size = 183 (0xb7) hdr 8 
"/tmp/test2.mp4": value = <183 bytes> 
"/tmp/test2.mp4": value:00000000: 00 00 00 10 74 72 70 79 00 00 00 00 
00 15 eb 34 ....trpy.......4 
"/tmp/test2.mp4": value:00000010: 00 00 00 10 6e 75 6d 70 00 00 00 00 
00 00 05 9d ....nump........ 
"/tmp/test2.mp4": value:00000020: 00 00 00 10 74 70 79 6c 00 00 00 00 
00 15 a7 d8 ....tpyl........ 
"/tmp/test2.mp4": value:00000030: 00 00 00 10 6d 61 78 72 00 00 03 e8 
00 00 cc 4e ....maxr.......N 
"/tmp/test2.mp4": value:00000040: 00 00 00 10 64 6d 65 64 00 00 00 00 
00 15 9d c0 ....dmed........ 
"/tmp/test2.mp4": value:00000050: 00 00 00 10 64 69 6d 6d 00 00 00 00 
00 00 0a 18 ....dimm........ 
"/tmp/test2.mp4": value:00000060: 00 00 00 10 64 72 65 70 00 00 00 00 
00 00 00 00 ....drep........ 
"/tmp/test2.mp4": value:00000070: 00 00 00 0c 74 6d 69 6e 00 00 00 00 
00 00 00 0c ....tmin........ 
"/tmp/test2.mp4": value:00000080: 74 6d 61 78 00 00 00 00 00 00 00 0c 
70 6d 61 78 tmax........pmax 
"/tmp/test2.mp4": value:00000090: 00 00 05 c0 00 00 00 0c 64 6d 61 78 
00 00 03 e9 ........dmax.... 
"/tmp/test2.mp4": value:000000a0: 00 00 00 17 70 61 79 74 00 00 00 60 
0a 48 32 36 ....payt...`.H26 
"/tmp/test2.mp4": value:000000b0: 34 2f 33 30 30 30 
30                            4/30000 
"/tmp/test2.mp4": FindProperty: matched trak.udta.hinf.payt.rtpMap 
"/tmp/test2.mp4": FindProperty: matched udta.hinf.payt.rtpMap 
"/tmp/test2.mp4": FindProperty: matched hinf.payt.rtpMap 
"/tmp/test2.mp4": FindProperty: no match for payt.rtpMap

But with mp4dump of old mpeg4ip it is shown as an atom 

type hinf 
     type trpy 
      bytes = 1436468 (0x000000000015eb34) 
     type nump 
      packets = 1437 (0x000000000000059d) 
     type tpyl 
      bytes = 1419224 (0x000000000015a7d8) 
     type maxr 
      granularity = 1000 (0x000003e8) 
      bytes = 52302 (0x0000cc4e) 
     type dmed 
      bytes = 1416640 (0x0000000000159dc0) 
     type dimm 
      bytes = 2584 (0x0000000000000a18) 
     type drep 
      bytes = 0 (0x0000000000000000) 
     type tmin 
      milliSecs = 0 (0x00000000) 
     type tmax 
      milliSecs = 0 (0x00000000) 
     type pmax 
      bytes = 1472 (0x000005c0) 
     type dmax 
      milliSecs = 1001 (0x000003e9) 
     type payt 
      payloadNumber = 96 (0x00000060) 
      rtpMap = H264/30000 

The solution is to remove "hinf" from the UDTA_ELEMENTS array so the 
MP4HinfAtom is created correctly.

Original issue reported on code.google.com by sergio.g...@gmail.com on 8 Apr 2011 at 9:35

GoogleCodeExporter commented 8 years ago
Thanks for reporting this; I spoke with Kona about it since he originally put 
in UDTA_ELEMENTS, and here was his response:

UDTA_ELEMENTS is just skeleton for udta child atom specialization. r194 
regresses such that (at least) 2 specializations of udta children are no longer 
specialized. I agree and recommend:

1. remove { hinf, hnti } from UDTA_ELEMENTS[]
2. suggest move construction of { MP4HinfAtom, MP4HntiAtom } from no-context 
block to udta context block.

...so this has been done.  It should now correctly create the hinf atom instead 
of the udta element atom.  This change should be in r466

Original comment by kid...@gmail.com on 23 May 2011 at 10:14