September 2019 - Ffmpeg-devel-irc

ffmpeg.log.20190819
by burek 10 Sep '19

10 Sep '19

[05:06:49 CEST] <Henry151> hiya [05:07:07 CEST] <Henry151> I'm trying to use https://termbin.com/od69 this to burn some subtitles from an mkv into an mp4 [05:07:56 CEST] <Henry151> did a lot of my collection already (got all the bitmap subtitle stuff done) but now I forget how to do .srt subtitles. Do I have to pull them out into a .srt file first or is there some way to copy an text-based subtitle stream straight out of an mkv and burn it into an outputted mp4? [05:08:20 CEST] <Henry151> because that attempt seems to not work as it is. [05:10:27 CEST] <Henry151> https://bpaste.net/show/U0ML here's the full paste showing exactly the problems I'm having and what i'm attempting [05:10:35 CEST] <Henry151> any guidance much appreciated :) [05:16:37 CEST] <Henry151> "THUNDERBIRD," Blondie thundered. [05:16:44 CEST] <Henry151> wrong room, oops. [06:24:05 CEST] <pk08> hi [06:24:28 CEST] <pk08> in showvolume filter, volume graph is too fast [06:25:07 CEST] <pk08> and volume values (level) is too low so i am getting small audiobars [06:25:36 CEST] <pk08> is there any way to make slow auidobar speed and higher audio level's value? [06:26:11 CEST] <pk08> filter=: showvolume=w=1080:h=45:o=1:f=1:r=25:dm=1.0:dmc=yellow:v=0 [06:50:12 CEST] <pk08> can we get cc error, sync byte and sync loss error log in ffmepg? of mpegts [06:51:15 CEST] <pk08> durandal_1707? [06:51:19 CEST] <pk08> JEEB? [07:54:38 CEST] <foobar2018> hi [07:58:38 CEST] <foobar2018> I'm trying to take the output of my webcam to stdout, I'm making "ffmpeg -f video4linux2 -input_format mjpeg -s 640x480 -i /dev/video0 aaa.ogv" and I can get the output to a file [07:59:14 CEST] <foobar2018> but if I make "ffmpeg -f video4linux2 -input_format mjpeg -s 640x480 -i /dev/video0 -" or "ffmpeg -f video4linux2 -input_format mjpeg -s 640x480 -i /dev/video0 pipe:0" it says "Unable to find a suitable output format for 'pipe:'" [07:59:22 CEST] <foobar2018> What am I doing wrong? [08:00:05 CEST] <TheAMM> You're not specifying a container [08:00:23 CEST] <TheAMM> Use -f <something> as an output option [08:00:44 CEST] <TheAMM> Depends on what container you actually want [08:02:15 CEST] <foobar2018> TheAMM: " ffmpeg -f video4linux2 -input_format mjpeg -s 640x480 -i /dev/video0 -f theora - " won't even work. [08:02:39 CEST] <TheAMM> Theora is not an output format [08:02:43 CEST] <TheAMM> ffmpeg -formats [08:02:53 CEST] <foobar2018> (sorry I'm not very good at this) [08:02:59 CEST] <TheAMM> Where are you piping the data into? [08:03:08 CEST] <foobar2018> I want to pipe to netcat [08:03:16 CEST] <TheAMM> And netcat pipes it to? [08:04:14 CEST] <foobar2018> to a socket, I think. I want to reply what he does in this video: https://www.youtube.com/watch?v=n4Ul_A0VBVI [08:04:27 CEST] <TheAMM> I meant what is going to consume the data in the end [08:04:48 CEST] <foobar2018> in the other side, vlc [08:05:46 CEST] <TheAMM> He has -f vob in there, look closely [08:06:23 CEST] <TheAMM> mpegts or matroska or maybe nut can work too [08:08:31 CEST] <foobar2018> OK [08:15:24 CEST] <foobar2018> It finally worked, but I seems I cannot open it with vlc [08:17:24 CEST] <foobar2018> nevermind, I missed the "tcp://" at the beginning. Thank you very much. [08:36:36 CEST] <durandal_1707> pk08: lower frame rate and use logarithmic scale? [08:42:15 CEST] <pk08> durandal_1707: ds=1 or ds=log> [08:42:18 CEST] <pk08> ? [08:43:24 CEST] <durandal_1707> log [08:44:22 CEST] <pk08> ok, thanks [09:00:27 CEST] <Fyr> guys, why is all the porn encoded in H264? [09:00:38 CEST] <Fyr> why does nobody use HEVC? [09:01:34 CEST] <Fyr> how about AV1, VP9? [09:02:11 CEST] <Fyr> why are porn producers still in the beginning of 00s? [09:04:24 CEST] <furq> nobody is releasing stuff in av1 and nobody but youtube is releasing stuff in vp9 [09:04:57 CEST] <furq> and nobody wants to release stuff in hevc because of the horrible licensing [09:05:19 CEST] <furq> so you pretty much universally only see it for 4k [09:05:26 CEST] <Fyr> oh [09:05:40 CEST] <furq> it's not vastly better than x264 at 1080p anyway [09:06:57 CEST] <Fyr> wikipedia says that AV1 specification was released a year ago. [09:07:07 CEST] <furq> it sure was [09:14:41 CEST] <another> for the record: netflix is also streaming vp9 [10:48:11 CEST] <snooky> hi all [13:12:01 CEST] <mlok> What is the best way to transcode an Origin RTMP stream that sometimes drops and results in a broken pipe with FFMPEG? [13:15:06 CEST] <BtbN> run ffmpeg in a loop? [13:15:34 CEST] <mlok> Tried that in a while true loop yet when I check on the stream it hangs with no message, seems to work well only with RTSP streams [13:16:16 CEST] <BtbN> "check on the stream"? [13:16:40 CEST] <mlok> I was thinking of perhaps generating a blank continous RTMP stream which would input the RTMP stream when available and when not it would revert to blank again until the stream is restarted, however I am not sure if that is a good way [13:16:47 CEST] <mlok> The script is running in scree [13:16:49 CEST] <mlok> *screen [13:17:09 CEST] <BtbN> You will have to write custom software for that. ffmpeg.c can't do that. [13:17:35 CEST] <mlok> Yeah... [13:17:43 CEST] <mlok> Is it a good idea to run transcoding in screen? [13:17:52 CEST] <JEEB> no. use services or something [13:18:47 CEST] <mlok> Thanks, what about increasing the timeout? I did that with a RTSP stream and it worked when in a while true loop [13:47:11 CEST] <rrva> can I enforce a certain fourcc in a output mp4 file? I want to set the fourcc dvh1 (hevc with dolby vision) [13:49:27 CEST] <BtbN> Does mp4 even use fourcc? [13:52:20 CEST] <rrva> or .mov files [13:52:35 CEST] <BtbN> mp4 and mov is the same thing. [13:52:52 CEST] <rrva> the -tag:v option [14:03:06 CEST] <shroomM> hey [14:04:14 CEST] <shroomM> i'm using ffmpeg to generate a hls output. single file ts, generating the master and the variant playlist [14:04:28 CEST] <shroomM> I want to process everything via pipes. is that doable? [14:05:25 CEST] <pk08> can I get cc errors in ffmpeg log? [14:08:33 CEST] <shroomM> basically 3 files are output - master playlist, variant playlist and the ts file... [15:03:58 CEST] <andrybak> hello, I'm trying to both crop and speed up a very long video. What would be faster? "setpts=0.03125*PTS , crop=717:402:0:0" or "crop=717:402:0:0, setpts=0.03125*PTS"? Or can ffmpeg choose the fastest way automatically? [15:06:52 CEST] <DHE> they're effectively identical [15:06:55 CEST] <Mavrik> andrybak: those two will be equivalent in performance [15:07:15 CEST] <andrybak> Mavrik, DHE thanks [15:07:32 CEST] <DHE> also when you say "speed up", you mean just crank the framerate right? [15:08:32 CEST] <andrybak> I'm going by https://trac.ffmpeg.org/wiki/How%20to%20speed%20up%20/%20slow%20down%20a%20… [15:08:44 CEST] <andrybak> and dropping frames is fine for my case [15:15:05 CEST] <andrybak> and I'm not sure what you mean by "just crank the framerate" [15:15:52 CEST] <Mavrik> Your code is just increasing the fps of the video by a lot [15:24:03 CEST] <andrybak> Mavrik, sounds like that's not what I want. I want to just drop a lot of frames, and play the leftovers at ~same fps. [15:25:01 CEST] <pagerage> Hello, I'm trying to capture both the video and audio of my desktop with ffmpeg using the command featured in the pastebin, the video works perfectly but the sound is not audible. https://pastebin.com/02vNW9jk [16:16:36 CEST] <Henry151> can one of y'all ffmpeg wizards help me get these subtitles to be hard-coded/burnt into the outputting mp4? https://bpaste.net/show/U0ML [16:30:08 CEST] <saml> Henry151, you need to specify subtitle [16:31:19 CEST] <saml> ffmpeg -i a.mkv -filter_complex "subtitles=a.srt" -c:v libx264 -c:a aac a.mp4 [19:23:12 CEST] <Thomas_J> . [19:30:00 CEST] <Thomas_J> I am having trouble getting an audio stream input going. Ive tried all sorts of things unsuccessfully. When I use "-f alsa -i hw:CARD=2,DEV=0" ffmpeg successfully launches but no audio is being input to the stream. I recompiled enabling pulse audio and with "-f pulse -i <tried every device name I could think of> but with this I get "pulse: Input/output error" [19:31:39 CEST] <Thomas_J> The device in question is a USB audio adaptor. [20:33:37 CEST] <rocktop> is there a way to convert video with ffmpeg to have at the end the file size is less than 64Mb ? [20:36:04 CEST] <relaxed> rocktop: look at 2 pass, https://trac.ffmpeg.org/wiki/Encode/H.264 [20:44:39 CEST] <Foaly> hi [20:45:03 CEST] <Foaly> i want to reduce the framerate of a video by blending multiple frames into one [20:45:25 CEST] <Foaly> i've tried tmix followed by framestep, but that is very slow [20:45:54 CEST] <Foaly> multiple tblend,framestep pairs are faster, but is there a better way? [20:47:22 CEST] <BtbN> Are you sure that's a good idea? Usually that looks horrible. [20:48:01 CEST] <BtbN> But nevertheless, putting frames together like that is a very computationally intensive operation, so it's gonna be slow. [20:48:51 CEST] <Foaly> i have rendered an image sequence at 960 fps [20:49:03 CEST] <Foaly> i want to merge 16 frames into one to create motion blur [20:49:48 CEST] <pink_mist> I would expect that to look horrible [20:50:11 CEST] <pink_mist> probably saner to just pick one of the frames and display it for 16 times as long [20:50:45 CEST] <Foaly> it is called sampled motion blur [20:51:24 CEST] <pink_mist> whatever you want to call it, I would expect for it to look awful [20:51:38 CEST] <Foaly> it's how motion blur is made [20:53:13 CEST] <BtbN> But your original question: It's crunching a lot of numbers. Not gonna be fast, ever. [20:53:34 CEST] <Foaly> yes, but the way i do it, it's basically doing too much work [20:53:53 CEST] <Foaly> with the framestep filter, it's just throwing away every second frame [20:55:00 CEST] <Foaly> anyway, it finished encoding, so i guess this doesn't matter anymore [21:00:02 CEST] <Thomas_J> I am having trouble getting an audio stream input going. Ive tried all sorts of things unsuccessfully. When I use "-f alsa -i hw:CARD=2,DEV=0" ffmpeg successfully launches but no audio is being input to the stream. I recompiled enabling pulse audio and with "-f pulse -i <tried every device name I could think of> but with this I get "pulse: Input/output error". The device in question is a USB audio adaptor. [21:12:22 CEST] <rocktop> how to merge and put video logo on other video with ffmpeg .? [21:18:45 CEST] <rocktop> I used this one : ffmpeg -i video3.mp -i title.mov -filter_complex "overlay=(main_w-overlay_w)/2:(main_h-overlay_h)/2" -codec:a copy output.mp4 [21:24:31 CEST] <rocktop> how can I loop title.mov to the length of the video3.mp4 ? [21:26:59 CEST] <rocktop> anyidea ? [21:30:48 CEST] <BtbN> combination of -loop and -shortest [23:46:00 CEST] <rocktop> anyidea ? [23:47:08 CEST] <cehoyos> For what? [23:49:15 CEST] <rocktop> I would like to place the title.mov on the video3.mp4 and loop it to the length of it [23:49:34 CEST] <rocktop> can'tfind a good solution to acheive that [23:52:16 CEST] <rocktop> cehoyos: ^ [23:52:17 CEST] <cehoyos> What did you try? (Command line including complete, uncut console output please.) [23:54:18 CEST] <rocktop> I have a video3.mp4 and I have an alpha video title.mov , I would like to place and repeat title.mov on video3.mp4 [23:54:48 CEST] <rocktop> like watermark [23:55:18 CEST] <Aerroon> there's a loop flag [23:56:13 CEST] <rocktop> I used this ffmpeg -i video3.mp4 -i title.mov -filter_complex "overlay=(main_w-overlay_w)/2:(main_h-overlay_h)/2" -codec:a copy output.mp4 [23:56:46 CEST] <Aerroon> here's how i did it [23:57:04 CEST] <rocktop> this place the title.mov one time I would like to use an option to make it repeating to the length of the video3.mp4 [23:57:26 CEST] <Aerroon> i had a podcast i wanted to upload to youtube [23:57:32 CEST] <Aerroon> so i took the podcast logo and made it into an mp4 file [23:57:52 CEST] <Aerroon> and to quickly create the video file from just the audio file and the logo video i did this [23:58:18 CEST] <Aerroon> ffmpeg -stream_loop -1 -i "logo.mp4" -i "audio.mp3" -shortest -c copy -r 1 "output.mkv" [23:58:27 CEST] <Aerroon> -r 1 is framerate of 1, so you might not want that one [23:58:39 CEST] <Aerroon> -stream_loop -1 makes it loop an infinite amount of times (that's why -shortest is needed) [23:58:54 CEST] <rocktop> Aerroon: so with this I need to dump the audio file from video first ? [23:59:03 CEST] <Aerroon> ???? no [23:59:09 CEST] <Aerroon> i'm just giving an example of a related problem i had [23:59:13 CEST] <Aerroon> you can probably do something similar [23:59:17 CEST] <Aerroon> probably something like [23:59:21 CEST] <rocktop> hmm [23:59:37 CEST] <rocktop> I will try this now [23:59:47 CEST] <Aerroon> ffmpeg -stream_loop -1 -i "logo.mp4" -i "video2.mp4" -shortest -c copy "output.mkv" [23:59:53 CEST] <Aerroon> but i am not sure [00:00:00 CEST] --- Tue Aug 20 2019

1 0

ffmpeg-devel.log.20190909
by burek 10 Sep '19

10 Sep '19

