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

Mon Feb 11 03:05:02 EET 2019

[00:00:03 CET] <JEEB> I did tell you didn't I? the VO probably didn't support 4:2:2 yet the module took it in
[00:00:14 CET] <shibboleth> mhm
[00:01:22 CET] <shibboleth> Movie-Aspect is 1.33:1 - prescaling to correct movie aspect.
[00:01:24 CET] <shibboleth> VO: [gl] 640x360 => 640x480 Planar 422P
[00:01:26 CET] <shibboleth> Movie-Aspect is 1.33:1 - prescaling to correct movie aspect.
[00:01:28 CET] <shibboleth> VO: [gl] 640x360 => 640x480 Planar 422P
[00:01:46 CET] <JEEB> yes, after you switch to gl it can take it in
[00:02:05 CET] <fructose> So this will show where key frames are, right? ffprobe -loglevel error -skip_frame nokey -select_streams v:0 -show_entries frame=pkt_pts_time -of csv=print_section=0
[00:02:24 CET] <JEEB> anyways, no idea about mplayer but since one had vdpau and the other didn't that seemed like the clearest thing
[00:03:41 CET] <JEEB> fructose: I think you just want pts for the AVFrames, and if you're OK with AVPackets then you should look at the AVPacket's pts/dts (pts is what you want)
[00:08:03 CET] <fructose> JEEB: So is there another command you'd recommend instead? This channel is for users, not developers, right?
[00:09:08 CET] <JEEB> yes
[00:17:45 CET] <shibboleth> speaking of key frame/iframes
[00:18:09 CET] <shibboleth> suggestions as to a golden rule when setting up sources such as sec cams?
[00:20:21 CET] <fructose> One version of that rule is:  "Treat your inferior as you would wish your superior to treat you."
[00:21:42 CET] <fructose> You know like, avoid requiring a user to know the intimate details of a C struct in order to get help
[00:22:20 CET] <JEEB> yes, you could just forget I mentioned the structs
[00:22:41 CET] <JEEB> ffprobe has -show_packets (demuxer level) and -show_frames (decoding level)
[00:23:13 CET] <JEEB> and you specifically noted pkt_pts_time , and thus I noted that you probably want to use pts or pts_time values from ffprobe
[00:23:27 CET] <JEEB> getting the packet pts from a decoded frame just doesn't make too much sense to me
[00:23:46 CET] <JEEB> unless show_entries frame=XXX does something completely different than what I'd guess
[00:24:40 CET] <fructose> Thanks, I'll see if I can decypher that.
[00:24:41 CET] <JEEB> and so far I think I'm treating people rather well, no? the only thing at times is that I can't give specifics right out of the store bookshelf because I don't remember all things exactly in my mind :P
[00:25:33 CET] <fructose> JEEB: Text can be ambiguous, no worries on my end.
[00:47:13 CET] <Kray> ¤
[05:35:44 CET] <cryptodechange> https://stackoverflow.com/a/30832903
[05:36:08 CET] <cryptodechange> How would I adapt that to make a 4:3 video to 16:9 with the blurred sides?
[06:34:33 CET] <cryptodechange> If a video's aspect ratio does not match the native resolution, does that simply mean that the media player is stretching the video to match?
[06:43:56 CET] <Fenrirthviti> cryptodechange: depends on the video player.
[07:09:40 CET] <mfwitten> cryptodechange: Did you figure it out?
[07:23:49 CET] <cryptodechange> using mpv
[07:25:12 CET] <cryptodechange> It's 720:480 with an 4:3 aspect ratio but mpv resizes it to 720x540
[07:26:03 CET] <furq> any video player that doesn't stretch to match sar/dar is broken
[07:27:13 CET] <cryptodechange> Is it better that it upscales it to 540p instead of downscaling the width?
[07:27:36 CET] <furq> probably
[07:27:40 CET] <furq> otherwise you'd lose horizontal information
[07:28:15 CET] <cryptodechange> I'm converting some 4:3 DVD content with a blurred background in the place of the black pillars
[07:28:31 CET] <cryptodechange> as I want to watch 4:3 content on my OLED without burning in
[07:49:31 CET] <furq> cryptodechange: "split[fg][bg];[bg]eq=contrast=0.4:brightness=-0.4:saturation=0.4,scale=w=if(gt(dar\,16/9)\,iw\,ih*16/9):h=i f(gt(dar\,16/9)\,iw/(16/9)\,ih):flags=bicubic,boxblur=8:8[bgout];[bgout][fg]overlay=x=(W-w)/2:y=(H-h)/2"
[07:49:38 CET] <furq> should work with any aspect ratio
[08:05:47 CET] <cryptodechange> nice thanks
[08:06:25 CET] <cryptodechange> trying to remember the detelecine stuff, fieldmatch,decimate still shows as having interlaced frames
[08:06:35 CET] <cryptodechange> every couple hundred frames
[08:07:43 CET] <cryptodechange> furq: that chain comes up with the error 'width not divisible by 2 (853x480)'
[12:03:47 CET] <sn00ker> hi all
[12:03:48 CET] <sn00ker> https://stackoverflow.com/questions/54404097/ffmpeg-v4l-snd-aloop-sound-asyncron-alsa-buffer-xrun
[17:06:37 CET] <JEEB> what's the dumbest dedup filter in lavfi?
[17:07:00 CET] <durandal_1707> dedup?
[17:07:13 CET] <JEEB> huh, why did I not notice that in ffmpeg-filters.html
[17:07:26 CET] <JEEB> yea, ctrl+F dedup there brings up nothing
[17:07:30 CET] <JEEB> but if that's true, great
[17:07:33 CET] <durandal_1707> define dedup
[17:07:50 CET] <JEEB> drop frames if they are exactly the same as the previous one
[17:07:58 CET] <JEEB> it can be dumb as a lamb
[17:08:23 CET] <durandal_1707> they are smart, mpdecimate and decimate
[17:08:33 CET] <JEEB> yes, decimate needs a pattern
[17:08:37 CET] <JEEB> if I understand correctly
[17:08:42 CET] <JEEB> and there's no pattern here
[17:08:46 CET] <JEEB> so for context
[17:09:06 CET] <JEEB> a friend asked me how to output DVD/BD subtitles as PNGs
[17:09:55 CET] <JEEB> -i SUBTITLES -f lavfi -i  "color=c=black:s=1920x1080:r=24000/1001" -filter_complex "[1:v][0:s:0]overlay[le_out]" -map "[le_out]"
[17:09:59 CET] <JEEB> this is what I'm at right now
[17:10:03 CET] <JEEB> 24/1.001 for sync
[17:10:24 CET] <JEEB> then I just want to blindly dedup
[17:10:34 CET] <JEEB> because duplicated frames will be exact dupes
[17:10:37 CET] <JEEB> vOv
[17:10:40 CET] <JEEB> lemme see mpdecimate
[17:11:08 CET] <JEEB> mpdecimate=max=0 I think
[17:12:53 CET] Action: durandal_1707 tries to dechipher hi/lo/frac
[17:59:47 CET] <Zexaron> I can't find changes for 4.1
[17:59:56 CET] <Zexaron> release notes
[18:01:21 CET] <Zexaron> ah here it is
[18:03:17 CET] <JEEB> I usually check it from the repo personally. although I think the site should also get updated
[18:15:15 CET] <cc0> hello, is there a way to print all encoder flags values used when encoding a file?
[18:17:52 CET] <furq> depends on the encoder
[18:17:56 CET] <furq> libx264 will do that automatically
[18:22:12 CET] <keegans> I have an .mp4 container file that contains AAC samples, I'd like to read sample by sample, decode, and then play it out. How should I get started with this?
[18:22:32 CET] <JEEB> see the transcoding example under doc/examples
[18:22:44 CET] <JEEB> playing is a separate thing of course since you have to output the audio somehow
[18:23:01 CET] <JEEB> but demuxing, decoding and filtering is achievable
[18:23:17 CET] <JEEB> filtering for example to get the planar floating point samples of lossy formats into, say, 16bit int
[18:23:30 CET] <JEEB> (and packed because many audio output things don't support that)
[18:23:40 CET] <JEEB> that meaning planar actually
[18:23:42 CET] <JEEB> sorry for that wording
[18:23:53 CET] <keegans> ah, I'll look at the examples, thanks
[18:24:02 CET] <keegans> it's audio-only thought, so is demuxing necessary
[18:24:06 CET] <JEEB> yes
[18:24:08 CET] <keegans> *though
[18:24:11 CET] <JEEB> that gets the samples from the mp4
[18:24:29 CET] <keegans> ok, i'll read up on that
[18:24:40 CET] <JEEB> basically you create/open an AVFormatContext which starts up the parser
[18:24:54 CET] <JEEB> then there's the BestNamedFunctionEver which is "read_frame"
[18:25:00 CET] <JEEB> (even though it returns AVPackets)
[18:25:11 CET] <JEEB> I did not name it, but I'm still sorry for the name
[18:25:40 CET] <keegans> :D
[18:25:53 CET] <JEEB> then with each packet you can see which AVStream it came from. depending on the input format you may or may not have the full list of streams from the beginning
[18:26:02 CET] <JEEB> and then in your code you either process or don't or whatever
[18:26:06 CET] <JEEB> this stuff is really generic
[18:26:23 CET] <JEEB> then the AVStream also has the AVCodecID
[18:26:26 CET] <JEEB> of the stream
[18:26:34 CET] <JEEB> through which you can then initialize an AVCodecContext
[18:26:48 CET] <JEEB> and start feeding AVPackets to the decoder
[18:27:06 CET] <JEEB> the newer decoding/encoding APIs are pretty well documented https://www.ffmpeg.org/doxygen/trunk/group__lavc__encdec.html
[18:27:44 CET] <JEEB> but yea, after this you are at the point where you're getting decoded AVFrames from a decoder
[18:27:58 CET] <JEEB> with their timestamps and durations and sample counts
[18:28:11 CET] <JEEB> and the world's your oyster
[18:28:44 CET] <JEEB> you can then utilize libavfilter or libswresample (latter of which libavfilter utilizes) to do any format conversions you require
[18:28:59 CET] <keegans> awesome! I am new to audio, so excuse me if this is an obvious question -- but the decoded frames are in what format?
[18:29:10 CET] <keegans> as in, when I get the decoded frames I'd like to play those in SDL for example
[18:29:13 CET] <JEEB> that 100% depends on the decoder
[18:29:25 CET] <JEEB> lossy formats generally give you floating point
[18:29:38 CET] <JEEB> the AVFrame has the actual data on what you received
[18:29:56 CET] <JEEB> so you can decide "if it's not XYZ that I need, I do conversion with swresample/libavfilter"
[18:30:29 CET] <JEEB> and it's generally planar, as I noted. as opposed to packed
[18:30:52 CET] <JEEB> but once again, that info is available in the AVFrames coming from the decoder
[18:31:02 CET] <JEEB> also the format can change
[18:32:03 CET] <keegans> ah I see, the formats are specified here for SDL: https://wiki.libsdl.org/SDL_AudioSpec
[18:32:10 CET] <keegans> so my goal is to get it in one of those formats I guess
[18:32:34 CET] <keegans> the frequency, channel, samples, etc. I can read from the mp4 using libavcodec
[18:33:04 CET] <JEEB> https://ffmpeg.org/doxygen/trunk/structAVFrame.html
[18:33:34 CET] <JEEB> but at least libavfilter seems to be able to handle format changes on the input side. for example if your audio stream decides to switch from stereo to 5.1 and back
[18:33:44 CET] <JEEB> not sure if swresample specifically by itself supports that
[18:33:56 CET] <JEEB> it does have an AVFrame based API so it'd be possible to implement at least
[18:34:20 CET] <cc0> furq: i'm using libxvid
[18:38:24 CET] <keegans> what is the purpose of filters, or where can I read up on them
[18:38:51 CET] <keegans> I am just reading the decoding process so I only need to demux then stream because I don't need to re-encode but it says you may filter after you demux
[18:39:28 CET] <JEEB> well if you need to play you can't exactly feed your audio output coded audio packets, no?
[18:39:31 CET] <JEEB> so decoding is needed
[18:39:33 CET] <JEEB> not only demuxing
[18:39:42 CET] <keegans> I understand the decoding, not the purpose of filtering
[18:39:45 CET] <JEEB> ok
[18:40:00 CET] <JEEB> filtering is when what you receive from input does not fit any hole on the other side
[18:40:24 CET] <JEEB> as in, when you have a use case and you need the stuff to be X
[18:40:41 CET] <JEEB> like, if you need your audio to be stereo, 16bit, 48000Hz, packed
[18:40:56 CET] <JEEB> and you get 5.1, float, 32bit, 44100Hz, planar
[18:41:01 CET] <JEEB> from the decoder :P
[18:41:21 CET] <keegans> what are those properties called
[18:41:43 CET] <keegans> that wasn't a very good phrasing of the question lol
[18:41:55 CET] <keegans> i mean like what is the packed or planar property called
[18:42:26 CET] <JEEB> AVFrame->format (AVSampleFormat)
[18:42:38 CET] <keegans> awesome thanks
[18:42:50 CET] <keegans> ok i get the purpose filtering now too, thank you
[18:42:57 CET] <keegans> lots for me to learn :D
[18:43:15 CET] <JEEB> also nb_extended_buf
[18:43:26 CET] <JEEB> which is then the exact amount of planes you got in the AVFrame
[18:43:52 CET] <JEEB> then channel_layout is basically the layout (stereo, 5.1 ec)
[18:44:10 CET] <JEEB> since for the same amount of channels you can have different things
[18:44:14 CET] <JEEB> 3.0, 2.1 etc for example
[18:44:48 CET] <JEEB> which is why generally you trust channel_layout more than the channel count :)
[18:45:10 CET] <JEEB> if channel_layout is not set then you have a function to help you guess the layout from the channel coun
[18:45:12 CET] <JEEB> *count
[18:46:00 CET] <JEEB> and yea, AVFrame also has sample_rate
[19:36:02 CET] <keegans> I am getting a segfault on av_log?
[19:36:21 CET] <keegans> I just run `avformat_open_input`
[19:38:07 CET] <JEEB> post some code on pastebin or something, and then link here
[19:39:58 CET] <keegans> https://pastebin.com/2vTwJHp7
[19:40:34 CET] <keegans> i guess i need to initialize something?
[19:40:38 CET] <keegans> seems strange
[19:41:18 CET] <JEEB> don't remember if av_register_all() is any more needed
[19:41:49 CET] <JEEB> also oyu need to allocate the AVFormatContext first I think?
[19:41:55 CET] <JEEB> avformat_alloc_context()
[19:42:27 CET] <keegans> ah i am dumb
[19:42:33 CET] <keegans> apologies, now it works
[19:42:40 CET] <JEEB> np
[19:42:59 CET] <JEEB> also I recommend dealing with a copy of FFmpeg with debug symbols while developing
[20:14:23 CET] <keegans> JEEB: ok awesome so I now have a loop which reads all AVPacket from the file -- I am kind of lost now, though. If I want to convert these frames to a `.wav`, what should be next steps be?
[20:14:35 CET] <keegans> I am reading through the transcoder example file but got a little lost
[20:15:00 CET] <keegans> I believe I want to decode them to wav then repackage them into a new AVFormat context I create?
[20:15:12 CET] <keegans> oh and i have to mux them too
[20:17:01 CET] <JEEB> keegans: the first thing you do is handle stream selection. how you exactly do this depends on what you expect your input to be and how much configurability you want to add
[20:17:18 CET] <keegans> it seems I only have one stream
[20:17:23 CET] <JEEB> in this example, yes
[20:17:46 CET] <keegans> it what cases would I have more than one?
[20:18:05 CET] <JEEB> normal a+v stream, files with multiple a/v/s streams?
[20:18:28 CET] <JEEB> also broadcast can have the program index update and thus you gain/lose streams dynamically
[20:18:36 CET] <keegans> I won't ever get a+v, this is only for audio
[20:19:09 CET] <keegans> for now I dont believe I will ever encounter more than one stream, I will just make it error out if I do
[20:19:56 CET] <JEEB> anyways, in this initial state you can just pick/hard-code the stream index you get from the AVPacket
[20:20:24 CET] <JEEB> then as you receive AVPackets you can check the AVFormatContext for what the stream actually is (in this case, AAC)
[20:21:28 CET] <JEEB> basically you can make a function for decoder initialization that takes in AVCodec and AVCodecParameters pointers
[20:22:03 CET] <JEEB> 1) avcodec_alloc_contextX (newest) with the AVCodec pointer
[20:22:18 CET] <JEEB> 2) if you set the parameters, pass them on with avcodec_parameters_to_context
[20:22:26 CET] <JEEB> 3) avcodec_open2
[20:22:31 CET] <JEEB> bam, you have a decoder context ;)
[20:22:46 CET] <keegans> awesome
[20:23:06 CET] <keegans> https://pastebin.com/6bnsxtaQ
[20:23:18 CET] <keegans> ignore the shitty error handling i am just doing this for testing
[20:23:25 CET] <keegans> and i will flesh it out better when i can get it working
[20:23:35 CET] <JEEB> yup
[20:23:58 CET] <JEEB> so yea, at that point you have a decoder available to which you can feed AVPackets and attempt to receive AVFrames
[20:24:03 CET] <JEEB> according to https://www.ffmpeg.org/doxygen/trunk/group__lavc__encdec.html
[20:24:25 CET] <keegans> avcodec_send_packet()  is what i want
[20:24:41 CET] <keegans> then I just call receive_frame in a loop it seems
[20:24:57 CET] <keegans> nice nice
[20:25:00 CET] <keegans> ok let me try to do it now :p
[20:27:59 CET] <JEEB> also lol
[20:28:11 CET] <JEEB> I look at my own local test thing I coded up a year or two ago
[20:28:18 CET] <JEEB> and I so much hated the "read_frame" thing
[20:28:30 CET] <JEEB> I ended up writing a really thin wrapper called read_packet_from_input()
[20:29:38 CET] <JEEB> (granted, in my simple use case I also made it skip all packets that I didn't give a damn about)
[20:31:01 CET] <keegans> #define read_packet_god_damn_it read_frame
[20:31:14 CET] <keegans> and i managed to mess that up
[20:31:34 CET] <keegans> `git blame`
[20:31:43 CET] <keegans> track 'em down
[20:32:41 CET] <JEEB> also I think at this point it's probably a good idea to remind you of time bases, although often audio streams are continuous and thus you can be mostly oblivious of them
[20:32:56 CET] <JEEB> your AVStream will have a time base, on which the AVPackets will recide
[20:33:10 CET] <JEEB> decoders and encoders also have their time bases
[20:33:49 CET] <JEEB> (as in, AVFrames decoded will have pts on that time base and AVFrames fed to an encoder should be on the time base set in the encoder
[20:34:01 CET] <JEEB> same goes for filter chain inputs and outputs
[20:34:29 CET] <JEEB> and output AVFormatContext AVStreams of course have their own time bases
[20:34:33 CET] <JEEB> just something to keep in mind
[20:40:09 CET] <keegans> will do
[20:40:24 CET] <keegans> i am currently having trouble understanding lifetimes in ffmpeg
[20:40:35 CET] <keegans> right now i am following a "if it doesnt segfault it probably works" philosophy
[20:40:42 CET] <keegans> i'll have to correct this at some point
[21:20:21 CET] <ossifrage> This is somewhat off-topic but should I be able to encode an aiff file as flac and then decode it and get the same bits (including headers)
[21:20:52 CET] <ossifrage> I'm using --keep-foreign-metadata but the flac->aiff file is a little smaller then the original
[21:21:07 CET] <ossifrage> (20 bytes)
[21:21:45 CET] <furq> probably not
[21:23:13 CET] <furq> some muxers support -fflags bitexact which ensures two files muxed by ffmpeg will be identical
[21:23:20 CET] <furq> but not that they'll be identical to files muxed by anything else
[21:24:31 CET] <durandal_1707> decoded audio should be same
[21:24:57 CET] <furq> right
[21:25:01 CET] <furq> you can check that with the hash muxer
[21:26:56 CET] <ossifrage> I thought I got it to work ages ago, but I don't have a clue how (or where that data went)
[21:30:33 CET] <furq> are they both big endian
[22:03:36 CET] <ossifrage> It looks like there is one missing tag 'CodecID', it is in the original files and missing from the flac generated ones
[22:03:47 CET] <ossifrage> the original files have it set to 'NONE'
[22:05:10 CET] <furq> yeah that's aiff-c
[22:05:19 CET] <furq> afaik the ffmpeg aiff muxer only does regular aiff
[22:06:44 CET] <ossifrage> ah, yeah my test case came from old aiff files, not the really old ones, so maybe it will work for the 'really old ones'...
[22:07:18 CET] <furq> only regular aiff for big endian, i mean
[22:08:41 CET] <furq> i just tested with little and big endian and the little endian file is 18 bytes larger
[22:08:46 CET] <furq> so presumably that's just the COMM chunk
[22:12:20 CET] <ossifrage> Hmm, the ones from 2001 also have the 20 byte difference.
[22:12:38 CET] <furq> `file` will tell you if it's aiff or aiff-c
[22:12:44 CET] <furq> aiff-c is from the early 90s
[22:13:05 CET] <ossifrage> IFF data, AIFF-C compressed audio
[22:14:00 CET] <ossifrage> Some of the files might have been ripped on an old SGI O2 that I used to use as a media server
[22:40:24 CET] <keegans> JEEB: do I have to worry about this : https://stackoverflow.com/questions/22822515/ffmpeg-resampling-from-av-sample-fmt-fltp-to-av-sample-fmt-s16-got-very-bad-so
[22:40:36 CET] <keegans> the audio file i have is fltp as well
[22:40:44 CET] <keegans> and i wish to convert to s16le
[22:41:14 CET] <JEEB> that's why you need to swresample or libavfilter it
[22:41:18 CET] <JEEB> which I mentioned
[22:41:28 CET] <JEEB> so if you need packed from planar, or just float to int
[22:41:47 CET] <JEEB> it sounds like crap if you do only one of those conversions if you need both, or none
[22:56:03 CET] <keegans> ok so i just destroyed my ears
[22:56:06 CET] <keegans> on the first attempt
[22:57:07 CET] <JEEB> which way did you attempt?
[22:57:10 CET] <JEEB> swresample or lavfi?
[22:57:28 CET] <keegans> swresample
[22:57:31 CET] <JEEB> ah
[22:57:38 CET] <JEEB> yea, that one I haven't utilized to be 100% honest
[22:57:43 CET] <JEEB> but it does have an AVFrame based API
[22:57:49 CET] <keegans> yeah
[22:57:49 CET] <JEEB> so I would hope you can do it
[22:58:07 CET] <JEEB> (the thing originally had a non-AVFrame based API and then people yelled)
[22:58:09 CET] <keegans> well i'll keep at it and figure it out eventually lol
[22:59:35 CET] <JEEB> you can probably peek at af_resample or so, which is the filter that does the resampling in lavfi (using swresample)
[23:00:35 CET] <JEEB> wait what :D
[23:00:40 CET] <JEEB> it's using avresample?
[23:00:43 CET] <JEEB> I don't even
[23:01:28 CET] <JEEB> keegans: there seems to be an example in the examples dir, too
[23:01:34 CET] <JEEB> using swresample
[23:01:54 CET] <keegans> yeah that is what i've been going off of
[23:02:23 CET] <JEEB> and of course it's using the non-AVFrame API?
[23:03:16 CET] <JEEB> I did at some point write a thing that used swresample through lavfi resampling functionality, but I don't have that around.
[23:03:23 CET] <JEEB> and of course ffmpeg.c also does stuff
[23:05:35 CET] <keegans> ok so
[23:05:42 CET] <keegans> i guess im playing it too slow
[23:05:45 CET] <keegans> i really am not sure
[23:06:03 CET] <keegans> i am using SDL to try to play the decoded PCM frames
[23:06:32 CET] <JEEB> dump them to file first and then compare?
[23:06:43 CET] <JEEB> against the expected values in there
[23:07:22 CET] <keegans> ah good idea yeah
[23:07:37 CET] <JEEB> of course it will headerless raw pcm but still
[23:07:51 CET] <JEEB> since I don't think the overhead of adding a muxer there right now is worth it
[23:08:43 CET] <keegans> oh im smart
[23:08:47 CET] <keegans> i fucked up the sample rate
[23:08:52 CET] <keegans> why did i hardcode this in the first place
[23:09:10 CET] <keegans> ok so now it sounds more right
[23:09:56 CET] <keegans> there is a loud hum over what sounds to be the bass and such
[00:00:00 CET] --- Mon Feb 11 2019