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

[burek]

[00:00:02 CET] <DHE> another reason to use h265, some hardware video players (eg: Set-top-boxes) that do 4k can't do it in h264
[00:00:26 CET] <alexpigment> DHE: that's what I was alluding to - maintaining a standard
[00:00:26 CET] <DHE> I only have 1 example, but I checked and it's true
[00:00:48 CET] <alexpigment> even though i'm almost positive that's a software-imposed limitation
[00:01:08 CET] <alexpigment> maybe MPEG-LA and co slipped the set top manufacturer a few bucks ;)
[00:01:20 CET] <JEEB> more likely the other patent pools
[00:01:23 CET] <DHE> well, this vendor (won't name names for now) claims h264 @ 4.2 high, which is only good to 1080p 60fps
[00:01:45 CET] <JEEB> I mean, the corps went out of MPEG-LA because they wanted more dough
[00:01:46 CET] <JEEB> lol
[00:01:49 CET] <alexpigment> DHE: again, I question the validity on actual hardware
[00:02:11 CET] <DHE> admittedly this is just spec sheet numbers. I don't even have a 4k TV to test with
[00:02:37 CET] <alexpigment> DHE: neither do I, but I've designed a lot of 4K video encoding profiles for HDTVs using H.264
[00:02:44 CET] <alexpigment> seems to work fine in every scenario
[00:03:11 CET] <DHE> hmm.. I guess testing the decoder chip wouldn't actually require a 4k TV, just 4k input
[00:03:16 CET] <alexpigment> the only way it wouldn't is if there are two separate hardware decoders and one is used for 4k and one is used for sub4k
[00:03:17 CET] <JEEB> yea, only input
[00:03:31 CET] <JEEB> talking of hardware, <BEEEEP> various ARM vendors' GLSL implementation <3
[00:05:04 CET] <ppw> well this is turning out to be interesting guys
[00:05:15 CET] <ppw> I'll share the results with you when I'm done with this batch of files.
[00:06:12 CET] <alexpigment> JEEB: I misread your last message, and you've inadvertentedly just reminded me to do my monthly check in on AMD VCE encoding in FFMPEG
[00:06:12 CET] <alexpigment> anyone know of any updates?
[00:06:19 CET] <JEEB> there's a patch on the ML which I haven't looked into yet properly
[00:06:30 CET] <alexpigment> oh nice
[00:06:36 CET] <alexpigment> i'll check it out
[00:07:25 CET] <JEEB> we might end up throwing out the nvidia headers because otherwise we would be making usage of nvidia's stuff where they don't provide an SDK properly simpler than AMD's where they seemingly are providing an SDK openly
[00:07:45 CET] <BtbN> unlikely
[00:07:50 CET] <JEEB> that's also true
[00:08:11 CET] <JEEB> it's just a herp derp situation where the shitty vendor got in first
[00:08:17 CET] <JEEB> and had to be hacked
[00:09:42 CET] <alexpigment> the shitty vendor = nvidia?
[00:09:49 CET] <JEEB> yes
[00:10:01 CET] <BtbN> I don't consider anything of it a hack
[00:10:07 CET] <alexpigment> in my experience, they're the best for hardware encoding
[00:10:07 CET] <BtbN> the availability of that header is just horrible
[00:10:11 CET] <JEEB> it's not a hack indeed
[00:10:15 CET] <JEEB> yes
[00:10:23 CET] <JEEB> I wasn't saying it was a hack, it's just a header :P
[00:10:33 CET] <JEEB> but yes, they're really shitty with the header
[00:10:39 CET] <BtbN> And they pretty much only made them includeable after _a lot_ of nagging from our side
[00:10:48 CET] <BtbN> They were under a nvidia proprietary license for the longest time
[00:14:05 CET] <DHE> didn't they need a license key to use?
[00:14:29 CET] <BtbN> At the very beginning of nvenc, yes
[00:14:30 CET] <JEEB> only private APIs
[00:14:38 CET] <JEEB> like the straight screen cap API
[00:14:48 CET] <BtbN> The header was NDA-Only, and you needed to pass a license key
[00:15:07 CET] <BtbN> The API key was trivial to extract from application though
[00:15:13 CET] <JEEB> yea
[00:15:17 CET] <BtbN> so they gave up on that quickly
[00:15:30 CET] <JEEB> I remember someone RE'ing steam for the quick screen capture APIs
[00:15:35 CET] <JEEB> and the API key
[00:15:40 CET] <BtbN> you don't need to RE anything
[00:15:50 CET] <BtbN> just auto-generate a shim for the dll, and read it out
[00:18:47 CET] <JEEB> BtbN: is NvFBC_CreateEx public now?
[00:19:04 CET] Action: JEEB found the old thing using NvFBC.dll
[00:19:18 CET] <BtbN> NvFBC/IFR is discontinued outside of GRID products
[00:19:29 CET] <BtbN> Even their own game stream application doesn't use it anymore
[00:19:32 CET] <JEEB> ah
[00:19:42 CET] <BtbN> Which is a shame
[00:19:48 CET] <BtbN> it's a _very_ useful and powerful thing
[00:19:51 CET] <JEEB> yup
[00:19:59 CET] <JEEB> that's why the guy looked at how steam used it
[00:20:10 CET] <JEEB> probably didn't want to go through NDAs etc
[00:20:12 CET] <BtbN> But I think there were serious security concerns
[00:20:23 CET] <BtbN> so they killed it off outside of GRID cards
[00:21:23 CET] <BtbN> It pretty much allowed a non-privileged user to screen-cap other users and privileged applications and entire desktops
[00:22:38 CET] <JEEB> yea
[00:25:27 CET] <ppw> BtbN furq CoReX alexpigment https://pasteboard.co/GTPiVqs.png thoughts?
[00:26:01 CET] <BtbN> without comparing the visual quality that's mostly meaningless
[00:26:11 CET] <BtbN> And you really should not be using he-aac. It's special.
[00:26:14 CET] <ppw> well it's nearly identical to my eye
[00:28:30 CET] <alexpigment> these numbers aren't really surprising to me, to be honest
[00:28:49 CET] <alexpigment> is this size reduction important enough to you that you're willing to spend the extra time and also lose device compatibility?
[00:29:09 CET] <alexpigment> everything plays h.264
[00:29:11 CET] <BtbN> you should also give x264 a slower preset
[00:29:14 CET] <alexpigment> not everything plays h.265
[00:29:23 CET] <BtbN> it's not a fair comparison unless they are "equally slow"
[00:31:59 CET] <ppw> thanks for the input, now I'm even less certain of my choices. if I delete the originals and keep only the h.264 versions, I will have made a mistake anyway. transcoding to hevc after-the-fact would result in even worse quality.
[00:32:25 CET] <ppw> oh well
[00:32:39 CET] <alexpigment> keep the originals. hard drive space is cheap
[00:33:21 CET] <ppw> I suppose.
[00:35:50 CET] <BtbN> Every re-encode will cost quality
[00:35:54 CET] <BtbN> no matter to what format
[00:36:05 CET] <BtbN> unless some of those odd-ball codecs that have no generation loss
[00:36:05 CET] <ppw> uh, ffv1 disagrees
[00:36:11 CET] <BtbN> And lossless codecs of course
[00:36:41 CET] <BtbN> surprisingly, jpeg/mjpeg has no generation loss
[00:36:55 CET] <BtbN> but only if you re-encode at the exact same parameters, which makes it pretty pointless
[00:37:04 CET] <ppw> does that mean that jpeg rotation is lossless?
[00:37:11 CET] <BtbN> no
[00:37:18 CET] <BtbN> rotating it qualifies as changing parameters
[00:37:22 CET] <BtbN> or rather, the entire image
[00:42:45 CET] <debianuser> ppw: unless you do it with jpegtran/exiftran/jpeglosslessrotator - those can do a lossless jpeg rotation.
[00:44:56 CET] <atomnuker> yep, lossless jpeg rotations are perfectly possible
[00:45:17 CET] <atomnuker> you reorder the blocks, you redo DC prediction and you swap AC coefficients' rows and columns
[01:17:59 CET] <kingsley> CVE-2017-15186 reports a double free vulnerability in version 3.3.4.
[01:19:18 CET] <kingsley> Could it be related to an error I get in melt, which says...
[01:19:22 CET] <kingsley> double free or corruption (fasttop)
[01:19:23 CET] <kingsley> ?
[01:20:34 CET] <kingsley> melt also reports...
[01:20:37 CET] <kingsley> [matroska @ 0x9b80b060] Using AVStream.codec to pass codec parameters to muxers is deprecated, use AVStream.codecpar instead.
[01:38:29 CET] <thebombzen> what's the difference between nvdec and cuvid hwaccels?
[01:38:42 CET] <thebombzen> nvdec isn't mentioned in `man ffmpeg-all`
[02:36:00 CET] <nelson> hi
[02:39:25 CET] <nelson> which file format can be loaded using any of those functions https://pastebin.com/9c8nqcKN ?
[03:06:16 CET] <ct_> hi. I would like to learn if it is possible to use ffprobe and ffmpeg to get a .mov file from stdin, get required metadata from the input file, use it to demux and mux it with ffmpeg to stdout as an mp4 with a "basic" moov atom at the beginning
[03:07:38 CET] <ct_> basically something like `ffprobe STDIN args ... | ffmpeg STDIN args STDOUT args`
[03:11:13 CET] <ct_> I have attempted various combination of arguments but either ffmpeg is not happy because .mov file that is piped from stdin has the moov atom at the end so ffmpeg fails
[03:11:48 CET] <ct_> or ffmpeg +faststart fails with stdout as the target because it needs a second pass to write the moov atom to the beginning
[03:13:51 CET] <ct_> I wonder if I can use ffprobe to read .mov file from stdin and get metadata needed by ffmpeg to start encoding immediately, and then also pass hardcoded values to ffmpeg to create a moov atom for the mp4 output and start outputting it to stdout
[03:46:30 CET] <Jonno_FTW> how can I have a constantly updating text overlay?
[03:48:21 CET] <Jonno_FTW> ie. it calls rythmbox-client every few seconds and updates the overlay
[03:51:30 CET] <Jonno_FTW> or would I just specify a file that is constantly being written to?
[04:15:18 CET] <tezogmix> How do I edit this batch command to target a filename with spaces? (in windows) I tried adding double quotes but that didn't work. <<<< for %%a in ("filename with spaces.wmv") do ffmpeg -i "%%a" -preset veryfast -crf 15 -c:a aac "newfiles\% >>>>
[04:15:54 CET] <tezogmix> I'm able to do files with no spaces + wildcards like *.wmv
[04:35:43 CET] <SortaCore> tezogmix, is "" any good, as in -i ""%%a""
[04:36:33 CET] <tezogmix> Hi SortaCore - I tried that one and believe it listed it as an invalid argument via windows command prompt
[04:37:18 CET] <tezogmix> also tried single quotes (') around the filename and also double quotes
[04:38:37 CET] <tezogmix> like (""filename with spaces.wmv"") ----- (''filename with spaces.wmv'') ----- ('filename with spaces.wmv')
[04:38:57 CET] <SortaCore> next thing would be putting it in a go-between variable
[04:39:13 CET] <tezogmix> was this a %1 ?
[04:39:39 CET] <tezogmix> I saw something posted just with that in a forum but it didn't mention much more.
[04:40:29 CET] <SortaCore> set "tempvar=long path with spaces"
[04:40:59 CET] <tezogmix> oh ok, where would I insert that into the original line above?
[04:42:34 CET] <SortaCore> try -i "%%~a"
[04:43:07 CET] <SortaCore> or -i "%%~sa"
[04:43:57 CET] <SortaCore> may not need a go-between
[04:44:10 CET] <SortaCore> 3rd thing is -i %%~sa
[04:46:28 CET] <SortaCore> any of those work?
[04:47:30 CET] <tezogmix> Hey SortaCore - thanks, just tried your 1st suggestion and it worked! "%%~a"
[04:47:43 CET] <tezogmix> right after -i
[04:47:47 CET] <SortaCore> ah ok
[04:48:03 CET] <SortaCore> The first strips quotes
[04:48:25 CET] <SortaCore> the second does that and converts to short filename format (8.3)
[04:48:27 CET] <tezogmix> oh I see, the "~" in front of the a
[04:48:38 CET] <SortaCore> yea, you can view about it under cmd "help for"
[04:49:08 CET] <tezogmix> and the 3rd one is without quotes as you commented
[04:49:19 CET] <SortaCore> yea
[04:49:31 CET] <SortaCore> since short filenames don't contain spaces it ought to have worked as well
[04:49:58 CET] <SortaCore> not sure if ffmpeg would have parsed it properly as they have funky symbols
[04:50:07 CET] <SortaCore> but probably would've worked
[04:50:56 CET] <tezogmix> I see, this was really helpful... thanks a bunch for the new tip SortaCore!
[04:54:58 CET] <SortaCore> no prob
[04:55:40 CET] <SortaCore> I'm sort of chilling here until I work out how hwa acceleration works
[04:55:52 CET] <SortaCore> and ideally how to fix qsv which seems to be dodgy product as opposed to ffmpeg
[04:56:56 CET] <SortaCore> I'm paid hourly so it's not a huge problem if it takes a while, but it's kinda annoying after so many weeks
[05:02:34 CET] <tezogmix> Sounds like an interesting work task (not sure of the technical details)
[05:06:22 CET] <tezogmix> hope you get billed for many hours in a good way SortaCore :) going to head to bed and sign off, appreciate the time!
[05:06:30 CET] <SortaCore> security software >.<
[05:06:54 CET] <SortaCore> well, video receiving part of security software
[05:07:02 CET] <SortaCore> cya, and np
[05:09:34 CET] <tezogmix> cool, I was curious and googled a few of your keywords and came across some intel/IP cam topics
[05:11:07 CET] <tezogmix> but surely can imagine this is much broader in application...
[05:11:20 CET] <SortaCore> well, it's for receiving video streams
[05:11:46 CET] <SortaCore> displaying them, re-encoding them to video files, allowing snapshots, and I wrote a mediocre motion-detection
[05:12:14 CET] <SortaCore> all software instead of hardware, so it's burning up more resources than necessary
[05:12:49 CET] <SortaCore> once I iron out the hardware I could publish it publicly - it's an extension for a coding language
[05:13:14 CET] <tezogmix> ah neat... well best wishes to its turnaround and success then! :)
[05:13:15 CET] <SortaCore> not limited to security firms, any online video feed is fine
[05:13:25 CET] <SortaCore> yea, appreciated
[05:13:44 CET] <tezogmix> the next hooli maybe? :P
[05:14:31 CET] <SortaCore> heh, who knows
[05:15:21 CET] <tezogmix> :)
[05:21:41 CET] <acos> Good evening.
[05:22:09 CET] <acos> Trying to figure out why vlc sees 100+ streams in a file and ffprobe only sees 2
[09:30:21 CET] <illegal> when making a video with a single image and audio (-i image.jpg -i audio.ogg output.mp4) the images do not appear on firefox, and when resuming playback with playbacks, I am using the git version static 64 from zeranoe. what could be the problem? on players like MPC-HC it just refuses to even play or show the image.
[09:31:28 CET] <durandal_170> illegal: full uncut console output missing
[09:33:00 CET] <illegal> https://ghostbin.com/paste/guu2a
[09:34:15 CET] <illegal> http://0x0.st/siCH.mp4 here is the file too
[10:50:58 CET] <durandal_170> illegal: try setting pix fmt to yuv420p
[10:56:09 CET] <illegal> It threw me an error with .mp4 so I used .webm, same error. https://ghostbin.com/paste/vv27v
[10:56:36 CET] <illegal> here is the one for the .mp4 durandal_170
[11:20:28 CET] <durandal_170> illegal: thats not error
[11:23:48 CET] <illegal> durandal_170, for the webm? I meant the output still came out with the error I mentioned earlier
[12:05:23 CET] <furq> illegal: -loop 1 -i push.jpg
[12:05:45 CET] <furq> you probably also want -c:a copy
[12:05:55 CET] <furq> for webm, obviously not for mp4
[12:07:26 CET] <illegal> apparently this takes longer to make than the others
[12:08:13 CET] <furq> well yeah you're encoding more than one frame of video now
[12:08:20 CET] <illegal> yea
[12:15:04 CET] <Objectively_> There is a problem, it creates a non ending file furq , for example the song is 3:03 and the video (when I cancel it) was 30:20
[12:15:30 CET] <illegal> I guess I'll just specify the time
[12:15:41 CET] <furq> oh right yeah
[12:15:43 CET] <furq> add -shortest
[12:23:04 CET] <illegal> worked, but I swear I did this and it didn't work earlier, whatever I guess
[13:52:02 CET] <rom1v> hi, instead of av_register_all()/avcodec_register_all(), I would like to call avcodec_register(AVCodec*) manually for some codecs.
[13:52:06 CET] <rom1v> For that purpose, I do:
[13:52:09 CET] <rom1v> extern AVCodec ff_h264_decoder;
[13:52:14 CET] <rom1v> avcodec_register(&ff_h264_decoder);
[13:52:31 CET] <rom1v> But it does not link: undefined reference to `ff_h264_decoder'
[13:52:38 CET] <JEEB> yea, because it's not a public thing
[13:52:38 CET] <rom1v> (it works with av_register_all())
[13:52:47 CET] <JEEB> the av_register functionality is really broken
[13:53:01 CET] <JEEB> better is to build without the decoders you don't need
[13:53:02 CET] <rom1v> ok, so how can I register specific codecs?
[13:53:06 CET] <rom1v> ah ok
[13:53:13 CET] <JEEB> test your app first with a full build
[13:53:17 CET] <JEEB> and then when you know your code works
[13:53:20 CET] <JEEB> start disabling things
[13:54:09 CET] <JEEB> rom1v: or wait
[13:54:13 CET] <JEEB> actually for internal ones
[13:54:22 CET] <JEEB> I think you can get avcodec_by_name
[13:54:23 CET] <JEEB> or so
[13:54:30 CET] <JEEB> wonder if that works before registration :DD
[13:54:37 CET] <rom1v> ok, I'll check
[13:54:38 CET] <rom1v> thank you
[13:54:40 CET] <JEEB> if it doesn't then the limited build is the only way
[13:54:50 CET] <JEEB> that's how people do it usually anyways
[13:57:00 CET] Action: man_in_shack waes
[13:57:02 CET] <man_in_shack> *waves
[13:58:17 CET] <man_in_shack> trying to get ffmpeg to not output stats and encoding info. i've tried using -loglevel and -nostats and still getting floods of info from hevc, libx264, and matroska modules
[13:58:44 CET] <man_in_shack> input is hevc/h265, encoding using -c:a copy -c:v libx264
[14:00:02 CET] <man_in_shack> any help? i could always redirect stderr, but i'd rather do it by ffmpeg options
[14:03:49 CET] <Nacht> What exactly do you wish it to put out then ?
[14:04:58 CET] <JEEB> man_in_shack: you can list the verbosity levels with
[14:05:00 CET] <JEEB> ./ffmpeg -v derp
[14:05:09 CET] <JEEB> (which is a wrong string but it will list valid ones)
[14:05:26 CET] <JEEB> then -v LEVEL_YOU_WANT
[14:05:48 CET] <ubitux> don't forget the +repeat hack
[14:05:55 CET] <DHE> x264's encoder summary is at log level INFO. so pick something stricter than that. maybe WARNING?
[14:06:41 CET] <man_in_shack> still getting loads of output even with -v quiet, JEEB
[14:07:40 CET] <DHE> really? I got nothing
[14:08:02 CET] <JEEB> none for me too
[14:08:17 CET] <JEEB> ./ffmpeg -v quiet -i "udp://MULTICAST" -c:v libx264 -crf 25 -preset veryfast -an -sn -f null -
[14:08:31 CET] <JEEB> this outputs zarro for me
[14:09:20 CET] <DHE> all I got was a warning that the output file I selected already existed (which is my own fault)
[14:09:39 CET] <man_in_shack> hmm
[14:10:12 CET] <acos> I actually used ffmpeg the other night.
[14:12:58 CET] <DHE> rom1v: you're best off using: configure --disable-decoder="decoder1,decoder2,nameprefix*,decoder13", or --disable-encoders --enable-encoder="iwantthis,iwantthat,libx26*"
[14:13:18 CET] <DHE> I have a pretty horrific commandline I use to make a version of ffmpeg that's half the binary size of the usual one
[14:17:04 CET] <JEEB> yea, just remember to develop with a normal build first, and start scratching things off later :P
[14:17:16 CET] <JEEB> I've seen plenty of people forgetting protocols or parsers or whatever
[14:17:21 CET] <JEEB> what they actually need
[14:17:25 CET] <rom1v> on Linux I would like to use ffmpeg from the distrib (it works fine), but on Windows I copy all the .dll, and there are many that should not be used (libbluray.dll&), I was looking for a way other than building a specific ffmpeg version?
[14:17:28 CET] <JEEB> and they can't get off the ground at all
[14:17:50 CET] <JEEB> rom1v: no
[14:18:43 CET] <rom1v> ok
[14:19:41 CET] <DHE> the DLL is built with the dependency. there's nothing you can do about that without modifying (rebuilding) the DLL
[14:19:59 CET] <strepto> Hi guys! A question about using ffmpeg to convert my .aiff libary to .flac; Have anyone made tools to make bulk-conversion easier? Scripts, etc, that I could utilize? Simply "convert folder A, store new files in folder B - and be recursive about it.".
[14:21:47 CET] Action: man_in_shack grumbles
[14:22:17 CET] <man_in_shack> just updated ffmpeg to 3.4 from debian-multimedia.org and still getting flood of output even with -v quiet
[14:22:33 CET] <JEEB> something else in your command line is forcing it then
[14:22:55 CET] <JEEB> try what I noted, but with your input. it runs x264 and outputs to dev/null
[14:22:58 CET] <JEEB> you can run it for a while
[14:23:12 CET] <JEEB> and then ctrl+C it off :P
[14:23:35 CET] <DHE> I pressed 'Q' to be sure and it was still good.
[14:24:00 CET] <acos> I spammed ctrl + c and it waited 45 sec before quitting.
[14:24:21 CET] <acos> I'm still a noob. But was able to concat 3 videos
[14:24:39 CET] Action: man_in_shack $ ffmpeg -v quiet -hide_banner -nostats -y -i "$in" -c:a copy -c:v libx265 -crf 26 -tune animation "$out"
[14:24:41 CET] <acos> What audio types can go with an mpg file? It kept giving me mp2 audio.
[14:24:43 CET] <man_in_shack> that's my command
[14:24:53 CET] <acos> So I went to h264 after.
[14:26:38 CET] <JEEB> hide_banner and nostats should at this point be irrelevant as they wouldn't get output with -v quiet anyways
[14:26:52 CET] <man_in_shack> took them off and no change
[14:26:54 CET] <JEEB> libx265 might be a special snowflake maybe
[14:27:09 CET] <man_in_shack> oh, that's a typo ... should read libx264
[14:27:38 CET] <JEEB> well for that I get zarro/nada stuff
[14:27:39 CET] <sfan5> i was about to say that x265 has no animation tune
[14:30:51 CET] <man_in_shack> ok i think i've found the issue
[14:31:56 CET] <man_in_shack> yup, got it
[14:32:08 CET] <man_in_shack> needed -nostdin because of the loop i'm using. always forget about that
[14:35:34 CET] <man_in_shack> encoding now going nice and quickly :D
[14:38:36 CET] <man_in_shack> thanks for your suggestions guys
[19:08:01 CET] <Guest64229> Hello guys i have problem Unknown option "--enable-nvresize. ich wersion of ffmpeg i should download for nvresize support ?
[19:10:06 CET] <BtbN> There is no nvresize in ffmpeg.
[19:10:17 CET] <BtbN> It's called scale_cuda or scale_npp
[19:22:10 CET] <Guest64229> BtbN, So instad of configure --enable-nvresize i shuld  type configure --enable-scale_cuda or configure --enable-scale_npp ?
[19:23:05 CET] <BtbN> They both need the CUDA SDK to be found and enabled
[19:23:19 CET] <BtbN> and npp also needs libnpp, which is part of the sdk, but needs to be explicitly enabled
[19:24:31 CET] <Guest64229> I have installed CUDA SDK, can you help me with full configure string with enable commands ?
[19:30:47 CET] <mva> hi there!
[19:32:36 CET] <mva> can you advice me, please, how is it possible to fix that thing > https://gist.github.com/raw/56b7031fd49299f251e861b1b39b73d8 < in case if I **do** have kvazaar installed, and it **do** have /usr/lib64/pkgconfig/kvazaar.pc file on it's place?
[19:33:12 CET] <BtbN> Check the log it mentions
[19:34:16 CET] <DHE> the requirements (version) might have changed, but gentoo didn't update the ebuild. version 9999 does a git checkout on the spot so these breaks can happen
[19:34:41 CET] <BtbN> 0.8 is very old
[19:34:46 CET] <BtbN> gentoo only has versions >1.0
[19:37:21 CET] <BtbN> I don't think the kvazaar thing in ffmpeg is very well maintained. So possible that it just broke with newer versions
[19:52:06 CET] <JEEB> &29
[20:59:41 CET] <realies> apparently you cant stream hvec within flv, what should i use?
[21:00:27 CET] <realies> trying to do ffmpeg -loglevel verbose -i IMG_0510.MOV -c:v libx264 -preset ultrafast -tune zerolatency -crf 23 -c:a aac -b:a 128k -f flv rtmp://localhost:1935/stream/preview
[21:00:35 CET] <realies> but that bursts the file at x5 speed to the server and stops
[21:01:59 CET] <sfan5> you can use -re to force 1x
[21:18:41 CET] <realies> sfan5, that seems to help
[21:19:15 CET] <realies> is there a way to be streaming constantly and just changing the view based on the selected file? any ideas how to build something like that
[21:21:30 CET] <JEEB> use the API
[21:22:09 CET] <realies> JEEB, not quite good with c/c++
[21:22:14 CET] <JEEB> oh well
[21:22:58 CET] <JEEB> but yea, basically what you want is not to close the muxer/writing protocol, while the rest of the chain you might or might not need to flush and recreate
[21:23:01 CET] <JEEB> which ffmpeg.c doesn't do
[21:28:58 CET] <realies> JEEB, i guess that's not possible via the command line
[21:29:04 CET] <JEEB> no
[21:48:38 CET] <DHE> there may be tricks you can do with a program feeding ffmpeg via if you can give ffmpeg the illusion of a continuous feed...
[21:49:08 CET] <DHE> *via [named] pipe
[21:50:37 CET] <realies> DHE, how do you make one?
[21:50:50 CET] <DHE> a named pipe can be made on unix with mkfifo
[21:52:16 CET] <DHE> I haven't tested this, I'm making it up as I go. maybe something like: while true; do cat $inputfile.ts ; done | ffmpeg -i - [transcode options] [output]
[21:52:58 CET] <realies> but that has to read the files at their native speed
[21:53:05 CET] <DHE> this should play $inputfile.ts on a loop, and you could swap it out for any other video at any time to change what's playing
[21:53:10 CET] <realies> not sure what would happen if you force -re on ffmpeg with the above loop
[21:53:18 CET] <DHE> yeah, add -re to the ffmpeg. pipes have very small buffers most of the time so it should work out okay
[21:53:34 CET] <realies> so the stdin would wait?
[21:53:47 CET] <realies> or rather be delayed by the consumed process
[21:53:50 CET] <realies> *consuming
[21:58:04 CET] <realies> getting some [mov,mp4,m4a,3gp,3g2,mj2 @ 0x3e63de0] Found duplicated MOOV Atom. Skipped it
[22:09:50 CET] <DHE> I used .ts because it's a streaming-friendly format. MP4 might or might not work as well.
[22:14:38 CET] <quasti> Hi. I have a question regarding ffplay. I'm using ffplay for playing an rtp stream. The connection is not completely stable, so packet loss may occur, or packets may arrive late in bulk. Over time this has the effect that ffplay starts building up a delay, so it is not realtime anymore. The delay seems to be unlimited, it can reach 10 seconds of delay after 10 minutes of playing. Are there any settings that I can tweak to avoid that k
[22:30:34 CET] <realies> DHE, i've managed to do it with the file list txt input method
[22:30:43 CET] <realies> although it loses the video sync from time to time
[22:31:00 CET] <realies> ffplay -loglevel verbose rtmp://dev.reali.es/stream/preview
[22:33:45 CET] <sfan5> quasti: i don't think ffplay is supposed to be a "proper" media player meaning it doesn't handle AV desync
[22:34:05 CET] <sfan5> well it's not AV desync in this case but you get what i mean
[22:40:11 CET] <realies> lowering the resolution to -vf scale=-1:270 it seems to work fine now
[22:42:14 CET] <realies> when doing 720p or 1080p it goes weird
[22:42:21 CET] <realies> perhaps transcode to ts?
[23:03:54 CET] <alexpigment> realies: fyi, scale=-1:270 can cause failures if your source content varies in resolution
[23:04:07 CET] <alexpigment> you ideally want to change this to scale=-2:270
[23:04:53 CET] <alexpigment> i'm not sure if that applies to playback necessarily, but encoders and decoders usually want even numbered resolutions, if not resolutions divisible by 4 or 8
[23:39:16 CET] <realies> alexpigment, streaming 720p via hls works just fine, so i guess im not feeding the transcoder with video fast enough? i can see that the speed goes to 0.99x sometimes
[23:39:45 CET] <realies> i was hoping to have a low latency feed via rtmp
[23:39:56 CET] <realies> maybe some buffers magix has to be done
[23:40:08 CET] <alexpigment> realies: to be honest, i'm not familiar enough with the situation. i just saw that you were using -1:270, I've learned the mistake of -1 on several occasions :)
[00:00:00 CET] --- Fri Nov 17 2017