[00:43:28 CEST] <Lynne> here's the new vulkan patches for anyone to test: https://0x0.st/zJ47.patch https://0x0.st/zJ4h.patch [09:57:16 CEST] <cone-595> ffmpeg 03Hendrik Leppkes 07master:4e759b56754a: configure: check for a sufficiently recent enough AMF version [10:04:49 CEST] <cone-595> ffmpeg 03Jun Zhao 07master:a0abcb4a31c3: lavfi/concat: fix logic error in framerate check [11:08:40 CEST] <cone-595> ffmpeg 03Paul B Mahol 07master:7985430c7091: avfilter/vf_v360: factor vector normalization out [11:36:56 CEST] <BtbN> We do not have support for svt vp9, do we? Or rather, any svt encoder. All I see is patches for the hevc one on the ML, but they are untouched for a month. [11:37:47 CEST] <nevcairiel> no i dont think anything of the svt stuff was ever added [11:38:14 CEST] <JEEB> yeh [11:38:26 CEST] <nevcairiel> the code quality was pretty bad when it was initially submitted and fixing took a long time, so by now it probably got a bad reputation :p [11:39:33 CEST] <BtbN> I'd be very interested in the svt-vp9 encoder. Given how horrible libvpx performs. [11:40:22 CEST] <BtbN> There is patches here even: https://github.com/OpenVisualCloud/SVT-VP9/blob/master/ffmpeg_plugin/0001-A… [11:40:40 CEST] <JEEB> yea htey had them in their repos all the time [11:40:57 CEST] <BtbN> A Patch with massive chunks of commented out code [11:41:15 CEST] <nevcairiel> and some hacks in general code [11:46:53 CEST] <BtbN> #define AV_PKT_FLAG_SVT_VP9_EXT_ON 0x10000 // Indicating SVT VP9 frame header ext on [11:46:58 CEST] <BtbN> what? Why not just an option? oO [11:47:46 CEST] <BtbN> The code itself doesn't look too horrible. But everything around it... [14:20:39 CEST] <cone-085> ffmpeg 03Paul B Mahol 07master:976617c7d21e: avfilter/vf_v360: extend stereographic projection [18:07:41 CEST] <cone-453> ffmpeg 03Paul B Mahol 07master:799c07e5c864: avfilter/vf_v360: partialy revert previous commit [18:07:41 CEST] <cone-453> ffmpeg 03Paul B Mahol 07master:0c9e01011b54: avfilter/vf_v360: add guards against NaNs [18:21:43 CEST] <cone-453> ffmpeg 03Andrey Semashev 07master:6d9d053edbed: tests: Fix bash errors in lavf_container tests. [18:21:44 CEST] <cone-453> ffmpeg 03Limin Wang 07master:29bde4b3b6d7: swscale/swscale: delete unwanted assignments [18:41:16 CEST] <cone-453> ffmpeg 03Paul B Mahol 07master:558265d4bc1a: avfilter/vf_v360: add padding to u/v/ker [19:08:34 CEST] <J_Darnley> What is the value in h264 that avcodec stores in "first_mb_addr"? And how does it change with mbaff coding? [19:10:00 CEST] <J_Darnley> It is read in h264_slice_header_parse() [19:10:55 CEST] <J_Darnley> The value is sanity checked with a shift using FIELD_OR_MBAFF_PICTURE [19:11:45 CEST] <J_Darnley> Is it coded as half the value I am expecting? [19:48:32 CEST] <J_Darnley> adjusting my the of it with FIELD_OR_MBAFF_PICTURE does seem to do what I want [21:08:39 CEST] <durandal_1707> test [21:09:25 CEST] <BradleyS> durandal_1707: beep boop [21:22:13 CEST] <BradleyS> /topic version [21:29:16 CEST] <taliho> just saw this today - [21:29:17 CEST] <taliho> https://www.phoronix.com/scan.php?page=news_item&px=FFmpeg-Avformat-ZeroMQ [21:40:38 CEST] <durandal_1707> typical moronix [21:50:36 CEST] <tmm1> what is the correct way to handle H264_NAL_PREFIX in cbs_h264_read_nal_unit [22:07:06 CEST] <Lynne> philipl: are semaphore imports into cuda expensive too? [22:26:33 CEST] <cone-001> ffmpeg 03Aman Gupta 07master:425be35c2648: avcodec/mediacodecdec_common: warn when PTS is missing [22:26:33 CEST] <cone-001> ffmpeg 03Aman Gupta 07master:f821d1953151: avcodec/mediacodecdec_common: improve trace logging for end-of-stream [22:26:33 CEST] <cone-001> ffmpeg 03Aman Gupta 07master:ca613dcc387e: avcodec/mediacodecdec_common: ensure current input buffer is always used correctly [22:26:33 CEST] <cone-001> ffmpeg 03Aman Gupta 07master:d0e676276856: avcodec/mediacodecdec_common: log codec name during configure/start failures [22:26:33 CEST] <cone-001> ffmpeg 03Aman Gupta 07master:35b0e75b545d: avcodec/mediacodec_surface: drop unnecessary local variable [22:48:17 CEST] <cone-001> ffmpeg 03Paul B Mahol 07master:2f071767d9b4: doc/filters: fix typo in v360 [22:57:24 CEST] <philipl> Lynne: probably. I never had a reason to profile it but it would be in-character for them. [22:57:49 CEST] <philipl> I'll try and find some time to try out your latested patches soon. [23:05:17 CEST] <cone-001> ffmpeg 03Michael Niedermayer 07master:9d1e98afeecb: tools/target_dec_fuzzer: Adjust threshold for LSCR [23:12:53 CEST] <cehoyos> https://github.com/Swaraj1998/FFmpeg/commit/7b69e66d [23:13:18 CEST] <cehoyos> The heif student has produced a patch that allows decoding both for advanced library users and for whoever just wants to decode the images. [23:14:06 CEST] <BradleyS> very cool [23:28:47 CEST] <thardin> not all heif variants i presume? [23:30:27 CEST] <thardin> tho that would be neat [23:30:29 CEST] <cehoyos> Not all variants? [23:30:49 CEST] <thardin> heif is a huge standard last time i looked [23:31:09 CEST] <cehoyos> I tested with a few samples that we had [23:31:38 CEST] <thardin> it's not just h26* in isobmff, it supports all kinds of shenanigans [23:31:50 CEST] <cehoyos> Do you have samples? [23:31:59 CEST] <thardin> no i do not [23:32:15 CEST] <cehoyos> (We do not support all shenanigans of many standards) [23:32:24 CEST] <thardin> true [23:32:37 CEST] <thardin> baseline h264 to name one [23:32:41 CEST] <cehoyos> My goal was to support what iDevices produce, that may (or may not) be achieved [23:32:48 CEST] <JEEB> I would be OK with supporting the stuff actually in use in the wild [23:32:51 CEST] <cehoyos> Or j2k or vc1 [23:33:14 CEST] <JEEB> most iDevices are HEVC I think, although it might also output HEIF with JPEG? although I never got a confirmation of that :) [23:35:02 CEST] <thardin> do they use that weird album mode? [23:35:45 CEST] <thardin> like instead of individual files there's support for tossing a whole album into a single file, for some reason [23:38:10 CEST] <JEEB> yes the spec supports all sorts of "interesting" things, but I would only start worrying about things after finding samples [23:38:20 CEST] <JEEB> and I'm fine with starting with the most popular sub-set [00:00:00 CEST] --- Tue Sep 10 2019

1 0

ffmpeg.log.20190909
by burek 10 Sep '19

10 Sep '19

