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

[burek]

[00:02:32 CEST] <jgb> who do i have to beg if i want to get this fixed: https://trac.ffmpeg.org/ticket/7912
[00:03:16 CEST] <BtbN> spamming on IRC will for sure make everyone very enthusiastic
[00:03:50 CEST] <jgb> btbn do you mean unenthusiastic
[00:04:23 CEST] <cone-841> ffmpeg 03Carl Eugen Hoyos 07master:e82a619c2a15: lavc/frame_thread_encoder: Do not memcpy() from NULL.
[00:07:03 CEST] <cone-841> ffmpeg 03Carl Eugen Hoyos 07master:ac457a3bc589: lavc/vc2enc_dwt: Avoid left-shifting a negative value.
[00:25:42 CEST] <jgb> i will pay $$$ to get this fixed:   https://trac.ffmpeg.org/ticket/7912
[00:26:40 CEST] <BtbN> So write it as bounty into the ticket and hope someone cares enough.
[00:27:00 CEST] <BtbN> spamming both channels here only gets people annoyed
[00:27:16 CEST] <jgb> btbn are you someone that is capable of fixing that?
[00:27:47 CEST] <BtbN> I have no idea what "that" even is. I only see you cross-spamming links on IRC.
[00:27:57 CEST] <jgb> https://trac.ffmpeg.org/ticket/7912
[00:28:06 CEST] <BtbN> Yes, I saw the link. A lot.
[00:28:10 CEST] <jgb> btbn are you someone that is capable of fixing that?
[00:28:17 CEST] <jgb> yes or no
[00:29:19 CEST] <jgb> it's simple yes or no question
[00:34:14 CEST] <kierank> jgb: write that in the ticket
[00:34:18 CEST] <kierank> say you will give $$$
[00:34:25 CEST] <jgb> kierank are you someone that is capable of fixing that?
[00:34:29 CEST] <kierank> no
[00:34:36 CEST] <kierank> but putting it in the ticket might find someone
[00:35:11 CEST] <jgb> kierank i see
[00:35:24 CEST] <jgb> kierank who do you think has most capable of fixing that
[00:35:31 CEST] <kierank> no idea
[00:35:39 CEST] <kierank> I don't use neckbeard subtitle formats
[00:35:39 CEST] <jgb> okay, thanks for the answer
[00:36:09 CEST] <jgb> i don't understand why btbn cannot answer a simple yes or question
[00:36:41 CEST] <kierank> he does not have to answer to you
[00:36:47 CEST] <kierank> he is a volunteer in his free time
[00:36:54 CEST] <BtbN> Because BtbN went to the toilet.
[00:36:54 CEST] <kierank> (or she)
[00:37:14 CEST] <jgb> btbn oh sorry,  so what is the answer then
[00:37:29 CEST] <BtbN> And I still haven't looked at the ticket. I don't have time to fix stuff anyway at the moment.
[00:37:46 CEST] <BtbN> But seriously, put a bounty into the ticket, spamming IRC will only get people annoyed enough to not care out of spite.
[00:38:34 CEST] <jgb> mpv can playback the sample.mkv  fine  which relies on ffmpeg
[00:38:54 CEST] <jgb> but ffmpeg has problems;  which i don't understand
[00:39:32 CEST] <BtbN> So, that ticket looks more like an issue with the srt muxer, than with anything else. I doubt mpv remuxed the subs to srt.
[00:39:59 CEST] <jgb> mpv displays subtitle at correct times
[00:40:30 CEST] <BtbN> Yes, so? Why would it need to invoke the srt muxer/encoder for that?
[00:41:41 CEST] <jgb> then what would it invoke?
[00:42:09 CEST] <BtbN> Nothing, it just "decodes" the subtitles and displays them.
[00:42:20 CEST] <jgb> i see
[00:43:07 CEST] <jgb> why can't  "ffmpeg -f lavfi -i movie=SrG.mkv[out+subcc] out.srt"   just  decode the subtitle and display them
[00:43:37 CEST] <BtbN> Because you're telling it to encode to srt.
[00:44:00 CEST] <jgb> i see
[00:44:34 CEST] <jgb> so bug must be in the "encoding to srt" part? you are saying
[00:45:03 CEST] <BtbN> That's literally what that ticket is about
[00:45:33 CEST] <jgb> btbn sounds like you are someone capable of fixing this
[00:45:50 CEST] <BtbN> Because I'm able to read a very short ticket?
[00:46:55 CEST] <BtbN> I have no clue about the srt muxer. Post the bounty on the ticket and see if it motivates anyone.
[00:47:35 CEST] <jgb> btbn okay thanks for the help
[02:08:02 CEST] <cone-841> ffmpeg 03Carl Eugen Hoyos 07master:2828f5b0d8e4: lavc/r210enc: Fix undefined behaviour encoding r10k.
[02:19:11 CEST] <philipl> Why not use mkvextract?
[02:19:49 CEST] <jgb> philipl  that works even less
[02:23:01 CEST] <jgb> philipl https://gitlab.com/mbunkus/mkvtoolnix/issues/2602
[02:25:51 CEST] <nevcairiel> CC are not a track in the container (ie. MKV), which is why its unlikely that any such demuxer supports it
[02:27:01 CEST] <nevcairiel> CC is a horrible format, and noone likes working with it, so don't expect any enthusiasm to fix such issues on any side
[02:27:56 CEST] <jgb> nevcairiel then why does  ffmpeg -f lavfi -i movie=SrG.mkv[out+subcc] out.srt  work "partially"
[02:28:17 CEST] <jgb> not fully obviously
[02:28:48 CEST] <nevcairiel> because that decodes the entire video to find the CC data, its ugly and slow, but its possible because ffmpeg also has decoders, and not just a demuxer
[02:28:51 CEST] <mkver> Because lavfi doesn't set the correct timebase, which means it defaults to the 90kHz clock of mpeg.
[02:29:08 CEST] <mkver> This is wrong by a factor of 90 (for your file).
[02:29:54 CEST] <jgb> mkver no it display all the subtitle in the first 10 seconds
[02:30:30 CEST] <nicolas17> how long is the video?
[02:30:34 CEST] <mkver> Because the timebase is wrong by a factor of 90.
[02:31:48 CEST] <mkver> 5:02. If you multiply all the srt's timestamps and durations by 90, it ends at 4:58.89
[02:33:03 CEST] <jgb> nicolas  5min 2 seconds  but it displays all the subtitles in first 4 seconds
[02:33:46 CEST] <jgb> it ends at 4:58.89??  huh
[02:33:50 CEST] <jgb> it displays all the subtitles in first 4 seconds
[02:34:18 CEST] <mkver> IF you multiply all the timestamps (start+end) by a factor of 90...
[02:34:23 CEST] <nicolas17> 5 minutes / 90 = 3.3 seconds
[02:34:37 CEST] <nevcairiel> so presumably calling avpriv_set_pts_info in create_subcc_streams then should fix it?
[02:34:56 CEST] <jgb> nicolas17 wow you are right
[02:35:11 CEST] <mkver> You of course need to know the correct timebase (the one from the actual source stream).
[02:35:42 CEST] <nevcairiel> thats the same as the video stream of course, since thats the timestamps it gets from the sidedata
[02:36:08 CEST] <mkver> Yes.
[02:37:12 CEST] <jgb> mkver how do i get rid of /90 
[02:37:22 CEST] <jgb> that ffmpeg likes to do
[02:37:49 CEST] <jgb> 146
[02:37:49 CEST] <jgb> 00:00:03,308 --> 00:00:03,321
[02:37:49 CEST] <jgb> <font face="Monospace">{\an7}\h\h\hI cant help it.
[02:38:15 CEST] <jgb> that's the last srt line
[02:38:50 CEST] <nevcairiel> so possibly something like this https://pastebin.com/0KCV7m7K .. entirely untested
[02:38:51 CEST] <mkver> You could simply use e.g. MKVToolNix to stretch the subtitles by a factor of 90. Or you could use SubtitleEdit for the job.
[02:41:17 CEST] <jgb> nevcairiel can you test it please:  video sample is:  https://x0.at/SrG.mkv
[02:41:53 CEST] <nevcairiel> its almost 3am and i'm going to sleep now
[02:42:32 CEST] <mkver> Good night!
[02:44:12 CEST] <jgb> mkver  wow it worked with mkvtoolnix
[02:44:22 CEST] <jgb> but it uses mks ; some weird format
[02:44:32 CEST] <mkver> It is a Matroska file.
[02:44:35 CEST] <nevcairiel> mks is just a mkv with only a subtitle in it
[02:44:49 CEST] <jgb> i want srt format
[02:44:58 CEST] <mkver> Use mkvextract on the mks.
[02:45:11 CEST] <mkver> Or ffmpeg or SubtitleEdit.
[02:45:51 CEST] <jgb> mkver wow you are very smart: how did you know about factor of 90
[02:48:52 CEST] <mkver> This was my initial guess: cc data usually lives in containers with a 90kHz clock; Matroska usually uses a 1kHz clock. Given that the timestamps are monotonically increasing and given that this procedure usually works, I guessed that there is a hardcoded timebase of 90kHz somewhere.
[02:49:23 CEST] <mkver> So I looked if the subtitles streched by a factor of 90 fitted the video and they did.
[02:51:52 CEST] <jgb> this must be simple fix then
[02:51:53 CEST] <nevcairiel> 90khz is the default timebase if none is set, so that makes sense
[02:53:32 CEST] <Compnno> jgb, does mplayer -dumpsub options work at all ? :D
[02:53:40 CEST] <Compnno> if its cc , probably not ;D
[02:53:56 CEST] <jgb> compnno not sure, i don't use mplayer
[02:54:06 CEST] <nevcairiel> anyhow someone try my patch if you want, i think it might solve it, otherwise maybe I remember tomorrow to try it
[02:54:37 CEST] <mkver> nevcairiel: Your patch sets the wraparound bits to 64; couldn't this break mpegts input?
[02:55:06 CEST] <nevcairiel> thats irrelevant at that point
[02:55:14 CEST] <nevcairiel> its also the exact same thing thats done for the video stream itself
[02:55:28 CEST] <nevcairiel> i litereally copied the timebase stuff from one function further down
[02:56:08 CEST] <mkver> Ok, I see.
[02:56:58 CEST] <Compnno> nevcairiel,  are you missing a ) or am i blind
[02:58:04 CEST] <Compnno> oh wow that text disappeared , my bad it was a font problem
[02:58:11 CEST] <Compnno> firefox what are you doing
[03:11:50 CEST] <mkver> Btw: The newest version of ccextractor can directly extract cc tracks of videos in Matroska.
[03:24:27 CEST] <jgb> that is horrible program
[03:37:31 CEST] <jgb> mkver  ffmpeg is creating  <font face="Monospace"> </font>  on every line
[03:37:37 CEST] <jgb> how do i remove this
[03:48:09 CEST] <mkver> You can use SubtitleEdit: Select all the subtitles, right click on them and use "Normal (Remove formatting)"
[03:52:13 CEST] <jgb> wow thanks, you are so smart
[04:55:51 CEST] <nicolas17> libx264 defaults to crf 23, is that set by ffmpeg or by libx264?
[04:56:41 CEST] <nicolas17> looking at libx264.c it seems the crf defaults to -1 so I'm *guessing* the libx264 library turns that into 23
[12:04:21 CEST] <durandal_1707> test test
[12:08:50 CEST] <cone-364> ffmpeg 03Thilo Borgmann 07master:33186028fcf7: MAINTAINERS: Add my GnuPG fingerprint.
[13:22:43 CEST] <durandal_1707> michaelni: whats needed to be on security ml?
[14:41:17 CEST] <kierank> michaelni: just put durandal_1707 on the security ml
[14:41:20 CEST] <kierank> stop blocking things
[14:41:43 CEST] <kierank> nobody blocked you like this when you got access
[15:33:19 CEST] <Chagall> what do I need to do to assign a version to a patch set?
[15:33:19 CEST] <Chagall> generate a patch on top of another?
[15:42:58 CEST] <jdarnley> Chagall: there's an option to give to format-patch or send-email
[15:56:16 CEST] <Chagall> I'm setting in-reply-to but it does not seem to set a version
[15:59:02 CEST] <Chagall> I guess this one is unrelated but I couldn't find anything else about setting a version in the format-patch or send-email docs
[16:00:38 CEST] <jamrial> Chagall: i think you just format-pach them, then use a text editor
[16:03:08 CEST] <Chagall> okay
[16:03:53 CEST] <jdarnley> -v <n>, --reroll-count=<n> Mark the series as the <n>-th iteration of the topic.
[16:07:23 CEST] <Chagall> thanks... I was ctrl+fing version
[16:24:04 CEST] <jdarnley> I was too at first
[16:53:32 CEST] <cone-625> ffmpeg 03Limin Wang 07master:391b67fcb58f: lavc/videotoolboxenc: add hdr10, linear, hlg color transfer function for videotoolboxenc
[16:53:32 CEST] <cone-625> ffmpeg 03Limin Wang 07master:1ee863a7b05a: lavc/videotoolboxenc: make transfer_fnc initialized for unsupport function
[18:35:19 CEST] <durandal_1707> ubitux: do you still read gmail mails?
[18:37:21 CEST] <cehoyos> jamrial, michaelni: No comment from me on vbv_delay
[18:47:20 CEST] <durandal_1707> cehoyos: did we ever met? and where?
[18:47:39 CEST] <cehoyos> I don't think so but who knows;-)
[18:48:34 CEST] <durandal_1707> if you never was in croatia, then we never met
[18:49:15 CEST] <cehoyos> I was at the airport in Zagred several times (always in green) and as a child I drove to Bosnia once
[18:50:19 CEST] <kierank> cehoyos: i thought you said you met paul
[18:50:36 CEST] <cehoyos> No, I don't think so
[18:51:27 CEST] <cehoyos> I should really visit Rijeka at some point though
[19:07:09 CEST] <ubitux> durandal_1707: nope
[19:09:58 CEST] <durandal_1707> than whats mail to contact you?
[19:16:19 CEST] <cone-625> ffmpeg 03Michael Niedermayer 07master:da93e2b14218: avcodec/aacdec_template: fix integer overflow in imdct_and_windowing()
[19:16:20 CEST] <cone-625> ffmpeg 03Michael Niedermayer 07master:b153ba1c2e03: avcodec/vc1_block: fix invalid shift in vc1_decode_p_mb()
[19:16:21 CEST] <cone-625> ffmpeg 03Michael Niedermayer 07master:c9415e815a99: avcodec/vc1_block: Fix invalid shifts in vc1_decode_i_blocks()
[19:16:22 CEST] <cone-625> ffmpeg 03Michael Niedermayer 07master:70432eac0b51: avcodec/pngdec: consider chunk size in minimal size check
[19:16:23 CEST] <cone-625> ffmpeg 03Michael Niedermayer 07master:02346292a334: avcodec/alsdec: fix mantisse shift
[19:16:24 CEST] <cone-625> ffmpeg 03Michael Niedermayer 07master:ce652324062a: avcodec/alsdec: Fix integer overflow of raw_samples in decode_blocks()
[19:16:25 CEST] <cone-625> ffmpeg 03Michael Niedermayer 07master:fad3ec89b7a6: avcodec/alsdec: Fix integer overflows of raw_samples in decode_var_block_data()
[19:16:26 CEST] <cone-625> ffmpeg 03Michael Niedermayer 07master:e8bb949ade40: avcodec/mpc8: Fix 32bit mask/enum
[19:16:27 CEST] <cone-625> ffmpeg 03Michael Niedermayer 07master:52b564ef1323: avformat/vividas: Fix infinite loop in header parser
[19:16:28 CEST] <cone-625> ffmpeg 03Michael Niedermayer 07master:1d72b5d2d522: avformat/vividas: Fix another infinite loop
[19:16:30 CEST] <cone-625> ffmpeg 03Michael Niedermayer 07master:9cd1e939cf26: avcodec/dds: Use ff_set_dimensions()
[19:16:31 CEST] <cone-625> ffmpeg 03Michael Niedermayer 07master:1fedba3c350a: avcodec/tiff: Enforce increasing offsets
[19:16:32 CEST] <cone-625> ffmpeg 03Michael Niedermayer 07master:950a21e83c74: avcodec/scpr: Use av_memcpy_backptr() in type 17 and 33
[19:16:33 CEST] <cone-625> ffmpeg 03Michael Niedermayer 07master:da8936969fe6: avcodec/hevc_refs: Optimize 16bit generate_missing_ref()
[19:20:24 CEST] <ubitux> durandal_1707: the latest one that pops up in the git history
[20:03:04 CEST] <tmm1> jkqxz: if the rc params being sent to libva are the same, do you have any other hunches on what might be different since ffmpeg 4.1 that would cause vbr not to work on some chips
[20:12:00 CEST] <thardin> what is with these terrible hacks in ff_read_riff_info()
[20:21:24 CEST] <thardin> postel's principle is a plague on computing
[20:57:06 CEST] <durandal_1707> thardin: what about hacks?
[20:58:29 CEST] <durandal_1707> michaelni: why are you ignoring my requests?
[21:04:52 CEST] <thardin> durandal_1707: the avio_seek() thing in there for one. it's not covered by FATE, there's no explanation for it
[21:08:03 CEST] <thardin> it got added in a merge commit
[21:09:53 CEST] <thardin> it's not a huge deal of course, it's just that I find lavf is an excellent example of the "shotgun parser" anti-pattern
[21:11:49 CEST] <thardin> hence all these fuzz fixes
[21:21:21 CEST] <thardin> background: I've been playing around with parser combinators recently (https://github.com/UpstandingHackers/hammer) and gave writing a RIFF WAVE parser a shot
[21:22:14 CEST] <thardin> after which it became abundantly clear why getting different multimedia software to cooperate is such a huge mess
[21:44:49 CEST] <durandal_1707> pm me if i missed reply
[21:57:05 CEST] <durandal_1707> pm if you are just bored
[22:03:24 CEST] <Lynne> working on mlp got you bored?
[22:03:28 CEST] <durandal_1707> anybody good with fractals math?
[22:03:48 CEST] <durandal_1707> mlp is history nobody use
[22:05:53 CEST] <durandal_1707> i want to zoom and pan inside sierpinski carpet
[22:06:12 CEST] <durandal_1707> writing new vsrc  filter
[22:06:44 CEST] <durandal_1707> mlp need to  wait until im back on linux
[22:11:25 CEST] <durandal_1707> i need your prompt reply
[22:23:36 CEST] <cehoyos> thardin: Ticket 1821
[22:26:50 CEST] <durandal_1707> what about it?
[22:28:06 CEST] <cehoyos> What about what?
[22:28:56 CEST] <durandal_1707> what about what about what about that ticket?
[22:33:41 CEST] <cehoyos> Tomas asked about samples and explanation for a particular line of code, both are in ticket 1821
[22:34:05 CEST] <thardin> cehoyos: yet another case of being accomodating to broken encoders instead of making them fix their shit
[22:34:40 CEST] <cehoyos> You misunderstand: FFmpeg is not a file validator, it aims to demuxer / decode everything that's in the wild
[22:35:41 CEST] <thardin> I know
[22:35:57 CEST] <cehoyos> It should also aim to fix regressions, sadly that's a little out-of-style nowadays;-(
[22:36:27 CEST] <thardin> maybe one way to look at it is ffmpeg encodes all the ways in which other programs are broken
[22:36:52 CEST] <BtbN> no, it should encode as correct as it possibly can
[22:37:02 CEST] <BtbN> And be lenient while decoding
[22:37:38 CEST] <thardin> this is postel's principle again. it's wrong
[22:38:23 CEST] <durandal_1707> this vc++ 2015 line should be removed
[22:38:28 CEST] <thardin> being lenient creates ever-increasing make-work
[22:38:44 CEST] <BtbN> Not being lenient will break a ton of files
[22:38:47 CEST] <thardin> partly because it's determining whether two decoders do the same thing is undecidable 
[22:38:56 CEST] <thardin> -it's
[22:40:10 CEST] <durandal_1707> please close useless bug reports like one above
[22:40:40 CEST] <thardin> I just have this nagging feeling that a huge class of problems will arise due to two or more multimedia capable programs having different opinions of what a given file *is*
[22:41:15 CEST] <thardin> a bit like how different URI decoder implementations cause endless security problems
[22:41:24 CEST] <durandal_1707> there is code to check for strict compliance
[22:41:42 CEST] <BtbN> Being lenient about what a parser accepts does not mean leaving security holes
[22:41:51 CEST] <BtbN> obviously leniency ends where it would leave security issues...
[22:42:17 CEST] <thardin> I disagree. lenience often makes parsers harder to understand
[22:42:20 CEST] <BtbN> Things get fun when the spec requires you to have a security issue to be compliant
[22:42:22 CEST] <cehoyos> thardin: I wonder if I understand you correctly - are you talking about the file that starts with a jpg image and then becomes an mp3 audio file?
[22:42:42 CEST] <thardin> cehoyos: that could be one issue. that's sadly not really solvable
[22:42:49 CEST] <BtbN> ffmpeg aims to be real-world useable, not to the book following standards.
[22:42:59 CEST] <cehoyos> Because for 99% of the samples, I believe there is no doubt what they are, the remaining ones have no "correct" solution, whatever is done can be useful (ex falso quod libet)
[22:43:02 CEST] <BtbN> And there are _a lot_ of broken files out there people want to play
[22:43:26 CEST] <thardin> indeed
[22:48:26 CEST] <thardin> one issue is that a lot of things end up being cargo culted, especially when not in FATE
[22:49:48 CEST] <durandal_1707> really. post examples.
[22:50:50 CEST] <BtbN> There once were a bunch of people wo said similar things, and started writing new parsers in rust. Their stuff ended up being several magnitudes slower. But they sure were correct and safe.
[22:52:17 CEST] <durandal_1707> rust is almost fast as C
[22:52:35 CEST] <BtbN> It is, rust was not what made it slow.
[22:53:03 CEST] <durandal_1707> then what was it?
[22:53:23 CEST] <BtbN> It being a 100% strict implementation with implicit consistency checks everywhere
[22:53:59 CEST] <BtbN> I think it was a h264 parser they re-implemented or something. And it was almost unable to keep up in real time.
[22:54:07 CEST] <durandal_1707> ugh
[22:54:46 CEST] <thardin> you can make that stuff cast though, if you use the right tools
[22:54:49 CEST] <BtbN> They wrote a blog-post about their findings somewhere on Mozillas pages
[22:54:51 CEST] <thardin> s/cast/fast/
[22:55:23 CEST] <BtbN> So then you make a safe implementation, and start introducing hacks to make it fast. Fantastic.
[22:55:32 CEST] <BtbN> Same thing, just backwards.
[22:55:53 CEST] <thardin> no. you can for example generate a correct implementation that compiles to a fast one
[22:56:46 CEST] <thardin> there's no need for paranoid checks if you know everything is correct
[22:57:00 CEST] <BtbN> How do you know everything is correct if you don't check everything?
[22:57:36 CEST] <durandal_1707> lol
[22:58:11 CEST] <thardin> that entirely depends. you don't need array bounds checks if your tooling checks all the way through that nothing can write out of bounds
[22:58:28 CEST] <thardin> then your code is fast, and can't crash
[22:58:35 CEST] <thardin> just as an example
[22:58:53 CEST] <BtbN> Sounds like something that doesn't work in reality.
[22:59:32 CEST] <thardin> it does. I have some embedded code that works exactly that way
[23:00:04 CEST] <BtbN> If you're parsing a potentially malicious file, you can't just assume stuff is just right. You need to check everything that can cause harm.
[23:00:21 CEST] <thardin> yes, and reject or otherwise deal with such files. that will always be the case
[23:00:30 CEST] <thardin> unless you want exploits of course
[23:00:39 CEST] <BtbN> So we do need the checks after all.
[23:01:13 CEST] <thardin> of course. but you can be very specific about what checks are needed
[23:01:40 CEST] <BtbN> That's what the current code is trying to do. And clearly doing that is hard to get 100% correct.
[23:01:48 CEST] <thardin> yep
[23:02:17 CEST] <thardin> I have about 1200 lines of verified code in one project
[23:02:37 CEST] <durandal_1707> verified how?
[23:03:00 CEST] <thardin> frama-c, and related backends (why3, coq, alt-ergo etc.)
[23:04:30 CEST] <thardin> that's a bit extreme tho, since the amount of code I'm able to produce is in the 10s of lines per day
[23:04:33 CEST] <cehoyos> https://ffmpeg.zeranoe.com/forum/viewtopic.php?f=7&t=7413 Does anybody know what this is about?
[23:06:35 CEST] <thardin> the trick is finding a sweet spot. it's no use if you end up being entirely unproductive
[23:07:15 CEST] <BtbN> fuzzing seems to be pretty effective at finding a bunch of weird edge cases nobody ever thought about
[23:07:30 CEST] <thardin> yeah fuzzing is great. afl especially
[23:07:42 CEST] <thardin> but it's also a huge hack
[23:08:35 CEST] <durandal_1707> cehoyos: http://ffmpeg.org/ffmpeg-codecs.html#libtwolame
[23:08:35 CEST] <thardin> I've been meaning to write a blog post comparing some of these methods. cost vs benefit. if formal verification was cheap enough it'd be ideal
[23:09:07 CEST] <thardin> it's only recently become useful enough to produce code at the reta of tens of lines per day rather than 1-2 lines per day
[23:09:49 CEST] <cehoyos> Bitstream peak data == energy level? Don't we also need this in the native encoder?
[23:10:16 CEST] <durandal_1707> useless stuff
[23:12:41 CEST] <cehoyos> The user seemed to indicate that the files don't completely work in some editors without it
[23:12:56 CEST] <cehoyos> But do you know if bitstream peak data and energy level are the same thing?
[23:13:19 CEST] <durandal_1707> ask  authors   of audition
[23:13:52 CEST] <BtbN> it's probably some hack to allow audio editors to show a peek meter without decoding
[23:18:26 CEST] <cehoyos> It appears more like a part of the mp2 specification than a hack...
[23:19:44 CEST] <durandal_1707> google is your friend
[23:20:46 CEST] <durandal_1707> how fuzzing can be huge hack? nonsense
[23:26:34 CEST] <thardin> not fuzzing itself, but the fact that we need to use it
[23:27:39 CEST] <thardin> we are extremely poor in how much we can reason about our code
[23:27:44 CEST] <BtbN> feel free to start a rewrite from scatch with validated code.
[23:27:51 CEST] <thardin> static analysis helps a bit, but only so much
[23:28:44 CEST] <thardin> BtbN: I've done some experiments in that direction, but it's.. slow-going. the parser combiner approach seems like it gives better returns
[23:31:14 CEST] <thardin> and one can just put ffmpeg inside a vm as a way to deal with untrusted input
[23:31:44 CEST] <BtbN> ...
[23:31:51 CEST] <Compnno> i still say with enough input we can assert everything
[23:32:01 CEST] <Compnno> e.g. youtube or facebook sample size
[23:32:10 CEST] <Compnno> then sandbox the assert fails
[23:33:01 CEST] <Compnno> an avi header, for example should almost always fall within a known range...
[23:41:57 CEST] <Compnno> of course the code would get ugly. would need a way to organize a ton of assertion values
[23:42:03 CEST] <cone-574> ffmpeg 03Marton Balint 07master:686755f02b02: avcodec/encode: only allow undersized audio frames if they are the last
[23:43:59 CEST] <cone-574> ffmpeg 03Carl Eugen Hoyos 07master:ea56af889560: lavc/zmbvenc: Do not left-shift negative values.
[00:00:00 CEST] --- Mon Aug 12 2019