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

[burek]

[00:46:36 CET] <calamari> it's strange, the best 60p from mixed telecine/interlace result seems to be ignoring the telecine and using yadif=mode=send_field:deint=all  Most of the time the 2 frames from fields are nearly identical, but it does help in some cases like rolling credits.
[00:50:26 CET] <calamari> mcdeint seems to do nothing
[01:00:54 CET] <calamari> experimented with minterpolate on yadif frame output to get 60p, but it was super weird looking. I guess I'm just not used to seeing that many frames during fast motion
[01:01:38 CET] <calamari> doing it after ivtc was even worse
[17:09:03 CET] <egrouse> is there a way to recover from 'conversion failed' errors?
[17:09:07 CET] <kepstin> calamari's gone, but to anyone else in that situation i'd recommend using w3fdif instead of yadif, it'll have less artifacting :)
[17:09:09 CET] <egrouse> ie to start again from same place/or just start again
[17:09:36 CET] <kepstin> egrouse: not in general, you have to know why the conversion failed to know what an appropriate thing to do would be
[17:09:49 CET] <egrouse> yeah, fair
[17:10:03 CET] <egrouse> i think its because the outbound stream cant keep up (im streaming to rtmp)
[17:10:07 CET] <egrouse> but i dont really know
[17:10:15 CET] <egrouse> i get a message about failing to update headers/timestamp, then conversion failed
[17:10:37 CET] <furq> kepstin: i mean i would recommend just not trying to do it automatically with a dirty source
[17:10:51 CET] <furq> unless you feel you have too much hair and it could benefit from being torn out
[17:11:32 CET] <kepstin> the failed to update headers thing can probably be ignored, that just is printed on exit in some streaming/piped formats. I suspect the issue you're hitting is that the remote server closed the connection, or another type of network error.
[17:12:19 CET] <kepstin> egrouse: note that if your input is a file and your output is a "live" network stream, you should be using the "-re" option to make ffmpeg slow down/pace the stream.
[17:12:40 CET] <furq> if the status line shows anything other than 1.00x with a network output then that's obviously a bad sign
[17:12:51 CET] <furq> +/- 0.01 or so
[17:13:42 CET] <egrouse> if i was redirecting a live stream to another live stream would it be better to omit -re
[17:13:51 CET] <egrouse> i do have -re on both non-live and live media atm
[17:14:00 CET] <kepstin> if your input is live (webcam capture, live stream) you should *not* have -re
[17:14:02 CET] <furq> i don't know that it does anything if the input is live
[17:14:14 CET] <furq> but yeah i would exclude it regardless because anything it does do would be wrong
[17:14:16 CET] <egrouse> ok, im fairly sure it does have re
[17:14:19 CET] <egrouse> so i will check that
[17:14:37 CET] <kepstin> (the way -re works is it causes ffmpeg to sleep after reading each frame, so if it's slightly out of sync with the input then bad things will happen)
[17:14:58 CET] <egrouse> that definitely sounds like it could be a probable cause
[17:15:00 CET] <egrouse> or at least part of
[17:16:32 CET] <furq> not to derail the topic here, but has anyone ever actually got good results converting a hybrid telecine/interlaced source without manually selecting frame ranges to filter
[17:16:49 CET] <furq> assuming the frames aren't flagged correctly to start with
[17:18:12 CET] <kepstin> there's no combination of ffmpeg filters that can do that automatically
[17:19:04 CET] <kepstin> (the particular thing that's missing is the ability to output vfr automatically - i.e. 4/5 frames from the telecined section, and 5/5 frames from the interlaced sections)
[17:19:33 CET] <furq> pullup seems to claim it can do it
[17:19:38 CET] <furq> but it's never even approached working for me
[17:19:55 CET] <kepstin> pullup isn't a very good detelecine filter imo, i've never had great results with its matching
[17:20:20 CET] <furq> there's also a note in the fieldmatch docs that claims it can do it as well
[17:20:35 CET] <furq> If your input has mixed telecined (30fps) and progressive content with a lower framerate like 24fps use the following filterchain to produce the necessary cfr stream: dejudder,fps=30000/1001,fieldmatch,decimate.
[17:20:40 CET] <kepstin> pullup might do ok on mixed progressive and telecined, i think?
[17:20:42 CET] <furq> but again that does nothing for me
[17:20:49 CET] <kepstin> but mixed telecined and interlaced is hard
[17:21:01 CET] <furq> yeah i've always just done it with vsedit and manually selecting frame ranges
[17:21:16 CET] <furq> that caused some controversy last night so i wondered if i was missing something
[17:22:09 CET] <kepstin> in many cases if you have mixed progressive and telecined, it'll be from a dvd mpeg2 source, and you should use the repeatfields to turn it into consistent telecine before running through a detelecine filter
[17:22:19 CET] <kepstin> repeatfields filter*
[17:22:49 CET] <furq> i don't even know how you'd get progressive and telecined
[17:22:57 CET] <furq> i've seen progressive and interlaced on pal dvds before
[17:23:08 CET] <kepstin> common on ntsc anime dvds, fwiw
[17:23:19 CET] <furq> i assume that's just 60i and 24p where they've already deinterlaced the 60i
[17:23:50 CET] <kepstin> i suspect what happened is that the mpeg encoder was given 60i telecined video, and it automatically detelecined parts where it found clean matches and left the rest
[17:24:14 CET] <furq> oh fun
[17:24:22 CET] <kepstin> (i've seen mismatches encoded into the progressive bits even, which is why i prefer to repeatfields and then redo the detelecine)
[17:25:13 CET] <kepstin> the two worst things i've seen for detelecining are the serial experiments lain opening, and the last exile opening, fwiw
[17:25:43 CET] <furq> my test corpus is the intro to "chuck norris karate kommandos"
[17:25:44 CET] <kepstin> last exile was so bad, the blu-ray release was actually done in 1080i, just an interlaced upscale preserving the telecine/interlacing
[17:26:01 CET] <furq> with russian audio that apparently exists on an official dvd
[17:26:56 CET] <kepstin> with s.e. lain, the most recent BD release remaster did ok on the animated bits, and then terribly messes up the bits recorded with a video camera and some of the effects.
[17:27:34 CET] <kepstin> part of that opening was done, as far as I can tell, by playing an animation clip on a CRT television then recording it with a camcorder to get the effect.
[17:28:41 CET] <kepstin> (the upscale of the parts with fake scanlines also doesn't look very good)
[17:30:03 CET] <kepstin> so yeah, there's actual interlaced 60i video mixed in with the 24p/12p effects. There was also a few CG bits in 30p iirc.
[17:30:31 CET] <furq> very cool
[17:33:12 CET] <furq> https://0x0.st/zsjG.ts
[17:33:15 CET] <furq> it seemed rude not to share
[17:33:30 CET] <furq> apparently i got rid of the russian audio when i remuxed this, which is something i can't believe i'd do
[17:36:17 CET] <television> h
[19:24:13 CET] <Trel> Does the windows builds of ffmpeg not have support for libaom-av1?
[19:27:48 CET] <JEEB> no idea, zeranoe does the most popular ones so you'd have to check from zeranoe's site
[19:27:53 CET] <JEEB> he lists all libraries he utilizes
[19:28:24 CET] <Trel> Thanks, I'll take a look
[19:28:26 CET] <JEEB> if you mean building yourself, yes they should have. libaom wrapper itself shouldn't have anything against windows
[19:28:36 CET] <furq> zeranoe's builds have aom
[19:29:24 CET] <mfwitten> The filter `setpts=PTS/2' results in output that finishes in half the time at FPS 30000/1001, but `setpts=PTS/2, fps=30000/1001' still takes the full amount of time; the last frame is duplicated until the very end of the unaltered duration. How can this be? Why is this so?
[19:30:25 CET] <furq> the fps filter will dup frames if you ask it to
[19:30:26 CET] <furq> which you are doing
[19:31:12 CET] <furq> actually nvm that sounds like something else is happening
[19:31:23 CET] <Trel> Ok, modified question, did the encoder change its name from libaom-av1?
[19:31:36 CET] <furq> it's still libaom-av1 in 4.1
[19:31:47 CET] <mfwitten> furq: If I remove `setpts=PTS/2', the result is exactly the same duration, albeit normal speed
[19:32:07 CET] <furq> pastebin the command line and output
[19:33:09 CET] <Trel> I'm a moron, I had my PATH var reversed, I was executing the wrong ffmpeg.
[19:33:14 CET] <Trel> I'm good now, sorry
[19:38:12 CET] <Accord> is yuv420p basically the same as yuvj420p?
[19:39:11 CET] <Accord> they seem to be compatible at concat atleast
[19:49:28 CET] <JEEB> Accord: the J thing is an old way of mentioning that the YCbCr range is full (as opposed to 16-235/240 limited)
[19:50:02 CET] <kepstin> mfwitten: my guess is that the setpts filter is passing through the eof timestamp unmodified rather than adjusting it like the frame timestamps? then the fps filter will fill in the gap until eof by duplicating the last frame.
[19:50:35 CET] <kepstin> mfwitten: what ffmpeg version?
[19:51:56 CET] <mfwitten> furq: I'm putting together a test command-line.
[19:52:11 CET] <mfwitten> kepstin: n4.1
[19:53:25 CET] <mfwitten> kepstin: It was built by my distro on 25 Nov 2018
[19:56:40 CET] <Accord> JEEB: so can I count on them being concat compatible with stream copy?
[19:57:37 CET] <Aerroon> where can i find docs for the "-loop" keyword?
[19:58:13 CET] <furq> Aerroon: https://www.ffmpeg.org/ffmpeg-formats.html#image2-1
[19:58:22 CET] <kepstin> the "-loop" option is an input option on certain input formats, you'd have to check the docs for each format.
[19:58:43 CET] <Aerroon> ah, i didn't know that
[19:58:44 CET] <Aerroon> thanks
[19:58:49 CET] <Aerroon> that's why i couldn't find anything about it
[19:59:06 CET] <mfwitten> furq, kepstin: https://pastebin.com/ziywypU7
[20:00:04 CET] <mfwitten> kepstin: I suspect you're right, but is there really an eof timestamp? Surely `fps' should just ignore that.
[20:00:20 CET] <kepstin> hmm, setpts is using the old filter framework, so it doesn't have explicit eof handling :/
[20:02:54 CET] <kepstin> hmm. to know exactly what's going on i'd need some debug level logs to find out what the fps filter is doing. Ideally, i'd want to reproduce this with a short video (e.g. a couple seconds long) and a filter chain that's just setpts,fps if possible.
[20:10:11 CET] <kepstin> huh, i just noticed that the fps filter fill strip all a53 closed caption data from the stream
[20:11:13 CET] <kepstin> i wonder when that was added, I think the person who added it might have misunderstood the code flow.
[20:11:47 CET] <kepstin> (i think the intent was that it would only strip the CC data on duplicated frames, but it is being stripped from all frames)
[20:12:46 CET] <kepstin> tbh, doing that probably makes sense since there's no handling for what to do with CC data on dropped frames
[20:14:54 CET] <mfwitten> kepstin: This A/V stuff is complicated
[20:16:19 CET] <mfwitten> kepstin: Here's a shorter version: ffmpeg -y -i input.mp4 -vf 'setpts=PTS/2,fps=30000/1001' -r 30000/1001 -an /tmp/too-long.mp4
[20:16:57 CET] <kepstin> so the issue does reproduce with that short filter chain? k.
[20:17:12 CET] <mfwitten> kepstin: Yes. I've tried 2 clips
[20:17:20 CET] <kepstin> I'll go make myself a 10 frame input video and do some quick tests with debug on.
[20:17:29 CET] <mfwitten> kepstin: Thanks
[20:18:07 CET] <mfwitten> kepstin: Note that the input is also FPS 30000/1001
[20:19:54 CET] <kepstin> alright, got a nice simple reproducer: https://gist.github.com/kepstin/cdf5eff501c5d0daed5dfdb2dc0d44de/raw/
[20:20:32 CET] <kepstin> confirmed the issue is that setpts filter is passing through the original eof pts
[20:20:47 CET] <mfwitten> kepstin: Great
[20:20:55 CET] <kepstin> solution is going to be ... rewriting the setpts filter using the activate callback.
[20:21:05 CET] <mfwitten> kepstin: Indeed
[20:31:40 CET] <kepstin> mfwitten: i don't have time to look further into this right now, but it would be great if you could file a bug on trac so the issue doesn't get forgotten, please include my reduced reproduction case.
[20:33:50 CET] <mfwitten> kepstin: OK.
[20:33:58 CET] <mfwitten> kepstin: Thanks for your help.
[20:35:38 CET] <kepstin> in the mean time, i'd recommend adding a trim filter after the setpts, with the end time manually set - that should fix the reset of the chain.
[20:36:55 CET] <kepstin> ... maybe
[20:37:28 CET] <kepstin> hmm, never mind, that doesn't work :/
[20:38:16 CET] <mfwitten> kepstin: Honestly, I think the `fps' filter should ignore EOF stuff.
[20:38:29 CET] <mfwitten> kepstin: Why does it care? It should just do as it's told
[20:39:25 CET] <kepstin> it's doing exactly as its told, right now. It's being told "make an X fps video from input with irregular frame timing that ends a Y", and so it duplicates frames as necessary to make the video constant framerate until the end time.
[20:39:43 CET] <mfwitten> kepstin: The "end at Y" part is wrong.
[20:40:07 CET] <mfwitten> kepstin: It should just regulate the stream to the desired FPS
[20:40:08 CET] <kepstin> yes, the setpts filter is telling the fps filter a wrong value for the end time.
[20:40:46 CET] <mfwitten> kepstin: But `fps' shouldn't try to hit a desired duration anyway
[20:41:44 CET] <mfwitten> kepstin: The docs make it seem like it just drops/dups frames in order to achieve the specified FPS. It says nothing, really, about EOF; indeed, even the `eof_action' argument talks about the last frame, not the EOF PTS
[20:42:25 CET] <kepstin> if the last frame is supposed to be displayed for 5 seconds, according to the input to the fps filter, then the fps filter will duplicate it sufficiently to achieve that.
[20:42:38 CET] <mfwitten> kepstin: I would also suggest there be a new filter, `seteof' and/or `neweof', so that it can be shimmed into place to help people, should there be a similar problem with another filter
[20:42:52 CET] <mfwitten> kepstin: I see.
[20:43:10 CET] <kepstin> but yeah, video end times are complicated
[20:43:22 CET] <kepstin> it's not a value most formats actually store
[20:43:55 CET] <kepstin> so in general it's calculated - if you assume constant framerate, then the EOF is set to the time when the next frame would have been if there was one
[20:44:43 CET] <mfwitten> kepstin: Well, I'll submit a report with your example output, and let the knowledgeablefolk discuss it
[20:45:21 CET] <kepstin> (there is a special value for unknown/undetermined EOF pts, which if the fps filter recieves that it will deal with the last frame exactly as you describe)
[20:46:37 CET] <mfwitten> kepstin: Is it the explicit convention that the last frame is meant to be presented until the EOF PTS ?
[20:47:05 CET] <mfwitten> (I guess I mean "Is it a standard?" Is that ffmpeg's design decision?)
[20:47:18 CET] <kepstin> within the ffmpeg filter system, if the EOF pts is set to a value other than AV_NOPTS_VALUE, then that's the expected result.
[20:47:31 CET] <kepstin> but like I said, most video containers don't actually store an end timestamp value
[20:48:01 CET] <kepstin> so instead the player just has to guess the amount of time to show the final frame - it's usually shown either "until the audio ends" or "for the same amount of time as the frame before it"
[20:48:30 CET] <mfwitten> kepstin: Hmm. So, is the `trim' filter setting an explicit EOF?
[20:48:58 CET] <kepstin> trim filter's eof handling is messy, turns out it doesn't really work around this issue.
[20:49:35 CET] <kepstin> if the trim filter cuts the video before it would have ended anyways, it sets the eof timestamp to AV_NOPTS_VALUE; if the video ends before the trim filter has to do anything, the eof timestamp is passed through untouched.
[20:51:22 CET] <mfwitten> kepstin: So, where is eof timestamp getting set in the problem example command line?
[20:51:54 CET] <kepstin> mfwitten: it's getting set implicitly by ffmpeg when reading the input file.
[20:52:26 CET] <kepstin> note that mp4 i think actually does support some edit lists features that means it can actually store an end time? Not sure if that's part of the issue here or not.
[20:52:41 CET] <mfwitten> kepstin: But your example? Also, the original problem cropped up for me well into a complex filtergraph, where there had already been much trimming
[20:53:53 CET] <kepstin> mfwitten: in my shortened example, it looks like the end timestamp is being set by the filter framework internally after the first trim filter cuts the video (since the video is constant framerate, the filter framework used the "time when the next frame would have been displayed" method to pick an EOF timestamp)
[20:54:33 CET] <mfwitten> kepstin: I feel like this EOF timestamp is anathema to a stream-based system
[20:57:15 CET] <mfwitten> kepstin: Ah. I see it in your output: [Parsed_trim_1 @ 0x56530a3a8180] Setting 'end_frame' to value '10'
[20:57:26 CET] <mfwitten> oh
[20:57:27 CET] <mfwitten> woops
[20:57:43 CET] <mfwitten> nm
[20:57:50 CET] <mfwitten> That's the just the argument
[20:58:13 CET] <kepstin> that's not what actually sets the end pts, the trim filter actually sets it to AV_NOPTS_VALUE, but it looks like the filter framework internally is converting that to a number instead.
[20:58:37 CET] <mfwitten> kepstin: Maybe that's another facet of the bug
[20:58:57 CET] <mfwitten> kepstin: Sure, setpts should probably do something, too, but it should have never been a problem I would think
[21:00:06 CET] <kepstin> well, setpts is a filter which can change the length of the output video, using the old filter api that didn't really support changing the length of the output video - but this wasn't that big of an issue as long as all the other filters were using the same old api
[21:01:11 CET] <kepstin> but the fps filter got rewritten to use the newer api recentlyish (to fix a nasty bug actually, the old api required buffering all the frames to fill a large gap in one call, which meant that if you had a several minute gap with no frames it would use a ton of memory), and as a result there's weird interactions with old filters :/
[21:01:59 CET] <kepstin> proper solution is to just move more filters - particularly those that might change the length or speed of videos - to the new framework so everything's happy together.
[21:02:45 CET] <kepstin> although it might also not be a bad idea to also add another setting for the "eof_action" parameter on the fps filter, to say "ignore" :)
[21:04:16 CET] <kepstin> or maybe just change the behaviour of "pass" mode
[21:04:32 CET] <kepstin> i'll have to check how the old version of the fps filter behaved to see what's best.
[21:05:40 CET] <kepstin> but yeah, it basically comes down to this problem: say you have a 1fps video that's 2 frames long. How long is this video?
[21:05:57 CET] <kepstin> a reasonable assumption is "2 seconds", so lets go with that.
[21:06:08 CET] <kepstin> now you run the fps filter to convert it to 30fps
[21:06:19 CET] <mfwitten> kepstin: You'll notice the docs describe `eof_action' in terms of the last frame, not the EOF. Strangely, too, it looks like `pass' is actually implemented as `AV_ROUND_UP', so it doesn't really just pass it along
[21:06:38 CET] <kepstin> if you want the video to still be "2 seconds" long, it has to make 30 copies of the first frame, *and* 30 copies of the last frame.
[21:07:12 CET] <kepstin> mfwitten: it can't really pass through the eof timestamp untouched, because the fps filter changes the timebase.
[21:07:29 CET] <kepstin> pass mode just ensures that the last frame is never dropped
[21:08:27 CET] <mfwitten> kepstin: I agree, but the docs are a bit wrongheaded
[21:09:09 CET] <kepstin> yeah, the docs could probably use some updates there. I think that part is untouched from the old version of the fps filter that dealt only with frames.
[21:12:15 CET] <mfwitten> kepstin: Just for clarification, what is the main purpose of the EOF timestamp; is it just to optimize the fact that the last frame remains displayed until that timestamp?
[21:13:44 CET] <kepstin> mfwitten: my understanding is that the purpose of the eof timestamp is to preserve the time that the last frame is displayed until across filters that might change things like framerate.
[21:16:08 CET] <mfwitten> kepstin: I see. I feel like the user should be responsible for handling those calculations himself.
[21:16:13 CET] <kepstin> fixing the particular issue you're hitting could be done by either having setpts also adjust the eof time using the same formula as the per-frame pts times (i'm not sure if this'll always work, since some variables might not be available), or just by having it reset the eof time to AV_NOPTS_VALUE
[21:18:01 CET] <kepstin> the latter is basically the equivalent of saying "well, i dunno what the user did with timestamps but it could have been anything, so i'm pretty sure the original eof isn't valid any more"
[21:20:21 CET] <kepstin> note that the fps isn't the only thing affected - pretty much any framesync based filter (most filters with multiple inputs), including things like overlay, will use the eof timestamp.
[21:21:08 CET] <kepstin> so e.g. if you were overlaying your setpts-adjusted video over something else with eof_action=pass, it would stay on screen for the extra length of time rather than disappearing when you expected.
[21:22:51 CET] <kepstin> filters like overlay let you put video with one framerate over video with a different framerate, so it might have to duplicate the last frame in order for the duration to be as expected.
[21:25:07 CET] <mfwitten> kepstin: Maybe it would be better to force users to think about syncing their sources manually. I'm still skeptical
[21:26:30 CET] <kepstin> i mean, we could force people to convert both inputs to constant framerate and then manually duplicate the last frame if needed using tpad before overlaying videos, but that would be both very inconvenient, and mean that you can't use overlay with variable framerate stuff at all
[21:27:07 CET] <kepstin> whereas now it just works :/
[21:27:32 CET] <kepstin> (and it will also just work with the setpts filter, once the bug where it doesn't reset eof timestamp is fixed)
[21:28:41 CET] <mfwitten> kepstin: Yeah, but, does it *really* just work? Duplicating frames is not what *I* would choose; I'd use a more sophisticated `minterpolate' or whatever, if applicable.
[21:28:58 CET] <kepstin> fps filter fills in gaps by duplicating frames
[21:29:04 CET] <kepstin> if you want something else, use a different filter
[21:29:12 CET] <kepstin> it treats the last frame the same as any other frame
[21:29:24 CET] <mfwitten> kepstin: Well, I was going to. I was just playing around; I had no intention whatsoever of use `fps'
[21:29:51 CET] <kepstin> but i'd expect the 'framerate' and 'minterpolate' filters to have similar eof behaviour
[21:30:06 CET] <mfwitten> kepstin: My point is that I don't agree that it just works; there's a difference between working and not producing an error.
[21:30:41 CET] <mfwitten> kepstin: Yes, they might. And that's exactly why I'm skeptical. Essentially, someone has made a design choice that takes control away from me, the user.
[21:31:08 CET] <kepstin> you hit a bug in the setpts filter.
[21:31:11 CET] <kepstin> it's a bug :/
[21:31:51 CET] <kepstin> if the setpts filter had correctly reset or recalculated the eof, your filter chain would have worked as you expected, and we wouldn't be having this conversation at all.
[21:32:06 CET] <mfwitten> kepstin: You're going to have people doing overlays, and begging in forums for help on making their videos look smooth [at the end]
[21:33:11 CET] <kepstin> not sure what you mean - in cases where the eof timestamp isn't broken, the last frame would behave exactly the same as any other frame in the video (duplicated if necessary to increase framerate to match the base video)
[21:33:27 CET] <kepstin> so if it's "not smooth", they'd notice that on earlier frames well before the last frame
[21:34:27 CET] <kepstin> all of the filters work by assuming the duration of a frame is "next frame's pts - current frame's pts"
[21:34:42 CET] <kepstin> but the last frame doesn't have a next frame, so the eof timestamp fills in that role
[21:37:31 CET] <mfwitten> kepstin: The overlay filter is choosing a particular way to sync the frames; instead, it should make the user think about what he wants to do. Secondly, what to do with the last frame is up to the player; it's up to whatever is *consuming* the stream of frames. Maybe ffmpeg shouldn't be making choices for consumers it knows nothing about
[21:38:15 CET] <mfwitten> Does the player simply display the last frame and then stop doing anything? Or, does it shove in a black frame with the words THE END?
[21:38:18 CET] <kepstin> i mean, if you're overlaying a 6fps video over a 24fps video, what other option is there than "repeat each frame 4 times"?
[21:38:38 CET] <pink_mist> magic
[21:39:14 CET] <mfwitten> kepstin: minterpolate instead? The overlay filter should just merge 2 synced streams, right?
[21:39:47 CET] <kepstin> but the top video is 6fps, so duplicating it preserves exactly what it looks like when played back standalone
[21:40:04 CET] <kepstin> minterpolate adds tons of motion artifacts and looks horrible on animation, for example
[21:40:17 CET] <mfwitten> kepstin: But that's a choice. The overlay filter is more complicated than it should be; it's doing syncing for you
[21:40:20 CET] <kepstin> mfwitten: i've actually already said what players do, earlier, but to repeat myself: they either hold the last frame on screen until the audio ends, display the last frame for the same amount of time as the frame before it, or don't show the last frame at all.
[21:40:24 CET] <mfwitten> As a result, you've got all this EOF stuff
[21:40:34 CET] <kepstin> mfwitten: it has to handle syncing. that's its job.
[21:41:20 CET] <mfwitten> kepstin: I'd say overlying is its job.
[21:41:31 CET] <kepstin> the only other way to do the overlay filter would be to require both inputs are constant framerate with the same framerate, and then it can't handle vfr content at all
[21:41:32 CET] <mfwitten> kepstin: As for what a player does, you have certainly listed choices.
[21:42:12 CET] <mfwitten> kepstin: Why would it have to be constant?
[21:42:31 CET] <kepstin> mfwitten: because otherwise the streams wouldn't be in sync
[21:43:01 CET] <kepstin> if you want to overlay one thing over another in sync, and the overlay filter isn't allowed to handle syncing timestamps, then you have to provide pairs of frames that are already in sync
[21:43:13 CET] <mfwitten> Yes
[21:43:37 CET] <mfwitten> I'm just saying that I suspect that sort of design choice would make more sense to me
[21:43:51 CET] <kepstin> well, that certainly would make it a lot harder to use ffmpeg
[21:43:55 CET] <mfwitten> EOF seems like a symptom of a wrong choice
[21:44:42 CET] <kepstin> this has nothing to do with eof, other than that eof is used as a way to represent the duration of the last video frame. These choices apply to the duration of every individual frame in the stream
[21:45:16 CET] <kepstin> anyways, i've made a note to look into fixing the eof behaviour of the setpts filter, and that'll fix the issue you've experienced. I'm done here for now.
[21:45:35 CET] <mfwitten> OK
[21:45:41 CET] <mfwitten> kepstin: I'll submit that report soon
[22:08:52 CET] <cfaber> hey, can I specify multiple vf's like -vf filter1 filter2 filter3 ?
[22:12:50 CET] <durandal_1707> cfaber: -vf filter1,filter2, ...
[22:15:24 CET] <cfaber> thanks
[22:16:14 CET] <cfaber> does order matter? in my case, I'm scaling then burning subtitles
[22:17:08 CET] <durandal_1707> order matter, think what is best way
[22:18:11 CET] <cfaber> okay thanks, so if I set subtitles first, it will burn those in, then scale everything (reducing the quality of the text) ?
[22:18:24 CET] <durandal_1707> yes
[22:26:58 CET] <cfaber> Thanks
[22:39:43 CET] <mfwitten> kepstin: https://trac.ffmpeg.org/ticket/7716
[00:00:00 CET] --- Tue Feb  5 2019