[00:13:10 CEST] <hotbobby> looking for advice to get better quality out of nvenc. example command: ffmpeg -hwaccel nvdec -y -i input.mpeg2 -async 1 -f flv -c:v h264_nvenc -o rtmp://website.com:1935/stream [00:13:38 CEST] <hotbobby> it will sit around 2000 kbit/s and looks pretty bad, but i also heard if you use a profile you can no longer use nvdec [00:13:45 CEST] <hotbobby> just looking for any kind of advice, thanks [00:13:58 CEST] <DHE> well you haven't specified any other options. maybe -b:v 6M or so? [00:14:08 CEST] <DHE> how much bandwidth you got to spare? [00:15:03 CEST] <DHE> also: ffmpeg -h encoder=h264_nvenc [00:15:44 CEST] <hotbobby> i figured without setting a -crf it would use as much as it wanted [00:15:54 CEST] <hotbobby> didnt know you could use help that way either, thanks [00:16:04 CEST] <DHE> nope. otherwise "as much as it wanted" would be equivalent to -crf 0 [00:18:45 CEST] <hotbobby> looks like there are presets specific to h264_nvenc i can try too, thanks for all the help [00:33:57 CEST] <hotbobby> looks like nvenc just looks bad at low bitrates :\ [00:34:20 CEST] <hotbobby> -preset slow -crf 0 will max out at like 3kbit/s from a 14kbit/s stream [00:34:41 CEST] <hotbobby> input and output are both 720p60fps [00:38:10 CEST] <another> 14kbit/s for 720p60 ? [00:40:35 CEST] <hotbobby> 3000kbit/s and 14000kbit/s sorry [00:43:13 CEST] <hotbobby> im transcoding video on a vm and want to preserve cpu usage. i figured nvdec/nvenc would be a good way to do so but there is no comparison to quality of x264 [00:53:45 CEST] <another> depends a bit on the hardware [00:54:29 CEST] <another> recent nvidia cards are apparently quite good [00:55:20 CEST] <another> but afaik they don't reach x264 in terms of compression efficiency [01:08:00 CEST] <hotbobby> interesting, these are gtx970's ill have to try again with a current gen card [01:23:32 CEST] <classsic> Hi, I have this commands https://gist.github.com/Classsic/49b00d4e68dc54a342f54a6cffb0823f and this inputs rtmp://207.246.92.193/copy/1 rtmp://207.246.92.193/copy/2 rtmp://207.246.92.193/copy/3 rtmp://207.246.92.193/copy/4rtmp://207.246.92.193/copy/1 rtmp://207.246.92.193/copy/2 rtmp://207.246.92.193/copy/3 rtmp://207.246.92.193/copy/4 [01:23:44 CEST] <classsic> sorry only 4 inputs rtmp://207.246.92.193/copy/1 rtmp://207.246.92.193/copy/2 rtmp://207.246.92.193/copy/3 rtmp://207.246.92.193/copy/4 [01:24:24 CEST] <classsic> the goal is get perfect sync, if somebody can helpme, or do it, I can pay some beers. :-) [01:44:08 CEST] <markfilipak> ffprobe's calling params are documented, but how about the output? Specifically "23.98 fps, 23.98 tbr, 90k tbn, 47.95 tbc" ...frames per second, but what about the rest? [01:49:12 CEST] <furq> markfilipak: container fps, best-guess codec fps, container timebase, codec timebase [02:02:40 CEST] <markfilipak> furq: Thanks. Is that stuff documented anywhere? [02:06:55 CEST] <markfilipak> Re, ffprobe: Is there any way to learn whether a stream is using constant frame rate or variable frame rate? [02:07:04 CEST] <gtech> I have a digitized film that I didn't align correctly so the bottom of the next(previous?) frame appears at the top of the current frame. Is there a way to fix with ffmpeg? [02:21:05 CEST] <gtech> https://imgur.com/a/b4SgqNe [02:21:14 CEST] <gtech> There's an example of what I'm talking about. [02:29:32 CEST] <nicolas17> gtech: if you copied that top strip into the bottom, would you get the full frame, or is there an extra missing gap? [02:29:48 CEST] <nicolas17> guess I could try it [02:30:05 CEST] <gtech> I mean it'd be a little better [02:30:21 CEST] <gtech> You could do one more edit with removing the black strip [02:30:53 CEST] <gtech> but yeah the idea is just to cut paste the top strip of video to the bottom. [02:31:48 CEST] <nicolas17> I just tried and it doesn't fit at all, unless there's a lot of movement between those two frames? [02:33:25 CEST] <gtech> Oh it must be overly zoomed too. [02:33:30 CEST] <gtech> Derp [02:33:39 CEST] <gtech> Then it's fine w/e. [02:34:08 CEST] <gtech> Thanks for doing that :) [04:28:27 CEST] <Diag> hey im likely about to ask a retarded question [04:28:41 CEST] <Diag> but is there anything obvious that would prevent me from building ffmpeg on a ppc machine [04:34:12 CEST] <furq> no [04:36:40 CEST] <Diag> so i can just grab it and build like normal on linux? [04:37:28 CEST] <furq> sure [04:37:35 CEST] <Diag> hmm. ok [04:37:47 CEST] <furq> the inline asm stuff is all optional and much of it probably exists on ppc anyway [04:37:55 CEST] <Diag> oh nice [04:38:00 CEST] <furq> maybe some external libs won't work, idk [04:38:04 CEST] <furq> all the good ones should though [04:38:07 CEST] <Diag> well, we'll see [04:38:19 CEST] <Diag> I dont expect everything to just go. im mostly interested in just h264 [04:39:11 CEST] <furq> anyone competent will write the whole thing in c and then add asm fastpaths on top [04:39:35 CEST] <furq> anyone competent who cares about other people using their library anyway [04:40:04 CEST] <Diag> see thats the thin yaknow, ya'd hope that because its c, but... [04:40:59 CEST] <furq> "anyone competent" being the operative term [04:41:04 CEST] <furq> always important when you're talking about programmers [04:41:37 CEST] <Diag> heh [04:41:47 CEST] <Diag> random question by the way. has anyone built or ran ffmpeg on a ps3 [04:41:54 CEST] <Diag> totally uh, not related [04:42:34 CEST] <furq> there's some specific asm in ffmpeg for cell iirc [04:42:43 CEST] <furq> for optimisation, not to make it work [04:42:48 CEST] <Diag> i just choked on my salad [04:42:51 CEST] <Diag> theres WAHT [04:43:04 CEST] <furq> idk if it made it in, i just remember seeing it on the ml years ago [04:43:22 CEST] <Diag> *visibly excited* huh well uh, ok [04:44:58 CEST] <furq> can't find it now but there's this [04:45:00 CEST] <furq> https://github.com/FFmpeg/FFmpeg/blob/43b3412631893ca432857304e91d85b953bd5… [04:45:13 CEST] <furq> so i guess it works just fine [04:45:57 CEST] <Diag> i pooped a little [04:46:42 CEST] <Diag> as soon as i finish dumping all the savedata off my ps3 ill drop linux on it and give er a whirl [07:10:40 CEST] <Diag> havent done it yet [07:10:42 CEST] <Diag> soon (tm) [10:20:39 CEST] <YellowOnion> how do I burn a subtitle track in to my video? [10:21:42 CEST] <YellowOnion> all the guides talk about using external files like a .srt file, but I don't have one. [10:24:29 CEST] <furq> if the subs are in the file then use subtitles=input.mkv [10:24:49 CEST] <furq> or if you have image subtitles then use scale2ref and overlay [10:25:02 CEST] <YellowOnion> why can't I just tell it to grab the track directly? [10:25:24 CEST] <JEEB> for image based subs you can, for text based nobody implemented that in ffmpeg.c yet [10:25:47 CEST] <JEEB> that's why you pass the file (like, literally a file containing the subtitle stream) separately to the video filter [10:26:55 CEST] <JEEB> video filters cannot take in AVSubtitles being one of the reasons why you can't just feed those subtitles to a video filter - unfortunately [10:27:09 CEST] <JEEB> video and audio use AVFrames [10:27:10 CEST] <YellowOnion> this is such a pain in the ass... [10:27:41 CEST] <JEEB> do note that as I said, you can use the same video file that contains the suvtitle stream for the subtitle filter [10:27:49 CEST] <JEEB> or you can attempt at making an extension to sub2video [10:27:52 CEST] <JEEB> in ffmpeg.c [10:28:14 CEST] <JEEB> that converts text based subtitles to images for the sub2video part to kick in [10:28:57 CEST] <YellowOnion> it's basically impossible to script this... [10:29:09 CEST] <JEEB> why? [10:29:47 CEST] <YellowOnion> because \ is path seperator on windows. [10:29:49 CEST] <JEEB> you can even specify in the subtitle filter which stream from the input file it is :P [10:30:34 CEST] <JEEB> note: you can use / in Windows as well as far as I know, if that really really is a problem. [10:31:20 CEST] <JEEB> it just means that in filter parameters you have to escape the backslash, just like with other things irrespective of the OS [10:31:44 CEST] <JEEB> (I don't remember how much escaping you would have to do to be honest) [10:31:54 CEST] <YellowOnion> either you add 3 backslashes or you replace \ with / still a pain ;) [10:32:23 CEST] <JEEB> sure, but not especially "impossible to script" [10:32:35 CEST] <JEEB> even with batch, although I feel sorry for you if that's what you've picked [10:32:36 CEST] <JEEB> :) [10:35:58 CEST] <YellowOnion> apparently this doesn't work because ffmpeg doesn't think it's a subtitle stream... [10:43:22 CEST] <YellowOnion> so I guess the next question is how do I convert a mp4 "data" stream to a "sub" stream... [10:44:25 CEST] <JEEB> by implementing the format whatever it may be? [10:44:37 CEST] <JEEB> otherwise it's rather useless unless it can be interpreted [10:44:53 CEST] <YellowOnion> Well it plays fine in VLC [10:45:40 CEST] <JEEB> that still doesn't mean that it isn't just not implemented in VLC? VLC uses its own MP4 parser and it has support for various subtitle formats which people are keeping away from in FFmpeg due to XML etc [10:46:03 CEST] <JEEB> ffprobe -v verbose -i INPUT , if you could post the output of that onto a pastebin or so and link here? [10:47:05 CEST] <YellowOnion> Stream #0:4(und): Data: bin_data (text / 0x74786574) [10:47:06 CEST] <YellowOnion> Metadata: [10:47:06 CEST] <YellowOnion> creation_time : 2013-06-01T16:10:15.000000Z [10:48:25 CEST] <JEEB> http://mp4ra.org/#/codecs [10:48:30 CEST] <JEEB> doesn't seem to know "text" [10:48:47 CEST] <JEEB> if VLC supports it, then its commit history might have hints [10:50:24 CEST] <YellowOnion> I just wanted to bake these subs lol [10:50:57 CEST] <JEEB> welcome to the real world where not everyone has poked your specific thingamajig [10:51:29 CEST] <JEEB> #define ATOM_text VLC_FOURCC( 't', 'e', 'x', 't' ) [10:51:51 CEST] <JEEB> http://git.videolan.org/?p=vlc.git;a=blob;f=modules/demux/mp4/libmp4.c;h=a0… [10:51:55 CEST] <JEEB> right [10:52:08 CEST] <JEEB> it seems to just take it as an alias for the subt/tx3g/sbtl ones [10:52:48 CEST] <YellowOnion> it's a "tx3g" sub format according to vlc. [10:52:51 CEST] <JEEB> although in another nice list it's commented out? (Ž4@) [10:53:00 CEST] <poutine> JEEB: Why is it 0x74786574 when that's literally "t","x","e","t"? [10:53:22 CEST] <ritsuka> "text" is a mov fourcc [10:53:32 CEST] <JEEB> poutine: they're written into the mov/mp4 container that way [10:54:07 CEST] <JEEB> also ATOM_text being commented out here sounds like fun? http://git.videolan.org/?p=vlc.git;a=blob;f=modules/demux/mp4/libmp4.c;h=a0… [10:54:38 CEST] <JEEB> but yes, if it's just another identifier for 3gpp/mov/mp4 timed text [10:54:48 CEST] <JEEB> then just adding it into the mov list should work [10:55:01 CEST] <JEEB> since we have support for that in FFmpeg as a subtitle format :P [10:55:20 CEST] <YellowOnion> can I trick it in to using that without patching the code. [10:57:46 CEST] <JEEB> by making a back-up of the file and binary patching with a hex editor? :P [10:58:09 CEST] <YellowOnion> -tag:d? lol [10:58:22 CEST] <JEEB> works for output I think :P [10:58:28 CEST] <JEEB> if it works for inputs, sure :P [10:58:34 CEST] <JEEB> but think that gets parsed from the container [10:59:31 CEST] <JEEB> also if you mean remuxing I'm not sure if ffmpeg.c would keep the subtitle-related structures [10:59:55 CEST] <JEEB> after all, it doesn't parse the media type or codec type correctly :P [11:00:21 CEST] <JEEB> you could see with something like L-SMASH's boxdumper the byte offsets of the structures and see where the fourcc is located [11:00:31 CEST] <JEEB> if you really want to rewrite the value [11:00:52 CEST] <JEEB> `boxdumper --box FILE > FILE.box.log` [11:09:11 CEST] <YellowOnion> according to mkvtoolnix it's a "chapters" stream and it no longer has subs if I remux it. [11:10:17 CEST] <JEEB> because one of the ways chapters are passed on are as "subtitles" in mp4 :P [11:10:19 CEST] <JEEB> or mov [11:12:55 CEST] <YellowOnion> it would seem more sane to just extract the bitstream and the import it back with the correct fourcc? [11:13:42 CEST] <JEEB> at this point if I knew it was timed text I'd probably just have added "text" into that one list and rebuilt FFmpeg :P [11:14:02 CEST] <JEEB> if not possible, to make sure the file structure was not altered I would have used boxdumper + hex editor to modify a copy of the file [11:14:21 CEST] <YellowOnion> on windows? lol [11:14:39 CEST] <JEEB> yes? [11:14:48 CEST] <JEEB> HxD is my go-to hex editor on windows after all [11:15:10 CEST] <YellowOnion> I mean rebuilding ffmpeg on windows is not quick and painless. [11:15:27 CEST] <JEEB> I dunno, native is slower than in a lunix vm, but nowadays you have WSL etc [11:15:56 CEST] <YellowOnion> WSL? lol [11:16:02 CEST] <YellowOnion> I think you're making my point for me. [11:16:05 CEST] <JEEB> Windows Subsystem for Linux [11:16:50 CEST] <JEEB> YellowOnion: I dunno what your definition of painless is. you can do it natively with a mingw-w64 compiler or MSVC, but then you gain the slowness of shell tools and I/O on windows (because of the antivirus and other reasons) [11:17:12 CEST] <JEEB> and then if you just want to follow some ubuntu or whatever mingw-w64 toolchain tutorial, I mean WSL is there [11:17:24 CEST] <JEEB> the first time setup is always the one part that bites you the most :P [11:17:28 CEST] <JEEB> and anyways [11:17:37 CEST] <JEEB> I did mention the hex editing if compilation is not possible [11:18:08 CEST] <YellowOnion> yeah first time setup is what I mean... [11:20:09 CEST] <YellowOnion> I tried it like a year ago to get opencl working [11:20:44 CEST] <YellowOnion> apparently it was like one extra flag and some header files...but apparenly it's not the default still. [11:22:16 CEST] <YellowOnion> I can probably just fine an srt file online too lol [11:25:00 CEST] <JEEB> would have mostly been interesting to figure out if just interpreting the stream as such would make it work or not. but if you're not interesting in either patching & building OR hex editing a copy of the file (don't touch the original) [12:39:10 CEST] <hero_biz> hi [12:41:54 CEST] <hero_biz> guys, I'm trying to encode a video with x264 codec and resulting file gets too big. But I cannot see any place in video with high complexity with eye at least. I wonder if there is any way to profile complexity of video only? So I can find complex parts of my source which I cannot detect with my eye? [12:53:08 CEST] <BtbN> Use the segment muxer and look at the biggest segments [13:20:53 CEST] <Radiator> Hey all, does libav* have any functions to do any gui programming like opening a window and so on ? [13:21:25 CEST] <ritsuka> no [13:22:03 CEST] <Radiator> Ok, what do you use for the GUI ? I've used opencv2 but it isn't as intuitive as I expected. [13:25:06 CEST] <DHE> normally GUI functions are part of the OS itself. ffmpeg provides video support [13:26:06 CEST] <Radiator> That's what I thought [13:34:26 CEST] <JEEB> Radiator: generally it works the other way. you have a GUI application and then you utilize the FFmpeg libraries to come up with something to render onto that view [14:52:56 CEST] <^Neo> Good morning! Has anyone used a Sencore SDI2X to convert SDI to SMPTE 2110-20/2022-6? [15:12:38 CEST] <Radiator> Is it possible to use CUDA or VAAPI to decode ? [15:45:55 CEST] <^Neo> Radiator - https://trac.ffmpeg.org/wiki/HWAccelIntro [15:49:28 CEST] <BtbN> nvidia does not support nvdec. It's either vdpau or nvdec there. [15:49:43 CEST] <BtbN> You cannot use CUDA itself for decoding, but it's supporting API, nvdec. [15:49:46 CEST] <Radiator> ^Neo: Thanks :) [15:49:59 CEST] <BtbN> *nvidia does not support _vaapi_ [15:50:12 CEST] <Radiator> BtbN: Yeah sorry that's what I meant by saying CUDA [15:50:41 CEST] <Radiator> It's either Intel or Nvidia anyway [15:51:31 CEST] <Radiator> vaapi supporting Intel and nvdec nvidia, right ? [15:51:57 CEST] <BtbN> For just decoding and playing there is no difference between vdpau and nvdec, and vdpau has better player support. [15:52:11 CEST] <BtbN> If this is an Optimus-Laptop, keep in mind that the nvidia GPU most likely has no video de/encoding capabilities. [15:52:26 CEST] <Radiator> BtbN: What do you mean by playing ? [15:52:57 CEST] <BtbN> Well, playing the video? [15:54:05 CEST] <Radiator> Beside decoding a stream to retreive the frame i don't see want to can do more to play the video [15:54:11 CEST] <BtbN> ? [15:54:20 CEST] <BtbN> You play it. To watch it. What else do you want to do with it? [15:54:24 CEST] <Radiator> *I don't see what you can do [15:55:07 CEST] <Radiator> Oooh sorry my mind is stuck on the library not on the ffmpeg or avconv binaries which display the video [15:55:11 CEST] <Radiator> My bad [15:55:20 CEST] <BtbN> They don't oO [15:55:29 CEST] <BtbN> They're cli tools [15:55:40 CEST] <BtbN> Any video PLAYER, that PLAYS the video, makes use of those APIs [15:56:13 CEST] <BtbN> vdpau and vaapi come with a full presentation chain. nvdec does not, unless you do some trickers with mapping things to GL/Vulkan [15:56:45 CEST] <Radiator> I didn't know ! [15:57:12 CEST] <Radiator> I still have a lot to learn about those APIs [17:53:32 CEST] <thnee> I am trying to play an HLS stream with ffplay. It says "Failed to open segment", even though the file works fine? https://dpaste.de/byYJ [17:53:46 CEST] <thnee> I have also verified downloading it with curl and playing it that way, which works just fine. [17:54:20 CEST] <thnee> Even with -logleve trace, ffplay does not provide any information about *why* it thinks it has failed, please help? [17:59:56 CEST] <poutine> thnee: says 0B [18:00:40 CEST] <poutine> [http @ 0x7fa4b8012700] header='HTTP/1.1 200 OK'B sq= 0B f=0/0 [18:39:24 CEST] <thnee> Umm ok.. [18:40:09 CEST] <thnee> poutine: Thanks, but what the heck does that mean? [18:49:24 CEST] <poutine> thnee: sorry I checked the source code and that's actually a reference to something relating to subtitles, ignore my comment [20:17:19 CEST] <leif> Hey, this is probably not the right place to ask, but I don't really know of anywhere better (nor do I really know the right way to ask it): [20:17:52 CEST] <leif> Is there any cheap device that does nothing but forwards an hdmi signal, and doesn't support HDCP. [20:18:13 CEST] <leif> (As in, if a laptop asks if it supports hdcp, it says no.) [20:18:52 CEST] <leif> I ask because apparently mac's like to send an hdcp signal if the target device can support it. [20:19:12 CEST] <leif> Which makes are splitter (and capture ffmpeg script) not work. [20:19:26 CEST] <leif> (For reference, we're just trying to capture presentor slides) [20:19:53 CEST] <leif> Does anyone have any thoughts, or even know of the right place to ask that question? [21:19:43 CEST] <Retal> Hello guys [21:19:43 CEST] <Retal> I am trying get info about UDP stream bitrate info. I see frame size, fps..... [21:19:43 CEST] <Retal> but no bitrate: bitrate: N/A [21:21:15 CEST] <Retal> how to find bitrate info for UDP streams ? [21:47:41 CEST] <SimAV> Hi! I would like ffmpeg to draw a *precise* waveform, i.e. exactly for every video frame the audio that should be played during the presentation of that frame [21:48:33 CEST] <SimAV> I tried with https://ffmpeg.org/ffmpeg-filters.html#showwaves, however I did not get it output one drawn frame per video frame... [21:50:41 CEST] <SimAV> I tried e.g.: ffmpeg -i INPUT.mkv -filter_complex '[0:a] showwaves=r=30 [A]; [0:v] [A] overlay [V] ' -map '0:a' -map '[V]' -b:v 28M -c:v h264_nvenc -f mp4 OUTPUT.mp4 [21:51:17 CEST] <SimAV> as ffprobe INPUT.mkv outputs [21:51:18 CEST] <SimAV> Stream #0:0(eng): Video: vp9 (Profile 0), yuv420p(tv, bt709), 1920x1080, SAR 1:1 DAR 16:9, 30 fps, 30 tbr, 1k tbn, 1k tbc (default) [21:53:38 CEST] <SimAV> but this doesn't deliver even just plausible results... (e.g., some waveform-frames seem to be just a copy of the preceding waveform-frame) [21:54:55 CEST] <SimAV> Does someone in here have an idea how to achieve this? (not necessarily, but preferably using ffmpeg) [21:55:29 CEST] <Atlenohen> Hello [21:55:55 CEST] <Atlenohen> is this still needed for HLS downloads "-bsf:a aac_adtstoasc" [21:56:05 CEST] <Atlenohen> I opened in MVP and it was able to play audio [21:56:16 CEST] <Atlenohen> I guess it's just some compatability with something else, but works on desktop [21:56:49 CEST] <Atlenohen> Oh, I downloaded raw without conversion, it did play raw .TS AAC ADTS normally [21:58:40 CEST] <durandal_1707> SimAV: you know that you would get dupe waveform anyway as that is result of big resolution and frame rate [21:59:48 CEST] <durandal_1707> reduce width of waveform video frame to get exactly unique waveforms each frame [21:59:52 CEST] <SimAV> durandal_1707, what do you mean by dupe waveform? some part of the 'audio frame' being plottet twice? [21:59:59 CEST] <durandal_1707> yes [22:00:27 CEST] <SimAV> Stream #0:1(eng): Audio: aac (LC), 44100 Hz, stereo, fltp (default) [22:00:27 CEST] <durandal_1707> or resample audio to higher sample rate [22:00:38 CEST] <SimAV> so I tried with [22:00:40 CEST] <SimAV> -filter_complex '[0:a] showwaves=mode=p2p:scale=lin:split_channels=0:s=1470x1080:r=30 [A]; [0:v] [A] overlay [V] ' [22:00:55 CEST] <SimAV> as 44100/30 = 1470 [22:01:12 CEST] <SimAV> durandal_1707, but that didn't solve the problem either... [22:02:33 CEST] <SimAV> again, some frames show exactly the same waveform [22:03:43 CEST] <durandal_1707> is overlay video 30 fps? [22:04:26 CEST] <SimAV> as posted above, Stream #0:0 (this is the video) has 30 fps [22:04:59 CEST] <SimAV> and Stream #0:1 (this is the audio) has 44100Hz as samplerate [22:05:37 CEST] <durandal_1707> right. let me try something [22:11:32 CEST] <SimAV> (just in case this should be relevant: I'm using ffmpeg version 4.1.4 on debian buster) [22:13:07 CEST] <durandal_1707> can not reproduce it [22:13:49 CEST] <durandal_1707> with 5.1 48000 audio and higher resolution [22:13:51 CEST] <SimAV> durandal_1707, what command did you use? [22:14:20 CEST] <durandal_1707> my video is not 30 but 24 [22:15:00 CEST] <durandal_1707> i just added fps=30 for video input [22:16:25 CEST] <durandal_1707> im using git version of ffmpeg [22:19:39 CEST] <durandal_1707> the reason you get same frame when overlaying is probably because of overlay filter [22:56:41 CEST] <SimAV> durandal_1707, OK, If i omit the overlay and just render the waveform video, that result seems more reasonable [22:57:55 CEST] <SimAV> if I colorkey the waveform in a second ffmpeg invocation and overlay it over the original video there, it seems as if the wave-form is one frame late [22:59:45 CEST] <durandal_1707> the output of waveform filter always start at 0 [23:00:24 CEST] <durandal_1707> the audio encoder you use may add additional delay [23:01:07 CEST] <durandal_1707> so for intermediate files use lossless audio and video codecs [23:01:18 CEST] <SimAV> durandal_1707, no, the audio tracks are exactly equivalent [23:01:45 CEST] <SimAV> the overlayed waveform ends up one frame later than it should [23:02:31 CEST] <durandal_1707> open bug report with exact steps to reproduce issue [23:03:35 CEST] <SimAV> so in the pure waveform video frame 70 (which shows the audio during original video frame 70) is overlayed over original video frame 71 [23:04:10 CEST] <SimAV> (when using two ffmpeg invocations, first creating the pure waveform video, second colorkeying and overlaying it) [23:04:33 CEST] <SimAV> durandal_1707, Ok, I have to get an example video first, that I can publish... [23:05:15 CEST] <durandal_1707> anyway try latest ffmpeg version [23:09:23 CEST] <SimAV> durandal_1707, ok. I'll do that and be back tomorrow... Thanks! [23:36:28 CEST] <SimAV> durandal_1707, Ok, I just reproduced the problem with current git (558265d4bc) [23:36:51 CEST] <SimAV> anyways, I'll be back tomorrow... [00:00:00 CEST] --- Tue Sep 10 2019

1 0

ffmpeg-devel.log.20190908
by burek 09 Sep '19

09 Sep '19

