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

[burek]

[00:03:34 CEST] Action: vlt wonders what phrase exactly caused JEEB to think of windows
[00:04:28 CEST] <JEEB> those intel things IIRC had window on them as they were tablets
[00:05:22 CEST] <vlt> JEEB: "-tune fastdecode" seems to work great so far. Without having measured yet: Does that increase the file size or affect the quality in any way?
[00:05:39 CEST] <JEEB> it does disable features which lower compressibility, yes
[00:05:51 CEST] <JEEB> stuff like CABAC and in-loop deblocking, if I recall correctly
[00:06:31 CEST] <PureTryOut[m]> hey guys, ffmpeg segfaults for me when trying to use an file from sftp (ssh) as input. turning on verbose logging doesn't show any interesting errors or warnings...
[00:06:53 CEST] <vlt> JEEB: I see, thanks. As I said before: In this situation I dont care for file size (as long as the tablet is able to read the data).
[00:07:06 CEST] <vlt> (fast enough)
[00:07:34 CEST] <JEEB> yea, it only starts becoming a problem when the speed of handling those bits is more than how long it would take to decompress the CABAC'd data
[01:41:52 CEST] <SpeakerToMeat> Is there any way to use ff to convert a single image to a piece of video x seconds long with a fade in and fade out?
[01:42:48 CEST] <JEEB> yes, but don't ask me for the filter chain
[01:43:09 CEST] <SpeakerToMeat> ha filter chains are my biggest boogie man
[01:46:02 CEST] <SpeakerToMeat> In IT we've had stuff like guie to regexp and gui to sql for a while, maybe I should try to do a gui to ff vf chain someday
[01:51:06 CEST] <JEEB> SpeakerToMeat: I think someone tried that for the previewing. you could look at for example vapoursynth editor for an example of how such things were done for other things
[01:51:18 CEST] <SpeakerToMeat> I always forget this, but what is the way to set an input image collection's native fps? seems not to be -r before .i
[01:51:42 CEST] <JEEB> I think the image2 "demuxer" had its own framerate AVOption
[01:51:55 CEST] <JEEB> there IIRC was a thing in ffmpeg.c that would let you list the AVOptions for a specific module
[01:52:17 CEST] <SpeakerToMeat> Hmm I could swear it was a "simple" ffmpeg option
[01:52:18 CEST] <c_14> ffmpeg -f image2 -framerate 1/duration -i image -vf fps=30,fade=in:d=1,fade=out:st=duration-1:d=1
[01:52:24 CEST] <c_14> something like that
[01:52:45 CEST] <JEEB> framerate most definitely was an AVOption
[01:52:52 CEST] <c_14> and it's `ffmpeg -h demuxer=image2'
[01:52:56 CEST] <JEEB> ah, thank you
[01:53:22 CEST] <JEEB> so that framerate goes before -i
[01:53:26 CEST] <JEEB> as it's a demuxer option
[01:53:31 CEST] <SpeakerToMeat> I could swear I didn't have to use image2
[01:53:41 CEST] <JEEB> most likely you didn't :P
[01:53:48 CEST] <c_14> defaults to image2 for images, I like forcing it
[01:54:06 CEST] <JEEB> I mean, I bet you could just ingest a single image and make a video filter output out of it
[01:54:27 CEST] <c_14> probably
[01:55:03 CEST] <SpeakerToMeat> ah iot was just -framerate I think
[01:55:21 CEST] <SpeakerToMeat> hahahaha bingo
[01:55:57 CEST] <SpeakerToMeat> ffmpeg -framerate 24 -i logo.tiff -t 4 -vf "fade=in:0:12,fade=out:83:12" dir/my_good_logo-%06d.dpx
[01:56:03 CEST] <SpeakerToMeat> c_14: thank you
[01:56:20 CEST] <JEEB> yes, framerate is an image2 AVOption
[01:56:33 CEST] <JEEB> and that most likely as he said went for the image2 "meta" demuxer
[01:56:39 CEST] <SpeakerToMeat> Yep
[01:56:42 CEST] <SpeakerToMeat> So it's auto selected
[01:56:58 CEST] <SpeakerToMeat> and its options are listed in the demuxer's help like c_14 said
[01:57:15 CEST] <JEEB> but yea, what I mean is if you use any other demuxer those options will not necessarily be available
[01:57:26 CEST] <JEEB> so they're not "ffmpeg.c options" or "global options"
[01:57:36 CEST] <JEEB> global options are generally stuff that goes into AVCodecContext
[01:57:45 CEST] <JEEB> like what -r sets, the poor bastard
[01:59:02 CEST] <SpeakerToMeat> poor bastard
[02:05:02 CEST] <Djfe> Hi, where should I report shareware that contains ffmpeg and mplayer without any mentioning of it? (nor license nor source code)
[02:05:19 CEST] <c_14> open a ticket on trac
[02:05:33 CEST] <Djfe> ok thx will do
[02:09:25 CEST] <SpeakerToMeat> c_14: I've been out of the loop, is each project still fighting gpl violations, or is there a foundation doign this now?
[02:09:58 CEST] <c_14> mostly project-by-project basis
[02:10:08 CEST] <SpeakerToMeat> nod
[02:10:18 CEST] <c_14> I think the FSF or Linux Foundation has an umbrella over a couple of projects
[02:15:47 CEST] <iive> ffmpeg used to have a layer that handled most of the violations, he specialised in that.
[02:15:47 CEST] <Djfe> but they can only represent the projects and not fight without their consent, right?
[02:16:14 CEST] <iive> unfortunately this has halted with the fork
[02:16:35 CEST] <Djfe> Done https://trac.ffmpeg.org/ticket/7197
[02:16:42 CEST] <c_14> Every person with a "reasonable" amount of code in ffmpeg is allowed to "deal with" (L)GPL violations
[02:17:01 CEST] <c_14> as pertaining to the parts of code they authored
[02:17:35 CEST] <iive> yes, but it also means that he represents only himself
[02:17:48 CEST] <c_14> yeah
[02:17:52 CEST] <iive> not the project.
[02:18:35 CEST] <c_14> If you wanted to represent the project you'd probably need a vote from the active members
[02:18:37 CEST] <iive> the layer had "authorization" from the most active developers for the most of the project.
[02:18:53 CEST] <Djfe> good to know :)
[02:19:12 CEST] <Djfe> lol https://i.imgur.com/0B3OC0C.png (I tried to attach their eula.pdf to the trac ticket)
[02:21:45 CEST] <SpeakerToMeat> Post a ticket on tract about trac's captcha not working ;)
[02:24:45 CEST] <Djfe> ok https://trac.ffmpeg.org/ticket/7198
[02:27:21 CEST] <SpeakerToMeat> :)
[02:29:40 CEST] <klaxa> Djfe: in the User_Guide_win.pdf it at least acknowledges ffmpeg and farbice bellard :P (page 23)
[02:29:58 CEST] <klaxa> is ffmpeg trademarked by him?
[02:31:26 CEST] <klaxa> >FFmpeg is a trademark of Fabrice Bellard, the originator of the FFmpeg project.
[02:32:15 CEST] <klaxa> but no gpl license in the pdf only their own
[02:38:11 CEST] <Djfe> Can you link your pdf?
[02:38:13 CEST] <Djfe> https://www.stellarinfo.com/de/installation-guide/video-repair/User_Guide_win.pdf
[02:38:30 CEST] <Djfe> this one is only 11 pages long (and in German, but at least for me that's my native language
[02:38:45 CEST] <Djfe> (oh and it doesn't mention ffmpeg or mplayer at all)
[02:39:18 CEST] <klaxa> https://www.stellarinfo.com/installation-guide/video-repair/User_Guide_win.pdf
[02:40:21 CEST] <Djfe> ah I see (I only tried replacing de with en and not leaving it out)
[02:40:40 CEST] <Djfe> Well they mention ffmpeg, but not mplayer and they don't mention the GPL at all.
[02:40:54 CEST] <klaxa> yeah, also nothing in the EULA
[02:41:12 CEST] <klaxa> at least it's concise only two pages
[02:41:26 CEST] <klaxa> but it's an image in a pdf
[02:41:33 CEST] <Djfe> "All rights of any kind in Stellar Phoenix Video Repair, which are not expressly granted in this license, are entirely and exclusively reserved to and by Stellar Information Technology Private Limited. You shall not rent, lease, modify, translate, reverse engineer, decompile, disassemble or create derivative works based on Stellar Phoenix Video Repair nor permit anyone else to do so."
[02:41:41 CEST] <Djfe> "You shall not make access to Stellar Phoenix Video Repair available to others in connection with a service bureau, application service provider or similar business nor permit anyone else to do so."
[02:42:10 CEST] <Djfe> @klaxa I know, but an image does nothing in this regard, it's clearly a violation
[02:42:56 CEST] <Djfe> They aren't allowed to use ffmpeg and make money with it (unless maybe they actually send every owner of their software the source code of their software
[02:43:06 CEST] <klaxa> yeah i was more complaining that you can't copy-paste from that file (without ocr)
[02:43:21 CEST] <klaxa> yee pretty much
[02:43:41 CEST] <klaxa> or something similar, i'm no lawyer
[02:43:42 CEST] <Djfe> are you sure? I can copy text from the manual using pdf.js in FF
[02:44:09 CEST] <klaxa> the manual yes, the EULA is 2 pages of images
[02:50:26 CEST] <Djfe> weird, not for me (pdf.js and Adobe Reader can copy text from it just fine)
[02:50:42 CEST] <Djfe> try this one:
[02:50:42 CEST] <Djfe> https://drive.google.com/open?id=1A97EkHD_Z2Va20S2WFNY6tbxopTYHlrI
[02:52:26 CEST] <klaxa> ah, i got EULA_eng.pdf obviously :D
[02:52:35 CEST] <klaxa> https://www.stellarinfo.com/installation-uninstallation/eula_eng.pdf
[02:52:38 CEST] <klaxa> looks quite different
[02:52:43 CEST] <klaxa> with branding and whatnot
[03:03:51 CEST] <Djfe> Anyways, taht's about it. I'm going to leave in 5mins. Bye! :)
[14:48:24 CEST] <dragmore88> hi, anyone seen that -CRF Value and maxrate + vbv doesnt really uphold the limit set.. example, i set the limit to 15mbps.. i still get peaks up in 18mbps... (measuerd in bitrate viewer..)
[14:52:54 CEST] <BtbN> either you use cr, or vbr/abr with vbv-maxrate
[14:52:57 CEST] <BtbN> *crf
[14:53:03 CEST] <BtbN> pretty sure crf will win if set
[14:54:00 CEST] <BtbN> also, keep in mind that spikes up to the set bufsize can happen anytime, that's just how it works
[16:01:34 CEST] <kepstin> crf in combination with vbv is supported with x264
[16:01:37 CEST] <kepstin> it should be working
[16:01:54 CEST] <kepstin> you'll obviously still get peaks, depending on the bufsize you choose
[16:02:16 CEST] <kepstin> (note that you are required to set bufsize, without it set, maxrate alone doesn't do anything)
[16:04:16 CEST] <PureTryOut[m]> can anyone help me with my segfaulting issue? :/
[16:05:57 CEST] <Blacker47> panter
[16:08:39 CEST] <PureTryOut[m]> panter?
[16:13:42 CEST] <Blacker47> PureTryOut[m], was wrong window and i wonder why tab don't work.
[16:15:07 CEST] <PureTryOut[m]> ah ok haha
[16:15:26 CEST] <PureTryOut[m]> at least I'm glad to know my messages are arriving
[16:16:18 CEST] <PureTryOut[m]> I thought they didn't, got no response at all for multiple days
[16:17:41 CEST] <kepstin> PureTryOut[m]: well, there's not really anything anyone could say except maybe "that's too bad, it works for me". You might want to try getting a backtrace or trying a different ffmpeg build.
[16:19:38 CEST] <kepstin> i didn't even know ffmpeg supported sftp protocol, tbh.
[16:21:23 CEST] <^Neo> hello, can someone explain why there's an X in HLS after EXT-X-????
[16:21:39 CEST] <^Neo> I'm trying to translate the acronyms to generic names
[16:21:54 CEST] <^Neo> EXTM3U = extended m3u playlist
[16:21:59 CEST] <^Neo> EXTINF = extended information
[16:22:05 CEST] <^Neo> EXT-X-??? = ????
[16:23:16 CEST] <Mavrik> extension I guess? :P
[16:23:32 CEST] <kepstin> ^Neo: the X doesn't really mean anything, it's just a commonly used way of saying that something is a vendor-specific (non-standard) extension in protocol docs.
[16:24:08 CEST] <kepstin> (of course, sometimes these get standardized later, including the x, so yea - it's basically meaningless)
[16:25:17 CEST] <jkqxz> PureTryOut[m]:  <https://trac.ffmpeg.org/ticket/6413>?
[16:47:40 CEST] <dragmore88> so whats the point of "max-rate" if it will go past it all the way up to the bufsize threshold? or is it something obvious im missing?
[16:47:57 CEST] <dragmore88> -crf 23 -maxrate 15M -bufsize 20M
[16:48:28 CEST] <kepstin> dragmore88: maxrate tells the coded what the expected speed that the buffer will fill at is
[16:48:28 CEST] <dragmore88> i see the bitrates on extreme peaks to go anywhere between 15 and 20 (just to confirm what u are saying..
[16:49:02 CEST] <kepstin> the video bitrate has nothing to do with the maxrate value
[16:49:13 CEST] <dragmore88> ah
[16:49:40 CEST] <kepstin> aside from that the codec might have to reduce bitrate if the buffer would underflow (because it's not refilling fast enough)
[16:50:15 CEST] <dragmore88> i allways belived that Maxrate is the max threshold that x264 could let the bitrate peak to in a CRF world
[16:50:34 CEST] <dragmore88> and bufsize was an absolute fixed buffer size in megabytes
[16:51:48 CEST] <kepstin> you configure bufsize and maxrate to tell the codec "the player has X amount of buffer ram, and can read data off the disc or network at Y minimum speed"
[16:52:10 CEST] <kepstin> and then the codec will make a video that'll stream smoothly with those parameters
[16:53:08 CEST] <dragmore88> but if one set maxrate to 15mbps and the buffer to 15mbps, this is fact the upper max bitrate thresholds in practise right ?
[16:53:27 CEST] <kepstin> and it will definitely make use of available buffer space to allow individual frames (esp keyframes) to peak at well over the maxrate if possible
[16:54:19 CEST] <dragmore88> hmm
[16:55:00 CEST] <dragmore88> i just did a test with a quite noisy prores source, 1 targe with CRF20 (free mode.. no limits) and CRF20 with maxrate = 10, bufsize = 10
[16:55:05 CEST] <kepstin> if the maxrate is 15 megabits per second and the buffer is 15 megabits, then the buffer takes 1s to refill. So the codec can take one second of video and make one frame (a keyframe) take 14mbits, and the other frames in that second (P or B frames) total 1mbit.
[16:55:50 CEST] <dragmore88> the first target ended up with a 35mbps avg bitrate and the latter ended up with 9mbps, then i did a VMAF comparison with the 2 and the source.. and they were nearly identcal
[16:56:03 CEST] <kepstin> so now you have to define how you measure "peak" bitrate
[16:56:36 CEST] <kepstin> if you measure bitrate per-frame, then a single 14mbit frame at 30fps is 420mbit/s :/
[16:56:45 CEST] <dragmore88> heh
[16:56:52 CEST] <kepstin> normally "peak" is averaged over some number of frames
[16:57:09 CEST] <dragmore88> yea.. bitrate viewer uses frames, gop, enchaned gop mode etc..
[16:57:13 CEST] <kepstin> when using vbv controls, the only meaningful number to use is "the number of frames that are buffered"
[16:57:31 CEST] <kepstin> so if you have 1 second of buffer, average bitrate over 1 second of frames to get the peak
[16:58:13 CEST] <kepstin> and you'll find that... this ends up being basically what you set maxrate to
[16:59:09 CEST] <dragmore88> agreed
[17:00:23 CEST] <dragmore88> i find that CRF is quite alot better than fixed vbr on my testclips with an all over smaller byte footprint
[17:00:31 CEST] <dragmore88> if one can accept the spikes
[17:00:46 CEST] <dragmore88> vmaf scores confirms this
[17:00:53 CEST] <kepstin> crf should be identical in overall quality to a 2-pass vbr encode with the same final bitrate.
[17:00:54 CEST] <dragmore88> and my eyes ;)
[17:01:10 CEST] <kepstin> (in x264, other codecs use different implementations)
[17:02:06 CEST] <dragmore88> yes, but for most of us broadcasters a fixed CBR and now VBR is the old fashion way to do it..
[17:02:13 CEST] <kepstin> this is a quirk of the x264 two-pass encode implementation. it works by running an analysis pass, calculating a "constant rate factor" that's applied to the complexity of each frame, then does a second encode using that constant rate factor
[17:02:21 CEST] <dragmore88> lots of wasted bits, and lost high quality areas lost..
[17:03:10 CEST] <dragmore88> does x264 use the crf values pr gop on the targed VBR? or just flat over the whole file ?
[17:03:28 CEST] <kepstin> crf is constant over the whole encode in normal usage
[17:03:44 CEST] <dragmore88> ok
[17:04:01 CEST] <kepstin> (you can actually change it in the middle of an encode using the x264 api, but i dunno if ffmpeg's wrapper lets you do that)
[17:04:25 CEST] <dragmore88> isnt this what netflix is doing on scene based encoding?
[17:04:47 CEST] <dragmore88> chopping up the scenes, CRF first pass, lock it down with VBR for that scene
[17:05:01 CEST] <dragmore88> or i might be wrong
[17:05:09 CEST] <kepstin> netflix appears to be doing bitrate based encodes at a bunch of bitrates, then picking one that meets their quality level
[17:05:22 CEST] <kepstin> crf is setting a quality level, and then getting whatever bitrate the encoder decides is good
[17:05:41 CEST] <dragmore88> like VMAF sub 90 -> /DEV/NULL
[17:05:44 CEST] <dragmore88> keep the one over
[17:07:27 CEST] <kepstin> the point of crf is that it lets the encoder automaticall raise and lower the bitrate per scene based on complexity to maintain constant visual quality (according to the encoder's builtin psy metrics)
[17:08:18 CEST] <dragmore88> japp
[17:08:25 CEST] <kepstin> said builtin metrics are obviously less complex than vmaf, for speed reasons, but for most uses they're good enough
[17:08:37 CEST] <dragmore88> i just want to limit it a bit on the top so it doesnt go totally haywire
[17:09:02 CEST] <kepstin> yep, makes sense. That's actually what google does with their vp9 encoding for youtube
[17:09:18 CEST] <dragmore88> i just 25 tests encodes on CRF20 and they averaged out on 4,4mbps and avg peak on 9mbps
[17:09:35 CEST] <dragmore88> our formar static CBR level was 6,5mbps
[17:09:37 CEST] <dragmore88> former*
[17:09:59 CEST] <dragmore88> so we gain alot on quality and reduce the bitrate by like 40%
[17:10:03 CEST] <dragmore88> on average
[17:10:13 CEST] <kepstin> vp9 doesn't have something exactly like crf mode, but it does have a quality limit mode that lets you say "don't bother spending extra bits if the quality is at least X good", which can be used either standalone or in combination with bitrate controls
[17:10:17 CEST] <dragmore88> just switching from a CBR to VBR world
[17:12:09 CEST] <dragmore88> thx for the informative discussion kepstin ;)
[17:18:23 CEST] <kepstin> probably the biggest thing about vod streaming that affects bitrate is what you set your gop size to
[17:18:59 CEST] <kepstin> if you're using crf mode, increasing the gop size means it'll use a lot more, smaller, predicted frames and lower your average bitrate a lot
[17:20:33 CEST] <kepstin> so e.g. going with 10s segments in your hls rather than 5s or something like that can be a big win.
[17:21:49 CEST] <kepstin> (if you're doing segmented video, you might want to set the vbv bufsize to match the segment length, since you'd normally be expecting players to buffer ~1 segment ahead)
[17:23:01 CEST] <BtbN> 3 segments actually
[17:28:17 CEST] <dragmore88> we are using 2 sec GOP size today (dash)
[17:28:28 CEST] <dragmore88> and im hardlocking IDR frames pr 2 sec
[17:28:53 CEST] <dragmore88> but enabeling scenecut detection within the gop (iframe)
[17:30:01 CEST] <kepstin> yeah, with that short of a gop, scene cut detection might not do much useful, since putting two i frames in the gop would probably hit the vbv limits, meaning one or both get reduced quality.
[17:30:05 CEST] <dragmore88> how can one set the VBV bufsize to match the segment length? mb vs. seconds ;)
[17:30:19 CEST] <kepstin> dragmore88: bitrate is in bits per second
[17:30:27 CEST] <kepstin> therefore if you know seconds, you can calculate bits
[17:30:39 CEST] <kepstin> (use the maxrate)
[17:30:39 CEST] <dragmore88> in a crf world, i would know the bitrate
[17:30:43 CEST] <dragmore88> k
[17:30:59 CEST] <dragmore88> so 10mbps maxrate x 2 sec = 20mbps
[17:31:11 CEST] <dragmore88> is the bufsize set in mbits or mbytes?
[17:31:23 CEST] <dragmore88> 20mbit i meant
[17:35:12 CEST] <kepstin> dragmore88: the suffixes 'M', 'K' in ffmpeg are in bits
[17:35:50 CEST] <kepstin> the bufsize parameter takes a value in bits
[20:21:32 CEST] <Cracki> silly question: does ffmpeg have a scene change detection such that it can poke a dumb, but p-frame-capable, codec to make an intra frame?
[20:22:24 CEST] <Cracki> (i have qtrle, which is qt animation, which can do "p-frames", and I can use -g, but I'd rather it make intra frames only when needed)
[20:27:04 CEST] <Cracki> (footage is screen capture of someone's static slides presentation, so no change mostly, and when change, it should be intra-coded)
[20:28:53 CEST] <kepstin> nothing built-in, it would require code changes.
[20:29:13 CEST] <Cracki> ic
[20:29:17 CEST] <Cracki> thx
[20:30:11 CEST] <kepstin> (the proper fix would probably be adding scene change detection to the codec itself)
[20:31:02 CEST] <kepstin> if you were writing an application using ffmpeg libraries, you could do something like use a filter to detect scene changes (iirc there's one that sets frame metadata) and use that info to set the frame type when encoding.
[20:32:24 CEST] <Cracki> don't even need a filter, I know exactly which frame needs intra, and all the rest are nulls
[20:32:42 CEST] <Cracki> just never had the need to deal with ffmpeg api directly
[20:33:21 CEST] <Cracki> say, using the API, I would be able to send null frames, eh?
[20:33:26 CEST] <Cracki> (to the codec)
[20:34:02 CEST] <Cracki> I think it's possible because cli ffmpeg transcode from one lossless p-capable codec (lagarith) to qtrle is really fast
[20:55:16 CEST] <kepstin> Cracki: note that with the ffmpeg api, passing a NULL AVFrame is the indication that you've hit end of stream and want to start flushing encoder buffers.
[20:55:34 CEST] <Cracki> ic. how to indicate a repeated frame?
[20:56:02 CEST] <JEEB> pass the same frame again?
[20:56:09 CEST] <kepstin> send another frame that references the same data
[20:56:17 CEST] <Cracki> ah, references the same data
[20:56:37 CEST] <kepstin> although I suspect few encoders bother optimizing by checking if the data pointers are the same
[20:56:47 CEST] <JEEB> yes, they generally check the content
[20:57:06 CEST] <Cracki> how do encoders typically handle that? can they detect that I sent the same frame twice, or would they have to figure out that there are no differences in the data on their own?
[20:57:06 CEST] <JEEB> or... you do VFR
[20:57:41 CEST] <Cracki> my output should be fixed frame rate... I can of course generate frames and PTSes
[20:58:03 CEST] <JEEB> no, I mean if you want to make sure that no extraneous pictures get encoded, you do Variable Frame Rate
[20:58:07 CEST] <kepstin> yeah, some people get this "null" frame idea because avi doesn't support vfr, but does let you pack null frames for skipped frames
[20:58:22 CEST] <Cracki> ic
[20:58:22 CEST] <JEEB> if you need to have a constant frame rate then you just feed frames over
[20:58:37 CEST] <JEEB> modern encoders will figure out the content is the same if you're not set to all-intra
[20:58:46 CEST] <JEEB> and yes, the AVI thing is actually VFR in a CFR container
[20:58:57 CEST] <Cracki> qtrle would encode that as a frame that immediately ends, meaning use all the data from the previous frame (and nothing updated)
[20:59:27 CEST] <JEEB> well yea, that depends on the encoder
[20:59:43 CEST] <Cracki> I'd like to give the codec as much hinting as possible so it doesn't _have to_ touch the frame contents
[20:59:43 CEST] <JEEB> any modern encoder worth its salt will attempt to figure out identical input
[21:00:06 CEST] <Cracki> do avframes have "identity"?
[21:00:09 CEST] <JEEB> Cracki: there's only two alternatives, you skip a timestamp and do VFR, or you just encode
[21:00:14 CEST] <Cracki> hm
[21:00:19 CEST] <JEEB> there's no flag for "this is a duplicate picture"
[21:03:24 CEST] <Cracki> hmmm the "fast" transcode only happens from lagarith inside avi to qtrle inside whatever
[21:03:52 CEST] <Cracki> and throws bunches of notices about repeated frames or somesuch. I guess ffmpeg does something smart in that case
[21:03:56 CEST] <kepstin> it's possible the lagarith inside avi is actually pseudo-vfr and has null frames
[21:04:07 CEST] <Cracki> it surely has null frames
[21:04:28 CEST] <kepstin> which means that as long as you're passing it through as vfr inside ffmpeg, it should stay that way
[21:04:31 CEST] <kepstin> i think
[21:04:36 CEST] <Cracki> hmmm
[21:04:42 CEST] <JEEB> yea, then it's VFR and for the mov muxer for some reason the default is CFR mode
[21:04:50 CEST] <JEEB> the ffmpeg.c vsync mode that is
[21:04:54 CEST] <JEEB> which is telling you it's duplicating things
[21:05:00 CEST] <kepstin> obviously if you use -r output option or something to set cfr, it'll duplicate the frames
[21:05:02 CEST] <JEEB> -vsync vfr or -vsync passthrough
[21:05:14 CEST] <JEEB> kepstin: you don't even need to set -r or anything
[21:05:20 CEST] <JEEB> just try doing VFR to movenc
[21:05:23 CEST] <Cracki> I guess the transcode from (constant frame rate) qtrle to qtrle is slow because ffmpeg has to decode all frames and pass them over, because the "null" is on the bitstream level, not the container level
[21:05:41 CEST] <JEEB> because movenc IIRC is for some reason marked as CFR container
[21:05:45 CEST] <JEEB> uhh, muxer
[21:06:23 CEST] <Cracki> I'd expect mp4 to be so restrictive. I can't even put qtrle into mp4, but mov...
[21:06:30 CEST] <Cracki> (I know they share history)
[21:06:36 CEST] <JEEB> no, it doesn't make sense for any of them to be honest
[21:06:51 CEST] <JEEB> you can set a wild time base for each, and I think mov actually is even more restricted than mp4?
[21:07:03 CEST] <Cracki> what makes sense, and what a standards body would think makes sense, are usually not the same
[21:07:24 CEST] <JEEB> no, I'm telling you - there's zarro issues with VFR in ISOBMFF as long as you pick your time base right
[21:07:38 CEST] <JEEB> I'll check where that CFR muxer flag comes from...
[21:07:41 CEST] <JEEB> time for archeology
[21:07:56 CEST] <JEEB> but you can override ffmpeg.c's behavior with -vsync vfr or -vsync passthrough
[21:08:09 CEST] <Cracki> no no, I'm absolutely ok with cfr. the target application is adobe premiere and the version I'm on has shit to NO support for vfr
[21:09:25 CEST] <JEEB> yeah, I was mostly commenting about the idea that the CFR limitation made any sense (there is no actual limitation in the muxer itself, if you set your time base you're rolling fine)
[21:09:32 CEST] <Cracki> ic
[21:09:38 CEST] <JEEB> and actually for video movenc.c generally just sets a >10k time base for you by default
[21:09:47 CEST] <Cracki> yes, everything's got a PTS and DTS these days, eh
[21:09:48 CEST] <JEEB> because back in ye olden days it didn't support edit lists
[21:10:05 CEST] <JEEB> or some archeological findings like that
[21:10:48 CEST] <Cracki> edit lists... I know they're part of mov/mp4 and some other formats but I have never seen a compelling purpose for them and I would strangle the ones who gave these formats the capability
[21:11:26 CEST] <JEEB> edit lists are by default utilized for stuff like audio encoder delay and b-frame delay signaling
[21:11:37 CEST] <Cracki> o.o
[21:11:52 CEST] <JEEB> so you can say that "yes, there's some audio data in the beginning that you don't want to output"
[21:12:04 CEST] <JEEB> because the encoder makes that, and the size depends on encoder mode etc
[21:12:09 CEST] <JEEB> usually a single audio frame, I think?
[21:12:12 CEST] <Cracki> or you can if you're so inclined, but there's no picture yet?
[21:12:23 CEST] <JEEB> yes
[21:12:32 CEST] <JEEB> although generally you don't want to decode encoder delay...
[21:12:36 CEST] <JEEB> or well, you want to decode it
[21:12:38 CEST] <JEEB> but not pass it on
[21:12:42 CEST] <Cracki> aye
[21:13:00 CEST] <JEEB> and I guess I should call it encoder initialization padding or something
[21:13:06 CEST] <JEEB> it ends up being the encoder delay, yes
[21:13:35 CEST] <JEEB> ah yes
[21:13:38 CEST] <JEEB> the classic ffmpeg.c line
[21:13:39 CEST] <JEEB> format_video_sync = (of->ctx->oformat->flags & AVFMT_VARIABLE_FPS) ? ((of->ctx->oformat->flags & AVFMT_NOTIMESTAMPS) ? VSYNC_PASSTHROUGH : VSYNC_VFR) : VSYNC_CFR;
[21:14:03 CEST] <JEEB> so, AVFMT_VARIABLE_FPS is not set for movencäs muxers
[21:14:03 CEST] <Cracki> why do you have no rule against masturbatory use of ternary operators?
[21:14:05 CEST] <Tonnes> hi, can I post a possible issue? (or wait a bit)
[21:14:29 CEST] <JEEB> Tonnes: just note it and also if you care you can post it on trac.ffmpeg.org
[21:14:42 CEST] <Cracki> go ahead, I'm just chatting idly
[21:15:29 CEST] <JEEB> but yea, that's why for any movenc.c muxer ffmpeg.c starts duplicating/dropping frames by itself by default
[21:15:41 CEST] <Cracki> moven cäs, sounds like an offshoot of mövenpick
[21:15:44 CEST] <JEEB> (it doesn't use the fps video filter, funny enough)
[21:15:48 CEST] <JEEB> lol
[21:15:57 CEST] <JEEB> that's what I get for missing a key location on a keyboard layout
[21:16:01 CEST] <JEEB> ä is next to '
[21:16:08 CEST] <Cracki> and less than next to .
[21:16:27 CEST] <Tonnes> i just stumbled on what may be a regression. when trying to fix a file as reported in mozilla's bug 1448762 using 2 builds from https://ffmpeg.zeranoe.com/builds/win32/shared/ I found that ffmpeg-20180102-41e51fb-win32-shared.zip worked, but ffmpeg-latest-win32-shared.zip did not, as the latter prevents is by the corrupt header
[21:16:29 CEST] <Cracki> oh right that wasn't movenc.c
[21:16:47 CEST] <Tonnes> s/prevents it
[21:17:05 CEST] <Cracki> Tonnes, so your problem is some of zeranoe's zips are malformed?
[21:17:15 CEST] <Cracki> or is that about the binaries inside?
[21:17:30 CEST] <JEEB> this is a broken ISOBMFF file
[21:17:33 CEST] <JEEB> https://bugzilla.mozilla.org/show_bug.cgi?id=1448762
[21:17:46 CEST] <Cracki> ah
[21:17:56 CEST] <JEEB> " the sample table of this file is invalid. In particular the Sample To Chunk Box (ISO/IEC 14496-12:2015 8.7.4) contains rubbish data with the value of first_chunk always set to 1 for all samples."
[21:18:19 CEST] <Tonnes> no, I think ffmpeg may work as it should (well, I never used it before today), it's just that "ffmpeg -i file.mp4 -codec copy file_fixed.mp4" halts because of the malformed header in the corrupt video
[21:18:38 CEST] <Cracki> halt as in crash, or stops gracefully?
[21:18:58 CEST] <Tonnes> will retry and post the error message if you want me to
[21:19:31 CEST] <JEEB> and is this a change in behavior? although to be honest, if we have actually managed to properly derp at broken files this is *so* good
[21:19:50 CEST] <JEEB> because usually FFmpeg is going the road to hell where we have more features to support broken files than valid ones
[21:20:05 CEST] <Cracki> the last post on the bug says remuxing (-c copy) should work without problems and actually fix the problem, not crash or halt or anything
[21:20:25 CEST] <JEEB> yes, but that could have been an old version
[21:20:39 CEST] <JEEB> there's been some changes recently to the "mov" demuxer from both google and elsewhere
[21:20:46 CEST] <Cracki> ic
[21:21:33 CEST] <JEEB> I would probably write a box editor for mp4 to fix these sorts of things
[21:22:44 CEST] <JEEB> and if you want, you can look into the byte offsets with L-SMASH's boxdumper or atomicparsley
[21:22:46 CEST] <Tonnes> https://imgur.com/a/v2TkP7M
[21:22:50 CEST] <JEEB> and use a hex editor
[21:22:56 CEST] <Tonnes> I figured it could be intended behavior though
[21:23:05 CEST] <Cracki> looks graceful enough
[21:23:29 CEST] <JEEB> nice, it even tells you where things start to fall apart
[21:23:45 CEST] <Tonnes> tried to help ouot som eforum user with broken videos in FF 59 and 60 so pointed to ffmpeg, then found this "issue" :)
[21:24:19 CEST] <JEEB> let's see who you can "blame" for this improvement
[21:25:02 CEST] <JEEB> ok, so it was asserting before
[21:25:07 CEST] <JEEB> and the chromium people didn't like that
[21:25:34 CEST] <JEEB> so now there's a commit that says "commit 9e67447a4ffacf28af8bace33faf3ea432ddc43e"
[21:25:37 CEST] <JEEB> Author:	Michael Niedermayer <michael at niedermayer.cc>  Fri Mar 16 20:53:36 2018
[21:25:40 CEST] <JEEB> Committer:	Michael Niedermayer <michael at niedermayer.cc>  Tue Mar 20 23:59:40 2018
[21:25:43 CEST] <JEEB> avformat/mov: Check STSC and remove invalid entries
[21:25:45 CEST] <JEEB> also I selected way more than I wanted
[21:26:02 CEST] <JEEB> Fixes: crbug 822547, crbug 822666 and crbug 823009
[21:26:09 CEST] <JEEB> for references to chromium (?) bugs on this
[21:26:19 CEST] <JEEB> it's their fuzzing infra
[21:26:52 CEST] <Cracki> so he turned assertions into proper errors? sounds like a good thing
[21:27:02 CEST] <JEEB> yes
[21:27:10 CEST] <JEEB> those sanity checks aren't always the best, though :P
[21:27:15 CEST] <JEEB> since they're not always clear cut
[21:27:22 CEST] <JEEB> esp. the stuff like timestamp checks in movenc.c
[21:28:10 CEST] <JEEB> Tonnes: if that file didn't assert before then it would have worked (maybe?)
[21:29:17 CEST] <Tonnes> ?
[21:29:49 CEST] <JEEB> as in, if you check out a version from before that hash, if it doesn't assert you might get something out of it
[21:30:05 CEST] <Cracki> meaning: that change only made breakage obvious, it make it more strict
[21:30:14 CEST] <Cracki> *didn't
[21:30:42 CEST] <JEEB> oh it did add the sanity checks. and it doesn't exactly say which cases led to the asserts
[21:30:46 CEST] <Tonnes> well, the same happens in fmpeg-4.0-win32-shared.zip
[21:30:47 CEST] <Cracki> ic
[21:30:55 CEST] <Cracki> 4.0 sounds fresh
[21:30:57 CEST] <JEEB> ffmpeg-4.0 is from after that March commit
[21:31:05 CEST] <JEEB> it was just branched a few weeks ago
[21:31:06 CEST] <Tonnes> s/ when using
[21:32:55 CEST] <Tonnes> ffmpeg-3.4.2-win32-shared.zip : no issue
[21:33:11 CEST] <JEEB> yea then that breakage wasn't hitting the assert
[21:34:11 CEST] <Tonnes> tbh I'd just be interested in whether or not this is expected behavior and moreover, if that's true, if there is an additional command line option to specify that would still enable FFmpeg to fix such a vid
[21:34:52 CEST] <Tonnes> all in favaor of users and website ownere that may want to use ffmpeg in order to fix some vids rather than waiting for FF 61
[21:35:26 CEST] <JEEB> no option for that sanity check
[21:35:35 CEST] <Tonnes> ..and grab the latest version automatically ;)
[21:36:22 CEST] <Cracki> keep versions of everything
[21:36:23 CEST] <BtbN> If ffmpeg can read that file and product proper audio and video from it, it shouldn't just fail imo
[21:36:39 CEST] <Cracki> I love zeranoe for keeping tons of builds around. sigrok could learn from that :>
[21:37:58 CEST] <JEEB> BtbN: as long as it doesn't insanely complicate things or enable completely invalid stuff to happen
[21:38:20 CEST] <JEEB> Tonnes: if you want you can create a ticket on trac.ffmpeg.org to explain the issue and link the bugzilla issue etc
[21:42:53 CEST] <Tonnes> only if you insist, otherwise I'd appreciate if you could do it for me (I'm a bit overloaded with other duties and it would require me to register somewhere)
[21:43:12 CEST] <JEEB> oh you don't say I don't have too many hot things on the iron :P
[21:43:33 CEST] <JEEB> I've got HDR output support in one player, multiple things  Iwant to implement in FFmpeg's MPEG-TS demuxer
[21:43:43 CEST] <JEEB> reviewing at least one dashenc.c patch set
[21:43:50 CEST] <JEEB> reviewing some MPEG-TS demuxer patches
[21:43:57 CEST] <Tonnes> :)
[21:44:08 CEST] <JEEB> and now you know why the fuck I haven't watched series for seven fucking weeks
[21:44:32 CEST] <JEEB> instead feeling sad and procrastinating on youtube bullshit if I'm too tired for open source on an evening
[22:01:35 CEST] <Etrigan63> Hello.
[22:02:36 CEST] <Etrigan63> Can anyone recommend a GUI front-end for ffmpeg on Linux? I am looking to take advantage of GPU acceleration that is not offered by Handbrake.
[22:02:53 CEST] <BtbN> I can recommend not using one, ever
[22:03:08 CEST] <BtbN> So far all of them I have seen were bad. Handbrake is the only somewhat decent one
[22:03:17 CEST] <JEEB> and Handbrake is after all, an API client
[22:03:44 CEST] <Etrigan63> So how can I enable GPU acceleration in Handbrake?
[22:04:29 CEST] <kerio> i can recommend not using GPU acceleration for h264 :^)
[22:05:00 CEST] <Etrigan63> Why not?
[22:06:10 CEST] <durandal_1707> use vidcoder
[22:06:53 CEST] <JEEB> handbrake IIRC had support for hwaccel, look into their documentation on how to use it
[22:07:00 CEST] <JEEB> we do not make handbrake, handbrake just uses FFmpeg
[22:07:03 CEST] <JEEB> (the libraries)
[22:07:40 CEST] <BtbN> handbrake doesn't even use ffmpeg
[22:07:57 CEST] <BtbN> it's libav-only from the looks of it, they are only, very slowly, thinking about switching to ffmpeg
[22:08:00 CEST] <JEEB> yea I heard they were going to with the latest release?
[22:08:01 CEST] <kerio> Etrigan63: libx264 is very very very good
[22:08:12 CEST] <BtbN> the bug about it is open for 2 years now
[22:12:05 CEST] <JEEB> oh well
[22:12:59 CEST] <furq> Etrigan63: if you mean nvenc/quicksync then those are really only suitable for realtime
[22:13:09 CEST] <furq> and handbrake implies this is for archival
[22:13:34 CEST] <furq> if you just mean opencl in x264 then that's not really worth using, it hardly gives any speedup and it has a minor impact on quality
[23:29:46 CEST] <zevarito> I am outputing m3u8 and looking for a way to introduce custom tags in the playlist, there is a way to do this inside the library?
[23:30:36 CEST] <zevarito> Also I am having hard time to identify how to create the liveplaylist or a VOD programatically
[00:00:00 CEST] --- Sat May 12 2018