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

[burek]

[00:04] <cehoyos> michaelni: Did you just fix ticket 1874 ? Or is this unrelated to 16bit dithering?
[00:04] <durandal_1707> what magic number dither_scale is?
[00:04] <durandal_1707> output_sample_bits does nothing all the time
[00:06] <cone-566> ffmpeg.git 03Paul B Mahol 07master:080417110405: swresample: set flags & description and add documentation for output_sample_bits
[00:08] <cone-566> ffmpeg.git 03Stefano Sabatini 07master:841df7bf865c: lavfi: port sab filter from libmpcodecs
[00:08] <cone-566> ffmpeg.git 03Stefano Sabatini 07master:449558d34a24: lavfi/mp: remove mp=sab
[00:09] <durandal_1707> oh noes, i need to reconfigure yet again...
[00:10] <michaelni> cehoyos, 1874 ? theres no match for dither in that
[00:11] <durandal_1707> saste: why you did not added mcdeing and sab into Changelog?
[00:12] <saste> durandal_1707,  don't want to spam the changelog
[00:12] <cehoyos> michaelni: Then sorry for the noise (I was able to reproduce the bug, I don't really understand it)
[00:13] <cehoyos> saste: mcdeint is certainly worth a Changelog entry (I don't know about sab)
[00:14] <ubitux> please add both in the Changelog :)
[00:14] <durandal_1707> but its already bloated
[00:14] <ubitux> it's bloated with awesomeness
[00:15] <ubitux> one solution would be to make a release
[00:15] <ubitux> not sure if the current state would allow that
[00:15] <saste> 2.0 -> tagged "MCDeint"
[00:15] <durandal_1707> what's wrong with current state?
[00:16] <ubitux> durandal_1707: dunno, it would be interesting to make a review of the current regressions before the release
[00:16] <durandal_1707> nope, next release is 1.3.0
[00:16] <ubitux> cehoyos might know more about it
[00:16] <ubitux> saste: haha
[00:16] <ubitux> saste: still didn't overcome the traumatism of porting it?
[00:17] <saste> ubitux, no mcdeint was smooth and nice
[00:17] <saste> sab was indeed boring
[00:17] <saste> tinterlace was unexpectedly painfull
[00:17] <ubitux> 00:33 <@saste> mcdeint is a bitch
[00:17] <ubitux> don't lie to me
[00:18] <durandal_1707> with only one user
[00:18] <ubitux> we'll drop it from the code base discretly when microchip_ will timeout
[00:19] <durandal_1707> 2.0 is when libmpcodecs is no more in lavfi
[00:21] <durandal_1707> and XX.0.0 if scrip filter in lavfi comes
[00:21] <durandal_1707> *script
[00:22] <durandal_1707> saste: you started to write some lua, do you?
[00:23] <ubitux> (anyone to add a AV_OPT_TYPE_BOOL?)
[00:23] <saste> durandal: will take a long time
[00:23] <durandal_1707> ubitux: how would that even work?
[00:25] <ubitux> durandal_1707: foobar={yes,true,1,y} vs foobar={no,false,0,n}
[00:25] <ubitux> i guess.
[00:26] <durandal_1707> cehoyos: what happened with your swscale excursion?
[00:27] <cehoyos> It is working for GBRPx and RGBx48/64 but not for GBRAP
[00:28] <cehoyos> It needed four switches for NE-NE, NNE-NE, NE-NNE and NNE-NNE
[00:28] <cehoyos> (native endia, non native endian)
[00:29] <cehoyos> I wonder atm if I should skip GBRAP for the moment or if I should implement it in the same function.
[00:29] <durandal_1707> use MACROS
[00:30] <cehoyos> And I think I found a bug (missing feature) in the isByteRGB() macro
[00:30] <ubitux> http://trac.ffmpeg.org/query?status=!closed&keywords=~mpegts :(
[00:31] <durandal_1707> cehoyos: well, its bad name for 32bits rgb formats only, you dont need it, you can add new one
[00:33] <cehoyos> I agree that the name is not optimal but would be neither a bug nor a missing feature.
[00:37] <durandal_1707> anyone gonna push that twolame patch?
[00:48] <durandal_1707> michaelni: dithering seems to be used only with flt/dbl ->int case
[00:48] <durandal_1707> but not for 32bit to 24 bit case
[00:51] <durandal_1707> also about mt patch, i'm not aware of any way how to fix that dts errors for broken files, and blocking patchset just because of that is sad
[01:34] <cehoyos> ubitux: I missed a line from you before, yes there are a few regressions imo that we should try to fix
[01:54] <michaelni> "<durandal_1707> also about mt patch, i'm not aware of any way how to fix that dts errors for broken files, and blocking patchset just because of that is sad"
[01:54] <michaelni> notthing is blocked
[01:54] <michaelni> you asked me to review it, i did
[01:54] <michaelni> you asked me to test it, i did
[01:55] <ubitux> he's away
[01:55] <michaelni> when i find time i will debug your code but ATM i dont know why it fails 
[01:55] <michaelni> ubitux, i know but AFAIK he reads the log
[01:55] <ubitux> ah, okay
[01:55] <michaelni> when hes not here
[03:02] <Compn> michaelni : is anyone reviewing the mips patches ? or testing benchmarks on float cpu ?
[03:02] <Compn> or is it on your todo? :)
[03:02] <Compn> just curious
[03:07] <michaelni> Compn, if someone wants to review them, thats very welcome, if noone does ill look into them eventually of course
[03:11] <cone-610> ffmpeg.git 03Michael Niedermayer 07master:6bc4e36ba7c4: swr: set scale for 32->32/24 dither
[03:11] <cone-610> ffmpeg.git 03Michael Niedermayer 07master:328967014295: swr: dont treat 32 and 24 as equal in simple copy check
[05:20] <jcorso> I have a question about seeking; for the life of me, I cannot get my code to seek (forward or backward) with av_seek_frame or avformat_seek_file.  I have searched through the documentation and the web.  Any help?
[05:22] <jcorso> hello?
[05:32] <jcorso> Can someone tell me what the proper seeking API to use is now?
[10:19] <microchip_> ubitux: drop what? mcdeint?
[10:34] <cone-936> ffmpeg.git 03Timothy Gu 07master:ea038b996d56: doc/encoders: add documentation for libtwolame
[10:35] <microchip_> durandal_1707: if you go to doom9 forum and search for mcdeint, you'll see other people using it too. I'm not the only one :)
[10:35] <durandal_1707> same people that use mencoder @_@
[10:36] <microchip_> yeah well, now it's in ffmpeg too, i guess they can switch
[10:44] <durandal_1707> Daemon404: what happened with ffv2?
[10:45] <JEEB> last diff from like 2010 IIRC
[10:45] <JEEB> http://akuvian.org/src/x264/
[10:45] <JEEB> see files that begin with ffv2
[10:46] <durandal_1707> is it abandoned or what?
[10:47] <JEEB> IIRC more or less
[11:26] <cone-936> ffmpeg.git 03Martin Storsjö 07master:fc962d4e7a7c: mem: Add av_realloc_array and av_reallocp_array
[11:26] <cone-936> ffmpeg.git 03Andrey Semashev 07master:3b4feac1ec14: movenc: Keep track of the allocated size for the cluster array
[11:26] <cone-936> ffmpeg.git 03Michael Niedermayer 07master:30b491f1c99a: Merge commit '3b4feac1ec14f861bdd7f494f288f4d8dd7f449e'
[11:31] <cone-936> ffmpeg.git 03Andrey Semashev 07master:ab1189766a82: movenc: Increase the cluster array allocation by doubling
[11:31] <cone-936> ffmpeg.git 03Michael Niedermayer 07master:28ce9c0b73c5: Merge commit 'ab1189766a82a95f108005463cde75f73fcc0ae5'
[11:37] <cone-936> ffmpeg.git 03Andrey Semashev 07master:7c020e1ad37d: movenc: Grow the frag_info array in chunks
[11:37] <cone-936> ffmpeg.git 03Michael Niedermayer 07master:606e8baf0fec: Merge commit '7c020e1ad37d27c9d5db4d714401f09c80e3cc44'
[12:02] <cone-936> ffmpeg.git 03Luca Barbato 07master:9835abb6d63f: network: uniform ff_listen_bind and ff_listen_connect
[12:02] <cone-936> ffmpeg.git 03Michael Niedermayer 07master:82070b01b85f: Merge commit '9835abb6d63fb07613994ae90e72fef758149408'
[12:12] <cone-936> ffmpeg.git 03Anton Khirnov 07master:8b7dffc2d6c6: lavfi doxy: improve/extend AVFilter doxy.
[12:12] <cone-936> ffmpeg.git 03Michael Niedermayer 07master:2280b539c505: Merge commit '8b7dffc2d6c6c19f8e0a1fedcd0e95dce7a273ff'
[12:25] <cone-936> ffmpeg.git 03Anton Khirnov 07master:274e134e49b1: avconv: check that the output format context exists before accessing it
[12:25] <cone-936> ffmpeg.git 03Michael Niedermayer 07master:4abd5a431823: Merge commit '274e134e49b1c92db0f0b8cb2ae7554fb7b9184c'
[12:32] <ubitux> another vp8 threading failure :(
[12:39] <ubitux> what is motivating this B-frame QP usage in spp filter?
[12:39] <ubitux> i mean, why that special case?
[12:41] <cone-936> ffmpeg.git 03Anton Khirnov 07master:e816aaacd682: apetag: use int64_t for filesize
[12:41] <cone-936> ffmpeg.git 03Michael Niedermayer 07master:856e7dbb7251: Merge remote-tracking branch 'qatar/master'
[12:42] <durandal_1707> ubitux: "fun"
[12:45] <michaelni> ubitux, B frames often have a higher QP and if you filter based on QP this periodic change can lead to flicker
[12:46] <durandal_1707> what actually exports QP?
[12:46] <michaelni> decoder
[12:46] <durandal_1707> what decoder(s)?
[12:47] <ubitux> michaelni: but, in that case, why would you ever want to use those B-frames QP?
[12:47] <ubitux> in case some codecs do not have the higher QP specificity?
[12:48] <michaelni> durandal_1707, DCT based ones
[12:49] <michaelni> ubitux, i dont remember but i probably just thought "dunno whats better, let the user fugure it out"
[12:49] <ubitux> ok :)
[12:57] <durandal_1707> users never ever figures anything
[12:58] <iive> they do, but they never tell us.
[12:59] <durandal_1707> so anyone going to fix mpegts muxer/demuxer ?
[13:20] <ubitux> does anyone knows why the QP tables were deprecated from the AVFrame?
[13:20] <ubitux> (what are we supposed to use instead?)
[13:22] <ubitux> mmh ok we're just not supposed to edit & access them
[13:23] <ubitux> that's really too bad that much exported information is not available anymore
[13:28] <durandal_1707> i don't remmember it was deprecated by us
[13:29] <ubitux> yeah well it's a thing of the evil plan
[13:29] <ubitux> the mpeg2 fields went unexported
[13:30] <ubitux> qp, motion vect etc
[13:30] <ubitux> afaict
[13:41] <durandal_1707> what is in evil plan?
[13:41] <ubitux> well you don't remember?
[13:41] <ubitux> the avframe buf counting etc
[13:41] <ubitux> a few month ago
[13:42] <durandal_1707> i thought evil plan never ended...
[13:42] <ubitux> ??
[14:23] <Compn> lots of output with this file > http://web.archive.org/web/20071027002243/http://www.americaone.org/video/images/clip43qt3-hi.mov
[14:23] <Compn> [qcelp @ 011959a0]Frame #154, IFQ: bitrate cannot be determined.
[14:25] <durandal_1707> and it sounds fine or?
[14:27] <durandal_1707> could you also find any unsupported speech codecs that is in mp4/mov ?
[14:35] <Compn> durandal_1707 : hummmmm, need a list of speech codecs in mov first, then i can locate the samples
[14:36] <Compn> but no, the audio does not work with that file
[14:36] <Compn> i guess i should file a report
[14:36] <durandal_1707> any file with unsupported codec
[14:36] <Compn> oh, i can dig one up :)
[14:39] <Compn> http://samples.ffmpeg.org/V-codecs/601P/hopla-00.00.03.10-V300 is a unknown video codec file 
[14:39] <Compn> let me look for audio
[14:41] <durandal_1707> Compn: with what tag?
[14:41] <Compn> what ?
[14:42] <durandal_1707> what is reported as tag
[14:42] <Compn> in that hopla video is "601P"
[14:42] <Compn> which is "Media 100 transcoder"
[14:44] <Compn> [mov,mp4,m4a,3gp,3g2,mj2 @ 027f78a0] Could not find codec parameters for stream 0 (Video: none (601P
[14:44] <Compn> . / 0x50313036), 720x576, 38156 kb/s): unknown codec
[14:45] <durandal_1707> ok, ignore that one, i'm interested in speech codecs that are actually standardised
[14:45] <Compn> heh
[14:45] <Compn> ok
[14:45] <Compn> i'm sure theres some codecs , but off hand i cant remember any of them
[14:45] <Compn> someone just finished the evrc decoder 
[14:47] <Compn> theres amr-wb , were all of those finished ?
[14:47] <Compn> amr-nb and amr-wb
[14:47] <cone-936> ffmpeg.git 03Michael Niedermayer 07master:21bf0d6f8026: avformat/network: remove unused variable
[14:47] <cone-936> ffmpeg.git 03Michael Niedermayer 07master:fbc472da295e: avutil/mem: simplify av_reallocp_array() by using av_realloc_f()
[14:47] <cone-936> ffmpeg.git 03Michael Niedermayer 07master:16f3102f4103: avformat/img2dec: timestamps are 64bit
[14:49] <durandal_1707> evrc-b and similar variants and smv (selectable mode vocoder - tag ssmv) ones i'm looking for
[14:56] <Compn> it took me a long time to find evrc , not sure i'll find those. but ill do some searching
[14:57] <durandal_1707> i doubt you will find such files by searching by codec name
[15:37] <durandal_1707> Compn: smv can be found in qcp files
[15:38] <durandal_1707> hmm, someone hacking irc....
[16:37] <Compn> durandal_1707 : ok, searching for qcp now
[16:37] <Compn> mostly qcelp
[16:39] <JEEB> holy shi-, DivX released its first RFC for HEVC-in-Matroska and will longpost on the matroska-devel list soon as well
[16:39] <JEEB> the latter part is where I'm actually somewhat surprised, companies don't usually try to discuss things ^^;
[16:40] <JEEB> http://labs.divx.com/node/127907
[16:40] <JEEB> http://lists.matroska.org/pipermail/matroska-devel/2013-June/004483.html
[16:41] <Compn> durandal_1707 : here you go , but its in smv format http://www.schuppan.de/viktor/fsen09_scp_examples/
[16:42] <Compn> oops no thats not it
[16:42] Action: Compn cant read
[16:42] <Compn> ignore that
[16:46] <durandal_1707> Compn: actually its not in mp4/mov extension but in 3g2 one
[16:47] <durandal_1707> usually
[16:51] <Compn> durandal_1707 : ok, all qcp so far are qcelp for me
[16:51] <Compn> starting 3g2 search, seems to be qcelp as well
[16:54] <durandal_1707> well look if your mobile phone can record such files...
[17:01] <durandal_1707> shit i just tried playing one .3g2 and it was p0rn
[17:06] <Compn> durandal_1707 : try emailing amistuff about samples. he is very adept at finding/creating samples
[17:08] <Compn> my phone is old
[17:08] <Compn> runs android
[17:09] <durandal_1707> i think you need even older phone....
[17:10] <Compn> durandal_1707 : you can write news post on ffmpeg asking for samples
[17:10] <Compn> maybe one of our users has one
[17:10] <Compn> ffmpeg.org that is
[17:11] <durandal_1707> so all you found was qcelp?
[17:12] <Compn> i found one aac :P
[17:12] <Compn> but yes qcelp everywhere
[17:12] <Compn> doesnt 3gpp have a testsuite ?
[17:13] <durandal_1707> hmm, previously you found evrc in qcp iirc
[17:13] <Compn> and i said it was hard to find those :)
[17:14] <Compn> want me to write ffmpeg.org post looking for samples ?
[17:16] <durandal_1707> yes, looking for speech codecs samples that are not aac
[17:18] <durandal_1707> evrc-b, evrc-wb, smv (but looks like they are not used any more...)
[17:29] <Compn> durandal_1707 : you want only the non-working codecs , right ?
[17:29] <Compn> i mean, ffmpeg wont be able to play them
[17:30] <Compn> well i'll just rephrase it i guess
[17:38] <Compn> durandal_1707 : ok, posted :)
[17:40] <ubitux> Compn: there is no space before a comma in english
[17:41] <durandal_1707> did anything ever happened with such requests?
[18:39] <cone-936> ffmpeg.git 03Michael Niedermayer 07master:6e9bfc19bd7b: jpeg2000: check that nreslevels2decode has been initialized before use
[18:39] <cone-936> ffmpeg.git 03Michael Niedermayer 07master:66c4d5441314: jpeg2000dec: Propagate error code from get_cox() correctly
[18:39] <cone-936> ffmpeg.git 03Michael Niedermayer 07master:2c2a8f70f571: jpeg2000: Make nreslevel fields int
[18:45] <durandal_1707> is jpeg2000 decoder finally useful?
[19:28] <durandal11707> michaelni: what are you trying to prove?
[19:34] <durandal11707> the all remaining issues you spotted are unrealted and are already present
[19:37] <cone-936> ffmpeg.git 03Stefano Sabatini 07master:702c1bf240f2: Changelog: add missing entries about new mcdeint and sab filters
[19:50] <michaelni> durandal11707, you asked me to test the patches
[19:51] <michaelni> and i found bugs (which may or may not be the fault of the patches)
[19:52] <durandal11707> michaelni: not the way you did. like wasting all day trying to find that file which breaks, i could do that too. actually i was already aware of tta in mkv thing (last frame decode error)
[19:53] <durandal11707> and i looked again why that happens and could solve it, as its probably ffmpeg thing
[19:54] <durandal11707> decode_error_stat looks silly
[19:59] <michaelni> what kind of testing where you looking for then ?
[20:00] <durandal11707> that md5 of final decoding is same, which looks like it really is
[20:00] <durandal11707> but that's irrelevant now, do you know why error dissapears?
[20:01] <michaelni> no i didnt investigate
[20:05] <michaelni> durandal11707, btw, the audio (and video) decoder multithreading has one problem, it increases cpu load per file. Thus when its not needed for realtime playback it would drain the battery of a mobile device faster than with no threading
[20:06] <durandal11707> how is that rellevant?
[20:07] <michaelni> maybe 10% less battery life when listing to music
[20:07] <durandal11707> so?
[20:10] <michaelni> for audio the multithreading could be disabled for playback but enabled for transcoding of audio only files
[20:10] <durandal11707> also do you realise that ffmpeg returns no errors when decoding any video (with threads 1) and zzuf. there are bunhc of errors. but no red log
[20:11] <durandal11707> michaelni: your sudden fear about battery lifes is really strange
[20:12] <durandal11707> for video, who cares, but for audio, and lossless one its really important ....
[20:12] <michaelni> durandal11707, its a issue for video as well
[20:12] <michaelni> maybe more so
[20:13] <michaelni> but i dunno how to fix it for video ATM
[20:13] <michaelni> disabling multithreading for video for playback isnt an option
[20:13] <michaelni> but for audio it _might_ work
[20:14] <durandal11707> but for lossless audio is really irrelevant
[20:15] <durandal11707> and there seems to be no way to set different default threads value for audio decoding
[20:15] <michaelni> i was thinking of somthing like if(audio) threads =1 in ffplay.c
[20:15] <durandal11707> well, i could add audio_threads or similar
[20:16] <durandal11707> its just changing default behavior - auto should be 1
[20:16] <durandal11707> but some codecs like als and ape can not be decoded in real time on some cpus
[20:17] <durandal11707> exp als
[20:17] <michaelni> then my suggestion for audio doesnt work :(
[20:18] <nevcairiel> in my experience with als, multi-threading is not trivial anyway, because the demuxer doesnt give you singular frames, which is required for frame threading
[20:18] <ubitux> (can we enable threading for audio-only or video-only?)
[20:19] <michaelni> -threads:a 1
[20:19] <ubitux> ah, cool
[20:20] <durandal11707> nevcairiel: decoder gives subframes
[20:21] <durandal11707> and i dont see how that will not make it possible
[20:21] <nevcairiel> all i know is that the als demuxer used to give me large blocks and the decoder only consumed small parts of that every call
[20:22] <nevcairiel> which is not something frame threading can do
[20:22] <nevcairiel> you need to split it before decoding
[20:22] <nevcairiel> iow, it needs a parser
[20:25] <durandal11707> why?
[20:25] <nevcairiel> i just explained why
[20:26] <durandal11707> but decoders take packets
[20:26] <nevcairiel> the demuxer doesn't output singular frames
[20:26] <nevcairiel> yes, decoders take packets
[20:26] <nevcairiel> and decoders are also free to only use half of that packet
[20:26] <nevcairiel> which assumes you call the decoder again with the second half
[20:29] <durandal11707> which is little pointless
[20:33] <durandal11707> so i can push first patch and flac, tak & wavpack one, as michaelni did not found sample with which it breaks :evil
[20:45] <durandal11707> hmm isn't thread_count set to 1 by default anyway
[20:48] <durandal11707> michaelni: that return value for mulitple threads seems serious, and because it happens here (on single cpu) even more
[20:54] <nevcairiel> thread_count should by default be 0, which means it auto-detects it based on your CPU
[20:55] <durandal11707> see libavcodec/options_table.h
[20:57] <nevcairiel> the funny thing about that is that avformat_find_stream_info sets the value to 0 for all codecs after its done, so if you use those codec contexts for decoding, it'll be 0 and auto-detect
[20:58] <nevcairiel> seems like a weird way to do things, but thats what happens right now
[21:00] <durandal11707> where?
[21:01] <nevcairiel> at the end of the function
[21:01] <durandal11707> michaelni: are going to take a look at that return thing?
[21:06] <durandal11707> looks like p->result just get overwritten
[21:08] <durandal11707> there is strange line in pthreads: #if 0 //BUFREF-FIXME
[21:09] <durandal11707> anyway return thing, same like pts one is unrelated, and already present for video
[21:09] <durandal11707> so i will just make threads for audio defaults to 1 and push patchset
[21:13] <michaelni> durandal11707, fine with me
[21:14] <michaelni> about the return thing, i think its more efficient if you fix it when you already started looking at it
[21:15] <michaelni> i have a few more crashes to look into
[21:15] <michaelni> and a long todo list ...
[21:18] <durandal11707> i dunno how to fix it....
[21:21] <durandal11707> results can be different, and how do I pick one?
[21:22] <durandal11707> FFMIN()?
[21:27] <durandal11707> that would be only useful to detect if decoding of some frame(s) failed, but not to find exact numbers of them....
[21:28] <michaelni> ideally no result would be lost or returned twice
[21:29] <durandal_1707> than it should be in array[nb_threads]
[21:50] <durandal_1707> michaelni: do you think 12 it too small for crc24?
[21:53] <durandal_1707> does it actually increase memory usage?
[21:56] <durandal_1707> if does, i could split tables as thing is static
[22:09] <michaelni> durandal_1707, i dont know if 12 is too small i cant predict the future ...
[22:17] <durandal_1707> in future it will be rewritten in javascript
[23:39] <cone-389> ffmpeg.git 03Michael Niedermayer 07master:bbc19010edfd: jpeg2000dec: return error for invalid cdxy values
[23:39] <cone-389> ffmpeg.git 03Michael Niedermayer 07master:258a05b21684: MAINTAINERS: add fingerprint of the FFmpeg release signing key
[00:00] --- Thu Jun  6 2013