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

[burek]

[00:07:04 CET] <dostoyevsky> Hi.  I am trying to cut out a part of a mkv video like -ss 60 -t 2 <- but when I look at the resulting video in VLC it seems not to display anything for a while and then suddenly I see 2-3 frames, followed by a freeze.  at the same time I can hear the audio working well.  It seems to me as if the mkv has some buffer sections and I cannot simply go whereever I like with -ss and -t
[01:23:26 CET] <dostoyevsky> I can get over the freezes if I decrease -ss by 5 seconds and raise -t... then the video will start to unfreeze at about where I want.  I am wondering if maybe I should convert the video to another format so I can do more a more precise cut out and then convert the resulting video back to mkv
[01:24:37 CET] <furq> dostoyevsky: you generally can't cut videos precisely with -c copy
[01:24:44 CET] <furq> unless you happen to want the cut to be exactly on a keyframe
[01:25:02 CET] <kevinnn> JEEB: hey are you still around?
[01:25:11 CET] <furq> if you reencode the video while cutting it should be fine
[01:25:18 CET] <furq> just the video, no need to touch the audio
[01:26:08 CET] <dostoyevsky> furq: thank you!
[01:32:06 CET] <dostoyevsky> furq: works now :)
[02:40:10 CET] <termos> I have an issue where i push data to av_interleaved_write_frame, where it buffers up enough data to create a ts segment. The problem is if my http endpoint goes down, a whole segment can be lost as I avio_close the input and re-open it. Is there a best practice way to avoid losing packets/segment here?
[02:40:28 CET] <termos> s/input/output
[02:56:00 CET] <termos> it could be that i'm using a custom hls_start_number_source and when one output goes down, the other one keeps on counting on it's own
[08:53:34 CET] <zyme> Any chance you guys know anything about ffdshow video decoder?
[08:54:45 CET] <JEEB> I did work on it briefly in 2011 or so, but soon after that it became more or less unneeded. it's a thing that uses its internal copy of FFmpeg and is barely maintained by clsid nowadays (since I don't think even he uses it any more)
[08:54:51 CET] <zyme> I just don't get why it shows up in my system tray along with LAV when LAV is configured to do all the decoding..
[08:55:23 CET] <zyme> https://usercontent.irccloud-cdn.com/file/YntkN2sb/sys-tray.png
[08:56:11 CET] <JEEB> it does filtering as well so it's really simple for it to catch up into the filter chain :P
[08:56:21 CET] <JEEB> have fun checking your player or DShow config for why that is the case
[08:56:41 CET] <JEEB> unfortunately, has pretty much nadda to do with FFmpeg itself
[08:59:06 CET] <zyme> I have mpc-hc+mpc-be atm, mpc-be likes to force ffdshow to be used exclusively and has this rediculous interface on the add+config plugins page, though I'm not sure that page does anything at all lol..
[09:00:42 CET] <JEEB> yea, have fun with that :P I'd just unregister ffdshow-tryouts (original ffdshow died in like 2008 or so?) if you don't use it
[09:00:44 CET] <zyme> but generally I wonder if it's adding another conversion layer or even just making the output not as nice as LAV.. which I mostly just use because of the hardware gpu/CUVID support
[09:01:48 CET] <zyme> hmm... hopefully my apps are smart enough to not just crash on attempting to play if I were to uninstall it..
[09:03:38 CET] <zyme> I tried playing around with enabling the filters, and while I love the "apply only to right half" that's only because it makes it obvious that anything I try turning on makes the video look worse =)
[09:25:47 CET] <cluelessperson_> ptx0:   You banned me because your communciation skills are shit and you're blaming me for YOUR misunderstanding and assumptions.
[09:26:13 CET] <cluelessperson_> ptx0: stop being a shithead.
[09:26:29 CET] <cluelessperson_> You sat there and mocked me, gave me roundabout responses, and made assumptions
[09:26:41 CET] <cluelessperson_> You were WRONG at every turn.
[09:26:58 CET] <cluelessperson_> and if I'd listened to you outright, I'd have wasted money on hardware.
[09:27:03 CET] <cluelessperson_> You're the one not listening.
[09:27:49 CET] <ivki> Hello
[09:28:12 CET] <ivki> I'm trying to convert png files to a webm/vp8 video with ffmpeg version 3.4.5 on centos7.
[09:28:29 CET] <cluelessperson_> like, individual frames?
[09:29:31 CET] <ivki> I use this command and I have this error : https://paste.frsag.net/fAw6C
[09:29:46 CET] <ivki> cluelessperson_ yes
[09:30:23 CET] <ivki> It was working with the version 2.6.9
[09:41:51 CET] <pink_mist> cluelessperson_: while I agree that ptx0's communiction skills are sometimes lacking, yours were bleeding atrocious. also this is not the right place to drag your disagreement with him into.
[09:43:24 CET] <cluelessperson_> pink_mist: I think you came in halfway through the conversation and didn't see the obvious context I gave, repeatedly.   He banned me without reason so I cannot plead my case.
[09:43:55 CET] <pink_mist> I've seen your conversations since sometime in december I think
[09:44:36 CET] <cluelessperson_> pink_mist: I'm not the best people person, but I absolutely methodically and logically laid out the syptomes and problems I ran into and the context.   They just chanted "buy more ram" and they were absolutely wrong.
[09:45:10 CET] <pink_mist> and yes. he's an op. he gets to ban people. it's part of the prerogatives of an op. whether you get to appeal or not depends competely on the channel in question, and you just haveto live with it.
[09:53:46 CET] <cluelessperson_> pink_mist: or, I can ignore dumb power tripping mods that ban people for no reason.
[09:54:44 CET] <furq> you can ignore them by starting a fight with them in another channel
[10:06:58 CET] <cluelessperson_> sorry for annoying this channel, you're right.
[17:06:21 CET] <ddubya> any ideas how I can repair mkv with read errors? Now I'm trying to use -c copy and seek over the bad part but no dice
[17:06:25 CET] <_Vi> Can I use formulas in noise bsf parameters? E.g. specify "amount" depending on time?
[17:07:04 CET] <_Vi> ddubya, Try mkvmerge or try my tool like mkv2xml+xml2mkv or HsMkv's transmux.
[17:08:14 CET] <ddubya> hmm
[17:08:25 CET] <ddubya> can it skip over corruptions?
[17:08:33 CET] <ddubya> or excise them
[17:08:39 CET] <ddubya>  the data is definitely corrupted
[17:10:36 CET] <ddubya> or do you mean use mkvmerge to split it manually?
[17:18:22 CET] <ddubya> _Vi, thanks. I tried mkvmerge but it chokes when it hits the corruption. There is no option to skip over it
[17:21:51 CET] <_Vi> ddubya, My program mkv2xml tries to resync to some nearest cluster on corruption.
[17:22:25 CET] <ddubya> mkvmerged tries to rsync and fails, seems to read out to EOF and gives up
[17:22:42 CET] <_Vi> ddubya, But I also expect FFmpeg to also resync on corruption. Are you sure there is any useful content in the file after first corruption point?
[17:23:06 CET] <_Vi> ddubya, If the file is small and non-sensitive, you can just publish it and give a link.
[17:23:13 CET] <ddubya> yeah, I'm rechecking that. I assumed it would play in vlc but maybe not
[17:24:12 CET] <_Vi> ddubya, No report about success or failure of this: https://github.com/vi/mkvparse
[17:26:00 CET] <ddubya> well, thanks for your help, but I'm an idiot it seems. I could have sworn I watched this movie in vlc before, now it will not seek over the corruption
[17:26:42 CET] <_Vi> ddubya, You can post the last megabyte of the file somewhere, and we'll see if it seems to contain anything resembling mkv data or not.
[17:27:44 CET] <_Vi> ddubya, Maybe storage drive is degrading and more and more of content getting lost?
[17:28:24 CET] <ddubya> yeah I considered bitrot so I verified the checksum in my backups
[17:30:18 CET] <ddubya> well I think I learned something anyways, thanks for the help
[17:37:01 CET] <Aerroon> what would be the fastest way out of common encoders to encode a video of a static image (to lower filesize)?
[17:37:14 CET] <Aerroon> doesn't have to be good, but simply fast encoding
[17:37:45 CET] <Aerroon> right now its that same static image just copied over and over and over again
[17:41:19 CET] <Aerroon> or alternatively, is it possible to do something like
[17:41:54 CET] <Aerroon> ffmpeg -stream_loop -1 -i image.png -i audio.m4a -shortest etc
[17:42:12 CET] <Aerroon> without ffmpeg trying to decode the image on every single loop again?
[17:55:14 CET] <BtbN> Try setting a ridiculously low fps
[18:59:32 CET] <Aerroon> BtbN, thanks!
[19:00:04 CET] <Aerroon> although i feel it doesn't work quite as i expected
[19:00:40 CET] <Aerroon> just to clarify
[19:00:42 CET] <Aerroon> -r[:stream_specifier] fps (input/output,per-stream)
[19:00:56 CET] <Aerroon> how would i set the (input/output) part
[19:01:17 CET] <BtbN> what?
[19:01:36 CET] <Aerroon> as in, how would i specify whether it should be for input only
[19:01:41 CET] <BtbN> That's not a parameter, it just tells you it's a per-stream option for both input and output streams.
[19:01:47 CET] <Aerroon> oh
[19:02:02 CET] <BtbN> Its positioning on the commandline determines which stream it affects
[19:03:09 CET] <Aerroon> cause when i run
[19:03:33 CET] <Aerroon> ffmpeg -r 1/100 -stream_loop -1 -i image.png -i audio.mp3 -shortest -c:v libx264 -c:a copy -r output.mkv
[19:03:49 CET] <Aerroon> it doesn't quite work since the resulting video's playback seems to start like an hour and 30 minutes in
[19:04:09 CET] <BtbN> try setting it on the output stream
[19:04:46 CET] <BtbN> even though it should carry over. Can also just try on both at the same time
[19:17:46 CET] <BtbN> Another idea would be -r 0.0000001 on the input, and normal -r 30 on the output. That should make it duplicate the decoded frame.
[19:18:24 CET] <BtbN> And you want to set a very long GOP for this kind of static "video"
[19:25:47 CET] <Aerroon> ohh, that last one might've worked
[19:26:02 CET] <Aerroon> i don't know anything about GOP, i'll look into it later, but if this just works even then i'll be happy
[19:26:24 CET] <BtbN> Why do you even care about decoding the input frame a lot? Decoding a png image should be fairly quick
[19:26:43 CET] <Aerroon> because last time i asked about it i was told that
[19:26:55 CET] <Aerroon> ffmpeg -stream_loop -1 -i image.png -i audio.mp3 -shortest -c:v libx264 -c:a copy -r output.mkv
[19:27:03 CET] <Aerroon> this decodes image.png every frame
[19:27:18 CET] <BtbN> Yeah, it does. But why is that a problem? Is it that slow?
[19:27:24 CET] <Aerroon> and this means that how long it takes to actually put this together is basically entirely dependent on how quickly it decodes
[19:27:50 CET] <BtbN> I'd expect it to be limited by the encoder in either case
[19:28:03 CET] <TheAMM> You might be able to use some sort of lavfi-complex for the looping
[19:28:08 CET] <Aerroon> libx264 -preset slowest goes at the same speed as h264_nvenc
[19:28:13 CET] <TheAMM> Like overlay will stick with the latest frame
[19:28:25 CET] <TheAMM> So you'd only decode once and then buffer it
[19:28:28 CET] <Aerroon> i don't know what that means, sorry
[19:28:35 CET] <Aerroon> but videos are not decoded multiple times though!
[19:28:38 CET] <Aerroon> so if i went with
[19:28:46 CET] <BtbN> duplicating it a ton via the fps trick should achive the same
[19:29:00 CET] <Aerroon> ffmpeg -stream_loop -1 -i video.mp4 -i audio.mp3 -shortest -c:v libx264 -c:a copy output.mkv
[19:29:03 CET] <Aerroon> it's fine
[19:29:34 CET] <BtbN> I don't think it will behave differently depending on the container of the input video
[19:29:41 CET] <BtbN> a .png is just a special case of a video for ffmpeg
[19:30:06 CET] <Aerroon> it does
[19:31:54 CET] <Aerroon> even with just libx264 it's a difference of several times in speed
[19:32:01 CET] <Aerroon> and if i use h264_nvenc it's even greater
[19:33:11 CET] <Aerroon> but the solution you suggested with a low input framerate and a normal output framerate is even better
[19:33:22 CET] <BtbN> Ah, there seems to be a special case for then the image on disk is actually constantly refreshed, so an actual video in a weird sense
[19:33:32 CET] <BtbN> that's why it's re-decoding it every access
[19:34:02 CET] <Aerroon> i'll see what youtube says about the one that you suggested
[19:34:22 CET] <Aerroon> the problem with that version is that mpchc didn't run it at all (but VLC did!), but VLC didn't let me seek
[19:34:33 CET] <Aerroon> but all i need it for is to upload to youtube anyway so it doesn't matter if those don't work properly
[19:34:43 CET] <BtbN> The resulting video should be a normal 30 fps video
[19:34:51 CET] <BtbN> If some player refuses to play it, something went wrong
[19:36:49 CET] <Aerroon> okay, so audio track is 1:23:41, but the resulting video is 1:33:20
[19:36:54 CET] <Aerroon> i guess the quest continues!
[19:38:09 CET] <Aerroon> it's a rather interesting problem, becuase you'd think this would be a really easy thing to do
[19:38:43 CET] <Aerroon> the wrong audio duration might be due to some audio stuff though
[19:42:28 CET] <BtbN> Have you tried using loop instead of stream_loop?
[19:43:49 CET] <Aerroon> i have not
[19:44:35 CET] <Aerroon> all the docs say is
[19:44:44 CET] <Aerroon> >Repeatedly loop output for formats that support looping such as animated GIF (0 will loop the output infinitely). This option is deprecated, use -loop.
[19:44:53 CET] <Aerroon> it doesn't give me anything else on what -loop does so i have no idea how to use it
[19:45:41 CET] <BtbN> https://trac.ffmpeg.org/wiki/Slideshow#Singleimage
[19:45:55 CET] <Aerroon> oh, i looked over here https://ffmpeg.org/ffmpeg.html
[19:45:57 CET] <Aerroon> thanks
[20:11:11 CET] <ossifrage> Huh, the i-frame only version of this encode came out smaller then IPPPPPI at the same crf.
[22:23:52 CET] <GTest1989> Hello, anyone here to assist?
[22:24:24 CET] <GTest1989> I have a Black Magic DeckLink device I can't get to work. Getting an I/O error.
[22:28:59 CET] <friendofafriend> GTest1989: Post the error to a paste site, like http://paste.debian.net
[00:00:00 CET] --- Sat Jan 19 2019