[02:16:31 CEST] <cone-121> ffmpeg 03Limin Wang 07master:cbc63d61b284: avfilter/vf_scale: split the scale_frame function from filter_frame for activate function support [03:25:43 CEST] <philipl> Lynne: It works, but only for VkBuffers. If you try and call it on memory bound a VkImage, you'll get an error. The end result is that due to ffmpeg only defining the hw format as a cudeviceptr, you still have to do a copy on the vulkan->cuda transfer (cuMemcpy2d from array to device memory). [03:26:54 CEST] <philipl> Technically, we could introduce a second hw format that maps to a cuarray to allow a zero copy transfer, and nvenc now supports cuarrays as input so it would have value, but adding a second hw format for the same hw is weird and would probably be a hard sell. [03:27:01 CEST] <philipl> BtbN certainly doesn't think it's worth it. [03:29:41 CEST] <philipl> Separately, CUarrays don't map well to our AVFrame design. They don't have a direct allocation size and pools work with a size rather than dimensions. I experimented with a CUarray format a few years ago and it was awkward and I never quite got it working. [10:52:57 CEST] <cone-219> ffmpeg 03Paul B Mahol 07master:85386c36e331: avfilter/vf_v360: add aliases for some projections [12:42:12 CEST] <Lynne> philipl: it would be fine, just deprecate the old version along with the old cuda hwaccel which afaik didn't support it [12:53:26 CEST] <BtbN> We're not gonna deprecate the current pixel format... Specially not if the other version has a bunch of known issues and limitations. [12:53:41 CEST] <BtbN> Both hwaccel-decoders, old and new, cannot output arrays either. [12:54:39 CEST] <BtbN> If we'd want to make the nvdec hwaccel output arrays, it would be forced to sync immediately after every frame to copy. Slowing it down immensely. [12:55:07 CEST] <BtbN> The cuvid decoders could output arrays quite easily however. [12:55:14 CEST] <BtbN> Because they make a copy anyway [12:56:45 CEST] <BtbN> I wouldn't block patches that add an Array-Based pixel format, but I feel like others would. [12:57:15 CEST] <BtbN> If we go that route, we also cannot get rid of the CUdevptr based format, simply because that's what nvdec inevitably outputs. [16:54:45 CEST] <cone-564> ffmpeg 03Calvin Walton 07master:3ad5d4df9ce7: lavfi/concat: allow to support inputs with different frame rates [21:09:14 CEST] <cone-564> ffmpeg 03Paul B Mahol 07master:a13b61b7fd05: avfilter/vf_v360: disallow too low h_fov/v_fov [21:09:15 CEST] <cone-564> ffmpeg 03Paul B Mahol 07master:973051e3bd56: avfilter/vf_v360: add stereographic output projection [21:09:16 CEST] <cone-564> ffmpeg 03Paul B Mahol 07master:8a1f0cb9e3a2: doc/filters: update v360 [23:33:15 CEST] <Lynne> seems like intel gpus deal with caching better than nvidia [23:33:37 CEST] <Lynne> a naive avgblur has no performance loss over a caching one [23:33:54 CEST] <Lynne> on nvidia, a caching one is 18% faster [00:00:00 CEST] --- Mon Sep 9 2019

1 0

ffmpeg.log.20190908
by burek 09 Sep '19

09 Sep '19

[02:07:42 CEST] <finalsummer> what is the proper way to fix hls .ts files that give a huge amount of 'Non-monotonous DTS in output stream' errors? [02:08:24 CEST] <finalsummer> ffmpeg -fflags +igndts -i input.ts -codec copy test.ts [02:08:41 CEST] <finalsummer> gives me audio errors and no audio with ffplay [02:08:52 CEST] <finalsummer> [mpegts @ 0x7f1d00000940] start time for stream 1 is not set in estimate_timings_from_pts [02:08:59 CEST] <finalsummer> [mpegts @ 0x7f1d00000940] Could not find codec parameters for stream 1 (Audio: aac ([15][0][0][0] / 0x000F), 0 channels): unspecified sample format [03:45:19 CEST] <finalsummer> https://ffmpeg.org/pipermail/ffmpeg-devel/2018-March/226706.html [03:45:53 CEST] <finalsummer> this patch solved my issue, i am not sure if something similar has been implemented upstream since it was written though [04:47:47 CEST] <T-D> if i want to upload a audio file to http website and i want people to play the audio without saving the file; what is best audio format to use [04:52:20 CEST] <fling> finalsummer: what is the command line you are using? [04:52:39 CEST] <fling> T-D: mp4 [04:54:43 CEST] <pink_mist> T-D: https://caniuse.com/#search=audio%20format has a few different ones, and the corresponding browsers/versions they work in [04:55:09 CEST] <furq> T-D: aac in m4a is the most universally supported [04:55:24 CEST] <T-D> furq ok thanks [04:55:37 CEST] <furq> but if you already have it in mp3 then that's also fine [04:55:42 CEST] <T-D> is m4a different from .mp4 or they are exaclty same [04:55:48 CEST] <furq> they're more or less the same [05:00:23 CEST] <fling> I'm going to try 0001-Introduce-force_dts_monotonicity-to-fix-timestamp-no.patch too [05:04:26 CEST] <FishPencil> Is 4fps normal for vp9 encoding on an i7@4Ghz? I'm only seeing usage around 40% [05:06:11 CEST] <fling> FishPencil: probably yes [05:06:37 CEST] <FishPencil> jeez [05:07:42 CEST] <furq> yeah vpx has terrible multithreading [05:14:40 CEST] <fling> -force_dts_monotonicity does not really help [05:15:26 CEST] <fling> [video4linux2,v4l2 @ 0x55cdfcc8e3a0] Incoming DTS error 200035, offsetting subsequent timestamps by 200035 to correct [05:16:56 CEST] <fling> if 200035 is error number then they are also coming out of order :D [05:17:19 CEST] <fling> also pulse dts are out of order too. Could this mean I have something wrong with my kernel? [05:17:28 CEST] <fling> otoh I tested it on different hosts& [05:30:28 CEST] <fling> JEEB: https://bpaste.net/show/1Em4 [05:31:05 CEST] <fling> JEEB: getting some bad dts in pulse also. Could this mean the muxer is actually bad in addition? :P [09:13:24 CEST] <KodiakIT[m]> OK, couple questions: A) are there particular opts to strip certain (possibly non-standard?) tags from files with ffmpeg, or roughly equivalently, to only preserve certain ones on conversion? B) Is there any way to take multiple videos (namely widescreen and letterbox versions) and encode them in such a way as to then allow a user/the program to choose which video stream to use on playback? [10:31:55 CEST] <finalsummer> -force_dts_monotonicity doesn't 'fix' it since the timestamp on the output is several hours wrong i just realized but i don't get any dts errors after it [10:32:42 CEST] <finalsummer> fling: just ffmpeg -force_dts_monotonicity -i input.ts -codec copy test.ts [10:32:58 CEST] <finalsummer> it fills the screen with messages but there aren't any when decoding it [10:33:09 CEST] <finalsummer> decoding the output file that is [10:45:21 CEST] <fling> finalsummer: is not there any better patch? :D [10:45:36 CEST] <fling> Or should I find one for the kernel? [10:47:41 CEST] <JEEB> fling: I hope you didn't start diving into the whole timestamp issues before figuring out the possible blocking issues :P [10:47:51 CEST] <JEEB> because that was the one that was actually breaking your stream, not this [10:48:14 CEST] <JEEB> and no, I think we pretty much validated with -debug_ts that the non-monotonic timestamps were coming from the lavd device [10:48:20 CEST] <JEEB> I don't know how the *muxer* is at all related [10:48:38 CEST] <JEEB> so either it's your device(s) or the lavd code [11:06:48 CEST] <finalsummer> my file is a captured HLS stream. i have no idea, sorry [11:36:02 CEST] <fling> JEEB: but I also see wrong timestamps in pulse! [11:37:00 CEST] <JEEB> I don't think that's anything new? [11:37:10 CEST] <JEEB> although it could be [11:37:26 CEST] <JEEB> I don't remember the debug_ts output that you posted yesterday by heart [11:39:53 CEST] <fling> I only noticed after patching ffmpeg [11:40:10 CEST] <fling> heads are not for remembering! [11:40:21 CEST] <JEEB> debug_ts had all that info btw. no idea what you patched and where [11:41:56 CEST] <fling> JEEB: this patch https://ffmpeg.org/pipermail/ffmpeg-devel/2018-March/226706.html [11:44:32 CEST] <JEEB> yea, I'm not sure how relevant that is to your case to be completely fair. I really wish you had kept to the one problem first, and then looked into the A/V desync after you had figured out the blocking problem (or what I supposed was a blocking problem) [11:57:08 CEST] <fling> ok [00:00:00 CEST] --- Mon Sep 9 2019

1 0

ffmpeg-devel.log.20190907
by burek 08 Sep '19

08 Sep '19

[00:05:33 CEST] <cone-928> ffmpeg 03Carl Eugen Hoyos 07release/3.2:9b236547f480: lavf/rawenc: Only accept the appropriate stream type for raw muxers. [00:05:36 CEST] <cone-928> ffmpeg 03Carl Eugen Hoyos 07release/3.4:cfa7c079f72b: lavf/rawenc: Only accept the appropriate stream type for raw muxers. [00:05:38 CEST] <cone-928> ffmpeg 03Carl Eugen Hoyos 07release/4.0:4a79f30d774d: lavf/rawenc: Only accept the appropriate stream type for raw muxers. [00:32:42 CEST] <cone-928> ffmpeg 03Michael Niedermayer 07n4.2.1:HEAD: avcodec/qdm2: Check frame size [21:40:14 CEST] <Lynne> philipl: did you say that cuExternalMemoryGetMappedBuffer doesn't work at all? I'm writing the vulkan->cuda interop [21:41:11 CEST] <Lynne> and avframes contain cudeviceptrs rather than cuarrays [22:46:43 CEST] <cone-785> ffmpeg 03Paul B Mahol 07master:a06d70350b2b: avfilter/vf_v360: support transposed input/output [22:46:43 CEST] <cone-785> ffmpeg 03Paul B Mahol 07master:5b12a47e088d: avfilter/vf_v360: add options to h/w unflip input video [23:36:04 CEST] <durandal_1707> i use kitty as terminal emulator now [00:00:00 CEST] --- Sun Sep 8 2019

1 0

ffmpeg.log.20190907
by burek 08 Sep '19

08 Sep '19

