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

[burek]

[00:02] Action: wm4 hopes that libavscale doesn't stay vaporware
[00:03] <J_Darnley> BBB: http://pastebin.com/CLmhJefE
[00:10] <ubitux> wm4: it will probably have similar bugs, some more, it will be slower, and probably just a wrapper around sws at the beginning
[00:10] <wm4> that's some optimism
[00:11] <ubitux> it won't happen anytime soon anyway
[00:11] <ubitux> unless they use the money of ffmtech
[00:12] <ubitux> the avframe wrapper might happen soon or later though, but i believe it will stay in that state for quite a long time
[00:12] <wm4> I have a patch to add that to swscale
[00:12] <wm4> I posted it a year ago or so
[00:18] <michaelni> wm4, whats the subject of the patch/mail ?
[00:20] <wm4> [FFmpeg-devel] [PATCH] swscale: add API to convert AVFrames directly
[00:37] <michaelni> wm4, the last thing in that thread is a review from stefano without a reply from you
[00:43] <wm4> yes I think I decided not to add this, because libavscale was supposedly in the works
[00:46] <wm4> and it was also kind of hacky how the reinitialization worked (sledge-hammer approach to make libswscale do what I want)
[00:47] <michaelni> what problem was there with reinit ?
[00:49] <wm4> I don't quite remember, but I had to uninit and reinit it in-place
[00:50] <michaelni> I suggest we work on swscale and improve what needs to be improved 
[00:52] <wm4> well, as it stands even adding simple conversions seems to be hard and non-trivial
[00:52] Action: wm4 remembers Daemon404 cursing for weeks when he wanted to add GBRP conversions
[00:56] <michaelni> so improve its structure
[00:57] <wm4> nobody really wants to refactor libswscale mess
[00:57] <michaelni> is it easier when its called avscale =
[00:57] <michaelni> ?
[00:58] <wm4> libavscale supposedly starts from fresh, instead of forking libswscale or anything
[00:58] <michaelni> also i do want to refactor it but i have too many things to do so its unlikely i will do it alone
[01:31] <michaelni> ubitux, the valgrind hqx issue looks like a valgrind "bug" SIMD having some input bytes uninitialized and that infecting too many output bytes
[02:06] <iive> are libav really working on avscale?
[02:07] <wm4> "working"
[02:12] <iive> wm4: ?
[02:13] <wm4> they've been talking about it for a year or so
[02:14] <iive> so just talk.
[02:18] <wm4> well, let's call it plans
[02:19] <nevcairiel> they dont have the man power to finish it any time soon anyway, as it is only like one guy is "working"/planning on it, isn't it
[02:25] <iive> and that guy should maintain the existing libav :)
[02:29] <wm4> nevcairiel: as long as there's literally nothing, nobody can help contributing anyway
[02:30] <nevcairiel> he keeps talking about their weird "sprint" somewhere on a mountain when he wants to create something
[02:33] <nevcairiel> it should be in a month or so, maybe we'll get something to bikeshed to death after \o/
[02:42] <wm4> lol
[02:42] <j-b> good morning
[02:43] <wm4> technically it's almost morning indeed
[02:43] <nevcairiel> its nearly 8pm, whatchatalkingabout
[02:49] <j-b> it's 3am almost
[03:16] <cone-539> ffmpeg.git 03Michael Niedermayer 07master:a1a76b209b42: swscale/x86/input: prevent RGB32_TO_UV_FN from reading into the padding
[03:16] <cone-539> ffmpeg.git 03Michael Niedermayer 07master:4abffbbc54a2: swscale/x86/input: prevent RGB32_TO_Y_FN from reading into the padding
[03:16] <michaelni> ubitux, wm4 valgrind issue should be fixed
[03:17] <michaelni> wm4, still not interrested in working together on improving swscale ?
[03:18] <michaelni> i really think it would be better if everyone would work together
[03:19] <wm4> I find the idea of starting fresh attractive, instead of forever-refactoring swscale, but I have no idea what will come of it
[03:21] <michaelni> well, if you have an idea on how to "segment" the scaling which is better than how it is currently then you can change swscale toward this in small steps
[03:21] <michaelni> i dont think it would be less work if you start from scratch
[03:22] <michaelni> and OTOH if you have no idea on how to improve things, well ..
[03:23] <iive> Daemon404 likes to complain about things he doesn't understand, blaming the author rather himself.
[03:23] <wm4> if you look at one of the swscale sources (I think it was utils.c), you can see there's a BIG function which initializes EVERYTHING, and which even has self-modifying code, complete with platform specific code for unix and windows
[03:23] <wm4> and it's for MMX
[03:23] <wm4> and this last bit always cracks me up
[03:23] <iive> and rewriting is good way to figure out how something works.
[03:25] <wm4> well there's fmtconv (https://github.com/vapoursynth/fmtconv) which in some circles was hailed as possible libswscale replacement, but I'm not sure about its performance
[03:25] <wm4> (performance as in speed and quality)
[03:25] <wm4> it's written in C++ though
[03:25] <iive> i'd like to see templates in C.
[03:25] <wm4> I have no idea if it has better design
[03:26] <michaelni> wm4, the self modifying code is just for the "fast biliear scaler" its quite seperate
[03:26] <wm4> quite separate? but it's messed right into the shit
[03:26] <wm4> technically it's probably not the worst part, sure
[03:27] <iive> i'm kind of disappointed, I thought the SMC is used for everything.
[03:28] <michaelni> wm4 you can comment it out and not use the FAST_BILINEAR scaler. it doesnt really affect any overall design
[03:28] <wm4> iive: no it's just for MMX and a shitty scaler
[03:28] <wm4> (apparently)
[03:28] <wm4> michaelni: yes sure, but I don't know how you expect anyone not to run away with code like this
[03:30] <iive> why do you call it shitty?
[03:33] <michaelni> wm4, i cant really do anything about "dislike for the existing code" except to suggest to improve it
[03:34] <wm4> can I send a patch to remove this code?
[03:35] <michaelni> send? yes, but what advantage and disadvantage does it have to remove it ?
[03:35] <iive> wm4: after you give benchmark proving that the remaining code is as fast as SMC and produces same output.
[03:35] <michaelni> has it lost its speed advantage with sse & avx ?
[03:36] <iive> michaelni: maybe you should add SSE and avx to it. and move it to separate file.
[03:36] <iive> so people are not scared :O
[03:37] <michaelni> a seperate file is certainly better than having it where it is now, yes
[03:38] <wm4> <michaelni> a seperate file is certainly better than having it where it is now, yes <- you're using the word "better", so at least you agree there's some sort of problem
[03:39] <michaelni> yes
[03:39] <iive> ok. what are the other problems of swscale?
[03:40] <wm4> iive: that apparently most conversions must go through yuv420
[03:40] <wm4> and general slowness and lack of quality
[03:40] <wm4> (image quality)
[03:41] <iive> you mean, rgb->rgb goes through yuv?
[03:41] <michaelni> yuv420 isnt really true, theres a >8bpp internal planar YUV buffer
[03:42] <michaelni> so it would be YUV 444 internally when its needed / the user wants
[03:43] <michaelni>  > 8 bit per sample that is not pixel ;)
[03:48] <nevcairiel> You need to explicitly request it to preserve full chroma, which seems kinda unintuitive
[03:49] <michaelni> yes and yes (unintuitive)
[03:50] <iive> doesn't it use the least common denominator?
[03:51] <nevcairiel> Its not that smart
[03:51] <michaelni> making it more intuitive and use better defaults should not be very hard
[03:53] <iive> maybe add two options, one to prefer speed over quality and another for the opposite.
[03:53] <iive> why the most interesting chat happens when i have to leave...
[03:53] <iive> n8 ppl
[03:53] <michaelni> n8 iive 
[05:16] <cone-539> ffmpeg.git 03Michael Niedermayer 07master:d7efafd63a63: avfilter/vf_hqx: partly fix big endian fate test
[05:16] <cone-539> ffmpeg.git 03Michael Niedermayer 07master:fd3c27375f96: fate/filter-video: fix hqx on big endian part 2
[05:35] <jamrial> seems that the hqx tests fail with threads > 2
[05:40] <jamrial> "make fate-filter-hqx THREADS=4" failure. "make fate-filter-hqx THREADS=4 THREAD_TYPE=slice" success
[06:05] <cone-539> ffmpeg.git 03Michael Niedermayer 07master:954a38e9bf65: avfilter/vf_hqx: remove << 0
[06:05] <cone-539> ffmpeg.git 03Ronald S. Bultje 07master:0dae193d3ecf: swr: remove another forgotten division in DSP function.
[09:18] <ubitux> oh thx michaelni 
[09:26] <ubitux> that threading issue seems related to the dimension changes again
[09:33] <ubitux> it's not calculating one of the frame, for some reason
[18:14] <cone-826> ffmpeg.git 03Diego Biurrun 07master:9a9e2f1c8aa4: dsputil: Split audio operations off into a separate context
[18:14] <cone-826> ffmpeg.git 03Michael Niedermayer 07master:99497b4683e5: Merge commit '9a9e2f1c8aa4539a261625145e5c1f46a8106ac2'
[18:31] <wm4> how long until vf_drawtext becomes photoshop
[18:35] <michaelni> thats easy, it will never, and actually i think thats sad .... a free software replacement for photoshop would be nice (gimp is nice yes but its user interface is not nearly as intuitive but then its long ago that i used either)
[18:53] <J_Darnley> I think 2.8's one-window interface made it much better, on Windows at least.
[18:54] <J_Darnley> ... and for what I do with it.
[18:55] <wm4> J_Darnley: except they did stupid things with the close button
[18:55] <wm4> now clicking the close button once closes a single document, not gimp (lolwut)
[18:56] <J_Darnley> Oh
[18:56] <wm4> I retried it, apparently they fixed it :D
[18:57] <J_Darnley> I must have missed that "feature"
[18:57] <J_Darnley> :)
[19:31] <nevcairiel> that was probably a remnant from the multi-window system
[19:32] <nevcairiel> since that was what happened there as well, and made somewhat sense then
[20:11] <cone-826> ffmpeg.git 03Andrey Utkin 07master:3bb4d26a5df4: drawtext: drop unused draw_glyphs() arg "rgbcolor"
[20:11] <cone-826> ffmpeg.git 03James Almer 07master:6ec3dc97fcd2: x86/audiodsp: move asm code out of dsputil
[20:29] <debianuser> Hello, I'm trying to concat different (wav, ogg) audio files. But command `echo -e "file 1.wav\nfile 2.ogg\nfile 3.wav" | ffmpeg -f concat -i - -ac 2 -ar 48000 0.wav` gives incorrect output file and lots of errors: pastebin.com/KQQSCGM4
[20:29] <debianuser> Is it a bug? Or maybe I miss something obvious?
[20:33] <J_Darnley> Apart from the fact that this is the wrong channel?
[20:38] <J_Darnley> Well to start with you cannot cat those file together.
[20:39] <wm4> hm, ffmpeg is still not in debian?
[20:42] <debianuser> wm4: It's in deb-multimedia, but mine was built from sources.
[20:43] <debianuser> J_Darnley: Sorry, I thought if that's a bug it must be reported to this channel.
[20:44] <wm4> deb-multimedia is not official
[20:45] <debianuser> J_Darnley: You mean it's impossible to concat audio files with ffmpeg at all, or am I using wrong command?
[20:45] <wm4> debianuser: it's not a bug, I think the problem is that you can't mix codecs
[20:50] <debianuser> Why? I mean it's not remuxing, it's recoding. And ffmpeg can decode any codec... Anyway, if I convert ogg->wav first and then try to concat 3 wav files I still get it wrong (47.35 seconds file while sources were 10.92+3.43+12.89 seconds).
[20:51] <J_Darnley> What you are asking ffmpeg to is the same as if you had cat the files directly.
[20:52] <J_Darnley> If you want to cat random files you will need to use the concat filter
[20:54] <debianuser> Is it "almost" the same or "literally" the same?
[20:56] <debianuser> No, it's not "literally" same. I just checked. When I `cat` wav files and try to recode result, only the first of 3 files is recoded.
[21:02] <debianuser> So if it's not a concat-bug, it's some missing feature of -f concat.
[21:02] <debianuser> J_Darnley: concat filter is harder for me to use, because I need this working for hundreds of files. For -f concat I could do `ls -1 dir/* | sed 's/^/file /' | ffmpeg -f concat -i - ...`. But it's much harder to construct a command line for concat filter. Anyway, I tried it too: `ffmpeg -i 1.wav -i 2.ogg -i 3.wav -filter_complex 'concat=n=3:v=0:a=1[a]' -map '[a]' -ac 2 -ar 48000 0.wav` gives a short file (10.92+3.43+12.89!=23.83) and many errors: past
[21:06] <wm4> there's no such thing as switching codec mid-stream (on the same ffmpeg-level stream), so that can't be fixed AFAIK
[21:06] <wm4> it needs to be implemented higher level
[21:06] <wm4> but good luck touching ffmpeg.c
[21:13] <nevcairiel> wasnt there some concept that allowed that somehow
[21:16] <cone-826> ffmpeg.git 03Michael Niedermayer 07master:31f77b46b2fa: avfilter/unsharp_opencl: fix macro ()
[21:16] <cone-826> ffmpeg.git 03Michael Niedermayer 07master:9b33cdcab211: avfilter/vf_blend: fix macro ()
[21:16] <cone-826> ffmpeg.git 03Anshul Maheshwari 07master:ca2f59e12108: avcodec/dvbsubdec: support returning exact end times
[21:16] <cone-826> ffmpeg.git 03Anshul Maheshwari 07master:7e6cf364537e: ffmpeg: fix transcoding dvbsub to dvbsub
[21:29] <debianuser> But there're files/streams changing codec on the fly. And mkv chapters loading content from another file. Can't ffmpeg support any of them yet?
[21:30] <nevcairiel> nope
[21:30] <nevcairiel> and those mkv things kidna require to be all the same codec
[21:32] <debianuser> Well, then, it's a feature request: support resetting/reinitializing codec mid-stream to support different codecs for -f concat.
[21:33] <JEEB> that'd pretty much be what Libav wanted to do with concateration then, which would be fully on the side of the app, instead of putting it into demuxers etc
[21:34] <wm4> isn't concatenation possible with lavfi?
[21:35] <nevcairiel> cant you pipe several files in order, decoding to the same raw format first
[21:35] <nevcairiel> doing this in the demuxer/decoder chain seems unlikely
[21:35] <nevcairiel> more like an application feature if anything
[21:36] <debianuser> That would be part of demuxer, i.e. only demuxer knows when stream of the first codec ended, and there goes another codec, isn't it? And -f concat looks like a demuxer for me, optionally calling other demuxers if needed...
[21:37] <nevcairiel> just saying that its highly doubtful to ever be implemented in a demuxer
[21:38] <nevcairiel> because in practice, it can't. the app controls the interaction between demuxing and decoding, which obviously alos needs to be updated when the format changes
[21:38] <nevcairiel> so it would be much easier to just open the new file on the side of the app
[21:39] <nevcairiel> in any case, best solution, just decode them all to the same raw format first
[21:45] <debianuser> Hm... Does the app initialize the decoder manually? Or is there a way for demuxer signal to the decoder somehow to reinitialize itself to some new settings?
[21:46] <nevcairiel> to new settings, sure, but not to an entire new decoder
[21:46] <nevcairiel> its not designed for this, and the design is unlikely to change
[21:48] <debianuser> Then concatting 3 wav files should work at least. But it does not. :( It gives me 47.35 seconds file while sources were 10.92+3.43+12.89 seconds.
[21:49] <nevcairiel> same channels and sample rate?
[21:50] <debianuser> No, different channels/rates, but same codec: wav
[21:50] <debianuser> (pcm s16_le)
[21:50] <nevcairiel> then thats your reason
[21:51] <debianuser> So it can't even reinitialize the codec to new values?
[21:52] <nevcairiel> i guess it could in theory do that, but in practice noone cares
[21:59] <debianuser> If I have to manually decode them to the same format, then... Why ffmpeg (as application) can't do it automatically? I mean if I do the recoding anyway why can't ffmpeg decode them all to the same format before concatting?
[22:00] <nevcairiel> like i said, because noone cares
[22:00] <nevcairiel> send a patch
[22:02] <wm4> AFAIK it's because ffmpeg.c is a big mess, and nobody wants to implement it the proper way
[22:02] <wm4> so there are hacks like the concat demuxer
[22:02] <wm4> which work "sometimes"
[22:07] <debianuser> Well, I guess that would remain a feature request then.
[22:09] <debianuser> How about -filter_comples concat, is it supposed to work for different codecs? This page says it does: http://trac.ffmpeg.org/wiki/How%20to%20concatenate%20%28join,%20merge%29%20media%20files
[22:09] <debianuser> And if it does, why command `ffmpeg -i 1.wav -i 2.ogg -i 3.wav -filter_complex 'concat=n=3:v=0:a=1[a]' -map '[a]' -ac 2 -ar 48000 0.wav` gives a short file (10.92+3.43+12.89!=23.83) and many errors: pastebin.com/nEYL9RLa
[22:09] <debianuser> Is that some missing feature too?
[22:10] <nevcairiel> you can probably fix that by mixing and resampling the audio before the concat filter
[22:10] <nevcairiel> so the concat filter gets all audio in the same format
[22:26] <debianuser> Hm... Like this? ([0:0]aresample=48000:och=2:osf=s16:first_pts=0[a0],[1:0]aresample=48000:och=2:osf=s16:first_pts=0[a1],[2:0]aresample=48000:och=2:osf=s16:first_pts=0[a2],[a0][a1][a2]concat=n=3:v=0:a=1[a]) http://pastebin.com/nA5JhXXZ Still 10.92+3.43+12.89 != 23.89 seconds
[23:36] <Timothy_Gu> debianuser: it seems to me that ffmpeg is skipping the ogg track
[23:37] <Timothy_Gu> 10.92+12.89 almost = 23.89
[23:47] <debianuser> Timothy_Gu: It's not, not completely. I can hear part of the track in the result file. (in case my ffmpeg build is broken) you can try it, these files are here: ge.tt/1Eg60nl1/v/1
[00:00] --- Mon Jun 23 2014