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

[burek]

[00:00] <saste_> oh got a crash
[00:01] <Daemon404> ?
[00:03] <saste_> Daemon404, ffmpeg -i test.ffmeta  -f lavfi -i "testsrc=d=0.125" -map_metadata 0 -y out.nut
[00:03] <Daemon404> oh?
[00:03] <Daemon404> is htis on linux?
[00:03] <saste_> yes
[00:04] <saste_> i'm debugging it, missing NULL checks somewhere in lavf
[00:04] <saste_> proof that this feature is not much used
[00:05] <Daemon404> ;p
[00:10] <Daemon404> saste_, confirmed its getting mangled somewhere inside ffmpeg
[00:10] <Daemon404> need to track down where
[00:11] <saste_> so you can confirm that strlen() is not mangling stuff at least
[00:11] <Daemon404> i did
[00:12] <Daemon404> its going into teh strlen areas of dict.c pre-mangled
[00:16] Action: Daemon404 poeks ffmpeg_opt.c
[00:22] <Daemon404> saste_, i cant find where metadata[i].u is set
[00:25] <Daemon404> hmm looks like it is copied through magic as a SpecifierOpt
[00:26] <Daemon404> but i have no idea where that occurs
[00:32] <Daemon404> such hairy code...
[00:34] <saste_> Daemon404, rewrite it from scratch ;-)
[00:35] <Daemon404> i confirmed is going into parse_option() pre-manged
[00:35] <Daemon404> but i cant freaking find where it gets set before that
[00:36] <Daemon404> oh
[00:36] <Daemon404> parse_option AND parse_options exist
[00:36] <Daemon404> fun
[00:37] Action: Daemon404 feels close
[00:39] <Daemon404> LOL
[00:39] <Daemon404> it gets mangled inside:
[00:39] <Daemon404>  * For Windows - perform wide-char to UTF-8 conversion.
[00:39] Last message repeated 1 time(s).
[00:39] <Daemon404> ^ this func
[00:39] <Daemon404> very classy
[00:40] <Daemon404> because it isnt -getting- wide char input
[00:40] <Daemon404> its getting utf8 input!
[00:40] <Daemon404> wtf is this
[00:41] <Daemon404> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=b1ac139d89b9fc55b70ad3411af2f75fe8b17805
[00:41] <Daemon404> this broke utf8 cmd line text rag handling
[00:42] <Daemon404> in the name of "fixing" unicode filenames
[00:42] <saste_> Daemon404, wait a minute
[00:43] <Daemon404> saste_, ?
[00:44] <saste_> Daemon404, apply the patch I just sent to ML
[00:44] <saste_> then try this command: ffmpeg -i test.ffmeta -f lavfi -i "testsrc=d=0.125" -map_metadata 0:g -y out.nut
[00:44] <saste_> test.ffmeta should contain an unicode string
[00:45] <Daemon404> saste_, im sure it will work
[00:45] <Daemon404> but that doesnt change the fct that b1ac139d89b9fc55b70ad3411af2f75fe8b17805 broke utf cmd lien args
[00:46] <saste_> yes
[00:47] <ubitux> char ***argv_ptr
[00:47] <ubitux> :))
[00:48] <Daemon404> saste_, crashes
[00:48] <Daemon404> cant open teh  ffmeta file
[00:48] <saste_> Daemon404, with or without the patch?
[00:48] <saste_> it works here
[00:48] <Daemon404> with
[00:51] <saste_> can you get a backtrace?
[00:51] <Daemon404> not right now on lolwindows
[00:52] <saste_> try with no funny chars in the meta file, to make sure that it's not a charset thing
[00:52] <Daemon404> i did
[00:52] <Daemon404> same diff
[00:52] <Daemon404> $ cat a.ffmeta
[00:53] <Daemon404> title=a
[00:54] <saste_> first line should be ;FFMETADATA1
[00:54] <Daemon404> >.>
[00:54] <saste_> followed by key=val
[00:54] <Daemon404> well it shouldnt crash
[00:54] <Daemon404> now should it
[00:54] <saste_> but even in that case it shouldn't crash
[00:54] <Daemon404> crashes anyway
[00:54] <saste_> damn
[00:56] <Daemon404> saste_, wait!
[00:56] <Daemon404> my fault
[00:56] <Daemon404> i left it code to dump strings
[00:56] <Daemon404> from argv[18]
[00:59] <Daemon404> saste_, it seems msys doesnt abide by standard cmd.exe behavior
[00:59] <Daemon404> which is what it expects
[00:59] <Daemon404> so there is no fix
[00:59] <Daemon404> "msys is broken"
[00:59] <Daemon404> end of story
[00:59] <saste_> good to know
[00:59] <saste_> anyway we can workaround the issue by using an ffmeta file
[00:59] <Daemon404> yes
[00:59] <Daemon404> let me test nw
[01:00] <saste_> that would be useful, because it allows to set metadata *per-stream*
[01:00] <saste_> (which i don't know how to set via commandline)
[01:01] <Daemon404> saste_, it works
[01:01] <Daemon404>   Metadata:
[01:01] <Daemon404>     title           : I e Üñîçød¬
[01:02] <saste_> yeah
[01:02] <saste_> i'm going to update test soon
[01:02] <saste_> as for the msys issue, should be reported to mingw folks
[01:04] <Daemon404> they know
[01:04] <Daemon404> there are many broked things in msys
[01:04] <Daemon404> they call it "nonissue"
[01:05] <saste_> yes the easy way to fix bugs
[01:05] <saste_> pretending they don't exist
[01:06] <Daemon404> man i wasted so much time on this
[01:06] Action: Daemon404 feels cheatede
[01:07] Action: saste_ hugs Daemon404 
[01:07] <Daemon404> ;p
[04:15] <ohsix> Daemon404: what do you mean "standard cmd.exe behavior", the way DOS & windows works the command line parser is in the program and ran before _main, not in the shell
[04:15] <ohsix> you need _wmain to get wide character arguments
[04:16] <Daemon404> i know you do
[04:17] <Daemon404> what i meant is if you ran cmd.exe and passed it that uncode argument
[04:17] <Daemon404> it would have not gotten there as utf8 like in msys
[04:17] <Daemon404> rather, 'typed' such an argument
[04:17] <ohsix> it would have gotten to main() as translated by the current code page
[04:17] <Daemon404> yes
[04:17] <Daemon404> which would have worked
[04:17] <ohsix> which is wrong :] or worse, ascii
[04:18] <Daemon404> if you have a way to handle both cases, feel free to help
[04:18] <ohsix> what do you mean? if you don't have _wmain you basically get "magic", or code page/ascii translations
[04:19] <Daemon404> im not sure _wmain would help much with the msys case
[04:19] <ohsix> the only thing really going on with main() is that on windows you get junk, on linux you basically get utf8 without magic
[04:20] <ohsix> what's actually breaking, is it getting invalid utf8 or something?
[04:20] <Daemon404> on msys it's getting valid utf8 from argv, but then it tries it's usual magic to work with stuff as seen from cmd.exe, and that actually mangles the utf8
[04:20] <Daemon404> i can link you to the relevant function
[04:21] <ohsix> "but then it" is what, any magic msys's stub or libc should be doing all of that before main and before there's even an argv to pass to it
[04:22] <Daemon404> well either it works in msys
[04:22] <Daemon404> or it works in cmd
[04:22] <Daemon404> i cant think of a way to do both
[04:23] <ohsix> cmd doesn't really have anything to do with it, it's not like bash or whatever where a ton of stuff happens in the shell, it's just passed verbatim to the program, and the startup stub does all the argument processing (including file globbing, and everything else)
[04:24] <Daemon404> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=b1ac139d89b9fc55b70ad3411af2f75fe8b17805
[04:24] <Daemon404> fwiw, you are not being helpful at all
[04:24] <ohsix> heh
[04:24] <ohsix> i'm trying to get the information on where msys may be broke, and telling you how it's all supposed to go together
[04:25] <Daemon404> with msys, you just gets cmd lien args verbatim.
[04:25] <Daemon404> in utf8.
[04:25] <Daemon404> it goes through that code, and gets mangled.
[04:26] <ohsix> command line arguments do not get to the environment in utf8, the program stub does all that before main, utf8 in argv[] should be pretty much what you get from the same program built for linux
[04:27] <ohsix> let me read that patch
[04:27] <ohsix> from my understanding it shouldn't even be needed
[04:28] <ohsix> so it is ignoring what's prepared and passed to main() and just getting the command line
[04:28] <ohsix> that's not a road you want to travel more than once
[04:30] <Daemon404> if you run ffmpeg from within cmd.exe, you sure dont get utf8 in argv
[04:30] <Daemon404> depending on the environment
[04:30] <Daemon404> pretty sure that is what that patch is trying to work around
[04:30] <ohsix> ok let me restate it all again, it depends on the c library & startup stub
[04:31] <Daemon404> its windows
[04:31] <ohsix> with cl/msvcrt you get code page arguments to main() the end, you need _wmain to get anything else
[04:31] <Daemon404> its the same dman c lib
[04:31] <ohsix> with mingw, it's being translated before main() and you're getting something like what you'd get on linux
[04:31] <ohsix> c library OR startup stub
[04:31] <Daemon404> thats is faulty statement
[04:31] <Daemon404> mingw !+ msys
[04:31] <Daemon404> !=*
[04:31] <ohsix> s/mingw/msys
[04:32] <Daemon404> the same problem exists with mingw built binaries, obviously
[04:32] <ohsix> it's not a part of the c runtime in msvcrt, it's in one of the stubs linked to it D: but there's part of it in msvcrt
[04:33] <Daemon404> [22:31] < ohsix> with cl/msvcrt you get code page arguments to main() the end, you need _wmain to get anything else
[04:33] <ohsix> so do you mean there's a difference between a shell in msys and cmd?
[04:33] <Daemon404> [22:31] < ohsix> with mingw, it's being translated before main() and you're getting something like what you'd get on linux
[04:33] <Daemon404> ^ the patch i linked is for the former
[04:33] <ohsix> right
[04:33] <Daemon404> [22:33] < ohsix> so do you mean there's a difference between a shell in msys and cmd?
[04:33] <ohsix> it's dumb, but right
[04:33] <Daemon404> isnt that wat i said numerous times
[04:33] <ohsix> no
[04:33] <ohsix> cmd isn't a "shell" like anything else
[04:33] <Daemon404> this is exactly what i said
[04:33] <ohsix> okay
[04:34] <ohsix> you should be using _wmain and calling main if you want more specific setup, let the linker figure it out
[04:35] <ohsix> (then you will get, again from the stub, a known format in argv[], wide characters)
[04:35] <Daemon404> youve only told me what i already knpw
[04:35] <Daemon404> and decided not to do
[04:36] <ohsix> why? that's how you do it
[04:36] <ohsix> windows is the only target with this problem, unless you are doing a dos port too
[04:36] <ohsix> os2
[04:36] <Daemon404> because it's very ugly, and i dont care much for doing it just so it works under msys bash
[04:37] <ohsix> how is it any more ugly than that patch heh
[04:37] <ohsix> you push the problem into the stub/libc with _wmain, and forget about it
[04:37] <Daemon404> when you start ifdefing main, its ugly.
[04:37] <ohsix> _wmain defined anywhere else is harmless, it just doesn't happen
[04:38] <ohsix> same ifdef you have for prepare_app_arguments
[04:38] <Daemon404> also i do not feel like getting it paste the bridge guarded by anti-ms trolls
[04:38] <Daemon404> on the mailing list
[04:39] <ohsix> that's an awful excuse to do it right, it's not like there isn't a bunch of specific code in there, and the main wrapper is less than what you'd need in prepare_app_arguments
[04:39] <Daemon404> and do you know if _wmain even works correctly under msys?
[04:39] <ohsix> i don't know how you get anything but the shit in the code page to main() in this situation, i'll look into that
[04:40] <Daemon404> i seem to remember a bunch of projects with bugs open saying it doesnt
[04:40] <ohsix> msysgit has a bunch of threads saying it doesn't
[04:40] <Daemon404> what whats the point?
[04:42] <ohsix> there's code in msysgit you can use
[04:42] <Daemon404> s/usr/read/
[04:42] <Daemon404> er s/use/read/
[04:42] <Daemon404> dat gpl
[04:43] <ohsix> oh right
[04:44] <ohsix> the possibility that mingw didn't do the wmain stuff didn't occur to me at all :<
[04:44] <ohsix> that's just dumb
[04:44] <Daemon404> tl;dr the whole thing is a crapshoot
[04:45] <Daemon404> msys has a whole bunch of problems nobody cares
[04:45] <ohsix> you have to reprocess the command line if you want to glob shit, after main, in the command line translator thing lewl
[04:45] <ohsix> well it's not really a problem, but they should have a helper that does it for you, or give you utf8 in main() automatically
[04:46] <Daemon404> you DO get utf8 in main
[04:46] <Daemon404> under msys
[04:46] <Daemon404> as you would in linux
[04:46] <ohsix> you can't ifdef msys and skip prepare?
[04:46] <Daemon404> theres no way to tell?
[04:47] <Daemon404> it's als oa runtime thing
[04:47] <Daemon404> you can run whatever the hell you want under msys
[04:47] <ohsix> i mean, isn't there a preprocessor symbol you can already use to skip it
[04:47] <Daemon404> its a runtime thing.
[04:47] <Daemon404> it has nothing to do with the compiler
[04:47] <Daemon404> so no, there isnt.
[04:48] <ohsix> so ok, we meant different things, i meant the program stub for msys/mingw giving you utf8 as arguments to main _always_, not just based on the shell
[04:48] <Daemon404> compiler is completely and utterly irrelevant here
[04:49] <Daemon404> the same binary behaves differently under msys than not under msys
[04:49] <Daemon404> msys being the shell
[04:50] <ohsix> right
[04:50] <ohsix> the stub has all the command line processing in it, i presumed that it would normalize the character set passed to main
[04:51] <ohsix> eg. the shell would not matter
[04:51] <Daemon404> nope.jpg
[04:53] <ohsix> msys-git has a wrapper to always launch it with a unicode environment lul
[04:53] <ohsix> solution coming right up
[05:06] <ohsix> so, getcommandlinew isn't returning utf16 characters?
[05:07] <ohsix> the conversions should fail too
[09:45] <ubitux> michaelni: it's not easy to test for f4v: the only two supported video codecs are avc & vp6
[09:45] <ubitux> we don't have any native support for those afaik
[09:45] <ubitux> oh i'm stupid
[09:46] <ubitux> i can test faststart with something else than f4v
[09:46] <ubitux> forget this.
[10:09] <CIA-56> ffmpeg: 03Stefano Sabatini 07master * r10c00f7a04 10ffmpeg/tests/ (Makefile test.ffmeta): 
[10:09] <CIA-56> ffmpeg: tests/fate-ffprobe: use an ffmetadata file for the injected metadata
[10:09] <CIA-56> ffmpeg: Workaround commandline msys issues, also allow more flexibility.
[10:09] <CIA-56> ffmpeg: Should fix ffprobe tests on mingw+MSVC.
[10:09] <CIA-56> ffmpeg: 03Stefano Sabatini 07master * r64d340c62a 10ffmpeg/libavformat/utils.c: 
[10:09] <CIA-56> ffmpeg: lavf/utils: add error check in av_read_frame()
[10:09] <CIA-56> ffmpeg: In particular, fix crash when the input file contains no packets (e.g. an
[10:09] <CIA-56> ffmpeg: ffmeta input).
[10:13] <ubitux> saste_: btw, there is a typo in the message
[10:13] <ubitux> s/wih/with/
[10:14] <ubitux> if you fix it, since the tests will change, could you take the opportunity to add a comment with binary data?
[10:14] <ubitux> with values < 32
[10:14] <ubitux> so it's covering the json escaping (and maybe other)
[10:14] <ubitux> :X
[10:15] <ubitux> (typo in the first comment*, in ffmeta, sorry)
[10:23] <saste_> ubitux, the typo was in the file, not in the comment
[10:23] <saste_> the funny thing is that i didn't notice the typo until now
[10:23] <saste_> but it was in the original metadata comment, so no harm is done
[10:23] <ubitux> yeah sure it wasn't introduced in that commit
[10:23] <ubitux> i just noticed it too
[10:24] <saste_> regarding binary values, patch is welcome
[10:24] <saste_> i'm going to fix the typo
[10:24] <ubitux> :)
[10:25] <ubitux> saste_: are you reworking the sections patch, or you're still waiting for a review?
[10:25] <saste_> reworking it
[10:26] <ubitux> ok
[10:26] <saste_> i'll take into account some of your comments, since they're required by the subsection change
[10:29] <saste_> funny, by adding a char in the metadata the estimated duration of the *audio stream* increases
[10:29] <ubitux> hehe
[10:29] <ubitux> size/bitrate? :p
[10:29] <saste_> yes i think so
[10:29] <saste_> btw while we're discussing
[10:30] <saste_> i wonder if we should add a duration estimation heuristics into ffprobe
[10:30] <saste_> that's a popular request, since there is no way to compute the duration of a stream if not from the single timestamps
[10:31] <saste_> it can be done in a script, but given that it is a popular request, and seem useful, we could compute it in ffprobe
[10:31] <saste_> and add some fields like "computed_duration"
[10:32] <saste_> alternatively: we add a script tools for getting durations
[10:32] <ubitux> huh, isn't this a lavf builtin?
[10:32] <saste_> where?
[10:33] <ubitux> update_stream_timings maybe dunno
[10:33] <ubitux> i mean, isn't the duration estimation already supposed to be done automagically?
[10:35] <CIA-56> ffmpeg: 03Stefano Sabatini 07master * rd40b197ca8 10ffmpeg/tests/ (8 files in 2 dirs): tests/fate-ffprobe: fix typo in metadata comment
[10:40] <saste_> ubitux, i'm not sure about that
[10:41] <ubitux> libavformat/avformat.h:enum AVDurationEstimationMethod av_fmt_ctx_get_duration_estimation_method(const AVFormatContext* ctx);
[10:41] <ubitux> another duration thing
[10:42] <saste_> if we can rely on the library, is so much better
[12:06] <CIA-56> ffmpeg: 03Stefano Sabatini 07master * rd2c70ec07f 10ffmpeg/libavcodec/roqvideodec.c: lavc/roqvideodec: remove useless headers
[12:06] <CIA-56> ffmpeg: 03Stefano Sabatini 07master * rb1fee1be61 10ffmpeg/libavcodec/roqvideodec.c: lavc/roqvideodec: propagate reget_buffer() error code
[12:06] <CIA-56> ffmpeg: 03Stefano Sabatini 07master * refa3d5af1e 10ffmpeg/libavcodec/roqvideodec.c: 
[12:06] <CIA-56> ffmpeg: lavc/roqvideodec: fix error message
[12:06] <CIA-56> ffmpeg: Remove redundant reference to codec name, it is already mentioned in the
[12:06] <CIA-56> ffmpeg: log header.
[13:47] <CIA-56> ffmpeg: 03Michael Niedermayer 07master * rc75b611a38 10ffmpeg/configure: (log message trimmed)
[13:47] <CIA-56> ffmpeg: configure: enable runtime cpu detect by default.
[13:47] <CIA-56> ffmpeg: with the exception of libpostproc runtime_cpudetect = no is not
[13:47] <CIA-56> ffmpeg: supported thus having no as default really is quite odd, it results in
[13:47] <CIA-56> ffmpeg: a libpostproc where HAVE_MMX* have very different meaning from the
[13:47] <CIA-56> ffmpeg: rest of ffmpeg and it breaks any x86 cpu that doesnt support mmx2
[13:47] <CIA-56> ffmpeg: because mmx2 is hardcoded as a result
[13:47] <CIA-56> ffmpeg: 03Michael Niedermayer 07master * r874b9dcc4b 10ffmpeg/libavutil/ppc/cpu.c: 
[13:47] <CIA-56> ffmpeg: ppc/cpu: make linux 32bit specific altivec detection depend on __linux__
[13:47] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[14:04] <CIA-56> ffmpeg: 03Martin Storsjö 07master * r71908f0838 10ffmpeg/libavformat/smoothstreamingenc.c: 
[14:04] <CIA-56> ffmpeg: smoothstreamingenc: Copy the SAR on the AVStreams as well
[14:04] <CIA-56> ffmpeg: This is required in chained muxers, if the SAR happens to be set.
[14:04] <CIA-56> ffmpeg: Signed-off-by: Martin Storsjö <martin at martin.st>
[14:04] <CIA-56> ffmpeg: 03Samuel Pitoiset 07master * rcee1950bbb 10ffmpeg/ (7 files in 2 dirs): rtp: Packetization of JPEG (RFC 2435)
[14:04] <CIA-56> ffmpeg: 03Michael Niedermayer 07master * rff584803b7 10ffmpeg/: (log message trimmed)
[14:04] <CIA-56> ffmpeg: Merge remote-tracking branch 'qatar/master'
[14:04] <CIA-56> ffmpeg: * qatar/master:
[14:04] <CIA-56> ffmpeg:  rtp: Packetization of JPEG (RFC 2435)
[14:04] <CIA-56> ffmpeg:  smoothstreamingenc: Copy the SAR on the AVStreams as well
[14:04] <CIA-56> ffmpeg: Conflicts:
[14:04] <CIA-56> ffmpeg:  Changelog
[15:00] <CIA-56> ffmpeg: 03Stefano Sabatini 07master * rf3bd6fa7a8 10ffmpeg/libavcodec/mmvideo.c: lavc/mmvideo: forward reget_buffer return value in mm_decode_frame()
[16:05] <Daemon404> http://chromashift.org/yeah.txt
[16:53] <teratorn> hope it is ok to ask here, if no response in #ffmpeg, 
[16:53] <teratorn> having trouble with complex filtergraphs, using a command like this, ffmpeg -i sample.mp4 -i sample2.mp4 -filter_complex '[0:0] [0:1] [1:0] [1:1] concat=n=2:v=1:a=1 [v] [a1]' -map '[v]' -map '[a1]' -strict -2 -acodec aac -vcodec libx264 -crf 23 output.mkv, I want to also add an overlay PNG to the output result of the concat filter, but how??
[17:43] <Daemon404> ubitux / saste_ : is it feasible to expose something ading to is_intra_only in ffprobe?
[17:43] <Daemon404> akin to*
[17:45] <ubitux> i'd better expose a get_codec_props or something
[17:45] <Daemon404> well that works too
[17:45] <Daemon404> it can be useful on occasion
[17:46] <ubitux> or get_codec_desc
[17:46] <Daemon404> (in my case, it's deciding if it can cut easily)
[17:46] <ubitux> but it exists :p
[17:47] <ubitux> is_intra_only sounds like a lost function to me if exposed
[17:47] <ubitux> the public api already allows you to do that in a few lines of code
[17:47] <ubitux> maybe the api could be improve
[17:47] <ubitux> +d
[17:47] <ubitux> to reduce the necessary code
[18:30] <CIA-56> ffmpeg: 03Michael Niedermayer 07master * rfd63c2ff0c 10ffmpeg/tests/Makefile: 
[18:30] <CIA-56> ffmpeg: fate: fix --disable-ffprobe
[18:30] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[19:07] <ubitux> "Snow is a toy codec with no real-world use and horrible code."
[19:07] <ubitux> lol
[19:07] <ubitux> plz.
[19:08] <Daemon404> ubitux, its not exactly wrong
[19:08] <Daemon404> not that i agree with it
[19:08] <j-b> ubitux: who uses it?
[19:08] <ubitux> what's wrong with having interesting codecs?
[19:09] <ubitux> it's one of the rare codecs using wavelets
[19:09] <ubitux> if you don't want it just disable it at built time
[19:09] <Daemon404> "Snow is a toy codec with no real-world use and horrible code." <-- still correct tho
[19:09] <Daemon404> factually
[19:09] <ubitux> it's actually fun to see Diego saying that but well.
[19:11] <ubitux> i think a --disable-unpopular-codecs or something like this should be added instead
[19:11] <ubitux> to put video games or experimental codecs
[19:12] <Daemon404> --disable-useless-cruft
[19:13] <ubitux> would that disable msvc support?
[19:13] <Daemon404> o u
[19:13] <ubitux> ;)
[19:13] <Daemon404> msvc is far fro museless
[19:13] <ubitux> i don't agree with that
[19:13] <Daemon404> and is going to be the mostdistributed form of ffmpeg
[19:13] <Daemon404> snow
[19:13] <Daemon404> is useless
[19:13] <Daemon404> objectively useless.
[19:13] <ubitux> not objectively
[19:14] <Daemon404> nobody uses it, its not better than anything, it is bad code
[19:14] <ubitux> what's bad?
[19:14] <ubitux> what's the problem with it?
[19:14] <gnafu> Perhaps the easier question to answer is, "What's good?"
[19:15] <ubitux> it's just an interesting codec that does no harm
[19:15] <ubitux> that's stupid and irrespectful to just decide to trash it because you don't care about it
[19:16] <Daemon404> its actually quite intertwined and problem causing with other code
[19:16] <Daemon404> see: dirac
[19:16] <Daemon404> forthcoming
[19:16] <gnafu> There is the potential for exploits in crafted Snow files, since the code is old and messy.  I don't want to be one of those fear-mongerers, and I don't have a stake in it, but it's a valid concern when looking at removing old, unused code.
[19:16] <ubitux> gnafu: aren't you using libav anyway?
[19:17] <gnafu> ubitux: Technically, I use ffmpeg, since that's what's packaged for Fedora (RPM Fusion), and I don't typically build for myself ;D.
[19:17] <ubitux> you're gonna get trolled hard if they hear this
[19:17] <gnafu> I think they already know, but I'm not sure.
[19:18] <gnafu> It is all a part of my laziness.
[19:18] <ubitux> Daemon404: really problems? or just potential factoring?
[19:19] <ubitux> what's wrong with improving code instead of trashing or rewriting it from scratch?
[19:19] <Daemon404> i dont really feel like arguing about this
[19:19] <Daemon404> its liek talking to a wall
[19:19] <ubitux> you guys really look like 1-yr CS student
[19:19] <gnafu> ubitux: You're free to improve it.  Perhaps a patch to clean it up could thwart its removal :-D.
[19:20] <ubitux> that patch will likely get ignored in the merge
[19:20] <ubitux> and libav will just loose a feature
[19:20] <ubitux> end of the story :p
[19:20] <Daemon404> snow?
[19:20] <Daemon404> a feature?
[19:20] <Daemon404> LOL
[19:21] <saste_> ubitux, i'd rather ask to the current maintainer of snow
[19:22] <saste_> snow was interesting when it was designed, and as an experimental codec
[19:22] <saste_> now i don't know if these conditions still stand
[19:22] <ubitux> dunno
[19:22] <ubitux> 19:11:04 <@ubitux> i think a --disable-unpopular-codecs or something like this should be added instead
[19:22] <ubitux> but well, whatever
[19:22] <saste_> but we have a thing in ffmpeg which is called maintainer, so the ultimate decision is for the people who is actually doing the work
[19:22] <saste_> (of maintaining / extending / fixing it)
[19:23] <ubitux> i agree
[19:23] <saste_> what i find questionable is that unused/marginally useful code is going to hinder overall development
[19:24] <saste_> but in the case of snow i see not much evidence of it
[19:26] <saste_> then there is the psychological motivation, a lot of people is apparently annoyed by the existence of "ugly" code, even if they'll never work on it
[19:26] <saste_> it is more a psychological need, rather than a real need, but still a need
[19:27] <ubitux> exactly
[19:27] <ubitux> just a purification state of mind
[19:27] <ubitux> some kind of nonsense ideology :p
[19:30] <saste_> yes, so the interesting question is, why people do feel the need to "clean-up" (even code which will never bother them/on which they'll never work)?
[19:33] <ubitux> it's kind of satisfying to drop code, but this is only valid when you are refactoring code and simplify it
[19:33] <ubitux> not just freely drop it
[19:33] <gnafu> saste_: While I can't speak to the motivation of this instance, I do know the potential security risk is a motivator for some people.
[19:33] <ubitux> of course it's more simple to just remove that code.
[19:33] <ubitux> gnafu: sorry but this is BS
[19:33] <ubitux> at least from libav PoV
[19:33] <ubitux> that is the last reason they would like to drop it
[19:33] <gnafu> Yeah, I was just speaking in a general software sense.
[19:34] <ubitux> no i just think they want to remove it to purify the project, remove some historical code reminding them the old bad days, and make them feel useful by dropping stuff
[19:35] <ubitux> gnafu: do you have known security issues with snow?
[19:35] <Daemon404> you know i used to like ffmpeg because you guys werent constantly talkign about and emoing over the other project like libav was
[19:35] <Daemon404> seems thats gone.
[19:36] <ubitux> sorry about that, i'm done :)
[19:36] <ubitux> just the rant of the day
[19:36] <ubitux> i got pissed off by reading just another drop commit, i won't talk about it anymore
[19:37] <saste_> gnafu, security concerns, that could be technically relevant
[19:38] <saste_> i wouldn't be against marking snow as experimental, and *not* compile it by default
[19:38] <gnafu> ubitux: Hehe, I already said that I wasn't speaking to this instance of code removal.  I know nothing about Snow's code, only that libschroedinger is better and using Snow for real work would be silly ;D.
[19:38] <ubitux> :)
[19:39] <ubitux> JEEBsv: ./configure --help|grep doc
[19:39] <ubitux> you'll get some more here
[19:39] <ubitux> in case you're interested :P
[19:41] <JEEBsv> did that and it still fails to show me anything else but the prefix settings
[19:41] <JEEBsv> xxxxdir= settings
[19:44] <ubitux> do you mind (re-)explaining the issue?
[19:44] <JEEBsv> built mingw-w64 for lunix, now trying to build mingw-w64 for win32 with the i686-w64-mingw32 toolchain
[19:45] <Daemon404> you need to build both toolchains for linxu first
[19:45] <Daemon404> not just i686
[19:45] <JEEBsv> yes, I have both of them
[19:45] <JEEBsv> both i686 and x86_64
[19:45] <Daemon404> also i wonder why that script uses binutils cvs
[19:45] <Daemon404> it has a git repo mirror now
[19:45] <Daemon404> (but devs sitll use cvs because theyre neckbeards)
[19:46] <JEEBsv> probably because they love seeing people get "can't connect right now" messages
[19:46] <Daemon404> and none of the devs use titles
[19:46] <Daemon404> so you have git commits listed as like
[19:46] <Daemon404> * dir/file.c: stuff
[19:46] <Daemon404> cause their messages are giant lists of changes
[19:46] <Daemon404> with no title
[19:47] <JEEBsv> ubitux: tl;dr trying to build for win32 and it seems to be going fine until the cvs binutils fails after configure building its docs
[19:47] <Daemon404> its GNU INFO docs
[19:48] <JEEBsv> which led me to see if those can be disabled. I only see --infodir=derp
[19:52] <saste_> michaelni, could it be because of "ffmpeg$(HOSTEXESUF)"?
[19:53] <saste_> saste_, but then it is no different than the other rules in tests/Makefile
[19:55] <mkrufky> i want to use libavcodec to add a feature to my TV app to transcode broadcast television (mpeg2) into h.264 on-the-fly ... does anybody know of any sample source code that i can look at for transcoding a live stream?
[19:56] <saste_> mkrufky, ffmpeg.c of course
[19:56] <saste_> mkrufky, and btw this is more a question for the #ffmpeg channel
[19:57] <mkrufky> heh, i'll take a look in ffmpeg.c...   
[19:57] <mkrufky> ah, i see u answered there too ....  
[19:59] <JEEBsv> heh, tried --disable-info
[19:59] <JEEBsv> does exactly as much as I hoped
[19:59] <michaelni> saste_, the other things get compiled for the HOST but ffmpeg is compiled for the target
[20:00] <gnafu> saste_: I totally read that as "ffmpeg$(HOTSEXSTUFF)".
[20:01] <saste_> gnafu, lol, that's sick ;-)
[20:02] <saste_> michaelni, don't we use ffmpeg to generate vsynth/asynth?
[20:02] <saste_> how's that different?
[20:03] <michaelni> tests/audiogen.c tests/videogen.c
[20:03] <saste_> yes i see sorry
[20:05] <michaelni> the more similar existing things would be the regression tests where a file is encoded with ffmpeg and then decoded with ffmpeg
[20:31] <Mista_D> I'm looking at upping file system RW block size of FFmpeg. Want to test performance with various NFS/TCP frames. Do I modify it in libavformat/avio? Thank you.
[21:18] <CIA-15> ffmpeg: 03Stefano Sabatini 07master * rbbe9fe469a 10ffmpeg/libavformat/utils.c: 
[21:18] <CIA-15> ffmpeg: lavf/utils: remove loop on AVERROR(EAGAIN) in av_read_frame()
[21:18] <CIA-15> ffmpeg: The loop was introduced in 64d340c62ad5954c1a834df2d26057135e771774, and
[21:18] <CIA-15> ffmpeg: was likely breaking non blocking reads as it busy loops.
[23:06] <Daemon404> our old friend h264-conformance-cama2_vtc_b
[23:25] <CIA-15> ffmpeg: 03Mans Rullgard 07master * r0eebde07a9 10ffmpeg/libswresample/ (5 files in 2 dirs): 
[23:25] <CIA-15> ffmpeg: ARM: libswresample: NEON optimised flat float to s16 conversion
[23:25] <CIA-15> ffmpeg: Adapted to swr by: Michael Niedermayer <michaelni at gmx.at>
[23:25] <CIA-15> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[23:25] <CIA-15> ffmpeg: 03Michael Niedermayer 07master * r97599f8c6d 10ffmpeg/libswresample/ (audioconvert.c swresample.c): 
[23:25] <CIA-15> ffmpeg: swr: make sure the last data element is NULL so we can use it to detect the number of channels
[23:25] <CIA-15> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[23:25] <CIA-15> ffmpeg: 03Mans Rullgard 07master * r7e3208a087 10ffmpeg/libswresample/arm/ (audio_convert_init.c audio_convert_neon.S): 
[23:25] <CIA-15> ffmpeg: ARM: libswresample: NEON optimised generic fltp to s16 conversion
[23:25] <CIA-15> ffmpeg: Adapted to swr by: Michael Niedermayer <michaelni at gmx.at>
[23:25] <CIA-15> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[23:25] <CIA-15> ffmpeg: 03Mans Rullgard 07master * r5dc7363446 10ffmpeg/libswresample/arm/ (audio_convert_init.c audio_convert_neon.S): 
[23:25] <CIA-15> ffmpeg: ARM: libswresample: NEON optimised stereo fltp to s16 conversion
[23:25] <CIA-15> ffmpeg: Adaption to swr by: Michael Niedermayer <michaelni at gmx.at>
[23:25] <CIA-15> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[00:00] --- Tue Sep 25 2012