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

[burek]

[05:15:37 CEST] <nine_milli> blb
[06:38:35 CEST] <KittyCat> I think I found an issue with libavcodec 58.35.100 (the current version in debian 10). I'm currently building the git version to see if the problem persists, but in the mean time, I figured to ask if it might be (or have been) a known issue
[06:40:07 CEST] <KittyCat> basically, the issue is with some files (some VP9 videos, but not all), avcodec_send_packet and avcodec_receive_frame will both return AVERROR(EAGAIN) in succession, which the documentation says shouldn't ever happen
[06:41:43 CEST] <KittyCat> once avcodec_receive_frame returns AVERROR(EAGAIN), avcodec_send_packet will then succeed, but not before
[06:47:05 CEST] <KittyCat> the general flow in my program is it sends encoded packets until avcodec_send_packet gives AVERROR(EAGAIN), at which point I call avcodec_receive_frame to get a single frame. then it goes back and sends more encoded packets until AVERROR(EAGAIN), then receives another single frame
[06:50:41 CEST] <KittyCat> hoever, I've noticed occasionally, I'll get a frame from avcodec_receive_frame, but the next call to avcodec_send_packet will return AVERROR(EAGAIN), as if there's still more frames to get and not enough space in the codec's internal buffer for another. but the following avcodec_receive_frame call will also return AVERROR(EAGAIN).
[06:51:22 CEST] <KittyCat> once that happens, avcodec_send_packet will accept the packet fine
[07:58:57 CEST] <KittyCat> still happens with latest git
[09:20:49 CEST] <nine_milli> blb
[15:26:43 CEST] <snooky> hi all
[16:25:23 CEST] <kepstin> KittyCat: you need to call avcodec_receive_frame until it returns eagain. it might return multiple frames before accepting more packets
[16:26:52 CEST] <kepstin> KittyCat: that is kinda weird behaviour tho, but it could just be internal state is messaged up because you weren't doing things in the expected order?
[16:30:48 CEST] <JEEB> the dec/enc APIs have been documented rather well
[16:31:12 CEST] <JEEB> https://www.ffmpeg.org/doxygen/trunk/group__lavc__encdec.html
[16:31:24 CEST] <JEEB> so if something is not according to these general ideas, something might be welp
[16:34:49 CEST] <kepstin> the docs do say "the only guarantee is that an AVERROR(EAGAIN) return value on a send/receive call on one end implies that a receive/send call on the other end will succeed, or at least will not fail with AVERROR(EAGAIN)."
[16:34:58 CEST] <kepstin> which seems not to be the case here :)
[16:36:14 CEST] <kepstin> but the recommendation is that apps call the send() function once, then call receive() in a loop until it returns EAGAIN
[16:37:48 CEST] <kepstin> KittyCat: if you have some reproducing code and a sample video, probably worth filing an issue for this.
[17:04:45 CEST] <nine_milli> blb
[18:21:24 CEST] <Polochon_street> Hi! I'm using ffmpeg for audio analysis, and I'm observing very subtle inconsistent results when I decode and resample the same song across different linux distros: I have an int16_t* array of samples, and, for the same song, they vary by usually just one depending on the distro
[18:22:03 CEST] <Polochon_street> the decoding code is here https://github.com/Polochon-street/bliss/blob/master/src/decode.c ; do you think it's ffmpeg-related, and I'm forgetting a rounding argument or something, or it's just platform-specific and nothing can be done about it?
[18:25:58 CEST] <zap0> smells like floating point rounding
[18:26:37 CEST] <zap0> " vary by usually just one"    one what?
[18:27:43 CEST] <Polochon_street> f.ex. p ((int16_t*) song->sample_array)[7] gives 1180 on one distro and 1181 on the other one
[18:34:48 CEST] <kepstin> what input codec and ffmpeg versions are you looking at?
[18:34:53 CEST] <cehoyos> It is very unlikely that the difference you see is due to the "distro"
[18:35:21 CEST] <cehoyos> Possible reasons are different FFmpeg versions, different hardware and different compiler (options)
[18:36:45 CEST] <Polochon_street> the file is mp3, and I'm not using the same ffmpeg version on the different distros
[18:36:55 CEST] <Polochon_street> so I guess that would explain the behavior
[18:37:06 CEST] <kepstin> iirc you might be getting a float vs int mp3 decoder in different versions and setups
[18:37:24 CEST] <cehoyos> You do know that the default mp3 decoder outputs floats (not int16_t)?
[18:37:47 CEST] <Polochon_street> cehoyos: I'm converting whatever I get to `int16_t` as pre-processing
[18:38:09 CEST] <cehoyos> This conversion depends on the hardware, not the distro
[18:38:40 CEST] <Polochon_street> hm, I guess this difference is explained then
[18:38:43 CEST] <cehoyos> But if you are using different FFmpeg versions, this discussion is moot as mp3 decoding is not bit-exact by definition (there is no "correct" output)
[18:38:52 CEST] <kepstin> Polochon_street: also consider trying the "-bitexact" option, which switches some algorithms in ffmpeg from "fasted available on this hardware" to "generic and reproducable"
[18:38:54 CEST] <zap0> Polochon_street which floating point rounding method have you set for your compiler
[18:38:56 CEST] <Polochon_street> thanks for the input :)
[18:39:13 CEST] <kepstin> but i dunno if that'll help in this particular case, especially across a range of ffmpeg versions
[18:39:40 CEST] <cehoyos> There is no *single* correct output, there are many correct outputs for mp3 decoding
[18:39:53 CEST] <cehoyos> (Contrary to h264, hevc etc.)
[18:40:06 CEST] <Polochon_street> so maybe using something with a single correct output for my tests would help? :D
[18:40:18 CEST] <Polochon_street> zap0: whatever CMake use as default for gcc, I think
[18:40:22 CEST] <cehoyos> Maybe using a single FFmpeg version would help
[18:40:41 CEST] <Polochon_street> cehoyos: well, I don't control the ffmepg version used by my users :D
[18:40:45 CEST] <kepstin> a single ffmpeg version in bitexact mode should provide the same results across different hardware.
[18:41:04 CEST] <kepstin> in this case, the differences should be small enough to simply not matter :/
[18:41:23 CEST] <cehoyos> Well, you simply cannot expect bit-exact output for mp3 decoding just as you cannot expect one specific FFmpeg version from your users.
[18:41:54 CEST] <Polochon_street> cehoyos: of course, that's why I'm saying that maybe changing my test file format is a first nice step :)
[18:42:15 CEST] <kepstin> bitexact mode in ffmpeg just means "the same output regardless of hardware", not "a standardized output" :)
[18:42:24 CEST] <cehoyos> (Note that bugs in - for example - flac decoding have been found in the past, so not even for formats that are bit-exact can you be sure that FFmpeg will return the right data)
[18:42:42 CEST] <kepstin> but yeah, probably not worth looking at for this case
[18:43:03 CEST] <Polochon_street> I could use bitexact for testing at least as well, yep
[18:43:16 CEST] <cehoyos> I am not convinced that "bitexact" will fix the issue you see, but you can of course test, it will change some routines that are known to output different data
[18:43:16 CEST] <Polochon_street> thanks for the input guys, much appreciated
[18:43:27 CEST] <kepstin> cehoyos: for testing purposes, your input should really be a lossless format. I would recommend flac if you don't want to store plain wav files
[18:44:00 CEST] <cehoyos> A format that has a "correct" output is sufficient imo
[18:44:07 CEST] <cehoyos> a single correct output...
[18:44:11 CEST] <kepstin> if you want to craft test input with exact sample values, then you can't use a lossy format because it won't preserve the sample values
[18:44:26 CEST] <kepstin> otherwise a lossy format with a defined spec decoder output would work, yes
[18:50:49 CEST] <Polochon_street> kepstin: WAV should do the trick, right?
[18:51:20 CEST] <cehoyos> wav is a fileformat that can take many codecs, for example mp3
[18:51:23 CEST] <kepstin> wav (with pcm audio) would work, but it's kinda big :)
[18:51:53 CEST] <Polochon_street> I have > song.wav: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16 bit, stereo 44100 Hz
[18:52:07 CEST] <kepstin> note also that resampling (sample rate conversion) isn't guaranteed to give the same output between ffmpeg versions either
[18:52:08 CEST] <Polochon_street> I cut the file down to 10s to have a not-too-big file
[18:52:29 CEST] <kepstin> so you'd want to pre-convert to 22050 to avoid having your program do a resample
[18:52:45 CEST] <Polochon_street> good point
[19:08:43 CEST] <nine_milli> blb
[20:12:42 CEST] <glittershark> hi all - I posted on ffmpeg-user too, but figured I'd ask here as well - anyone ever see ffmpeg only return one frame when splitting a multi-minute video?
[20:12:58 CEST] <glittershark> https://lists.ffmpeg.org/pipermail/ffmpeg-user/2019-July/044797.html has my logs
[20:20:31 CEST] <Mavrik> glittershark, you didn't write out your full command-line
[20:20:41 CEST] <furq> it's halfway down the post
[20:20:53 CEST] <furq>   $ ffmpeg -i video.mpg -r 2 -s 640x480 'output/frame_%06d.jpg'
[20:21:38 CEST] <glittershark> yeah, sorry, that text got pretty dense
[20:28:20 CEST] <Mavrik> oh
[20:28:40 CEST] <Mavrik> I have a suspicion that DTS errors might be at fault
[20:29:21 CEST] <glittershark> yeah so do I
[20:29:47 CEST] <Mavrik> Since your timestamps are all over the place
[20:29:48 CEST] <Mavrik> :)
[20:30:16 CEST] <glittershark> yeah >.> it's a pretty wild video
[20:30:18 CEST] <glittershark> VLC plays it though
[20:30:20 CEST] <Mavrik> Can you try reencoding the video to something like h.264 (ffmpeg -i <vid> -codec:v libx264 output.mp4) and see if it's still watchable?
[20:30:50 CEST] <glittershark> will do
[20:32:02 CEST] <glittershark> nope, output.mp4 is .03s long
[20:32:19 CEST] <glittershark> https://pastebin.com/dEtPqqMC
[20:39:49 CEST] <Mavrik> Yeah, it seems that ffmpeg's decoder hates that video then :(
[20:41:12 CEST] <glittershark> dang
[20:41:52 CEST] <zap0> in my experience, MP4 and anything less than 1sec  is a bad combo.  most players do not like it
[20:42:17 CEST] <glittershark> The original video is 3 minutes long
[20:42:21 CEST] <glittershark> it's just... very broken
[20:43:24 CEST] <glittershark> If nobody on the mailing list has any ideas then this is for work, so I'll probably just get approval to throw money at someone on https://ffmpeg.org/consulting.html
[20:43:43 CEST] <glittershark> was kinda holding out hope that someone had run into a video that had this exact problem before though :P
[20:48:24 CEST] <Mavrik> glittershark, the other option is to just use vlc to convert the video to something else
[20:48:29 CEST] <Mavrik> assuming that will repair the timestamps
[20:48:33 CEST] <glittershark> hmm
[20:48:39 CEST] <glittershark> vlc does conversion?
[20:48:55 CEST] <glittershark> oh I guess from the UI
[20:49:00 CEST] <glittershark> wonder if there's a CLI...
[20:49:29 CEST] <Mavrik> there's also cli
[20:49:33 CEST] <Mavrik> cvlc or something
[20:49:42 CEST] <Mavrik> The commandline is pretty arcane, but UI can help assemble it
[20:53:29 CEST] <glittershark> oh great
[20:53:32 CEST] <glittershark> > main video output error: Failed to compensate for the format changes, removing all filters
[20:53:36 CEST] <glittershark> VLC is giving up too
[20:53:41 CEST] <glittershark> it still plays the video though...
[21:05:42 CEST] <zap0> re-film it off the screen!
[21:06:31 CEST] <glittershark> lol
[21:06:37 CEST] <glittershark> xvfb here I come
[21:07:38 CEST] <durandal_1707> -genpts
[21:09:47 CEST] <glittershark> durandal_1707: you mean -fflags -genpts?
[21:10:16 CEST] <glittershark> neither -fflags -genpts or -fflags +genpts work
[21:17:03 CEST] <nine_milli> blb
[21:27:40 CEST] <kepstin> glittershark: also consider trying "-vf fps=2" rather than the "-r 2" output option, the fps filter might have better behaviour here.
[21:28:10 CEST] <kepstin> oh, hmm, probably won't help in this case :)
[21:29:30 CEST] <kepstin> glittershark: hmm, i wonder if it maybe has an editlist? try using the "-ignore_editlist 1" input option. that could explain the weird start time and duration
[21:29:57 CEST] <JEEB> I recommend just disabling the advanced edit list stuff
[21:30:01 CEST] <JEEB> not edit list stuff completely
[21:30:08 CEST] <JEEB> unless the mp4 file is borked
[21:30:28 CEST] <JEEB> -advanced_editlist 0
[21:30:40 CEST] <JEEB> sad that you have to set this stuff, but we can all thank GOOG for it :P
[21:38:45 CEST] <lmat> whoa, ffplay got an overhaul! (command line UI anyway...) Looks good!
[21:49:22 CEST] <glittershark> Disabling editlist didn't help, unfortunately
[21:49:32 CEST] <glittershark> thanks for the suggestion though kepstin + JEEB
[22:14:26 CEST] <cehoyos> glittershark: Please provide your input file
[22:36:57 CEST] <durandal_1707> cehoyos: he can not share private files
[22:37:21 CEST] <cehoyos> Then how is the issue supposed to be fixed?
[22:41:12 CEST] <durandal_1707> cehoyos: clairvoyance
[22:46:51 CEST] <pink_mist> he did say he would probably get approval to throw money at a contributor who presumably would be allowed to see the file after signing enough of his soul away
[22:53:17 CEST] <cehoyos> This does not sound like a smart move to me (but it isn't my money)
[22:53:56 CEST] <pink_mist> you're one of the ones listed under consulting.html aren't you? so it potentially could be your money :P
[22:54:29 CEST] <cehoyos> I doubt it...
[23:40:48 CEST] <Thomas_J> I need to ad a 2 second delay for audio input and "-itsoffset 2"doesn't seem to be working for me. when I add this to the command string, I get silence with a short audio burst at about every 2 second intervals.
[23:42:31 CEST] <durandal_1707> Thomas_J: you probably need adelay filter
[23:46:00 CEST] <Thomas_J> If I use a delay filter on audio input, this won't try to decode the video stream, will it?
[23:47:00 CEST] <Thomas_J> Could I just increase the audio input buffer size?
[23:47:01 CEST] <kepstin> you can filter audio (re-encoding it) while using -c:v copy at the same time
[23:47:24 CEST] <durandal_1707> itsoffset is global for both audio and video last time i checked
[23:47:48 CEST] <Thomas_J> Good. My audio in is a seperate input off of a captyre device.
[23:48:26 CEST] <cehoyos> It is possible that itsoffset does not like "live" input
[23:58:55 CEST] <nine_milli> blb
[00:00:00 CEST] --- Tue Jul 16 2019