[Ffmpeg-devel-irc] ffmpeg-devel.log.20120822

[burek]

[05:28] <xxthink> how to use ffmpeg to decode cuvc format?
[05:29] <Daemon404> you do not, because it hasn't been reverse engineer'd yet.
[05:29] <xxthink> ok
[09:57] <JEEB> michaelni, I wish I had known that there was a huffman code len gen already available created by loren... I still remember looking at huffman.c/h and only seeing a function to get the whole pack for decoding >_> (which I did actually use for lengths at one point, throwing everything else out)
[09:58] <japjap> Hello, I am having a remote DVR and I want to ask it to play some video for given time range (RTSP). I need to record that locally with ffmpeg. Does ffmpeg support this ?
[10:00] <JEEB> also Daemon404 tried to use the dsputil median predict but IIRC the functionality didn't match
[10:33] <japjap> So does anybody know about setting the date/time range ?
[10:52] <cbsrobot> japjap: can you make the rtsp stream public ?
[10:53] <highgod> Hi all.I want to ask a question.I want to add opendecode to decode h264 in ffmpeg.but I am not familar with configure file.I can I modify configure file to create a string like "#define CONFIG_H264_OPENVIDEO_HWACCEL 1" in config.h? Thanks.
[10:58] <ubitux> maybe add "h264_openvideo_hwaccel" in the CONFIG_LIST
[10:58] <ubitux> then it should be available through some kind of --enable-h264-openvideo-hwaccel or something
[10:59] <highgod> Thanks,I will try it.
[11:03] <highgod> Yes it worked,and I have to add REGISTER_HWACCEL (H264_OPENVIDEO, h264_openvideo); in avcodec_register_all function.Thank you very much
[11:18] <ubitux> ah wait
[11:18] <ubitux> if it's an hwaccel, it's most likely not the correct place
[11:19] <ubitux> you might not need anything in the configure
[11:19] <ubitux> except dependencies
[11:20] <ubitux> something like h264_openvideo_hwaccel_deps=... 
[11:20] <ubitux> look how the other hwaccel are made
[11:38] <highgod> Oh,hehe,I want to run it first,and than correct the config.hehe Thanks.I have added this in configure file h264_openvideo_hwaccel_deps.Thanks.
[13:06] <ubitux> michaelni: how could i reproduce the case you mention in the ogg patch?
[13:07] <ubitux> i tested the patch with a webradio where there is stream switches, and of course with the problematic sample
[13:10] <ubitux> Daemon404: actually, the padding with silence is pointless, it's done automatically
[13:11] <ubitux> or at least it seems :p
[13:21] <saste> typedef short DCTELEM;
[13:22] <saste> any reason is not typedef int16_t DCTELEM?
[14:23] <michaelni> ubitux i dont have a testcase but maybe zzuf would cause some crashes
[14:23] <ubitux> oh.
[14:24] <michaelni> the possible problem i saw was that a stream could be added after ogg_save and then ogg restore ould remove it from the ogg trsuct
[14:24] <michaelni> but not AVFormatContext
[14:24] <michaelni> but that maybe isnt the only case
[14:25] <michaelni> and once things are inconsistent bad things can happen (example is seek based on a strea, that isnt in the ogg struct)
[14:28] <michaelni> JEEB, Daemon404  ill take a deeper look at if dsputil median predict can be used
[14:28] <michaelni> from a quick look yesterday they seemed compatible
[16:29] <michaelni> JEEB, Daemon404, patchset that switches to dsputils median predict code posted, review welcome
[16:30] Action: Daemon404 wakes up
[16:42] <kriegerod> can AVFormatContext & AVIOContext be used for frames reading again after interrupt_callback returning positive?
[16:43] <Daemon404> weird... did my review eve get through to the ML?
[16:43] <Daemon404> isn't appearing on pipermail
[16:44] <michaelni> Daemon404, which review, when/where posted?
[16:46] <Daemon404> for patch 1/7
[16:46] <Daemon404> i think the spam filters caught it
[16:46] <Daemon404> utvideoenc
[16:46] <michaelni> michael sees: 16:41 Derek Buitenhui (0.9K) 
[16:47] <Daemon404> ok
[16:47] <Daemon404> that'd be it
[16:47] <Daemon404> not listed on: http://ffmpeg.org/pipermail/ffmpeg-devel/2012-August/
[16:47] Action: Daemon404 shrug
[17:00] <retrosnub1> I'd like to have a go at this ticket: http://ffmpeg.org/trac/ffmpeg/ticket/1537
[17:00] <retrosnub1> I have a decent understanding of C but have never worked with ffmpeg before. Could you give me some pointers where to start?
[17:01] <retrosnub1> like where in the source are the pixel formats implemented
[17:02] <av500> a good hint is to always work backwards from the error message
[17:03] <retrosnub1> that has led me to the file libavdevice/v4l2.c but I'm stuck there
[17:05] <Daemon404> damn thunderbird... addding a > in front of any line that starts with From
[17:10] <kierank> retrosnub1: google what cpia is
[17:10] <michaelni> seems some simple non intra compression scheme
[17:11] <retrosnub1> used by some old webcams
[17:13] <retrosnub1> ok, so I guess I have to add the format to the enum in libavutil/pixfmt.h to begin with
[17:13] <michaelni> probably no
[17:13] <michaelni> if its a non intra compression scheme then its not  apixel format
[17:13] <retrosnub1> what do you suggest?
[17:14] <michaelni> v4l* just calls it that way due to lack of an other term in the APi i suspect
[17:14] <michaelni> it would need a simple AVCodec that decodes it to some raw YUV
[17:14] <retrosnub1> ok
[17:15] <michaelni> try to pick a simple one that uses reget_buffer() as example
[17:16] <Daemon404> michaelni, all reviewed. mostly cosmetic.
[17:19] <michaelni> Daemon404, moment i just need to double check that libutvideo decodes it identical after the huffman changes
[17:19] <michaelni> i checked our decoder yesterday already
[17:19] <ubitux> (your first sed is missing a greedy mode :-°)
[17:20] <retrosnub1> ok, it seems libavcodec/avs.c uses reget_buffer and is quite smallsized
[17:21] <Daemon404> michaelni, ok
[17:35] <Daemon404> i miss CIA
[17:35] <Daemon404> maybe someone can setup a bot to use teh github hooks
[17:35] <Daemon404> actually... cia might be able to.
[17:36] <michaelni> JEEB, where do you want the k++ ? in the for() after i+= or on a seperate line ?
[20:18] <CIA-56> FFmpeg: 03Michael Niedermayer 07master * rf92f493 10/ (13 files in 2 dirs): utvideoenc: use ff_generate_len() (+5 more commits...) - http://git.io/_0iYew
[20:18] <Daemon404> \o/
[20:18] Action: michaelni hugs CIA-56 
[20:18] Action: CIA-56 hugs michaelni
[20:18] <JEEB> michaelni, the k++ in my opinion can be within the for() as it should be readable like that, but it indeed would take some simplicity out of it (no longer a "single-variable" loop, if you know what I mean)...
[20:19] <JEEB> I guess since all other loops are IIRC "single-variable" I would like them all to be so?
[20:21] <michaelni> JEEB, whatever you prefer, just tell me clearly which you prefer :)
[20:21] <JEEB> then the second line I said :)
[20:25] <ubitux> yay
[20:25] <michaelni> JEEB, ok
[20:26] <michaelni> btw, in case people didnt notice CIA now runs over our github mirror, this means it will lag behind a bit
[20:27] <Daemon404> better than not at all
[20:27] <JEEB> makes sense since they finally killed off their e-mail based service after all these years of deprecation
[20:27] <michaelni> ill disable the github side again if it starts working over videolan again
[20:28] <michaelni> they didnt just kill their email based service they completely killed email, not even password recovery via email works
[20:28] <JEEB> oh
[20:56] <Compn> pff
[20:56] <Compn> who needs email anyway
[20:58] <CIA-56> FFmpeg: 03Michael Niedermayer 07master * rba69eb5 10/ (libavcodec/utvideo.h libavcodec/utvideoenc.c): utvideoenc: avoid writing into the input picture. - http://git.io/W76EVA
[20:58] <CIA-56> FFmpeg: 03Michael Niedermayer 07master * rd79c87a 10/ libavcodec/utvideoenc.c : utvideoenc: drop step - http://git.io/bkUZrg
[20:58] <CIA-56> FFmpeg: 03Michael Niedermayer 07master * r729b2d0 10/ (libavcodec/utvideo.h libavcodec/utvideoenc.c): utvideoenc: align mangled buffer starts. - http://git.io/gg246A
[20:58] <CIA-56> FFmpeg: 03Michael Niedermayer 07master * r12ad68b 10/ libavcodec/utvideoenc.c : utvideoenc: use dsp.sub_hfyu_median_prediction - http://git.io/DJ7bpQ
[20:59] <michaelni> the commits over videolan-CIA looked more verbose :/
[21:00] <j-b> which ones?
[21:01] <michaelni> the ones we got in the last years before cia died :)
[21:01] <michaelni> btw j-b will the videolan hook be swicthed to that RPC thing ?
[21:02] <michaelni> or some other solution ?
[21:04] <j-b> yes, of course
[21:04] <j-b> we are trying several solutions
[21:04] <j-b> none are perfect yet
[21:05] <Daemon404> orite
[21:05] Action: Daemon404 should send his patches to vlc
[21:05] Action: Daemon404 forgot
[21:05] <j-b> canopus?N
[21:05] <Daemon404> j-b, also that qt problem and ARGB
[21:05] <j-b> ok
[21:05] <Daemon404> unless that qt build failure was fixed.
[21:05] <j-b> cool
[21:06] <saste> #1672 lol
[21:07] <saste> ffget
[21:08] <Daemon404> j-b, do decoder issues on vlc's trac get forwarded to ffmpeg or libav's bug trackers?
[21:08] <Daemon404> i see e.g. a lagarith one
[21:10] <ubitux> saste: and smb ;)
[21:11] <saste> and nfs
[21:11] <saste> and why not, smtp
[21:11] <saste> would be useful to send a video by email
[21:11] <saste> but seriously, i would not be against an ftp implementation
[21:12] <Daemon404> >_>
[21:12] <Daemon404> libavkitchensink
[21:12] <saste> we still miss an editor
[21:12] <saste> drawtext is still far from it
[21:12] <ubitux> i'm not against ftp either :)
[21:12] <Daemon404> we have parts of a libm and libc
[21:12] <Daemon404> soon... FFmpegOS
[21:13] <ubitux> well maybe we should focus on ivtc and motion estimation fitst
[21:13] <ubitux> first*
[21:16] <Compn> i thought ffmpeg had ftp support
[21:16] <Compn> mplayer and vlc have ftp support :P
[21:16] <Daemon404> vlc has lulz things
[21:16] <Daemon404> i think it even supports playing files still inside rars
[21:17] <Daemon404> for the truly braindead
[21:17] <Compn> ffmpeg should have rar support 
[21:17] <Compn> why ignore a large number of files like that Daemon404 ?
[21:17] <Compn> 99% of usenet ...
[21:18] <Daemon404> because the user should be able to know rar != video
[21:18] <Compn> the user knows that
[21:18] <ubitux> well rar wouldn't be that idiot
[21:18] <nevcairiel> i never understood why people are against unpacking it
[21:18] <ubitux> given the insanity of the warez scene
[21:18] <Compn> he would just rather play a rar than extract it first
[21:18] <Daemon404> its like my mom copying an excel spread sheet to a usb drive, and wondering why "double clicking it on my other pc doesnt work"
[21:19] <Daemon404> (tip: excel was not installed)
[21:19] <ubitux> nevcairiel: to be able to seed it without duplicating the data i guess
[21:19] <Compn> it takes time, uses hd space and wears out the hd :P
[21:19] <nevcairiel> you dont seed in usenet
[21:19] <Daemon404> most usenet clients unrar it for you
[21:19] <nevcairiel> unless i misunderstand the concept :P
[21:19] <ubitux> usenet is not the only way to share warez
[21:19] <Daemon404> true story.
[21:19] <Daemon404> and most torrenys are pre-unrared
[21:19] <Daemon404> and if youre on a topsite, you know what a rar is
[21:19] <Compn> the scene still uses rar
[21:19] <ubitux> a lot of torrents are still in rar
[21:19] <nevcairiel> only place i really see rars these days are usenet
[21:19] <Daemon404> ubitux, only on fancy priv trackers
[21:20] <Compn> its not about knowing rar
[21:20] <nevcairiel> my fancy tracker has a "no rars" rule :d
[21:20] <Compn> its about supporting a file format that is just about everywhere
[21:20] <ubitux> i found some regularly on tpb
[21:20] <Daemon404> Compn, rar capabaility does not belong in a video library
[21:20] <Daemon404> end of story
[21:20] <Compn> couple trackers have no-rar rules :p
[21:20] <ubitux> it's just another storage method
[21:20] <ubitux> adding a protocol should work
[21:20] <ubitux> :)
[21:20] <Daemon404> it should be implemented in the player
[21:20] <Daemon404> not vid lib
[21:20] <Daemon404> if anywhere.
[21:21] <ubitux> if it's in the lib, it will be supported by any players
[21:21] <ubitux> (even ffplay, yay!)
[21:21] <Compn> yay
[21:21] <ubitux> Daemon404: and btw, even if you don't have it for video, it's common to have all the vobsubz in a .rar
[21:21] <ubitux> (yeah that's stupid as well)
[21:21] <Daemon404> ubitux, not allowed in hd scene
[21:22] <Compn> hd scene doesnt have vobsubs by definition dont it
[21:22] <ubitux> pgssub ? :)
[21:22] <Compn> pgs sub would be another question :)
[21:22] <Daemon404> nope
[21:22] <Daemon404> hd scene is srt
[21:22] <Daemon404> and muxed in
[21:23] <Compn> Daemon404 : you like the scene ?
[21:23] <Daemon404> fuck no
[21:23] <Daemon404> theyre retarded
[21:23] <Compn> hehe
[21:23] <ubitux> then let's piss them off and put some vobsub in .rar
[21:25] <nevcairiel> I can see one file rar'ed working ok, but if you have more then one file in your rar, how the hell do you do file selection? =p
[21:26] <Daemon404> rand()
[21:28] <Compn> nevcairiel : biggest file first? treat it as a playlist and go by filename, just like mplayer * would do
[21:28] <Compn> ffmpeg needs playlist support...
[21:28] <Daemon404> no it doesnt
[21:28] <Daemon404> out of scope
[21:28] <Daemon404> ffmpeg is not a player.
[21:29] <Compn> mencoder isnt a player either, and yet, it has playlist support
[21:29] <Compn> your arguments are silly
[21:30] <Compn> playlists are just another file format to support
[21:34] <Daemon404> mencoder has tons of crap
[21:35] <microchip_> mencoder ftw!
[21:36] Action: Daemon404 hates mencoder
[21:36] <Compn> nevcairiel : does lav filters do rar ?
[21:36] Action: microchip_ loves it
[21:36] <Daemon404> the only thing it was ever useful for was teaching me how to use ffmpeg's cli
[21:36] <Daemon404> back when ffmpeg's cli wasnt documented
[21:36] <Daemon404> (moreso)
[21:36] <nevcairiel> Compn: no
[21:38] <Daemon404> does vlc have a devel channel?
[21:38] <Daemon404> or just #videolan?
[21:39] <Compn> i thought there was one
[21:39] <Compn> maybe not
[21:40] <Compn> you just want to talk about me behind my back :P
[21:40] <Daemon404> yeah that Compn guy
[21:40] <Daemon404> whats his problem?
[21:40] <Compn> hes such a jerk
[21:44] <Daemon404> oh... no wonder vlc-devel is so dead
[21:44] <Daemon404> people just push stuff with no review
[21:45] <ubitux> does anyone know if Jan Ekström is on IRC and if he plans to fix the memory leak in the utvideoenc?
[21:45] <Daemon404> it's JEEB
[21:45] <Daemon404> and which memleak
[21:45] <ubitux> http://fate.ffmpeg.org/report.cgi?time=20120822182605&slot=x86_64-archlinux-gcc-valgrindundef
[21:46] <Daemon404> a bunch of utvideo stuff just got pushed
[21:46] <Daemon404> including memstuff
[21:46] <Daemon404> wait and see?
[21:46] <ubitux> ok :)
[21:51] <j-b> Daemon404: usually, they do
[21:51] <Daemon404> im not used to it :P
[21:51] <Daemon404> is all.
[21:55] <Daemon404> humm
[21:55] <Daemon404> is paul b mahol sitll around
[21:55] <Daemon404> he's teh EXR guy isnt he?
[21:55] <ubitux> durandal... it's been a while i didn't see him
[21:56] <Daemon404> [exr @ 0x1560a60] error during zlib decompression
[21:56] <Daemon404> on big buck bunny's production EXRs
[21:56] Action: Compn still hasnt seen big buck bunny
[21:56] <Compn> i feel bad
[21:56] <Compn> because i like animation too
[21:56] <ubitux> he left on Aug 09 2012
[21:57] <Daemon404> im trying to render BBB @ super-hd res
[21:57] <Daemon404> biggest they offer is 1080p
[21:57] <Compn> you want 4096x4096? 
[21:57] <Compn> 4k
[21:57] <Compn> or whatever it is
[21:57] <Daemon404> nah
[21:57] <Daemon404> 1440p
[21:57] <gnafu> Sintel has 4K renders available.
[21:58] Action: gnafu is looking forward to Tears of Steel.
[21:58] <Daemon404> gnafu, sintel is the otehr foss movie?
[21:58] <gnafu> It's the one that followed BBB, yes.
[21:58] <Daemon404> ah.
[21:58] <gnafu> https://media.xiph.org/
[21:58] <Daemon404> works for me
[21:59] <gnafu> 94GB PNGs, or 483GB 16-bit TIFFs.
[21:59] <gnafu> Wait, that's 16-bit PNGs.  16-bit TIFFs are 632GB.
[22:01] <JEEB> ubitux, btw I did notice that on libav side as well, but to be honest I can't read of it where I'm leaking memory
[22:01] <ubitux> maybe a missing av_opt_free() or something
[22:02] <ubitux> mmh doesn't look there is any option in it
[22:02] <Daemon404> gnafu, annoying that i have to garb eahc png sep
[22:02] <Daemon404> no archive
[22:05] <ubitux> seems there is no more leak actually
[22:05] <ubitux> at least i'm not able to reproduce locally
[22:06] <JEEB> so michaelni fixed it? I was actually surprised by the interest it got from him.
[22:06] <gnafu> Daemon404: Too true.
[22:06] <gnafu> Write a script!
[22:07] <ubitux> mmh it's strange
[22:07] <Compn> you people and your fad-anime codecs
[22:07] <Compn> ehe
[22:08] <JEEB> I dunno, I see it being used by random people on doom9
[22:08] <JEEB> and it has plugins for both QT and VFW/DS
[22:11] <Daemon404> gnafu, done a few mins ago
[22:12] <Daemon404> JEEB, i think he pokes any new codec
[22:12] <Daemon404> he did stuff to VBLE too
[22:12] <Daemon404> and zerocodec
[22:12] <Daemon404> iirc
[22:14] <ubitux> ok it's not fixed, my bad
[22:15] <Daemon404> ok
[22:15] <Daemon404> JEEB, you or i can fix it
[22:15] <Daemon404> up to you.
[22:15] <JEEB> do you know where it happens?
[22:15] <Daemon404> valgrind can tell me
[22:15] <JEEB> I wish I could run valgrind here
[22:16] <Daemon404> the info from valgrind on fate is useless
[22:16] <JEEB> more or less, yeah
[22:16] <JEEB> anyways, if you could get a valgrind log I'd be grateful
[22:16] <ubitux> looks like it's the -f avi
[22:16] <Daemon404> ubitux, how?
[22:16] <Daemon404> i dont see how its related to utv
[22:17] <ubitux> the test uses -f avi and then -f framemd5
[22:17] <ubitux> so it guess it overrides the previous
[22:17] <Daemon404> ubitux, sounds like an avi muxer leak
[22:17] <ubitux> no
[22:17] <Daemon404> or ...why is it using avi at all
[22:17] <JEEB> your v410 test was using -f avi so I copied that, and the -f avi got left there after the switch to framemd5 OTL
[22:18] <Daemon404> o
[22:18] <Daemon404> send patches
[22:18] <ubitux> removing the -f avi should fix the problem
[22:18] <JEEB> k
[22:18] <ubitux> but the thing is, it might be interesting to avoid the leak as well in this case
[22:18] <Daemon404> ofc, but its beyond the scope of jeeb
[22:19] <Daemon404> and what hes working on
[22:19] <Daemon404> :P
[22:19] <ubitux> removing -f avi isn't :)
[22:19] <Daemon404> yes
[22:19] <Daemon404> i tried zzuffing + running my cllc decoder under valgrind, but but valgridn kills itself because of GET_VLC
[22:21] <ubitux> JEEB: you'll send a patch or i do it?
[22:21] <JEEB> I just did the change, and am sending a patch to libav, as I'm not yet registered on the ffmpeg ML IIRC. 'make fate-utvideoenc' just decided to recompile a lot of stuff after a rebase so I'll only be sending it after that finishes
[22:22] <ubitux> ok
[22:30] <ubitux> hehe yet another blur filter
[22:30] <ubitux> btw, is there any reason to prefer smartblur over boxblur?
[22:31] <Daemon404> different blurs look different
[22:31] <Daemon404> why do you think after effects has like 10 types
[22:31] <ubitux> is there that much usage of blur filters?
[22:31] <Daemon404> in video editing?
[22:32] <ubitux> i mean, i can see the point of sharpen filters, but blur... looks like a kind of very specific usage
[22:32] <Daemon404> a metric shitload.
[22:41] <CIA-56> FFmpeg: 03Derek Buitenhuis 07master * r081a822 10/ (3 files in 2 dirs): FATE: Add Canopus Lossless tests - http://git.io/JLJQLQ
[22:51] <gnafu> You have to soften the actress's skin while keeping her hair and clothes sharp for the OMGHD effect.
[22:53] Action: ubitux just bisected the lavf-ogg memleak regression, and it comes from 429c6cab1cb13b0e9eab101e290a4ad23d20c976
[22:53] Action: ubitux sent an email.
[22:53] <ubitux> gnafu: mmh ok
[22:59] <gnafu> Can't have any pimple or visible pores on your perfect starlet.
[23:01] <ubitux> ok now the last valgrind complain is the vc1 test
[23:25] <cbsrobot> ubitux: ping
[23:28] <ubitux> cbsrobot: pong
[23:28] <cbsrobot> you remember the tcmd patch you sent a while aho for the mov de/muxer ?
[23:28] <ubitux> yes?
[23:29] <ubitux> it's upstream since a while now
[23:29] <cbsrobot> in the demuxer you write the drop frame falg into  st->codec->flags2
[23:30] <cbsrobot> I cant seem to get it back in the movenc muxer
[23:30] <cbsrobot> this should be possible - no ?
[23:31] <ubitux> well it should be available in s->streams[i]->codec->flags2, with i the tmcd track
[23:31] <cbsrobot> hmmm - it's not there ...
[23:31] <ubitux> but btw, the way the timecode is handled in the mov muxer is kind of special
[23:32] <cbsrobot> strange
[23:32] <ubitux> you're trying to support data codec copy?
[23:32] <cbsrobot> sort of
[23:32] <ubitux> 'cause muxing a new tmcd track is supported
[23:33] <ubitux> and you'll likely need to drop the timecode metadata first
[23:33] <cbsrobot> I'm looking at http://ffmpeg.org/trac/ffmpeg/ticket/236
[23:34] <cbsrobot> actually I thought this ticket could be closed, but there are some issues
[23:34] <nevcairiel> speaking about tmcd, the demuxing of that thing broke demuxing of any other tref atoms, like the chap atom
[23:34] <ubitux> oh this is still reproducible?
[23:34] <cbsrobot> I can copy the tmcd with:
[23:34] <ubitux> nevcairiel: ah really? :(
[23:34] <ubitux> nevcairiel: is there a ticket for this?
[23:35] <cbsrobot> ffmpeg_g -i fcp_export8.mov -c copy -map 0:0 -map 0:1 -map 0:2 -map 0:3 -map 0:4 -y fcp_export9.mov
[23:35] <cbsrobot> but when I open the file in quicktime the timecode is messed up
[23:35] <nevcairiel> ubitux: probably not, but i have a patch that might fix it, at least it fixes the chap atom, but i have no way to test if tmcd still works :)
[23:35] <nevcairiel> i should send it
[23:35] <ubitux> the timecode is kind of tested by fate
[23:36] <ubitux> cbsrobot: it's not copied properly?
[23:36] <cbsrobot> no not entierly
[23:36] <cbsrobot> there are several issues
[23:37] <ubitux> did you check if creating a new timecode track fixes the issue?
[23:37] <ubitux> (just remove the map of the track)
[23:37] <cbsrobot> not yet
[23:38] <cbsrobot> 1. the tmcd atom in the source file is only 22 bytes long, in the destination its 24 bytes - but I don't think this causes an issue and according to the specs it should be 24
[23:39] <cbsrobot> 2. the frameduration and nb_of_frames differ
[23:40] <cbsrobot> 3. the drop_frame flag is not present
[23:40] <cbsrobot> and last point, but this is not related, the first stream has multile tref tags, but this is not yet implemented
[23:41] <cbsrobot> *multiple
[00:00] --- Thu Aug 23 2012