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

[burek]

[00:00:27 CET] <JEEB> av_get_bytes_per_sample(sample_fmt)
[00:00:28 CET] <JEEB> HA
[00:00:30 CET] <JEEB> there it was
[00:00:32 CET] <faLUCE> JEEB: av_get_bytes_per_sample(avctx->sample_fmt))
[00:00:35 CET] <JEEB> yes
[00:00:41 CET] <JEEB> had to just remember how it was called :)
[00:10:52 CET] <faLUCE> there should be an option for setting the buffer size of the opus encoder
[01:18:44 CET] <Geek> does anyone know a ffmpeg based tool that uses mouse to select video area to cut a video?
[01:19:17 CET] <Geek> or is there a script to measure video screen then return ffmpeg code for that, I am considering to create such thing
[01:45:00 CET] <ossifrage> I copied the movflags from libavformat/dashenc.c and it gets a parse error "frag_every_frame+dash+delay_moov+skip_sidx+skip_trailer" == Undefined constant or missing '(' in 'skip_sidx'
[01:45:03 CET] <ossifrage> Any ideas?
[03:46:51 CET] <fling> Geek: there is an mpv plugin
[05:10:50 CET] <ossifrage> Doh, it turns out at some point I had moved my ffmpeg git tree I was using for reference to a version after the one I have on my desktop and on the embedded target, doh
[08:24:29 CET] <JEEB> dongs: so is it really mostly tlv id 0x03 and header packed ipv6 packets? i fed a few megabytes into a thing and I just get cid 1,2,3 from those. so no signaling packets etc? or are they just rarely muxed?
[08:31:15 CET] <JEEB> also I get it why you said "not really variable length" because a whole lot of packets are 14xx bytes
[08:31:35 CET] <JEEB> there's some 32-7xx ones but mostly 14xx
[08:33:02 CET] <dongs> hi
[08:33:18 CET] <dongs> JEEB: there's SI tables and shit (described in B60
[08:33:29 CET] <dongs> and NTP stuff over ipv6
[08:33:31 CET] <dongs> otherwise, yes just that
[08:34:04 CET] <dongs> also i think i was doing something wrong with cid1/2/3 stuff before, i reran my shit and cid != 2 (from teh samples you haev anyway) is very little amount of data. i think my != or == thing was wrong when i was rejecting stuff
[08:34:13 CET] <JEEB> ok
[08:35:58 CET] <dongs> there's the PLT table that describes where stuff is, as well as MPT table. other stuff isnt strictly necessary, MH-SDT, MH-EIT etc.
[08:36:17 CET] <dongs> also MH-CAT for crpyto stuff
[08:38:11 CET] <dongs> about the only cunty stuff is gathering mfu/mpu sections until complete packet is done
[08:38:16 CET] <dongs> this is where the DumpTS thing fails
[08:39:15 CET] <JEEB> yea so a growing buffer a la pes packet finishing with mpeg-ts
[08:39:40 CET] <dongs> yeah, start it on division=0, apppend othewies, and if 3= append and commit.
[08:39:41 CET] <JEEB> then you pass that to the following layer as it's complete
[08:39:45 CET] <dongs> ya
[12:23:55 CET] <sazawal> Hello. I have split a video into clips at every keyframe using, "ffmpeg -i input.mkv -acodec copy -f segment -vcodec copy clip%d.mkv >& output.txt". I found the keyframe timestamps using, "ffprobe -v error -skip_frame nokey -sexagesimal -show_entries frame=pkt_pts_time -select_streams v -of csv=p=0 input.mkv >output1.txt". The first clip (clip0.mkv) I get is about 11 seconds long, and the timestamps in output1.txt says "(1) 0:00:
[12:23:55 CET] <sazawal> 00.120000   (2) 0:00:01.200000 (3) 0:00:11.200000 (4) 0:00:20.920000". I do not understand why the first split is taking place at the third keyframe.
[12:35:27 CET] <Ariyasu> the first key frame is probably the first frame
[12:35:32 CET] <Ariyasu> so no point splitting there
[12:35:42 CET] <Ariyasu> also the second frame could also be a keyframe
[12:36:00 CET] <Ariyasu> the inital gop can be weird depending on how the file was created or cut
[12:36:15 CET] <Ariyasu> you can have a few idr/i frames next to each other
[12:44:04 CET] <sazawal> Ariyasu, I see. So apart from the first few clips/keyframes, it should be good otherwise. I mean, I am not doing anything wrong here.
[12:47:12 CET] <sazawal> Ariyasu, Is there a way to get timestamps when the split is happening? Can I use some options in the split command (first command) to get the timestamps at the time of spllitting?
[13:21:04 CET] <faLUCE> is it possible to encode/decode a RAW opus audio file?
[13:34:47 CET] <JEEB> there's no raw opus as far as I know, although you will want to verify from #xiph or #opus or whatever the channel for that is?
[13:34:58 CET] <JEEB> the .opus files are actually OGG
[13:35:48 CET] <JEEB> (and those libavformat can read)
[13:36:11 CET] <JEEB> if you have actual separate opus packets then I guess it could be decoded if you make AVPackets out of them
[13:36:52 CET] <faLUCE> JEEB: ok. In addition, I just verified that frames sent to the opus encoder (not by me, but by ffmpeg command) have non costant pts incremental (--> they don't have pts = nb_samples.frame_counter)
[13:37:40 CET] <faLUCE> I don't understand how ffmpeg sets these pts....
[13:38:05 CET] <faLUCE> they are around the same incremental value, but not with an exact incremental value
[13:38:53 CET] <faLUCE> I printed the pts inside   static int libopus_encode(...)
[13:39:04 CET] <faLUCE> (libopusenc.c)
[13:39:11 CET] <JEEB> don't need to do that to see the timestamps
[13:39:12 CET] <JEEB> -debug_ts
[13:39:15 CET] <JEEB> if you are using ffmpeg.c
[13:39:27 CET] <JEEB> that will show you what the AVFrame/AVpacket timestamps will look like
[13:40:10 CET] <faLUCE> but does it show that for ENCODED or MUXED frames/packets?
[13:40:21 CET] <JEEB> yes
[13:40:36 CET] <faLUCE> encoded or muxed?
[13:40:38 CET] <faLUCE> or both?
[13:40:40 CET] <JEEB> both
[13:41:11 CET] <JEEB> demux, ffmpeg adjusted demux (fed to decoder), decoded timestamps
[13:41:26 CET] <JEEB> you can see all the spots with `git grep -A2 "debug_ts"`
[13:42:22 CET] <JEEB> basically on ffmpeg.c level (which is the API client)
[13:42:42 CET] <JEEB> demuxer has two entries, "raw" demuxer and demuxer+ffmpeg adjustment
[13:43:59 CET] <JEEB> for encoding it has both encoder <- (in) and encoder -> (out) etc
[13:45:53 CET] <faLUCE> yes, I see all. I confirm they don't have a fixed incremental value
[13:46:26 CET] <JEEB> you could add to the decoder output logging the nb_samples
[13:46:52 CET] <JEEB> in the received AVFrame
[13:54:52 CET] <faLUCE> JEEB: in the received avpacket o frame ?
[13:54:56 CET] <faLUCE> or
[13:57:02 CET] <faLUCE> (right,the frame for the decoder)
[13:59:48 CET] <JEEB> yup
[14:19:37 CET] <faLUCE> this is the command I used:   ffmpeg -f alsa -ac 2 -i default -c:a libopus -f mpegts -debug_ts prova.ts   I don't understand why it outputs also pts of a "demuxer" and "demuxer+ffmpeg" element. which is this demuxer?
[14:20:58 CET] <faLUCE> are they the pts for the decoder?
[14:21:36 CET] <JEEB> it's the input you feed into ffmpeg.c
[14:21:43 CET] <JEEB> in this case the libavdevice ALSA device :P
[14:22:02 CET] <JEEB> demuxer+ffmpeg is after ffmpeg.c plays with the values that are received from the "demuxer"
[14:22:21 CET] <JEEB> you av_read_frame() from the devices so it makes sense to use the same logic as for normal reading of input
[14:22:52 CET] <faLUCE> I see. In my program I don't use av_read_frame(), I call alsa API directly
[16:24:03 CET] <faLUCE> Given this command:   ffmpeg -f alsa -ac 2 -i default -c:a libopus -f mpegts -debug_ts prova.ts   ---> I see two lists of pts:
[16:24:11 CET] <faLUCE> encoder <- type:audio frame_pts:97935 frame_pts_time:2.04031 time_base:1/48000
[16:24:19 CET] <faLUCE> encoder -> type:audio pkt_pts:183039 pkt_pts_time:3.81331 pkt_dts:183039 pkt_dts_time:3.81331
[16:25:20 CET] <faLUCE> so, the second one is the output of the encoder: but how are these pts obtained ? I checked that they are not the pts of the avpackets obtained with "receive_av_packet()"
[16:29:01 CET] <faLUCE> it seems that there's an additional rescaling for the out packets of a libopus encoder
[16:44:22 CET] <faLUCE> this is very obscure... is there some hidden resampling or remuxing involved?
[16:45:17 CET] <durandal_1707> opus encoder resamples everything into 48k
[16:45:51 CET] <JEEB> but the fed time base seemed to be 48k too
[16:46:07 CET] <JEEB> the offset is what he was interested in I guess?
[16:46:18 CET] <JEEB> if those were for the same frame/packet
[16:47:18 CET] <JEEB> faLUCE: check if that receival part is before or after the thing gets rescaled to the muxer time base?
[16:48:17 CET] <JEEB> anyways i've had lavf+lavc work fine input to output with the api without any other pts/dts/duration adjustment than time base scaling where needed
[16:49:07 CET] <JEEB> so I know that in theory the extra random stuff that ffmpeg.c isn't really needed (like starting timestamps at zero)
[16:50:34 CET] <faLUCE> JEEB: it's before. In fact:
[16:50:38 CET] <faLUCE> encoder -> type:audio pkt_pts:8400 pkt_pts_time:0.175 pkt_dts:8400 pkt_dts_time:0.175
[16:50:39 CET] <faLUCE> muxer <- type:audio pkt_pts:8400 pkt_pts_time:0.0933333 pkt_dts:8400 pkt_dts_time:0.0933333 size:151
[16:52:01 CET] <faLUCE> there should be an adjustmen somewhere.... let's lool libopusenc.c again
[16:54:05 CET] <faLUCE> maybe the rescaling is in ff_af_queue_add()
[17:19:56 CET] <faLUCE> nothing found...
[17:39:06 CET] <faLUCE> [16:46] <JEEB> the offset is what he was interested in I guess?  <--- which offset?
[17:40:28 CET] <JEEB> the one between the two _time variables, pkt_pts_time:0.175 vs pkt_pts_time:0.0933333 .
[17:40:37 CET] <JEEB> or those weren't the same thing?
[17:41:28 CET] <JEEB> although no
[17:41:39 CET] <JEEB> those are just two different things, just having matching pkt_pts :P
[17:41:46 CET] <JEEB> 8400 / 48000
[17:41:47 CET] <JEEB> 0.175
[17:41:52 CET] <JEEB> 8400 / 90000
[17:41:52 CET] <JEEB> 0.09333333333333334
[17:41:59 CET] <JEEB> so it's not the same thing you're looking at :P
[17:42:17 CET] <faLUCE> I mean: there seem to be some offset put by ffmpeg to the encoded pkts' pts....
[17:42:40 CET] <JEEB> to compare the same thing, the latter would be
[17:42:40 CET] <JEEB> 8400 * (90000 / 48000)
[17:42:41 CET] <JEEB> 15750.0
[17:42:45 CET] <JEEB> that pkt_pts
[17:43:28 CET] <faLUCE> so, the value debugged by ffmpeg as the "encoder output", is not the avpacket->pts .... but what is it?
[17:43:47 CET] <JEEB> it is, but it is the output of an earlier packet that you looked at :P
[17:43:56 CET] <JEEB> because the timestamps have been adjusted for time base
[17:44:25 CET] <JEEB> the one that is fed to MPEG-TS muxer has its timestamps adjusted to 1/90000
[17:44:28 CET] <faLUCE> I checked that... there was no buffering
[17:44:41 CET] <JEEB> ok, let's not go further. let's confirm one thing
[17:44:47 CET] <JEEB> you posted two AVPacket log lines, right?
[17:44:52 CET] <faLUCE> yes
[17:44:55 CET] <JEEB> with both having pkt_pts 8400, right?
[17:45:22 CET] <faLUCE> yes
[17:45:34 CET] <JEEB> now, do you understand that those two are not the same "thing". it's just two packets that happen to have the same pkt_pts *after* the pkt_pts was adjusted for time base?
[17:45:53 CET] <JEEB> when you receive the AVPacket from encoder that packet is in encoder time base
[17:45:59 CET] <JEEB> which in case of libopus is 1/48000
[17:46:00 CET] <faLUCE> damn, I thought they were the same packet
[17:46:02 CET] <JEEB> yea
[17:46:18 CET] <faLUCE> so, the "encoder->" packet is a buffered packet, right?
[17:46:19 CET] <JEEB> the log line for muxing is after the pkt_pts is adjusted
[17:46:32 CET] <JEEB> what do you mean with "buffered packet"?
[17:46:49 CET] <faLUCE> I mean:
[17:46:54 CET] <JEEB> anyways, to match the packet that was received from the decoder for pkt_pts
[17:46:56 CET] <JEEB> 8400
[17:46:57 CET] <JEEB> 18:42 < JEEB> 8400 * (90000 / 48000)
[17:46:57 CET] <JEEB> 18:42 < JEEB> 15750.0
[17:47:06 CET] <JEEB> that pkt_pts should be the same timestamp for 1/90000
[17:47:16 CET] <faLUCE> look at this log:
[17:47:19 CET] <faLUCE> encoder <- type:audio frame_pts:3832 frame_pts_time:0.0798333 time_base:1/48000
[17:47:20 CET] <faLUCE> encoder -> type:audio pkt_pts:6593 pkt_pts_time:0.137354 pkt_dts:6593 pkt_dts_time:0.137354
[17:47:22 CET] <faLUCE> muxer <- type:audio pkt_pts:6593 pkt_pts_time:0.0732556 pkt_dts:6593 pkt_dts_time:0.0732556 size:168
[17:47:52 CET] <faLUCE> now, you confirm that the muxer packet is not the "encoder->" packet
[17:47:53 CET] <faLUCE> right?
[17:48:10 CET] <JEEB> encoder -> is the "received from encoder" point
[17:48:34 CET] <JEEB> muxer <- is the "feeding AVPacket with these timestamps to muxer"
[17:48:45 CET] <faLUCE> and in this case they are not the same packet
[17:48:48 CET] <faLUCE> right?
[17:49:06 CET] <JEEB> yes, the one fed into muxer is an earlier one
[17:49:30 CET] <JEEB> the pkt_pts just happens to match :P
[17:49:42 CET] <JEEB> (after time_base adjustment)
[17:49:50 CET] <faLUCE> ok, now: looking at the "encoder <-", that frame does not correspond to the packet in the "encoder->" line soon after
[17:49:52 CET] <faLUCE> right?
[17:52:06 CET] <faLUCE> (in fact I see different pts)
[17:52:38 CET] <JEEB> for the record, there can also be an offset due to the encoder's encoder delay for audio
[17:52:47 CET] <JEEB> the amount of encoder delay depends on the audio frame sizes usually
[17:53:13 CET] <JEEB> but I don't know, I don't know your full logs or anything to make a proper assessment which frame and packet match each other. sorry :P
[17:54:20 CET] <faLUCE> but I made a debug inside libopus_encode(). I debugged the pts for of the input FRAME, and it is the same of (encoder<-) part, and the pts of the output packet, and it is the same of (encoder<-) part
[17:54:41 CET] <faLUCE> so, there should be a buffering outside the opus stuff
[17:54:50 CET] <JEEB> yes, because encoder <- is what is fed into the encoder
[17:54:52 CET] <JEEB> from ffmpeg.c
[17:55:19 CET] <faLUCE> ok, but the pts of the output packet should be the same of that of "encoder->"
[17:55:22 CET] <faLUCE> but it is not
[17:55:35 CET] <faLUCE> so, the debug is misleading...
[17:55:41 CET] <JEEB> depends on how ffmpeg.c calls teh receive
[17:55:47 CET] <JEEB> and/or other possible factors
[17:56:15 CET] <faLUCE> [17:55] <JEEB> depends on how ffmpeg.c calls teh receive . Well, this is true. But this is not something associated to the opus code
[17:56:23 CET] <JEEB> of course not
[17:56:35 CET] <faLUCE> but at the same time, it's mixed to the opus part
[17:57:09 CET] <faLUCE> but in each case, there's something between send and receive that ADJUSTS
[17:57:12 CET] <faLUCE> these timestamp
[17:57:21 CET] <faLUCE> in ffmpeg.c
[17:57:34 CET] <faLUCE> am I wrong?
[17:57:42 CET] <thebombzen> tfw my patch is ignored again
[17:57:44 CET] <thebombzen> 2nd time in a row
[17:57:45 CET] <thebombzen> lol
[17:57:53 CET] <JEEB> I've just been dead and all :V
[17:58:00 CET] <JEEB> I tried to get derek to look at the fps patch
[17:58:05 CET] <JEEB> since he asked about that very thing
[17:58:08 CET] <thebombzen> oh so u know which one I'm talking about
[17:58:13 CET] <JEEB> "can I set fps with ffmpeg.c?"
[17:58:25 CET] <thebombzen> ye
[17:58:30 CET] <thebombzen> I sent it in january
[17:58:47 CET] <JEEB> yea, it's unfortunate that some patches don't get attention
[17:58:52 CET] <JEEB> there was also a patch to improve examples
[17:59:06 CET] <JEEB> I wanted to take a look at it but I've had other things I've had to prioritize higher than that
[17:59:09 CET] <JEEB> :V
[17:59:10 CET] <thebombzen> it was this one
[17:59:10 CET] <thebombzen> https://0x0.st/zXg0.patch
[17:59:50 CET] <faLUCE> I sent patches one year ago. they had also good feedbacks, but they were forgotten
[18:00:08 CET] <JEEB> faLUCE: I'm not sure if ffmpeg.c adjusts timestamps after receiving the AVPacket and feeding it into a muxer. other than adjusting the timestamps and duration according to time base
[18:00:26 CET] <JEEB> check how much encoder delay libopus adds?
[18:00:50 CET] <JEEB> this probably doesn't help at all, but I've actually built an API client myself that decoded and re-encoded audio
[18:00:53 CET] <JEEB> it worked :P
[18:00:59 CET] <JEEB> without any real special stuff
[18:01:36 CET] <thebombzen> doesn't ffmpeg.c sanitize timestamps on input
[18:01:41 CET] <thebombzen> unless you use `-copyts` input option?
[18:01:41 CET] <JEEB> on input, yes
[18:01:50 CET] <JEEB> this is after receiving AVPacket from encoder
[18:01:58 CET] <thebombzen> also what happens if you try `-vsync passthrough`
[18:02:07 CET] <JEEB> he is ok with the input adjustments
[18:02:11 CET] <faLUCE> <JEEB> check how much encoder delay libopus adds? <--- already done. there's a delay field. It sets a "312" delay to the avctx
[18:02:12 CET] <JEEB> (after av_read_frame)
[18:02:16 CET] <thebombzen> oh nvm, that's video
[18:02:39 CET] <JEEB> faLUCE: it should also be adjusted in the AVPackets
[18:02:44 CET] <JEEB> at least that's how it usually is
[18:03:10 CET] <faLUCE> JEEB: yes, in fact I saw it's adjusted in the output avpacket
[18:03:13 CET] <JEEB> just like you open an mp4 file with encoder delay and the AVPacket you demux has a negative PTS
[18:03:22 CET] <JEEB> (the first one)
[18:03:34 CET] <faLUCE> but it is not the same delay in the  encoder->  part
[18:04:17 CET] <JEEB> anyways, the logging is very close by
[18:04:22 CET] <JEEB> if you look at do_audio_out
[18:04:25 CET] <JEEB> in ffmpeg.c
[18:04:58 CET] <JEEB> 1. debug_ts encoder <- 2. avcodec_send_frame 3. go into avcodec_receive_packet loop
[18:05:24 CET] <JEEB> it rescales to muxer AVStream time base and another debug_ts
[18:05:30 CET] <faLUCE> av_packet_rescale_ts(&pkt, enc->time_base, ost->mux_timebase);
[18:05:34 CET] <faLUCE> damn!!!|
[18:05:59 CET] <faLUCE> then this is misleading
[18:06:13 CET] <JEEB> well yes, I've mentioned it will rescale the timestamps from encoder time base to muxer time base?
[18:06:27 CET] <JEEB> but yes, the differing time bases can be fun. that should still not cause a drift
[18:06:43 CET] <faLUCE> JEEB: ok, but this is misleading, because the debug says encoder->  and muxer<-
[18:06:47 CET] <JEEB> that should only make f.ex. 8400 into 15750
[18:06:56 CET] <faLUCE> this should be fixed, IMHO
[18:06:59 CET] <JEEB> faLUCE: muxer <- comes later :P
[18:07:30 CET] <JEEB> but yes, it should be more clear what time base is being used
[18:07:39 CET] <faLUCE> I'll send a ticket
[18:07:45 CET] <JEEB> for what?
[18:07:48 CET] <faLUCE> for that
[18:07:52 CET] <JEEB> ?
[18:08:10 CET] <JEEB> for it not being clear which time base it is?
[18:08:15 CET] <faLUCE> it's absolutely not clear that the out ts of the encoder-> part is rescaled
[18:08:24 CET] <faLUCE> yes
[18:08:26 CET] <JEEB> ok
[18:08:34 CET] <JEEB> I just wanted you to confirm that :P
[18:08:55 CET] <faLUCE> JEEB: note that the timebase in other log lines is specified
[18:09:05 CET] <JEEB> yea
[18:09:12 CET] <JEEB> in the AVFrame ones at least
[18:09:23 CET] <JEEB> or the one right before feeding it
[18:09:35 CET] <JEEB> the _time ones give a hint, but are not exact
[18:09:39 CET] <JEEB> so yes, I agree :P
[18:09:42 CET] <JEEB> that logging could be improved
[18:09:44 CET] <faLUCE> but I think that the two lines should be swapped
[18:10:00 CET] <faLUCE> av_packet_rescale_ts(&pkt, enc->time_base, ost->mux_timebase);   AFTER the av_log
[18:10:55 CET] <JEEB> yea, I guess it makes sense to log in the same time base that the other log line logged in
[18:10:56 CET] <faLUCE> let's inform the devel channel
[18:11:43 CET] <JEEB> these sorts of things are just low priority. not controversial and I bet nobody would actually mind :P
[18:12:11 CET] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=blobdiff;f=fftools/ffmpeg.c;h=544f1a1cef334df9a2c0507dc40ac587b41787d6;hp=6abcc57776e839eb0b2ce59bb1fbd3cd417e0658;hb=3a36b0c4b8f2a4529fb8d1df217cada04e59aef7;hpb=c0fb6f963fd7ee555ba2fdc254444e208bb0bc46
[18:12:16 CET] <JEEB> I improve logging sometimes
[18:13:07 CET] <JEEB> although the delta and the ts_offset are not exactly understandable :P
[18:13:14 CET] <JEEB> but at least it tells you now which stream had a discontinuity
[18:13:21 CET] <JEEB> and if it was video or audio or whatever
[19:13:04 CET] <lemourin> is it possible to read parts of very big images with ffmpeg without running out of memory? e.g these http://images.aperio.com/BigTIFF/
[19:20:50 CET] <JEEB> lemourin: there's a random memory allocation limit somewhere so if those images are really large you might hit that
[19:21:06 CET] <JEEB> supposedly it's to protect against mistaken large allocations... or something
[19:23:18 CET] <lemourin> yea, but in the link i sent there is an image with resolution 1095630 x 939495 (10^12 pixels) so there is no way any normal pc would load it all at once; so what i'm asking about is whether  it is possible to read only a subrectangle of such big image
[19:24:34 CET] <JEEB> you'd need to make a decoder that takes in requests of specific parts
[19:24:39 CET] <JEEB> or something like that
[19:25:03 CET] <lemourin> ok, so currently it is not possible; thats all i need to know for now :)
[19:26:40 CET] <JEEB> or at least I don't remember any decoders being able to return limited images without the decoder supporting it. and other than cropping in AVC / HEVC etc I don't remember there being such partial things
[19:28:03 CET] <JEEB> lemourin: basically just not that I know of :)
[19:28:13 CET] <JEEB> I could be incorrect o' course
[20:46:29 CET] <faLUCE> is it possible to feed an opus audio muxer,  with ffmpeg, with encoded frames as separate files?
[20:48:15 CET] <faLUCE> (or with a raw opus encoded stream file)
[20:54:39 CET] <faLUCE> ffmpeg -f alsa -ac 2 -i default -c:a libopus -f opus prova.opus   <---- I don't understand if the output is raw opus and how to play it (if I play it with ffplay, I hear very fast audio)
[20:57:23 CET] <JEEB> -f opus is opus-in-ogg
[20:57:28 CET] <JEEB> there is no such thing as "raw opus"
[20:57:40 CET] <JEEB> opus always needs some encapsulation
[21:46:53 CET] <retal> Hi guys, how to fix common.mak:57: recipe for target 'libavcodec/libx264.o' failed   ?
[21:46:55 CET] <retal> https://pastebin.com/VXeFWtKq
[21:54:55 CET] <faLUCE> retal: which version of ffmpeg are you compiling?
[21:55:50 CET] <retal> i pulled from git
[21:55:58 CET] <faLUCE> retal: then update x264 too
[21:56:32 CET] <faLUCE> (upgrade)
[21:56:45 CET] <retal> 264 also pulled from  N-76538-gb83c849e87
[21:56:58 CET] <retal> sorry  https://code.videolan.org/videolan/x264.git
[21:58:29 CET] <retal> faLUCE, ffmpeg from  git://source.ffmpeg.org/ffmpeg.git
[21:58:29 CET] <retal> x264 from https://code.videolan.org/videolan/x264.git
[21:58:56 CET] <faLUCE> retal: check if you have x264_bit_depth in x264_config.h
[21:59:33 CET] <faLUCE> defined
[22:01:39 CET] <retal> faLUCE, #define X264_BIT_DEPTH     0
[22:05:08 CET] <faLUCE> retal: wait a sec
[22:06:09 CET] <faLUCE> retal: do you need latest x264 ?
[22:06:41 CET] <retal> faLUCE,  https://code.videolan.org/videolan/x264.git not latest ?
[22:06:48 CET] <faLUCE> retal: I mean:
[22:06:58 CET] <faLUCE> do you WANT to use the latest x264
[22:07:01 CET] <faLUCE> ?
[22:07:08 CET] <faLUCE> for specific reasons?
[22:07:22 CET] <retal> i dont care about version , i just need x264 :)
[22:08:21 CET] <kepstin> i don't see anything obvious in current x264 git that would break it with ffmpeg
[22:08:35 CET] <faLUCE> ok, then download an older x264 version, and make sure that in common.c   "const int x264_bit_depth = BIT_DEPTH;"
[22:08:45 CET] <faLUCE> make sure there's that line
[22:09:39 CET] <faLUCE> kepstin: yes, it's strange
[22:10:04 CET] <retal> faLUCE, thank you i will try
[22:11:08 CET] <kepstin> retal: it looks like the issue is that ffmpeg's configure script and ffmpeg's build were run with different x264 versions
[22:11:20 CET] <kepstin> maybe you have a system copy of x264 installed that's confusing things?
[22:11:39 CET] <kepstin> hmm, wait, no that makes no sense
[22:12:04 CET] <faLUCE> kepstin: just checked that I have x264_bit_depth in ffmpeg 4.2.1 too, but not in libx264. and it compiled fine
[22:12:08 CET] <kepstin> but regardless, ffmpeg shouldn't be trying to access teh `x264_bit_depth` field at all for X264 >= 153
[22:12:17 CET] <kepstin> so it's misdetected the x264 version
[22:13:11 CET] <faLUCE> yes, that's right
[22:14:31 CET] <faLUCE> kepstin: btw, the ffmpeg program doesn't calculate timestamps for the avframe input of opus encoder based on samples... it's time based
[22:14:57 CET] <kepstin> faLUCE: yes, that's because everything ffmpeg cli does is generic and based on time/pts.
[22:15:13 CET] <kepstin> faLUCE: however, most audio inputs to ffmpeg will report time based on samples, so...
[22:15:23 CET] <kepstin> although it depends
[22:15:52 CET] <faLUCE> kepstin: in each case, sample-based or time-based pts gave me the same choppy audio :-(
[22:16:20 CET] <kepstin> faLUCE: hmm, sometime else going wrong then. really hard to say without being able to hear it or see the code.
[22:16:29 CET] <faLUCE> kepstin: I know, I know
[22:16:49 CET] <faLUCE> kepstin: the biggest problem is that I could write a "raw opus file" but
[22:17:05 CET] <faLUCE> I don't know how I could use it for debugging
[22:17:18 CET] <kepstin> there's no such thing as raw opus, because opus packets are not self framing (they need external signalling of packet length)
[22:17:33 CET] <kepstin> inside ffmpeg, that's done by the data size on the AVPacket
[22:17:39 CET] <kepstin> and in containers, by the container
[22:18:24 CET] <faLUCE> the biggest problem is that it's very hard to figure which field in the avctxt, in the avframe or in the muxer has not been set..... they are so many
[22:20:49 CET] <kepstin> i think all you need to actually set on the avctx is just channels, sample_rate, and sample_fmt - everything else has reasonable defaults
[22:21:23 CET] <faLUCE> kepstin: and they are set correctly (and they work with mp2 and adts aac)
[22:23:12 CET] <faLUCE> kepstin: on the avframe I set nb_samples, format, channels, layout, sample_rate   and pts (before encoding)
[22:24:00 CET] <faLUCE> and filled the avframe with linesize[0] bytes
[22:24:02 CET] <kepstin> right, frame->nb_samples should match avctx->frame_size - and you have to make sure you actually have that many samples in the buffer, of course.
[22:24:20 CET] <faLUCE> yes, I have all the samples in the buffer
[22:24:40 CET] <faLUCE> the strange thing is that the audio distortion is very little
[22:25:07 CET] <faLUCE> I wonder if it has something to do with a pre-roll
[22:25:23 CET] <kepstin> preroll has nothing to do with it
[22:25:47 CET] <kepstin> preroll is how many samples the decoder is supposed to discard after starting playback
[22:25:53 CET] <kepstin> it doesn't affect ongoing decoding
[22:26:38 CET] <kepstin> (the encoder sticks some extra samples at the start before encoding to, "prime" the encoder i guess you'd say)
[22:27:29 CET] <faLUCE> kepstin: but if I encode (resulting good audio )  with ffmpeg, I see that the first encoded frame has a ts = -312.   Where 312 is a sort of padding
[22:28:05 CET] <kepstin> yeah, that's the preroll. how it's signalled depends on the container
[22:28:29 CET] <kepstin> when you decode that, you throw out the first 312 samples and then use the rest continuously
[22:29:04 CET] <faLUCE> then the distortion could depend on that
[22:29:08 CET] <kepstin> how?
[22:29:40 CET] <faLUCE> I mean, if I have to use the rest continously, there a bad offset of 312 for each frame?
[22:29:51 CET] <faLUCE> (there is)
[22:29:53 CET] <kepstin> the worst that could happen is you forget to remove the preroll during playback, and then you have an extra couple ms of junk (mostly silence) at the start.
[22:30:08 CET] <faLUCE> kepstin: exactly
[22:30:11 CET] <kepstin> all the timestamps are correct in that case - 0 is the start of the useful audio
[22:31:06 CET] <faLUCE> coming back in 15 mins
[22:31:20 CET] <kepstin> so the first frame contains e.g. samples -312 to before 0, which you throw out, and then it has the other 648 that you keep
[22:31:30 CET] <kepstin> then the next frame has 960 samples starting at 648
[22:31:42 CET] <kepstin> then the next has 960 sample starting at 1608
[22:31:44 CET] <kepstin> and so on
[22:32:30 CET] <kepstin> but that's on the decoder side
[22:32:55 CET] <kepstin> on the encoder side, you don't need to do anything - you just pass in audio, and the encoder will insert the preroll samples before starting to encode your audio
[22:34:38 CET] <kepstin> note that preroll samples are common in all dct based audio codecs, with varying ways to signal them
[22:34:56 CET] <kepstin> vorbis signals them in-stream, so the decoder transparently removes them for you
[22:35:33 CET] <kepstin> mp3 doesn't bother, so the only way you'll know about the added samples is if the encoder put some custom metadata in (e.g. a xing header) that indicates it
[22:37:09 CET] <kepstin> aac is a mess, there's apparently a way to signal it properly in mp4 now, but originally you just assumed that your aac was made by itunes, and hardcoded the delay to the value itunes used.
[22:37:28 CET] <kepstin> anyways, none of this *in any way* would cause ongoing noticable problesm with audio quality
[22:38:31 CET] <kepstin> since it's done by the encoder, so you don't need to do anything when encoding, and it's only handled once at the start of the audio when decoding, and if you forget to do that you probably still wouldn't be able to tell unless you cared about exact alignment of samples or "gapless" music playback between multiple files
[22:41:34 CET] <kepstin> (er, i guess "MDCT" based codecs specifically, since those are the onces that do overlap)
[22:48:39 CET] <MiniDude_> Hello ffmpeg group don't want to step on anyone else's questions, and hopefully this is the right channel to ask. When doing some transcoding with the fflag discardcorrupt, what is it looking at in the frames to determine if the frame is corrupted?  i see when transcoding the error Dropped corrupted packet (stream = 1). I've been digging through the files, and see in utils.c where it is using the constant AVFMT_FLAG_DISCARD_CORRUP
[22:49:36 CET] <kepstin> MiniDude_: corruption is detected in the decoder - if the decoder sees something it doesn't expect, it might set the a flag on the decoded flag to indicate it has corrupt data
[22:49:54 CET] <kepstin> how accurate this is depends on the decoder
[22:50:06 CET] <kepstin> a flag on the decoded frame*
[22:50:19 CET] <JEEB> MiniDude_: it's handled within libavformat
[22:50:20 CET] <kepstin> I suppose some containers with checksums might also do something at the container level
[22:50:26 CET] <kepstin> not sure, haven't looked into that
[22:50:30 CET] <JEEB> if some demuxer sets the flag
[22:50:36 CET] <JEEB> AV_PKT_FLAG_CORRUPT
[22:50:44 CET] <JEEB> if that gets set, you get that message
[22:50:50 CET] <JEEB> since the internal lavf code drops that packet
[22:50:57 CET] <kepstin> hmm, is it only at the packet level?
[22:51:01 CET] <JEEB> this option is
[22:51:08 CET] <JEEB> (discardcorrupt)
[22:51:21 CET] <kepstin> oh right, I should have seen the "Dropped corrupted *packet*" :)
[22:51:33 CET] <faLUCE> About two years ago I submitted some api examples, like this one:   https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg50906.html    now I will use the same example in order to understand what was wrong with opus... if anyone finds useful this patch, please signal it so it can be added to the examples of ffmpeg
[22:52:06 CET] <JEEB> MiniDude_: so if *you* want to handle the corrupt packets, then you *don't* set that flag
[22:52:18 CET] <JEEB> because with this flag it will just drop the packets for you
[22:52:27 CET] <MiniDude_> yeah i figured if by not setting the flag it would stop the errors
[22:52:50 CET] <MiniDude_> was just trying to understand what would cause the packet to be considered corrupt when it is passed through the decoder.
[22:53:07 CET] <MiniDude_> So i guess it would have to do with the other flags that are being used
[22:53:13 CET] <JEEB> s/decoder/demuxer/
[22:53:15 CET] <JEEB> since this is libavformat
[22:54:17 CET] <JEEB> if you do a `git grep "AV_PKT_FLAG_CORRUPT"` you will see which modules utilize this value at all
[22:54:34 CET] <faLUCE> kepstin: as you can see, about two years ago I used the sample-based method:    pts =  converted_audio_frame->nb_samples*(encoded_pkt_counter-1);    :-)
[22:55:10 CET] <MiniDude_> i saw the code in libavformat where it was using the if statement to compare the value
[22:55:11 CET] <kepstin> faLUCE: biggest change you should have to make to that example for opus is that the libopus encoder doesn't accept planar formats, only packet s16 and flt.
[22:55:20 CET] <kepstin> packed*
[22:55:26 CET] <faLUCE> kepstin: I defined all...
[22:55:42 CET] <faLUCE> so, with few changes it would be good for opus too
[22:55:46 CET] <MiniDude_> thanks for the quick response. i'll go do some more research.
[22:55:52 CET] <JEEB> MiniDude_: basically without the flag the API gives you packets including those marked by the demuxers as corrupt
[22:55:54 CET] <faLUCE> and it's really better than the strange examples in the doc dir
[22:56:04 CET] <JEEB> MiniDude_: with the flag, it automagically drops them
[22:56:11 CET] <JEEB> which is where the message comes from
[22:56:18 CET] <JEEB> so that you know that the API did indeed drop a packet
[22:56:24 CET] <JEEB> (because it was flagged corrupt)
[22:56:27 CET] <MiniDude_> yeah i figured that was the case.
[22:57:08 CET] <MiniDude_> would it be possible that by dropping packets it would cause an issue like lipsync on video?
[22:57:11 CET] <MiniDude_> i would assume yes
[22:57:29 CET] <kepstin> it shouldn't, since the following packets will still have correct timestamps (pts)
[22:57:30 CET] <JEEB> depends on the exact container and if it has proper timestamps and you as the API client are able to re-sync
[22:58:06 CET] <MiniDude_> hmm you just might have just given me an ahah moment.
[22:58:31 CET] <kepstin> depending on the codec, you might want to pass corrupt packets to the decoder anyways, they might be able to partly decode it or do some error concealment. Or you might just get cool glitch effects.
[22:59:19 CET] <MiniDude_> lol cool glitch effect
[23:01:12 CET] <MiniDude_> what would you say the effects would be of dropping those corrupt packets. mind you this is doing mpeg2 and mpeg4.
[23:01:27 CET] <JEEB> depends
[23:03:42 CET] <kepstin> in general, the earlier in the gop your corrupt frame is the worse it'll be, since it means predictions of later frames in the gop will be based on incorrect/missing data
[23:03:44 CET] <MiniDude_> so one thing i'm experiencing is the lipsync issue on some of my streams, but like it was pointe dout that could be the re-sync of the time stamps, but i'm also seeing where sometimes it will just stop doing transcoding
[23:04:17 CET] <kepstin> what container? something like mpeg-ts where you can resync?
[23:04:35 CET] <MiniDude_> correct mpeg-ts
[23:05:03 CET] <JEEB> some corruption can cause long-lasting effects in a decoder for instance
[23:05:18 CET] <JEEB> i've had one channel get such an error about nightly while it was around :P
[23:05:53 CET] <MiniDude_> that is what i'm seeing. over a span of time the channel will be fine and then just start spewing corrupt errors. Restarting the channel seems to clear them up for a while.
[23:06:19 CET] <JEEB> if it's the corrupt error you quoted before, that's *before* decoding
[23:06:26 CET] <JEEB> it's the protocol/demuxing layer
[23:06:42 CET] <JEEB> I'm talking about passing such data to the decoder anyways
[23:07:08 CET] <JEEB> protocol (file, udp, whatever) -> demuxer (f.ex. mpeg-ts) -> decoder (f.ex. H.264)
[23:07:16 CET] <MiniDude_> ot
[23:07:26 CET] <MiniDude_> it's* pulling in a udp
[23:07:44 CET] <MiniDude_> not that it really matters, but the full error is: 03-14 10:15:18 INFO  [50450:libavutil/log.c:338] [mpegts @ 0x2483740] Dropped corrupted packet (stream = 0)
[23:07:58 CET] <MiniDude_> and that can be repeated multiple times in a single second.
[23:08:09 CET] <kepstin> might want to double-check buffers/processing speed if this is something that happens regularly after it's been running for some amount of time
[23:08:21 CET] <JEEB> yes, that's the libavformat packet reading layer telling you it's getting garbage in
[23:08:26 CET] <JEEB> it's way before decoding
[23:08:48 CET] <JEEB> libavformat handles protocols (I/O) and containers (demuxing and muxing)
[23:08:55 CET] <MiniDude_> ok
[23:09:26 CET] <JEEB> if you have multiple sources, make sure you're only taking in one
[23:09:35 CET] <MiniDude_> would you think a low udp buffer in the sysctl cause it to become garbage?
[23:09:54 CET] <JEEB> yes, if the kernel has to drop packets from queue the result will be garbage
[23:09:58 CET] <kepstin> if you receive multiple frames while the application is busy doing something else, yes
[23:10:02 CET] <MiniDude_> perfect.
[23:10:09 CET] <MiniDude_> that is another route i was going down
[23:10:11 CET] <kepstin> well, s/multiple frames/too much data/
[23:10:49 CET] <MiniDude_> i was thinking that if the udp buffer was filling up too much it was dropping and then the next packet in line would not be in the correct order
[23:15:15 CET] <MiniDude_> thanks everyone for the input. gonna take this back and do some tweaks to see if it improves performance. If not i'll probably come back and hit you with some more questions.
[00:00:00 CET] --- Sat Mar 16 2019