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

[burek]

[07:22:32 CET] <avi_m> Hello, I have some http input stream which the server recreates each 17~ seconds, meaning that in order to play it one would turn on "replay" in his video player and open the strea, what i'm trying to do is to generate m3u8 playlist that will buffer the video for me. I was trying to use this command - https://pastebin.com/XCkZNtq9 . with infinte list of the same link but it keep generating ts files for only first http stream
[07:22:38 CET] <avi_m> any idea how to fix it ?
[07:27:20 CET] <avi_m> ffmpeg output - https://pastebin.com/3gfUKxF8
[09:11:50 CET] <th3_v0ice> How does FFmpeg handle videos that have interlaced and progressive frames?
[09:12:00 CET] <JEEB> AVFrames will have the coding mode
[09:12:08 CET] <JEEB> and I think the field order
[09:12:19 CET] <JEEB> with the *content* you will have to actually look (TM)
[09:30:55 CET] <FishPencil> How do I convert an RGB png file to a raw YUV444P file and preserve the full range?
[09:32:04 CET] <th3_v0ice> So does it simply pass everything in to some of the deinterlace filters like bwdif, yadif, or it looks at the coding modes and according to that uses or not the filter. I am interested in sequences that have mixed interlaced and progressive frames.
[09:32:10 CET] <FishPencil> I tried ffmpeg -i i.png -pix_fmt yuv444p -vf setrange=full -f rawvideo i.yuv444p
[09:32:23 CET] <furq> FishPencil: yuvj444p
[09:33:39 CET] <FishPencil> furq: What is the j?
[09:33:55 CET] <furq> jpeg/pc/full range
[09:34:26 CET] <FishPencil> Oh nice
[09:34:31 CET] <FishPencil> That looks correct
[09:34:50 CET] <FishPencil> I see there's also an "a"?
[09:34:56 CET] <furq> alpha
[09:35:06 CET] <FishPencil> Ah
[09:36:29 CET] <furq> th3_v0ice: you can set yadif etc to only deinterlace frames flagged as interlaced
[09:38:12 CET] <furq> there's also the idet filter if the video isn't flagged correctly
[09:38:27 CET] <th3_v0ice> furq: I set bwdif to do exactly that, but now my audio and video are not in sync.
[09:38:37 CET] <furq> are you using send_field mode
[09:39:02 CET] <furq> you should probably not do that
[09:39:03 CET] <th3_v0ice> bwdif=0:-1:1, I am using API just for reference.
[09:39:23 CET] <furq> no idea then
[11:56:57 CET] <th3_v0ice> Is there a way to force bwdif filter not to touch PTS info of non interlaced frames?
[12:03:13 CET] <durandal_1707> nope
[12:05:56 CET] <JEEB> yea the filter itself doesn't touch things it seems. it just sets the frame rate for the link
[12:06:09 CET] <JEEB> unless that code is moved to some common place
[12:06:14 CET] <JEEB> instead of being vf_bwdif
[12:06:31 CET] <JEEB> I would guess deint=interlaced would remove some filtering?
[12:06:44 CET] <JEEB> since it would then only touched pictures coded in progressive mode
[12:06:48 CET] <JEEB> or well, flagged progressive
[12:08:04 CET] <JEEB> ok, it seems to be largely re-using yadif base code regarding that
[12:08:07 CET] <JEEB> so the logic should be the same
[12:09:01 CET] <th3_v0ice> Where is that source code located? What is the file name?
[12:09:18 CET] <JEEB> libavfilter/vf_yadif.c and vf_bwdif.c etc related
[12:09:37 CET] <JEEB> libavfilter/yadif_common.c as well
[12:10:20 CET] <JEEB> ff_yadif_filter_frame has the deint checks
[12:13:01 CET] <th3_v0ice> Ok, thanks
[17:05:56 CET] <TheOneRing_m> hi
[17:06:13 CET] <TheOneRing_m> I'm trying to build ffmpeg with msvc and lame enabled
[17:06:15 CET] <TheOneRing_m>  --enable-shared                 --disable-debug --disable-doc --enable-gpl --enable-version3                 --enable-avresample --enable-libmp3lame  --toolchain=msvc
[17:06:25 CET] <TheOneRing_m> ERROR: libmp3lame >= 3.98.3 not found
[17:06:59 CET] <TheOneRing_m> the lame makefile for msvc produces
[17:07:02 CET] <TheOneRing_m> https://www.irccloud.com/pastebin/LTxZyu3d/
[18:26:41 CET] <avi_m> Hi, I have http stream which regenerates each 20~ seconds, I try to fetch it and convert to hls (m3u8) in order to buffer it, I use following command - https://pastebin.com/w8furX35 . The problem is ffmpeg only take the file once and does not re-GET it, any idea what i'm doing wrong ?
[18:30:29 CET] <eschmidbauer> hi. id like to use ffmpeg to transcode wav -> mp3. so far it works great. just wondering if there is a way to tell ffmpeg to write to a "temp" file (or folder) until the encoding is completed, then move the completed file to the desired output destination
[18:32:37 CET] <JEEB> no
[18:32:57 CET] <JEEB> you will have to script or code that yourself as a user of ffmpeg.c or the FFmpeg APIs
[18:33:45 CET] <eschmidbauer> really? i would think this is a common use-case
[18:36:08 CET] <JEEB> well it is something that is outside of the use case IMHO. FFmpeg will write the output somewhere. if you want the file specifically to not be available in the end result, then you write into a temporary file or so, and then rename/move (depending on if you're on the same file system) it to the place you want in the end
[18:36:58 CET] <JEEB> I can see an application utilizing the APIs or ffmpeg.c doing this, but I do not think "move after completion" as something that should be in the thing itself as a specifically coded function
[18:38:14 CET] <eschmidbauer> really? cuz what if you are "watching" a directory for transcoded files? how could you handle that ? cuz ffmpeg will write them instantly into the directory, the "watcher" has no way of knowing if they are completed or not
[18:38:57 CET] <JEEB> what I just said, a user of FFmpeg should do the moving if such requirements are there, not ffmpeg.c
[18:39:38 CET] <JEEB> often it's not just that, but also various other rules like file names etc
[18:39:48 CET] <JEEB> if you're already doing that on your automation or whatever side
[18:39:58 CET] <BtbN> Use your shell to do that
[18:40:08 CET] <BtbN> it's nothing more than "&& mv ..."
[18:40:22 CET] <JEEB> or batch or python or powershell or whatever
[18:40:36 CET] <eschmidbauer> i was hoping to do this all inside a system call from golang
[18:40:49 CET] <eschmidbauer> and not have to worry about output or return result
[18:41:10 CET] <BtbN> Don't use system(), it's always bad design
[18:41:21 CET] <BtbN> (and it's not what you call a system call)
[18:41:46 CET] <eschmidbauer> there are no go pkgs that can transcode
[18:41:52 CET] <eschmidbauer> so i have to call a system call
[18:42:00 CET] <BtbN> But there surely are packages to cleanly invoke processes
[18:42:02 CET] <JEEB> eschmidbauer: you already have an app that has your own use cases there. adding things to ffmpeg.c etc just complicates things for no real reason
[18:42:20 CET] <JEEB> just mktemp for the file either on the same disk or in general tmpt
[18:42:22 CET] <JEEB> *tmp
[18:42:34 CET] <eschmidbauer> JEEB: i really disagree with you but it's fine. no point in arguing
[18:42:37 CET] <JEEB> then launch, if everything's good, rename/move
[18:42:57 CET] <JEEB> eschmidbauer: do note that I'm not against the use case. just the fact that putting that into ffmpeg.c doesn't make much sense
[18:43:02 CET] <eschmidbauer> having a "tmp" file is like using a buffer file. it makes complete sense if implemented with a flag
[18:43:25 CET] <BtbN> It's trivial to do with any shell or whatever you use. No point in adding it.
[18:43:28 CET] <JEEB> ^
[18:43:37 CET] <DHE> but then you have to specify where/what the buffer file is
[18:43:41 CET] <JEEB> it's more complexity to add it into ffmpeg.c than just have people who have their own application logic
[18:43:55 CET] <JEEB> also people can expand on that in N different ways
[18:43:58 CET] <eschmidbauer> i actually dont give a crap about where/what the buffer file is
[18:43:59 CET] <JEEB> also it's not always files etc
[18:44:06 CET] <DHE> clearly you do
[18:44:08 CET] <eschmidbauer> i just want the final output in a folder
[18:44:23 CET] <DHE> <eschmidbauer> really? cuz what if you are "watching" a directory for transcoded files?   # then you have a problem with that way
[18:44:41 CET] <eschmidbauer> the transcoded files would be the final output
[18:44:43 CET] <JEEB> what you now actually mean is that you want it somewhere from where you can rename()
[18:44:56 CET] <JEEB> because as soon as you move() you start catching non-final data
[18:45:03 CET] <JEEB> in your watching :P
[18:45:03 CET] <DHE> and that somewhere will vary. maybe a different extension works, maybe a .hidden file works, maybe another directory works
[18:45:18 CET] <JEEB> yes, it's heavily user's use case specific
[18:45:41 CET] <eschmidbauer> yea pretty sure other libs have this type of flag. im really surprised ffmpeg doesn't
[18:45:46 CET] <eschmidbauer> i'll just go with something else
[18:45:53 CET] <JEEB> ok, cool
[18:45:59 CET] <BtbN> (the img2 muxer actually does exactly that with a ${filename}.tmp, and it causes issues every now and then)
[18:46:23 CET] <eschmidbauer> yea this doc mentions it too
[18:46:26 CET] <eschmidbauer> https://ffmpeg.org/ffmpeg-all.html
[18:46:30 CET] <eschmidbauer> `temp_file`
[18:46:57 CET] <BtbN> That's for HLS
[18:47:23 CET] <JEEB> yes, various people implemented their own little use cases in various places. whether that works for you is a whole separate discussion, and I would like to not add to that list since you will always get "one more"
[18:47:23 CET] <DHE> which does in fact require atomic updates because users are expected to be downloading the .m3u8 at all times
[18:47:59 CET] <BtbN> It doesn't even use it for the m3u8, but for the segment currently being written
[18:48:02 CET] <eschmidbauer> BtbN: yes- so apparently HLS use-case fits
[18:48:07 CET] <eschmidbauer> idk what HTLS is
[18:48:19 CET] <eschmidbauer> but clearly there is need for such a flag there...
[18:48:25 CET] <BtbN> It's a thing internal to HLS, not a public feature for generic use
[18:48:28 CET] <DHE> literally "HTTP live streaming". being a live-stream protocol rather than a batch job protocol, it has different needs
[18:48:44 CET] <BtbN> I really don't get what your issue with two, or even one, extra line of code is
[18:48:59 CET] <JEEB> anyways, there are over 9000 things that warp around FFmpeg or related things
[18:49:03 CET] <BtbN> ffmpeg ... /tmp/out.mp3 && mv out.mp3 wherever.mp3
[18:49:04 CET] <BtbN> done
[18:49:06 CET] <JEEB> I recommend you poke there if you don't want to handle it yourself
[18:50:30 CET] <eschmidbauer> what happens if ffmpeg fails there
[18:50:45 CET] <BtbN> It fails
[18:50:52 CET] <BtbN> You are aware what && does?
[18:51:00 CET] <eschmidbauer> i guess problem is, i can't run that from a single system call
[18:51:09 CET] <BtbN> It's not a system call.
[18:51:17 CET] <BtbN> And don't ever use system(), it's seriously bad.
[18:51:19 CET] <JEEB> your whole logic somehow already made things such as the file name
[18:51:23 CET] <JEEB> but I digress
[18:51:35 CET] <eschmidbauer> what should i use instead of system() in golang?
[18:51:38 CET] <JEEB> executing a process and checking nonzero exit code should not be a Hard Thing
[18:51:56 CET] <JEEB> https://golang.org/pkg/os/exec/
[18:51:59 CET] <BtbN> No idea about Go, but it _has_ to have something to properly invoke a process, pass arguments as an array, and get the final status code
[18:52:01 CET] <eschmidbauer> ah
[18:52:01 CET] <JEEB> this should do the trick?
[18:52:15 CET] <JEEB> also you can additionally get the piped output if needed
[18:52:19 CET] <JEEB> or pipe something yourself
[18:52:32 CET] <DHE> system() just calls: sh -c "(your string here)"     which is potentially a can of worms if you don't do quoting and escaping properly
[18:52:50 CET] <JEEB> yea, APIs that take in an argument *list* generally are what you want
[18:52:58 CET] <BtbN> And it has different semantics depending on what sh is
[18:53:01 CET] <eschmidbauer> how is that better than system()?
[18:53:08 CET] <BtbN> ...
[18:53:13 CET] <JEEB> :)
[18:53:41 CET] <eschmidbauer> what does exec do differently
[18:53:46 CET] <JEEB> if you don't care about making sure the command goes out in the way you think it will, and all you need is the exit code - probably no difference
[18:54:08 CET] <JEEB> I of course am expecting system() to also return the exit code
[18:54:14 CET] <JEEB> which I didn't check :P
[18:54:20 CET] <another> it starts a process. instead of starting a shell with arguments
[18:56:34 CET] <eschmidbauer> https://play.golang.org/p/j8zvxQHX54p
[18:56:45 CET] <eschmidbauer> throws an error
[18:56:50 CET] <JEEB> yes
[18:56:57 CET] <JEEB> -i is an argument
[18:57:03 CET] <JEEB> the input file name should be the next
[18:57:07 CET] <JEEB> not as a single argument
[18:57:11 CET] <JEEB> that's the *good* side of such APIs
[18:57:19 CET] <eschmidbauer> oh thanks
[18:57:21 CET] <JEEB> for example if you have a file name with spaces or anything else that is random
[18:57:23 CET] <eschmidbauer> that worked
[18:57:37 CET] <JEEB> if you do a shell, you have to make sure you have properly ""'d or otherwise made it lovely
[18:57:42 CET] <JEEB> with actual separate arguments
[18:57:47 CET] <eschmidbauer> yea i can see how this is better, thanks for the help
[18:57:57 CET] <JEEB> cool :)
[18:58:49 CET] <JEEB> I think one of the most "what?" moments I've had with python came from them having an API like this, except they also let you pass in a single string which they would then parse as if they were a shell
[18:59:00 CET] <JEEB> which kind of... counters the whole idea of a command launching API
[18:59:05 CET] <JEEB> at least in my opinion
[18:59:34 CET] <JEEB> of course the positive side is that it will not go into an actual shell
[18:59:38 CET] <JEEB> but still :P
[18:59:56 CET] <eschmidbauer> i still think ffmpeg should have this flag
[19:00:09 CET] <eschmidbauer> it's a common use-case and isn't difficult to support
[19:00:37 CET] <JEEB> uhh, the problem is - it's not. unless you take a *lot* of decisions that limit things
[19:00:51 CET] <JEEB> like for example many things first make a file that starts with a dot in the same dir
[19:00:54 CET] <JEEB> or something like that
[19:00:59 CET] <JEEB> and then rename() in the end
[19:01:13 CET] <JEEB> but then your own logic has to be able to handle that
[19:01:18 CET] <JEEB> so it touches *your* logic anyways
[19:01:52 CET] <JEEB> or then you have to decide on the temporary file name, in which case we're once again delegated majority of the logic to the user
[19:03:31 CET] <JEEB> so yea, since it's so user's use case specific, I'm happy to leave something that can for that user be so simple (because they know their specific use case!)
[19:04:20 CET] <JEEB> what FFmpeg should care about is to provide the means to do in and out
[00:00:00 CET] --- Wed Jan 16 2019