[Asterisk-video] Fixed h324m and mp4save (bug#3)

[Klaus Darilion]

I've also tested the new code with same result :-(

Thomas Frieling schrieb:
> Hi Sergio!
> 
> I just tested the new version. It doesn't crash badly but I cannot see a
> difference in the resulting video files...
> 
> There is still the difference in time and about every second time
> (strongly depends on the handset you use) the video track seems to be
> still corrupted:
> 
> $ mp4info /tmp/recorded_video.mp4 
> mp4info version 1.5.0.1
> /tmp/recorded_video.mp4:
> Track	Type	Info
> 1	audio	AMR, 15.260 secs, 12 kbps, 8000 Hz
> 2	hint	Payload AMR for track 1
> 3	video	H.263, 5.077 secs, 62 kbps, 176x144 @ 25.802639 fps
> 4	hint	Payload H263-1998 for track 3
> 
> 
> MP4ERROR: MP4File::FindBytesProperty: no such property
> moov.trak[2].mdia.minf.stbl.stsd.*[0].*.esds.decConfigDescr.decSpecificInfo[0].info
> /usr/local/bin/mp4creator: Could not parse input file, invalid video
> stream?
> /usr/local/bin/mp4info version 1.5.0.1
> 
> 
> Regards,
> Thomas
> 
> 
> 
> Am Mittwoch, den 29.08.2007, 23:06 +0200 schrieb Sergio Garcia Murillo:
>> I've just commited a version which, I beleive, fixes the problem with
>> h324m and mp4save.
>> The problem was in the marked bit of the video frame that was not set
>> correctly. 
>> As It can only be set when you know that the next packet is the
>> begining of I new frame I
>> have to implement a temporary buffer and delay the sending of the
>> frame until the next
>> has arrive.
>>  
>> Please, test it and let me know if it crashes badly or it solves the
>> problem correctly.. :)
>>  
>> BR
>> Sergio
>> _______________________________________________
>> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>>
>> asterisk-video mailing list
>> To UNSUBSCRIBE or update options visit:
>>    http://lists.digium.com/mailman/listinfo/asterisk-video