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

[burek]

[03:40:44 CET] <ossifrage> Should I be able to call avformat_write_header() .. av_write_trailer() multiple times without tearing down the AVFormatContext?
[03:41:32 CET] <ossifrage> I thought I had things working with non-seekable files, but when I started trying to write out multiple segments I got: muxer does not support non seekable output
[03:52:42 CET] <ossifrage> yeah, av_write_trailer() clobbers all my streams :(
[04:35:15 CET] <c0nundrum> hello
[04:35:48 CET] <c0nundrum> Anyone know what causes ffmpeg to trigger a chmod on the output file /
[04:45:03 CET] <darthshort>  trying to build HandBrake-1.2.2 on Centos 7 and getting the error "opus not found using pkg-config" when running make
[04:45:36 CET] <darthshort> the opus package is installed as well as opus-devel
[05:55:19 CET] <ossifrage> Huh, setting "movflags" to "frag_every_frame+dash+delay_moov+skip_sidx+skip_trailer" causes a parse error
[05:55:32 CET] <ossifrage> Undefined constant or missing '(' in 'skip_sidx'
[05:55:40 CET] <ossifrage> Unable to parse option value "skip_sidx+skip_trailer"
[05:56:08 CET] <ossifrage> I pulled those settings from libavformat/dashenc.c
[07:16:08 CET] <ross`> Hey, Can someone tell me why -vn might not strip audio of an mp4 file but also not fail with an error?
[07:16:38 CET] <ross`> ffmpeg -vn -i video.mp4 -o foo.mp4
[07:17:25 CET] <pink_mist> why would -vn strip audio? -vn should strip video...
[07:17:31 CET] <ross`> er strip video*
[07:17:37 CET] <ross`> Ya, I meant video
[07:18:28 CET] <pink_mist> perhaps you need to put it after the -i video.mp4
[07:20:09 CET] <ross`> pink_mist: <3
[07:20:10 CET] <ross`> Thanks!
[09:36:45 CET] <StudentSA> Hi! I have a use case where I need to run two separate ffmpeg process (one for streaming and one for recording) from a UDP mp3 stream source. when running the second ffmpeg process I get error "bind failed: Address already in use". Is it not possible for multiple consumers to use the same UDP port?
[09:37:44 CET] <StudentSA> I found that this can be done in a single ffmpeg process, but I want to decouple the two actions. any help is appreciated
[10:55:26 CET] <LigH> Hi.
[10:55:31 CET] <JEEB> ohai
[10:56:47 CET] <LigH> I stumbled upon a recent patch for x264 removing a compatibility change for 4:4:4 CABAC. This may affect ffmpeg before June/July 2017. Can you tell me a version milestone of this time? I believe it was before v4?
[10:57:25 CET] <JEEB> yea, that's quite old. check the search on git.videolan.org's ffmpeg repo
[10:57:51 CET] <JEEB> probably 840b41b2a643fc8f0617c0370125a19c02c6b586
[10:58:39 CET] <JEEB> which was committed into the repo 2017-06-19
[10:59:02 CET] <JEEB> 3.4 does have that change as far as I can tell
[10:59:19 CET] <JEEB> (and it might have been back-ported to other things)
[11:00:32 CET] <LigH> Yes, in the "tags" list, the release of v3.4 was 16 months ago, that should just be past.
[11:00:49 CET] <LigH> Thank you, bye...
[11:01:09 CET] <JEEB> gitk f.ex. can nicely show what tags etc a thing precedes and follows
[11:08:00 CET] <santigaite> FFmpeg suports UHD HDR ? keeps 10bit color space ?
[11:10:00 CET] <JEEB> HEVC/AVC/VP9 decoders support 10bit just fine and if the colorspace/transfer function can be read and is in the AVFrames, the question is mostly what you want to do with it
[11:36:30 CET] <justinasvd> JEEB: Remember the question what to do if avio blocks on another thread? Said to implement asynchronous AVIO.
[11:37:07 CET] <justinasvd> I tried to do that (and several other things). In the end, pthread_cancel was the most robust and elegant solution.
[11:38:35 CET] <justinasvd> If the thread blocks on IO, the easiest way to kill it is via thread cancellation.
[11:56:43 CET] <sazawal> BtbN, Hi. Now I have used "ffmpeg -i input.mkv -acodec copy -f segment -vcodec copy -map 0 clip%d.mkv" to split the video at every keyframe, without reset_timestamps option. But when I obtain frames from the clip using "ffmpeg -vsync 0 -i clip1.mkv -vf "showinfo" frame%04d.png -hide_banner >& output.txt", I am not getting the original timestamps of the frame in output.txt. The pts_time timestamps are relative to each clip. How do
[11:56:43 CET] <sazawal>  I get the original timestamps of the frame?
[12:00:36 CET] <JEEB> justinasvd: I would guess so
[12:00:43 CET] <JEEB> (haven't given it too much thought)
[12:01:11 CET] <JEEB> I know that the UDP protocol internally implements stuff in a separate thread and feeds it forwards as requested by the non-async API
[12:12:47 CET] <ringo_> hello
[14:45:39 CET] <santigaite> JEEB, recode/compress
[15:10:22 CET] <iTommix> Hello. I have read many about usage of ffmpeg and tried many things without success. maybe someone can point me to a solution: What i want is to transcode and stream a RTP (its a TV program stream, like rtp://@239.35.10.1:10000) that i can pause and rewind that stream. is it possible?
[15:52:26 CET] <ncouloute> Is there a way with ffprobe and ffmpeg to get the timestamp of a particular frame. I know with ffprobe you can get every frames timestamp, but that takes longer than I would like. I want to just seek to a frame then get its time stamp. If not maybe suggest another 3rd party cmdline util?
[15:53:27 CET] <kepstin> ncouloute: you can't seek to a frame by number, file formats don't index that information
[15:53:38 CET] <kepstin> (and you can't seek to a time and find the frame number either)
[15:54:32 CET] <JEEB> for mp4 l-smash's boxdumper can give you the timestamps of samples, and for matroska I think mkvinfo can do it. those might or might not be faster than ffprobe -of json -show_packets FILE
[15:54:32 CET] <kepstin> ncouloute: the only way to match up frame time & frame number is to read every frame from the start of the file. iirc, there is a library that does this and builds an index which you can use
[15:54:46 CET] <JEEB> and yes, if you are OK with indexing once, then ffms2
[15:54:56 CET] <perseiver> ncouloute: while using ffmpeg to convert the video to another format. (like from wav to mp4 ).. You will see Frame number on left..  and timestamp in 2nd Column from right..  This might help you to look into frame number and its timestamp
[15:54:57 CET] <JEEB> that is less format specific
[15:55:05 CET] <ncouloute> I should specify that I'm dealing with h264 mp4s
[15:55:28 CET] <JEEB> MP4s as long as they have a full index should be quick to check. possibly even ffprobe -show_packets should be quick?
[15:56:06 CET] <kepstin> well, -show_packets runs through the full demuxer, it'll be disk speed limited
[15:56:57 CET] <perseiver> for example:  when I run command.  ffmpeg -i videofilename  outputfilename.. then I got
[15:57:00 CET] <perseiver> frame=  838 fps=170 q=-1.0 Lsize=     986kB time=00:00:33.38 bitrate= 241.9kbits
[15:57:08 CET] <perseiver> Here you got frame number and timestamp
[15:57:18 CET] <perseiver> so you can guess timestamp and frame...
[15:57:40 CET] <kepstin> yes, you can record this information while you encode the file - but that doesn't help if you have existing already encoded files.
[15:58:47 CET] <perseiver> Yes, I know, but you can output the file to temp directory... As main intention is to know the frame with timestamp
[15:59:16 CET] <ncouloute> in my case I am trying to find a particular frame in the original file after I encode it. So that approach may work. Although is that the frame and timestamp for the encoded file?
[15:59:16 CET] <kepstin> if you just want the frame with timestamp, it would be a lot faster to use ffprobe -show_packets instead of doing a full re-encode :)
[16:00:07 CET] <ncouloute> Basically I have a list of frames numbers. IN and OUT points.. and I need to get the new frame number location
[16:01:13 CET] <kepstin> ncouloute: I think ffmpeg prints that message using frame numbers and timestamps of frames being sent to the encoder - but i'm not totally sure. It's possible the muxer might make additional changes to the timestamps (although unlikely in most cases). And that output is rate-limited and thus missing frames.
[16:02:31 CET] <ncouloute> This will be almost always going from lower fps to higher fps. So I shouldnt lose many frames for example 30->60.
[16:04:41 CET] <kepstin> if you want to log this information while encoding... maybe use a filter to do it? the "showinfo" filter should output all the info you want
[16:04:59 CET] <kepstin> i thought there was a filter that generated an mkvmerge-style timestamps file, but I can't find it now.
[16:05:53 CET] <kepstin> although note that the filter chain is possibly running at a different timebase from the encoder/muxer
[16:12:42 CET] <ncouloute> I guess I have to see what info that is giving me. I'm assuming its the info about the original file. I've seen resources online about being able to write the original timestamp and/or frame number on the resulting file. Not quite what I want I need it just in text form. My intial thoughts was to index both the try and find that same timestamp in the resulting file. But that is bond to be inaccurate. I guess I need to
[16:12:42 CET] <ncouloute> look into showinfo and go from there.
[16:15:23 CET] <ncouloute> so it looks like showinfo will give me lots of info about the input file. That would save me from having to index the original file but I would still have to index the resulting file. =/
[16:15:47 CET] <kepstin> showinfo logs stuff at the point where you insert the filter in the filter chain
[16:15:57 CET] <kepstin> so if you put it after the fps filter...
[16:16:39 CET] <kepstin> (although that won't really tell you much, the fps filter always generates "perfect" timestamps, counting up by exactly 1 each frame in the specified timebase)
[16:22:08 CET] <kepstin> fwiw, if your video has a framerate that's exactly representable in mp4 (most integer rates are? ntsc rates aren't iirc), then the pts values from the fps filter will be saved into the file without modification, so you can calculate the time of each frame exactly.
[16:22:22 CET] <JEEB> that's matroska
[16:22:50 CET] <JEEB> mp4 you can have 1001/24000 time base and then each sample has +1 PTS
[16:22:53 CET] <kepstin> ffmpeg's matroska muxer converts everything to 1/1000 timebase, so basically nothing is stored exactly
[16:23:10 CET] <kepstin> weird, when i tried to make a 1001/24000 file, ffmpeg actually made it 1/24000
[16:23:19 CET] <kepstin> (in mp4)
[16:24:40 CET] <JEEB> movenc.c has some weird stuff, although generally it should only ² your time base or so until it's "large enough"
[16:25:14 CET] <JEEB> I don't remember it ever making the output time base worse
[16:25:16 CET] <kepstin> and I though nut stored timebases exactly, but my 1001/24000 video got stored as 1/48000!?
[16:25:43 CET] <JEEB> I should probably try and make an API usage test for the MP4 case and see wtf one gets out of it
[16:25:57 CET] <JEEB> since movenc.c already has an API usage based test
[16:26:40 CET] <kepstin> yeah, I just did a simple test using fps filter to get some exact timestamps and timebase, and it gets messed up when muxed. hmm. this system has ffmpeg 4.0.3 tho, i should check other versions
[16:28:34 CET] <kepstin> but yeah, if mp4 is capable of storing ntsc timebase exactly, we really should be doing that :)
[16:29:23 CET] <ncouloute> So I'm thinking my best bet is to index each file get the timestamps then find the same timestamp in the resulting file. Those are very slow operations though. I was hoping ffmpeg or maybe the fps filter could output the frame mapping somehow. I think you are saying use show info twice once before fps filter and then after the fps filter?
[16:32:25 CET] <JEEB> kepstin: http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/movenc.c;h=77943304b5a52b70aebf547d8351a3bd26d7caa9;hb=HEAD#l6252
[16:32:39 CET] <JEEB> that's the only thing I know of where we're poking at the time base
[16:32:44 CET] <faLUCE> how can I list the supported samplerates for opus?
[16:32:52 CET] <kepstin> faLUCE: 48000
[16:32:53 CET] <kepstin> done
[16:33:15 CET] <another> ffmpeg -h encoder=libopus
[16:33:23 CET] <another> ffmpeg -h encoder=opus
[16:33:49 CET] <kepstin> (libopus technically has an internal resampler, and accepts other sample rates too, converting them itself)
[16:33:54 CET] <faLUCE> tnx
[16:35:33 CET] <another> (yes, but ffmpeg only knows about 48k and therefore resamples)
[16:36:00 CET] <another> oh. i was wrong
[16:37:11 CET] <another> seems like ffmpeg only resamples if the sample rate does not match opus' native rates
[16:40:27 CET] <kepstin> the ffmpeg libopus wrapper allows a few different sample rates, yeah. it does signal it to the libopus encoder, and in theory libopus might use that to make some decisions on which encoding modes to use?
[16:43:10 CET] <kepstin> presumably sending it 48Khz and setting the -cutoff option lower does the same thing.
[16:51:53 CET] <ncouloute> I see that there is a select filter. Doesn't that seek to a certain frame or does it actually decode until it gets to that point?
[16:52:05 CET] <kepstin> ncouloute: filters can't seek
[16:52:47 CET] <kepstin> (filters like trim and select work by discarding unwanted frames in the filterchain, so after they're decoded)
[16:54:34 CET] <ncouloute> gotcha so I think I'm pretty much going to have to index each file then. Unless -r or fps filter can output some debug information about where each frame ends up.
[16:56:44 CET] <TheAMM> If you want all the timestamps, ffmpeg -i file.mkv -vsync 0 -f mkvtimestamp_v2 timestamps.txt
[16:57:05 CET] <TheAMM> (or ffprobe -show_frames and parsing the output)
[16:57:28 CET] <TheAMM> but both of these do mean decoding the stream (as far as I know)
[16:57:33 CET] <ncouloute> I just want the timestamps of particular frames but it doesnt seem like I can do that without running through the entire file.
[16:57:48 CET] <ncouloute> maybe i can make the ffprobe line faster somehow
[16:58:04 CET] <kepstin> oh, the mkvmerge timestamp think is a muxer? right.
[16:58:21 CET] <kepstin> you could probably do two outputs when encoding the file - one to the mp4, one to the timestamp muxer
[16:58:39 CET] <kepstin> be tricky to set up since you'd need to use the tee muxer, but theoretically doable
[16:59:14 CET] <kepstin> ncouloute: the ffprobe command with -show_streams -show_packets should run as fast as it can read the file from disk, since it's not doing any decoding.
[16:59:19 CET] <TheAMM> ffprobe -i file.mkv -select_streams 0:v -show_frames -show_entries frame=pkt_pts_time -of csv=p=0
[16:59:55 CET] <ncouloute> that brings up a good point. I should be using pkts_pts_time instead of the best_effort_timestamp_time?
[16:59:56 CET] <TheAMM> That's the fastest way to get (just) timestamps for all frames
[17:00:02 CET] <ncouloute> gotcha
[17:00:13 CET] <TheAMM> At least from my testing from a few months ago
[17:00:43 CET] <TheAMM> I don't use it though, since for my thing I needed the image data as well
[17:01:02 CET] <TheAMM> So I wrote a NUT demuxer, getting the timestamp and actual frame data
[17:01:23 CET] <TheAMM> But it's a bit faster than mkvtimestamps_v2
[17:01:40 CET] <TheAMM> Like, couple of seconds faster on a 20-minute file
[17:01:53 CET] <TheAMM> on this speciic file, on this specific hardware, etc
[17:03:11 CET] <kepstin> but if you're encoding the file in the first place, writing the mkvtimestamps in the same command while encoding should be faster.
[17:04:19 CET] <kepstin> something like ... -f tee "[f=mkvtimestamp_v2]timestamps.txt|output.mp4"
[17:30:48 CET] <esx2ve> Hey guys. I'm in dire need of advice / guidance. Long story short, due to a stupid bug in our production pipeline, we 'concat'd' an HEVC file with an x264 file. Obviously when playing the joined .mov file, everything that comes from the x264 is read as corrupted (Invalid NAL unit size). Is there a way to extract the original video fragments?
[17:31:48 CET] <durandal_1707> you concated 2 movs into 1 mov?
[17:32:15 CET] <durandal_1707> also is there audio or only video?
[17:32:48 CET] <esx2ve> only video
[17:32:56 CET] <esx2ve> it's working perfectly when the codecs match
[17:33:34 CET] <kepstin> esx2ve: depending exactly what happened, you might need a custom tool that parses the packets and tries to figure out whether it's h264 or hevc :/
[17:34:02 CET] <kepstin> also you might be missing some initialization data required for the hevc data to be playable depending how it was muxed
[17:34:28 CET] <faLUCE> do you know in which cases libopus can output this warning? "[libopus @ 0x558cd0bf15c0] Queue input is backward in time"
[17:36:13 CET] <esx2ve> Thanks @kepstin!
[17:36:31 CET] <esx2ve> Maybe go about it like this - force ffmpeg to use a certain codec to decode? Is it possible?
[17:36:38 CET] <kepstin> faLUCE: iirc, that means timestamps on the input frames don't match the length of audio in the frames - like, you have a frame with 20ms of audio, but the timestamp of the next frame is only 15ms later.
[17:37:23 CET] <JEEB> or just going bsckwards in genersl
[17:38:46 CET] <faLUCE> uhmmmm
[17:40:00 CET] <kepstin> esx2ve: it sounds like you want to copy the data, not decode it? but yeah, you can try "-c:v hevc" as an input option (before the input file). no idea if it'll work, it might not be able to find the initialization data needed, and it'll definitely report errors on the h264 packets. you might be able to seek to near where the hevc starts and get better results.
[17:40:51 CET] <ossifrage> So my make fragmented mp4 files and then cat them back together in the server thing works on chrome/linux but not on chrome/ios :-(
[17:41:21 CET] <kepstin> tbh, i'm surprised it works in native chrome
[17:41:44 CET] <ossifrage> Yeah I just use the url: http://192.168.100.100/video.mp4 and it plays
[17:41:50 CET] <kepstin> but yeah, chrome on ios isn't chrome, it's just a webview (webkit) wrapper, so it can't really do anything safari can't do.
[17:41:58 CET] <esx2ve> kepstin, thank you very much! we tried to force the codec using -f and it got the frames we needed
[17:42:06 CET] <ossifrage> Yup, it also doesn't work in safari
[17:42:52 CET] <ossifrage> You get the play button with a line through it, and it seems the console is missing on ios now, you need to do the USB debug thing, which requires a mac
[17:44:20 CET] <ossifrage> Any ideas how to generate fmp4 that ios can decode, it is not the raw h.264, ios will decode that just fine
[17:44:22 CET] <kepstin> yeah, we picked up a new mac mini at my office for testing mac os x and ios stuff. If you need to support macs, you need to give apple money :/
[17:44:27 CET] <ossifrage> (if I use ffmpeg to make a mp4 file)
[17:44:54 CET] <kepstin> ossifrage: as far as i know, ios doesn't support fragmented mp4. remux it into normal mp4.
[17:45:18 CET] <kepstin> although what i know might be obsolete :)
[17:46:02 CET] <ossifrage> hls supports fragmented mp4, I thought that would mean ios could play a file with fragments :-(
[17:46:37 CET] <ossifrage> kepstin, I can't remux it into normal mp4 because I'm trying to do live playback
[17:46:41 CET] <kepstin> nah, hls stuff is distinct from the standalone file playback for who knows what reason
[17:48:13 CET] <kepstin> if you want live streaming to ios devices, you need to use hls.
[17:48:32 CET] <ossifrage> Hmm, now I need to come up with another way to do live streaming (without js if possible) to chrome/safari/firefox
[17:48:45 CET] <kepstin> (i'm unsure about whether dash works in ios yet)
[17:48:56 CET] <kepstin> dash works in other browsers, and iirc can use the same encoded media files
[17:51:07 CET] <faLUCE> kepstin: in case of opus I encode a pkt with a size = avframe->linesize[0]. Then it could be that the size is wrong, if I get all that warnings? The audio results a bit choppy
[17:52:04 CET] <ossifrage> I was trying to do something that would work for both live and archived playback. I write the fragments to tmpfs and then selectively archive the interesting bits for later playback
[17:52:16 CET] <faLUCE> (I use the same value for aac and mp2, and don't have problems...)
[17:53:09 CET] <ossifrage> I'm working on an opensource security camera firmware replacement project
[17:54:22 CET] <kepstin> ossifrage: if you have the fragments as separate files on tmpfs, then it shouldn't be hard to have a dash manifest and hls playlist referencing those fragments, then just statically serve up a dash js player for non-ios browsers.
[17:54:46 CET] <kepstin> faLUCE: are your pts values set right?
[17:55:02 CET] <faLUCE> kepstin: yes, just checked
[17:55:35 CET] <kepstin> (iirc, you usually want to use inverted sample rate for audio timebase, then the pts is just the sample number of the first sample in the frame)
[17:55:50 CET] <ossifrage> The whole point of using dash was I thought it was implemented natively in chrome, grrr...
[17:56:42 CET] <kepstin> hls is natively supported in safari (it basically just loads an os level player for it), and every other browser needs JS for fragmented live streaming.
[17:59:49 CET] <ossifrage> Kinda sad that I can't get the same result I get with raw h.264 over ssh, 500ms latency and it just works
[18:01:52 CET] <kepstin> if you want really low latency streaming to browsers, the only way is webrtc - and *that* is a pain to get working :)
[18:02:57 CET] <kepstin> it's not just rtp, there's required dtls encryption and ice that make it tricky to get right and interoperable.
[18:03:04 CET] <ossifrage> (I wanted low latency and no javascript, just native html5 video, didn't seem like too much to ask for)
[18:03:17 CET] <kepstin> nah, way too much to ask for
[18:03:46 CET] <kepstin> live native html5 video is only possible on a limited number of browsers that natively play hls
[18:03:52 CET] <kepstin> every other browser needs javascript.
[18:03:56 CET] <kepstin> and low latency is right out.
[18:04:43 CET] <kepstin> (well, some browsers don't break if you feed them live-generated streams in certain specific formats, but that's more of a quirk than anything imo)
[18:06:48 CET] <ossifrage> It was a simpler time when you could do moderately low latency multicast video on the local network with very little pain, now things have gotten more complex and much higher latency
[18:07:59 CET] <kepstin> i mean, you can still do that if you can convince people to install a player app on their local systems
[18:08:10 CET] <kepstin> it's only this reliance on doing everything in a web browser that makes it hard
[18:08:11 CET] <Mavrik> or use webrtc :)
[18:08:30 CET] <kepstin> webrtc can't multicast due to the encryption requirements
[18:09:02 CET] <Mavrik> I've seen most solutions walk away from multicast anyway
[18:09:05 CET] <ossifrage> Yeah, I really don't want to do anything with multicast video. But back when I was it generally worked fairly well
[18:09:28 CET] <kepstin> the main issue is that multicast over the internet basically isn't usable, yeah.
[18:09:41 CET] <Mavrik> mhm
[18:09:54 CET] <kepstin> but even unicast udp over modern internet is a pain due to stateful firewalls and nat :/
[18:09:57 CET] <Mavrik> Even live tv providers I've worked with moved away from multicast on their networks due to people using mobile devices :)
[18:10:07 CET] <ossifrage> The multicast video stuff I was doing in the past was purely to save compute costs in the device sending the video
[18:10:43 CET] <ossifrage> It just didn't have the compute/network budget to send multiple copies of the data, so you multicasted out one stream and multiple clients could watch it (on the local network)
[18:11:09 CET] <Mavrik> also multicast tends to greatly trash wifi networks :)
[18:11:16 CET] <ossifrage> So you could stick a camera on the end of a longish haul wifi link and still have multiple people watch it
[18:11:29 CET] <kepstin> falls back to broadcast at base rate iirc? yeah :)
[18:11:55 CET] <ossifrage> Yeah you do need all the igmp stuff working in the network
[18:12:10 CET] <faLUCE> kepstin: you were right, it was a mismatch between the time calculated on the framesize and the pts.
[18:12:47 CET] <ossifrage> If the multicast traffic leaks into the wrong places then it does fall apart quite nicely
[18:14:04 CET] <kepstin> faLUCE: yep. that message is printed based on a simple sanity check on the input timestamps and framelengths.
[18:14:35 CET] <ossifrage> For this project I have enough encoder channnels that I can produce a set of streams hi/medium/low/potato/mjpeg without much effort
[18:15:37 CET] <ossifrage> So I thought that DASH would be a good fit for what I can already encode
[18:15:41 CET] <kepstin> faLUCE: the message is printed by a generic queue that's used to re-frame the samples to the right packet size for the codec.
[18:17:08 CET] <kepstin> ossifrage: it is, particularly if you want to support stuff like dynamic quality switching based on bandwidth. but it does require js in the player, which isn't normally a problem.
[18:17:37 CET] <retal> Hi guys, where i can found working guide about how to buld ffmpeg with nvenc support for ubuntu 18
[18:17:39 CET] <kepstin> since the way dash is implemented in the browser is that the javascript builds a continuous stream which is fed to the browser player through the "media source extensions"
[18:17:55 CET] <ossifrage> kepstin, yeah I don't mind that. But I assumed there was a solution to do the simple single live stream playback without any js
[18:18:39 CET] <kepstin> ossifrage: it shouldn't be a big deal? you just need to grab a dash player js file and server it statically along with your player html page.
[18:20:23 CET] <ossifrage> I just was hoping to do the simple thing first so I could go back to working on what I actually care about and then come back to the video streaming stuff later
[18:24:59 CET] <kepstin> retal: your easiest bet is to probably just grab a static ffmpeg build of 4.1 - there's some linked off the ffmpeg site, including ubuntu packages -  most should have nvenc support. building it yourself isn't that hard, just need to make sure you have the ffmpeg "nv-codec-headers" installed before building.
[18:25:56 CET] <retal> kepstin, thank you !
[18:28:20 CET] <kepstin> retal: regarding nv-codec-headers - that's from this git repo: https://git.videolan.org/?p=ffmpeg/nv-codec-headers.git;a=summary - if those are installed correctly, ffmpeg's configure script will automatically enable nvenc support (you can check by adding --enable-nvenc to the ffmpeg configure command line, then it'll error out if it can't find them)
[18:29:56 CET] <retal> kepstin, why i need headers, if i download static build ?
[18:30:09 CET] <kepstin> retal: that's only if you build it yourself
[18:32:46 CET] <retal> kepstin, oh yea. I first will try with static build (wor saving time) for testing my nvidia, then will try build from sources , thank you
[18:37:11 CET] <retal> kepstin, i just downloaded ffmpeg version 4.1.1-static, and try: ./ffmpeg -codecs | grep nvenc, looks loke there no nvrenc support in static buld
[18:58:31 CET] <sazawal> Hi. I have used "ffmpeg -i input.mkv -acodec copy -f segment -vcodec copy -map 0 clip%d.mkv" to split the video at every keyframe. I obtained frames from the each of clips using "ffmpeg -vsync 0 -i clip1.mkv -vf "showinfo" frame%04d.png -hide_banner >& output.txt". How do I get the timestamps of the frames as it was in the original video?
[19:06:10 CET] <ossifrage> Ouch, my ffmpeg code has a memory leak that was bad enough to panic the machine, ouch
[19:19:16 CET] <kepstin> sazawal: you can't, there's not enough information to do that. You'd have to record the frame timestamps of the original video before splitting.
[19:24:42 CET] <sazawal> kepstin, Yes I was expecting this. Can I record the information of the timestamps when I am splitting the original to clips? So for example, the second keyframe is at 00:00:10 and the particular frame is at 00:00:02 in the second clip, then the original timestamp of the video must be 00:00:12.
[19:25:22 CET] <sazawal> original timestamp of the frame must be 00:00:12*
[19:25:54 CET] <kepstin> sazawal: i'd just do the same thing you're doing with showinfo when you're doing the command that splits into segments, then you should be able to reference by counting frames.
[19:27:39 CET] <sazawal> kepstin, Actually I did redirect the output of the first command (when I split the original into clips) to a text file. I am not sure which variable in the output has this timestamp information.
[19:28:15 CET] <kepstin> sazawal: you didn't add any options to the first command that would cause it to record that information.
[19:28:42 CET] <sazawal> kepstin, I see. Please tell me which are these options.
[19:29:01 CET] <kepstin> <kepstin> sazawal: i'd just do the same thing you're doing with showinfo when you're doing the command that splits into segments, then you should be able to reference by counting frames.
[19:29:25 CET] <sazawal> kepstin, Ohh. Let me quickly check it.
[19:41:41 CET] <faLUCE> now, I don't understand exactly the size that I have to use for each packet to encode with opus. Normally, I set this size = avframe->linesize[0],  but for libopus there's the "frame_duration" option, which is set to 20 as default. Then, I should use a size that corresponds to this duration... but how to calculate it?
[19:48:02 CET] <sazawal> kepstin, It is not working with -vf "showinfo" option. It says, "Filtergraph 'showinfo' was defined for video output stream 0:0 but codec copy was selected.
[19:48:02 CET] <sazawal> Filtering and streamcopy cannot be used together."
[19:48:16 CET] <kepstin> ah, right.
[19:53:10 CET] <sazawal> kepstin, Is there another way to get these timestamps? Maybe I can get all the keyframe timestamps before splitting it into clips. The keyframe timestamps must be the timestamps where the splitting is taking place.
[20:19:39 CET] <dominiques> hello
[20:19:50 CET] <dominiques>  Hello please, can you HELP me... i really need solve using ffmpeg cutting exactly 00:04:00 second audio fragments ... i need cut ideally aac or wav, for example, i have 60 second audio file, and i need to cut them to exactly 15*4sec audio fragments i am using for example ffmpeg -i $DIR_TMP/"${file%.mp4}.wav" -segment_time 4 -f segment $DIR_TMP/"${file%.mp4}%03d.wav"
[20:22:08 CET] <dominiques> please PM to me
[20:28:36 CET] <retal> I am trying use nvenc coder ffmpeg -i video.mp4 -vcodec h264_nvenc -b:v 5M -acodec copy out.mp4
[20:28:36 CET] <retal> But it can utilize videocard only for ~20%, how i can increase utilization?
[20:29:10 CET] <kepstin> retal: how are you measuring utilization?
[20:29:36 CET] <kepstin> there's some cases where you might be bottlenecked by the decoder or memory transfers - using hardware decoder might help
[20:30:05 CET] <retal> nvidia-smi
[20:30:57 CET] <retal> how to use hardvare decoder in my case ?
[20:31:03 CET] <kepstin> note that the hardware encoder is a specific functional unit - it can be used 100% independently of gpu compute resources.
[20:31:44 CET] <kepstin> retal: see the nvdec section of https://trac.ffmpeg.org/wiki/HWAccelIntro
[20:32:07 CET] <arthuralbano2> hello world
[20:33:30 CET] <arthuralbano2> Hi people! I wanted to generate a single image from a mp4 video, so I can filter everything that is moving and leave one single image of the background. Perhaps using median smooth over all video, but I have no idea on how to accomplish this...
[20:33:43 CET] <retal> kepstin, i think in my case it shuld work , i am using GPU wit Pascal
[20:33:46 CET] <arthuralbano2> Sorry about newbie question... :)
[20:36:30 CET] <kepstin> arthuralbano2: that's not really something that ffmpeg can do by itself. You might want to look at OpenCV, which has a bunch of related image processing algorithms
[20:36:57 CET] <kepstin> (although removing a static background is more common problem than keeping the background and removing foreground, but the problems are kinda related)
[20:41:24 CET] <retal> also with hwaccel option: ffmpeg -hwaccel nvdec -i 1.mp4 -vcodec h264_nvenc -b:v 5M -acodec copy out.mp4    utilization ~37$
[20:41:48 CET] <dominiques> any idea how to split audio to everytime get exactly 00:04:00 ~+-01  audio fragments ?
[20:41:50 CET] <kepstin> arthuralbano2: https://docs.opencv.org/master/d1/dc5/tutorial_background_subtraction.html is the related tutorial - note that the "BackgroundSubtractor" builds a background model, after processing you can ask it to generate a background image.
[20:41:51 CET] <retal> Intel i7 8th gen, DRR4
[20:46:02 CET] <kepstin> retal: now you've gone and disabled the hardare encoder... look at the "Full hardware transcode" example.
[20:56:15 CET] <retal> kepstin, also tryed with "Full hardware transciding" ffmpeg -hwaccel cuvid -c:v h264_cuvid -i SuperMama.mp4 -c:v h264_nvenc  1.mp4     same result ~8% Utilisation. I understand it gave me x48 speed but i think there is so much power still inused
[20:57:21 CET] <furq> retal: like he said, nvenc is a separate asic, its utilisation won't show up as gpu utilisation
[20:57:38 CET] <kepstin> retal: you have to look specifically at usage of the hardware encoder, not gpu as a whole
[20:58:01 CET] <kepstin> retal: and for the higher end gpus, they're really designed for multiple concurrent streams to get full usage of the hardware encoder
[20:58:26 CET] <kepstin> (although geforce branded cards have arbitrary limits on concurrent streams - you need quadro hardware for lots of streams)
[21:00:15 CET] <another> dominiques: what's with your current command (.. -f segment -segment_time 4 ...)
[21:01:29 CET] <retal> ooh guys thank you i understood, i was looks whole GPU utilization
[21:02:08 CET] <furq> is nvenc utilisation even observable
[21:03:27 CET] <furq> i assume it's not but the last nvidia card i had was a gtx 260
[21:03:50 CET] <retal> im my case gtx 1060
[21:04:54 CET] <retal> 100 min vide i transcoded with i7 8gen in 16 min, with GPU 2 min
[21:13:29 CET] <dominiques> another https://codeshare.io/aVnze3
[21:13:57 CET] <dominiques> can someone help me get EXACTLY 4 second audio splitting ? please check code https://codeshare.io/aVnze3
[21:17:02 CET] <dominiques> I CAN PAY FOR YOUR HELP ! REALLY NEED SOLVE THIS .. PLEASE CHECK https://codeshare.io/aVnze3
[21:24:00 CET] <ksk> stop screaming.
[21:24:24 CET] <ksk> IIRC there is an example of how to take samples (just some seconds) of a file in the ffmpeg-wiki/x264 article
[21:25:46 CET] <dominiques> ok
[21:26:31 CET] <ksk> -t and -to - see the manpage
[21:26:43 CET] <kepstin> note that a lot of the ffmpeg audio stuff works on frame boundaries, not sample accurate. Especially things that deal with encoded audio (like the segment muxer), which can't split anywhere except a sample boundary.
[21:26:50 CET] <kepstin> except a frame boundary*
[21:27:36 CET] <ksk> also, you can just go from input to wav directly, you dont need to make that output aac first, and then wav..
[21:28:55 CET] <kepstin> dominiques: for this type of stuff, sometimes dedicated audio processing tools (like sox) might be easier to use than ffmpeg.
[21:31:14 CET] <dominiques> problem its, i have video mp4, i will extract audio and now i need split audio to exactly 4 second, i am still looking for best solution
[21:33:40 CET] <dominiques> for example i have extracted from mp4 ... wav ... and this have exactly 3.98 az 4.01 second . this is OK ... can you tell me how can i get them back to AAC without loose lenght ...
[21:34:00 CET] <dominiques> wav to aac to have  3.98 az 4.01 still
[21:35:10 CET] <sazawal> dominiques, You could use Audacity to process/split the extracted audio.
[21:36:09 CET] <kepstin> aac is tricky, because it has a frame length of ~20ms it can cause rounding errors if an application somwhere isn't indicating the correct samples to use in playuback
[21:37:17 CET] <faLUCE> when I encode with libopus, the output says:  "Stream #0:0: Audio: opus (libopus), 48000 Hz, stereo, s16, delay 312, 96 kb/s"     <--- what is "delay"?
[21:37:50 CET] <faLUCE> I mean: how can I set it through av_opt_set ?
[21:41:26 CET] <kepstin> faLUCE: delay is the number of samples of preroll the codec uses as part of its algorithm. setting the frame duration to a lower value, and setting application to lowdelay should reduce that.
[21:41:54 CET] <kepstin> note that 312 samples is 6.5ms @ 48kHz
[21:43:10 CET] <faLUCE> kepstin: I did not set anything with the "ffmpeg" command, but I wonder how to obtain the same delay value with libavcodec... or do I have to leave all as default?
[21:43:45 CET] <kepstin> faLUCE: i have no idea what you mean
[21:43:56 CET] <kepstin> if you don't set options, the defaults are used...
[21:45:33 CET] <faLUCE> kepstin: sorry, I explain better. I executed this command:  "ffmpeg -f alsa -ac 2 -i default -c:a libopus -f mpegts -v verbose prova.ts"     and obtained 312 as "delay".  Now, I want to replicate the same settings manually with some code using libavcodec. Which "non default" option should I use for that?
[21:45:55 CET] <kepstin> faLUCE: nothing, the defaults should do that
[21:46:13 CET] <kepstin> make sure you selected the libopus codec specifically, rather than ffmpeg's builtin opus encoder
[21:46:21 CET] <faLUCE> I see. I don't understand why I still have a bit choppy audio.
[21:46:26 CET] <faLUCE> I used libopus codec
[21:46:41 CET] <kepstin> choppy audio has nothing to do with that
[21:47:15 CET] <faLUCE> it should depend on the size of each encoded packet
[21:47:28 CET] <faLUCE> which is not the right size, pheraps
[21:47:44 CET] <kepstin> choppy audio could happen if each input frame to the codec has fewer samples than required for the time between frames
[21:48:05 CET] <retal> last question for today :) How to compile with nvresize ?
[21:48:05 CET] <kepstin> because then the extra time will have to be filled with silence, i guess
[21:49:16 CET] <kepstin> retal: that one's harder, I don't actually know. I think it actually requires some nvidia sdk to be installed on your machine to build it.
[21:49:23 CET] <faLUCE> yes, in fact I don't understand how to calculate the exact input frame size... I copied avframe->linesize[0] bytes into the avpacket....
[21:49:58 CET] <kepstin> a frame should contain a number of samples equal to (next pts - current pts in seconds) * sample rate
[21:50:24 CET] <retal> kepstin, thanks
[21:50:37 CET] <kepstin> so if you have a frame at 0 seconds, the next frame at 1 second, and 48000khz sample rate, then the first frame should have exactly 48000 samples.
[21:51:30 CET] <kepstin> the amount of bytes depends on the sample format and channels - as an example, for s16 stereo, that'll be 2 * 2 *48000 bytes.
[21:51:55 CET] <faLUCE> kepstin: ok, but ffmpeg should already give me this value with the linesize[0] field
[21:52:12 CET] <faLUCE> I used that field for MP2 and AAC and all worked fine
[21:52:20 CET] <kepstin> faLUCE: how did ffmpeg give you something? where did this audio frame come from?
[21:52:36 CET] <kepstin> is this a frame you got from a libavcodec decoder?
[21:52:55 CET] <kepstin> if so, the only thing you should need to do is rescale the pts if needed.
[21:53:06 CET] <faLUCE> kepstin: it is the frame obtained with av_frame_alloc();
[21:53:13 CET] <faLUCE> when allocating all the codec stuss
[21:53:17 CET] <faLUCE> stuff
[21:53:51 CET] <kepstin> faLUCE: sure, but where did the buffer come from? av_frame_alloc doesn't give you a buffer
[21:54:13 CET] <faLUCE> kepstin: av_frame_get_buffer(mRawInputLibAVFrame, 0)
[21:54:32 CET] <another> faLUCE: maybe relevant: 312 is the value opustools call pre-skip
[21:55:15 CET] <kepstin> faLUCE: before you called av_frame_get_buffer, you need to set nb_samples and channel_layout on the avframe
[21:55:24 CET] <kepstin> faLUCE: the nb_samples is ... the number of samples
[21:55:29 CET] <faLUCE> kepstin: mRawInputLibAVFrame->nb_samples     = mAudioEncoderCodecContext->frame_size;
[21:56:04 CET] <kepstin> and the number of the samples is equivalent to the duration of the frame
[21:56:33 CET] <faLUCE> I followed all the procedure for AAC and MP2 and I can encode well with these two codecs
[21:56:35 CET] <kepstin> the number of samples in the frame and the pts values you set on each frame should be calculated from the same values
[21:57:26 CET] <faLUCE> kepstin: I did not set the pts values... I left the encode() function set them
[21:57:41 CET] <faLUCE> I mean: they are set by the encode() function
[21:57:41 CET] <kepstin> faLUCE: that's not how it works...
[21:57:52 CET] <kepstin> you set the pts values on the avframe before you send it to the encode function
[21:58:12 CET] <faLUCE> kepstin: normally I set them in the way you say
[21:58:39 CET] <faLUCE> but given that without setting them I see that they are set by the function, I avoided to set them
[21:58:54 CET] <kepstin> faLUCE: you need to set the pts on an avframe before sending it to the encoder
[21:59:12 CET] <kepstin> it might work by coincidence in some encoders, but you can't rely on that
[21:59:19 CET] <faLUCE> kepstin: I see. this explains the previous problem. But why the hell are they set by the encoding function??
[21:59:25 CET] <faLUCE> this confused me
[21:59:50 CET] <kepstin> the encoder shouldn't be touching the pts on the input frame. It will set the pts on the output packet.
[22:00:10 CET] <kepstin> if you don't provide a pts on the input frame, the output packet's pts will be nonsense
[22:00:23 CET] <faLUCE> kepstin: but I see that they are monotonic
[22:00:28 CET] <kepstin> although some audio codecs might set it based on input sample count, so it could just work by chance
[22:00:32 CET] <kepstin> but you can't rely on that
[22:00:37 CET] <faLUCE> I see, I see
[22:00:37 CET] <kepstin> set your pts values.
[22:00:42 CET] <faLUCE> ok, thanks
[22:00:59 CET] <faLUCE> I saw monotonic values and I thought they were right...
[22:01:20 CET] <kepstin> libopus in particular uses a queue to adjust the input frame sizes if needed, and that queue relies on pts values to work correctly.
[22:02:13 CET] <faLUCE> I see
[22:03:01 CET] <faLUCE> well, If I set manually them with  av_rescale_q(av_gettime_relative(), AV_TIME_BASE_Q,mAudioEncoderCodecContext->time_base)   I still have some issues
[22:03:17 CET] <faLUCE> maybe the rescaling is not correct
[22:04:17 CET] <kepstin> faLUCE: set it based on the count of samples in the packet, not current time
[22:04:41 CET] <faLUCE> kepstin: even with VBR ?
[22:04:41 CET] <kepstin> av_rescale_q(number_of_samples_processed_so_far, sample_rate, output_time_base)
[22:04:50 CET] <kepstin> vbr has nothing to do with sample rate
[22:05:11 CET] <faLUCE> kepstin: I see, but why the previous way is not good? It should have a high resolution
[22:05:22 CET] <kepstin> faLUCE: because it *doesn't match what's in the packet*
[22:05:36 CET] <kepstin> it's a different clock, at a different speed, sampled at a different time
[22:05:42 CET] <kepstin> has no relation to your audio whatsoever
[22:05:57 CET] <faLUCE> kepstin: I see
[22:06:11 CET] <faLUCE> ok let's try all
[22:06:15 CET] <kepstin> an audio frame containing N samples at 48000khz is *exactly* N/48000 seconds long.
[22:08:15 CET] <kepstin> so i'd recommend keeping a running count of number of samples encoded, start at 0, update it after encoding each frame with the number of samples in the frame.
[22:08:33 CET] <kepstin> use that to calculate the pts by using the sample rate as a time base
[22:09:05 CET] <kepstin> (equivalently, if every frame is the same size, you could work out a formula to calculate from number of frames encoded)
[22:09:33 CET] <faLUCE> kepstin: yes, I used AudioEncoderCodecContext->time_base = (AVRational){ 1, audioSampleRate::value };
[22:10:35 CET] <faLUCE> but I did not calculate the pts before sending to the encoder in the way you said. I used the get_time() way for MP2, and given that it's not buffered, it worked
[22:12:09 CET] <kepstin> audio is tricky, because the sound card has its own independent clock that it uses to count out the samples/sample rate
[22:12:46 CET] <kepstin> if you request a specific sample rate, then you can determine the time from the sound card clock by the number of samples you get from it
[22:13:47 CET] <kepstin> (this makes timing separately captured audio and video tricky, because they were probably timed using different clocks - and therefore might have drift)
[22:14:50 CET] <faLUCE> yes, I remember that
[22:17:36 CET] <kepstin> note that in the case where you're capturing audio in realtime and want to sync it with your system clock, you should use the aresample filter (see the resampler options) to fix it before encoding it
[22:18:35 CET] <kepstin> so if you set the frame pts value from the system clock, you can then run the frames through aresample filter with appropriate options, and it'll add/remove frames and adjust speed to make the audio samples match the pts values.
[22:18:40 CET] <kepstin> then the encoder will be happy with it
[22:18:52 CET] <kepstin> add/remove samples*
[22:19:27 CET] <faLUCE> kepstin: I don't need to sync with my system clock, I just need to sync it with the samples count when making pts
[22:19:47 CET] <kepstin> yeah, if you're just capturing audio, that's the way to do it.
[22:23:24 CET] <faLUCE> kepstin: but, given that the encoder timebase is  (AVRational){ 1, audioSampleRate::value }, what do you mean with output timebase? the timebase of the muxer/container ?
[22:24:45 CET] <kepstin> faLUCE: i'm missing some context, but the container might require scaling to a different timebase (e.g. ffmpeg's matroska/webm muxer uses a fixed timebase of 1/1000)
[22:25:13 CET] <faLUCE> kepstin: for mpegts I use  (AVRational){ 1, audioSampleRate::value } as timebase
[22:25:46 CET] <kepstin> mpegts has a fixed timebase of 1/90000
[22:25:55 CET] <kepstin> so that'll need rescaling before muxing
[22:26:15 CET] <faLUCE> kepstin: yes, you are right, it was the timebase of the muxer's encoder
[22:26:31 CET] <faLUCE> I mean, the timebase of the muxer's codeccontext
[22:58:36 CET] <faLUCE> kepstino, so, with:   sample_rate = 48000,  float, stereo, with opus frame_duration = 60ms, I have  nb_samples = 2880 .    should I feed the opus encoder with pts = 2880*i  , where i is the frame number?
[22:58:39 CET] <faLUCE> kepstin:
[22:59:10 CET] <kepstin> faLUCE: assuming timebase is 1/sample_rate, that would be correct.
[22:59:39 CET] <faLUCE> kepstin: yes, I have that timebase .... but audio is still a bit choppy :-(
[23:01:12 CET] <JEEB> usually you check how big audio frames an encoder wants with http://ffmpeg.org/doxygen/trunk/structAVCodecContext.html#aec57f0d859a6df8b479cd93ca3a44a33
[23:01:21 CET] <JEEB> the problem seems to be that I can't see libopus wrapper setting that
[23:02:48 CET] <faLUCE> JEEB: in libopusenc.c there's  avctx->frame_size      = frame_size * avctx->sample_rate / 48000;
[23:03:03 CET] <JEEB> oh, how did I not see that one
[23:03:14 CET] <JEEB> yup, it does set it
[23:04:21 CET] <JEEB> so yea, you should be able to figure out how big audio frames the encoder wants with that.
[23:04:47 CET] <JEEB> personally I used libavfilter to do my resampling previously, and there was a nice function which you could tell how many samples you wanted exactly
[23:04:58 CET] <JEEB> mostly because your input format could have 1024, or 960 or 1500
[23:05:02 CET] <faLUCE> JEEB: I already took that value with avframe->linesize[0]
[23:05:22 CET] <JEEB> not nb_samples?
[23:05:32 CET] <JEEB> linesize != actual amount of samples
[23:05:39 CET] <kepstin> faLUCE: avframe->linesize is meaningless, that's just the size of the buffer you allocated. you already know that, since you allocated the buffer
[23:06:03 CET] <faLUCE> uhmmm wait
[23:06:20 CET] <JEEB> linesize is the amount of bytes to go to get to the following set of samples
[23:06:31 CET] <JEEB> https://ffmpeg.org/doxygen/trunk/structAVFrame.html#aa52bfc6605f6a3059a0c3226cc0f6567
[23:06:41 CET] <JEEB> nb_samples is how many audio samples it has
[23:06:46 CET] <kepstin> in particular, when you set nb_samples and the sample format on the avframe, then the buffer allocation calculates how big the buffer should be from those.
[23:07:37 CET] <JEEB> right, av_buffersink_get_samples
[23:07:40 CET] <JEEB> is what I used with libavfilter
[23:07:49 CET] <JEEB> "gimme XYZ samples from the audio chain"
[23:08:01 CET] <JEEB> and then I just fed decoded audio to that and got out what I needed
[23:09:57 CET] <faLUCE> well, what Imeant is that I set the avpacket size to linesize[0]
[23:10:18 CET] <kepstin> avpacket size has nothing to do with frame size, why would you do that?
[23:10:20 CET] <faLUCE> which tells me how many bytes (considering the layout, the format etc.)
[23:10:51 CET] <faLUCE> what I do is to allocate an avpacket, and then fill it with data for linesize[0] bytes
[23:10:53 CET] <kepstin> note that with planar audio formats, linesize[0] will be the length of only one of the planes (channels)
[23:11:03 CET] <faLUCE> I use packed format
[23:11:07 CET] <kepstin> do you mean avframe? packets are for encoded audio
[23:11:51 CET] <faLUCE> I allocate an avpacket, then copy raw data into it. I copy exactly linesize[0] bytes
[23:12:04 CET] <faLUCE> all works perfectly with MP2 and AAC
[23:12:09 CET] <kepstin> the input to an encoder is avframes, not avpackets...
[23:14:04 CET] <faLUCE> well, you are right, I was confused by "receive_packet"
[23:14:39 CET] <faLUCE> (encoding is in two steps... the second one outputs packets)
[23:14:42 CET] <JEEB> yes
[23:14:48 CET] <JEEB> feed it frames, receive bacon^Wpackets
[23:14:49 CET] <faLUCE> so, I have to set the FRAME's ts
[23:15:02 CET] <kepstin> YES THAT"S EXACTLY WHAT I"VE BEEN SAYING ALL DAY
[23:15:11 CET] Action: kepstin goes home
[23:15:12 CET] Action: JEEB pats kepstin 
[23:15:42 CET] <faLUCE> thanks kepstin  and JEEB... but you know? some times ago there was the first step function with packet too
[23:15:54 CET] <JEEB> yes, the other way
[23:15:55 CET] <JEEB> decoding
[23:16:04 CET] <faLUCE> it's pretty confusing
[23:16:05 CET] <JEEB> feed packet, receive bacon^Wframe
[23:16:09 CET] <faLUCE> ok
[23:16:28 CET] <JEEB> faLUCE: just think of AVFrames always when you deal with raw data, and AVPackets with encoded data
[23:18:13 CET] <kepstin> i guess it was only about an hour and a half ago that i wrote "<kepstin> you set the pts values on the avframe before you send it to the encode function" :/
[23:18:26 CET] <faLUCE> JEEB: yes... now I remember all... I did not use libavcodec since one year
[23:18:52 CET] <faLUCE> kepstin: sorry.... but when reading "setting pts" I suddenly thought about an avpacket
[23:19:56 CET] <faLUCE> I know that I was wrong, but there's another function that misleaded me:
[23:19:59 CET] <faLUCE> av_write_frame()
[23:20:06 CET] <faLUCE> which wants an avpacket
[23:20:20 CET] <JEEB> yes, those old functions are a real misnomer
[23:20:22 CET] <faLUCE> (muxing)
[23:20:29 CET] <JEEB> av_read_frame and av_write_frame
[23:21:48 CET] <faLUCE> why a "deprecated" ticket is not open?
[23:22:20 CET] <JEEB> because deprecation generally means something new was written instead
[23:22:29 CET] <JEEB> although in theory there could be a rename deprecation :P
[23:22:45 CET] <faLUCE> but send_frame and receive_packet were the result of a deprecation
[23:22:52 CET] <faLUCE> and they clarify lot of things
[23:23:03 CET] <JEEB> they were the result of someone making a better API
[23:23:10 CET] <JEEB> and thus the old one was deprecated
[23:23:26 CET] <JEEB> deprecation usually is "here's a better thing, please use it before we remove the old one"
[23:23:34 CET] <faLUCE> so, also for write/read_frame the same thing should be applied
[23:23:56 CET] <faLUCE> depraction is good also for API improvement... when changing names
[23:24:03 CET] <faLUCE> (deprecation)
[23:24:07 CET] <JEEB> yes, I don't disagree
[23:24:13 CET] <JEEB> it could/should get renamed
[23:24:46 CET] <faLUCE> :-)
[23:37:30 CET] <faLUCE> so, let's resume. I feed the AVFrame* frame with linesize[0] bytes.  And I set frame.pts = frame.nb_samples*i , where i is the frame number. .... still choppy audio... :-(  . I tried also frame.pts = frame.nb_samples*i*2  (stereo) but the problem remains
[23:40:47 CET] <faLUCE> the strange thing is that the distortion is minimal
[23:42:18 CET] <faLUCE> I don't even get any warning from libavcodec.  If I set, for example frame.pts = i, where i is incremental, I have warnings
[23:42:51 CET] <faLUCE> I think it's a matter of insufficient buffering
[23:44:54 CET] <JEEB> why are you putting linesize[0] amount of samples, and not nb_samples amount of samples?
[23:45:27 CET] <JEEB> also I'm not sure if your sample is of size of a single byte, but that's a detail :P
[23:46:02 CET] <JEEB> like, there's a warning about linesize being larger than nb_samples*sizeof(sample)
[23:46:09 CET] <JEEB> for optimization etc reasons
[23:46:19 CET] <JEEB> it can be the same, but never ever expect it to be
[23:46:30 CET] <JEEB> it really sounds like you have fed into the AVFrame more data than nb_samples
[23:46:35 CET] <faLUCE> I don't put linesize[0] samples... I put linesize[0] bytes
[23:46:41 CET] <JEEB> yes, still
[23:46:50 CET] <JEEB> https://ffmpeg.org/doxygen/trunk/structAVFrame.html#aa52bfc6605f6a3059a0c3226cc0f6567
[23:46:58 CET] <JEEB> > The linesize may be larger than the size of usable data  there may be extra padding present for performance reasons.
[23:47:19 CET] <JEEB> never, ever use linesize for anything else than getting from one set of data to the next or previous
[23:47:31 CET] <faLUCE> I see, there's an extra padding
[23:47:38 CET] <JEEB> always use nb_samples*sizeof(sample)
[23:47:51 CET] <JEEB> you know the size of a sample from the AVFrame's sample format
[23:47:58 CET] <faLUCE> JEEB: nb_samples*sizeof(sample)*channels
[23:47:59 CET] <faLUCE> ?
[23:48:37 CET] <JEEB> channels can be separate or together, so depending on planar/not planar
[23:48:44 CET] <faLUCE> I use packed
[23:50:38 CET] <JEEB> I don't remember the exact details of audio frames, but if it's a single "line" for all channels then yes
[23:50:48 CET] <JEEB> (I let avfilter do this boring stuff for me)
[23:50:58 CET] <JEEB> which then used swresample underneath
[23:51:17 CET] <JEEB> (which at the very least can do the AVFrame size changes for me vOv)
[23:54:20 CET] <JEEB> but yea, the primary thing I try to note is that linesize != nb_samples*size of sample
[23:54:26 CET] <faLUCE> JEEB:  nb_samples*sizeof(float)*2   gives me exactly the  value of linesize[0] .... and the same problem :-(
[23:54:52 CET] <JEEB> pretty sure there's a function for the size
[23:56:01 CET] <JEEB> surprising that it doesn't have any padding :/
[23:57:15 CET] <faLUCE> JEEB: there's not such a function in the avframe API
[23:57:35 CET] <JEEB> no I mean something that gives you a size from AVSampleFormat
[23:57:42 CET] <JEEB> of course I could be incorrect :P
[23:57:46 CET] <JEEB> it just feels like something that should be there
[23:58:02 CET] <faLUCE> yes, there is but I'm sure I used float...
[23:59:14 CET] <JEEB> which should be native 32bit float
[23:59:39 CET] <JEEB> anyways, I'm just interested myself if I were to code this myself :P
[00:00:00 CET] --- Fri Mar 15 2019