[02:04:14 CEST] <cpusage> Hi. I'm simply converted h264 videos to h265 videos, but the ffmpeg instance keeps shutting down by itself during the encode [02:04:24 CEST] <cpusage> any idea why this might be happening? [02:04:46 CEST] <pink_mist> doesn't it tell you why [02:05:29 CEST] <cpusage> I'm running it on cmd (win10) via a batch file I made [02:05:40 CEST] <cpusage> so, the cmd window just shuts off without notice [02:05:51 CEST] <nicolas17> add 'pause' at the end of your batch file [02:07:22 CEST] <cpusage> ah, good idea [02:07:51 CEST] <pink_mist> sometimes I wish there was a ubiquitous 'pause' command on *nix too, rather than having to do a 'read' or suchlike in bash [02:08:50 CEST] <cpusage> just writing out / copy&pasting the ffmpeg command in cmd should also keep the cmd window open [02:09:12 CEST] <cpusage> :') can't believe I didn't think of that [02:09:22 CEST] <tdr> nohup your command so if it closes who cares? [02:09:43 CEST] <pink_mist> tdr: uh, how does that help anything? [02:11:03 CEST] <tdr> or put <ffmpeg commands here>> && do-something-else ... would be the equiv of "wait for it to get done" and something else could be "exit" or "kill -9 -1" [02:11:45 CEST] <tdr> the "lack of pause" ... its not a lack, its the presence of options. [02:12:24 CEST] <pink_mist> tdr: his problem was that ffmpeg kept shutting down abnormally without his console window staying open to show him why [02:12:57 CEST] <tdr> yeah was closing during the encoding, so was it dying? [02:13:10 CEST] <pink_mist> who knows. presumably. [02:13:29 CEST] <tdr> or just closing the cmd window .. its winderz... it prob thought it "knew better" [02:13:40 CEST] <pink_mist> either way, nohup is completely irrlevant, and chaining with && wouldn't work if it didn't exit cleanly [02:14:04 CEST] <pink_mist> I'm not even sure && works in batch [02:14:06 CEST] <tdr> yeah but it also wouldn't close due to idle [02:14:21 CEST] <pink_mist> what [02:14:24 CEST] <pink_mist> that's not a thing [02:14:24 CEST] <tdr> since it would imply "wait for result" [02:14:48 CEST] <nicolas17> what result? [02:15:25 CEST] <tdr> of whether the command completed or died or whatever, the return value to evaluate to see if it does the && part [02:16:07 CEST] <nicolas17> still doesn't help you see the last messages before it closes the window [02:23:21 CEST] <WereCatf> How do I make ffmpeg copy attachments (cover-pictures and whatnot) from input MKV to output MKV? At the moment "ffmpeg -i in.mkv -map 0 -map -0:a:0 -map -0:s:0 -map -0:s:1 -map -0:s:2 -map -0:s:3 -c copy out.mkv" converts those attachments into video-streams, which is not correct [02:26:30 CEST] <nicolas17> why are you selecting audio and subtitle streams? doesn't -map 0 select all streams in the file already? [02:26:59 CEST] <WereCatf> I'm excluding several streams [02:27:22 CEST] <WereCatf> Do notice that they are negative mappings [02:27:30 CEST] <nicolas17> oh I didn't know the - was to exclude, okay [02:51:08 CEST] <another> WereCatf: ffmpeg regard cover art as video [02:51:30 CEST] <another> you can handle it (almost) like any other video stream [02:53:09 CEST] <WereCatf> That doesn't help me in any way or form. Like I said, ffmpeg changes those to video-tracks when they aren't and so they show up in e.g. VLC as new video-tracks [02:53:20 CEST] <WereCatf> The point is that I want any attachments to remain attachments [02:55:02 CEST] <cpusage> hmm... so, it just stops in the middle of a job [02:55:05 CEST] <nicolas17> what's your goal? just discarding some audio/sub streams and leaving everything else intact? perhaps mkvtoolnix is more suitable than ffmpeg idk [02:55:09 CEST] <another> what kind of attachment? just coverart? attached jpeg? fonts? [02:55:19 CEST] <WereCatf> Varying [02:55:38 CEST] <cpusage> continuing from my previous comment, ffmpeg just stops encoding on it's own without any indications of an error [02:56:49 CEST] <cpusage> can't seem to find out why [02:57:59 CEST] <nicolas17> cpusage: could it be running out of memory? [02:58:01 CEST] <another> WereCatf: see: https://ffmpeg.org/ffmpeg-all.html#Stream-selection and https://ffmpeg.org/ffmpeg-all.html#Stream-specifiers-1 [02:58:23 CEST] <WereCatf> another: as you can see, I am using "-map 0 -c copy" [02:58:28 CEST] <cpusage> I got 32GB of memory, so should be more than enough :S [02:58:52 CEST] <another> hold on [02:59:15 CEST] <furq> WereCatf: https://trac.ffmpeg.org/ticket/4591 [02:59:20 CEST] <furq> so i guess in summary just use mkvmerge [02:59:44 CEST] <cpusage> nicolas17 My memory usages doesn't go past 15% [02:59:59 CEST] <WereCatf> I guess I don't have another choice [03:02:00 CEST] <cpusage> even the ffmpeg command I'm running is bloody simple. just can't understand why it would just stop it's process without indicating any errors [03:02:15 CEST] <cpusage> ffmpeg -i input.mkv -c:v libx265 -preset slow -crf 18 -x265-params no-info=1 -c:a copy output_H265.mkv [03:04:58 CEST] <WereCatf> Windows or Linux? If Linux, you could try and see if there's anything in dmesg [03:21:10 CEST] <cpusage> ugh, this is infuriating [03:46:39 CEST] <ssamjh> I'm trying to overlay cfm1.png on top of the RTSP feed. cfm1.png is exactly 1920x1080, so it will fit perfectly onto the output. I believe I need to use -filter_complex, but I'm unsure how to do to, and how to send it to my mapping part. Does anyone have some suggestions? Command: https://pastebin.com/raw/eYej41Tw Output: https://pastebin.com/raw/F05dxmYq [11:28:43 CEST] <fling> Is not there really a trick for dealing with multiple live inputs/outputs? [11:29:41 CEST] <furq> the trick is don't use ffmpeg because it'll desync and/or die on dropouts [11:31:18 CEST] <JEEB> fling: depends on your issues. the FFmpeg API lets you do a lot of things but ffmpeg.c is of course just one API client :P [11:31:54 CEST] <fling> https://www.dacast.com/blog/how-to-broadcast-live-stream-using-ffmpeg/ [11:32:03 CEST] <fling> ^ it looks like it works for other people [11:32:48 CEST] <JEEB> well, ffmpeg.c mostly works for my use cases (kind of fortunately and unfortunately) [11:32:51 CEST] <fling> furq: I tried gstreamer but I'm getting fps followed by seconds of 0fps when muxing aac to a live rtmp stream :> [11:33:19 CEST] <fling> JEEB: I wanted an one-liner, instead of coding in C :> [11:33:27 CEST] <JEEB> everyone wants a one-liner [11:33:35 CEST] <JEEB> nto everyone gets bacon [11:33:49 CEST] <JEEB> do note that I didn't read that article you linked, I'm speaking in generalities :P [11:34:16 CEST] <JEEB> for example, people didn't want to implement dynamic inputs in ffmpeg.c so you have a lavfi filter that takes in multiple inputs. but it can only back up to a fall-back if one dies [11:34:19 CEST] <fling> step 3 in article is ->$ ffmpeg -re -f lavfi -i testsrc -c:v libx264 -b:v 1600k -preset ultrafast -b 900k -c:a libfdk_aac -b:a 128k -s 1920x1080 -x264opts keyint=50 -g 25 -pix_fmt yuv420p -f flv "rtmp://p.ep246802.i.akamaientrypoint.net/EntryPoint flashver=FMLE/3.020(compatible;20FMSc/1.0) live=true pubUser=123456 pubPasswd=789123 playpath=dclive_1_1@246802" [11:34:22 CEST] <JEEB> it will not bring that one back up [11:34:36 CEST] <furq> yeah that's not dealing with live inputs [11:34:42 CEST] <furq> and only one live output [11:34:45 CEST] <furq> that's easy [11:34:57 CEST] <JEEB> yea, although -re can already fail if you have something with discontinuities :) [11:35:18 CEST] <fling> furq: right, it works bad when I add aac, getting distortions in video [11:35:23 CEST] <JEEB> (it kind of works as long as your timestamps go forwards in a normal manner) [11:35:52 CEST] <fling> I'm not even reencoding video, I'm using preencoded h264 stream [11:36:36 CEST] <JEEB> anyways, for a normal live input you want something not like -re because if you have an actual live input, that will not go over realtime [11:36:43 CEST] <fling> what is lavfi filter? [11:36:53 CEST] <JEEB> lavfi is a shorthand for libavfilter [11:37:01 CEST] <JEEB> the library with all the filters in FFmpeg :P [11:37:03 CEST] <fling> will it help me? [11:37:06 CEST] <JEEB> not really [11:37:07 CEST] <fling> oh ok [11:37:52 CEST] <fling> maybe I should try muxing with nginx somehow [11:37:57 CEST] <fling> rtmp -> nginx [11:38:00 CEST] <JEEB> anyways, if you are just stream copying and getting distortions then you're breaking the data somewhere along the way :P [11:38:02 CEST] <fling> aac -> nginx [11:38:06 CEST] <fling> nginx -> rtmp [11:38:29 CEST] <JEEB> also for the record, I've got bad experiences with RTMP, so if you have a basic HTTP setup I'd rather recommend the HLS writer or something over HTTP post [11:38:30 CEST] <fling> Yes, I'm breaking it in the muxer, when adding aac to the stream [11:38:38 CEST] <JEEB> that doesn't make sense :P [11:38:54 CEST] <JEEB> if you are creating a normal AAC stream into FLV that does not break it [11:39:00 CEST] <JEEB> unless the receiving part is broken [11:39:02 CEST] <JEEB> somehow [11:39:09 CEST] <fling> it does break [11:39:14 CEST] <fling> It was always this way for me [11:39:35 CEST] <fling> two live inputs/outputs work just fine [11:39:46 CEST] <fling> adding one more live input or output breaks the muxer [11:40:15 CEST] <JEEB> time to post the exact command lines (although it's OK to hide RTMP credentials etc in the output/input URL f.ex.) and the full terminal logs with -v verbose on a pastebin or so [11:40:18 CEST] <JEEB> and link here [11:40:38 CEST] <fling> need to find it [11:40:45 CEST] <JEEB> give an example of two working, and the broken case [11:40:51 CEST] <fling> tinkered with gstreamer mostly lately [12:09:49 CEST] <fling> JEEB: ok, this is reproducible [12:10:14 CEST] <fling> for rtmp first works, second breaks video stream https://bpaste.net/show/LT0X [12:10:34 CEST] <fling> same issue with pipe output, first works, second breas video -> https://bpaste.net/show/3oUk [12:10:39 CEST] <fling> absolutely the same way [12:11:21 CEST] <fling> limiting input framerate to 15 using `v4l2-ctl -c exposure_auto_priority=1 -d /dev/video0` makes the second work too [12:11:30 CEST] <fling> meaning 30fps might be too much for muxer :> [12:11:33 CEST] <JEEB> ok, that's two inputs and one output. I thought you were talking about two or three outputs. but sure. this shows the actual parts you're using :P [12:11:45 CEST] <JEEB> also no, the muxer should not have random frame rate limitations :P [12:11:57 CEST] <JEEB> now please give a -v verbose log of those working/not working in a similar pastebin [12:12:05 CEST] Action: fling doing [12:12:38 CEST] <JEEB> and yea, the threads probably do nothing in there because you've effectivly got no decoding going on [12:12:59 CEST] <JEEB> you're just receiving *something* from v4l2 and pulse [12:13:16 CEST] <fling> h264 and raw [12:13:32 CEST] <fling> should also try without aac [12:13:47 CEST] <JEEB> I don't think the encoding should have much to do with it at all [12:14:13 CEST] <JEEB> aac is just the encoder you use with flv because everything else it supports sucks [12:14:22 CEST] <JEEB> but yea, more comments after there's some logs [12:15:21 CEST] <JEEB> also I wish all these capture apis could just give you timestamps on a common clock :P [12:15:35 CEST] <JEEB> so that the API user wouldn't have to guesstimate [12:32:29 CEST] <fling> JEEB: https://bpaste.net/show/5BS4 https://bpaste.net/show/TQpm [12:33:26 CEST] <fling> JEEB: first works, second broken, third works [12:34:36 CEST] <fling> second plays for a second, then stalls for a second with h264 artifacts looking like a missing frame [12:35:07 CEST] <fling> if I set `-framerate 30` in third it stalls the same way but without artifacts :> [12:39:35 CEST] <JEEB> > [video4linux2,v4l2 @ 0x556254c45480] Thread message queue blocking; consider raising the thread_queue_size option (current value: 8) [12:40:29 CEST] <fling> Where do I position this option properly? [12:40:51 CEST] <JEEB> it's an input option and specific to the v4l2 module so before that input (and after any other input) [12:41:26 CEST] <fling> >> after any other input >> what? [12:41:35 CEST] <JEEB> if you have any input before v4l2 that is :P [12:42:13 CEST] <JEEB> ffmpeg -i first_input -i second_input output. if the second input is your v4l2 then it goes after first_input but before second_input [12:42:31 CEST] <fling> ok :> [12:42:38 CEST] <JEEB> because if the option was before first_input it would get applied to that input [12:42:49 CEST] <fling> right [12:43:38 CEST] <fling> `-thread_queue_size 9001 -i $video_input \` [12:43:42 CEST] <fling> does not really help ^ [12:43:54 CEST] <fling> the corruption looks the same, I remember trying -thread_queue_size in the past [12:44:15 CEST] <JEEB> well it also seemed to have broken timestamps at least somewhere along the way :P also not sure how big the option should be [12:45:06 CEST] <JEEB> also there's an option at least for v4l2 to set timestamps in the avdevice [12:45:14 CEST] <JEEB> default seems to be "utilize what you get from kernel" [12:45:54 CEST] <JEEB> just because I don't know if `-fflags +genpts` is exactly optimal :P [12:46:13 CEST] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavdevice/v4l2.c;h=446a243… [12:46:17 CEST] <JEEB> the options in the v4l2 module [12:46:24 CEST] <fling> setting it to 1000000 makes no difference, setting it to 1000000000 only works for first, triggering conversion failed for second and third :D [12:46:49 CEST] <JEEB> ah, thread queue size is not even a v4l2 option [12:47:04 CEST] <JEEB> ah it's an ffmpeg.c option [12:47:15 CEST] <JEEB> fftools/ffmpeg.h: int thread_queue_size; /* maximum number of queued packets */ [12:47:26 CEST] <JEEB> so it's some internal queue within ffmpeg.c [12:47:54 CEST] <JEEB> fling: I would possibly recommend checking the output with -debug_ts, it should show you at which point ffmpeg.c is pushing which stream's packets through the chain and how [12:47:58 CEST] <JEEB> and with what kind of timestamps [12:48:15 CEST] <JEEB> it will barf a lot more stuff of course, but you only need to make the issue happen :P [12:48:26 CEST] <fling> this is interesting [12:48:46 CEST] <fling> removing +genpts has some effect [12:49:06 CEST] <JEEB> genpts is a rather crude thing, I think quite often you don't really need it [12:49:09 CEST] <fling> without it second looks like third with fps set to 30 so no corruption [12:49:19 CEST] <fling> but it plays for a second, then stalls for a second [12:49:53 CEST] <JEEB> anyways, -debug_ts probably worth a look even if it logs a lot [12:50:09 CEST] <JEEB> it should show when packets are received and handled by ffmpeg.c and what their timestamps are [12:50:41 CEST] <fling> so I only need to run the second one without +genpts and with -debug_ts right? [12:51:00 CEST] <JEEB> a failing one with it, sure [12:51:04 CEST] <fling> ok [12:51:15 CEST] <JEEB> it will barf a lot since it will output multiple lines for each video/audio frame you get [12:51:40 CEST] <JEEB> so 2> ffmpeg.log might be worth a pre-emptive stderr redirect [12:51:41 CEST] <JEEB> :) [12:52:49 CEST] <JEEB> of course still much less than something like -v debug, which will enable debug logging in all modules xD [12:53:05 CEST] <JEEB> which is why I usually just use -v verbose, since most of the stuff that gets added there is kind of useful [13:00:44 CEST] <fling> JEEB: log -> https://ufile.io/s4p25za3 [13:02:20 CEST] <fling> command https://bpaste.net/show/3BgV [13:02:48 CEST] <JEEB> ok, so whatever is feeding you stuff started with the pts 1417226745970 [13:02:54 CEST] <JEEB> on the v4l2 side [13:03:53 CEST] <JEEB> which then ffmpeg.c takes as the initial offset, and starts the stream at zero [13:04:10 CEST] <fling> What can I do? [13:04:10 CEST] <JEEB> the "demuxer -> " and "demuxer+ffmpeg" lines [13:04:26 CEST] <JEEB> fling: this is still in the phase of interpreting rather than saying good/bad/whatever :P [13:04:39 CEST] <fling> Ok [13:04:51 CEST] <JEEB> ok, your audio starts at 1567853690443172 [13:05:11 CEST] <JEEB> and gets taken as zero [13:08:45 CEST] <fling> tried to search for `ffmpeg "discard" input pts` on the internets [13:09:01 CEST] <fling> the first link is http://www.ffmpeg-archive.org/Copy-capturing-h264-input-while-force-rewriti… [13:09:02 CEST] <JEEB> you don't want that [13:09:13 CEST] <JEEB> fling: well it seems like your input device is giving incorrect timestamps at the very least in the beginning of the stream. if you see the time going a bit backwards after the initial thing. (see the demuxer+ffmpeg stuff) [13:09:37 CEST] <JEEB> or well, you might have to do that but I'm mostly trying to make sure you're not just trying to apply random techniques from the internet :P [13:10:11 CEST] <fling> but this is what I do [13:10:19 CEST] <fling> if this is really the kernel issue [13:10:30 CEST] <JEEB> now the question is, why would the v4l2 device give you suddenly backwards timestamps [13:10:59 CEST] <JEEB> and if there's no good answer to that, you might attempt to check the timestamps/ts AVOption in the v4l2 module [13:11:12 CEST] <fling> omg https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/dri… [13:11:57 CEST] <JEEB> basically I linked you the part of the v4l2 module that has the options [13:12:06 CEST] <JEEB> there's multiple modes for the v4l2 capture module in FFmpeg to poke at timestamps [13:12:13 CEST] <JEEB> the default seems to be "take what kernel gives you" [13:12:18 CEST] <JEEB> which sounds sane enough [13:12:54 CEST] <JEEB> then there's use_libv4l2 which attempts to utilize libv4l2's timestamp functionality on the kernel-returned timestamps [13:13:01 CEST] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavdevice/v4l2.c;h=446a243… [13:13:08 CEST] <JEEB> this is the link to the options, if you missed it [13:14:57 CEST] <JEEB> now do note that you will probably want your other input to have a similar setup for timestamps, even though ffmpeg.c (by default) will make the first timestamp be the "zero point") [13:15:29 CEST] <fling> JEEB: how do I set it on the command line actually? this is new for me [13:15:38 CEST] <JEEB> which? [13:18:30 CEST] <fling> v4l2 mode to poke at timestamps ^ [13:19:24 CEST] <JEEB> basically you know which module you want to apply the option to, and you add a dash at the beginning to it for ffmpeg.c [13:19:45 CEST] <JEEB> ffmpeg.c will attempt to pass options as AVOptions to modules one at a time in the matching position if it doesn't know the option itself :P [13:20:07 CEST] <JEEB> which is a funny proposition if you have an option that has the same name in ffmpeg.c, and then you are attempting to set an AVOption by the same name [13:20:38 CEST] <fling> I'm not getting anything :D [13:21:01 CEST] <JEEB> so when you pass an option to ffmpeg.c [13:21:09 CEST] <JEEB> if it cannot find that named option in itself [13:21:15 CEST] <JEEB> it will take the initial dash out [13:21:37 CEST] <JEEB> and pass the option and the value into various modules applicable as an AVOption until it gets taken in by some module [13:21:55 CEST] <fling> oh [13:21:56 CEST] <JEEB> for example that input_format you're already passing [13:22:04 CEST] <JEEB> that's an AVOption for that v4l2 input module [13:22:11 CEST] <JEEB> you just don't even think about it while using it :P [13:22:19 CEST] <JEEB> for you it's an option for ffmpeg.c [13:27:07 CEST] <fling> JEEB: do I need -ts ? [13:28:16 CEST] <JEEB> no idea: all I can see is that v4l2 is giving you initially backwards-going timestamps, which is why I noted it might be worth while to attempt something like the use_libv4l2 value there. [13:29:34 CEST] <pink_mist> fling: tias - try it and see :P [13:31:12 CEST] <fling> so what would be the command line switch? I really don't understand it [13:31:33 CEST] <JEEB> the option is defined twice, "timestamps" or "ts" [13:31:38 CEST] <JEEB> so it has two names [13:34:19 CEST] <fling> trying passing different values to -ts but see no difference https://bpaste.net/show/eZK0 [13:34:37 CEST] <JEEB> don't use numbers :< [13:34:44 CEST] <JEEB> it has named parameters that I linked to you after all [13:34:52 CEST] <JEEB> *values [13:35:16 CEST] <fling> oh [13:35:20 CEST] <fling> now I see it [13:35:46 CEST] <JEEB> also oooh [13:35:52 CEST] <JEEB> -use_libv4l2 is its own option [13:35:52 CEST] <JEEB> sorry [13:36:01 CEST] <JEEB> not another timestamp mode :P [13:36:33 CEST] <JEEB> so keep away from the ts/timestamps thing, and just do -use_libv4l2 1 (it's a boolean, but 1 should work) [13:39:07 CEST] <fling> same with -use_libv4l2 1 https://bpaste.net/show/E1qi [13:39:35 CEST] <JEEB> did you check how the first N timestamps look like? [13:42:09 CEST] <fling> demuxer -> ist_index:0 type:video next_dts:NOPTS next_dts_time:NOPTS next_pts:NOPTS next_pts_time:NOPTS pkt_pts:1419991608023 pkt_pts_time:1.41999e+06 pkt_dts:1419991608023 pkt_dts_time:1.41999e+06 off:-1419991608023 off_time:-1.41999e+06 [13:42:57 CEST] <JEEB> yea, look up the first N demuxer+ffmpeg things for that input stream [13:43:29 CEST] <JEEB> if the times seem to go backwards [13:43:57 CEST] <fling> https://bpaste.net/show/fTIS [13:44:42 CEST] <JEEB> ok, still goes somewhat backwards :< [13:45:09 CEST] <JEEB> I mean, that's not the end of the world, but it will create a possibly interesting result [13:45:40 CEST] <fling> is is the command fine? ->https://bpaste.net/show/PP-R [13:46:05 CEST] <JEEB> what is your expectation of "fine"? [13:46:22 CEST] <fling> idk [13:46:44 CEST] <JEEB> because at the very least you're just defining thread_queue_size twice, of which probably the last one gets picked [13:47:53 CEST] <JEEB> also as someone who isn't actually running the command or checking anything I have no idea how that actually works for you - keep that in mind [13:49:37 CEST] <JEEB> fling: btw if you still have issues you can attempt to set both v4l2 and pulse to wallclock. for v4l2 that would be -ts abs and for pulse it'd be -wallclock 1 [13:49:46 CEST] <JEEB> I mean, it *sucks* and you *shouldn't* be doing it [13:50:19 CEST] <JEEB> but if the timestamps seem to be awry and seem to be the issue (which I have no idea honestly if they are), that /might/ improve it as long as you don't have b-frames or whatever in your input :P [13:51:03 CEST] <fling> JEEB: same issue https://bpaste.net/show/xP_8 [13:51:21 CEST] <JEEB> what is teh issue at this point? [13:51:38 CEST] <fling> distorted choppy video as always [13:51:49 CEST] <fling> plays for a second then artifacts appear [13:52:30 CEST] <JEEB> that sounds like broken input rather than anything else. are you really sure this works with just the video track? [13:52:37 CEST] <JEEB> because ffmpeg.c itself doesn't touch those packets [13:52:41 CEST] <JEEB> esp. if it is OK at first [13:52:46 CEST] <fling> Yes, works without muxing anything to the h264 stream [13:54:02 CEST] <JEEB> well at that point it's either the input giving you broken stuff because of different timing of requests (v4l2) or there's some buffer within ffmpeg.c that gets filled and new packets don't get put there. but that should be giving you a loud warning/error if that happens. [13:54:19 CEST] <JEEB> ffmpeg.c itself does not bork your packets [13:55:09 CEST] <fling> JEEB: also no issues with non-live output [13:55:11 CEST] <fling> JEEB: https://bpaste.net/show/5G1i [13:55:41 CEST] <fling> so replacing pipe with a file also works [13:56:09 CEST] <JEEB> rtmp is TCP so it could be blocking if the thing you're pushing to is blocking [13:56:21 CEST] <JEEB> but I'm not sure if ffmpeg.c would block on that or if it's as eparate thread [13:56:41 CEST] <JEEB> not sure how ffmpeg.c uses the API in my memory :P [13:57:14 CEST] <fling> Am I out of luck with ffmpeg? Or am I doing it wrong? [13:57:15 CEST] <JEEB> fling: so if you push to a local FLV file it works? same copy for video and -c:aac -b:a 192k or so for audio? [13:57:22 CEST] <JEEB> *-c:a aac [13:57:26 CEST] <fling> I remember trying to fix this three years ago and five years ago too [13:58:30 CEST] <JEEB> I don't have devices that give me video like that, nor do I have a use case for it right now so unfortunately I can't be testing/debugging it for you :P [13:59:28 CEST] <JEEB> fling: also if FLV to a local file works, does output to local HLS segments work? [13:59:40 CEST] <fling> JEEB: sure, any file output works https://bpaste.net/show/xxJP [13:59:50 CEST] <JEEB> ok [13:59:58 CEST] <fling> you can test it with three pipes [14:00:00 CEST] <JEEB> that really sounds like the RTMP TCP transport is what's blocking you [14:00:03 CEST] <fling> three pipes are also broken [14:00:19 CEST] <fling> idk what HLS is [14:00:31 CEST] <JEEB> it's what those CDNs usually output after they ingest RTMP :P [14:00:45 CEST] <JEEB> since I expect you want to push live stream to something that then publishes HLS/DASH from it [14:00:50 CEST] <JEEB> which can then be played from a browser [14:01:01 CEST] <JEEB> (and mobiles) [14:01:18 CEST] <fling> the only issue with file output is audio slightly out of sync and these warnings https://bpaste.net/show/fXdB [14:02:02 CEST] <fling> it should be related to timestamps ^ [14:02:11 CEST] <fling> I've seen this with other devices [14:02:55 CEST] <fling> but file output is broken with three live inputs :P [14:03:11 CEST] <fling> I can't mux three input streams together into a single file [14:04:30 CEST] <JEEB> it's never *that* simple [14:05:26 CEST] <JEEB> fling: and yea it seems like pulse is also going backwards for some strange reason :P [14:05:30 CEST] <JEEB> or wait that's 0:0 [14:05:33 CEST] <JEEB> that is video :P [14:05:50 CEST] <JEEB> so yes, A/V desync might be caused by that [14:06:29 CEST] <fling> it was always exactly _this_ simple to me haha [14:07:25 CEST] <fling> I was able to use only up to two live inputs outputs, it never worked with three for some reason [14:07:25 CEST] <JEEB> and now you can start guesstimating why you at the very least had to add the "live" part there :P [14:07:51 CEST] <fling> what? [14:07:59 CEST] <fling> Unfortunately pipes count as live too [14:08:58 CEST] <JEEB> I'm pretty sure if I make three named pipes and then feed a video file, audio and subtitle file to those, it should output just fine :P [14:09:02 CEST] <JEEB> into a single matroska file with video, audio and subtitles [14:09:19 CEST] <JEEB> this is just a guesstimate of course :P [14:09:49 CEST] <fling> I tried two videos and one sound [14:10:11 CEST] <fling> So what else could I try here? [14:10:23 CEST] <fling> Is it possible to somehow drop few initial frames? [14:10:31 CEST] <fling> together with pts and everything [14:10:31 CEST] <JEEB> anyways, let's try to keep focused on the two live inputs and output file vs output RTMP [14:10:44 CEST] <JEEB> since that seems to be the simplest case where you are having issues [14:10:53 CEST] <JEEB> and on the other side (output to a file) it works [14:10:53 CEST] <fling> rtmp and pipe works the same [14:11:03 CEST] <fling> pipe is easier to test because of ffplay [14:11:22 CEST] <fling> did you noticed ffplay in my examples? :P [14:11:34 CEST] <JEEB> a pipe is probably limited to how quickly the thing reading the pipe is ingesting it [14:11:40 CEST] <JEEB> if ffmpeg.c does blocking I/O [14:11:52 CEST] <fling> should I stop using pipe for testing? [14:12:15 CEST] <JEEB> pipe by itself is probably fine, like piping into a file or whatever :P [14:12:24 CEST] <fling> oh [14:12:27 CEST] <JEEB> anyways, jogging for me to keep myself at least in some way healthy [14:13:10 CEST] <fling> cya [14:20:05 CEST] <fling> furq: how do I drop few input frames? [14:27:49 CEST] <fling> JEEB: artifacts are only at the beginning when reencoding with libx264 [14:28:09 CEST] <fling> right where it is dropping five frames probably [14:28:10 CEST] <fling> `*** dropping frame 1 from stream 0 at ts -5` [14:51:29 CEST] <fling> The whole idea was to _not_ reencode :D [14:53:32 CEST] <fling> Should I use kurokesu instead? :D [15:07:12 CEST] <fling> Should I try this patch? -> https://patchwork.kernel.org/patch/6874491/ [15:10:43 CEST] <JEEB> sounds reasonable at least seemingly fixing the first timestamp > second timestamp issue? [15:10:59 CEST] <JEEB> but I still think your issue might be with something blocking your input if you get actual corruption [15:12:05 CEST] <JEEB> would be probably useful to check how long the calls take and if it seems to block [15:13:08 CEST] <fling> v4l people say the patch is already merged [15:13:20 CEST] <JEEB> ok [15:13:34 CEST] <fling> Also looks like this is a popular known issue with c920 where timestamps go back in time [15:13:51 CEST] <JEEB> but that might only affect a/v desync, not actual corruption tbh [15:14:11 CEST] <JEEB> unless the timestamps lead to AVPackets getting dropped from theo utput [15:14:14 CEST] <JEEB> but it didn't seem to happen [15:14:36 CEST] <fling> With reencoding I always see the same corruption but only at the beginning. [15:14:38 CEST] <JEEB> which means that something is blocking long enough that at 30Hz ffmpeg.c is not calling read_packet often enough :P [15:14:59 CEST] <fling> And sometimes video plays two times slower for few seconds at the beginning [15:15:22 CEST] <JEEB> fling: yes but that seemed to be because at first some input packets got dropped or otherwise derp'd due to the timestamps as video decoding got into the mix [15:15:35 CEST] <JEEB> basically I have a feeling that "copying" might be more affected [15:15:37 CEST] <fling> Right. [15:15:55 CEST] <JEEB> as in, it skips some extra threads etc [15:16:07 CEST] <JEEB> might be bullshit but that's how it feels :P [15:16:15 CEST] <fling> no, it looks like it [15:16:36 CEST] <JEEB> because that's what the results feel like: works for a while at 30Hz but then something borks - and setting frame rate to 15Hz helps [15:16:51 CEST] <JEEB> and of course lowering frame rate gives the application more time [15:17:02 CEST] <JEEB> fling: you might want to rebuild ffmpeg.c with some extra logging with monotonic timestamps [15:17:09 CEST] <JEEB> to get actual stats [15:17:48 CEST] <fling> Can't I tell ffmpeg to drop everything in the input until a keyframe? [15:17:58 CEST] <fling> including pts [15:18:10 CEST] <JEEB> you can patch that in real quickly but I don't think that's the problem? [15:18:28 CEST] <JEEB> if the application is just not keeping up fast enough for the input device [15:19:03 CEST] <fling> but when reencoding everything looks fine after the first keyframe [15:19:06 CEST] <fling> hmm [15:19:17 CEST] <JEEB> that's with decoding and re-encoding [15:19:26 CEST] <JEEB> as I said that probably has different threading and other things [15:19:30 CEST] <JEEB> so don't mish-mash them too much :P [15:19:31 CEST] <fling> right [15:19:33 CEST] <fling> ok [15:21:01 CEST] <JEEB> I recommend you add logging on going into and out of functions that call av_read_frame (effectively, in the beginning and end of input_thread since you have threads) [15:21:04 CEST] <JEEB> and then write_packet [15:21:38 CEST] <JEEB> write_packet has multiple returns so you might have to add logging where that function is called from [15:22:06 CEST] <JEEB> then when you get entry and exit av_log lines there you should know how long those operations take and all [15:23:07 CEST] <JEEB> apparently av_gettime_relative might be monotonic depending on the OS [15:23:44 CEST] <JEEB> seems like on linux it should be? [15:26:57 CEST] <JEEB> something like av_log(NULL, AV_LOG_VERBOSE, "[%"PRId64"] -> write_packet\n", av_gettime_relative()); [15:27:25 CEST] <JEEB> you can then also add input file/stream indexes to it etc [15:31:30 CEST] <fling> hmm [18:46:05 CEST] <fling> JEEB: < pinchartl> with the hw timestamps disabled, the timestamps are generated in software, it shouldn't have anything to do with the hardware [18:46:09 CEST] <fling> Is it a kernel bug then? [18:47:48 CEST] <fling> can't it be caused by libv4l somehow? [18:47:52 CEST] <fling> going to try disabling it [00:00:00 CEST] --- Sun Sep 8 2019

