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

[burek]

[00:00:10 CEST] <kepstin> ztube: well, do you want to write a libdvdread/libdvdnav input format for ffmpeg? :/
[00:02:17 CEST] <ztube> Well I don't have any experience with that ^^ So propably not
[00:12:07 CEST] <furq> ztube: tccat from transcode does an ok job
[00:12:31 CEST] <furq> a bunch of distros stopped packaging it for some reason though
[00:13:14 CEST] <kepstin> furq: do you know if it grabs the audio/subtitle track language metadata?
[00:13:39 CEST] <furq> no idea
[00:13:57 CEST] <ztube> I'll try
[00:15:53 CEST] <ztube> just had a look at the IFO with a hex editor, seems as if it is quite easy for a human to determine the metadata, however the order of the tracks seems to be scrambled by ffmpeg, that's strange. Could this be due to multithreading when repacking into mkv?
[00:17:14 CEST] <furq>     Stream #0:3[0x20]: Subtitle: dvd_subtitle
[00:17:17 CEST] <furq> doesn't look like it
[00:17:25 CEST] <furq> i forget if metadata shows up there though
[00:18:19 CEST] <fulaphex> hello, I'm trying to stream my desktop to another linux machine, but I find the documentation extremely complicated and I don't know what exactly I'm trying to set up
[00:19:49 CEST] <ztube> https://pastebin.com/YedYjDYe This is the important part of an IFO in a hex editor. The first part would match the audio tracks, and the second one the subtitles respectively. Strangely enough there is only one english audio track in the resulting file, whereas in the IFO there are multiple ones
[00:19:54 CEST] <fulaphex> what kind of command should I run from the pc that's creating the stream? how should I connect to the stream from another machine? will the stream be accessible on ip:port? or do I need to specify in ffmpeg to which macine I'm streaming?
[00:20:09 CEST] <kepstin> ztube: some other fun issues with using ffmpeg to read vob files directly include that it doesn't know the aspect ratio, and it can't handle multi-angle stuff
[00:20:56 CEST] <kepstin> ztube: libdvdnav already abstracts all that stuff away, the way to do this properly is to use libdvdnav to read the dvd structure :/
[00:21:17 CEST] <furq> it'll mess up stuff like subtitle palettes as well
[00:21:36 CEST] <kepstin> hmm, yeah, the palettes are in the ifo too, aren't they
[00:21:39 CEST] <furq> yeah
[00:21:50 CEST] <ztube> I typically don't have multiple angles and aspect ratio seems to work properly as well, my only problem is the metadata
[00:22:05 CEST] <kepstin> trust me, the aspect ratio is wrong ;)
[00:22:32 CEST] <furq> yeah if you're not setting the ar somewhere then it's definitely wrong
[00:25:01 CEST] <ztube> Hmm maybe some combination of lsdvd and mkvpropedit, sounds really error-prone though
[00:25:18 CEST] <kepstin> i think ffmpeg will just use 1:1 sar when reading vob files? which will make the resulting aspect ratio somewhere in-between fullscreen and widescreen
[00:25:49 CEST] <kepstin> (for ntsc, i can't remember how pal aspect ratios work)
[00:26:45 CEST] <ztube> Aspect ratio is just metadata aswell for mkv right? then it should be possible to change it quickly
[00:27:02 CEST] <kepstin> you can override it at the container level in mkv, yes
[00:27:57 CEST] <ztube> Since lsdvd tells me the aspect ratio, I could write a script for that
[00:28:47 CEST] <ztube> However I still have the issue of ffmpeg scrambling the subtitles/audio tracks
[00:30:47 CEST] <kepstin> i think it normally puts them in the order of their stream ids? but vob is one of those kinda weird formats, so they might be in the order of "whichever stream's packets it sees first"
[00:31:30 CEST] <ztube> ffmpeg -analyzeduration 1000M -probesize 1000M -fflags +genpts -i CONCAT.VOB -c copy -threads 4 -map 0:v -map 0:a -map 0:s "/media/video/$TITLE/$TITLE.mkv"
[00:32:03 CEST] <kepstin> yeah, checked on a couple files with ffprobe, they're in random order
[00:32:25 CEST] <kepstin> your best option might be to check what order they're in the file with ffprobe - that'll match the order that ffmpeg writes them to the mkv
[00:32:46 CEST] <ztube> For audio at least the first track is at the right position, however after that it seems to be exactly reversed
[00:33:03 CEST] <kepstin> the "id" field in ffprobe -show_streams should match some info from lsdvd, probably
[00:56:26 CEST] <furq> ztube: the easiest and probably most correct way of setting ar from a dvd source is -vf setsar=12/11
[00:56:36 CEST] <furq> or whatever it says in https://en.wikipedia.org/wiki/Pixel_aspect_ratio#Pixel_aspect_ratios_of_common_video_formats
[00:57:01 CEST] <furq> you can set it in the container but you should only really do that if you already encoded something and don't want to do it again
[00:57:10 CEST] <furq> and also remember you need to adjust for any cropping you did
[00:59:14 CEST] <furq> it'd be nice to have ITU_PAL_FS = 12/11 constants in setsar
[00:59:16 CEST] <furq> or something along those lines
[07:22:20 CEST] <TheDcoder> Hello everyone, I am downloading audio from an online video stream and it is encoded in AAC (audio/mp4;codecs=mp4a.40.5), however when I play it back, the audio is feels much deeper (the voice of a female sounds very deep)
[07:23:07 CEST] <TheDcoder> I have no idea why, the browser is able to play it back properly, any way I can restore the audio?
[07:23:27 CEST] <TheDcoder> The audio also seems to have some degradation in quality... not sure why
[12:46:42 CEST] <neildarlow> loudnorm and dual_mono. If I set my single-channel mono podcast target TP to -16 will dual_mono reduce TP to -19? Do I have to specify dual_mono on both passes of loudnorm in two-pass mode?
[13:03:30 CEST] <ralphcor> Hi, I want to pluck A&V from the middle of an MP4.  I've read https://trac.ffmpeg.org/wiki/Seeking and I'm doing  ffmpeg -ss $from -i in.mp4 -t $len -c:v copy -c:a copy -sn out.mp4  I understand why the video starts from the I-frame before the -ss, and that if I transcoded then I would get an accurate cut, but I want to copy.  However, I'd be happy to transcode the initial fragment from the -ss to the next
[13:03:32 CEST] <ralphcor> I-frame and then copy from then on.  I'm surprised that I failed to find how to do this, simply, anyway.  Keen to hear learned opinion.  Thanks.
[13:04:08 CEST] <JEEB> that needs its own implementation and you'd have to be able to match the configuration of the original stream well enough
[13:04:25 CEST] <JEEB> so that the parmaeter sets with H.264 or HEVC for example would match what's in the original stream
[13:04:44 CEST] <ralphcor> Ah, okay, otherwise the `join' would be noticeable?
[13:05:24 CEST] <JEEB> the newly transcoded stuff would have a different required parameter sets and that would cause decoding issues for the newly added stuff
[13:06:22 CEST] <ralphcor> Oh, I didn't realise that information flowed across I-frame boundaries.  I thought that each run of frame starting with I-frame was self-contained.  I see.
[13:07:38 CEST] <ralphcor> It's h264 (Main) (avc1 / 0x31637661) BTW.
[13:12:24 CEST] <cehoyos> "decoding issues" == it would fail hard
[13:12:48 CEST] <cehoyos> Note that while it would work fine for older codecs, the feature was never implemented
[13:12:57 CEST] <cehoyos> in FFmpeg
[13:13:46 CEST] <JEEB> ralphcor: parameter sets are the initialization data for the stream. while you can have multiple, synchronizing them can be fun and thus generally you keep to a single set of them
[13:14:06 CEST] <JEEB> thus your newly transcoded content should in such cases match the original content to make sure there are no issues with decoding
[13:16:01 CEST] <ralphcor> Right, so otherwise it would have to be PSets for the transcoded intro and then the original PSets inserted for the following copy.
[13:19:08 CEST] <JEEB> yup
[17:40:10 CEST] <cehoyos> Is the ivf guy around?
[17:40:27 CEST] <cehoyos> Chagall: Are you here?
[17:41:29 CEST] <Chagall> yes
[17:42:30 CEST] <cehoyos> How did you test your patch?
[17:43:39 CEST] <cehoyos> I don't think it works and I think it works without your patch.
[17:43:47 CEST] <cehoyos> (as written yesterday)
[17:45:15 CEST] <Chagall> ah, I didn't see anything in my log, sorry
[17:46:08 CEST] <cehoyos> [23:30:16 CEST] <cehoyos> FFmpeg does write the video duration
[17:48:17 CEST] <cehoyos> Note that you are claiming on the mailing list that the file "ivf_parser.h" "handles" a field - header files in general do not handle anything, it seems to me that the corresponding C++ file also does not "handle" the duration (but I may be wrong)
[17:48:39 CEST] <cehoyos> Anyway: Please test again without your patch and if you can reproduce the issue you are trying to fix, please tell me how!
[17:54:52 CEST] <Chagall> still rebuilding to check
[17:55:41 CEST] <Chagall> I lost your message(s) in scrollback so I wasn't careful, mb
[17:56:27 CEST] <cehoyos> The duration and the time_base are closely related: It is not useful to write the number of frames if the time_base is not the inverse of the framerate (which it might be)
[17:56:43 CEST] <cehoyos> But FFmpeg already writes the duration (unless you kill the application hard)
[17:56:58 CEST] <cehoyos> or the output file is not seekable
[17:57:04 CEST] <cehoyos> What did you lose?
[17:59:01 CEST] <Chagall> about 20 mins around the message you just reposted
[17:59:22 CEST] <cehoyos> You mean you lost yesterday's history, not today?
[17:59:29 CEST] <Chagall> yes
[17:59:44 CEST] <cehoyos> There was no more about the duration than my comment above.
[18:15:57 CEST] <Chagall> it seems the program i'm using might not be fetching the number of frames correctly, because i'm getting identical output before and after, though it doesn't seem to be correct. with the master branch just compiled i'm also getting invalid timestamps from mpv, though as you mentioned seeking works so the duration seems coded correctly. again though no visible difference with my patch that I've been able to verify
[18:18:54 CEST] <cehoyos> It would make more sense if you run ffmpeg -i on the output file to see if a duration was written and is read by FFmpeg.
[18:22:02 CEST] <Chagall> cehoyos: I get a duration of 708:16:00.00 for a clip that's a few seconds converted from mp4 with a time base that's not the framerate's inverse
[18:22:08 CEST] <Chagall> same on master, btw
[18:22:23 CEST] <cehoyos> So there is a bug, good to know!
[18:22:44 CEST] <cehoyos> I only have to reproduce it now...
[18:22:46 CEST] <Chagall> I don't think IVF has an actual "duration" field does it? it must be inferred from pts and display rate
[18:22:53 CEST] <cehoyos> What do you mean with "same on master"?
[18:23:24 CEST] <Chagall> my installed ffmpeg is built from master
[18:23:32 CEST] <Chagall> and I test my change with a local build
[18:23:42 CEST] <cehoyos> Only master is supported, no other versions
[18:23:53 CEST] <Chagall> N-95183-g97450d2b6a
[18:24:14 CEST] <Chagall> maybe from yesterday
[18:25:08 CEST] <cehoyos> I cannot reproduce...
[18:25:29 CEST] <Chagall> cehoyos: with what commands/clips?
[18:25:31 CEST] <cehoyos> Remuxing vp9 from mp4 to ivf leads to a file that shows the same duration as the mp4 file (the actual duration)
[18:25:52 CEST] <Chagall> can you send the vp9 sample?
[18:25:57 CEST] <cehoyos> ffmpeg -i input -vcodec vp9 -an out.mp4 && ffmpeg -i out.mp4 -vcodec copy out.ivf
[18:26:23 CEST] <cehoyos> You can use -f lavfi -i testsrc2 to create a vp9 sample which will allow us to test the same thing
[18:26:55 CEST] <cehoyos> I used fate-suite/svq3/Vertical400kbit.sorenson3.mov as input
[18:26:56 CEST] <Chagall> ok
[18:27:16 CEST] <cehoyos> As expected, a timebase of 15360 was written
[18:29:22 CEST] <Chagall> still an absurd duration on my end
[18:29:44 CEST] <Chagall> um, time base seems wrong actually, it is 25
[18:30:34 CEST] <Chagall> I will rebuild again
[18:32:13 CEST] <kepstin> from a quick look, i think ffmpeg might be writing/reading duration from the ivf field header that's supposed to hold frame count?
[18:32:28 CEST] <cehoyos> I successfully tested the following: ffmpeg -f lavfi -i testsrc2 -vcodec vp9 -t 3.5 out.mp4 && ffmpeg -i out.mp4 -vcodec copy out.ivf
[18:32:46 CEST] <cehoyos> It makes no sense to write the frame count (unless the time_base is 1/framerate)
[18:33:17 CEST] <kepstin> sure it doesn't make any sense, but it is what it is
[18:34:27 CEST] <cehoyos> The assumption that we should not honour the existing fields but some text makes not much sense in general and is known to be wrong for things related to VPx (where the specification only has an informatioal character)
[18:34:33 CEST] <kepstin> libvpx for reference: https://github.com/webmproject/libvpx/blob/master/ivfenc.c#L31
[18:34:40 CEST] <kepstin> writes a 32bit frame count
[18:35:25 CEST] <cehoyos> That can lead to a wrong duration
[18:36:05 CEST] <cehoyos> Please note the comment! ;-)
[18:36:12 CEST] <kepstin> yep, if you read the frame count field from the ivf field as a duration, then you will get the wrong duration
[18:36:20 CEST] <cehoyos> Read the comment!
[18:37:05 CEST] <cehoyos> Note that I did not say that this will lead to a wrong "length" in libvpx, it would lead to a wrong length if used 1:1 in FFmpeg
[18:37:48 CEST] <cehoyos> I suspect that in libvpx, the assumptions time_base == 1/framerate and cfr will hold.
[18:41:19 CEST] <kepstin> that appears to be true in most cases, but vpxenc does allow arbitrary rational timebases.
[18:41:25 CEST] <kepstin> (and still writes frame count)
[18:41:42 CEST] <cehoyos> Then - according to the comment in the code - you have found a bug in libvpx
[18:42:11 CEST] <Chagall> "length" is ambiguous, does not imply the same thing as duration IMO
[18:42:13 CEST] <kepstin> which comment, the one-word comment "length" that can be interpreted ambiguously as either "length in frames" or "length in timebase units"?
[18:43:08 CEST] <kepstin> https://chromium.googlesource.com/chromium/src/media/+/master/filters/ivf_parser.h explicitly says "number of frames in file" fwiw
[18:43:17 CEST] <cehoyos> Please understand that there are (literally) hundred of known and many unknown bugs in FFmpeg that are reproducible and wait for someone to work on them - you have not found a bug today.
[18:43:59 CEST] <kepstin> that chromium code also uses a 32bit field, not 64bit.
[18:44:38 CEST] <cehoyos> Patch probably welcome!
[19:05:21 CEST] <Chagall> cehoyos: sent a patch for that then.
[19:05:45 CEST] <Chagall> not going to argue about length but I added a comment to clarify at least can split into 2 commits if preferred
[19:06:18 CEST] <cehoyos> Did you test fate with the patch applied?
[19:06:21 CEST] <Chagall> yes
[19:06:26 CEST] <cehoyos> The comment should be a separate patch.
[19:06:43 CEST] <Chagall> ok.
[19:06:52 CEST] <cehoyos> The second one is unneeded though
[19:07:35 CEST] <kepstin> Chagall: the demuxer should save the frame count into st->nb_frames not st->duration i think
[19:07:47 CEST] <Chagall> it's confusing to read the code without it and does not change the line count
[19:08:10 CEST] <Chagall> like I said I won't argue about length vs frame count
[19:08:17 CEST] <Chagall> leaving that how it is
[19:09:27 CEST] <kepstin> i'm too lazy to send it to the ml right now, but here's my more complete fix: https://www.kepstin.ca/dump/0001-ivfdec-ivfenc-Match-behaviour-of-libvpx-and-chromium.patch
[19:10:02 CEST] <cehoyos> Breaks the command line I posted above
[19:10:24 CEST] <cehoyos> Sorry: Breaks all command lines (no duration)
[19:10:33 CEST] <kepstin> exactly, because ivf doesn't store a duration
[19:10:53 CEST] <cehoyos> This is not a helpful comment
[19:11:17 CEST] <cehoyos> I am not a native speaker but "lenght" is certainly not the number of frames
[19:11:28 CEST] <cehoyos> I am not a native speaker but "length" is certainly not the number of frames
[19:11:34 CEST] <kepstin> https://chromium.googlesource.com/chromium/src/media/+/1681b9abff73fe0e3d0932aefdab4f039a284d1a/filters/ivf_parser.h#34 has a better comment then
[19:11:52 CEST] <kepstin> and "length" is ambiguous - number of frames is one way of counting length
[19:12:05 CEST] <cehoyos> No, the world is not cfr
[19:12:33 CEST] <kepstin> the ivf format is an extremely simple format where the creators apparently didn't realize that, and so they didn't include a correct duration field
[19:13:20 CEST] <cehoyos> You will have to agree to disagree with the FFmpeg developers
[19:13:34 CEST] <kepstin> ffmpeg disagrees with libvpx, which is a bigger problem
[19:13:42 CEST] <cehoyos> I don't think it does
[19:14:01 CEST] <kepstin> libvpx writes a *frame count* field. I've provided references in my commit message in my patch that show that
[19:14:13 CEST] <kepstin> chromium's parser explicitly documents a *frame count* field
[19:14:25 CEST] <cehoyos> Yes, for libvpx this is the "length" of the stream. In FFmpeg, it wouldn't be
[19:14:31 CEST] <cehoyos> Can we stop this?
[19:14:41 CEST] <cehoyos> Just send your patch to the mailing list, I may be wrong after all
[19:14:51 CEST] <kepstin> libvpx writes a frame count even if you set a timebase which is not 1/framerate
[19:15:01 CEST] <kepstin> (specifically, vpxenc.c)
[19:15:13 CEST] <cehoyos> As said, please stop it
[19:17:34 CEST] <Chagall> kepstin: please do send it to ML
[19:18:28 CEST] <kepstin> let me at least compile-check it and make sure it either doesn't break fate or that i update fate tests, first :)
[19:32:48 CEST] <Chagall> cehoyos: should avformat patch version increase with the 64-bit to 32-bit field change?
[19:33:07 CEST] <cehoyos> Not if you only change the demuxer as requested
[19:33:40 CEST] <Chagall> got it
[19:33:44 CEST] <cehoyos> You can of course bump micro on every patch but some developers don't like it because it triggers a recompilation of the whole library
[19:48:15 CEST] <Diag> hey regarding a few weeks ago when i was gonna build ffmpeg on my ps3
[19:48:52 CEST] <Diag> it was building and something failed because of a missing dependency, got distracted, redid thermal shit and other shit
[19:49:19 CEST] <Diag> at some point along the way it randomly decided to stop working and i couldnt be assed to start investigating it yet, so
[20:08:27 CEST] <safinaskar> hi. i want to generate raw uncompressed rgb video from my c program without external libs and then feed it to ffmpeg, i. e. i want ffmpeg to convert this raw video to some "normal" format.     also i want such raw video to contain very minimal metainformation about this video (in fact, i need frame size only).   so, i need some file format (or
[20:08:27 CEST] <safinaskar> "muxer" or "container" in ffmpeg term), that should be very simple (so that i can generate it from my program easily) and that should contain frame size. in other words i need something like blind ( https://tools.suckless.org/blind/ ), but blind itself will not go, because it is not rgb and because it is not supported by ffmpeg.           "-f
[20:08:28 CEST] <safinaskar> rawvideo" will not go, because such rawvideo doesn't contain frame size.           "-f yuv4mpegpipe" will not go, because it is YUV, but i need RGB.         "-f nut" is good candidate. as well as i know nut supports storing raw video. but nut's spec is too difficult for me.        so?
[20:09:26 CEST] <cehoyos> You will have to decide: Either "rawvideo" or "metadata"
[20:09:40 CEST] <furq> ppm pipe maybe
[20:09:58 CEST] <furq> or bmp pipe if you don't mind sending every row backwards
[20:12:15 CEST] <furq> http://netpbm.sourceforge.net/doc/ppm.html#format
[20:12:31 CEST] <furq> then -f image2pipe -c:v ppm -i -
[20:13:30 CEST] <safinaskar> cehoyos: "Either "rawvideo" or "metadata"" - i choose metadata
[20:13:42 CEST] <safinaskar> cehoyos: i mean uncompressed video with metadata
[20:13:47 CEST] <furq> safinaskar: ^
[20:14:05 CEST] <furq> if you only care about frame size and not framerate etc then ppm pipe is the easiest way out
[20:21:12 CEST] <safinaskar> ok, thanks, i choose ppm pipe
[21:33:34 CEST] <taliho> Hi, I'm muxing h264 into flv with
[21:33:52 CEST] <taliho> ./ffmpeg -f mpegts -i udp://192.168.0.104:6500 -map 0:0 -codec:v libx264 -x264-params keyint=100:scenecut=0 -bsf:v extract_extradata -f flv udp://127.0.0.1:10000
[21:36:29 CEST] <taliho> the resolution of my input can change so that's why I have the bsf filter. My goal is flv to resend the headers when parameter sets change so this can be detected by the server (please ignore desting udp, I'm actually using rtmp)
[21:37:16 CEST] <taliho> but it seems that when muxing with flv all the pps/sps parameter sets disappear from the stream, so the bsf filter is actually not inserting any data
[21:37:46 CEST] <cehoyos> I don't think ffmpeg supports changing output resolutions
[21:37:59 CEST] <cehoyos> And I don't think you need the filter
[21:39:57 CEST] <taliho> ok, let me just try to dump raw to udp and if I see a resolution change
[21:40:33 CEST] <cehoyos> If you increase verbosity, you should get a message that a scaling filter was inserted
[21:45:21 CEST] <JEEB> &25
[21:50:31 CEST] <djp_> looking for advice regards using deinterlacing. i've dumped a dvd to my hard disk and checked it using the mediainfo command. it shows that the dvd is interlaced and its scan order is top field first. i've been using variations of commands with the yadif filter, for example "-vf yadif=1:-1:0". i've also tried "-vf yadif=1:-1:0,mcdeint=2:1:10" but this takes an age!!! is there a recommended solution for deinterlacing a dvd rip or is it best to leave it alone
[21:50:31 CEST] <djp_> and let the media player deal with it?
[21:53:07 CEST] <cehoyos> mediainfo cannot tell you if the video is interlaced
[21:53:11 CEST] <cehoyos> the idet filter can
[21:53:26 CEST] <cehoyos> mcdeint is slow
[21:56:31 CEST] <furq> djp_: if you're not going to use something incredibly slow then you might as well just encode it interlaced and deinterlace it on playback
[21:56:40 CEST] <furq> mpv et al just use yadif anyway
[21:56:53 CEST] <djp_> cehoyos, oh i see. so i should ignore the output that reads "Scan type: Interlaced" and "Scan order: Top Field First" when running mediainfo?
[21:57:00 CEST] <furq> all dvds say that
[21:57:17 CEST] <furq> you're best off just looking at it
[21:57:33 CEST] <djp_> furq, ah right. sure.
[21:57:40 CEST] <furq> anyway personally i like vapoursynth qtgmc for dvds
[21:57:40 CEST] <JEEB> content != coding, unfortunately
[21:57:48 CEST] <furq> but that's a whole lot of stuff to set up
[21:57:59 CEST] <furq> and also very slow
[21:59:31 CEST] <der_richter> and it won't ITVC, which is also likely needed for DVDs
[21:59:40 CEST] <cehoyos> If you have many dvd's you don't have to look, you can also use idet
[21:59:46 CEST] <furq> well it'll usually be one or the other
[22:00:01 CEST] <djp_> furq, so using mcdeint is probably a good option, as long as time is not an issue. otherwise just let the player do the work.
[22:00:02 CEST] <furq> ivtc for film, deinterlace for video
[22:00:14 CEST] <cehoyos> Mixed telecined and interlaced exists
[22:00:26 CEST] <furq> if you're very unlucky, sure
[22:00:32 CEST] <cehoyos> yadif should be a lot faster than mcdeint
[22:00:38 CEST] <der_richter> there is also mixed DVDs
[22:00:59 CEST] <djp_> cehoyos, mixed telecined? i think i have that on some old studio ghibli dvds?
[22:00:59 CEST] <furq> i've only ever encountered one
[22:00:59 CEST] <der_richter> what cehoyos said
[22:01:02 CEST] <furq> perks of living in a pal region
[22:01:08 CEST] <taliho> cehoyos: thanks. I think you are right, it seems that a scaling filter is inserted when the input resolution changes. Although, I do not see a log message even with trace
[22:01:25 CEST] <cehoyos> Should be verbose
[22:01:32 CEST] <djp_> cehoyos, yes, if i use yadif on its own, it is fast.
[22:01:36 CEST] <der_richter> pal DVDs can also be kinda cool, like speed up progressive material. easy to fix.
[22:01:55 CEST] <taliho> cehoyos: sorry the message is there :)
[22:01:57 CEST] <cehoyos> I still like yadif's quality but there may be better filters
[22:02:09 CEST] <furq> bwdif is supposedly slightly better than yadif
[22:02:17 CEST] <furq> neither is particularly amazing on sd content though
[22:02:30 CEST] <kepstin> i find yadif has slightly annoying artifacts on diagonal lines in sd content.
[22:02:33 CEST] <furq> yeah
[22:02:44 CEST] <furq> i've never used anything other than qtgmc that didn't have those
[22:03:01 CEST] <furq> with that said i could never get mcdeint working right
[22:03:10 CEST] <furq> and ffmpeg nnedi3 is just a waste of time
[22:03:23 CEST] <durandal_1707> shit talk from furq
[22:03:53 CEST] <kepstin> well, at least if you leave ffmpeg nnedi3 running in the background on a modern multi-core computer, it won't interfere with anything else you're doing ;)
[22:03:55 CEST] <djp_> cehoyos, are my settings correct for yadif? "yadif=1:-1:0".
[22:04:23 CEST] <furq> someone should try to convince the nnedi3cl author to relicense it under lgpl
[22:05:09 CEST] <cehoyos> djp_: It depends - do you want to double framerate?
[22:05:39 CEST] <kepstin> djp_: fwiw, that's equivalent to "yadif=mode=send_field" (all the other options listed are defaults)
[22:06:03 CEST] <cehoyos> (doubling framerate likely doubles encoding time)
[22:06:11 CEST] <djp_> cehoyos, not sure. is that a good option or should i keep it as is?
[22:06:27 CEST] <furq> you generally want to double the framerate when deinterlacing
[22:06:36 CEST] <djp_> cehoyos, doesn't make much of a difference in my encoding time.
[22:06:40 CEST] <furq> it'll look a lot nicer and it won't hurt the size that much
[22:06:47 CEST] <kepstin> it makes motion look smoother - preserves the motion from both fields in the interlaced video
[22:06:53 CEST] <furq> it will definitely take longer to encode though
[22:07:02 CEST] <djp_> ok
[22:07:14 CEST] <furq> you'll get roughly the same fps but obviously there's 2x as many frames
[22:07:31 CEST] <durandal_1707> w3fdif
[22:07:38 CEST] <djp_> so i need to check that. thanks cehoyos , furq , kepstin and all.
[22:09:12 CEST] <kepstin> i normally use bwdif, which in theory combines the strengths of yadif and w3fdif. But you should compare a few, pick the one that looks best on your video.
[22:13:04 CEST] <taliho> cehoyos: do you think a resolution change would be an interesting feature to support? I guess just a reset of the all the components down the chain is needed.. It's something that I could work on
[22:14:34 CEST] <cehoyos> It was just implemented;-)
[22:14:36 CEST] <cehoyos> (iirc)
[22:14:41 CEST] <cehoyos> But so far only for vp9
[22:14:56 CEST] <cehoyos> You should test first if it works in your use-case
[22:15:03 CEST] <cehoyos> Or maybe it does work for x264?
[22:15:06 CEST] <JEEB> hmm, I think libx264 had reconfig for quite a while
[22:15:16 CEST] <JEEB> but it didn't work f.ex. for colorspace info changes
[22:15:27 CEST] <cehoyos> No
[22:15:31 CEST] <JEEB> for example if you don't at encoder init yet know the colorspace etc
[22:15:39 CEST] <cehoyos> But test with vpx first
[22:15:57 CEST] <taliho> I see, thanks, will look at that code
[22:16:25 CEST] <JEEB> but yea, x264 mostly supported dynamic reconfig without major changes? and then you might have to re-init in your wrapper if you needed bigger changes.
[22:17:07 CEST] <JEEB> and of course this would mostly work for in-band containers unless you somehow signal the new extradata :)
[22:17:47 CEST] <cehoyos> https://ffmpeg.org/pipermail/ffmpeg-devel/2019-August/247365.html
[22:17:54 CEST] <cehoyos> It seems the patch was not applied yet
[22:18:04 CEST] <JEEB> :)
[22:18:54 CEST] <taliho> thanks JEEB, cehoyos
[00:00:00 CEST] --- Wed Oct  2 2019