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

[burek]

[00:01] <cehoyos> Correction: I did not even find it for 8bit...
[00:02] <cehoyos> planarRgbToRgbWrapper(), found it
[00:05] Action: durandal11707 awww
[00:07] <durandal11707> wtf, apetags to aac
[00:08] <ubitux> :D
[00:28] <cone-800> ffmpeg.git 03Paul B Mahol 07master:0e84ba747efa: tta: return meaningful error codrs
[00:31] <Daemon404> codrs eh
[00:31] <Daemon404> thats a hip and with-it name
[00:31] <Daemon404> like solr, or tumblr
[00:36] <ubitux> grrr
[01:05] <cone-800> ffmpeg.git 03Paul B Mahol 07master:55121f3fa929: tta: add support for reading ape tags
[01:26] <kierank> is there a way of getting ffmpeg to force cfr encoding?
[01:26] <kierank> for blu-ray
[01:26] <durandal11707> encoding of what?
[01:26] <kierank> h264. so the timestamps are cfr?
[01:27] <kierank> i could of course write a dodgy patch but is there a proper way
[01:33] <durandal11707> -vsync cfr ?
[01:42] <cehoyos> michaelni: I wrote the unscaled special converter for GBR16 -> RGB48/64 but I realize now that some scaling of the values is necessary for 9bit / 10bit / 12bit / 14bit, does this mean a shift and or for each assignment in the for loop or is there an alternative?
[01:42] <cehoyos> a simple alternative?
[01:45] <durandal11707> gbrp 9-15 bits to rgb48/64 is just shifting
[01:46] <michaelni> durandal11707, white wont be white if you just shift
[01:47] <durandal11707> if its not linear, than what is it?
[01:47] <michaelni> cehoyos, if the user wants rgb48 then some shift or rescale will be needed
[01:48] <durandal11707> the dpx code for 9/10 .. to rgb48 did shifting iirc
[01:48] <Skyler_> durandal11707: (255 << 8) != 65535 (for example)
[01:51] <durandal11707> actually only 10bit one did some sort of scaling
[02:00] <iive> the usual workaround is to repeat the bits you shifted. e.g. 0xAA<<8 -> 0xAA0 +0xA.A so you get = 0xAAA
[02:01] <iive> or 0x5a<<8 -> 0x5a5a
[02:01] <iive> (ops first line example should be <<4)
[02:02] <iive> alternatively, you may just mask the old bits. e.g. 0x5a<<4 -> 0x5aa
[02:03] <iive> instead of 0x5a<<4 -> 0x5a5
[02:07] <cehoyos> It works now for the one case in the ticket, I will try to complete it tomorrow. gn
[02:08] <cone-800> ffmpeg.git 03Paul B Mahol 07master:d19d679e4b58: lavf/aacdec: add support for reading ape tags
[02:15] <cehoyos> michaelni: I pushed the ffplay patch to github, we could wait it is tested in ticket 2630
[02:15] <cehoyos> .. until
[02:44] <cone-800> ffmpeg.git 03Michael Niedermayer 07master:fca435fee167: vc1dec: Disable dead code
[04:07] <michaelni> do we have a volunteer with a amd cpu for setting up a fate client?
[04:19] <michaelni> my duron is pretty much dead, if noone volunteers i will have to completely reinstall it
[04:20] <michaelni> i think it would be better if i would spend my time writing code than reinstalling linux on a "new" disk
[04:28] <michaelni> "pretty much dead" == it rebooted runned fsck which failed and a manual fsck -y had uncountable numbers of errors, smart said on the next boot the disk is expected to fail within 24h or something and my attempt to copy anything of it ended with scp and tar not working anymore
[04:38] <ulatekh> Ouch...my condolences.  Recently I backed up the system/home partitions of my two main computers, onto an external USB hard drive.
[04:39] <michaelni> theres nothing important on the box that i dont have a backup of
[04:39] <ulatekh> Good man. :-)
[04:40] <michaelni> iam just trying to find some volunteer to take over maintaining a amd fate client
[04:41] <michaelni> as the one we had is dead and i would prefer if i dont have to reinstall & maintain it
[04:42] <ulatekh> Right now, my volunteer time is being spent building MinGW dependencies for Mixxx, an open-source DJing program.  I'm currently submitting several dozen packages to Fedora.
[04:42] <ulatekh> I'm like a rash on the open-source world ;-)
[04:43] <Compn> michaelni : ask on list
[04:43] <Compn> about amd fate
[04:44] <michaelni> Compn, yes, i guess ill do that
[04:44] <ulatekh> A development branch of Mixxx that uses ffmpeg to enable several more sound formats is imminent...the MinGW version of ffmpeg will involve another couple of dozen dependencies.  But ffmpeg compiled for MinGW with little trouble, and seems to run fine, so thanks to all for that!
[04:47] <drv> i have an old athlon64 i could probably revive, needs a new power supply though
[04:47] <ulatekh> I have a question about how av_clipl_int32_c() (in ffmpeg/libavutil/common.h) calls UINT64_C(), which doesn't work in current g++ unless __STDC_CONSTANT_MACROS is defined, and whether that's an ffmpeg bug, or if the client should be defining this every time an ffmpeg header file is included.  Is that a question for here or for #ffmpeg?
[04:47] <Compn> i'm running too many computers now. need to conserve energy :P
[04:51] <Plorkyeran> ulatekh: ffmpeg headers don't do anything to ease inclusion in C++
[04:51] <Plorkyeran> so you need to define __STDC_CONSTANT_MACROS and wrap them with extern "C"
[04:51] <ulatekh> OK, so this is expected to be something the client deals with, then.
[04:54] <michaelni> drv, that sounds interresting, i would have to find something else for 32bit valgrind then though but running valgrind on the old amd was never a very bright idea so that shouldnt be a problem
[05:01] <drv> actually looks like i have an old psu that still works, just need a disk and an OS now, rummaging... :)
[05:01] <drv> what tests was the old one running, 64-bit amd?
[05:06] <michaelni> the entries that say duron on http://fate.ffmpeg.org/ should list what was tested
[05:08] <michaelni> they where all 32bit but 64bit amd should be able to run 32 &64bit
[05:08] <michaelni> just 32bit valgrind didnt work on 64bit x86 last i tried
[05:19] Action: michaelni realizes its already 5 in the morning
[05:20] Action: michaelni falls asleep
[08:54] <damir__> hello
[12:55] <durandal_1707> michaelni: so fate test fails, or just dts is wrong?
[12:58] <durandal_1707> because first patch changes dts thing - looked at video thing, and it may not be correct at all, as i do not see any logic behind it....
[13:04] <durandal_1707> actually, there is yet another && :)
[13:07] <michaelni> durandal_1707, fate passed, just the command line given failed
[13:12] <ubitux> is this patchset going to add 100M of output to the helgrind & drd boxes? :))
[13:12] <durandal_1707> we will find out
[13:13] <durandal_1707> how much is current one big?
[13:14] <ubitux> alot©
[13:14] <ubitux> 820M
[13:14] <ubitux> and 809M
[13:14] <durandal_1707> so it grows exponentialy?
[13:15] <ubitux> well, everytime something get threaded & covered by fate, i guess it grows a little 
[13:20] <durandal_1707> michaelni: i fixed && nonsense, could you try again your tests that are not in fate, but should be?
[13:30] <cone-264> ffmpeg.git 03Michael Niedermayer 07master:2192f89368d8: ffserver: fix null pointer dereference
[13:35] <michaelni> durandal_1707, the alac thing still seems happening
[13:37] <durandal_1707> it does not happen with flac in same container?
[13:38] <michaelni> i just tried some random files, i dont know if a flac in mkv was amongth them
[13:39] <durandal_1707> well, reencode to flac & alac, and try again?
[13:39] <durandal_1707> i can't reproduce it here
[13:41] <michaelni> i see no difference in framecrc with flac in mkv
[13:42] <durandal_1707> and with reencoded alac in mkv?
[13:42] <durandal_1707> the one possible reason why it happens is because dts in not set anymore for mt case
[13:43] <michaelni> cant see a difference either in framecrc output
[13:46] <durandal_1707> michaelni: you actually tested output_sample_bits in libswresample?
[13:52] <michaelni> durandal_1707, i dont remember but i would assume i did test it
[13:52] <michaelni> if theres a problem with it please open a ticket
[13:53] <durandal_1707> better, i will fix it
[14:00] <durandal_1707> michaelni: patch on ml
[14:01] <cone-264> ffmpeg.git 03Lukasz Marek 07master:7faafe606fb2: ftp: fix using uninitialized value
[14:01] <cone-264> ffmpeg.git 03Michael Niedermayer 07master:372e00793fe8: Merge remote-tracking branch 'lukaszmluki/master'
[14:09] <durandal_1707> michaelni: how i test this dither thing? i tried: -output_sample_bits 6 -dither_method triangular, and got same file
[14:13] <durandal_1707> i get assertion: Assertion 0 failed at libswresample/rematrix.c:370
[14:13] <durandal_1707> when doing s32 -> s32 : ffmpeg -i /tmp/o2.mka -af aresample=output_sample_bits=6:dither_method=triangular -acodec pcm_s32le /tmp/o.mka
[14:17] <michaelni> line 360 is s->native_matrix = av_calloc(nb_in * nb_out, sizeof(double));
[14:18] <durandal_1707> i said 370
[14:18] <durandal_1707> rematrix_init does not handle s32 at all
[14:20] <michaelni> it should use float or double in that case not assert
[14:20] <durandal_1707> but dithering is done in s32 case only
[14:21] <durandal_1707> anyway assert should not happen
[14:21] <michaelni> rematrix isnt dithering
[14:21] <durandal_1707> then why its called at all
[14:23] <michaelni> how would i know why its called in a testcase that i dont have ?
[14:23] <durandal_1707> i given you testcase
[14:23] <durandal_1707> encoder pcm_s32le into mka
[14:23] <durandal_1707> and run command i mentioned
[14:23] <michaelni> encoder pcm_s32le into mka ?
[14:24] <michaelni> sorry but ENOTIME
[14:24] <michaelni> i need a working command line and a input file
[14:24] <michaelni> no guessing 
[14:25] <durandal_1707> ffmpeg -f lavfi -i aevalsrc=0 -af aformat=s32,aresample=dither_method=triangular,aformat=s32 -f null -
[14:25] <michaelni> ok, reproduced
[14:36] <durandal_1707> michaelni: i don't see how alac-in-matroska.mka can be fixed, it looks like bad encoding, and similar could happen with video too
[14:37] <nevcairiel> if it works single threaded, something must be up
[14:37] <durandal_1707> its just guessing pts
[14:45] <durandal_1707> and same could happen with video
[14:58] <durandal_1707> if i want to memove almost whole file data from few bytes from start to next few kbs, what is best method? (i dislike use of temp file)
[15:12] <cone-264> ffmpeg.git 03Michael Niedermayer 07master:f3c638eac1e3: wresample/rematrix_template: fix internal types
[15:12] <cone-264> ffmpeg.git 03Michael Niedermayer 07master:b84de51f548a: swresample/rematrix: add S32 mixing code
[15:58] <durandal_1707> michaelni: so what should be done with this pts/dts issue? I don't think because of it one drops all of it.
[16:03] <durandal_1707> if i want to add new crc table to lavu/crc.h, what should i do?
[16:04] <durandal_1707> add AV_CRC_XXX = 666, and dont care for big hole?
[16:08] <michaelni> the crc table isnt public so a large ID doesnt neccessarily need a large hole but = 66 or so would work as well
[16:08] <michaelni> about pts/dts decoders should return the same timestamps independant of the number of threads
[16:10] <durandal_1707> michaelni: its not decoder thing to return pts/dts
[17:53] <durandal_1707> michaelni: so where is place to fix this pts issue? Everything points that same issue should be present for video decoders.
[19:20] <michaelni> durandal_1707, i didnt had time to look into it but decoders should return the same data independant of the number of threads
[19:21] <michaelni> the number of threads can differ between different computers as its automatically choosen based on cpu count
[19:21] <michaelni> it would be bad if timestamps differed randomly depending on how many cpu cores one has
[19:22] <durandal11707> same issue is with video streams
[19:22] <durandal11707> just because you did not waste time on finding such file does not mean there is no same bug
[19:23] <durandal11707> anyway i'm not asking is there is bug or not...
[19:27] <cone-566> ffmpeg.git 03Paul B Mahol 07master:f5d5bc3493c4: tak: simplify ff_tak_check_crc()
[19:29] <durandal_1707> instead i'm looking for solution
[19:45] <michaelni> durandal_1707, why do the timestamps depend on the thread count ?
[19:46] <michaelni> (i didnt yet have time to look at the issue)
[19:46] <durandal_1707> i dunno
[19:46] <durandal_1707> perhaps there are no timestamps, and using threads breaks "guessing/recreation"
[19:46] <durandal_1707> -c copy -f framemd5 shows funny things
[19:49] <cehoyos> michaelni: Please merge the ffplay patch from github, it appears nobody is going to test
[19:59] <cone-566> ffmpeg.git 03Carl Eugen Hoyos 07master:3b491c5a5002: Use av_log() instead of fprintf() in ffplay.
[20:10] <j-b> good morning
[20:13] <ubitux> 20:07:18 < kierank> seems to be a free copy now of the ts spec: http://www.itu.int/rec/T-REC-H.222.0-201206-I/en
[20:13] <ubitux> might interest some ppl here ^
[20:15] <ubitux> it would be nice if ppl were interested in at least :p
[20:19] <michaelni> ubitux, nice, i think this is newer than what i had
[20:40] <cone-566> ffmpeg.git 03Michael Niedermayer 07master:3b58ab4c5fdc: pngdec: dont treat mpng like png with key and non keyframes
[21:25] <funman> hello
[21:27] <Daemon404> michaelni, has anything changed in the wya lavf handles muxing and setting the timebase lately?
[21:27] <Daemon404> code that used to work is how busted
[21:27] <Daemon404> setting some inssane timebase
[21:29] <durandal_1707> since when?
[22:06] <Daemon404> durandal_1707, i dont know
[22:06] <Daemon404> i havent run a bisect... but "last few months"
[22:07] <Daemon404> time_base=1/95904
[22:07] <Daemon404> originally:
[22:07] <Daemon404> 1/5994
[22:08] <durandal_1707> mkv?
[22:08] <Daemon404> nut
[22:08] <Daemon404> <_<
[22:10] <durandal_1707> for newly created files or old ones?
[22:12] <durandal_1707> i don't see anything obvious
[22:13] <michaelni> Daemon404, what is the problem with a "finer" timebase ?
[22:14] <michaelni> it does allow more accurate specification of timestamps
[22:16] <Daemon404> michaelni, im calling libavformat manually
[22:16] <Daemon404> with tah tspeiic timebas
[22:16] <Daemon404> it should NOT change it
[22:16] <Daemon404> because i am ALSO setting teh pts
[22:16] <Daemon404> silently changing the timebase when i specify one in lavf's muxing api is ... bad is an understatement.
[22:19] <michaelni> AVStream.time_base isnt settable by the user, and never was
[22:19] <Daemon404>     stream->codec->time_base.den = tb->Den;
[22:19] <Daemon404>     stream->codec->time_base.num = tb->Num / 1000;
[22:19] <Daemon404> ^ this worked 8 months ago
[22:20] <nevcairiel> you can set codec timebase, but the muxer is not guaranteed to use it for stream timebase
[22:20] <nevcairiel> its even documented
[22:20] <nevcairiel> well, indirectly :)
[22:20] <michaelni> also mpeg-ps/ts for example will use 90khz tb
[22:21] <michaelni> Daemon404,  off topic but the /1000 looks wrong
[22:21] <Daemon404> it is correct
[22:21] <Daemon404> its from ffms2
[22:21] <Daemon404> which needs it
[22:21] <Daemon404> (their precision is higher from haali's demuxer e.g.)
[22:21] <Daemon404> but not relevant in this case
[22:22] <Daemon404> so basically what youre telling me
[22:22] <Daemon404> is that if i just want to PASS THROUGH pts
[22:22] <Daemon404> i have to regenerate/compensate the pts
[22:22] <Daemon404> manually
[22:22] <Daemon404> gee that sounds fun
[22:22] <nevcairiel> its one rescale to stream timebase, doesnt sound that terrible
[22:22] <nevcairiel> one function call
[22:24] <michaelni> Daemon404, we could probably quite easily support forcing the muxer timebase if people want that (for the muxers that support arbitrary timebases)
[22:24] <Daemon404> btw
[22:24] <Daemon404>  1264     /**
[22:24] <Daemon404>  1265      * This is the fundamental unit of time (in seconds) in terms
[22:24] <Daemon404>  1266      * of which frame timestamps are represented. For fixed-fps content,
[22:24] <Daemon404>  1267      * timebase should be 1/framerate and timestamp increments should be
[22:24] <Daemon404>  1268      * identically 1.
[22:24] <Daemon404>  1269      * - encoding: MUST be set by user.
[22:24] <Daemon404>  1270      * - decoding: Set by libavcodec.
[22:24] <Daemon404>  1271      */
[22:24] <Daemon404> this is misleading as HELL
[22:24] <Daemon404> if this is true
[22:25] <Daemon404> as in it can be downright wrong
[22:25] <Daemon404> especially the last part.
[22:29] <Daemon404> i guess the next questions are:
[22:29] <Daemon404> 1) shall i update the incorrect documentation?
[22:29] <Daemon404> 2) at which point can I rescale? is this documented?
[22:29] <Daemon404> 3) ???
[22:29] <Daemon404> 4) profit
[22:42] <Daemon404> i see... so i need to set a timebase, start encoding/muxing, and then rescale the pts based on the new timebase
[22:42] <Daemon404> fun times.
[22:43] <Daemon404> ........
[22:44] <durandal_1707> so, previously timebase was not overwriten?
[22:44] <Daemon404> in the past, the timebase i set was used
[22:45] <durandal_1707> well, there should be at least option to keep timebase.....
[22:46] <Daemon404> -        pkt.pts           = curframeinfo->PTS;
[22:46] <Daemon404> -        pkt.dts           = curframeinfo->PTS;
[22:46] <Daemon404> +        pkt.pts           = av_rescale_q(curframeinfo->PTS, stream->codec->time_base, stream->time_base);
[22:46] <Daemon404> +        pkt.dts           = av_rescale_q(curframeinfo->PTS, stream->codec->time_base, stream->time_base);
[22:46] <Daemon404> ^ fix
[22:54] <durandal_1707> so skip_put_bits() overwrites bits?
[23:04] <durandal_1707> michaelni: i still can't find case where dithering actually does something
[23:44] <cone-566> ffmpeg.git 03Paul B Mahol 07master:e3e398b80be4: doc/general: update after e4e4add0e3ba7
[23:48] <durandal_1707> michaelni: how to test dither and output_sample_bits? why is there no fate test?
[23:51] <cone-566> ffmpeg.git 03Michael Niedermayer 07master:4cfc92081dfe: swr: add native_simd_one
[23:51] <cone-566> ffmpeg.git 03Michael Niedermayer 07master:495bf1b68574: swr: Fix dithering of s16 with SIMD
[23:52] <michaelni> durandal_1707, after my last 2 commits this:
[23:53] <michaelni> ./ffmpeg -i matrixbench_mpeg2.mpg -af aresample=dither_method=triangular:dither_scale=X -acodec pcm_u8 test.wav
[23:53] <michaelni> works
[00:00] --- Wed Jun  5 2013