1 0

ffmpeg-devel.log.20190820
by burek 07 Sep '19

07 Sep '19

[01:33:00 CEST] <BtbN> Using video hwaccel with the latest AMD Windows driver is a Bluescreen Minefield, holy hell. [01:34:50 CEST] <thardin> such is the penalty for using restricting software [02:09:20 CEST] <juandl_> Is Nicolas George here? [02:22:15 CEST] <jamrial> juandl_: no, he doesn't use irc [02:25:55 CEST] <cone-290> ffmpeg 03Limin Wang 07master:eccb94c3babc: lavf/hlsenc: fix one warning: unused variable 'filename' [-Wunused-variable] [02:59:26 CEST] <cone-290> ffmpeg 03Jun Zhao 07master:f36925201c59: lavf/hlsenc: free the old_filname to avoid memory leak [03:23:42 CEST] <juandl_> jamrial: ah, thanks anyway [03:46:46 CEST] <cone-290> ffmpeg 03Steven Liu 07master:939c17fcb33f: avformat/hlsenc: remove unuse comment of the code [03:58:23 CEST] <cone-290> ffmpeg 03Steven Liu 07master:3708a2a90991: avformat/hlsenc: reindent code [04:10:55 CEST] <cone-290> ffmpeg 03Jun Zhao 07master:df6876d69172: lavfi/af_adeclick: fix double free after ff_filter_frame fail [04:10:56 CEST] <cone-290> ffmpeg 03Jun Zhao 07master:f156f4ab2317: lavfi/avfiltergraph: add check before free the format [04:10:57 CEST] <cone-290> ffmpeg 03Jun Zhao 07master:1b0a8e48f1d7: lavfi/dnn/dnn_backend_native: fix memory leak in error path [06:25:58 CEST] <durandal_1707> michaelni_: vp8 is broken, see above ticket [07:39:57 CEST] <cone-422> ffmpeg 03Zhong Li 07master:f115a2b7635d: lavc/qsvdec: add function ff_qsv_map_picstruct() [07:39:57 CEST] <cone-422> ffmpeg 03Zhong Li 07master:f3dfd34f27ae: lavc/qsv: make function qsv_map_fourcc() can be called externally [07:39:57 CEST] <cone-422> ffmpeg 03Zhong Li 07master:00d0a4aa9eda: lavc/qsvdec: Replace current parser with MFXVideoDECODE_DecodeHeader() [07:39:57 CEST] <cone-422> ffmpeg 03Zhong Li 07master:0dfcfc5096d7: lavc/qsvdec: remove orignal parser code since not needed now [07:39:57 CEST] <cone-422> ffmpeg 03Zhong Li 07master:7555cfd29b71: lavc/qsvdec: Add mjpeg decoder support [07:39:58 CEST] <cone-422> ffmpeg 03Zhong Li 07master:655ff4708bfe: lavc/qsvdec: Add VP9 decoder support [07:39:58 CEST] <cone-422> ffmpeg 03Zhong Li 07master:d252d1c2e987: lavfi/scale_qsv: change alignment to be 16 bytes [08:11:42 CEST] <cone-422> ffmpeg 03Zhong Li 07master:74e6800381a2: lavfi/qsvvpp: disable pass through mode if format changed [10:25:21 CEST] <kierank> durandal_1707: do not question important fuzzing work [10:28:24 CEST] <thardin> please report to nearest fuzzing reeducation facility [10:28:46 CEST] <kierank> lol [12:09:33 CEST] <durandal_1707> cehoyos: make sure g729b is not better name than acelp.kelvin [12:10:18 CEST] <cehoyos> G.729b is a bad name for this codec imo, or do you see any indication that G.729b has a leading byte with additional information? [12:10:35 CEST] <cehoyos> Afaict, G.729B allows network transmission to signal silent frames [12:10:58 CEST] <durandal_1707> consult specifications [12:11:10 CEST] <cehoyos> That's what I did but I may have missed something [12:11:22 CEST] <durandal_1707> have link? [12:18:57 CEST] <cehoyos> I read something when I looked into ticket 7604 but cannot find it atm [12:21:52 CEST] <cehoyos> To say it differently: It seems more likely to me that 7604 (where the sample contains no frame that is longer than ten bytes) is G.729B than the sample from ticket 8081 [12:22:25 CEST] <JEEB> sounds like fun formats when they can't be proper discerned from each other :/ [12:22:28 CEST] <JEEB> *properly [12:22:42 CEST] <cehoyos> The TwoCC does not claim G.729B, only the dll [12:22:51 CEST] <cehoyos> The TwoCC entry does not claim G.729B, only the dll [12:23:01 CEST] <cehoyos> Maybe the dll can do both.. [12:23:32 CEST] <cehoyos> And maybe the leading byte can also signal silence [12:24:52 CEST] <cehoyos> https://tools.ietf.org/html/rfc3551#section-4.5.6 clearly speaks of "two octets" to signal silence [12:32:40 CEST] <durandal_1707> wrong specs [12:44:04 CEST] <durandal_1707> https://www.itu.int/rec/T-REC-G.729 [12:48:33 CEST] <cehoyos> Does it specify eleven-byte frames for G.729B? [12:49:37 CEST] <durandal_1707> im on phone cant look [14:16:11 CEST] <durandal_1707> cehoyos: name is ok [14:16:22 CEST] <cehoyos> Thank you [14:29:38 CEST] <durandal_1707> please, someone apply v360 set from me! [15:19:03 CEST] <durandal_1707> cehoyos: how can it hurt FFmpeg? [15:21:56 CEST] <durandal_1707> cuurently it never returns last frame [15:22:08 CEST] <durandal_1707> for vfr [15:22:27 CEST] <durandal_1707> eg case when last frames are same [15:29:33 CEST] <Heisenberg> Hi ! I want to design a system in which a video is streamed under a given condition determined in a bsf filter, how could I drop packets (filtered as non relevant) and still be able to decode the non filtered packets at the receiver ? (H.264 videos and using the ffmpeg streaming feature) [15:38:16 CEST] <J_Darnley> So you want to do 2 actions with incomping packets, right? [15:38:38 CEST] <J_Darnley> Filter and retransmit? And decode? [15:40:20 CEST] <kierank> stream under a given condition [15:40:23 CEST] <kierank> what does that mean [15:41:00 CEST] <Heisenberg> The bsf would only filter the relevant packets and I would stream or save to a file the outgoing stream. The issue is about "not dropping necessary infromations for decoding" so being able to play the video at the end. [15:41:54 CEST] <Heisenberg> A condition that I would implement like "if motion" -> stream it otherwise -> save bandwidth [15:43:59 CEST] <nevcairiel> with complex codecs like h264, its not necessarily that easy to just drop arbitrary packets just because nothing changes - unless you encode it in a particular (less efficient) way. On the other hand, if you encode it very efficient, then the bandwidth during times of no motion would be extremely small anyway [15:50:58 CEST] <Heisenberg> That is what I tried to do even if it is less efficient : defining a specific fps and gop so that I am sure to include the corresponding key frame when transmitting any predicted frame, so the packets would not really be drop arbitrary but "gop by gop" [16:28:38 CEST] <J_Darnley> Am I going to have to install wine just to use HxD? [16:28:50 CEST] <J_Darnley> Why isn't there a good hex editor on linux? [16:29:22 CEST] <JEEB> bless is the one I utilized, but I didn't like it as much as HxD :< [16:29:36 CEST] <JEEB> there's some payware one, but I've not tested it on lunix [16:32:52 CEST] <J_Darnley> I've just tried ghex [16:33:08 CEST] <J_Darnley> I made a selection to delete some bytes [16:33:14 CEST] <J_Darnley> and it deleted 1 [16:33:19 CEST] <J_Darnley> 1! [16:33:39 CEST] <J_Darnley> Not thw whole selection, the 1 byte I ended the selection at [16:34:12 CEST] <durandal_1707> pay more [16:34:23 CEST] <J_Darnley> Maybe I should [16:34:38 CEST] <J_Darnley> Do you have a recommendation? [16:38:40 CEST] <durandal_1707> my software i have yet to write :) [16:38:56 CEST] <J_Darnley> :) [16:39:37 CEST] <J_Darnley> I will add: no electron [16:41:55 CEST] <BtbN> KDE has a nice Hex Editor iirc [16:45:26 CEST] <kierank> J_Darnley: i used to use bless [16:46:18 CEST] <durandal_1707> KDE ? [16:46:55 CEST] <JEEB> khex was it? [16:47:06 CEST] <durandal_1707> i think you could use radare2 [16:48:08 CEST] <kierank> durandal_1707: never managed to use that thing [16:48:21 CEST] <J_Darnley> I tried it once too and was in way over my head. [16:49:30 CEST] <durandal_1707> you just use visual modr [16:49:39 CEST] <durandal_1707> *mode [16:50:14 CEST] <durandal_1707> its little more complicated than vi/vim [16:52:27 CEST] <durandal_1707> once you learn basics you starting to be excelent in it, not for simple minded people [16:53:01 CEST] <kierank> too complex for J_Darnley, he is simple man :) [16:53:18 CEST] <J_Darnley> Indeed. Basic vim usage is my limit. [16:53:19 CEST] <kierank> he likes beer and guns [16:53:28 CEST] <J_Darnley> *cider and guns [16:53:44 CEST] <durandal_1707> gums* [17:45:25 CEST] <BtbN> https://www.reddit.com/r/Amd/comments/cqfdm8/psa_adrenaline_1981_has_bsod_f… hrm, "fun" [18:49:09 CEST] <durandal_1707> kierank: please if you can apply my v360 set [18:53:20 CEST] <kierank> Later yes [18:55:36 CEST] <durandal_1707> is lego saturn finished? [19:11:22 CEST] <durandal_1707> here is more music for your fuzz fest: https://m.soundcloud.com/fuzz-me/overgame [19:17:59 CEST] <durandal_1707> https://www.usenix.org/conference/usenixsecurity19/presentation/jung [19:18:19 CEST] <durandal_1707> here you can learn how to beat fuzzer [19:38:37 CEST] <durandal_1707> michealni: you are a truly dictator, your way or no way at all [19:53:04 CEST] <BradleyS> "please report to nearest fuzzing reeducation facility" [19:53:10 CEST] Action: BradleyS gives thardin a cookie [19:55:22 CEST] Action: durandal_1707 gives a fuzz [20:42:53 CEST] <thardin> :] [22:09:26 CEST] <durandal_1707> kierank: when to expect it? [22:11:43 CEST] <kierank> Have to eat dinner [22:11:48 CEST] <kierank> Was in pub [22:13:49 CEST] <kierank> durandal_1707: seems Michaelni has sent me what he would call an "ad-hominem" [22:15:00 CEST] <durandal_1707> that reply or private one? [22:16:10 CEST] <kierank> public reply [22:17:58 CEST] <durandal_1707> it happens to the best, even with good intentions [22:18:17 CEST] <kierank> I replied [22:18:37 CEST] <durandal_1707> never reply [22:19:28 CEST] <kierank> yes I know, it's playing into michaelni_ game [22:19:34 CEST] <kierank> where he argues you all the way so you give up [22:19:37 CEST] <kierank> same with nicolas [22:20:09 CEST] <kierank> but arguments for frame doubling are not comparable to dropping frames that fuzzed files decide not to decode [22:24:08 CEST] <durandal_1707> it breaks final frame... amd appears to have more cases in codebase [22:26:02 CEST] <durandal_1707> this is for timeout which was not even measured [22:27:31 CEST] <durandal_1707> and still fuzzer should use reference counting, but im afraid that would kill most of highly valuable work over timeouts [22:33:28 CEST] <kierank> Yes my concern is breaking other codecs, slippery slope [22:40:48 CEST] <jamrial> i thought there was a patch to reintroduce the final frame dropped by accident? [22:44:18 CEST] <jamrial> durandal_1707: re refcounting, avcodec_send_packet() ensures it's refcounted internally, before it gets to the decoder [22:44:21 CEST] <jamrial> why would it matter what target_dec_fuzzer.c does? [22:58:05 CEST] <kierank> durandal_1707: is urgent to push patch [22:59:02 CEST] <durandal_1707> why? [22:59:18 CEST] <kierank> i might sleep [22:59:33 CEST] <durandal_1707> go play with lego? :) [22:59:40 CEST] <thardin> maybe I've been foolish in planting the idea that one could do smart things when identical frames are output [22:59:49 CEST] <thardin> instead of the stupid and simple thing [23:00:47 CEST] <durandal_1707> kierank: fuzz is more urgent [23:00:50 CEST] <kierank> durandal_1707: go watch japanese cartoons [23:01:19 CEST] <durandal_1707> will i [23:02:16 CEST] <thardin> ah right repeat_pict already exists [23:04:13 CEST] <thardin> but only works if you know the picture repeats in advance [23:04:49 CEST] <jamrial> so as kierank said, based on metadata coded into the bitstream [23:05:33 CEST] <BtbN> Am I missing the issue at hand, or could a decoder keep a refernece to the buffer of the last frame it returned, and re-use it when it's a duplicate? That way it's still cfr, but avoid the memory allocation bomb. [23:06:30 CEST] <thardin> that's what cinepak ends up doing at least [23:07:09 CEST] <jamrial> and what ff_reget_buffer is for, afaik [23:07:18 CEST] <thardin> turn on references, decoding speeds up ~1000x on fuzzed input [23:07:53 CEST] <BtbN> Oh, so the issue is that the fuzzer does not use refcounting, and thus will get a copy made no matter what? [23:08:01 CEST] <thardin> yes [23:08:12 CEST] <thardin> and michael thinks this is an issue for some reasoon [23:08:15 CEST] <BtbN> That's pretty dumb [23:08:25 CEST] <thardin> so every decoder then needs ugly checks to bail out early [23:08:33 CEST] <BtbN> We should deprecate and discourage non-ref-counted frames more aggressively [23:08:43 CEST] <thardin> but of course you can make files that avoid those checks and still decode to an identical frame [23:09:40 CEST] <thardin> I think in theory at least it could be useful to signal that a frame didn't change. then users can turn cfr into vfr if they wish [23:10:04 CEST] <BtbN> Can it even detect those cases? [23:10:15 CEST] <thardin> I'd like to see someone actually wanting that first, instead of coding for theoretical use cases [23:10:20 CEST] <thardin> BtbN: for meny codecs you can [23:10:40 CEST] <thardin> fli, gif, cinepak at least. I think all the mpeg codecs have stuff for that too [23:10:47 CEST] <BtbN> I mean, sure you can detect a clear duplicated frame. But if it's specifically crafted to not appear duplicated, but decode to the same data nevertheless? [23:11:09 CEST] <thardin> yeah [23:11:53 CEST] <thardin> I think we should have an actual use case, preferably some free software project. else it's probably a waste of effort [23:21:45 CEST] <thardin> uhm this "sane number of channels" thing feels quite arbitrary [23:23:08 CEST] <thardin> I've used .wav to store radio IQ data at a few MHz, and it could certainly be used to transport channelized data at similar rates [23:23:28 CEST] <thardin> with many many channels [23:31:37 CEST] <jamrial> durandal_1707, BtbN, thardin: so making target_dec_fuzzer.c refcount its packets before passing them to libavcodec in its loop would help with these timeouts [23:32:15 CEST] <BtbN> non-refcounted frames are deprecated, right? [23:32:34 CEST] <jamrial> yeah [23:32:36 CEST] <BtbN> So fuzzing them seems like a waste of time. Not like there is nothing else to work on. [23:33:11 CEST] <BtbN> Specially with how many things it reports, and what a mess it potentialy makes all over the whole codebase... [23:33:17 CEST] <jamrial> ok, will try to implement that [23:33:43 CEST] <jamrial> if it makes bogus timeout reports disappear and helps people calm down, i'm for it [23:33:59 CEST] <BtbN> Why is it even NOT doing that? Just an oversight, or is it intentional? [23:34:38 CEST] <thardin> michael wrote something about wanting to simulate what a user program would do [23:34:47 CEST] <thardin> like that user programs will process the frames [23:34:53 CEST] <jamrial> it's using the old decode api, which accepts non refcounted packets, despite being discouraged [23:34:59 CEST] <thardin> but that doesn't help us make lavc nice and fast [23:35:36 CEST] <thardin> I'd be in favor of using refcounting only in that fuzzing program [23:36:07 CEST] <thardin> and maybe revert or at least look over all these timeout patches to see if they still timeout with refcounting enabled [23:38:03 CEST] <BtbN> The other big issue with fuzzing is how every single thing it reports is treated as security bug, and thus only handled by a very small circle of people. [23:38:10 CEST] <thardin> it certainly doesn't make sense trying to optimize for the older api [23:38:25 CEST] <BtbN> imo it should be separated from the security list, and get its own, more accessible or even public list [23:41:09 CEST] <jamrial> BtbN: lotharkript offered to do that, i think [23:41:41 CEST] <thardin> some timeouts are a bit more important tho, like in lavf since that would make ffprobe slow [23:42:27 CEST] <BtbN> Sure, there will still be timeouts, and a lot of them will be valid issues. But eliminating a whole class of timeouts that are not actual issues [23:42:37 CEST] <lotharkript> jamrial: i'm ok to make the bugs closes only for Security, but some timeout could be a infinite loop. In this case, every one will see it. [23:43:38 CEST] <lotharkript> but if there is something to chang ein the target_dec_fuzzer.c to make most timeout gone, please do [23:44:07 CEST] <thardin> the class of "oh if I make a 65000x1000 file then it takes time to process!" is definitely silly [23:45:45 CEST] <lotharkript> should we have then per codec a max resolution and/or max pixel per frame? [23:45:52 CEST] <lotharkript> so we can abort faster? [23:46:05 CEST] <thardin> a max resolution in the ffmpeg cli could be useful [23:47:21 CEST] <thardin> say if a stream changes resolutions, which is something ffprobe wouldn't catch [23:48:32 CEST] <jamrial> the fuzzer already sets 16mp as max frame size [23:52:02 CEST] <BtbN> An infinite loop should be somewhat easy to detect though, shouldn't it? [23:52:10 CEST] <BtbN> Compared to a two or ten second slowdown [23:52:55 CEST] <BtbN> I can see a point in not making all the fuzzing results public, same as it is with the static analysis ones. [23:53:27 CEST] <BtbN> It should be more like coverity, where everyone who is known gets access easily. [23:57:51 CEST] <BtbN> Speaking about Static Analysis. michaelni_, can you cancel the "current" builds analysy? It's been stuck for a while now again. [00:00:00 CEST] --- Wed Aug 21 2019

