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

[burek]

[02:12] <cone-989> ffmpeg.git 03Reynaldo H. Verdejo Pinochet 07master:d67d4072390d: ffserver: tests, use new port/bindaddress config
[02:12] <cone-989> ffmpeg.git 03Reynaldo H. Verdejo Pinochet 07master:07bc24973b8c: ffserver: tests, use Metadata title in config
[02:29] <cone-989> ffmpeg.git 03Michael Niedermayer 07master:30f680ee0a27: avcodec/vc1dec: fix null pointer dereference
[03:05] <cone-989> ffmpeg.git 03Michael Niedermayer 07master:a2841d92c384: Revert "pnmenc: use bits_per_raw_sample"
[12:25] <cone-798> ffmpeg.git 03Anton Khirnov 07master:6ca11f7157d0: doc/APIchanges: fill in missing hashes and dates
[12:25] <cone-798> ffmpeg.git 03Michael Niedermayer 07master:f1b04f803eaf: Merge commit '6ca11f7157d0ffd11ea9a4211b04981b46dc75d6'
[12:35] <J_Darnley> ubitux: I've just seen your message from yesterday...
[12:37] <J_Darnley> It works fairly well for detecting which "video frame" should be a beat
[12:37] <J_Darnley> or should sow a beat.
[12:37] <J_Darnley> *show
[12:38] <J_Darnley> I have no idea how it works though
[12:38] <J_Darnley> It was and still is a lot of messy code.
[12:40] <J_Darnley> I haven't tried cleaning it up yet.
[12:40] <J_Darnley> I could spin it off into some skeleton of a filter so you can see it on its own.
[13:27] <cone-798> ffmpeg.git 03Anton Khirnov 07master:b263f8ffe759: lavf: add AVFormatContext.max_ts_probe
[13:27] <cone-798> ffmpeg.git 03Michael Niedermayer 07master:215db2935b06: Merge commit 'b263f8ffe7599d9cd27ec477a12700da8eb2790d'
[13:33] <cone-798> ffmpeg.git 03Rémi Denis-Courmont 07master:6ee1cb5740e7: libavformat: use MSG_NOSIGNAL when applicable
[13:33] <cone-798> ffmpeg.git 03Michael Niedermayer 07master:08a110ca871e: Merge commit '6ee1cb5740e7490151db7dcec7e20ceaf8a2fe1f'
[15:14] <cone-798> ffmpeg.git 03Michael Niedermayer 07master:d647ef0c8069: avcodec/mpegvideo_parser: consider vbv_delay in bitrate heuristic also for mpeg2
[15:59] <cone-798> ffmpeg.git 03Michael Niedermayer 07master:beaf86bd02e4: doc/APIchanges: fill in dates and hashes
[16:13] <cone-798> ffmpeg.git 03Michael Niedermayer 07master:52fca28c3bf5: avcodec/vorbisenc: use av_malloc(z)_array()
[16:13] <cone-798> ffmpeg.git 03Michael Niedermayer 07master:bb29896793bf: avutil/opencl: use av_malloc(z)_array()
[17:25] <wm4> so, many files have stuff in AVFormatContext.metadata which are not file tags at all, e.g. mp4 has crap like "compatible_brands"
[17:25] <wm4> do we need a way to separate real tags from additional metadata?
[17:26] <wm4> any suggestions? maybe a separate tags dict?
[17:35] <ubitux> wm4: add a special flag/category to AVDictionaryEntry?
[17:35] <ubitux> theree are a bunch of metadata with special meaning
[17:35] <nevcairiel> That seems like a better solution than a separate dict
[17:35] <ubitux> i can think of the mp4 stuff typically, or timecodes, or even lavfi frame metadata
[17:36] <ubitux> typically you don't want to store a "rotate" tag when converting from mp4 to mkv
[17:36] <ubitux> nor you would be interested in lavfi.xxx tags
[17:37] <ubitux> i would support such changes
[17:38] <wm4> I don't know, dict entries don't have flags yet, so that'd be weird
[17:38] <wm4> "lavfi.xxx tags"?
[17:39] <wm4> also, there was at least one user who was interested in "untranslated" tag names (lavf tries to rename format specific tags to generic names)
[17:49] <nevcairiel> wm4: BTW, NVIDIA has a special OpenGL extension for DX interop, but of course its NV specific and still marked experimental, despite being years old already
[17:49] <wm4> as expected
[17:49] <nevcairiel> http://developer.download.nvidia.com/opengl/specs/WGL_NV_DX_interop.txt
[17:51] <wm4> probably not generally useable (might be unstable, and is extra work since it won't work with other drivers)
[17:52] <nevcairiel> I'll never need it, but it's interesting non the less
[18:00] <ubitux> wm4: lavfi.xxx tags are AVFrame tags, they're not remuxed currently anyway
[18:00] <ubitux> but it could be better than this "lavfi." prefix
[18:01] <wm4> why not make tags side data!
[18:02] <ubitux> lol
[18:02] <nevcairiel> Well they kinda are anyway
[18:09] <durandal_1707> this: http://git.1f0.de/gitweb?p=ffmpeg.git;a=commit;h=b7c37a5541b8bf69ba173ad7269a4b19f3155e9a
[19:09] <cone-798> ffmpeg.git 03Vignesh Venkatasubramanian 07master:080acf7771e1: lavf/matroskadec: Ensure cues_end is initialized
[19:20] <kierank> ubitux: when is ffmpeg chocolate coming
[19:21] <kierank> libav have chocolate
[19:21] <kierank> and i thought the idea is to have ffmpeg a strict superset of libav
[19:22] <ubitux> i wouldn't mind not having food, trains & travel discussions all the time here :)
[19:22] <ubitux> i'm not into this commercial thing, ask someone else if you want such thing
[19:24] <Daemon404> kierank, bake a cake with libav chocolate
[19:24] <Daemon404> bam. superset.
[19:24] <kierank> i have started making zero noodles my food of choice
[19:24] <kierank> https://www.boots.com/en/Zero-Noodles-Original-200g_1469881/
[19:25] <kierank> bought the entire stock of bristol today
[19:25] <Daemon404> oic
[19:25] <Daemon404> i (we) only buy noodles from hong kong / china from the asian supermarket
[19:25] <Daemon404> and/or japan
[19:25] Action: Daemon404 has no choice in the matter
[19:25] <kierank> that packet of noodles is FOUR calories
[19:26] <wm4> huh, why would people buy food with no nutritional value...
[19:26] <kierank> as a base for food with nutritional value
[19:27] <Daemon404> ive mostly been cooking healthyish food lately
[19:27] <Daemon404> *mostly*
[19:44] <rcombs> so, I've been in an email chain with our CEO and a copyright and licensing lawyer
[19:44] <rcombs> and he believes that FDKAAC's license is GPL-compatible, because the patent licensing section is not part of the license, but instead a separate advisory
[19:45] <rcombs> so, that means that FDKAAC shouldn't have to be considered non-free
[19:46] <rcombs> if anyone would like details or to speak to him directly, feel free to PM or email me
[19:46] <j-b> https://github.com/mstorsjo/fdk-aac/blob/master/NOTICE
[19:46] <j-b> this is the license
[19:46] <j-b> "Software License for The Fraunhofer FDK AAC Codec Library for Android"
[19:47] <j-b> the whole file
[19:47] <j-b> not just one part
[19:47] <j-b> section 4 is the usual "No warranty clause"
[19:47] <j-b> and is found in all the FLOSS licences
[19:48] <rcombs> 'I see no issue under GPL here. The reference to patent licenses is advisory and not a limitation on use. In essence, it says, "you can get a license here if you want one [implicitly, if you don't, you are at your peril], but you may not need one because most Android hardware makers already have one that covers you."'
[19:48] <j-b> "You may use this FDK AAC Codec software or modifications thereto only for purposes that are authorized
[19:48] <j-b> by appropriate patent licenses."
[19:48] <j-b> "You may use .. only .."
[19:49] <j-b> [implicitly, if you don't, you are not allowed to use]
[19:50] <kierank> rcombs: the requirement to have a patent licence is an additional restriction under the gpl
[19:50] <rcombs> I'll get back to Chris with a copy of this conversation
[19:51] <j-b> I agree with kierank (as usual)
[19:52] <wm4> "It is patented but free to use as long as you use the openexr library."
[19:52] <wm4> what the shit
[19:52] <wm4> (OpenEXR)
[19:52] <JEEB> lol
[19:53] <Daemon404> for troll purposes, i should remind you guys i contacted the SFLC
[19:53] <Daemon404> and they said not-GPL-compatible
[19:53] <j-b> Daemon404: can you fwd the email?
[19:53] <j-b> please?
[19:53] <Daemon404> j-b, it is ages old, but i can find and fwd it to you
[19:53] <Daemon404> which email?
[19:53] <rcombs> Daemon404: also to me? at rodger at plexapp.com
[19:53] <Daemon404> jb at v.o?
[19:53] <j-b> Daemon404: yes
[19:53] <j-b> ah, you're from plex...
[19:54] <Daemon404> rcombs, ok.
[19:54] <j-b> that explains a lot...
[19:54] <wm4> trollol
[19:54] <Daemon404> j-b / rcombs -- are you OK with a bunch of .eml attachments for teh thread
[19:54] <Daemon404> its how tbird does it.
[19:54] <wm4> j-b: well he was a free open source spirit until recently
[19:54] <rcombs> Daemon404: sure
[19:54] <rcombs> this started because I asked our CEO to talk to Fraunhofer about relicensing FDKAAC under something GPL-compatible
[19:55] <Daemon404> gl;hf
[19:55] <rcombs> and he said he'd double-check with a licensing attorney about whether or not the existing license was compatible first
[19:55] <Daemon404> hmm which email addy did i use...
[19:55] <rcombs> which made me :rolleyes:, but figured it couldn't hurt
[19:56] <rcombs> so, I've told him your reply now (which I agree seems accurate, but I'm not a lawyer), and he'll either try to convince everyone you're wrong, or agree and then we'll go to Fraunhofer with money
[19:57] <wm4> isn't that what they want, Money
[19:57] <wm4> just use the lavc encoder
[19:57] <wm4> not like your users hear the difference
[19:57] <wm4> or why use aac at all
[19:57] <rcombs> wm4: we'd like fixed-point for some platforms
[19:57] <Daemon404> aha found it
[20:00] <Daemon404> j-b / rcombs - sent
[20:01] <rcombs> j-b: for the record, I came onboard a few months ago, and am trying to get us to build better relations with ffmpeg than we've historically had
[20:01] <Daemon404> kudos
[20:02] <j-b> you mean, stop exploiting open source for money and give almost nothing back?
[20:03] <wm4> is plex closed source shit?
[20:04] <rcombs> wm4: media server is open-source; it uses ffmpeg shared libs (under LGPL) and a full compiled modified ffmpeg binary (under GPL), with the source for both published
[20:04] <wm4> that's nice
[20:05] <rcombs> and I'm intending to push any bug fix we make from here on to upstream, and possibly some new work; our CTO is hesitant because he's afraid of helping competitors, but I think we'd be much better off having a good relationship with ffmpeg
[20:05] <kierank> lol this "helping competitor" argument
[20:05] <rcombs> kierank: yeah :\
[20:05] <j-b> exactly what I meant with above
[20:06] <j-b> Let's use open source, but please don't give anything back...
[20:06] <rcombs> Daemon404: huh, they pointed at the no-license-fee clause
[20:13] <Daemon404> eh dont ask me
[20:13] <llogan> rcombs: what are some of the modifications?
[20:15] <rcombs> llogan: we have a hack that enables ffmpeg to render inline ASS subtitles, a limited MPEG-DASH muxer (based on smoothstreaming), and various little compatibility tweaks on both input and output
[20:16] <llogan> you mean like the ass filter to make hardsubs (but without the need for standalone ass file)?
[20:16] <rcombs> e.g. if analysis fails to determine a video pixel format, we guess YUV420p because that's very common, rather than leaving it NONE and having a guaranteed failure; if the MOV timescale is very large, we actually reduce it instead of just warning
[20:16] <rcombs> llogan: right
[20:18] <rcombs> our MKV muxer writes the duration from the source file before it starts rather than an EBML void, so players know an approximate duration while we're transcoding
[20:18] <rcombs> the code for all this is available as a .tgz (and I've been trying to convince our CTO to just make the git repo public, but he really doesn't want to :( )
[20:19] Action: Daemon404 has a utility to determine what git hash tarbal ldrops are based on
[20:19] <rcombs> there are a few other little tweaks all over the place, some of which are Plex-specific (e.g. we log to the server via HTTP calls and throttle ourselves if the server says to)
[20:19] <Daemon404> more or less you otpimize for diff -urN | wc -l
[20:19] <Daemon404> find smallest #
[20:19] <rcombs> and there's some other stuff not yet released (and therefore not yet public), which I can tell you about when we launch
[20:20] <Daemon404> rcombs, it seems very dumb to keep it locked ep
[20:20] <Daemon404> up
[20:20] <rcombs> Daemon404: agreed
[20:20] <Daemon404> existign stuff i mena
[20:20] <wm4> but the competition
[20:20] <rcombs> Daemon404: well, I had the pleasure of doing the same before I was hired; it's easier than that
[20:20] <rcombs> Daemon404: there's a RELEASE file (or whatever it's called) in the tarball, and it's forked off that exact tag
[20:21] <rcombs> superpea: 'ello
[20:21] <Daemon404> rcombs, not all source drops are forked off tags
[20:21] <Daemon404> ;)
[20:21] <superpea> hey rcombs!
[20:21] <rcombs> this is superpea, a coworker
[20:22] <JEEB> Daemon404, I remember making a similar tool once
[20:22] <JEEB> lörs lärä
[20:22] <llogan> rcombs: thanks for the descriptions. looking forward to your contributions.
[20:22] <wm4> Daemon404, j-b: if you want that nobody can "steal" ffmpeg without giving back, why not switch to AGPL3?
[20:22] <Daemon404> trolls gonna trol
[20:22] <Daemon404> l
[20:22] <rcombs> wm4: because re-licensing software this large with this many contributors is impractical
[20:22] <Daemon404> dont tell j-b that
[20:23] <Daemon404> because he did just that
[20:23] <Daemon404> relicensed all of libvlc.
[20:23] <Daemon404> (more or less)
[20:25] <j-b> wm4: no, but I really dislike Plex and their lack of commitment
[20:25] <j-b> they are mostly only a ffmpeg-rewrapper
[20:25] <j-b> and they refuse to share anything
[20:26] <j-b> or are plain rude
[20:26] <j-b> Daemon404: of course, the usual BS about relicesing
[20:26] <Daemon404> that said i think AGPL is crap
[20:27] <j-b> not to add that, in the US, relicensing is 10x easier, because of copyright vs authors rights
[20:27] <wm4> the GNU licenses would be nicer if they were properly interoperable with each others
[20:27] <nevcairiel> AGPL makes stuff finally entirely corporate incompatible
[20:27] <JEEB> just switches one corporate to another
[20:27] <JEEB> the FSF corporate
[20:28] <nevcairiel> Back when I still did web development, I stumbled across a few java libraries dual licensed AGPL and $$$
[20:28] <JEEB> yup
[20:28] <nevcairiel> If you use them you have to put info on your website
[20:28] <nevcairiel> Like any company is ever going to do thay
[20:28] <nevcairiel> that*
[20:28] <Daemon404> some do
[20:29] <Daemon404> e.g. http://www.whatsapp.com/opensource/
[20:29] <Daemon404> and they sold for 16 billion :P
[20:29] <nevcairiel> Not sure how it would really work out when you use it for internal purposes only
[20:29] <nevcairiel> I mean, not like anyone would ever find out anyway
[20:30] <nevcairiel> Stuff like WhatsApp sells for the user base, and absolutely nothing else. :P
[20:30] <Daemon404> yep.
[20:32] <nevcairiel> Speaking of aac earlier, someone wake that guy and his mega trac ticket up again
[20:32] <JEEB> zat german dude IIRC
[20:32] <JEEB> and yeah, we def. want that stuff merged
[20:33] <JEEB> there's so much code written and it has become better :s
[20:35] <Daemon404> "still worse than LAME"
[20:35] Action: Daemon404 runs
[20:36] <nevcairiel> I've had some noisy clips where the aac encoder really produces terrible artifacts, but its much better with the patch
[20:36] <nevcairiel> I should just apply it
[20:36] <Daemon404> what do you even want with it?
[20:36] <Daemon404> you write decoding filters
[20:37] <Daemon404> bitstreaming?
[20:37] <nevcairiel> For work
[20:37] <Daemon404> oh ok.
[20:37] <nevcairiel> We have a live transcoder for streaming to mobile
[20:37] <Daemon404> hmm, can you not link fdk directly to your software>
[20:38] <nevcairiel> Then I would have to implement a special encoding path
[20:38] <Daemon404> figured that was the answer
[20:39] <nevcairiel> This license thing is stupid. I could use it separately, but if I use it inside FFmpeg it goes all bad
[20:39] <nevcairiel> Do androids decode ac3
[20:40] Action: nevcairiel wonders
[20:40] <nevcairiel> It opus in ts? d:
[20:40] <nevcairiel> Hey kierank, going to build opus in ts mixing as well? :)
[20:40] <JEEB> ac3 is only supported if the maker got a license
[20:40] <nevcairiel> muxing*
[20:40] <JEEB> and used the dolby binary
[20:41] <kepstin-laptop> only very recent versions of android do opus in the media framework :/
[20:41] <kierank> nevcairiel: not until people ar ehappy with the spec
[20:41] <kierank> are
[20:41] <nevcairiel> so, 2018 then?
[20:42] <j-b> btw, do we know people good around libavcodec looking for a job > 50k¬ ?
[20:42] <nevcairiel> kepstin-laptop: might still be nice as an option 
[20:47] <kierank> nevcairiel: the realistic answer is post-ibc
[20:47] <kierank> we can have a quick "is everyone happy session" at vdd
[20:49] <nevcairiel> I wouldn't really be able to use it in the next couple months anyway, I have a large project rewriting the whole encoding thing in the app lined up, but not immediately anyway
[20:50] <kierank> android doesn't support ac3 afaik
[20:50] <kierank> 7:37 PM <"Daemon404> hmm, can you not link fdk directly to your software> --> no it has a viral property
[20:50] <nevcairiel> And opus support would be a nice addition, if its viable by then (depending on support both in FFmpeg and Android)
[20:51] <kierank> vlc supports opus in android
[20:51] <kierank> I listen to it every day
[20:51] <j-b> opus > *
[20:51] <kierank> he-aacv2 is better
[20:51] <nevcairiel> We use the built-in media engine
[20:51] <kierank> but laaatency
[20:52] <nevcairiel> And the whole discussion started because we don't have a good aac encoder at hand, so.... ;)
[20:52] <kierank> use lame at 192kbps
[20:52] <kierank> i assume you have mp3 patents paid
[20:53] <nevcairiel> Can I shove that in a HLS TS stream?
[20:53] <kierank> oh surround sound and other stuff
[20:53] <kierank> yes
[20:53] <kierank> not sure if mp3 supports surround
[20:53] <nevcairiel> Stereo is fine for now
[20:54] <nevcairiel> Also, mp3 in ts is actually a thing? Don't think I've ever seen it
[20:54] <kierank> mp3 licensing for broadcast is expensive
[20:54] <kierank> afaik tat's why it's not used
[20:55] <nevcairiel> Android doesn't list it as a compatible combination, but who knows if it would be able to play that
[20:57] <kierank> apple says it is possible
[20:58] <nevcairiel> I shall just remember to try at some point
[20:59] <nevcairiel> With my usual luck, it works on nexus devices but fails on Samsung or Sony, like my last experiments with fragmented mov
[21:38] <Compn> Subject:	WebM DASH Manifest Test Files
[21:38] <Compn>  	Size:	5677870 bytes
[21:38] <Compn> in moderation queue. 5mb email
[21:42] <wm4> wat
[21:44] <gnafu> Seems legit.
[21:46] <wm4> right now I only see a 11kb mail
[21:53] <Compn> i wasnt sure i should approve sending 5mb to the entire list
[21:58] <wm4> what was it?
[21:58] <wm4> surely not 5 MB of XML?
[21:59] <jamrial> dash_video1.webm and dash_audio1.webm judging by the second patch contents
[22:08] <llogan> Compn: i rejected it with a notificaiton to provide links to the files.
[22:17] <JayBlanc> The other channel has sent me here. My question is, is cli ffmpeg supposed to have positive return values when there have been recoverable errors in decoding/encoding? A glance at ffmpeg.c shows it's set by a global variable, which seems like a bad idea.
[22:19] <kepstin-laptop> JayBlanc: it's configurable with a command-line option
[22:19] <JayBlanc> Which is?
[22:19] <kepstin-laptop> (it annoyed me a bit that the default was changed from previous versions tho; it used to ignore them prior to 2.2)
[22:20] <JEEB> err_detect ? I couldn't find the IRC logs for whatever I looked into months before
[22:20] <JEEB> all of the settings are defined @ http://ffmpeg.org/ffmpeg-all.html
[22:21] <kepstin-laptop> -max_error_rate
[22:21] <kepstin-laptop> set it to 1.0 to make it ignore all errors
[22:22] <JayBlanc> And its undocumented.
[22:22] <JEEB> I would guess err_detect is actually the one you want if you want to set a specific level
[22:22] <JEEB> not sure what -max_error_rate is
[22:22] <JEEB> esp. since it's not in the documentation
[22:23] <kepstin-laptop> shows up with a description in `ffmpeg -h`, but yeah, the docs aren't very good :/
[22:23] <JayBlanc> err_detect is something entiely different.
[22:24] <JEEB> well looking at explode and ignore_err
[22:24] <JEEB> it can be used to either set ffmpeg to either ignore all errors or explode on any :P
[22:25] <JayBlanc> A better default for -max_error_rate would be something above 0.
[22:27] <JayBlanc> It's actually useful if it works the way I think it works, but it needed to be fully documented so people who write scripts that depend on the return value knew about it.
[22:27] <JEEB> uhh, looking at that help message it really seems like a rather vague thing :P
[22:27] <kepstin-laptop> after my scripts failed for no good reason when switching to ffmpeg 2.2, I had to go look it up in the git history to figure it out :/
[22:27] <JEEB> as in, it will ignore a certain amount of errors percentage-wise
[22:28] <JEEB> which doesn't seem very good for me :P
[22:29] <JEEB> I wish one of the maintainers was here because I'm most definitely not really good with the command line side of things due to mostly poking lavf/lavc and swscale
[22:29] <JEEB> because I just can't help but to feel that -max_error_rate is something very unspecific :P
[22:30] <JEEB> as in, will not help you if you only want to ignore errors of a certain level
[22:30] <JayBlanc> Yeah, I don't quite understand how errors get quantified into that percentage.
[22:30] <JEEB> they don't
[22:30] <JEEB> at least looking at the help
[22:31] <JayBlanc> Percentage of frames? Percentage of time? Percentage of unicorns?
[22:31] <JEEB> of all messages/return values I would guess, but looking at the source code is most probably more useful
[22:32] <kepstin-laptop> given how different codecs handle this differently, I don't think the percentage thing would be useful unless you have a really well defined use case
[22:34] <JayBlanc> This patch seems to have gone in very quickly too. Less than a weeks discussion on changing a fundemntal way the CLI functions.
[22:35] <JayBlanc> Or perhaps a failure to check that the function is only applied when directed to be applied.
[22:35] <JayBlanc> ie, it defaults to -max_error_rate=0 when it should be defaulting to -max_error_rate=1
[22:36] <JEEB> and yeah, it seems to be as vague as I thought :P http://git.videolan.org/?p=ffmpeg.git;a=blobdiff;f=ffmpeg.c;h=d7bcb78cc0f7b0c5b4422fc3ffbb152e25935e50;hp=38a3bd0d024dc93f4b6ede533f52af79d0431047;hb=b6b9c150f06adc5a2feada116e9d8f3c3fba8b71;hpb=728bb910ec04ef7138a4089ca72398270210e11f
[22:40] <JEEB> also the default is 2.0/3 , just fyi :P
[22:42] <JayBlanc> Well, then the functions is basically just broken, because it's triggering on things that I would not consider over two thirds 'errored'.
[22:43] <JEEB> also that's so arbitrary that I genuinely would be looking for other things like the stuff I noted if I some levels of errors are wished to be ignored. That said, not all decoders or demuxers differentiate between these
[22:43] <JayBlanc> Oh... Unless it sees 'corrections' in streams that are *meant* to be corrected for packet loss, ie over-the-air TS streams, as "Errors".
[22:44] <JayBlanc> In which case if could well be declaring perfectly decodable TS streams as "having too many errors".
[22:44] <JEEB> well it should be telling you the values if you enable debug output with -v debug
[22:44] <JEEB> "%"PRIu64" frames successfully decoded, %"PRIu64" decoding errors\n"
[22:44] <kepstin-laptop> I was seeing it trigger on some poorly-encoded flash svc2 streams that still decoded without any visible issues :/
[22:45] <JayBlanc> Yeah, I'm thinking about filing an error on it to get it pulled.
[22:45] <JEEB> I'm pretty sure the issue could rather be in the stuff being noted as errors rather than the amount of errors in general :P
[22:46] <JEEB> stuff like err_detect and verbosity or similar sounds like what could be useful, but at this point I think I'll just go throw myself at the bed
[22:47] <JEEB> also I consider both the old and the new behavior of how that thing worked goddamn arbitrary :P
[22:48] <JEEB> anyways, your issue is something being seen as an error rather than having a random % be too low/high.
[22:58] <JayBlanc> kepstin-laptop: Do you still have that flash stream to use as an example? The only files I have that are examples are too huge to upload as samples.
[22:58] <kepstin-laptop> I have several hundreds of gb of them, the trick is finding one that shows the issue and which isn't private :)
[22:59] <kepstin-laptop> but I'll take a look
[22:59] <kepstin-laptop> logs look like
[22:59] <kepstin-laptop> [flashsv2 @ 0x120cda0] 0x0 invalid color depth 3
[23:01] <kepstin-laptop> (these are made by custom java code in the bigbluebutton screen sharing app, so I'm not super-confident in the encoder quality :)
[23:54] <Timothy_Gu> Does FFmpeg accept patented but non-copyrighted code?
[23:54] <wm4> I think ffmpeg pretty much does not care about patents
[23:55] <wm4> it had native mp3 decoders at a time where distros patched many programs to remove mp3 decoders...
[23:56] <Timothy_Gu> And also on a completely unrelated topic, do you need to check errors for avio_tell()
[23:56] <Timothy_Gu> ?
[23:57] <Timothy_Gu> tell() uses seek(), which returns errors, but is there a way for this limited use of avio_seek() to actually fail?
[23:58] <wm4> hm
[23:58] <wm4> it calla avio_seek
[23:58] <wm4> *calls
[23:58] <wm4> and that can return AVERROR
[23:58] <wm4> sol I guess check if the result is <0
[23:58] <wm4> oh I'm blind
[23:58] <wm4> (and you too)
[23:58] <wm4> avio_tell documents: * @return position or AVERROR.
[00:00] --- Tue Aug 26 2014