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

[burek]

[00:10:24 CEST] <fling> Where can I find https://roundup.ffmpeg.org/file1098/utils.c.patch ?
[00:10:36 CEST] <fling> the one mentioned here -> https://stackoverflow.com/questions/3774853/ffmpeg-av-interleaved-write-frame-operation-not-permitted
[00:12:38 CEST] <BtbN> "8 years, 11 months ago"
[00:16:42 CEST] <nicolas17> it's unlikely an 8-year-old patch will apply on current ffmpeg code
[00:22:59 CEST] <fling> ok
[01:06:15 CEST] <rocktop> how can I scroll text from left to right ?
[01:07:18 CEST] <pink_mist> include some .ass subtitles that displays text which you have used .ass commands to animate
[01:09:31 CEST] <rocktop> pink_mist: I never used subtitles
[01:09:46 CEST] <rocktop> can you show me an example please ?
[01:10:02 CEST] <nicolas17> hmm I think you can do it with the drawtext filter
[01:10:43 CEST] <rocktop> nicolas17: yes I know but I can't achieve that there are a complex calculations
[01:10:50 CEST] <pink_mist> I've never used subs for anything remotely like this myself, so no, I can't - I just know it's possible
[02:22:56 CEST] <rocktop> anyidea how to make the text sliding from left to right  ?
[02:27:28 CEST] <DHE> make the X offset in drawtext a formula involving time or frame number. start big, shrink over time.
[02:35:46 CEST] <rocktop> DHE: I only get this x=w-w/3*mod(t\,3*(w+tw)/w)  this scrolling fast from the right to the left I want to make reverse it and make it little slow
[02:37:18 CEST] <rocktop> any idea ?
[03:40:56 CEST] <Aurora_iz_kosmos> Will the use of "-codec copy" for output use compression? Say, going $(ffmpeg -i file.avi -codec copy file.mkv) ?
[03:47:18 CEST] <nicolas17> it will use whatever compression was in the original file
[03:48:48 CEST] <Aurora_iz_kosmos> So it directly copies over the streams without any transcoding? I see. Would the use of "-map 0:0" similarly keep all streams while transcoding?
[03:49:02 CEST] <Aurora_iz_kosmos> Erh, "-map 0"
[03:49:38 CEST] <Aurora_iz_kosmos> I have no idea what I'm doing. I just have a bunch of old media I'm trying to shrink without degrading its quality.
[04:02:27 CEST] <nicolas17> -map is unrelated
[04:02:44 CEST] <nicolas17> it just says picks what streams to use
[04:03:17 CEST] <nicolas17> you won't get any shrinking if you copy without transcoding
[04:07:04 CEST] <Aurora_iz_kosmos> Okay.
[04:09:15 CEST] <Aurora_iz_kosmos> So, would something along the lines of $(find /media/my-old-stuff -type f -iname "*.avi" -print0 | parallel -0 -j 1 ffmpeg -i {} -map 0 {.}.mkv) would do what I think it will?
[04:10:06 CEST] <nicolas17> test with one video alone first :P
[04:10:21 CEST] <nicolas17> you're not specifying any options there so I think that will transcode with mkv's default codec and default quality/bitrate which probably sucks
[04:12:34 CEST] <Aurora_iz_kosmos> Hm. Is there a way to somehow detect each video's input quality and give something similar as output?
[04:12:54 CEST] <nicolas17> not really
[04:13:01 CEST] <nicolas17> what codec do your input videos have?
[04:13:22 CEST] <Aurora_iz_kosmos> I'm not sure. Several different recorders were used over the years.
[04:14:20 CEST] <nicolas17> run ffprobe on one and share a pastebin of the result
[04:16:52 CEST] <Aurora_iz_kosmos> https://pastebin.com/C0Mze0A2
[04:18:52 CEST] <another> you can probably use some lossless codec to compress this
[04:19:04 CEST] <another> mjpeg is not really efficient
[04:19:30 CEST] <Aurora_iz_kosmos> I'd surmised as much when I looked into ip-cams.
[04:19:41 CEST] <nicolas17> each frame is an independent JPEG image
[04:20:06 CEST] <nicolas17> another: I'm surprised *lossless* codecs do better than mjpeg though
[04:20:14 CEST] <another> i think the cut off the additional headers or something, but yes
[04:21:03 CEST] <another> well, you can use interframe prediction
[04:21:59 CEST] <nicolas17> then again I was also surprised when ffv1 did better than h264-lossless in one particular sample...
[04:24:37 CEST] <furq> was that with ultrafast or something
[04:25:14 CEST] <Aurora_iz_kosmos> what sorta codec would you recommend?
[04:25:59 CEST] <furq> you won't shrink any of these without losing quality unless the source is huffyuv or something
[04:26:06 CEST] <furq> so the question is how much quality are you prepared to lose
[04:27:08 CEST] <furq> something like x264 crf 18 will be a lot smaller and almost indistinguishable
[04:27:24 CEST] <furq> you'd really just want to cut some short samples and experiment to see what suits you
[04:28:29 CEST] <Aurora_iz_kosmos> I see. Seems like this project is going to take a lot more time than I'd originally thought. I was asking for recommendations mostly because I know very little about codecs.
[04:29:38 CEST] <furq> also there's no point using parallel if you go with x264 since it'll multithread anyway
[04:29:44 CEST] <furq> unless you're on a dual xeon box or something
[04:30:19 CEST] <Aurora_iz_kosmos> I mostly planned to use it because of the syntax-sugar for extension stripping.
[04:30:28 CEST] <Aurora_iz_kosmos> (Which xargs lacks)
[04:30:56 CEST] <Aurora_iz_kosmos> The "-j 1" flag was meant to keep it linear/serial.
[04:31:05 CEST] <furq> oh right
[04:32:54 CEST] <another> Aurora_iz_kosmos: what is your goal?
[04:33:05 CEST] <furq> well if all of the audio is pcm then you can get one easy win by converting all of that to flac
[04:33:10 CEST] <another> lossless archival?
[04:33:22 CEST] <furq> it won't be a huge win if it's all 11k u8 though
[04:33:27 CEST] <another> or save space while keeping it "good enough"?
[04:33:37 CEST] <Aurora_iz_kosmos> another: Ideally yeah. Though I'd settle for not-eye-distinguishable.
[04:34:16 CEST] <nicolas17> unfortunately the appropriate quality parameters for "not-eye-distinguishable" have to be decided by your own eye and experimenting
[04:34:38 CEST] <another> see here: https://trac.ffmpeg.org/wiki/Encode/H.264
[04:34:44 CEST] <furq> x264 should be good enough and there's only really two settings worth tweaking
[04:34:57 CEST] <furq> crf (lower values = higher quality/bigger file) and preset (slower preset = more cpu usage)
[04:35:37 CEST] <furq> if it's all 480p then it won't take long to encode test samples
[04:35:59 CEST] <furq> this is probably also a good time to do any denoising/deinterlacing or any other cleanup
[04:36:53 CEST] <Aurora_iz_kosmos> I see. Any similar links to read up on those you'd suggest?
[04:37:31 CEST] <Aurora_iz_kosmos> (I might as well do this properly if I'm to do it at all.)
[06:27:32 CEST] <lain98> how do i calculate the frame number at a particular time in seconds. i have stream information. for example i want to know that the frame at 5 seconds is frame number 331.
[06:28:08 CEST] <lain98> i know total number of frames and assume cfr
[06:36:08 CEST] <Oleg_> how do I re-encode a file into a 10-bit hevc file?
[06:36:42 CEST] <Oleg_> I typed:
[06:36:45 CEST] <Oleg_> ffmpeg -i input.mkv -c:v libx265 -c:a copy -max_muxing_queue_size 400 file.mkv
[06:37:03 CEST] <Oleg_> but I think it's re-encoding it into a 8-bit hevc file
[06:37:16 CEST] <lain98> Oleg_: ffmpeg -i pix_fmts. pick one of the 10 bit formats
[06:37:47 CEST] <lain98> such as yuv420p10be i think
[06:39:22 CEST] <Oleg_> lain98, what do you mean? ffmpeg -i input.mkv followed by what?
[06:41:00 CEST] <lain98> ffmpeg -i input.mkv -pix_fmt yuv420pb10e output.mkv
[06:42:10 CEST] <lain98> if your file had 8 bit format then just transcode to 10 bit wont magically increase the bit depth
[06:42:18 CEST] <lain98> its still the same information
[06:42:34 CEST] <lain98> using more bytes
[06:43:50 CEST] <Oleg_> I am trying to transcode a 10-bit h264 file into a 10-bit hevc file
[06:44:08 CEST] <lain98> Oleg_: then it should work imho
[06:44:36 CEST] <Oleg_> I got the message: Unknown pixel format requested: yuv420pb10e
[06:44:37 CEST] <lain98> Oleg_: tbh i dont think you even need to specify the pix_fmt
[06:45:03 CEST] <lain98> Oleg_: its 10be
[06:45:05 CEST] <lain98> not b10e
[06:45:25 CEST] <lain98> also check the pix_fmt in your h264 file first
[06:47:07 CEST] <Oleg_> yuv420p10be ?
[06:47:49 CEST] <lain98> yes
[06:48:08 CEST] <lain98> ffmpeg -pix_fmts shows you all the pix_fmts that ffmpeg supports
[06:50:21 CEST] <Oleg_> it says "yuv420p10be            3            15"
[06:50:51 CEST] <Oleg_> why does it say 15 BITS_PER_PIXEL for yuv420p10be?
[06:51:08 CEST] <lain98> because its 420
[06:51:30 CEST] <lain98> uv planes are half of y
[06:51:50 CEST] <Oleg_> but it definitely stands for 10-bit transcoding?
[06:52:09 CEST] <lain98> y=10 bits and u+v=5 bits
[06:52:41 CEST] <lain98> Oleg_: whats the pix_fmt of your h264 file
[06:53:00 CEST] <Oleg_> ffmpeg pix_fmt input.mkv ?
[06:53:55 CEST] <furq> ffprobe -show_entries stream=pix_fmt input.mkv
[06:54:47 CEST] <lain98> Oleg_: dont think you need to bother about pix_fmt. just trancode the file
[06:54:54 CEST] <Oleg_> pix_fmt=yuv420p10le
[06:55:03 CEST] <Oleg_> that's the output I got
[06:55:07 CEST] <Oleg_> from ffprobe
[06:55:16 CEST] <furq> use that then
[06:56:02 CEST] <Oleg_> if the file has yuv420p10le pix_fmt, that means I gotta use yuv420p10le for transcoding, not yuv420p10be?
[06:56:14 CEST] <furq> either should work but le will be slightly faster
[06:56:28 CEST] <furq> no point shuffling bits around if you don't need to
[06:57:11 CEST] <lain98> q
[06:57:30 CEST] <lain98> sorry i thought i was exiting vim
[06:57:34 CEST] <lain98> :D
[06:57:42 CEST] <Oleg_> if I type
[06:57:46 CEST] <Oleg_> ffmpeg -i input.mkv -pix_fmt yuv420p10le -c:v libx265 -c:a copy file.mkv
[06:57:57 CEST] <Oleg_> will I lose some video quality in the resulting file?
[06:58:02 CEST] <furq> yes
[06:58:21 CEST] <furq> if you don't want to lose quality then don't transcode it
[06:58:57 CEST] <lain98> why will he lose quality ?
[06:59:16 CEST] <lain98> if its the same pixel format and depth
[06:59:29 CEST] <furq> because he's transcoding
[06:59:34 CEST] <lain98> just different codec ?
[06:59:48 CEST] <lain98> oh yeah encoding isnt perfect
[07:00:35 CEST] <furq> Oleg_: you'll want to set -crf and -preset to suit your needs
[07:00:48 CEST] <furq> you will always lose quality but with a low enough crf value you won't notice
[07:01:21 CEST] <lain98> dont think its much either way
[07:01:30 CEST] <Oleg_> what's the lowest possible -crf value?
[07:01:35 CEST] <furq> 0
[07:02:01 CEST] <furq> encode a test clip at 20 and then tune it from there
[07:04:04 CEST] <furq> if the source is hi10p then i assume you also want -tune animation
[07:07:29 CEST] <Oleg_> furg, I am re-encoding the file that was already re-encoded with hi10p
[07:23:43 CEST] <Oleg_> anyway, thanks, guys
[08:32:25 CEST] <lain98> if i have a variable frame rate stream. do avformat_seek_file or av_seek_frame seek to the correct frame ?
[08:33:11 CEST] <JEEB> they both work with time
[08:33:22 CEST] <JEEB> so as long as your input is actually seekable and indexed, they should be OK
[08:33:28 CEST] <lain98> theres flag option that allow to send frame number too
[08:33:31 CEST] <JEEB> if your input is not indexed (like mpeg-ts)
[08:33:37 CEST] <JEEB> then index it :P
[08:34:26 CEST] <lain98> i want to seek somewhere in the middle of a stream and decode n frames from frame number x onwards.
[08:34:39 CEST] <lain98> so i seek to the key frame before frame x
[08:34:46 CEST] <JEEB> see ffms2, that handles indexing
[08:34:51 CEST] <lain98> and then i decode from key frame to next keyframe
[08:35:24 CEST] <lain98> vfr sort of breaks this logic and i cant see why
[08:35:51 CEST] <lain98> JEEB: that kind of defeats the whole purpose of only wanting to decode some frames. i dont need the whole file
[08:36:16 CEST] <JEEB> you don't need to *decode* the whole thing
[08:36:20 CEST] <JEEB> that's not what indexing means
[08:36:51 CEST] <JEEB> you go through the whole thing once on the *container* level
[08:36:55 CEST] <JEEB> then you have an index
[08:37:36 CEST] <JEEB> lain98: also not sure but I wouldn't be surprised if the "frame" seek just converts that to time :P
[08:37:44 CEST] <lain98> the AVSEEK_FLAG_FRAME doesnt seem accurate under vfr
[08:37:49 CEST] <JEEB> which in case of VFR ends up incorrect
[08:37:53 CEST] <lain98> yeah
[08:38:08 CEST] <JEEB> if you want frame based accurate seeking it sounds like you want ffms2
[08:38:16 CEST] <JEEB> if you don't want to even look at it, sure fine
[08:38:43 CEST] <lain98> i saw a patch in some other software. they like go through all key frames and index the byte position
[08:39:02 CEST] <lain98> then seek to whatever keyframe corresponds to a frame number
[08:39:12 CEST] <JEEB> that sounds like ffms2
[08:39:19 CEST] <JEEB> but sure, have fun
[08:40:04 CEST] <lain98> the performance impact of indexing might like defeat the whole purpose of my application
[08:40:18 CEST] <JEEB> that's mostly IO
[08:40:30 CEST] <lain98> thats why i wanted to have some sort of hack instead of indexing
[08:41:33 CEST] <lain98> like ill have to index 10000 frames to decode 5 frames
[08:42:01 CEST] <JEEB> I would actually first see if it's really too much overhead to get things right
[08:42:16 CEST] <JEEB> since as I noted it's not about decoding, it's about container level indexing
[08:42:23 CEST] <JEEB> if it's really too much, then OK
[08:42:28 CEST] <lain98> hmm. ill check
[08:42:31 CEST] <lain98> thanks JEEB
[08:47:50 CEST] <pk08> hi guys,
[08:47:51 CEST] <pk08> since JEEB is in this chat and my problem is related to ffmpeg and mpv player so i decided to post here instead of mpv channel.
[08:47:51 CEST] <pk08> i am using cuda-copy as hardware decoder and its using cuviddec.c module.
[08:47:51 CEST] <pk08> now I want to use different gpu but by default it using gpu 0 even if i pass --vd-lavc-o=gpu=1!
[08:47:51 CEST] <pk08> can anyone help me to find a way to use different gpu?
[08:47:56 CEST] <pk08> mpv command: https://pastebin.com/5y9mjVXi
[08:47:59 CEST] <pk08> log file: https://pastebin.com/tG0CLWpq
[08:49:58 CEST] <JEEB> well your problem is not necessarily related to FFmpeg, I listed you the possibilities in #mpv before
[08:51:04 CEST] <JEEB> depends on 1) if that lavc option setting actually passes the option to the hwaccel decoder context 2) if the hwaccel has that option that is actually being utilized
[08:51:18 CEST] <JEEB> anyways, I'm at $dayjob and can't exactly give thorough help right now :P
[08:57:18 CEST] <pk08> sorry i was disconnected for few mins
[08:57:32 CEST] <pk08> did anyone reply to my question?
[09:00:03 CEST] <Diag> pk08: did you catch http://tyronesbeefarm.com/images/2019c7f26142-0f17-4adb-b3fb-b3290bea7b6a.png
[09:00:19 CEST] <Diag> ima assume that was related to you
[09:02:29 CEST] <pk08> Diag: yes, but i dont see lavc passed to hardware decoder in log file
[09:03:07 CEST] <pk08> so i dont see anything related to gpu setting option in log
[09:43:58 CEST] <lavalike> how to accurately calculate the duration of an aac file? ffprobe tells me it just does an approximation (and the resulting file plays quite a while longer than what's reported by the app playing it)
[11:58:38 CEST] <DHE> lavalike: the only sure way is to read the whole thing. otherwise duration is estimated by assuming a constant bitrate and reading a bit to get a bitrate estimate.
[13:22:25 CEST] <lavalike> DHE: can I ask ffprobe or another program to do that?
[13:23:56 CEST] <JEEB> -show_frames or -show_packets
[13:24:06 CEST] <JEEB> then you calculate
[13:24:19 CEST] <JEEB> -show_frames decodes, -show_packets is container level
[13:29:34 CEST] <GuiToris> hey, I'd like some advice. The majority of my clips are in 29.97 fps and I have a clip from an other source which is 25fps interlaced. I don't know what to do
[13:29:58 CEST] <GuiToris> I'm about to deinterlace it with nnedi but which framerate should I choose?
[13:30:11 CEST] <GuiToris> should I keep 25 or should I make it 50?
[14:31:18 CEST] <lofo> Hey, i'm learning libav by reproducing the remuxing example (https://ffmpeg.org/doxygen/3.3/remuxing_8c-example.html). I get an error on a call to av_interleaved_write_frame : [mpegts @ 0x16f00f728] Packet with invalid duration -9223372036854775808 in stream 0
[14:31:26 CEST] <lofo> For some reason my outputStream's timebase is 0/0... But i cant find in the documentation at which point the timebase is set
[14:31:35 CEST] <lofo> should i set the time_base manually ?! but in the example there is no such thing
[14:36:57 CEST] <JEEB> you should set it so that the container knows what you'd prefer but then various containers will override you (like MPEG-TS)
[14:37:10 CEST] <JEEB> so with MPEG-TS you should get 1/90000
[14:37:16 CEST] <JEEB> and FLV would be 1/1000
[14:41:58 CEST] <lofo> just solved it myself! indeed MPEG-TS gives 1/90000
[14:42:11 CEST] <lofo> i held bad refs to my output streams
[14:42:16 CEST] <JEEB> :)
[14:42:47 CEST] <lofo> thanks JEEB :)
[14:50:03 CEST] <GuiToris> JEEB, can you help me?
[14:50:12 CEST] <GuiToris> you must know what I should do
[15:10:53 CEST] <DHE> GuiToris: the deinterlacer should be setting its own time_base
[15:11:21 CEST] <GuiToris> DHE, but the original is 25 fps
[15:11:27 CEST] <GuiToris> it'll never be 29.97
[15:11:45 CEST] <GuiToris> the timeline framerate is going to be 29.97 too
[15:12:28 CEST] <GuiToris> I'm afraid the clip will be jerky
[15:45:51 CEST] <GuiToris> what do you think about this one : $ ffmpeg -i input -vf nnedi=weights=/usr/lib/vapoursynth/nnedi3_weights.bin:field=af,fps=fps=30000/1001 output ?
[15:47:52 CEST] <GuiToris> or should I keep all the 50 frames per sec and let premiere throw them away itself?
[15:56:04 CEST] <YellowOnion> Is the "unscaled special converter" meant to look ugly as hell? how do I turn it off...
[16:09:40 CEST] <durandal_1707> YellowOnion: post full logs
[16:12:05 CEST] <YellowOnion> https://gist.github.com/YellowOnion/f214289c42a4b9e130136d167074c2d3
[16:12:25 CEST] <YellowOnion> line 61
[16:13:26 CEST] <YellowOnion> What is the actual problem is that both Kodi and VLC use this ugly scaler and it's been driving me nuts for years.
[16:14:27 CEST] <kepstin> your original video is subsampled (chroma is 1/2 height and 1/2 width), so it's upscaling the chrome with bicubic, a perfectly reasonable option, then performing the yuv to rgb conversion
[16:15:04 CEST] <kepstin> if it looks bad, it's because the original video looked bad, for example maybe it has some sharp color edges that can't be represented properly by subsampled chroma.
[16:15:14 CEST] <YellowOnion> kepstin, it's not upscaling it with bicubic...bicbuic doesn't make it look like pixelated junk.
[16:15:58 CEST] <kepstin> YellowOnion: the scaler isn't the problem, your video just looks bad.
[16:16:15 CEST] <kepstin> probably :)
[16:16:20 CEST] <YellowOnion> kepstin, why does it look better with a different player? https://imgur.com/a/R9ZWhiT
[16:17:09 CEST] <durandal_1707> unscaled scaler is just doing yuv to rgb
[16:17:28 CEST] <durandal_1707> but see line above
[16:17:42 CEST] <durandal_1707> it uses mmxext
[16:17:50 CEST] <YellowOnion> If I enable DXVA in Kodi it look better as well, because ffmpeg is using nearest neighbour
[16:17:52 CEST] <durandal_1707> it is 2019
[16:18:19 CEST] <durandal_1707> yes it uses crappy fast scaler
[16:18:34 CEST] <durandal_1707> use zscale instead
[16:18:50 CEST] <durandal_1707> swscale is piece of crap
[16:18:58 CEST] <kepstin> YellowOnion: i wonder if the other player is doing some additional deblocking/post-processing too
[16:20:03 CEST] <YellowOnion> It' just a different render method. VLC on "software" does it as well, because it ALSO uses ffmpeg's scaler...
[16:20:45 CEST] <durandal_1707> ffmpeg scaler is prahistoric
[17:45:10 CEST] <lavalike> JEEB: neat, that works, by adding up the pkt_duration_time!
[18:23:56 CEST] <JEEB> lavalike: great
[22:01:37 CEST] <SpeakerToMeat> Hello all....
[22:02:24 CEST] <SpeakerToMeat> question, if I have stream 0:0 (video) and stream 1:0 (audio) is there any way to combine both into a file so that stream 0:0  (video) which is shorter is looped the right ammount of times to cover the whole length of stream 1:0?
[22:02:58 CEST] <SpeakerToMeat> Aaaand, as usual, after googling, I finally find a question in stackexchange right after I ask...
[22:04:30 CEST] <SpeakerToMeat> But, the answer doesn't seem right
[22:05:53 CEST] <kepstin> i'd think it should be sufficient to use the `-stream_loop -1` input option on the video stream, combined with the `-shortest` output option
[22:12:14 CEST] <SpeakerToMeat> Ok that one didn't work
[22:12:54 CEST] <kepstin> please pastebin the command line that you ran and the complete console output.
[22:13:09 CEST] <SpeakerToMeat> And this one: ffmpeg  -stream_loop -1 -i vid.mp4 -c copy -v 0 -f nut - | ffmpeg -thread_queue_size 10K -i - -i sound.aac -c copy -map 0:v -map 1:a -shortest -y tomvid.mp4
[22:13:21 CEST] <SpeakerToMeat> kidn of works, but at the moment where the video must loop, it gets stuck on a frame
[22:13:30 CEST] <SpeakerToMeat> which gets unstuck if I ff the player
[22:13:52 CEST] <kepstin> hmm, yeah, it's probably a bad interaction between copy mode and the stream loop option
[22:14:11 CEST] <SpeakerToMeat> probably better to reencode...
[22:15:21 CEST] <SpeakerToMeat> I also tried this: ffmpeg  -stream_loop -1 -i vid.mp4 -i sound.aac -c copy -map 0:v -map 1:a -shortest -y tomvid.mp4 but the output video is the length of the shortest (the video) and the soudn gets cut
[22:15:43 CEST] <kepstin> it might be possible to use the concat demuxer for this - create a playlist file that just has the same video a bunch of times, then use that as an input.
[22:16:02 CEST] <SpeakerToMeat> Hmmmm
[22:16:37 CEST] <kepstin> i suspect that might have a better chance of working with -c copy, too.
[22:16:53 CEST] <SpeakerToMeat> I don't mind reencoding if that'll help
[22:23:13 CEST] <SpeakerToMeat> Hmm ok reencoding on the receive rin th epipe still has the stuck frame, reencodign on the sender fails
[22:25:02 CEST] <SpeakerToMeat> Maybe...
[22:25:34 CEST] <SpeakerToMeat> Sigh if I use the single line: ffmpeg  -stream_loop -1 -i ../Downloads/20190827_063046.mp4 -i mod.aac -c copy -map 0:v -map 1:a -shortest -y tomvid.mp4
[22:25:57 CEST] <SpeakerToMeat> the end result cuts on the video length (shortest) it's like the length beign use is the original video, not the looped one
[22:26:14 CEST] <SpeakerToMeat> I even tried setting loop to a long value (30) instead of -1, same thing
[22:27:34 CEST] <SpeakerToMeat> I'll drop this on kdenlive for now
[22:29:39 CEST] <SpeakerToMeat> Maybe if I use the loop filter
[22:30:21 CEST] <SpeakerToMeat> But I'm unsure how ot combien this with a 2 file input...
[22:31:20 CEST] <SpeakerToMeat> I need to do something like this I guess? -filter_complex "[0:v]loop=loop=30[outvid]" -map outvid -map 1:a
[22:31:38 CEST] <SpeakerToMeat> that with -shortest for output...
[22:33:30 CEST] <SpeakerToMeat> sigh
[22:33:51 CEST] <SpeakerToMeat> c:v h264 is slow. I wonder if I can get nvenc to work, and get decent quality from it
[22:34:43 CEST] <SpeakerToMeat> aaarrrrgh... even with this it still outs to the length of the video like it were not looped
[22:34:54 CEST] <SpeakerToMeat> I think concat....
[22:35:15 CEST] <SpeakerToMeat> kepstin: but if I use a concat demux... do I need to pipe this to another instance to mix with the audio?
[22:35:29 CEST] <kepstin> no, there's no reason to use 2 instances at all
[22:36:30 CEST] <SpeakerToMeat> How would I do this with the concat demuxer then? to map only the video form the concat and the aduio from the other file...
[22:36:31 CEST] <SpeakerToMeat> let me google
[22:37:02 CEST] <kepstin> ffmpeg -f concat -i playlistfile -i audio.aac -map 0:v -map 1:a <output options>
[22:39:08 CEST] <SpeakerToMeat> thanks, let's try that
[22:45:36 CEST] <SpeakerToMeat> It stopped at 9 minutes :/
[22:50:47 CEST] <SpeakerToMeat> Oh it worked with concat...
[22:51:15 CEST] <SpeakerToMeat> only, the audio said 20 minutes in ffprobe... but it's actually 9 minutes, which is what was output
[22:51:36 CEST] <SpeakerToMeat> So I was expecting more.
[22:51:40 CEST] <kepstin> raw aac doesn't store the length anywhere, so ffprobe can't read it accurately
[22:51:56 CEST] <kepstin> i think it just makes a guess based on the bitrate near the start of the file
[22:51:56 CEST] <another> that's exactly what i suspected
[22:52:14 CEST] <kepstin> which in vbr is usually pretty low, so it often guesses too long.
[22:52:36 CEST] <another> is there any specific reason why you have raw aac?
[22:55:14 CEST] <SpeakerToMeat> That makes sense
[22:55:24 CEST] <SpeakerToMeat> so raw aac is sort of like raw pcm in that
[22:55:37 CEST] <another> kinda
[22:55:50 CEST] <SpeakerToMeat> only pcm is cbr
[22:56:03 CEST] <kepstin> raw pcm isn't vbr, it's always an exact number of bits per second, so you can calculate duration exactly from file length.
[22:56:20 CEST] <SpeakerToMeat> Yep
[22:56:28 CEST] <FooNess> (Assuming "raw PCM" here means just that, without any metadata and container overhead.)
[22:56:33 CEST] <kepstin> assuming you know the sample format, sample rate, and number of channels somehow :)
[22:56:48 CEST] <SpeakerToMeat> kepstin:You can always start moltiplying/dividing to try and guess ;)
[22:56:53 CEST] <SpeakerToMeat> multiplying
[23:26:07 CEST] <GuiToris> so are there any suggestions what I should do with my 25fps clip on a 29.97 timeline?
[23:30:04 CEST] <pink_mist> use a format that allows vfr and stop worrying?
[23:31:59 CEST] <GuiToris> pink_mist, the thing is I need to deinterlace the clip first and I have the opportunity to double the framerate to 50. The actual question is if I should do this or not
[23:32:52 CEST] <GuiToris> I've been thinking about this: $ ffmpeg -i input -vf nnedi=weights=/usr/lib/vapoursynth/nnedi3_weights.bin:field=af,fps=fps=30000/1001 output
[23:34:17 CEST] Action: kepstin would probably use bwdif rather than nnedi for general content
[23:34:57 CEST] <furq> is ffmpeg nnedi usable yet
[23:35:08 CEST] <furq> i'm guessing it's still appallingly slow unless someone added frame threading to lavfi
[23:35:18 CEST] <kepstin> in theory, you should have slightly less judder going from 50fps to 30/1.001 than from 25 to 30/1.001
[23:35:34 CEST] <furq> it's not going to be great either way but i guess it's better to start with 50
[23:36:11 CEST] <kepstin> use the fps filter to convert to 30/1.001 fps, it has better rounding behaviour than the -r output option
[23:36:19 CEST] <GuiToris> should I specify fps=fps=30000/1001, or should i let premier throw away the extra frames?
[23:36:32 CEST] <furq> well if you do it with ffmpeg then you can preview it
[23:36:53 CEST] <kepstin> i have no idea how premier works, but it's probably not any better than the fps filter
[23:36:53 CEST] <furq> i would try with bwdif=1 and bwdif=0 and see which looks better
[23:37:04 CEST] <kepstin> (it might be worse)
[23:37:24 CEST] <furq> bwdif vs nnedi isn't going to make it more or less juddery
[23:37:31 CEST] <GuiToris> isn't nnedi superior to bwdif?
[23:37:38 CEST] <furq> yes but they both work in the same way
[23:37:41 CEST] <furq> nnedi just uses a better upscaler
[23:37:55 CEST] <furq> any judder will be the same for both
[23:38:01 CEST] <kepstin> nnedi is just *really slow* in ffmpeg, so you should test with a faster filter
[23:38:07 CEST] <furq> yeah mostly that
[23:38:15 CEST] <furq> also maybe consider using nnedi through vapoursynth so you can at least multithread it
[23:38:32 CEST] <furq> also i think the implementations there are just faster in general (definitely if you have a fast gpu)
[23:39:00 CEST] <GuiToris> the speed is not that important now, I'll leave my computer do it all night
[23:39:01 CEST] <kepstin> iirc there isn't even any simd in the ffmpeg filter
[23:39:25 CEST] <kepstin> you should test it with a fast filter to compare which method looks better
[23:39:27 CEST] <furq> GuiToris: do whatever you want for the final export, i'm just suggesting bwdif for previewing
[23:39:50 CEST] <furq> any method of deinterlacing and then converting to 30fps will exhibit the same issues
[23:40:33 CEST] <GuiToris> :/ got it
[23:40:38 CEST] <GuiToris> thank you so much for your help :)
[23:41:02 CEST] <kepstin> hmm, someone wrote an opencl port of nnedi3, and it's lgpl3
[23:41:08 CEST] <furq> yeah it's pretty good
[23:41:13 CEST] <furq> i use that one in vs
[23:41:25 CEST] <furq> there's also znedi3 from the zimg guy
[23:41:44 CEST] <furq> i assume the opencl one will suffer less from not having frame threading though
[23:41:47 CEST] <kepstin> i should try to get opencl working on one of my systems.
[23:44:06 CEST] <kepstin> i guess on radeon stuff i want to use rocm.
[23:48:05 CEST] <furq> that or amdgpu-pro
[23:49:04 CEST] <furq> iirc you can install the amdgpu-pro opencl stuff alongside the oss driver
[23:49:27 CEST] <furq> but if rocm is good now then that's probably less hassle
[00:00:00 CEST] --- Wed Aug 28 2019