1 0

ffmpeg-devel.log.20190906
by burek 07 Sep '19

07 Sep '19

[00:00:35 CEST] <rcombs> well yes, the kernel closes all of a process's fds when it exits [00:00:43 CEST] <rcombs> (and then the P-state returns to normal) [00:01:09 CEST] <BtbN> So it's only an issue if you have a long running process that sometimes uses nvenc/cuda? [00:01:12 CEST] <rcombs> but I want to allow the GPU to return to a low-power state while my app's still running, after I've finished using it for something [00:01:14 CEST] <rcombs> right [00:01:35 CEST] <rcombs> which is a bit edgy, I suppose, so I'm not especially surprised it's buggy [00:01:47 CEST] <BtbN> For nvidia contacts, just search ffmpeg-devel for the last mails froms @nvidia.com and send it to the last 2 people or so. [00:02:17 CEST] <rcombs> I'll give that a go, thanks [00:02:41 CEST] <BtbN> ygupta(a)nvidia.com used to be our usual contact, but I haven't heard from him in a while. [03:15:03 CEST] <tmm1> what is the correct way to handle H264_NAL_PREFIX in cbs_h264_read_nal_unit [04:26:46 CEST] <cone-896> ffmpeg 03Steven Liu 07master:6c593fee6335: avformat/http: add ff_http_get_shutdown_status api for check the status of shutdown [04:26:46 CEST] <cone-896> ffmpeg 03Steven Liu 07master:f267a2ac9c74: avformat/hlsenc: avformat/hlsenc: reopen new http session for http_persistent [06:30:33 CEST] <cone-896> ffmpeg 03Steven Liu 07master:07b4bf5f11e4: avformat/hlsenc: move the warning message from every segment upload to init part [06:30:34 CEST] <cone-896> ffmpeg 03Steven Liu 07master:fe77cad3a412: avformat/hlsenc: fix code style [06:47:42 CEST] <cone-896> ffmpeg 03Steven Liu 07master:db92a3e4630f: avformat/hlsenc: fix compiling error of hlsenc [09:10:29 CEST] <VenomFK> Hi, I am planning a to add a new hardware based filter in ffmpeg. Is there any documentation which can guide me things to take care while adding a new hardware based filter? [09:12:57 CEST] <JEEB> thre's a few of them now for various hwaccel-related things [09:13:06 CEST] <JEEB> not sure if they're standardized between themselves [09:14:40 CEST] <VenomFK> I have some propriety tool which performs some post processing on the raw data, which I want to integrate in ffmpeg for ease of my usage [09:18:42 CEST] <JEEB> anyways, see stuff like cuda or opencl or vulkan etc under libavfilter [09:19:39 CEST] <VenomFK> Thanks [09:49:57 CEST] <Radiator> Hello erveryone. I have a question on the libav and mpv. For my work I have to decode a video stream from a camera as fast as possible (as close as I can to >50ms). To do so I had an example from my superior from mpv : mpv --no-cache --untimed --no-demuxer-thread --vd-lavc-threads=1 udp://224.0.1.1:10001/ [09:51:25 CEST] <Radiator> So I browsed the source code of mpv which is quite a maze and couldn't find anything as like which library call is used etc... [09:52:17 CEST] <Radiator> Do you have by any chance an idea on how to recreate the behavior of mpv with no cache, untimed, and no demuxer thread ? [09:52:50 CEST] <JEEB> I think it's all based on libavformat protocol and format options so you should be capable of [09:52:56 CEST] <JEEB> it's not magic, after all [09:53:11 CEST] <JEEB> by default libavformat favours some amount of buffering for stability [09:53:56 CEST] <Radiator> Great I'll give it a shot ! [09:54:50 CEST] <Radiator> Another thing (might be wrong channel tho) mpv is using libav or not ? It says they use ffmpeg but ffmpeg is libav from what I understand [09:55:26 CEST] <JEEB> it uses the libav* libraries whichever you built against :P if you built mpv against FFmpeg, then FFmpeg's libav* libraries [09:56:38 CEST] <Radiator> Ooooh I see, in the end it only depends on the building process. [09:56:55 CEST] <Radiator> Well, thank you JEEB [09:57:36 CEST] <JEEB> also this stuff probably is more relevant towards the user channel, since development is development within the FFmpeg project, not utilizing it :) [09:58:23 CEST] <Radiator> Oh my bad, I thought it was dev in general [10:40:43 CEST] <cone-306> ffmpeg 03Sourabh Sharma 07master:3424600e0b19: doc/filters: correct range for contrast in eq filter [11:46:54 CEST] <JEEB> VenomFK: can I politely request you to not privately message me unless absolutely required? [11:47:13 CEST] <VenomFK> Sure, apologies [14:07:55 CEST] <durandal_1707> fate have drastically reduced in number of machines [14:11:46 CEST] <cone-306> ffmpeg 03Paul B Mahol 07master:28dfa1e37169: avfilter/vf_v360: rewrite storing of remap positions and interpolations [14:11:47 CEST] <cone-306> ffmpeg 03Paul B Mahol 07master:32dd429bc735: avfilter/vf_v360: stop using floats in interpolation [14:11:48 CEST] <cone-306> ffmpeg 03Paul B Mahol 07master:f0d8005ec5be: avfilter/vf_v360: add asserts to guard against invalid conditions [14:11:49 CEST] <cone-306> ffmpeg 03Paul B Mahol 07master:058bbf48c6ba: avfilter/vf_v360: x86 SIMD for interpolations [14:11:50 CEST] <cone-306> ffmpeg 03Paul B Mahol 07master:d13154144500: avfilter/vf_v360: reduce allocations by reusing duplicated remaps [14:11:51 CEST] <cone-306> ffmpeg 03Paul B Mahol 07master:cb8c353032ab: avfilter/vf_v360: add option to pick rotation order [17:48:02 CEST] <cone-306> ffmpeg 03James Almer 07master:2200cf1acaf0: x86/vf_v360: make remap{1,2}_8bit_line_avx2 work on x86_32 [17:48:03 CEST] <cone-306> ffmpeg 03James Almer 07master:4857688732e2: x86/vf_v360: use a faster horizontal add in remap4_8bit_line_avx2 [21:20:24 CEST] <jamrial> cehoyos: do you intend to push "lavf/rawenc: Only accept the appropriate stream type for raw muxers"? [21:20:43 CEST] <cehoyos> I'll do it tonight, I was away for two days. [21:21:10 CEST] <jamrial> ok [21:21:12 CEST] <cehoyos> In the future, please feel free to push patches you believe should be applied. (I have done it in the past) [21:21:31 CEST] <JEEB> oh, so sticking random stuff through rawvideo etc wasn't a meant feature? :) [21:22:01 CEST] <jamrial> it should make it to 4.2.1, so ok, i'll push and backport it in a minute [21:23:17 CEST] <JEEB> I recently used it to dump subtitle packets into separate files with the segment muxer :) but I guess that just means that it should be "rawdata" or so for unknown stream types instead of "rawvideo" or so :) [21:23:50 CEST] <cone-928> ffmpeg 03Carl Eugen Hoyos 07master:aef24efb0c1e: lavf/rawenc: Only accept the appropriate stream type for raw muxers. [21:26:00 CEST] <cehoyos> Sorry: Do you understand that I feel pissed now? [21:26:08 CEST] <cone-928> ffmpeg 03Carl Eugen Hoyos 07release/4.2:1dec90d45656: lavf/rawenc: Only accept the appropriate stream type for raw muxers. [21:27:28 CEST] <JEEB> I didn't mean to make you pissed :< sorry. because I think your change is correct. I was just misusing a tool that I noticed being there. [21:27:28 CEST] <jamrial> cehoyos: i'm sorry? [21:27:57 CEST] <cehoyos> You asked me if I will commit the patch, I answered that I will do it and started doing it and you committed the patch. [21:28:16 CEST] <cehoyos> I wonder now if you did that on purpose only to make my life more difficult [21:28:41 CEST] <jamrial> you said you'd do it tonight, then told me to feel free to push patches that should be applied [21:28:50 CEST] <cehoyos> Yes, "in the future" [21:29:07 CEST] <jamrial> since michaelni_ apparently plans to tag 4.2.1 before tonight, i went and pushed it so it may make it to the release in question [21:29:08 CEST] <cehoyos> And I did wonder since you wrote that email why you didn't push it [21:29:32 CEST] <jamrial> it was not my intention to make your life more dificult. i just wanted that fix committed on time for the release [21:29:39 CEST] <cehoyos> ok, sorry [21:30:45 CEST] <cehoyos> Note that it is of course no fix but a work-around that is often called a "hack" [21:31:38 CEST] <cehoyos> JEEB: Did you read the commit message? [21:32:24 CEST] <JEEB> only the part that was mentioned/logged on IRC. I'll go read the full one on gitweb if you think I misunderstood it [21:32:35 CEST] <JEEB> ahhh [21:32:36 CEST] <JEEB> ok [21:32:40 CEST] <JEEB> roger that [21:35:16 CEST] <durandal_1707> relax, be happy [21:36:02 CEST] <JEEB> well, I did note that I would consider the change to be correct even if rawvideo would only take in video AVStreams :) [21:36:13 CEST] <JEEB> given that after all, it says "video" [21:36:41 CEST] <JEEB> me pushing unknown or subtitle AVStreams into it would be the part I would consider being a "hack" given its name :) [21:37:23 CEST] <JEEB> so no real unhappiness regarding that vOv [21:37:58 CEST] <durandal_1707> you can still use -f u8 [21:38:36 CEST] <JEEB> I did find it cute that if you knew the right incantation with the segment muxer you'd get a csv with the timestamps and file names of segments, and then the packets dumpe [21:38:39 CEST] <JEEB> *dumped [21:39:55 CEST] <JEEB> lets you then parse the csv and validate that the timestamps of the entities within the samples (because someone decided that whole XML documents should be samples, with timing inside of course) are as you'd expect [21:41:03 CEST] <JEEB> also I noticed someone wanted to add extra stream support into webvtt muxer just because instead of doing HLS with the HLS muxer he wanted to use the segment muxer. that was interesting [21:41:27 CEST] <JEEB> although the webvtt support in the hls muxer is kind of weird since it seems like the master playlist support never thought of it [21:41:40 CEST] <JEEB> might poke that if I have the time to add subtitle streams into the master playlist as well [21:41:46 CEST] <jamrial> nevcairiel: your msvc fate clients haven't run in like two weeks [21:52:16 CEST] <durandal_1707> it is end [21:52:42 CEST] <durandal_1707> no more fate machines [21:54:08 CEST] <kepstin> i could put fate on my amd k6-3 box, but i'm not sure that would be particularly useful ;) [22:07:41 CEST] <cone-928> ffmpeg 03Michael Niedermayer 07master:722fd4696583: avcodec/vorbisdec: fix FASTDIV usage for vr_type == 2 [22:07:42 CEST] <cone-928> ffmpeg 03Linjie Fu 07master:ef1342650f97: swscale/output: fix some code indentations [22:07:43 CEST] <cone-928> ffmpeg 03Limin Wang 07master:ede15bf2e359: avfilter/vf_showinfo: display GOP timecode side data [22:29:55 CEST] <cehoyos> jamrial: I cannot reproduce with clang either. [22:30:53 CEST] <jamrial> cehoyos: i only have gcc and can't reproduce it [22:31:05 CEST] <cehoyos> ... after testing with gcc [22:31:08 CEST] <cehoyos> first [22:31:15 CEST] <jamrial> so i does sound like a bug in whatever version of clang he's using [22:31:34 CEST] <cehoyos> I already spent far too much time on an invalid ticket;-( [22:37:02 CEST] <durandal_1707> cehoyos: do not be angry [22:41:29 CEST] <iive> the sign at the end indicates sadness, not anger. afaik [22:45:44 CEST] <cone-928> ffmpeg 03Michael Niedermayer 07master:413e0f2516ee: avcodec/vc1_pred: Fix refdist in scaleforopp() [22:45:45 CEST] <cone-928> ffmpeg 03Michael Niedermayer 07master:55d4e22d71ca: avformat/vividas: check for tiny blocks using alignment [22:45:46 CEST] <cone-928> ffmpeg 03Michael Niedermayer 07master:12b909ba319d: avcodec/qdm2: Check frame size [23:38:51 CEST] <cone-928> ffmpeg 03Michael Niedermayer 07release/4.2:ee89d9e3d6ee: avcodec/apedec: Fix 32bit int overflow in do_apply_filter() [23:38:52 CEST] <cone-928> ffmpeg 03Michael Niedermayer 07release/4.2:6c583ec9bdcc: avcodec/iff: Check for overlap in cmap_read_palette() [23:38:53 CEST] <cone-928> ffmpeg 03Michael Niedermayer 07release/4.2:5b44aec196e6: avcodec/vorbisdec: fix FASTDIV usage for vr_type == 2 [23:38:54 CEST] <cone-928> ffmpeg 03Michael Niedermayer 07release/4.2:d3b45f137882: avcodec/vc1_pred: Fix refdist in scaleforopp() [23:38:55 CEST] <cone-928> ffmpeg 03Michael Niedermayer 07release/4.2:5a1e0cae2f78: avformat/vividas: check for tiny blocks using alignment [23:38:56 CEST] <cone-928> ffmpeg 03Michael Niedermayer 07release/4.2:e66d4725c718: avcodec/qdm2: Check frame size [23:38:57 CEST] <cone-928> ffmpeg 03Michael Niedermayer 07release/4.2:1529dfb73a51: Update for 4.2.1 [23:55:06 CEST] <cone-928> ffmpeg 03Carl Eugen Hoyos 07release/4.1:60094fc2f552: lavf/rawenc: Only accept the appropriate stream type for raw muxers. [00:00:00 CEST] --- Sat Sep 7 2019

