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

[burek]

[01:26:27 CEST] <PhantomSc> Does anyone have an example of how to use '-hls_segment_size'?
[02:18:56 CEST] <unlord> how do I find out what version of libaom is in ffmpeg N-93083-g8522d219c
[02:22:50 CEST] <unlord> I'm sure the answer is in a file somewhere in here: https://gitlab.com/UbikBSD/Codecs/FFMpeg/tree/8522d219c
[02:36:00 CEST] <unlord> how about just printing the one linked in
[02:36:13 CEST] <unlord> ffmpeg -encoders shows libaom-av1
[02:44:30 CEST] <kepstin> unlord: might not be an easy way to know without asking the person who built the ffmpeg binary you're using, unless it prints it in a log when encoding something (some encoders do, i haven't checked libaom) or maybe just looking for the version string in the compiled binary :/
[02:45:09 CEST] <kepstin> libaom is an external library, so there's no correlation between the ffmpeg version and the libaom version
[02:51:58 CEST] <unlord> kepstin: I downloaded the static Windows build ffmpeg-20190205-8522d21-win64-static.zip and got it by running some video through it: [libaom-av1 @ 0000000000388640] 1.0.0-1297-g52ea88fd1
[02:53:05 CEST] <unlord> Gotta go back and verify these results https://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=130284 after this announcement https://twitter.com/janozer/status/1113930266983190529
[02:53:32 CEST] <kepstin> unlord: that looks like a zeranoe build - here's the readme: https://ffmpeg.zeranoe.com/builds/readme/win64/static/ffmpeg-20190205-8522d21-win64-static-readme.txt
[02:54:13 CEST] <unlord> kepstin: libaom is not listed there
[02:54:27 CEST] <kepstin> it is, it's just called 'aom'
[02:54:37 CEST] <kepstin> shows the same git hash as you saw in the log
[02:54:46 CEST] <unlord> wooops, you are right
[02:55:09 CEST] <unlord> No idea if Jan Ozer was using this build, but without asking him who knows
[02:55:46 CEST] <unlord> Note that the MSU results just came out and came to a very different conclusion on page 17: http://www.compression.ru/video/codec_comparison/hevc_2018/pdf/MSU_HEVC_AV1_comparison_2018_P4_HQ_encoders.pdf
[02:56:22 CEST] <unlord> but he wasn't really trying to do the same comparison, so it just sloppy reporting
[03:02:09 CEST] <kepstin> every time i see these comparisons, i'm impressed by how close the quality of x264 is to the newer codecs while it's still /way/ faster to encode.
[03:03:36 CEST] <furq> unlord: the aom version in the msu report is from january 30th
[03:04:44 CEST] <furq> https://aomedia.googlesource.com/aom/+/625cded0550bb79efd10d98a9809a7ccd72a8f60
[03:04:50 CEST] <kepstin> huh, the msu report didn't run av1 in a bitrate target mode, they used cq?
[03:05:09 CEST] <kepstin> is 2-pass mode just not finished, or did they not feel like waiting? :)
[03:05:12 CEST] <unlord> 625cded0 = Date:   Tue Jan 29 19:50:20 2019 -0800
[03:05:22 CEST] <unlord> but yeah, that is just the authored date
[03:05:27 CEST] <furq> yeah close enough
[03:05:37 CEST] <furq> also idk how much i trust those msu reports if they're only using ssim
[03:05:49 CEST] <furq> maybe they do some better analysis in the paid version
[03:07:06 CEST] <unlord> furq: when you scroll that blurred PDF, my reader gets jank.  Just sayin....
[03:07:17 CEST] <furq> i was going to ask what sz264/sz265 is but the link in the codecs list is just a mailto:
[03:07:28 CEST] <furq> not really sure why they would include this but ok
[03:09:04 CEST] <kepstin> presumably someone paid them to?
[03:09:20 CEST] <kepstin> kinda amazing how closely sz264 tracks to x264 on some of the graphs...
[03:09:29 CEST] <furq> yeah until you get to encoding time
[03:12:15 CEST] <kepstin> so it's x264 being run in placebo mode, maybe with some asm optimizations removed? :)
[03:25:56 CEST] <DHE> AV1 at 1 megabit can encode 1080p @ 25fps at very watchable image quality...
[03:27:05 CEST] <DHE> (I did a test video a while ago... many months)
[05:26:48 CEST] <Kuukunen> 4
[07:49:28 CEST] <lindylex> I am try to compile ffmpeg with gltransition and I keep getting the following error. https://pastebin.com/JW1Nsehf
[13:34:27 CEST] <CCFL_Man> hello, what can one use in place of ffserver? the modern freebsd ports don't have it
[13:35:07 CEST] <CCFL_Man> can mkvserver_mk2 provide the same stream that could be compatible with other players?
[14:12:31 CEST] <DHE> people say good things about nginx-rtmp
[14:13:05 CEST] <DHE> if HTTP-based streaming is acceptable, HLS or Dash with just any old static content HTTP server (apache, nginx plain, etc) can work at the cost of high delay live streaming
[15:05:32 CEST] <faLUCE> hello all
[15:10:45 CEST] <Freneticks> Hey Is it possible to have 2 input stream and change if input 1 is down to >> -c copy test.ts
[15:19:30 CEST] <DHE> ffmpeg doesn't do that dynamically. some manual control can be done with the streamselect filter, but ffmpeg in general doesn't handle outages like that either
[15:27:13 CEST] <saml_> you can set up proxy and do failover in the proxy
[15:29:07 CEST] <Freneticks> what kind of proxy are you thinking about saml_
[15:29:14 CEST] <Freneticks> or maybe with dns
[15:29:55 CEST] <saml_> ah is it generating livestream?
[15:30:02 CEST] <Freneticks> yes
[15:30:24 CEST] <saml_> and you have two source streams?  what protocol those source streams use? HTTP?
[15:30:34 CEST] <saml_> i'm not familiar with livestream
[15:30:45 CEST] <Freneticks> http yes
[15:31:17 CEST] <saml_> i think nginx and haproxy can do failover. If one http upstream is down, use another
[15:32:11 CEST] <Freneticks> nice idea will check that
[15:32:30 CEST] <saml_> but i don't know how well failover at loadbalancer would  work with livestream. it could introduce glitches during failover
[16:08:56 CEST] <pink_mist> Freneticks: I was recently informed of http://upipe.org/blog/ which I was told was what one should use rather than (or possibly in front of) ffmpeg for that kind of thing ... I've never used it myself though, so I can't really say whether or not it'll actually work
[16:09:29 CEST] <JEEB> it's a framework more geared for live streaming, esp. in broadcast environments. it uses FFmpeg for decoding etc, of course
[16:09:45 CEST] <JEEB> it does not have standard modules for web streaming etc, of course
[16:09:55 CEST] <JEEB> but it's something I've been meaning to look into for a while
[16:10:28 CEST] <pink_mist> yeah, JEEB was the one who informed me :P (though I think he was informing someone else at the time; I was just listening on the side :P)
[16:12:14 CEST] <friendofafriend> I was feeding images and audio through a FIFO at ffmpeg to make slideshows.  It works sort of OK, but all the sync problems you'd imagine.
[16:14:47 CEST] <Freneticks> JEEB: It's a low level lib, why not go on gstreamer and built something good ?
[16:15:16 CEST] <JEEB> that's another framework, and also already has logic like switching between alternative inputs?
[16:15:22 CEST] <JEEB> also it seems to have alright inputs for stuff like MPEG-TS
[16:15:28 CEST] <JEEB> and I like the concept of three timestamps
[16:15:32 CEST] <JEEB> you have the original coded timestamp
[16:15:40 CEST] <JEEB> you have the adjusted coded timestamp
[16:15:44 CEST] <JEEB> and you have the receipt time
[16:15:57 CEST] <JEEB> different applications can utilize these things for different things
[16:18:39 CEST] <Freneticks> unfortunately i don't know anything about gstreamer, never took the time learn, but seems powerfull, and have the pipe concept too
[16:18:55 CEST] <JEEB> all the frameworks have some sort of "pipeline" going
[16:19:07 CEST] <JEEB> FFmpeg, upipe, gstreamer
[16:20:51 CEST] <Freneticks> Also gstreamer have python bindings which can save me to learn C ^^
[16:45:13 CEST] <while> is rfc3533 the rfc implemented by ffmpeg when encoding OGG files?
[16:55:42 CEST] <JEEB> no idea
[16:56:15 CEST] <JEEB> it has an ogg muxer which seems apparently capable of writing ogg files readable by other applications
[17:00:06 CEST] <kepstin> i'm pretty sure ffmpeg's ogg muxer was written before rfc3533 was published
[17:00:46 CEST] <kepstin> but on the other hand, rfc3533 is supposed to be a document of the ogg container as it existed
[17:05:23 CEST] <kepstin> ogg itself is of course pretty simple, the tricky stuff is mostly in the individual codec mappings.
[17:07:19 CEST] <JEEB> yea
[17:33:27 CEST] <Hello71> even though mans hates it
[17:41:32 CEST] <dongs> dongs
[17:44:19 CEST] <JEEB> perkele
[18:43:24 CEST] <CCFL_Man> DHE: i just need low latency http streaming, same thing as what ffserver provided
[18:58:35 CEST] <TAFB> How do I get microsecond in my filename with strftime? supposed to be %f I think but I always get "Could not get segment filename with strftime" if I use %f
[19:16:56 CEST] <TAFB> "there is no way to get the current time with a higher precision than seconds in POSIX on which FFmpeg depends."
[19:16:58 CEST] <TAFB> oh damn :(
[19:24:40 CEST] <TAFB> if I can't use microsecongs, how about what frame I'm at in the -i file?
[19:29:31 CEST] <TAFB> or how can I use a random number in the filename?
[19:29:39 CEST] <TAFB> (windows)
[20:21:42 CEST] <while> TAFB: you could probably find a proprietary solution (for creating random numbers) if nothing else works
[20:38:00 CEST] <coolhp48> Hello all. I was wondering if this is the appropriate channel to ask a question about libavcodec/libavformat ?
[20:38:19 CEST] <JEEB> it is
[20:38:39 CEST] <JEEB> this channel for API usage of FFmpeg's libraries, and then the -devel channel is for actual development within the FFmpeg libraries
[20:42:03 CEST] <coolhp48> Wonderful. I am in the middle of a puzzle I cant seem to figure out how to solve : I'm trying to decode raw AAC audio frames directly. The data I receive doesnt give me access to the packet itself. I just receive a variable with some context (like the number of channels and number of samples)
[20:42:16 CEST] <coolhp48> And a buffer containing a raw AAC frame.
[20:43:45 CEST] <coolhp48> In theory the right function to decode it would be either aac_decode_frame_int or aac_decode_frame but I cant access those if I just include libavcodec.h
[20:44:07 CEST] <Mavrik> You shouldn't call those directly
[20:44:17 CEST] <coolhp48> I've tried "reconstructing" an AVPacket from the buffer but to no avail...
[20:44:34 CEST] <coolhp48> I'm at a bit of a loss as to what to try next.
[20:44:43 CEST] <Mavrik> see https://ffmpeg.org/doxygen/trunk/decode__audio_8c_source.html
[20:45:25 CEST] <coolhp48> Hi Mavrik. Thanks for the link. I've actually used that example as a roadmap for everything I've tried.
[20:46:02 CEST] <coolhp48> But the issue with that example is that it expects the contents of the buffer to be a full ADTS/AAC Packet, not just a frame.
[20:46:03 CEST] <JEEB> if you don't know if your data is properly separated per packet
[20:46:09 CEST] <JEEB> oh
[20:46:12 CEST] <JEEB> it's not ADTS?
[20:46:24 CEST] <JEEB> or the thing that's in MP4?
[20:46:43 CEST] <coolhp48> It should be. But what I'm receiving is really a raw audio frame. Not a full packet.
[20:47:22 CEST] <coolhp48> I know its a proper frame because the headers are correct (ie : the first 3 bits indicate either TYPE_CPE, or TYPE_LFE or other)
[20:47:35 CEST] <coolhp48> So its really a frame I'm trying to decode, not a packet.
[20:50:18 CEST] <coolhp48> Here's an example of the buffer I'm being served : https://pastebin.com/iyqPU5E4
[20:57:11 CEST] <coolhp48> In theory, would this work ? Create an AVFrame, put that raw frame data I'm receiving in ->data[0], then create an AVPacket and somehow store that frame in that new packet, then follow the same logic as decode_audio.c does to finally get the decoded audio buffer ?
[21:05:27 CEST] <JEEB> AVFrames are for raw audio/video/etc
[21:05:32 CEST] <JEEB> AVPackets are something to feed into a decoder
[21:05:43 CEST] <JEEB> or received from an encoder
[21:05:49 CEST] <coolhp48> Ok.
[21:06:13 CEST] <coolhp48> So assuming I have a byte array that contains an encoded AAC frame... how would I go about decoding it ?
[21:06:18 CEST] <JEEB> so you would have to make an AVPacket out of your data in a format that lavc's decoder can take it in
[21:06:55 CEST] <JEEB> coolhp48: you make a new AVPacket with the buffer allocated with FFmpeg helpers (to make sure you have needed alignment and additional buffer)
[21:07:07 CEST] <JEEB> then make sure your frame is packaged in a way that the AAC decoder can eat
[21:08:45 CEST] <coolhp48> Aye... with you so far :-) That's what I've been trying to do... Let me cleanup my code a bit and try again.
[21:10:15 CEST] <JEEB> ok, so it expects when you init the decoder that you have the sample rate there
[21:10:38 CEST] <coolhp48> Yup, I have that.
[21:11:17 CEST] <JEEB> also channel count as far as I can see
[21:11:41 CEST] <coolhp48> Just to give you a bit more context, I'm trying to decode an Apple Airplay 2 stream... while the contents of the frames are the same (proper AAC frames) the packets are in a completely different format.
[21:11:43 CEST] <JEEB> I'm just looking at what the aac_decode_init() function seems to require to be set
[21:11:45 CEST] <coolhp48> Thus my issue.
[21:12:17 CEST] <coolhp48> (We're talking AAC stream here, not one using Apple's Lossless codec)
[21:14:43 CEST] <JEEB> coolhp48: also if you have means to make it into ADTS or so, sticking the raw aac reader in front of the decoding might let you get the parsing for free, too
[21:14:51 CEST] <JEEB> and thus make the whole shebang simpler
[21:15:36 CEST] <coolhp48> Ah... that might be a good option... is there an example of how to call up the raw aac reader ?
[21:16:20 CEST] <JEEB> there should be an example of how to utilize your own AVIO callback implementation with libavformat
[21:16:38 CEST] <JEEB> then you just set the format to be "aac" in the AVFormatContext creation
[21:17:01 CEST] <JEEB> yea, doc/examples/avio_reading.c
[21:17:15 CEST] <JEEB> seems to be a "libavformat AVIOContext API example."
[21:17:27 CEST] <JEEB> in other words, instead of reading from a file or protocol
[21:17:39 CEST] <JEEB> you would be providing the functions which libavformat calls when it wants to read or write or seek
[21:17:47 CEST] <JEEB> of course in your case you just implement read
[21:18:12 CEST] <coolhp48> Looks very promising :-) ... I'm going to read up on it and see what I can figure out.
[21:18:48 CEST] <JEEB> you just have to make sure you can make ADTS AAC from whatever you're given
[21:25:47 CEST] <coolhp48> Ah... down the rabbit hole I went and low and behold, it looks like what I have are actually LATM ? Trying to understand what that is.
[21:28:12 CEST] <JEEB> coolhp48: ok, then you should be able to feed that into the loas reader
[21:28:26 CEST] <JEEB> as opposed to the "aac" one which ADTS
[21:29:08 CEST] <coolhp48> Trying to adapt the decode example with that in mind.... brb
[21:31:08 CEST] <coolhp48> There seems to be a code for that directly (CODEC_ID_AAC_LATM)
[21:32:41 CEST] <JEEB> yes, of course you can try your chances and try making an AVPacket out of your data and feeding that into the AAC decoder with that codec id
[21:33:03 CEST] <JEEB> if that doesn't seem to work, then you'll have to try the "demuxer" level thing with your own AVIO callbacks
[21:33:18 CEST] <JEEB> which will then call the parser on the stream and all that fancy stuff
[21:33:45 CEST] <coolhp48> Thanks a lot JEEB.... I'm going to keep going down this avenue and see where it leads.
[21:38:07 CEST] <texasmynsted> I have videos recorded using OBS to h264 using "Apple VT H264 Hardware Encoder" with aac audio in mkv container.
[21:38:55 CEST] <texasmynsted> They can not be seeked. They play but only from start to finish, no seeking of any kind. I tried copy to mp4, but the same issue exists.
[21:39:04 CEST] <texasmynsted> How can I fix this?
[21:39:54 CEST] <BtbN> Just remuxing to any other container will fix that. The encoder is entirely irrelevant for that. Unless it did some insanity like not adding I frames at all.
[21:40:21 CEST] <texasmynsted> I added bframes
[21:40:26 CEST] <texasmynsted> during encoding
[21:40:53 CEST] <texasmynsted> so copy from mkv to mp4, should have fixed it?
[21:41:51 CEST] <JEEB> yes, if it has random access points correctly marked
[21:42:05 CEST] <BtbN> bframes don't matter either
[21:42:09 CEST] <JEEB> you might try to extract into a raw .264 file first
[21:42:19 CEST] <BtbN> that'll mess up sync with the audio
[21:42:28 CEST] <JEEB> if it's VFR, yes
[21:42:35 CEST] <BtbN> Even if not
[21:42:49 CEST] <JEEB> and I was going to note L-SMASH's mxuer because the frame rate setting patch is not in yet
[21:42:51 CEST] <BtbN> Audio and Video might be offset a bit
[21:42:56 CEST] <JEEB> well yes
[21:43:55 CEST] <BtbN> I'd first make sure if that thing has more than one I frame
[21:44:18 CEST] <texasmynsted> how?
[21:46:16 CEST] <JEEB> ffprobe's show_packets might not show anything else than what the container is informing it of. thus, probably ffprobe's show_frames + grep for the keyframe flag
[21:46:23 CEST] <JEEB> I think it was also in AVFrames?
[21:46:28 CEST] <JEEB> don't remember
[21:49:43 CEST] <coolhp48> I'm now hitting a strange problem : When I call "codec = avcodec_find_decoder(AV_CODEC_ID_AAC);
[21:49:43 CEST] <coolhp48> " , it always return 0x00... any ideas ?
[21:49:56 CEST] <JEEB> how old FFmpeg?
[21:50:04 CEST] <JEEB> also you need specifically the LATM one
[21:50:16 CEST] <JEEB> AV_CODEC_ID_AAC_LATM
[21:51:08 CEST] <coolhp48> Yup, that's what I tried too. My FFMpeg is 3.2.12
[21:51:23 CEST] <JEEB> ok, then you need to call av_register_all
[21:51:29 CEST] <JEEB> as one of your first things :P
[21:51:43 CEST] <JEEB> that was made unnecessary half a year or so ago
[21:51:45 CEST] <JEEB> I think?
[21:51:54 CEST] <texasmynsted> I guess -count_frames
[21:52:14 CEST] <coolhp48> Doh ! ... thank you !
[21:52:25 CEST] <JEEB> texasmynsted: -of json -show_frames |grep keyframe ... I think?
[21:52:26 CEST] <texasmynsted> but it will probe for the entire time of the video (I am guessing). Video is 1 hour
[21:52:37 CEST] <JEEB> it will decode the whole shebang as fast as it can :P
[21:52:48 CEST] <texasmynsted> ok
[21:53:08 CEST] <texasmynsted> I will just let it work in the backgroun
[21:53:13 CEST] <JEEB> alternatively, extract the H.264 stream and use show_packets
[21:53:15 CEST] <JEEB> which is much faster
[21:53:24 CEST] <JEEB> because that way it will have to parse the stream
[21:53:26 CEST] <JEEB> :)
[21:53:50 CEST] <JEEB> as opposed to "this is in a sane container, and I can trust it to have set the flags right")
[21:54:00 CEST] <texasmynsted> ok what if it does not have frames or whatever
[21:54:06 CEST] <texasmynsted> Can I somehow add them?
[21:54:48 CEST] <JEEB> not without re-encoding
[21:55:17 CEST] <texasmynsted> Okay, how would I re-encode?
[21:55:52 CEST] <texasmynsted> like rather than copy, I am guessing I would somehow let it transcode back to the same codec?
[21:56:09 CEST] <JEEB> just check the stream first :P
[21:56:17 CEST] <JEEB> since it makes no sense to re-encode if you can just properly remux
[22:01:21 CEST] <texasmynsted> okay
[22:06:39 CEST] <texasmynsted> many key_frame
[22:07:10 CEST] <JEEB> alright
[22:07:15 CEST] <JEEB> so it's just a bugged mux \o/
[22:08:23 CEST] <texasmynsted> https://gist.github.com/mmynsted/f976a399080d635fb011ca354d74454d
[22:09:05 CEST] <texasmynsted> they are all 1 or 0
[22:09:09 CEST] <texasmynsted> whatever that means
[22:10:12 CEST] <JEEB> so yea, you should try to extract the video track, extract the timestamps (they're called "timecodes" with mkvextract or so) for the video track, and then use the separate video track and the timecodes together with the audio from the other matroska file with mkvmerge(gui) or so
[22:10:16 CEST] <texasmynsted> so is this correct to re-mux? ffmpeg -i 2019-04-05_13-04-27.mkv -codec copy 2019-04-05_13-04-27.mp4
[22:10:24 CEST] <JEEB> yes, but if your input file's flags are bonkers
[22:10:34 CEST] <JEEB> then it will copy the flags incorrectly
[22:10:54 CEST] <JEEB> that's why I noted how to do it the "long way"
[22:12:58 CEST] <texasmynsted> So then: 1. extract video h264, 2. extract audio aac, 3. extract timecodes, 4. use something called mkvmerge to combine/remux them?
[22:14:09 CEST] <JEEB> no need to extract audio
[22:15:31 CEST] <JEEB> 1. so extract the video (can be done in ffmpeg) 2. extract the video timecodes (really: timestamps! matroska has brought up a generation of people who go to work in media and get confused about these two). 4) in mkvmerge(gui) stick in a) the audio track from the original mkv (disable video),  b) the video from the raw .264 file (with timecodes)
[22:15:53 CEST] <JEEB> so you can read the audio as-is, but the video you want to once pull out
[22:16:59 CEST] <coolhp48> Question : When I call av_parser_parse2 with my codec set to AV_CODEC_ID_AAC_LATM , which function in actually being called to parse the LATM packet ? Is it latm_parse() from
[22:17:00 CEST] <coolhp48> libavcodec
[22:17:00 CEST] <coolhp48> latm_parser.c ?
[22:18:00 CEST] <texasmynsted> okay thank you. I will try this.  I also need to figure out why OBS would do this, to prevent this for future videos.
[22:18:22 CEST] <texasmynsted> I do now want to have to do this over and over, each day. Hehe
[22:21:50 CEST] <JEEB> coolhp48: if you have an AVPacket you have already "parsed" it
[22:22:17 CEST] <JEEB> not sure how you got parsing in there, but not like I've used that API
[22:22:40 CEST] <JEEB> if you were getting "standard" LATM AAC packets I would have thought you would have just attempted to feed them to the decoder
[22:22:45 CEST] <JEEB> and see how it explodes or not
[22:28:33 CEST] <Retal> Guys, what command shows all available ffmpeg filters? Like  ffmpeg -h......
[22:29:15 CEST] <durandal_1707> ffmpeg -filters
[22:29:47 CEST] <Retal> durandal_1707: thx!
[22:34:23 CEST] <JEEB> (45
[00:00:00 CEST] --- Sat Apr  6 2019