1 0

ffmpeg.log.20190906
by burek 07 Sep '19

07 Sep '19

[03:12:19 CEST] <jarred> can someone help me with the correct filter_complex incantation? https://gist.github.com/Jarred-Sumner/6e5a7c3eb80f7d01c0cd19fa04c55644 [06:39:14 CEST] <pk08> can anyone please correct CC error logic in libavformat/mpegts.c (https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/mpegts.c#L2627) [06:39:47 CEST] <pk08> because i see error msg in ffmpeg but not in other analyser [06:40:27 CEST] <pk08> and ffmpeg shows CC error even when tss->last_cc == cc [06:41:58 CEST] <pk08> and according to DVB standard H.222, tss->last_cc and cc can be same [08:42:04 CEST] <dwqq> hello guys [08:42:35 CEST] <dwqq> ffmpeg -f lavfi -i anullsrc -rtsp_transport tcp -i ${RTSP_URL} -tune zerolatency -vcodec libx264 -preset medium -crf 24 pix_fmt + -c:v copy -c:a aac -strict experimental -f flv ${YOUTUBE_URL}/${YOUTUBE_KEY} -nostdin -nostats 2> frames.log & [08:43:22 CEST] <dwqq> i am using the command above to stream to youtube channel, how can i set 480p and remove sound? [08:43:39 CEST] <dwqq> there is no sound at all [10:43:08 CEST] <Radiator> Hi, does anybody knows what would be the equivqlent of this line : mpv --no-cache --untimed --no-demuxer-thread --vd-lavc-threads=1 udp://224.0.1.1:10001/ [10:43:27 CEST] <Radiator> using ffmpeg instead of mpv [10:44:14 CEST] <JEEB> see what options mpv sets and mimic that [10:44:29 CEST] <JEEB> also I think the untimed option just disables vsync, so it just reads as fast as possible [10:47:20 CEST] <Radiator> Yeah that's what I saw from the documentation. The no-cache also forces goes alonf with no-demuxer-thread which helps to go even faster. The decoding on a thread helps too. I just can't figure out how to replicate that behavior with ffmpeg or ffplay [12:29:56 CEST] <lain98> kepstin: because vfr [12:30:28 CEST] <lain98> how does av_seek_frame/avformat_seek_file behave with vfr files ? [12:30:46 CEST] <JEEB> just fine if the container is indexed [12:31:01 CEST] <JEEB> like, you could just take the "VFR" part out of the equation [12:31:08 CEST] <JEEB> like, if you have a horribly VBR MPEG-TS mux [12:31:19 CEST] <JEEB> it will fsck your seeking up even without VFR [12:31:36 CEST] <JEEB> which is why I have noted that indexing on the container level is the only way to get frame-exact results [12:31:47 CEST] <lain98> ok but another problem. my application's purpose is to extract based on frame numbers [12:31:49 CEST] <JEEB> you don't have to decode, just index on the container level which is mostly IO [12:31:54 CEST] <JEEB> yes [12:31:59 CEST] <JEEB> I wonder why you still haven't utilized ffms2 [12:32:11 CEST] <JEEB> that gives you access on frame level after indexing [12:32:36 CEST] <lain98> theres a flag avseek_flag_frame which doesnt work for me in vfr [12:33:07 CEST] <lain98> because i want to decode through my app [12:33:29 CEST] <JEEB> ffms2 is a C++ library with A C API utilizing FFmpeg APIs [12:33:32 CEST] <JEEB> so you can use it in your app, yes [12:33:54 CEST] <JEEB> anyways, I think I'll stop at this point. I probably sound annoying as hell since you probably have a Very Good Reason not to look at ffms2 [12:48:25 CEST] <lain98> JEEB: will ffms allow me to use nvdec ? [12:49:01 CEST] <JEEB> I don't remember; if not it sounds like contributing to it might be the less hard way out [12:49:11 CEST] <JEEB> but what do I know [12:51:13 CEST] <lain98> my only reason for not using ffms is perf [12:51:45 CEST] <lain98> i did look into ffms source code [12:52:11 CEST] <lain98> and they do a lot of stuff that i dont want to waste cycles for [12:53:50 CEST] <JEEB> as far as I remember it's 99% I/O indexing rather than CPU cycles. CPU only comes up when decoding or if you have audio enabled at all [12:54:16 CEST] <JEEB> but sure. in any case, enjoy implementing something that sounds very similar yourself [13:23:01 CEST] <lain98> :( [13:25:50 CEST] <sopparus> hello, im trying to restream a ts stream to m3u8, it mostly works [13:25:55 CEST] <sopparus> but sometimes stutters [13:25:57 CEST] <sopparus> i can see this [13:25:59 CEST] <sopparus> [http @ 0x55a8355f0700] Will reconnect at 84386208 in 0 second(s), error=End of file. [14:57:15 CEST] <sfan5> why can't ffmpeg handle 16384x16384 pngs? [14:58:29 CEST] <Radiator> It could giving proper parameters. But that vary large! [14:58:51 CEST] <durandal_1707> because it takes 4gb memory [14:59:27 CEST] <sfan5> Radiator: unfortunately imgutils refuses to [IMGUTILS @ 0x7ffd5868a5c0] Picture size 16384x16384 is invalid [15:00:37 CEST] <Radiator> Not suprising given the size of the picture [15:01:59 CEST] <pink_mist> durandal_1707: why is it a problem that it takes 4GB of memory? with 64bit operating systems that's no longer a limit ... and most people these days will have quite a bit more available than that [15:02:28 CEST] <DHE> it also means that any offset variables need to be 64 bit as well [15:02:48 CEST] <durandal_1707> and it is fuzz problem [15:03:27 CEST] <xdudi> after call this command: ffmpeg -i 'rtsp://....' -c:v copy -c:a copy -f rtp rtp://127.0.0.1:12345 I expected that ffmpeg will open a port but netstat doesn't show it. what did I wrong? [15:03:28 CEST] <pink_mist> DHE: oh, you mean that PNG internal offsets are 32bit? [15:03:48 CEST] <sfan5> uncommenting the "stride*(uint64_t)(h+128) >= INT_MAX" check in imgutils.c makes it work [15:03:54 CEST] <Radiator> Where can I find a key / value list for av_dict_set ? [15:03:55 CEST] <sfan5> though probably unsafe, since the check exists for a reason [15:06:23 CEST] <DHE> pink_mist: no. I don't know about PNG internals... [15:06:53 CEST] <DHE> pink_mist: but if you wrote something like "int offset = y*png->height + x;" you are in for a world of hurt as offset risks overflow [15:07:48 CEST] <DHE> that's not literally how it works as a user of ffmpeg libs, but you could see how there could be a hidden bug somewhere when dealing with this stuff [15:08:19 CEST] <pink_mist> yeah, I can [16:20:34 CEST] <Radiator> A simple link to compile with the libav* should work right ? I installed ffmpeg, tried to just call avformat_alloc_context() with -lavformat but it doesn't link [16:20:50 CEST] <Radiator> Using gcc [16:21:13 CEST] <pink_mist> check the pkgconfig files [16:21:57 CEST] <Radiator> Where would it be ? [16:24:56 CEST] <pink_mist> you installed ffmpeg yourself, you should be able to check [16:25:05 CEST] <pink_mist> I don't know how you installed it [16:25:21 CEST] <Radiator> On ubuntu using apt-get [16:25:58 CEST] <pink_mist> well then you probably didn't even install the dev stuff, which includes the pkgconfig files and the headers you need in order to link to it at all [16:26:42 CEST] <another> pkg-config --path libavformat [16:26:44 CEST] <Radiator> Oh ok. Is there a documentation where I could find how to do that ? [16:27:40 CEST] <pink_mist> another: without the pkgconfig files even included, that'd do little to help [16:27:48 CEST] <another> i know [16:27:49 CEST] <pink_mist> Radiator: like I said, the dev stuff [16:28:32 CEST] <pink_mist> Radiator: perhaps you should ask in an ubuntu help forum if you don't know where to find such things in ubuntu [16:29:26 CEST] <Radiator> I'll figure it out, it's just that there's nothing in the documentation explaining how to configure or install the libs [16:30:32 CEST] <pink_mist> you can't expect ffmpeg to have documentation for every single different linux distribution out there, or all the other operating systems ffmpeg works on [16:30:44 CEST] <pink_mist> it's up to your linux distribution to do that shit [16:32:16 CEST] <Radiator> I don't think it is about my distribution itself but more like a getting started for devs [16:32:22 CEST] <pink_mist> I'm telling you it is, though [16:32:55 CEST] <pink_mist> whether or not you believe me doesn't change reality [00:00:00 CEST] --- Sat Sep 7 2019

1 0