Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

February 2019

1 participants
56 discussions

ffmpeg-devel.log.20190207
by burek 08 Feb '19

08 Feb '19

[00:21:37 CET] <nevcairiel> JEEB: looking at the libc ML there, he really never got a hard no, apparently he just didnt push for it any further [00:23:03 CET] <JEEB> yea [00:23:18 CET] <nevcairiel> even the guy with the initial no said he wouldnt have any problems with it if someone elses agrees [00:23:56 CET] <JEEB> yup, too bad the guy had already taken the thing as NACK and then people went with "yeah, that's probably a good idea" with regards to the linuxtv thing [00:24:06 CET] <JEEB> also I just took a look at the code there [00:24:13 CET] <JEEB> the use of macros is interesting [00:24:22 CET] <nevcairiel> its a hundred year old gnu-adjacent code [00:24:23 CET] <JEEB> and how I guess the included .c file generates the module [00:24:26 CET] <nevcairiel> better have eye soap ready [00:24:33 CET] <JEEB> from all those defines [00:47:21 CET] <cone-791> ffmpeg 03Michael Niedermayer 07master:1e59071aad95: avcodec/ac3: Explicitly return to discard large amounts of nonsense bytes [00:47:21 CET] <cone-791> ffmpeg 03Michael Niedermayer 07master:1aa796bc9c65: avcodec/mpegvideo_enc: Use av_assert1() instead of assert() in merge_context_after_encode() [00:47:21 CET] <cone-791> ffmpeg 03Nikolas Bowe 07master:2b8458fcc5d5: avformat/movenc: Add more error checking when writing sample entries. [10:47:39 CET] <ubitux> i have a mp4 sample (generated with ffmpeg) with multiple aac audio frames in its packets [10:47:46 CET] <ubitux> like, 2 audio frames in every packets [10:47:57 CET] <ubitux> does anyone have any clue what's the cause of this? [10:48:33 CET] <ubitux> it's not causing much issue to ffmpeg for playback (except a warning), but it's causing trouble for the rest of the world [10:48:58 CET] <nevcairiel> i would think that even ffmpeg couldnt play raw aac when the packet boundaries are broken [10:49:13 CET] <nevcairiel> because it lacks sync markers [10:49:48 CET] <ubitux> it seems mpv and ffplay are able to deal with this; on other players you typically get a full speed playback or whatever similar madness [10:50:02 CET] <ubitux> i'm just curious how we could end up with such a file generated by ffmpeg [10:50:07 CET] <ubitux> (Lavf58.12.100) [10:50:44 CET] <nevcairiel> well if a file was like that and you used stream copy, it might seem like ffmpeg caused this [10:50:49 CET] <nevcairiel> not sure how encoding would result in that [10:51:18 CET] <ubitux> oh, stream copy mmh [10:51:32 CET] <ubitux> like, stream copy from mpeg ts or something like that? [10:52:07 CET] <nevcairiel> any source really i guess [10:53:02 CET] <nevcairiel> although a clue would be if the second frame has an ADTS header [10:53:14 CET] <ubitux> but the source would already have this audio frame pairing in the first place, or it's the stream copy that would have cause this? [10:53:38 CET] <ubitux> (and if it's the source, in what situation would it be valid?) [10:54:04 CET] <nevcairiel> raw aac frames without packet boundaries are really never valid [10:54:29 CET] <nevcairiel> what I could imagine happening is that the origin stream was ADTS, which has sync markers and therefor can exist without containers [10:54:38 CET] <nevcairiel> and a conversion of that went wrong somewhere [10:57:44 CET] <ubitux> ok, i'm going to check that ADTS header, thank you ! [11:02:19 CET] <ubitux> http://b.pkh.me/p/2019-02-07-110147-thuw8Ees [11:02:23 CET] <ubitux> i don't see any sync word [11:09:48 CET] <ubitux> cuts are systematic, but look pretty much random 371/743 476/986 487/978 452/876 ... [18:28:52 CET] <kevinnn> hey does anyone know if libav can be used to create an rtsp stream? Can libav be an rtsp server? [18:33:37 CET] <JEEB> there's an rtsp input/output format as far as I can see :P [18:33:56 CET] <JEEB> what you define as "rtsp server" is a whole separate discussion of course [18:34:01 CET] <JEEB> and IIRC rtsp is a mess [18:35:34 CET] <kevinnn> why would you say rtsp is a mess? [18:36:00 CET] <JEEB> what some vendor means with "rtsp" can mean something completely different to another [18:36:58 CET] <JEEB> that's why there's live555 for example which is an old and probably the most compatible thing for RT(S)P [18:37:02 CET] <JEEB> but yea, it's a mess :P [18:37:25 CET] <kevinnn> I am currently using live555 as my rtsp server, but unfortunately because the way the code is structured (with a bunch of classes and abstract functions) it makes integrating with my current code base a struggle [18:37:44 CET] <kevinnn> the abstract functions don't let me pass along any parameters I want to [18:38:00 CET] <kevinnn> and because classes are initialized and deleted often during the life time of the stream [18:38:11 CET] <kevinnn> passing data to live555 is very difficult [18:38:33 CET] <kevinnn> I basically had to create a bunch of global static variables to pass data into live555 [18:39:01 CET] <kevinnn> I was hoping for a simpler solution but is live555 basically my best option? [18:39:12 CET] <kevinnn> If I want a UDP stream for video [18:39:30 CET] <JEEB> I have no idea. I see the input and output modules so you should be able to check if those contain the features you require [18:39:47 CET] <kevinnn> I considered rtmp for a while but since it transmits video using tcp I figured it would be prone to more latency than rtsp [18:40:04 CET] <kevinnn> what do you mean input and output modules? [18:40:08 CET] <kevinnn> can you link me? [18:40:17 CET] <JEEB> libavformat/rtsp*.c [18:40:39 CET] <JEEB> you use those when you open an AVFormatContext with rtsp:// [18:40:56 CET] <kevinnn> any nice examples implementing these? [18:41:20 CET] Last message repeated 1 time(s). [18:41:20 CET] <kevinnn> also I only see libavformat/rtsp.c [18:41:23 CET] <kevinnn> nothing else [18:41:35 CET] <JEEB> rtspenc.c? [18:41:52 CET] <JEEB> rtspdec.c? [18:42:08 CET] <JEEB> anyways, I've only used rtsp in FFmpeg for reading [18:42:25 CET] <JEEB> and in that case you just made sure if you were using UDP or TCP, and then passed on the URL [18:42:36 CET] <JEEB> nothing special as far as API-wise usage goes [18:42:45 CET] <kevinnn> hmm, I see a bunch of references to tcp in that source file... [18:43:00 CET] <JEEB> yes, there's an option to either use TCP or UDP [18:43:12 CET] <kevinnn> the comments suggest otherwise [18:43:40 CET] <JEEB> rtsp.c AVOption rtsp_transport [18:44:00 CET] <JEEB> which seems to utilize the variable lower_transport_mask [18:46:04 CET] <JEEB> anyways, most UDP output I've done so far has just been plain old UDP with MPEG-TS [18:47:04 CET] <kevinnn> okay thanks, I' [18:47:13 CET] <kevinnn> ll keep digging around [20:00:43 CET] <Mathieu_Du> before making more mess on the ML, I guess I should ask here, when updating a proposed patch should it be send in a new thread? as a reply? if so to what post? [20:02:11 CET] <JEEB> I generally do an in-reply-to to the original patch, and first format-patch it out, to modify the [PATCH] header to [PATCH vXYZ] [20:02:30 CET] <JEEB> that way people can separate it from the previous version(s) [20:03:14 CET] <JEEB> see for example the libaribb24 thread I've been recently posting in [20:03:22 CET] <JEEB> (has versions 2,3 there) [20:04:04 CET] <JEEB> also format-patching means you can add comments after the --- line, but before the first diff [20:04:11 CET] <JEEB> (unless I've been getting that wrong 8)) [20:05:49 CET] <Mathieu_Du> oh I see, so you don't pass a commit name to git send-email ? [20:06:52 CET] <JEEB> I either note a directory, or a specific format-patch patch if I need to add comments or a preface [20:07:03 CET] <Mathieu_Du> some info on this would probably be make for a useful update to doc/developer.texi :) [20:07:50 CET] <JEEB> if I don't need to add comments etc I just do git send-email --suppress-cc=all master..HEAD or something :) [20:08:13 CET] <JEEB> cc suppression just to make sure I don't cause random spam to people :) [20:08:40 CET] <Mathieu_Du> I see, thanks :) [20:08:55 CET] Action: Mathieu_Du refrains from addressing the elephant in the room [20:09:15 CET] <nevcairiel> great, now the elephant is lonely again [20:11:05 CET] Action: Mathieu_Du pats the elephant [00:00:00 CET] --- Fri Feb 8 2019

1 0

ffmpeg.log.20190207
by burek 08 Feb '19

08 Feb '19

[00:32:21 CET] <DHE> friendofafriend: if it's x264, you might be able to extract the exact settings. otherwise ffprobe can only make high level guesses like the profile [02:34:59 CET] <nativetexan> howdy [02:39:59 CET] <saml_> how can I loop video until audio ends? [06:25:17 CET] <dongs> hithere, why i cannot encode 5760x2880 video with nvenc? https://developer.nvidia.com/video-encode-decode-gpu-support-matrix says anything in pascal family should be able to do 8K. is it for hevc only? [06:26:52 CET] <dongs> ok yeah hevc only. neverm ind. [09:55:30 CET] <drag88> Hi, im getting an error during 10bit encoding via ffmpeg/x264, https://pastebin.com/n02558zK [09:55:42 CET] <drag88> Unable to find a suitable output format for 'high10' [09:55:52 CET] <drag88> Zerano builds should have 10bit support [09:58:09 CET] <JEEB> that error makes it sound like high10 is a file name and as it doesn't have an extension lavf can't guess which container format you want :P [10:17:23 CET] <drag88> @JEEB, mind taking a look at my syntax in the paste? [10:36:22 CET] <JEEB> drag88: unfortunately not since $dayjob [10:39:04 CET] <drag88> ok [10:39:29 CET] <drag88> for reference: ffmpeg -loglevel verbose -i 2398.mov -pix_fmt yuv420p10le -codec:v libx264 -x264opts -profile:v high10 -preset veryslow -crf 10 -c:a copy -map 0:v -map 0:a -y TEST_CRF10_veryslow.mkv [10:40:10 CET] <JEEB> yea, the -x264opts is where it starts going wrong :P [10:40:17 CET] <JEEB> because -x264opts -profile:v [10:40:32 CET] <JEEB> then high10 ends up being not an option but output path [10:40:55 CET] <JEEB> so just remove -x264opts since you're not setting any options with it [10:45:12 CET] <drag88> isnt -profile:v part of the x264opts? [10:46:03 CET] <drag88> ure right.. i allways thought that it was a part of x264opts.. removed it = works [17:25:43 CET] <th3_v0ice> How can I check if frame had decoding errors when it exits the decoder? [17:28:28 CET] <DHE> frame->flags & AV_FRAME_FLAG_CORRUPT [17:33:25 CET] <Mavrik> Is that even used? [17:47:30 CET] <sybariten> Hello [17:48:02 CET] <sybariten> Is it even possible to make estimations about what filesize an x minute video will have, given that its using a still picture all through it? [17:48:26 CET] <sybariten> Where the pic dimensions are known ofcourse. I'm asking this for a podcast issue, and regarding storage at youtube [17:51:11 CET] <kepstin> hmm, you don't have to regard storage at youtube, that's all on google :) [17:51:34 CET] <kepstin> (they encode multiple formats at different bitrate in multiple codecs, so filesize is kinda meaningless there) [17:57:59 CET] <furq> it'll almost certainly be smaller than the audio [18:03:09 CET] <sybariten> kepstin: hmmm weeeelll.... i suppose part of me just wanted to not waste unnecessary bandwidth or storage [18:03:44 CET] <sybariten> furq: hmm how so? I was thinking of taking the mp3 files of my podcast and just throw them into some video container with a still image [18:04:14 CET] <kepstin> for unnecessary bandwidth, that's all on you - you just have to encode with settings (long gop) that minimize upload size [18:04:25 CET] <kepstin> youtube's gonna re-encode it after they receive it anyways [18:04:50 CET] <kepstin> their outgoing bandwidth is something you have no say over whatsoever [18:05:40 CET] <th3_v0ice> DHE: Thanks. I will use that. [18:06:32 CET] <th3_v0ice> Is it possible that the number of streams in AVFormatContext->nb_streams changes during the av_read_frame operation? [18:07:08 CET] <furq> sybariten: ffmpeg -loop 1 -framerate 6 -i foo.png -i bar.mp3 -shortest -tune stillimage -preset veryfast -pix_fmt yuv420p -vf scale=-2:720 -g 120 -c:a copy baz.mkv [18:07:14 CET] <furq> that's the one i use [18:07:16 CET] <TheAMM> th3_v0ice: Multimedia is hell, so yes [18:07:26 CET] <TheAMM> AFAIK, anyhow, but iirc that's mostly just on .ts [18:07:44 CET] <sybariten> kepstin: really? I'm not sure i grasp this. I'm guessing long GOP means i should code it in a way that there are very few, hm, intraframes or whatever they are called? [18:07:47 CET] <TheAMM> Someone will explain how I'm wrong, soon [18:08:02 CET] <furq> i'm pretty sure youtube reencodes everything with 5-second gops anyway [18:08:09 CET] <furq> so it doesn't matter for vod [18:08:35 CET] <kepstin> sybariten: yeah. This basically means setting -g to a big value. The only reason to do this is to make the upload to youtube go faster. [18:08:51 CET] <furq> it doesn't make as much of a difference as you'd think [18:09:13 CET] <sybariten> kepstin: but lets say i have a 10 minute 100 megabyte mp4 file at HD size and a bitrate of 3 megabits. (I'm just making this up). What do you mean happens once it reaches youtube? [18:09:18 CET] <furq> but if you're not going to use the file locally at all then you might as well [18:09:18 CET] <kepstin> hmm. in combination with a low framerate, too... but yeah, gains are marginal [18:09:30 CET] <furq> well youtube's minimum framerate is 6 for some reason [18:09:32 CET] <furq> so i just give them that [18:09:36 CET] <kepstin> sybariten: youtube re-encodes it using secret settings and it might get bigger or smaller [18:09:41 CET] <sybariten> aha [18:09:58 CET] <th3_v0ice> TheAMM: I am working with .ts file now, never expected this number to change actually. [18:10:15 CET] <furq> sybariten: you'll be talking like 50kbps for a still image at 720p [18:10:22 CET] <sybariten> ok [18:10:27 CET] <kepstin> th3_v0ice: with ts files, ffmpeg by default only probes partway into the file, and ts can add/remove streams at any point [18:10:44 CET] <kepstin> th3_v0ice: you can increase the probe size/duration so it finds more streams in the initial probe sometimes [18:11:12 CET] <kevinnn> Hi, does anyone have a short simple example of how to use libav to transmit h264 frames via rtsp [18:11:36 CET] <kevinnn> rephrased: I want an example of how to set up a simple rtsp server using libav [18:13:05 CET] <th3_v0ice> kepstin: It becames very tiresome handling all of those changes actually. Is there a trigger that can help me call my code and update my allocated fields? Because I am allocating some arrays based on the nb_streams. Once that changes I am actually calling invalid pointers. [18:13:15 CET] <sybariten> furq: thanks for the command line! [18:14:07 CET] <sybariten> but lets just say for local storage reasons then: does the video filesize change much in a situation like this, between 1280x720 and 1920x1080 as a still image? [18:14:18 CET] <sybariten> s/change/grow [18:14:25 CET] <furq> it'd change a bit [18:14:38 CET] <sybariten> but not in a magnitude of double perhaps [18:14:48 CET] <furq> but you already get the best audio quality on youtube if you upload at 720p [18:14:53 CET] <furq> so i don't see the point of going higher [18:15:19 CET] <sybariten> nah, i was kind of thinking of using a 720 pixel image. [18:18:42 CET] <kevinnn> also because the lack of good results on google I am questioning now if libav is even capable of doing an rtsp server... [18:21:24 CET] Action: th3_v0ice slaps Jervis_ around a bit with a large trout [19:00:34 CET] <trashPanda_> Hey, I have kinda a dumb question. If I wanted to describe the difference between ffmpeg and libav, how would I characterize it? Where does ffmpeg end and libav code start? There appear to be two githubs, one for libav and one for ffmpeg but both have the same files inside. [19:16:38 CET] <BtbN> libav is a separate Project [19:32:54 CET] <kepstin> the differences are more in the people working on the code than the code itself [19:33:28 CET] <kepstin> they both start from the same point, there's been code copied between them, etc. [19:43:59 CET] <grayhatter> trashPanda_ theres an interesting article i found on stackexchange [19:44:13 CET] <grayhatter> that's what i'd recommend [20:14:05 CET] <mfolivas> need some suggestions guys/gals. looking for other hardware encoders that could get us to 2x encoding speed with reasonable file sizes [20:16:18 CET] Action: kepstin recommends using the "x86-64 cpu" encoder hardware running the "libx264" firmware, but in a pinch, the nvidia encoders are considered fairly decent. [20:28:12 CET] <BtbN> Nvidia on Touring actually got a lot better, but haven't had the chance to test yet [20:33:57 CET] <^Neo> does anyone know if there's an example read/write circular buffer AVIOContext implementation already in master branch? [21:29:07 CET] <GlidingHorse> hi, i'm muxing to mpegts and I need the result to start at a different timestamp, i.e. the output's first pts must be X value [21:29:30 CET] <GlidingHorse> but i can't find any way of achieving that [21:30:08 CET] <GlidingHorse> always starts at 0, or the same as input (-copyts) [21:30:17 CET] <GlidingHorse> i need to set an specific time [21:33:18 CET] <JEEB> ffmpeg.c had itsoffset I think? [21:34:39 CET] <kepstin> if you're re-encoding you could just the setpts filter to make arbitrary adjustments. [21:35:29 CET] <GlidingHorse> thanks JEEB and kepstin, i didn't see itsoffset. i think that would be enought, if it's not i'll do the setpts filter [21:36:11 CET] <kepstin> there's also an "mpegts_copyts" option on the muxer, there might be some cases where you have to turn that on to preserve timestamps [21:39:19 CET] <JEEB> that only seems to affect addition of delay, which seems to be s->max_delay, which seems to be an option as well [21:39:51 CET] <JEEB> so I'd not look into that too much [21:39:53 CET] <JEEB> :P [00:00:00 CET] --- Fri Feb 8 2019

1 0

ffmpeg-devel.log.20190206
by burek 07 Feb '19

07 Feb '19

[00:25:16 CET] <acetone> Hi, may I have a question about swscale? [00:27:35 CET] <JEEB> just ask [00:31:05 CET] <acetone> We use swscale to just convert pixel format, so we do scale 1:1, I am reviewing bug report of "quality loss" and found that swscale tries to scale the image even if src res is the same as dst res [00:31:41 CET] <acetone> we use SWS_FAST_BILINEAR method. [00:32:01 CET] <JEEB> yes, I think there can be plenty of conversions that f.ex. go through YCbCr or so. also colorspace conversions like RGB to 4:2:0 will anyways have chroma subsampling [00:33:20 CET] <acetone> So it's unavoidable then? [00:33:54 CET] <JEEB> depends on what's your exact conversion etc [00:35:16 CET] <acetone> in this case it's AV_PIX_FMT_YUV444P10LE to AV_PIX_FMT_RGBA [00:35:45 CET] <JEEB> ok, so in theory there should be no chroma subsampling unless you somehow end up in a chain that does that [00:35:52 CET] <JEEB> since input and output are 4:4:4 [00:36:38 CET] <JEEB> although there might have been a required option for swscale to not try to be "fast" with certain conversions and insert chroma subsampling somewhere [00:36:55 CET] <JEEB> acetone: are you utilizing through lavfi or swscale itself? [00:38:16 CET] <acetone> Also when I said "tried to scale" I meant, in X on the "left" side of the image, there was almost no difference from reference, but on the "right" side of the image pixels were shifted 1pixel to the right... [00:39:15 CET] <acetone> JEEB, I think this is swscale directly. it's defined in swscale.h [00:44:36 CET] <acetone> I can upload a picture, that demonstrate this issue if it helps [00:50:53 CET] <jdarnley> swscale must have a couple of options that might be related because they are accessible from ffmpeg's command line [00:51:03 CET] <jdarnley> something like "full chroma intrpolation" [00:54:32 CET] <jdarnley> https://ffmpeg.org/ffmpeg-scaler.html#sws_005fflags [00:54:57 CET] <jdarnley> full_chroma_int Enable full chroma interpolation. full_chroma_inp Select full chroma input. [00:56:19 CET] <JEEB> acetone: if you were on lavfi I would have recommended testing out 4:4:4 to gbrp with zscale, and then gbrp->rgba packetizing with the format filter (which is swscale) [00:56:28 CET] <JEEB> since that seemed to work for me :P [00:58:35 CET] <JEEB> uhh, scale filter I meant for the packetizing - format to tell zscale what to output, scale to do the simple conversion [00:58:45 CET] <JEEB> but yes, with swscale I would test those options [00:59:01 CET] <JEEB> because swscale can do fun things by default :P [00:59:10 CET] <acetone> JEEB, I am afraid that I will not be able to change libs that we use. Project I am working on is Blender, but I can reproduce this with VLC also [00:59:20 CET] <jamrial> there's bitdepth conversion from yuv444p10 to rgba [00:59:31 CET] <jamrial> so there is data loss no matter what [00:59:40 CET] <JEEB> yes, that of course will be there [01:08:13 CET] <acetone> I uploaded the image https://drive.google.com/file/d/15npoPBX776L3YRz6BtLzX2-lczMVHiv4/view?usp=… [01:10:19 CET] <acetone> first 3 pixels is reference. IMO it seems more like a bug then only a subsampling issue - it is clear, that it scales the image to X+1 pixel [01:11:45 CET] <JEEB> if you can create a simple thing to replicate it, feel free to post an issue on the trac issue tracker [01:15:17 CET] <acetone> JEEB, Can I refer to our code to replicate issue, or do you need something like console command? [01:15:40 CET] <JEEB> if you can replicate it with ffmpeg.c as well, that's fine too [01:15:50 CET] <JEEB> if not, you can minimal API example [01:16:31 CET] <acetone> OK, worst case you will request better case I guess.. [01:17:08 CET] <JEEB> you can dump an example yuv444p10 frame into y4m or so :P [01:19:44 CET] <acetone> biggest problem is that I don't know a lot of what you are talking about, that's why I want you to look at it :) [01:23:26 CET] <JEEB> provide a sample of the input and the way to replicate the issue, post on the issue tracker [01:23:41 CET] <JEEB> it's 2:23 AM here and I'm definitely not going to be looking into swscale any time soon :P [01:25:07 CET] <acetone> Sure. Anyway, thanks for help :) bye! [08:20:43 CET] <JEEB> argh, why is the gmail application so bad. i cannot properly reply to my own mail and do an in-line reply. the darn client just refyses to leave quoting [08:20:58 CET] <JEEB> will have to reply when I get to a pc [08:33:17 CET] <JEEB> because while lgplv3 is ok by me, i missed to note that i do not want to use my free time in pulling in a 3rd party lib packaged in distros if the end result isn't even compatible with our base license [13:02:08 CET] <cone-800> ffmpeg 03PaweB Wegner 07master:835ab35ef023: libavformat/dashdec: disable seeking only for live streams. [19:34:43 CET] <JEEB> can I get some extra opinions on the libaribb24 thing? because right now it seems like it's just me who wants to put that thing in, and just carl who doesn't [20:09:14 CET] <durandal_1707> JEEB: ask nicolas [20:14:11 CET] <iive> JEEB, what is libaribb24? [20:14:31 CET] <JEEB> the library VLC uses for ARIB caption decoding [20:14:49 CET] <JEEB> I did babby's first subtitle decoder using it :P (and also implemented demuxing of those captions) [20:15:01 CET] <JEEB> mostly because the alternative would have been [20:15:25 CET] <JEEB> a) import an out of tree iconv module that is LGPLv2.1+ and never went upstream because broadcast text is "not common in computing" [20:15:44 CET] <JEEB> b) start figuring out if an anonymous, never-talked-to-upstream implementation of the captions was any good [20:15:55 CET] <JEEB> you can see why I decided to make sure I had a reference first :P [20:16:12 CET] <JEEB> because vlc already uses libaribb24 and it's packaged in debian etc [20:16:51 CET] <JEEB> iive: the patch itself for the decoder is @ https://patchwork.ffmpeg.org/patch/11965/ [20:16:59 CET] <JEEB> I don't think anyone had any objections to the demuxing patch [20:17:23 CET] <JEEB> demuxer patch is https://patchwork.ffmpeg.org/patch/11960/ [20:17:24 CET] <JEEB> :V [20:18:41 CET] <JEEB> also I don't even know how people would react if we had to pull in a full text encoding conversion thing into lavu or something since all of the MPEG-TS metadata in ARIB streams is also coded in that text encoding [20:19:41 CET] <JEEB> iive: how it looks like rendered: https://megumin.fushizen.eu/screenshots/arib_subs/mpv-shot0004.png [20:20:00 CET] <JEEB> (the 0/0 patch has a sample linked) [20:20:48 CET] <iive> why is carl opposing it? I see no reason for objections. [20:21:00 CET] <iive> unless he wants to merge the library into ffmpeg [20:21:42 CET] <JEEB> he wanted that but I did most recently tell him that since it's LGPLv3 I would probably not put in all the effort if it ends up being a thing that isn't enabled in the default config :P [20:21:59 CET] <JEEB> because it means the whole effective parts of that library have to go through FFmpeg code review [20:22:02 CET] <JEEB> :P [20:22:15 CET] <JEEB> and at that point I'd rather start working on the LGPLv2.1+ alternatives [20:22:30 CET] <durandal_1707> there is no FFmpeg code review - really [20:22:50 CET] <iive> JEEB, this doesn't sound like strong objection, only preference [20:23:34 CET] <durandal_1707> you need to explicitly ask Carl if that is objection/blocking [20:23:42 CET] <JEEB> he already said no, thankfully [20:23:47 CET] <JEEB> he just doesn't like it [20:23:53 CET] <iive> and even if somebody is working on merging or porting the code, it makes sense to have library support to compare it. [20:24:23 CET] <iive> so, there is no problem then. [20:25:40 CET] <JEEB> I'm just mostly looking for opinions so I know how many people's tastes I step onto since at least one person has shown dislike towards it :P [20:25:49 CET] <JEEB> because right now it looks like 1:1 [20:37:32 CET] <nevcairiel> why do crazy asians not like unicode :( [20:37:48 CET] <nevcairiel> or rather, utf-something [20:38:17 CET] <JEEB> I think they actually have UTF-8 in the spec, but I bet in 2003 all the broadcasters went "uuhhhh, this is very much like this ISO Japanese coding so we'll just go with it" [20:38:26 CET] <JEEB> (except it isn't exactly) [20:39:05 CET] <JEEB> I think like half of it matches some ISO, and another matches some other coding native to Japan (JIS?) [20:39:51 CET] <JEEB> back in like 2011-12 or so when I was trying to get a friend to implement this stuff for funzies and giggles, he just took a look at the character mapping at the end of the spec and ragequit on the spot [20:40:09 CET] <JEEB> fun times [20:40:27 CET] <nevcairiel> heh [20:40:36 CET] <JEEB> also I found it extra fun when the guy who implemented the decoding (and encoding!) in an iconv module actually tried to push it upstream [20:40:50 CET] <nevcairiel> using something like iconv for this stuff is the only realistic option, one really doesnt want to re-implement it [20:40:54 CET] <JEEB> let me find the thread where he got told that broadcast text codings aren't computing enough [20:40:57 CET] <nevcairiel> hopefully iconv supports it? :P [20:40:59 CET] <JEEB> nope [20:41:03 CET] <JEEB> it's only in linuxtv's modules [20:41:04 CET] <JEEB> xD [20:41:20 CET] <JEEB> so to have it available anywhere you have to basically start taking it in [20:43:27 CET] <JEEB> https://sourceware.org/ml/libc-help/2015-03/msg00008.html [20:43:55 CET] <JEEB> and then https://sourceware.org/ml/libc-help/2015-03/msg00016.html [20:46:42 CET] <JEEB> so now they're just sitting @ https://git.linuxtv.org//v4l-utils.git/tree/contrib/gconv [20:48:58 CET] <JEEB> but yes, I wish it was available in iconv things :P [20:49:28 CET] <JEEB> because I bet if you try to put text decoding/encoding into lavu someone will have a "you w0t m8" moment [20:52:41 CET] <iive> JEEB, have you tried extending the iconv to support it? [20:53:32 CET] <JEEB> do you mean some other iconv than the one I posted because it got pretty well nope'd there? [20:53:52 CET] <JEEB> (I thought we only wrap iconv) [20:56:05 CET] <JEEB> or do you mean that all the iconvs have a standardized API? [20:56:15 CET] <JEEB> into which you can stick new modules [20:57:14 CET] <JEEB> I know iconv modules are a thing but I'm not sure it worked with f.ex. windows? [20:57:27 CET] <durandal_1707> RULE 1: if nobody reviews your patch after 5 days of sending, it get automatically pushed [21:02:44 CET] <durandal_1707> mailing list activity is not high as it used to be [21:02:53 CET] <iive> JEEB, following the whole libc thread, i'm a bit confused. some of the developers kind of agreed, then somebody gave up?! [21:03:26 CET] <JEEB> the end result seems to be that first it was "let's take a look at it" [21:03:34 CET] <JEEB> and then when it came to it, another person went "nope, not computing enough" [21:03:45 CET] <JEEB> that patch set had both the DVB text coding and ARIB [21:04:14 CET] <iive> but the thread continued after that [21:04:32 CET] <iive> and developers were inclined to ... not reject it. [21:05:07 CET] <JEEB> looking at https://sourceware.org/ml/libc-help/2015-03/threads.html#00016 [21:05:26 CET] <JEEB> it seems like Florian and Carlos generally started talking about reworking parts of gconv [21:05:44 CET] <JEEB> https://sourceware.org/ml/libc-help/2015-03/msg00032.html [21:05:58 CET] <JEEB> is where the guy settles for the linuxtv.org repo [21:06:43 CET] <iive> you see the quoted text? [21:07:39 CET] <iive> it looks like Akihiro TSUKADA declares defeat and tries another approach [21:08:05 CET] <iive> and the libc guys simply accept it, since it means less work for them. [21:08:47 CET] <iive> https://sourceware.org/ml/libc-help/2015-03/msg00024.html [21:08:57 CET] <iive> that sounds like they were OK with including it. [21:09:04 CET] <JEEB> yes, he then got positive stuff [21:09:20 CET] <JEEB> unfortunately he also got a NACK [21:09:26 CET] <JEEB> anyways, long story short it never went in [21:09:54 CET] <iive> it should have. [21:10:10 CET] <iive> it could have... [21:10:20 CET] <durandal_1707> so did work got committed somewhere after all? [21:10:27 CET] <JEEB> in linuxtv repo [21:10:31 CET] <JEEB> https://git.linuxtv.org//v4l-utils.git/tree/contrib/gconv [21:10:37 CET] <durandal_1707> ah [21:12:46 CET] <iive> what is that and how is it used? [21:13:17 CET] <JEEB> seems to have a makefile to make modules, but I don't think it works with anything else than linux :P [21:13:32 CET] <JEEB> the arib one is the ARIB STD-B24 dec/enc [21:13:38 CET] <JEEB> and the en300 one is DVB [21:14:05 CET] <iive> oh... [21:14:24 CET] <JEEB> and when I say dec/enc I mean the *text* encoding [21:14:26 CET] <iive> so totally useless. [21:15:38 CET] <JEEB> but yea, I was planning on looking at this stuff and seeing if I could make it into an OK API'd thing in lavu or so [21:15:46 CET] <JEEB> so that lavf/lavc would be able to use it [21:16:11 CET] <JEEB> after that the anonymous ARIB STD-B24 lavc decoder that's LGPL2.1+ could be looked into [21:16:18 CET] <JEEB> since right now it 100% bases on that module [21:16:37 CET] <JEEB> so you need to be able to replace that text coding conversion part with something else [21:17:16 CET] <JEEB> libaribb24 just happens to have both of those parts in it (text coding and the actual captions), which is why I picked it as the first thing :P [21:17:27 CET] <JEEB> it just unfortunately is LGPLv3 [21:24:58 CET] <atomnuker> that would be okay too, we have a flag for that [21:25:27 CET] <JEEB> yes, but if I have to drag that thing through code review then I'm not going to do it with an LGPLv3 component :P [21:25:37 CET] <JEEB> for an external lib it's OK [00:00:00 CET] --- Thu Feb 7 2019

1 0

ffmpeg.log.20190206
by burek 07 Feb '19

07 Feb '19

[01:12:25 CET] <mfwitten> For example, given a video stream in an `input.mp4', can you resize each frame but maintain *exactly* the same presentation time for each frame? I've found it to be impossible; and, I get different results with different containers, too. [01:13:41 CET] <mfwitten> As you might guess, this is mainly a problem for streams with a variable frame rate (vfr).f [01:14:15 CET] <furq> did you try -vf settb [01:18:24 CET] <mfwitten> furq: I have not, but I have tried `-copyts', `-enc_time_base', `-time_base', and `-vsync passthrough'. [01:18:31 CET] <mfwitten> furq: I'll try settb now [01:19:14 CET] <furq> you'll get odd results with mpegts and mkv because those have fixed timebases (1/90000 and 1/1000) [01:19:39 CET] <JEEB> matroska isn't fixed actually, but it's in increments of *10 [01:19:48 CET] <furq> isn't it always 1/1000 in ffmpeg [01:19:53 CET] <JEEB> most matroska files and the default is 1/1000 though [01:19:55 CET] <furq> or lavf rather [01:19:58 CET] <JEEB> lessee matroskaenc [01:20:40 CET] <furq> i forget if it's the default or if it's hardcoded [01:20:51 CET] <furq> but either way if your source is 1/25 or something then mkv won't do that [01:21:12 CET] <JEEB> it does use AV_TIME_BASE_Q an awful lot it seems [01:21:22 CET] <JEEB> av_rescale_q(pkt->dts, s->streams[pkt->stream_index]->time_base, AV_TIME_BASE_Q) [01:22:16 CET] <JEEB> chapters are set to AVRational scale = {1, 1E9}; funny enough [01:23:38 CET] <mfwitten> furq: It doesn't seem to have an effect. I think the encoder and/or muxer is doing its own thing [01:26:16 CET] <furq> are you getting the same timebase and different pts values [01:26:20 CET] <furq> or is the timebase different [01:26:31 CET] <mfwitten> furq: both [01:27:07 CET] <mfwitten> furq: The calculated duration changes, too. And if I swap clips in a filtergraph, there are minute but accumulative discrepancies in timing [01:28:46 CET] <mfwitten> furq: The results are very close to what it should be, but basically there are probably rounding errors and the like through the ffmpeg pipeline, and the result is not exact [01:29:17 CET] <furq> it's weird that the timebase would change if you're not changing container [01:29:50 CET] <furq> maybe this is one of those codec/container timebase things that i never bothered to learn about [01:30:15 CET] <mfwitten> furq: Yes. Indeed. I suspect its different hard-coded choices, heuristics based on constant-frame-rate concepts, and rounding errors [01:31:22 CET] <furq> well i can see where rounding errors would creep into the actual pts values [01:31:27 CET] <furq> but not the timebase itself [01:31:51 CET] <furq> afaik it should default to keeping the source timebase [01:32:02 CET] <mfwitten> furq: Why though? Surely ffmpeg has been written to handle mp4 values *exactly*. [01:32:27 CET] <mfwitten> furq: It's even wrong with `nut' (on output), which is designed to be very flexible [01:32:55 CET] <furq> i'm not saying it should happen with timestamps, just that i have no idea how it would happen with the timebase [01:47:44 CET] <ariyasu> [swscaler @ 0000000003727340] deprecated pixel format used, make sure you did set range correctly [01:48:21 CET] <ariyasu> any idea what causes this? im not setting -pxl_fmt to anything [01:48:32 CET] <furq> is your source jpeg or mjpeg [01:48:48 CET] <furq> for some reason that warning gets thrown if the source pixel format is yuvj* [01:48:55 CET] <furq> you can just ignore it in that case [01:49:26 CET] <ariyasu> color space is yuv [01:49:27 CET] <ariyasu> ok [01:49:34 CET] <ariyasu> thanks furq [01:49:43 CET] <furq> you can ignore it anyway, it doesn't change anything [01:49:50 CET] <furq> it's just to let you know it might stop working in future [01:51:03 CET] <mfwitten> furq: That's confusing to me, too. yuvj* has a larger dynamic range, doesn't it? [01:51:25 CET] <furq> yuvj is deprecated because it's a stupid way of signalling full range [01:51:38 CET] <furq> there's a separate flag for that now [01:51:47 CET] <mfwitten> furq: Chromium didn't support playing files with that pixel format, but Google's own Pixel phone creates files with that format [01:52:22 CET] <mfwitten> furq: How should people convert away from it? [01:52:26 CET] <furq> you don't [01:52:29 CET] <mfwitten> oh [01:52:33 CET] <furq> yuvj isn't a real pixel format, it's an ffmpeg internal thing [01:52:40 CET] <ariyasu> Stream #0:0: Video: h264 (High 4:4:4 Predictive), yuvj420p(pc, progressive), 720x480, 59.94 fps, 59.94 tbr, 1k tbn, 119.88 tbc (default) [01:52:50 CET] <ariyasu> this was source [01:52:52 CET] <furq> in practice what it does right now is just set the respective yuv pixel format and then sets the range flag [01:53:04 CET] <mfwitten> ariyasu: Just curious: Is it a video from an Android phone? [01:53:19 CET] <ariyasu> no, im trying to do lossless video capture from a gamecube [01:53:30 CET] <ariyasu> and thats what obs gave me when i set it to crf 0 [01:53:48 CET] <furq> probably because it's an rgb source [02:03:53 CET] <mfwitten> furq: Oh! Thank goodness! It looks like I can get the right timing by setting `-time_base' appropriately; I can get the value by running `ffprobe' on the input. However, I have to say that this is a major pain in the arse. [02:28:53 CET] <mfwitten> furq: Fortunately, `-time_base' seems to do the trick, but it requires looking up the right value ahead of time. Would you consider this a bug? Shouldn't the encoder, by default, just use the input stream's timing information if it's valid? [02:30:02 CET] <mfwitten> furq: Also, `ffmpeg' shows both `codec_time_base' and `time_base'. I can't seem to affect `codec_time_base', despite `-enc_time_base' being an option; what is `codec_time_base'? [02:30:40 CET] <furq> neither of those are listed in ffmpeg-all so i assume they're old aliases for time_base [02:31:09 CET] <furq> or just specific to certain codecs [02:32:28 CET] <mfwitten> furq: I've got ffmpeg `n4.1' installed, and `-enc_time_base' is in `ffmpeg-all' [02:33:02 CET] <mfwitten> furq: Also `codec_time_base' is different in my `input.mp4' from `output.mp4'. So, it must have some meaning [02:33:28 CET] <mfwitten> furq: Does the encoder/decoder have its own timing information separate from the decoded stream's timing? [02:35:52 CET] <mfwitten> I found an old email in the mailing list stating that `-time_base' applies only to native/internal encoders, and so it wouldn't work with `libx264', but it does *now* seem to work with `libx264'. I wonder whether this "bug" (ignoring input timing choices by default) is in `libx264', and not ffmpeg's stuff. [02:54:56 CET] <mfwitten> furq: Sorry to keep bothering you, but I thought you might be interested. `-time_base' is older than `-enc_time_base'; the former may be per-output while the latter is per-encoder or per-stream; the new one supports special arguments, namely `-1', which means to use the input's time base, which is *exactly* what I want, and it seems to work. (For further details, perhaps see: `git log -1 [02:55:02 CET] <mfwitten> 3ac46a0a62386a52e38c066379ff36b5038dd4d0; git log -1 2b06f2d2e24ccc4098f3ab40efd68e8f3f02b273'). [07:13:00 CET] <mfwitten> What is going on here? [07:13:04 CET] <mfwitten> Input stream #0:0 (video): 291 packets read (1096238 bytes); 290 frames decoded; [07:13:07 CET] <mfwitten> ... [07:13:10 CET] <mfwitten> 290 frames successfully decoded, 0 decoding errors [07:14:16 CET] <mfwitten> There are supposed to be 291 frames; in the original file, 291 frames are decoded, yet in this re-encoded (but otherwise the same) file, there are 290 frames decoded [07:14:31 CET] <mfwitten> 291 packets are indeed acknowledged as having been read, but only 290 frames decoded [07:14:50 CET] <mfwitten> There are no errors of any kind [07:16:09 CET] <mfwitten> In other words, the lines should be: [07:16:27 CET] <mfwitten> Input stream #0:0 (video): 291 packets read (????? bytes); 291 frames decoded; [07:16:38 CET] <mfwitten> 291 frames successfully decoded, 0 decoding errors [08:55:11 CET] <th3_v0ice> One packet will not always contain one frame. In my testing if you output to h264 raw bitstream there will always be one frame missing at the end. Not sure if bug or not. [09:02:12 CET] <JEEB> th3_v0ice: you need to flush [09:02:33 CET] <JEEB> so far all of my tests have decoded all frames with H.264 (and you can see the tests in FATE run over samples) [11:12:43 CET] <Foloex> Hello world, I'm trying to make the waveform appear on top of the video. Creating the waveform, positioning it and blending it with the video I managed. I can't figure out how to set the size of the showwaves to be the one of the input video. The size is expected in the form of heightxwidth, I don't get how I can generate this string using W and H. Can someone give me some pointers on that ? [11:14:17 CET] <durandal_1707> 400x300 [11:15:14 CET] <Foloex> Just to be clear, the size of the input varies [11:15:39 CET] <Foloex> I don't want to hard code those values in my filter [11:15:50 CET] <durandal_1707> use shell scripting [11:16:14 CET] <Foloex> You mean use ffprobe then ffmpeg in a script file ? [11:17:09 CET] <durandal_1707> no [11:18:46 CET] <th3_v0ice> JEEB: I did actually, but decoding from h264 to yuv left one frame less, or something like that. Thanks for your help yesterday. [11:19:32 CET] <Foloex> durandal_1707: what do you mean by shell scripting then ? [11:20:23 CET] <durandal_1707> google it [11:20:59 CET] <Foloex> I did and I find things about making a bash file (or equivalent) [11:21:22 CET] <Foloex> nothing specific to ffmpeg though [11:26:11 CET] <th3_v0ice> Use ffprobe to get WxH, copy pasted from stack overflow ffprobe -v error -select_streams v:0 -show_entries stream=width,height -of csv=s=x:p=0 input.mp4, then use string in your filter. [11:26:42 CET] <furq> Foloex: generate showwaves oversized and use scale2ref [11:28:41 CET] <Foloex> I was hoping to do everything within ffmpeg, thanks furq I'll try that [11:30:10 CET] <Foloex> I'm kind of surprise that H and W ffmpeg constants cannot be used to create a size string [11:31:03 CET] <furq> those constants are specific to each filter, and showwaves doesn't take a video as input [11:31:09 CET] <furq> so it has nowhere to get them from [11:32:21 CET] <Foloex> furq: makes sense, thanks [12:34:45 CET] <JEEB> well we're testing that stuff with the FATE tests so you might really want to verify. if you're 100% sure you're missing a picture (frame or field), then make sure you make a test sample and a test case that can be tested/verified [12:34:52 CET] <JEEB> and post an issue on the trac issue tracker [15:38:17 CET] <egrouse> is it possible to, say, continuously write the timestamp of currently playing vid to a file? so if it fails to convert at any point i can resume from the previous place it reached [15:38:43 CET] <egrouse> or is there some other way to achieve this resuming of previous file [15:38:52 CET] <mfwitten> th3_v0ice, JEEB: Interestingly, allowing ffmpeg to choose the default encoding settings for h.264 results in all 291 frames being present, but specifying `-c:v libx264 -preset ultrafast -crf 23' somehow keeps the last frame from being decodable (despite there being a frame, and despite there being no decoding errors. Maybe it requires an even number of frames?). [15:39:05 CET] <mfwitten> egrouse: Yes [15:39:22 CET] <mfwitten> egrouse: Here's a quick hack... [15:40:43 CET] <mfwitten> egrouse: do you understand filtergraphs? If not, perhaps you could give me your command line, so that I can edit it [15:48:17 CET] <mfwitten> egrouse: ffmpeg -v 0 -i input.mp4 -vf 'setpts=PTS+0*print(T\,0)' output.mp4 2>&1 | tee /tmp/timestamps.txt [15:50:11 CET] <mfwitten> egrouse: Now, it might be a little more complicated than that; you might want to ensure that the time stamps in `output.mp4' really are what is being gotten from `input.mp4'. In that case, you currently have to be more precise: [15:50:56 CET] <mfwitten> egrouse: ffmpeg -v 0 -copyts -i input.mp4 -vf 'setpts=PTS+0*print(T\,0)' -enc_time_base -1 output.mp4 2>&1 | tee /tmp/timestamps.txt [15:52:05 CET] <mfwitten> egrouse: Maybe you should be using PTS values instead (i.e., `print(PTS\,0)'), or even explicit frame numbers (i.e., `print(N\,0)'). [15:52:51 CET] <mfwitten> egrouse: Lastly, you'll probably want to split the output into discreet chunks that can be finished separately and then concatenated together at the end if necessary [15:53:28 CET] <mfwitten> egrouse: If you do that, then you might not even need to write out timestamps or whatever, which won't necessarily be too useful anyway [16:20:14 CET] <egrouse> mfwitten, sorry i had to go away - thanks a lot for that [16:21:19 CET] <egrouse> looks like it could be very useful and definitely appreciate the comments regards splitting chunks etc [16:21:25 CET] <egrouse> gonna save all that and have a play later - thank you ;) [16:24:10 CET] <mfwitten> egrouse: d=$(ffprobe -v quiet -select_streams v:0 -show_streams input.mp4 | awk -F= '/^duration=/ {print $2}') [16:24:16 CET] <mfwitten> egrouse: half_d=$(echo "scale=6; $d / 2" | bc) [16:24:22 CET] <mfwitten> egrouse: ffmpeg -i input.mp4 -filter_complex ' [16:24:22 CET] <mfwitten> split=3 [v0][v1][v_output]; [16:24:22 CET] <mfwitten> [v0] trim=duration='"$half_d"' [v_output0]; [16:24:22 CET] <mfwitten> [v1] trim=start='"$half_d"':duration='"$half_d"' [v_output1] [16:24:22 CET] <mfwitten> ' -map '[v_output0]' -an /tmp/output0.mp4 \ [16:24:25 CET] <mfwitten> -map '[v_output1]' -an /tmp/output1.mp4 \ [16:24:27 CET] <mfwitten> -map '[v_output]' -an /tmp/output.mp4 [16:25:07 CET] <mfwitten> egrouse: Something like that. Of course, there are issues with timing and duplicated frames and the like which may be difficult to deal with [16:25:43 CET] <mfwitten> egrouse: Also see here: https://trac.ffmpeg.org/wiki/Concatenate [16:26:26 CET] <furq> wow don't do that [16:26:34 CET] <furq> use the segment muxer to split into chunks [16:26:56 CET] <furq> also use mpegts or something that's more concat-friendly for the intermediate format [16:27:24 CET] <mfwitten> furq: Sure. However, sometimes the chunks you want aren't just linear [16:27:56 CET] <egrouse> thanks to you both [16:28:04 CET] <egrouse> really come to appreciate this channel over the last few weeks :p [16:28:42 CET] <mfwitten> egrouse: Good luck! [16:29:09 CET] <egrouse> thank you :) [16:55:59 CET] <^Neo> hello friends, I'm trying to add spdif support to alsa dec and leverage the spdifdec code in libavformat. In libavformat its expecting an AVIOContext to be present, but in libavdevice it looks like alsa doesn't have one populated. I figure I have two options, add/populate an AVIOContext in the AVFormatContext used in alsa_dec.c, or modify the spdifdec.c (or make a copy for libavdevice) where I just operate over a buffer that the alsa subs [17:06:42 CET] <ariyasu> what's the correct way to end a job when using a direct show device? [17:06:55 CET] <ariyasu> as the input is endless [17:07:39 CET] <c_14> press q [17:07:48 CET] <c_14> or ctrl+c as long as you only press it once [17:08:16 CET] <ariyasu> thanks [17:44:20 CET] <ariyasu> how come when i do "-vf setdar=4:3" it sets the dar to 3:1 ? [17:44:38 CET] <ariyasu> Stream #0:0: Video: h264 (libx264), yuv420p(progressive), 720x480 [SAR 2:1 DAR 3:1], q=-1--1, 59.94 fps, 90k tbn, 59.94 tbc [17:48:13 CET] <furq> ariyasu: setdar=4/3 [17:48:22 CET] <furq> or 4\:3 [17:48:31 CET] <furq> otherwise the : is interpreted as an option separator [17:50:23 CET] <ariyasu> i see, thanks [17:53:34 CET] <Sesse> hi. I have a multi-track mkv file (MJPEG, if it matters) where some of the tracks change video resolution a few times. since it's huge (~2.5 TB), I'd like to get it down to h264 for archival, but after transcoding (which takes a few days...), it seems that the resolution information is lost; the tracks are all at the resolution they started at. is there some way I can keep the original data without [17:53:40 CET] <Sesse> splitting? [17:54:10 CET] <Sesse> fwiw, the command line is: ffmpeg -i input.mkv -map 0:0 -map 0:1 -map 0:2 -map 0:3 -c:v libx264 -crf 24 -preset slower -sn -tune film -movflags faststart output.mp4 [18:04:02 CET] <mfwitten> Sesse: I do not know for sure, but I suspect that neither the mp4 container nor h264 can handle changing dimensions midstream [18:04:21 CET] <mfwitten> Sesse: You could encode each track at the largest dimensions [18:04:54 CET] <mfwitten> Sesse: Also, if you're archiving, you might want to look into a newer codec like AV1 (though the encoder is apparently horrifically slow right now) [18:05:26 CET] <DHE> oh boy is it.. I spent a week on a Ryzen encoding a 1-minute video (25fps) [18:05:31 CET] <DHE> or was it 2 weeks... [18:05:42 CET] <mfwitten> Yikes [18:05:52 CET] <Sesse> mfwitten: I could use something else than mp4 if it helps, I'm positive mkv can handle it [18:05:56 CET] <Sesse> h264, on the other hand... [18:06:01 CET] <Sesse> you'd almost certainly need to insert an IDR frame, of course [18:06:05 CET] <mfwitten> Well, there are some Big Guns lined up behind AV1, so I suspect we'll have hardware acceleration soon enough [18:06:19 CET] <Sesse> AV1 is out of the question for the reasons DHE mention :-) [18:06:28 CET] <Sesse> rav1e is almost realtime now... aka 480p in 10 fps [18:06:31 CET] <Sesse> on a fast machine [18:06:37 CET] <DHE> x264, at least as far as ffmpeg offers it, does not appear to support resolution changes. you'd have to close and re-open the encoder at a minimum. if you can just stream the new packets from the reloaded encoder, MAYBE... [18:06:48 CET] <DHE> but I don't know if that's a spec violation or whatever... [18:07:46 CET] <Sesse> well, it happens in transport streams all the time [18:07:50 CET] <Sesse> so surely it must be allowed [18:08:14 CET] <Sesse> well, ok, switching audio codecs is probably more common than switching resolutions [18:09:17 CET] <Sesse> but I'm fairly certain I've seen blu-rays where the menus are 1080p and the content is 720p [18:09:26 CET] <mfwitten> Sesse: I'm not sure that's the same situation. Those are separate streams of the same content at different resolutions, whereas yours is changing explicitly mid-stream [18:09:38 CET] <Sesse> fair enough [18:10:19 CET] <Mavrik> Huh, is there even a single codec that supports resolution switching? [18:10:27 CET] <Sesse> Mavrik: any intraframe codec [18:10:30 CET] <Mavrik> I mean, there's H.264 SVC, but even that one can't change res [18:10:39 CET] <mfwitten> If you want h264, and you want to be certain you remain withing the bounds of practical tech, then I suggest figuring out the largest dimensions for a frame, and then filtering the other frames so that they are overlayed correctly at the center of these larger frames [18:10:53 CET] <Sesse> mfwitten: I'd assume I just scale down everything to the same resolution [18:10:59 CET] <Sesse> for this purpose, it's good enough-ish [18:11:01 CET] <mfwitten> No need [18:11:17 CET] <mfwitten> Sesse: You could overlay [18:11:26 CET] <Sesse> as in have black borders around? [18:11:29 CET] <mfwitten> Sesse: Your smaller images get overlayed perfectly within big Frames [18:11:34 CET] <mfwitten> Sesse: Yeah [18:11:44 CET] <Sesse> given that it's supposed to simulate camera input, that doesn [18:11:46 CET] <Sesse> 't sound so good :-) [18:11:58 CET] <mfwitten> Well, I figured you were just trying to preserve the images [18:12:15 CET] <mfwitten> Sesse: Otherwise, you'd want to upscale the smaller images in order to preserve the detail in the larger images [18:12:18 CET] <Sesse> it's multi-angle test data [18:12:29 CET] <Sesse> which I'm publishing since it's pretty much impossible to find online [18:12:48 CET] <Sesse> but the cameras changed in the middle of the stream, since one of them had power problems :-) [18:14:01 CET] <mfwitten> So, what did ffmpeg do? Scale smaller images up automatically? [18:14:13 CET] <Sesse> it seems it scaled, yes [18:14:15 CET] <Sesse> up and down [18:14:50 CET] <Sesse> actually, in one of the transcodes, when I started in the middle to test something (with -ss), it chose to convert to 1280x1440 [18:14:53 CET] <Sesse> which is... bizarre [18:14:56 CET] <mfwitten> I see. Well, if I were you, I'd just use the largest dimensions for the whole thing. Maybe explicitly set up scaling so that you can control the quality [18:14:59 CET] <Sesse> (the streams are either 720p or 1080p) [18:15:45 CET] <mfwitten> Sesse: The aspect ratios of 720p and 1080p are different [18:15:56 CET] <mfwitten> Sesse: Maybe it was trying to prevent bad scaling [18:16:11 CET] <Sesse> wait, are they? [18:16:16 CET] <mfwitten> I think... [18:16:22 CET] <Sesse> both should be 16:9 [18:17:41 CET] <mfwitten> Sesse: Sorry. My mistake [18:22:32 CET] <mfwitten> Sesse: What is the output of the following: ffprobe -v quiet -select_streams v:0 -show_streams input.mkv | grep -e ^width= -e ^height= [18:23:01 CET] <mfwitten> Sesse: I'm curious what `ffprobe' says about the dimensions. [18:23:21 CET] <darkdrgn2k> im trying to read a video stream from a camera that uses "Advanced ip-Camera Stream(ACS)". i can get FFMPEG to decode the stream by adding -f h264 in front of the source. However to get this into zonerminder is a bit tricky since it does not use command line. there is a "OPTIONS_FFMPEG" paramater that uses for example "reorder_queue_size=nnn" but f=h264 does not seem to work. [18:23:32 CET] <darkdrgn2k> 1) any one have any idea if tehre is a FFMPEG option that could force the demuxer [18:23:52 CET] <darkdrgn2k> 2) if not any idea how i can use a ffmpeg process to send out an RTSP stream to another process on the same computer [18:24:23 CET] <Sesse> mfwitten: 1280x720 [18:24:39 CET] <mfwitten> Sesse: That's it? Just one? [18:24:45 CET] <Sesse> yes [18:24:48 CET] <Sesse> mfwitten: but I guess the container doesn't really matter in this case [18:24:55 CET] <Sesse> the jpeg frame inside is what matters [18:26:51 CET] <Sesse> it obviously didn't scan anything except the header, unless it read terabytes of data in a few milliseconds [18:26:55 CET] <mfwitten> Sesse: Well, I would have hoped `-show_streams' would be written to account for that fact, but I guess not. There is probably an assumption that the dimensions do not change [18:30:55 CET] <mfwitten> DHE: Was the AV1 encoding worth it? [18:36:31 CET] <mfwitten> darkdrgn2k: Maybe this helps: https://wiki.zoneminder.com/Ffmpeg [18:36:38 CET] <mfwitten> darkdrgn2k: FFMPEG_INPUT_OPTIONS [18:36:57 CET] <darkdrgn2k> yes lots of help :( "usually leave this empty " is all it says [18:37:16 CET] <mfwitten> Well, set it to `-f h264' [18:37:25 CET] <mfwitten> darkdrgn2k: ^^ [18:37:27 CET] <darkdrgn2k> also docs are out of date, there is a module that saves h264 passthrough [18:37:36 CET] <darkdrgn2k> also the format is x=y no -x y [18:37:38 CET] <darkdrgn2k> and didnt seem to work [18:38:24 CET] <mfwitten> darkdrgn2k: That page says to use zmvideo.pl [18:38:50 CET] <darkdrgn2k> that page is also about genering a video AFTER the capture is completed (ie export a video) [18:39:07 CET] <darkdrgn2k> the new module lets you read the video comming of the cam in raw h264 [18:39:12 CET] <darkdrgn2k> (liek i said very out of date) [18:40:01 CET] <mfwitten> darkdrgn2k: Well, perhaps you can send me to documentation that I can read myself. This is the first time I've heard of zoneminder [18:40:08 CET] <mfwitten> darkdrgn2k: This isn't #zoneminder [18:40:34 CET] <darkdrgn2k> mfwitten, yes i know. im trying to see if there was some sort of series of paramaters that where differnt then console for the ffmpeg libraries [18:41:51 CET] <darkdrgn2k> so assuming thats not somethign that is easy to poke at im looking at plan B [18:42:10 CET] <darkdrgn2k> can i feed via the ffmpeg process a RTSP stream to another process on the same computer? [18:47:05 CET] <mfwitten> darkdrgn2k: So, look at this picture: https://zoneminder.readthedocs.io/en/latest/userguide/components.html#syste… [18:47:16 CET] <mfwitten> darkdrgn2k: You're trying to feed a zmc instance? [18:47:33 CET] <darkdrgn2k> correct [18:48:15 CET] <darkdrgn2k> https://zoneminder.readthedocs.io/en/stable/userguide/definemonitor.html#so… [18:48:43 CET] <darkdrgn2k> source is "ffmpeg" which allows zoneminder to record data withouth transcoding it [18:52:48 CET] <mfwitten> darkdrgn2k: Well, the question is what does zmc (or whatever) expect? They're trying to be too cute, hiding what's going on. [18:53:20 CET] <mfwitten> darkdrgn2k: Like you say, you probably need to use RTSP, as that's the only thing mentioned [18:53:34 CET] <darkdrgn2k> it expects a h264 stream [18:53:45 CET] <mfwitten> darkdrgn2k: Does it? Where do you get that information? [18:53:52 CET] <darkdrgn2k> i have one but it include "Advanced ip-Camera Stream(ACS)" that ffmpeg (im guessing) does not like [18:54:11 CET] <darkdrgn2k> the other camera that produces a rtsp 264 stream works [18:54:42 CET] <darkdrgn2k> the real problem is that this camerea is a pos [18:55:08 CET] <darkdrgn2k> and i been poking at it trying to make it workable. I got it to spit out a h264 stream (which is more then anyone has evern done) but im stuck at the next strop [18:55:37 CET] <darkdrgn2k> the issue may be that its getting the h264 stream over http instead of rtsp but its not clear [18:55:37 CET] <mfwitten> darkdrgn2k: Listen, you're not being precise. It's hard to know what's failing in your pipeline. [18:55:51 CET] <darkdrgn2k> because im not sure what fails [18:56:10 CET] <darkdrgn2k> if i pull a feed of the camera, raw ffmpeg does not recognize it [18:56:26 CET] <darkdrgn2k> forcing it with -f h264 produces a viewable video [18:56:41 CET] <darkdrgn2k> that is basically as far as i got [18:56:50 CET] <mfwitten> What is your ffmpeg command line? [18:57:24 CET] <darkdrgn2k> ffmpeg http://admin:@192.168.95.102/video/ACVS-H264.cgi?profileid=1 <- failes [18:57:30 CET] <darkdrgn2k> ffmpeg -f h264 http://admin:@192.168.95.102/video/ACVS-H264.cgi?profileid=1 <- succeeds [18:58:50 CET] <mfwitten> darkdrgn2k: Does this not seem more appropriate: https://zoneminder.readthedocs.io/en/stable/userguide/definemonitor.html#re… [19:00:03 CET] <darkdrgn2k> ffmpeg is the only model that supports h264 passthrough (meaning zoneminder will not de-code then re-encode the data) [19:00:27 CET] <mfwitten> darkdrgn2k: Just for completeness, what exactly is ffmpeg receiving from that URL? [19:00:34 CET] <darkdrgn2k> i have managed to get it working with jpg stills but the quality of the image is much smaller then 1080p [19:01:02 CET] <DHE> <mfwitten> DHE: Was the AV1 encoding worth it? # source video was 1080p@25 and I gave it 1 megabit of video. It actually looks REALLY good [19:01:18 CET] <darkdrgn2k> i have reason to beleave that it is described here [19:01:18 CET] <darkdrgn2k> http://gurau-audibert.hd.free.fr/josdblog/wp-content/uploads/2013/09/CGI_21… [19:01:36 CET] <mfwitten> DHE: Awesome. Thanks. [19:01:40 CET] <darkdrgn2k> page 32 [19:01:47 CET] <darkdrgn2k> "4.1.9.get H.264 video stream" [19:02:05 CET] <DHE> mfwitten: again, it took a week or so in order to encode a 1 minute video [19:02:10 CET] <furq> does aom have any multithreadnig yet [19:02:24 CET] <furq> i'm guessing no [19:02:30 CET] <Sesse> DHE: 1mbit at x264 in placebo is pretty good, too =) [19:02:42 CET] <darkdrgn2k> i evaluated the data commeing out and it seemed to conform to this model [19:02:56 CET] <mfwitten> DHE: Indeed. [19:03:09 CET] <darkdrgn2k> ACS header on page 42 seemed to confirm as well [19:03:15 CET] <mfwitten> darkdrgn2k: looking now [19:03:34 CET] <furq> oh apparently it has row-mt [19:03:45 CET] <furq> i should give it a try [19:04:00 CET] <darkdrgn2k> (i have been trying to get the camrea to respond to a real rtsp stream but it does not seem to work. And i get port 554 as "filtered" during an nmap scan) [19:07:14 CET] <mfwitten> darkdrgn2k: OK, so the IP camera is producing an H.264 stream that ffmpeg is capable of processing; you were able to specify an output file or something and then watch the results? [19:07:32 CET] <darkdrgn2k> yes [19:07:37 CET] <darkdrgn2k> only when i add -f h264 in front [19:07:40 CET] <mfwitten> darkdrgn2k: So, then you want zoneminder to use ffmpeg just like that [19:07:50 CET] <darkdrgn2k> idealy [19:08:08 CET] <darkdrgn2k> alternativly be able to have ffmpeg feed the "cleaned" stream back into zonerminder -vcopy [19:08:44 CET] <mfwitten> darkdrgn2k: Can you make this the source path? -f h264 http://admin:@192.168.95.102/video/ACVS-H264.cgi?profileid=1 [19:08:50 CET] <DHE> Sesse: while I don't think I used placebo (maybe veryslow) I did do the same test with x264 and x265 for the sake of comparing the video. x264 looks pretty good but you can still see the artifacts... [19:08:54 CET] <darkdrgn2k> i tried, it did not work [19:08:55 CET] <mfwitten> (Include the "-f h264" in there [19:09:06 CET] <furq> well row-mt is working great [19:09:13 CET] <furq> using two whole threads for a 720p source [19:09:20 CET] <darkdrgn2k> ` Stream #0:0: Video: h264 (libx264) ([33][0][0][0] / 0x0021), yuv420p, 1920x1080, q=-1--1, 30 fps, 15360 tbn, 30 tbc [19:09:21 CET] <darkdrgn2k> ` [19:09:22 CET] <mfwitten> darkdrgn2k: Well, this zoneminder thing is open source, so let's have a lok [19:09:44 CET] <darkdrgn2k> my cpp foo is not that strong [19:09:45 CET] <darkdrgn2k> https://github.com/ZoneMinder/zoneminder/blob/51f0e7e5c8320d7b855ae3bff8ed4… [19:10:17 CET] <furq> wait never mind it's using one thread [19:10:18 CET] <darkdrgn2k> or rather https://github.com/ZoneMinder/zoneminder/blob/master/src/zm_ffmpeg_camera.c… [19:13:24 CET] <furq> Codec AVOption row-mt (Row based multi-threading) specified for output file #0 (pipe:) has not been used for any stream. [19:13:27 CET] <furq> cool [19:13:56 CET] <furq> -tiles also makes no difference so this is going well so far [19:16:09 CET] <mfwitten> darkdrgn2k: What version of `libavformat' do you have? [19:16:24 CET] <mfwitten> darkdrgn2k: ls /usr/lib/libavformat.so* [19:16:31 CET] <mfwitten> darkdrgn2k: Or the like [19:17:03 CET] <darkdrgn2k> searching 1 sec [19:17:19 CET] <darkdrgn2k> /usr/lib/x86_64-linux-gnu/libavformat.so.57.56.101 [19:19:56 CET] <mfwitten> darkdrgn2k: From a quick glance, it looks like the Source Path field probably gets picked up here: https://github.com/ZoneMinder/zoneminder/blob/master/src/zm_ffmpeg_camera.c… [19:20:15 CET] <darkdrgn2k> yes and options just below it at mOptions( p_options ) [19:20:26 CET] <darkdrgn2k> which i think is defined in .h [19:20:54 CET] <mfwitten> darkdrgn2k: https://github.com/ZoneMinder/zoneminder/blob/master/src/zm_ffmpeg_camera.c… [19:21:04 CET] <mfwitten> See that line? [19:21:13 CET] <mfwitten> I bet that's doing the opening [19:21:43 CET] <mfwitten> If you look below, for older/other versions, it does options processing [19:22:21 CET] <darkdrgn2k> hmm [19:22:44 CET] <mfwitten> darkdrgn2k: Or if you look at the options processing, it seems to only do RTSP [19:22:59 CET] <darkdrgn2k> hmm yeh thast what im looking at here too :/ [19:23:07 CET] <darkdrgn2k> there is a"http tunnel" option but not sure what that is [19:23:08 CET] <darkdrgn2k> *sigh* [19:23:29 CET] <mfwitten> darkdrgn2k: Well, ffmpeg can do that, right? [19:24:12 CET] <darkdrgn2k> so only solution is figure out how to convince the camera to do rtps (which is not going well right now) or have an ffmpeg procses pull the http stream and send it back to ffmpeg as rtsp [19:26:00 CET] <mfwitten> Camera ---rtsp---> zonemine; or, camera ----H.264----> ffmpeg ----RTSP----> zonemine [19:26:05 CET] <mfwitten> darkdrgn2k: ^^ [19:26:11 CET] <darkdrgn2k> pritty myuuch [19:26:49 CET] <darkdrgn2k> or change zoneminder code some how :P but the compile would be a pain lol [19:27:04 CET] <darkdrgn2k> id love to post all this reverse engeering on the dlink forum [19:27:22 CET] <darkdrgn2k> where people are comlpainin how krappy this camera is and support is like "uhh use the android app" lol [19:27:37 CET] <mfwitten> darkdrgn2k: I'm still looking at that code though, because I didn't take a hard look [19:29:02 CET] <darkdrgn2k> and the dam camrea doesnt repond to syn packests on 554 (rtmp :( ) [19:35:32 CET] <mfwitten> darkdrgn2k: Yeah. I'm pretty sure the later stuff, the option-processing stuff, is what's being used, and it's hard-coded to handle only RTSP [19:35:47 CET] <mfwitten> darkdrgn2k: As you say, you could just slip in the right code there directly and re-compile if you want [19:36:41 CET] <mfwitten> darkdrgn2k: However, it would perhaps make more sense just to tell your ffmpeg program to send out RTSP, accessible from localhost:port [19:37:11 CET] <darkdrgn2k> may be a fast way to a solutin for now [19:37:16 CET] <mfwitten> darkdrgn2k: You could use udp, too, to cut down on overhead [19:37:24 CET] <mfwitten> darkdrgn2k: Well, what's your qualm? Unnecessary overhead? [19:37:25 CET] <darkdrgn2k> so any idea how to do that? seems all the attempts i tried have failed so far [19:37:53 CET] <darkdrgn2k> my only concern is reduce cpu overhead a much as possible. [19:38:04 CET] <mfwitten> darkdrgn2k: Actually. [19:38:08 CET] <mfwitten> darkdrgn2k: There's another solution [19:38:11 CET] <darkdrgn2k> o.O [19:38:27 CET] <mfwitten> darkdrgn2k: Maybe you could just have ffmpeg pipe its data to a unix socket, and then open that unix socket as the source path [19:39:20 CET] <mfwitten> darkdrgn2k: ffmpeg -f h264 .... -f h264 unix://<filepath> [19:39:32 CET] <mfwitten> darkdrgn2k: Or something like that [19:39:36 CET] <darkdrgn2k> hmm maybe [19:39:41 CET] <darkdrgn2k> can we try udp or tcp first? [19:39:59 CET] <mfwitten> darkdrgn2k: Really? [19:40:02 CET] <darkdrgn2k> ( was thinking of sockets to but i think going udp/tcp may be easier for now ) [19:40:04 CET] <mfwitten> darkdrgn2k: This seems much better [19:40:15 CET] <darkdrgn2k> i dont know how zoenminder will react to a non rtsp:// source [19:40:49 CET] <mfwitten> darkdrgn2k: Well, the old code just opens a file, and the new stuff just warns if it doesn't know rtsp method being used [19:41:11 CET] <darkdrgn2k> well let me try [19:41:18 CET] <darkdrgn2k> will only take a second to set it up [19:41:21 CET] <mfwitten> darkdrgn2k: You wouldn't even need ffmpeg, potentially, though I'd suggest scaling the input image to make zone* run faster [19:45:05 CET] <mfwitten> darkdrgn2k: ffmpeg -f h264 -i http://sfsadfsfsdkjhsfkjsdhf -f h264 -listen 1 unix:/tmp/socket [19:45:11 CET] <mfwitten> darkdrgn2k: Then use /tmp/socket as the source path [19:46:17 CET] <darkdrgn2k> Stream #0:0: Video: h264 (High), yuv420p(progressive), 1920x1080, 30 fps, 30 tbr, 1200k tbn, 60 tbc [19:46:42 CET] <darkdrgn2k> zoenminder keeps dieing [19:46:42 CET] <darkdrgn2k> Got signal 15 (Terminated), exiting [19:47:08 CET] <darkdrgn2k> hmm [19:47:17 CET] <darkdrgn2k> ffprobe yeilded /tmp/test1: No such device or address [19:48:27 CET] <mfwitten> darkdrgn2k: Sorry, I think I gave you bad advice [19:48:31 CET] <mfwitten> darkdrgn2k: Try this... [19:49:38 CET] <mfwitten> darkdrgn2k: mkfifo /tmp/fifo [19:49:47 CET] <mfwitten> darkdrgn2k: ffmpeg -f h264 -i http://sfsadfsfsdkjhsfkjsdhf -f h264 /tmp/fifo [19:50:00 CET] <mfwitten> darkdrgn2k: add -y to that command [19:50:11 CET] <mfwitten> darkdrgn2k: ffmpeg -y -f h264 -i http://sfsadfsfsdkjhsfkjsdhf -f h264 /tmp/fifo [19:50:18 CET] <mfwitten> darkdrgn2k: Then use /tmp/fifo as the source path [19:50:34 CET] <darkdrgn2k> unix:/tmp/fifo: Address already in use [19:50:52 CET] <darkdrgn2k> wait me dumb [19:52:02 CET] <darkdrgn2k> Priming capture from /tmp/fifo2 then Got signal 15 (Terminated), exiting [19:52:06 CET] <darkdrgn2k> doesnt like sockets [19:52:14 CET] <mfwitten> hmmm [19:52:23 CET] <mfwitten> You didn't use unix:, right? [19:52:27 CET] <darkdrgn2k> correct [19:52:41 CET] <darkdrgn2k> there is only a drop down for tcp udp http or multicast [19:52:42 CET] <mfwitten> darkdrgn2k: Ah, man! I thought we had it with that [19:52:46 CET] <mfwitten> ok [19:52:52 CET] <mfwitten> Then we know what to do [19:53:24 CET] <darkdrgn2k> tcp or udp rstp [19:53:30 CET] <mfwitten> udp [19:53:51 CET] <mfwitten> darkdrgn2k: There's no worry about bad transmission conditions [19:54:03 CET] <darkdrgn2k> correct [19:56:45 CET] <darkdrgn2k> i never had any luck getting ffmpet to push out rtsp [20:03:02 CET] <mfwitten> darkdrgn2k: The documentation is a little wonky. [20:03:19 CET] <darkdrgn2k> not as wonky as zoneminders :P [20:04:38 CET] <mfwitten> darkdrgn2k: It seems like either you need to run a separate RTSP server to which you can send data and which can then transmit it to zoneminder, or somehow set up something (like the fifo we tried) to act like source for zoneminder (although this time delivering rtsp data). [20:08:57 CET] <mfwitten> darkdrgn2k: Hey. When we tried the FIFO, you never got the message "Unknown method", right? [20:10:05 CET] <mfwitten> darkdrgn2k: Maybe try the fifo again, but set the method to something unknown (e.g., "pleasejustwork") [20:10:46 CET] <mfwitten> darkdrgn2k: Then the code won't try to set rtsp_transport, and maybe it will just open it as a file [20:18:06 CET] <mfwitten> darkdrgn2k: https://github.com/revmischa/rtsp-server [20:18:20 CET] <mfwitten> darkdrgn2k: See the README there [20:20:02 CET] <mfwitten> darkdrgn2k: I would use `--clientport' to avoid running as root [20:22:22 CET] <mfwitten> darkdrgn2k: So, run `rtsp-server --clientport 1234 --sourceport 4321' (or the like), and then `ffmpeg -f h264 -i http://sdfasfsdf -f rtsp -muxdelay 0.1 rtsp://127.0.0.1:4321/video' [20:23:38 CET] <mfwitten> darkdrgn2k: And then tell zoneminder the source path is `rtsp://127.0.0.1:1234/video' [20:24:02 CET] <darkdrgn2k> shouldnt setting zoneminder for UDP accept a udp stream? [20:26:46 CET] <mfwitten> darkdrgn2k: And, I guess, zoneminder should be set up to use tcp [20:26:59 CET] <darkdrgn2k> but if i do udp [20:27:03 CET] <darkdrgn2k> cant i bypass the server? [20:29:02 CET] <mfwitten> darkdrgn2k: I don't think ffmpeg acts as an RTPS server; it can act as a source for a server [20:29:09 CET] <mfwitten> darkdrgn2k: or it can act as a client to a server [20:30:37 CET] <mfwitten> camera ----H.264 over HTTP----> ffmpeg ---- RTPS source----> rtps-server ----RTPS service---> zoneminder [20:32:53 CET] <darkdrgn2k> im wondering if ffmpeg can act as a server.. [20:33:43 CET] <mfwitten> darkdrgn2k: I'm pretty sure it cannot. It's a muxer that can send data to a server [20:36:31 CET] <mfwitten> darkdrgn2k: Alternatively, did you try the fifo method again while setting the RTSP method to gibberish? [20:55:15 CET] <darkdrgn2k> i found another url that actaulyl works1 [20:58:15 CET] <mfwitten> darkdrgn2k: Good [20:58:31 CET] <darkdrgn2k> undocumented [20:58:33 CET] <darkdrgn2k> as everthing' [20:58:37 CET] <darkdrgn2k> kinda jittery but [20:58:37 CET] <mfwitten> indeed [20:58:47 CET] <mfwitten> What does it produce? [20:58:54 CET] <mfwitten> What does that URL yield? [20:59:35 CET] <darkdrgn2k> mpegts [20:59:35 CET] <darkdrgn2k> Stream #0:0[0x100]: Audio: aac (LC) ([15][0][0][0] / 0x000F), 16000 Hz, mono, fltp, 20 kb/s [20:59:36 CET] <darkdrgn2k> Stream #0:1[0x101]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(progressive), 1920x1080, 30 fps, 30 tbr, 90k tbn, 60 tbc [21:00:24 CET] <mfwitten> And so what are you doing with that? [21:00:41 CET] <darkdrgn2k> fead it into zonerminder [21:00:43 CET] <darkdrgn2k> and it pickled it up [21:00:54 CET] <darkdrgn2k> but it plays a few frames then stalls for a second plays a few frames stalls. [21:01:43 CET] <^Neo> can anyone point me to an example aviocontext usage where I'm writing data into from an AVPacket data field? [21:01:46 CET] <mfwitten> darkdrgn2k: Basically, it just thinks its a ".ts" file on the server? [21:02:03 CET] <darkdrgn2k> i guess so [21:02:56 CET] <darkdrgn2k> lol announces the langth as Length: 99999999999 (93G) [video/mpeg] [21:02:57 CET] <darkdrgn2k> lol [21:03:13 CET] <mfwitten> :-) [21:03:40 CET] <mfwitten> darkdrgn2k: Have you tried the fifo method again, albeit with a gibberish "RTSP" transport method? [21:04:31 CET] <darkdrgn2k> not yet i will though [21:04:32 CET] <darkdrgn2k> report back [21:08:00 CET] <grayhatter> I'm using swresample, and when playing back the audio, it seems to play at the wrong sample rate. When I use swr_alloc_set_opts(..., in_rate / 4, ...); it sounds closer, but still distorted... I'm out of ideas, anyone have any thoughts? [21:08:44 CET] <durandal_1707> grayhatter: make sure you use right sample format [21:09:09 CET] <wfbarksdale> Hey folks, I am working on a c++ wrapper around muxing / demuxing using ffmpeg (2.8 blech). I am trying to initialize an output context for an mp4 container to mux to, but I am seeing the output "Codec for stream 0 does not use global headers bug container format requires global headers" [21:09:22 CET] <grayhatter> when I use the correct sample rate it plays bake super distorted, and what seems like REALLY sped up [21:09:25 CET] <wfbarksdale> does anyone know what i need to set when initializing my streams to make this work? [21:09:39 CET] <grayhatter> as I said, when I use the wrong rate, it sounds closer to correct, but still distorted [21:10:16 CET] <grayhatter> plays back* [21:11:30 CET] <mfwitten> darkdrgn2k: I don't know whether the GUI allows for changing things, but the code suggests it loads options (like your desired `-f h264') from a MySQL database: https://github.com/ZoneMinder/zoneminder/blob/9f588d5758b57c187f71a348370f9… [21:13:04 CET] <mfwitten> darkdrgn2k: If you can manipulate the MySQL database entry for this monitor you're setting up, then you can pass whatever you want [21:14:06 CET] <mfwitten> darkdrgn2k: https://github.com/ZoneMinder/zoneminder/blob/9f588d5758b57c187f71a348370f9… [21:14:20 CET] <darkdrgn2k> ill have to check thank you [21:14:22 CET] <mfwitten> darkdrgn2k: That's the table layout and SQL needed [21:18:42 CET] <grayhatter> figured it out, I needed to convert the number of samples * NUM_CHANNELS to bytes, then to frames for alsa [21:44:56 CET] <mfwitten> darkdrgn2k: I take it back about being able to add `-f h264' somewhere; that appears to be an `ffmpeg' option. Look at the 3rd argument here: https://github.com/ZoneMinder/zoneminder/blob/51f0e7e5c8320d7b855ae3bff8ed4… [21:45:15 CET] <mfwitten> darkdrgn2k: It's NULL. That's the format you want to use (i.e., the `h264' demuxer) [21:46:07 CET] <mfwitten> darkdrgn2k: So, either a gibberish RTPS transport method combined with a FIFO will work, or you'll have to set up the RTPS server [21:46:17 CET] <mfwitten> darkdrgn2k: (or edit the source code) [21:46:57 CET] <mfwitten> darkdrgn2k: (To clarify, the `NULL' means that no format can be specified explicitly) [22:44:36 CET] <mfwitten> darkdrgn2k: I don't know whether you're still working on this problem, but I've come up with another idea that seems obvious in retrospect. [22:45:53 CET] <mfwitten> darkdrgn2k: You could read your H.264 stream into ffmpeg, and write out to the fifo an mpegts; that way, when you open the fifo as a source path, it will have enough container information to satisfy the missing format info [22:46:33 CET] <darkdrgn2k> mfwitten, hmm interesting i wanna play with those just to see what happens :) [22:46:43 CET] <darkdrgn2k> its great solutions to other issues i had before where ffmpeg would come in [22:46:55 CET] <darkdrgn2k> for now im ttying to solve anotehr zoneminder related issue :/ [22:47:10 CET] <darkdrgn2k> seems in "pass throguh" mode it jitters in encode mode its fine ~*shur*~ [22:47:45 CET] <mfwitten> darkdrgn2k: mkfifo /tmp/fifo [22:48:07 CET] <mfwitten> darkdrgn2k: ffmpeg -y -f h264 -i http://asfasdfsdafsd -vsync passthrough -enc_time_base -1 -c:v copy -bsf:v h264_mp4toannexb -f mpegts /tmp/fifo [23:10:34 CET] <friendofafriend> If you had a video clip and you wanted to duplicate its encoding settings, what tool would you use? ffprobe? [00:00:00 CET] --- Thu Feb 7 2019

1 0

ffmpeg-devel.log.20190205
by burek 06 Feb '19

06 Feb '19

[00:45:05 CET] <llogan> what's the minimum supported nasm version? [00:48:06 CET] <nevcairiel> probably something ridicoulously old [00:48:45 CET] <nevcairiel> according to some commits, 2.09 from 2010 should still work at the very least [00:49:15 CET] <nevcairiel> apparently we're supposed to support all the way back to nasm 2.03 from 2008 [00:51:16 CET] <llogan> assisted living for the elderly [00:52:19 CET] <jamrial> i don't think something that old works by now, but the minimum requirement in configure is a version with movbe support [00:53:32 CET] <nevcairiel> the above was from a statement from not too long ago, i'm not sure we changed anything fundamental since then [00:54:34 CET] <jamrial> some code might have been committed that doesn't work with a version that old. i don't think there's a fate test with it [00:55:05 CET] <nevcairiel> i guess [00:55:15 CET] <jamrial> i'll try a build with 2.08 [00:55:16 CET] <nevcairiel> there were fixes for at least 2.09 back in 2017 still [00:57:52 CET] <nevcairiel> finding out the nasm version on fate boxes is apparently impossible [01:02:27 CET] <llogan> for the wiki i'll just assume any nasm used in the currently supported ubuntu/debian repos will work. oldest is 2.10, but that distro version is going away 30 april then it will be 2.11. [01:03:46 CET] <nevcairiel> hm apparently i updated nasm on my debian build box [01:03:58 CET] <nevcairiel> i was trying to check which one i used there :D [01:04:31 CET] <llogan> 2.13.03 didn't like gcc 8 [01:04:52 CET] <nevcairiel> for some reason latest nasm also doesnt like s ome windows tools [01:05:11 CET] <nevcairiel> could never figure out whats up with that [01:05:52 CET] <nevcairiel> so i'm still building iwth yasm :) [01:06:24 CET] <llogan> looks like 2.03 got movbe [01:32:11 CET] <jamrial> well, 2.08 doesn't work [01:32:29 CET] <jamrial> guess now we know what to expect from 2.03 :p [01:33:18 CET] <jamrial> nevcairiel: i can build mingw-w64 with nasm 2.14 just fine [01:34:22 CET] <nevcairiel> mingw is fine [01:34:28 CET] <nevcairiel> msvc is what breaks [01:34:37 CET] <nevcairiel> for some reason the linker freaks out on some nasm object files [01:34:40 CET] <nevcairiel> or well it used to [01:34:45 CET] <nevcairiel> updated nasm and msvc since then [01:40:31 CET] <llogan> jamrial: thanks for testing. only disto using something older that i know of is CentOS 6 with 2.07. [01:42:51 CET] <jamrial> guess they force yasm [01:43:17 CET] <nevcairiel> their ffmpeg is also older then our switch to nasm default [01:43:25 CET] <nevcairiel> built-in one anyway [08:27:55 CET] <cone-725> ffmpeg 03Lauri Kasanen 07master:fc6022e1088d: avutil/ppc/cpu: Fix power8 linux detection [08:33:39 CET] <cone-725> ffmpeg 03Lauri Kasanen 07master:8522d219ce80: libswscale/ppc: VSX-optimize 9-16 bit yuv2planeX [09:17:39 CET] <JEEB> alright, so there's opposition to aribb24 library being utilized. time to see if I can at least get some of the AVCodec/demuxing stuff in since I'd rather like things to go in in pieces :/ [09:18:02 CET] <JEEB> since if we're going to start bringing in swathes of code that's going to take a while for anyone to review [09:19:59 CET] <JEEB> and if we go bit by bit people will ask why something's being added if it's not necessarily being used yet (like I'd like to get the ARIB STD-B24 text conversion in first, and then the actual subtitle decoding which requires the former) [09:20:27 CET] <JEEB> (the text decoding can be utilized for metadata encoding, but then we go into the mess that is "pick your MPEG-TS broadcast mode" :P [09:20:35 CET] <JEEB> *metadata decoding [09:23:02 CET] <JEEB> I already had patches doing similar stuff that VLC is doing for trying to probe ARIB-defined MPEG-TS muxes by certain things in the PMT, and to convert the metadata from ARIB STD-B24 to UTF-8 [09:23:23 CET] <JEEB> but I thought I'd ease the whole thing by first getting the subtitle demuxing in first :P [09:23:51 CET] <JEEB> (since finding ARIB captions in MPEG-TS is a most obvious hint that it's ARIB specified) [09:24:33 CET] <JEEB> I guess when I have actual time to formulate a proper response on the ML I will try to poke carl on what is his idea of going forward with this [09:25:19 CET] <JEEB> because it's one thing saying "I am against this" and another to be able to help people move forward to a place of common understanding [18:25:18 CET] <JEEB> phew [18:25:23 CET] <JEEB> that took a while to write down [18:25:37 CET] <JEEB> and to be honest, I don't want to throw what I've done so far into the garbage bin [18:25:51 CET] <Taripe> ? [18:26:02 CET] <JEEB> carl was against using libaribb24 [18:26:07 CET] <Taripe> Ah that [18:26:31 CET] <JEEB> so I did write a full step-by-step thing towards a LGPLv2.1+ decoder, but geeez [18:26:50 CET] <durandal_1707> ignore carl [18:27:03 CET] <JEEB> although if that's what it takes to at least get the demuxing parts in, at least that gets in :V [18:40:03 CET] <atomnuker> just ignore it, its packaged by debian which is definitely good enough [18:47:55 CET] <JEEB> atomnuker: I will prod michaelni or so if there really is a stallmate :P [19:15:41 CET] <JEEB> I love it how people tell me that they don't even apply for FFmpeg in GSoC because of the opinion they have regarding the mailing list. [19:15:48 CET] <JEEB> or more like, I don't love it [19:16:16 CET] <JEEB> just had someone mentioned it off-hand that he skipped trying to contribute because he felt the community was toxic :D [19:16:28 CET] <JEEB> *mention [19:17:51 CET] <JEEB> and this stuff is sad because what we need are capable, thinking newcomers [20:36:02 CET] <durandal_1707> we need only Carl [21:49:37 CET] <durandal_1707> lets create FFmpeg: most commits award! [22:43:24 CET] <Mathieu_Du> Hey, please correct me if I'm mistaken, but the mpeg-2 encoder doesn't take side_data into account (eg A53 CC) right? [22:44:26 CET] <JEEB> git grep "SIDE_DATA" libavcodec/mpegvideo_enc.c [22:44:28 CET] <JEEB> gives nothing [22:44:37 CET] <JEEB> so I would say it doesn't support closed captions [22:44:51 CET] <Mathieu_Du> yeah I was looking at the source too (with -i :P) [22:44:59 CET] <Mathieu_Du> seems nvenc does inject it as SEI [22:45:17 CET] <JEEB> the newer format encoders do take it in [22:45:22 CET] <JEEB> started with libx264, IIRC [22:45:31 CET] <Mathieu_Du> I see, too bad but thanks :) [22:45:37 CET] <Mathieu_Du> I'll figure out some other way [22:46:07 CET] <JEEB> I have no idea if the data is similar, but you could try implementing it? [22:47:50 CET] <Mathieu_Du> It's really similar, but it's not easy for me to test it, I'm using FFmpeg through gstreamer, built against my system wide FFmpeg [22:48:28 CET] <JEEB> in the worst case you could try passing a source with captions through ffmpeg.c? [22:48:29 CET] <Mathieu_Du> guess I could dust off my meson port :P [22:49:39 CET] <Mathieu_Du> hrm, what do you mean ? [22:51:31 CET] <JEEB> if you have an input stream that can be read and FFmpeg can parse the captions from into side data [22:51:36 CET] <JEEB> then ffmpeg.c is able to pass that through [22:51:43 CET] <JEEB> when you re-encode it [22:52:02 CET] <JEEB> so you re-encode with libx264 and check if it's in the output. if it is, you've got yer test case [22:52:15 CET] <JEEB> then you start poking at the mpeg-2 stuff and see if it gets passed [22:53:07 CET] <Mathieu_Du> Well that's pretty much my setup already [22:53:30 CET] <JEEB> ok, then I didn't fully get what your issue was [22:53:38 CET] <Mathieu_Du> I'm getting the CC as side_data from the decoder all right [22:53:53 CET] <JEEB> since that should validate your implementation if you do one [22:54:55 CET] <Mathieu_Du> I can pass that to libx264 in the gstreamer wrapper and I get the expected result, but I was trying to do roughly the same in the gstreamer ffmpeg wrapper around the mpeg2 encoder and no luck [22:55:03 CET] <Mathieu_Du> (using av_frame_new_side_data) [22:56:14 CET] <BtbN> Can't you just use normal captions instead? [22:56:40 CET] <BtbN> I'm still not sure why CC are a thing [22:56:40 CET] <Mathieu_Du> nope :) [22:56:56 CET] <Mathieu_Du> broadcasting industry kind of likes them afaiu :) [23:00:59 CET] <nevcairiel> CC is mandatory in the US, because they forgot to spec proper subtitles [23:01:19 CET] <nevcairiel> and its demanded by law that they are present or something [23:01:59 CET] <BtbN> So everyone has to live with forced subtitles there? oO [23:02:49 CET] <nevcairiel> its only mandatory that they are present [23:02:52 CET] <nevcairiel> you dont have to turn them on [23:02:58 CET] <JEEB> they're not mandatory to turn on, yea [23:03:08 CET] <BtbN> At least my TV shows them without choice when present [23:03:09 CET] <JEEB> but they're really used. I laughed out loud when the ADS had captions [23:03:45 CET] <JEEB> nevcairiel: and now with web streaming I'm beginning to think that with live streams US style closed captions are the only sane way... [23:03:51 CET] <JEEB> and I hate to admit that [23:04:13 CET] <BtbN> well, as everything is still using rtmp for that stuff, it's the only caption kind it can carry [23:04:20 CET] <nevcairiel> i dont remember if they specced something for ATSC 3.0 [23:04:25 CET] <nevcairiel> but that standard is terrible anyway [23:04:29 CET] <nevcairiel> its like DASH for broadcast [23:04:30 CET] <BtbN> Can there even be multiple CC streams? Like, multiple languages? [23:04:56 CET] Action: Mathieu_Du didn't want to reopen old wounds, sorry :P [23:05:03 CET] <BtbN> I remember people in #videolan talking about stuff in IPv6 in mpegts [23:05:09 CET] <nevcairiel> (literally DASH, they get the manifest etc from a web host, and only stream the main media data through the broadcast afaik) [23:05:24 CET] <BtbN> what? [23:05:37 CET] <BtbN> So if you're offline, no TV for you? [23:05:50 CET] <JEEB> MMTP yo [23:06:10 CET] <JEEB> let me find my X over Y thing for MMTP [23:08:51 CET] <nevcairiel> they can also send you targeted ads from the web andshit like that, its really a terrible concept for broadcast, but everything is going web anyway [23:09:31 CET] <JEEB> anyways, it's TLV (ip over broadcast) -> UDP multicasts -> you find out the index by a broadcast standard specific multicast address -> then you listen for different ISOBMFF parts over UDP multicast from the ones marked in the index [23:09:35 CET] <JEEB> if I recall correctly [23:09:55 CET] <JEEB> and the ISOBMFF parts can then also contain stuff like XML indices etc [00:00:00 CET] --- Wed Feb 6 2019

1 0

ffmpeg.log.20190205
by burek 06 Feb '19

06 Feb '19

[00:03:19 CET] <turnage> I am using libavcodec to encode and would like to know the size of buffer I ought to prepare for a receive_packet call. In the examples they use constants and I do not know how they are chosen. Can libavcodec provide me a reasonable hint, or does the buffer size I provide inform libavcodec on how to size its packets? [00:26:11 CET] <DHE> the AVPacket will be prepared by the codec. You can just do "AVPacket *pkkt = av_packet_alloc(); int code = avcodec_receive_packet(avc_context, pkt);" and go with it [00:26:24 CET] <DHE> just be sure to free it properly afterwards (where applicable) [00:33:58 CET] <turnage> I want to prepare the buffers myself; I need to share them with another process and can't afford the copy. [02:05:52 CET] <brimestone> Hey guys, anyone here knows of a streaming server that works with ffmpeg -re and has less than 2 second delay? [02:15:42 CET] <DHE> rtmp is probably the best you can hope for, but encoder settings are important. not -tune zerolatency, but there are other options for x264 [09:34:35 CET] <botik101> hello, I hgaev a question about using select between. My command allows me to cut out segments from video, but it does not cut audio. Can someone please help [09:35:45 CET] <botik101> I am trying: ffmpeg -i /tmp/inputvideo.mp4 -vf "select='between(n,1264, 4244) +between(n,20663, 20664)',setpts=N/FRAME_RATE/TB" /tmp/out.mp4 [09:35:58 CET] <botik101> it cuts video but audio remains the same [09:38:07 CET] <friendofafriend> botik101: -vf is for "video filter". [09:38:36 CET] <botik101> how do i tell it to cut both video and audio? If I replace -vf with -filter it tells me it @cannot connect video filter to audio output@ [09:39:20 CET] <botik101> friendofafriend: yes, thank you! I noticed it. I tried using -filter but then it gives me "cannot connect video filter to audio output". How do I rip out both video and audio ? So confused [09:40:34 CET] <friendofafriend> I believe that is the "aselect" filter. [09:42:35 CET] <botik101> friendofafriend: so you are saying i should use -vf AND -af in the same string and repeat SELECT BETWEEN twice [09:42:40 CET] <friendofafriend> There are some pretty good examples over here. https://superuser.com/questions/866144/cutting-videos-at-exact-frames-with-… [09:43:50 CET] <botik101> friendofafriend: yes, thak you. I saw that. It still does not tell you how to cut both video and audio in one line [09:43:54 CET] <friendofafriend> Also pretty good material here, specifying an -af and -vf. https://video.stackexchange.com/questions/17164/accurate-audio-selection [09:46:57 CET] <botik101> friendofafriend: trying! :) [09:48:48 CET] <friendofafriend> botik101: Good luck to you, botik101! [09:58:53 CET] <botik101> ffmpeg -i /tmp/input.mp4 -vf "select='between(n,1264, 4244)+between(n,20663, 20664)',setpts=PTS-STARTPTS" -af "aselect='between(n,1264, 4244)+between(n,20663, 20664)',asetpts=PTS-STARTPTS" -y -strict -2 /tmp/out.mp4 [09:59:27 CET] <botik101> friendofafriend: nope....still the same problem [10:15:04 CET] <botik101> almot [10:23:09 CET] <botik101> guys, I still do not have audio being cut correctly in this case: [10:23:50 CET] <botik101> ffmpeg -i /tmp/input.mp4 -vf "select='between(n,1264, 4244)+between(n,20663, 20664)',setpts=N/FRAME_RATE/TB" -af "aselect='between(n,1264, 4244)+between(n,20663, 20664)',asetpts=N/SR/TB" -y -strict -2 /tmp/out.mp4 [10:24:41 CET] <botik101> audio does not start anywhere near video frame and abruptly ends midway through the final video. what am I doing wrong [10:26:05 CET] <durandal_1707> botik101: audio frames numbers are not same as video ones [10:26:37 CET] <durandal_1707> you can not use n, use pts [10:32:21 CET] <botik101> durandal_1707: wxcwkkwbr~ [10:32:41 CET] <botik101> durandal_1707: thanks! trying it now! [10:36:52 CET] <durandal_1707> you need to make sure pts timebase of audio and video is same [11:58:57 CET] <X-Kent> Hello, I cannot figure out how to correctly transcode segments of the HLS stream. I want to transcode each segment individually while preserving all the stream information. To eliminate possible codec problems I for now use "copy". My ffmpeg command is "ffmpeg -i in_segment_i.ts -map 0:0 -map 0:1 -map 0:2 -c:v copy -c:a copy -f mpegts -copyts out_segment_i.ts". When I try to play the stream with ffmpeg I get "Continuity check failed [11:58:57 CET] <X-Kent> for pid 17 expected 7 got 0". It doesn't happen in the source stream. [12:00:14 CET] <X-Kent> I used the map to preserve stream 0 as it is a "timed_id3" stream and it gets stripped off if I don't use map. [12:01:39 CET] <X-Kent> The stream is a live stream. The playback works in general but sometimes (like every minute) there a slight freeze. I believe that's because I don't copy some metadata. Do I need to copy something other than what "copyts" does ? [12:03:01 CET] <X-Kent> I tried setting GOP to 25 (stream is 50fps), tryed "-vsync 0". No effect. [14:10:45 CET] <th3_v0ice> Is it possible to create fake input file using API? Like specify the number of streams and decoders and everything? [14:13:47 CET] <JEEB> yes [14:14:54 CET] <th3_v0ice> Stupid question. Sorry :) [16:40:48 CET] <th3_v0ice> JEEB: In order to create this fake file, what do you think appropriate methods and order of calling them would be? I currently have avformat_allo_context, and then avformat_new_stream() and avcodec_parameters_copy(). Is anything else needed? avio_open or something? [16:58:44 CET] <JEEB> th3_v0ice: depends on what exactly you want to create [17:07:28 CET] <th3_v0ice> Well, I have input file that has 10 streams and I want to create fake file, which will only have 2 streams from the original 10 in the original input file. I will copy the decoder contexts and stream properties. I would like to copy all that is possible to copy so that the fake input file will have everything the same except number of streams. [17:17:01 CET] <th3_v0ice> JEEB: Currently I get segmentation fault because AVFormatContext->iformat is NULL in the fake file I created. [17:18:43 CET] <kepstin> why do you need a fake file? can't you just ignore the streams you don't want to read from the input? [17:21:17 CET] <th3_v0ice> I was using that tehnique and currently its limiting me. I need to create a fake file. [17:29:03 CET] <th3_v0ice> Copying the AVFormatContext->iformat's pointer seems to be creating a proper fake file. At least av_dump_format() prints everything as it should. I dont know if this can have some consequences. [17:43:18 CET] <kepstin> I suspect you might get issues with double-frees when trying to tear this all down. There might not be any way to do this "properly" without access to ffmpeg private functions/structures. [17:47:45 CET] <JEEB> th3_v0ice: I was more interested in what exactly do you want to test. [17:47:56 CET] <JEEB> do you want to test your iteration etc logic based on AVStreams etc? [17:48:16 CET] <JEEB> or do you want to just have a test initialization etc from X decoders etc [17:50:13 CET] <JEEB> if you really really want to emulate an AVFormatContext, then there's two ways: either use your own data through an AVIO context, or make a thing in libavformat that lets you filter etc the input data (but it requires an actual input file for that) [17:50:43 CET] <JEEB> so really, I would generate the required data and use AVIO context if I need to test the whole API client logic without changing things [18:03:17 CET] <kepstin> if this is for tests, I'd probably just use ffmpeg cli to remux the input file to a temporary file on disk before running the test. [18:03:35 CET] <kepstin> (or run ffmpeg in a subprocess, piped to your test program's input) [18:08:46 CET] <JEEB> the movenc tests have pre-generated H.264 headers etc [18:09:15 CET] <JEEB> so in a similar way if you pre-generate some data to be demuxed you can always feed that to lavf through AVIO [18:48:01 CET] <turnage> Can I peek at or configure the size of packets that will be written during encoding with libavcodec in calls to receive_packet before actually writing the bytes? [19:16:23 CET] <turnage> I see an option called packetsize in the options table. Does this refer to encoder the size of packets output by encoders? [19:17:21 CET] <DHE> where's this? [19:18:08 CET] <turnage> https://github.com/FFmpeg/FFmpeg/blob/8522d219ce805ce69ff302f259e6f083fdb48… [19:18:30 CET] <turnage> actually this may not have anything to do with libavcodec [19:18:33 CET] <DHE> well that's libavformat, and second not all formats will handle that. just ones where it makes sense [19:18:59 CET] <turnage> is there an options for it in libavcodec? [19:19:11 CET] <DHE> how would it work? [19:19:39 CET] <DHE> packets are encoded data. you don't set that directly. you might be able to set the bitrate but there's still going to be variance [19:19:51 CET] <kepstin> most codecs don't know how big the packet will be until it's done encoding it, so... (there's some special cases for constant bit rate which are configured with codec-specific options) [19:20:11 CET] <JEEB> in other words, start with the use case explanation [19:20:36 CET] <JEEB> after we figure out the use case we can see if there's a better way of doing it [19:20:37 CET] <JEEB> :P [19:20:40 CET] <turnage> helpful info. An upper bound for h264 encoded packet sizes with a known target variable bitrate is what I'd like [19:20:58 CET] <JEEB> just use VBV/HRD [19:21:05 CET] <JEEB> aka -maxrate and -bufsize [19:21:20 CET] <JEEB> that makes sure that over bufsize the average rate is max maxrate [19:21:26 CET] <DHE> there are strategies to reduce the bursts, like intra_refresh instead of regular keyframes but that one has some pretty serious downsides [19:21:42 CET] <JEEB> that does work with libx264, for example [19:21:45 CET] <kepstin> note that vbv doesn't have a limit on encoded frame size directly, but i think it requires that any given frame is no bigger than the buffer. [19:21:51 CET] <JEEB> other encoders... mileage may vary [19:22:43 CET] <turnage> it's probably invariant in h264 that any given packet is smaller than an uncompressed frame yes? [19:22:55 CET] <kepstin> turnage: not specifically required. [19:23:11 CET] <kepstin> why do you need this anyways? [19:23:38 CET] <kepstin> ffmpeg allocates the right amount of memory for packets for you, you don't need to care in most cases. [19:24:25 CET] <turnage> I'm working in a multiprocess pipeline that needs to agree on buffer sizes ahead of time. [19:24:57 CET] <turnage> Looks like I may just have to estimate up and suffer a copy on occasion though. [19:25:29 CET] <kepstin> oh, you're doing some sort of shared memory thing? [19:25:33 CET] <turnage> yeah [19:27:39 CET] <kepstin> Hmm, so you're using a fixed size shared buffer rather than changing ownership of memory pages between processes? [19:35:11 CET] <turnage> Yeah; it's a pipeline of vmos: https://fuchsia.googlesource.com/zircon/+/HEAD/docs/objects/vm_object.md [19:36:09 CET] <kepstin> hmm, so roughly analogous to mmaping a "file" on /dev/shm on linux then. Resizable, that's good. [19:37:09 CET] <turnage> Thanks for the helpful info. I'll deal with a copy for now. It may be possible to get RT even with the copies and I'll revisit later if not. [19:37:37 CET] <kepstin> how are you convincing the encoder to write the frame into your smh block, anyways? [19:38:03 CET] <turnage> I map it into the process: https://fuchsia.googlesource.com/zircon/+/HEAD/docs/objects/vm_address_regi… [19:38:25 CET] <turnage> then make an AVBuffer backed by it [19:39:57 CET] <kepstin> hmm, right, if the destination avpacket contains a preallocated buffer, then it'll be used if it's big enough. [19:45:34 CET] <kepstin> it looks like if the buffer is too small, the encoder functions will automatically allocate a new buffer and use that instead :/ [19:46:03 CET] <turnage> lol [19:50:02 CET] <kepstin> best thing I can think of is that if the packet the encoder gives you back has a reallocated buffer, then your buffer was too small and you should resize it larger for next time. [19:50:19 CET] <kepstin> should at least limit the number of copies you have to do. [19:52:45 CET] <turnage> that's a good idea, kepstin [19:54:18 CET] <kepstin> it would require a bit of experimenting to pick a reasonable initial buffer size. Same as frame size should certainly cover 99.99% of encoded frames, you could probably pick something smaller (but how much? I dunno) [19:56:43 CET] <turnage> yeah I foresee a lot of math in that optimization problem. Whatever I end up needing to get RT, I'll come back and let you know how it went. [20:20:19 CET] Action: kepstin didn't know that the fuchsia kernel was to the point where people were actually trying to build apps using ffmpeg on it, that's kinda neat [20:23:21 CET] <JEEB> oh, that's from fuchsia? funky [20:30:31 CET] <LunaLovegood> Is there a way to make avcodec_send_packet() and avcodec_receive_frame() act like blocking i/o functions? Like I'd have a thread that simply sends packets in a loop, and another thread that would receive decoded frames. ? [20:31:19 CET] <turnage> that is what I do but I use a signal to block [20:31:38 CET] <turnage> e.g. send on one thread, then signal to the other thread to unblock and receive until EAGAIN [20:31:55 CET] <turnage> e.g. with conditional variable [20:32:17 CET] <LunaLovegood> oh right. that makes sense. I guess I'll just write wrapper functions like that. [20:33:03 CET] <kepstin> LunaLovegood: you can't call functions on a single avcodeccontext from different threads without taking care of any required synchronization yourself. [20:33:22 CET] <kepstin> but you can send avframe and avpacket structures safetly across frames [20:33:26 CET] <kepstin> across threads* [20:34:37 CET] <kepstin> so i'd probably suggest using some sort of bounded length threadsafe queue with blocking operations to transfer either frames or packets between threads [20:34:47 CET] <LunaLovegood> alright [20:36:10 CET] <LunaLovegood> do ffmpeg's decoding threads run in the background, or are they only active until avcodec_send_packet or avcodec_receive_frame returns? [20:36:44 CET] <LunaLovegood> err. not that it should matter much since I'll be calling those functions often enough. sorry. [20:38:32 CET] <kepstin> i don't actually know, tbh. It might depend on the particular codec. [20:39:14 CET] <turnage> could be wrong but I don't think threads will be spun up without you asking [20:39:36 CET] <turnage> ime work happens on the receive side [20:39:56 CET] <turnage> and the buffers from send need to stay alive while referenced which may be long after the corresponding data has been received [20:40:05 CET] <kepstin> default for codecs that support it is to do multithreaded decoding (you can override this by setting threads to 1 in the context iirc [20:40:10 CET] <kepstin> ) [20:40:35 CET] <turnage> oh interesting I didn't know default wasn't 1. [20:40:40 CET] <kepstin> and the ffmpeg buffer/frame api takes care of keeping data alive, you don't need to do anything special [20:41:10 CET] <kepstin> (buffers are actually thread-safe reference counted) [20:43:43 CET] <DHE> it will vary by codec, but the most popular ones usually support multi-threading [21:35:39 CET] <BtbN> LunaLovegood, you can't do that unless you lock every call with a mutex for that context. Which removes most benefits, since you end up waiting for it to finish again anyway. [00:00:00 CET] --- Wed Feb 6 2019

1 0

ffmpeg-devel.log.20190204
by burek 05 Feb '19

05 Feb '19

[00:50:34 CET] <cone-126> ffmpeg 03Michael Niedermayer 07release/4.1:62f5325ca30a: avcodec/ilbcdec: Fix integer overflow in construct_vector() [00:50:35 CET] <cone-126> ffmpeg 03Michael Niedermayer 07release/4.1:d8b8b27dc312: avcodec/ilbcdec: Fix undefined integer overflow lsf2poly() [00:50:36 CET] <cone-126> ffmpeg 03Michael Niedermayer 07release/4.1:f5c9753bfdab: avcodec/fic: Check that there is input left in fic_decode_block() [00:50:37 CET] <cone-126> ffmpeg 03Michael Niedermayer 07release/4.1:0f1332309aff: avcodec/rasc: Check uncompressed dlta size [00:50:38 CET] <cone-126> ffmpeg 03Michael Niedermayer 07release/4.1:b482e94e59b1: avcodec/rasc: Move ff_get_buffer() after frame checks [00:50:39 CET] <cone-126> ffmpeg 03Michael Niedermayer 07release/4.1:e75a73d62948: avformat/rtsp: Clear reply in every iteration in ff_rtsp_connect() [00:50:40 CET] <cone-126> ffmpeg 03Michael Niedermayer 07release/4.1:953f97979fc2: avformat/rtsp: Check number of streams in sdp_parse_line() [00:50:41 CET] <cone-126> ffmpeg 03Michael Niedermayer 07release/4.1:7816497ba081: avcodec/pgssubdec: Check for duplicate display segments [00:52:20 CET] <cone-126> ffmpeg 03Michael Niedermayer 07release/4.1:31a1d2aa8309: Changelog: update [01:40:14 CET] <BradleyS> michaelni: planning a patch release soon? [01:42:49 CET] <michaelni> i intend to make 4.1.1 soon (next days maybe tomorrow) [02:27:16 CET] <BradleyS> cool, thank you [02:28:04 CET] <BradleyS> that should make it into the next handbrake release then, will wait a few days and get that integrated [06:09:41 CET] <cone-233> ffmpeg 03Gyan Doshi 07master:075fd5ba4541: doc/filters: correct headphone examples [14:12:49 CET] <arpu> hello how can i prrevent the dashenc to write the static mpd if the stream is closed ? [14:17:58 CET] <arpu> looks like it have something todo with the final var [14:41:15 CET] <arpu> the idea is if a broadcaster restarts his publsih stream the player should automatic restart the stream ( with the static mpd player want replay the old stream) [14:45:42 CET] <BtbN> See topic, you're looking for #ffmpeg [14:48:53 CET] <BtbN> Looking at the code of dashenc.c it seems like you can't prevent it from doing that though. [14:49:24 CET] <BtbN> Maybe remove_at_exit works? [14:50:08 CET] <arpu> hi BtbN i will try but it looks like it first creats the static mpd and than delete it ( player gets in replay mode) [14:50:23 CET] <BtbN> Yes, it creates it and immediately deletes it. [14:50:32 CET] <BtbN> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/dashenc.c;h=37a7… [14:51:27 CET] <arpu> ok thx good hint! will try this [14:56:34 CET] <JEEB> anyone else given a try at the libaribb24 thing I did? [18:42:52 CET] <cand> michaelni: ppc ping [19:11:24 CET] <michaelni> cand, i forgot, i just replied to ML ... [19:12:50 CET] <cand> how do I send ssh keys, or do you prefer some other way? [19:22:14 CET] <cand> michaelni, ^ [21:00:52 CET] <lemourin> Hello, any reason why this commit: https://github.com/FFmpeg/FFmpeg/commit/d54ae9b782c85e626a1e49a8ee204728746… disables seeking in dash demuxer? Seeking works fine for my dash manifests when I remove the highlighted line. [21:02:08 CET] <JEEB> lemourin: I would recommend asking on ffmpeg-devel as the maintainer hangs around there [21:02:25 CET] <lemourin> isnt it ffmpeg-devel? [21:02:41 CET] <JEEB> I meant the mailing list, sorry for not being specific [21:02:44 CET] <JEEB> also lol [21:02:48 CET] <lemourin> ok [21:02:49 CET] <JEEB> "remove unused functions" [21:02:58 CET] <cone-453> ffmpeg 03Lauri Kasanen 07master:87b00cac2a3b: MAINTAINERS: add myself to the PPC section [21:02:58 CET] <cone-453> ffmpeg 03Andreas Rheinhardt 07master:1eb6bfbc1ff5: avcodec/mpeg4_unpack_bframes_bsf: Use avpriv_find_start_code [21:03:25 CET] <JEEB> so before it did if (c->is_live) { [21:03:32 CET] <JEEB> and only set seekable to zero if that was true [21:04:32 CET] <JEEB> and the seekable thing was not removed from the DASHContext [21:04:39 CET] <JEEB> so either it's being touched somewhere else or... [21:37:52 CET] <JEEB> lemourin: nice with the patches [21:38:22 CET] <JEEB> or well, patch but still :) [21:38:53 CET] <lemourin> @JEEB: :) [21:39:08 CET] <JEEB> the DASH "demuxer" really needs tests and stuff and more people to care about it [21:41:30 CET] <agrecascino> dangit nobody has stared at my rtx yet [21:41:36 CET] <agrecascino> rfc* [21:42:04 CET] <JEEB> agrecascino: I took a quick look at it but a lot of the time I either don't have the time or the brain matter to actually start thinking about it :P [21:42:16 CET] <lemourin> @JEEB: for some reason it feels like its still better than the one in vlc [21:42:22 CET] <JEEB> wow [21:42:22 CET] <agrecascino> its fine im genuinely just like [21:42:31 CET] <agrecascino> hoping someone can tell me im wrong and make this easier [21:42:38 CET] <agrecascino> or give me some ideas on how to do it [21:43:25 CET] <nevcairiel> i was considering making use of the DASH demuxer [21:43:38 CET] <nevcairiel> but looking at the commits to it, it seems so questionable [21:46:34 CET] <agrecascino> all i want to do is keep my nose clean and mutilate my jazzmaster with humbuckers [21:47:44 CET] <cone-453> ffmpeg 03Marton Balint 07master:56c58b99d067: avformat/mpegts: cache PID discard values [21:47:45 CET] <cone-453> ffmpeg 03Marton Balint 07master:4b46d1ee463f: avformat/async: fix assertion condition when draining buffer [00:00:00 CET] --- Tue Feb 5 2019

1 0

ffmpeg.log.20190204
by burek 05 Feb '19

05 Feb '19

[00:46:36 CET] <calamari> it's strange, the best 60p from mixed telecine/interlace result seems to be ignoring the telecine and using yadif=mode=send_field:deint=all Most of the time the 2 frames from fields are nearly identical, but it does help in some cases like rolling credits. [00:50:26 CET] <calamari> mcdeint seems to do nothing [01:00:54 CET] <calamari> experimented with minterpolate on yadif frame output to get 60p, but it was super weird looking. I guess I'm just not used to seeing that many frames during fast motion [01:01:38 CET] <calamari> doing it after ivtc was even worse [17:09:03 CET] <egrouse> is there a way to recover from 'conversion failed' errors? [17:09:07 CET] <kepstin> calamari's gone, but to anyone else in that situation i'd recommend using w3fdif instead of yadif, it'll have less artifacting :) [17:09:09 CET] <egrouse> ie to start again from same place/or just start again [17:09:36 CET] <kepstin> egrouse: not in general, you have to know why the conversion failed to know what an appropriate thing to do would be [17:09:49 CET] <egrouse> yeah, fair [17:10:03 CET] <egrouse> i think its because the outbound stream cant keep up (im streaming to rtmp) [17:10:07 CET] <egrouse> but i dont really know [17:10:15 CET] <egrouse> i get a message about failing to update headers/timestamp, then conversion failed [17:10:37 CET] <furq> kepstin: i mean i would recommend just not trying to do it automatically with a dirty source [17:10:51 CET] <furq> unless you feel you have too much hair and it could benefit from being torn out [17:11:32 CET] <kepstin> the failed to update headers thing can probably be ignored, that just is printed on exit in some streaming/piped formats. I suspect the issue you're hitting is that the remote server closed the connection, or another type of network error. [17:12:19 CET] <kepstin> egrouse: note that if your input is a file and your output is a "live" network stream, you should be using the "-re" option to make ffmpeg slow down/pace the stream. [17:12:40 CET] <furq> if the status line shows anything other than 1.00x with a network output then that's obviously a bad sign [17:12:51 CET] <furq> +/- 0.01 or so [17:13:42 CET] <egrouse> if i was redirecting a live stream to another live stream would it be better to omit -re [17:13:51 CET] <egrouse> i do have -re on both non-live and live media atm [17:14:00 CET] <kepstin> if your input is live (webcam capture, live stream) you should *not* have -re [17:14:02 CET] <furq> i don't know that it does anything if the input is live [17:14:14 CET] <furq> but yeah i would exclude it regardless because anything it does do would be wrong [17:14:16 CET] <egrouse> ok, im fairly sure it does have re [17:14:19 CET] <egrouse> so i will check that [17:14:37 CET] <kepstin> (the way -re works is it causes ffmpeg to sleep after reading each frame, so if it's slightly out of sync with the input then bad things will happen) [17:14:58 CET] <egrouse> that definitely sounds like it could be a probable cause [17:15:00 CET] <egrouse> or at least part of [17:16:32 CET] <furq> not to derail the topic here, but has anyone ever actually got good results converting a hybrid telecine/interlaced source without manually selecting frame ranges to filter [17:16:49 CET] <furq> assuming the frames aren't flagged correctly to start with [17:18:12 CET] <kepstin> there's no combination of ffmpeg filters that can do that automatically [17:19:04 CET] <kepstin> (the particular thing that's missing is the ability to output vfr automatically - i.e. 4/5 frames from the telecined section, and 5/5 frames from the interlaced sections) [17:19:33 CET] <furq> pullup seems to claim it can do it [17:19:38 CET] <furq> but it's never even approached working for me [17:19:55 CET] <kepstin> pullup isn't a very good detelecine filter imo, i've never had great results with its matching [17:20:20 CET] <furq> there's also a note in the fieldmatch docs that claims it can do it as well [17:20:35 CET] <furq> If your input has mixed telecined (30fps) and progressive content with a lower framerate like 24fps use the following filterchain to produce the necessary cfr stream: dejudder,fps=30000/1001,fieldmatch,decimate. [17:20:40 CET] <kepstin> pullup might do ok on mixed progressive and telecined, i think? [17:20:42 CET] <furq> but again that does nothing for me [17:20:49 CET] <kepstin> but mixed telecined and interlaced is hard [17:21:01 CET] <furq> yeah i've always just done it with vsedit and manually selecting frame ranges [17:21:16 CET] <furq> that caused some controversy last night so i wondered if i was missing something [17:22:09 CET] <kepstin> in many cases if you have mixed progressive and telecined, it'll be from a dvd mpeg2 source, and you should use the repeatfields to turn it into consistent telecine before running through a detelecine filter [17:22:19 CET] <kepstin> repeatfields filter* [17:22:49 CET] <furq> i don't even know how you'd get progressive and telecined [17:22:57 CET] <furq> i've seen progressive and interlaced on pal dvds before [17:23:08 CET] <kepstin> common on ntsc anime dvds, fwiw [17:23:19 CET] <furq> i assume that's just 60i and 24p where they've already deinterlaced the 60i [17:23:50 CET] <kepstin> i suspect what happened is that the mpeg encoder was given 60i telecined video, and it automatically detelecined parts where it found clean matches and left the rest [17:24:14 CET] <furq> oh fun [17:24:22 CET] <kepstin> (i've seen mismatches encoded into the progressive bits even, which is why i prefer to repeatfields and then redo the detelecine) [17:25:13 CET] <kepstin> the two worst things i've seen for detelecining are the serial experiments lain opening, and the last exile opening, fwiw [17:25:43 CET] <furq> my test corpus is the intro to "chuck norris karate kommandos" [17:25:44 CET] <kepstin> last exile was so bad, the blu-ray release was actually done in 1080i, just an interlaced upscale preserving the telecine/interlacing [17:26:01 CET] <furq> with russian audio that apparently exists on an official dvd [17:26:56 CET] <kepstin> with s.e. lain, the most recent BD release remaster did ok on the animated bits, and then terribly messes up the bits recorded with a video camera and some of the effects. [17:27:34 CET] <kepstin> part of that opening was done, as far as I can tell, by playing an animation clip on a CRT television then recording it with a camcorder to get the effect. [17:28:41 CET] <kepstin> (the upscale of the parts with fake scanlines also doesn't look very good) [17:30:03 CET] <kepstin> so yeah, there's actual interlaced 60i video mixed in with the 24p/12p effects. There was also a few CG bits in 30p iirc. [17:30:31 CET] <furq> very cool [17:33:12 CET] <furq> https://0x0.st/zsjG.ts [17:33:15 CET] <furq> it seemed rude not to share [17:33:30 CET] <furq> apparently i got rid of the russian audio when i remuxed this, which is something i can't believe i'd do [17:36:17 CET] <television> h [19:24:13 CET] <Trel> Does the windows builds of ffmpeg not have support for libaom-av1? [19:27:48 CET] <JEEB> no idea, zeranoe does the most popular ones so you'd have to check from zeranoe's site [19:27:53 CET] <JEEB> he lists all libraries he utilizes [19:28:24 CET] <Trel> Thanks, I'll take a look [19:28:26 CET] <JEEB> if you mean building yourself, yes they should have. libaom wrapper itself shouldn't have anything against windows [19:28:36 CET] <furq> zeranoe's builds have aom [19:29:24 CET] <mfwitten> The filter `setpts=PTS/2' results in output that finishes in half the time at FPS 30000/1001, but `setpts=PTS/2, fps=30000/1001' still takes the full amount of time; the last frame is duplicated until the very end of the unaltered duration. How can this be? Why is this so? [19:30:25 CET] <furq> the fps filter will dup frames if you ask it to [19:30:26 CET] <furq> which you are doing [19:31:12 CET] <furq> actually nvm that sounds like something else is happening [19:31:23 CET] <Trel> Ok, modified question, did the encoder change its name from libaom-av1? [19:31:36 CET] <furq> it's still libaom-av1 in 4.1 [19:31:47 CET] <mfwitten> furq: If I remove `setpts=PTS/2', the result is exactly the same duration, albeit normal speed [19:32:07 CET] <furq> pastebin the command line and output [19:33:09 CET] <Trel> I'm a moron, I had my PATH var reversed, I was executing the wrong ffmpeg. [19:33:14 CET] <Trel> I'm good now, sorry [19:38:12 CET] <Accord> is yuv420p basically the same as yuvj420p? [19:39:11 CET] <Accord> they seem to be compatible at concat atleast [19:49:28 CET] <JEEB> Accord: the J thing is an old way of mentioning that the YCbCr range is full (as opposed to 16-235/240 limited) [19:50:02 CET] <kepstin> mfwitten: my guess is that the setpts filter is passing through the eof timestamp unmodified rather than adjusting it like the frame timestamps? then the fps filter will fill in the gap until eof by duplicating the last frame. [19:50:35 CET] <kepstin> mfwitten: what ffmpeg version? [19:51:56 CET] <mfwitten> furq: I'm putting together a test command-line. [19:52:11 CET] <mfwitten> kepstin: n4.1 [19:53:25 CET] <mfwitten> kepstin: It was built by my distro on 25 Nov 2018 [19:56:40 CET] <Accord> JEEB: so can I count on them being concat compatible with stream copy? [19:57:37 CET] <Aerroon> where can i find docs for the "-loop" keyword? [19:58:13 CET] <furq> Aerroon: https://www.ffmpeg.org/ffmpeg-formats.html#image2-1 [19:58:22 CET] <kepstin> the "-loop" option is an input option on certain input formats, you'd have to check the docs for each format. [19:58:43 CET] <Aerroon> ah, i didn't know that [19:58:44 CET] <Aerroon> thanks [19:58:49 CET] <Aerroon> that's why i couldn't find anything about it [19:59:06 CET] <mfwitten> furq, kepstin: https://pastebin.com/ziywypU7 [20:00:04 CET] <mfwitten> kepstin: I suspect you're right, but is there really an eof timestamp? Surely `fps' should just ignore that. [20:00:20 CET] <kepstin> hmm, setpts is using the old filter framework, so it doesn't have explicit eof handling :/ [20:02:54 CET] <kepstin> hmm. to know exactly what's going on i'd need some debug level logs to find out what the fps filter is doing. Ideally, i'd want to reproduce this with a short video (e.g. a couple seconds long) and a filter chain that's just setpts,fps if possible. [20:10:11 CET] <kepstin> huh, i just noticed that the fps filter fill strip all a53 closed caption data from the stream [20:11:13 CET] <kepstin> i wonder when that was added, I think the person who added it might have misunderstood the code flow. [20:11:47 CET] <kepstin> (i think the intent was that it would only strip the CC data on duplicated frames, but it is being stripped from all frames) [20:12:46 CET] <kepstin> tbh, doing that probably makes sense since there's no handling for what to do with CC data on dropped frames [20:14:54 CET] <mfwitten> kepstin: This A/V stuff is complicated [20:16:19 CET] <mfwitten> kepstin: Here's a shorter version: ffmpeg -y -i input.mp4 -vf 'setpts=PTS/2,fps=30000/1001' -r 30000/1001 -an /tmp/too-long.mp4 [20:16:57 CET] <kepstin> so the issue does reproduce with that short filter chain? k. [20:17:12 CET] <mfwitten> kepstin: Yes. I've tried 2 clips [20:17:20 CET] <kepstin> I'll go make myself a 10 frame input video and do some quick tests with debug on. [20:17:29 CET] <mfwitten> kepstin: Thanks [20:18:07 CET] <mfwitten> kepstin: Note that the input is also FPS 30000/1001 [20:19:54 CET] <kepstin> alright, got a nice simple reproducer: https://gist.github.com/kepstin/cdf5eff501c5d0daed5dfdb2dc0d44de/raw/ [20:20:32 CET] <kepstin> confirmed the issue is that setpts filter is passing through the original eof pts [20:20:47 CET] <mfwitten> kepstin: Great [20:20:55 CET] <kepstin> solution is going to be ... rewriting the setpts filter using the activate callback. [20:21:05 CET] <mfwitten> kepstin: Indeed [20:31:40 CET] <kepstin> mfwitten: i don't have time to look further into this right now, but it would be great if you could file a bug on trac so the issue doesn't get forgotten, please include my reduced reproduction case. [20:33:50 CET] <mfwitten> kepstin: OK. [20:33:58 CET] <mfwitten> kepstin: Thanks for your help. [20:35:38 CET] <kepstin> in the mean time, i'd recommend adding a trim filter after the setpts, with the end time manually set - that should fix the reset of the chain. [20:36:55 CET] <kepstin> ... maybe [20:37:28 CET] <kepstin> hmm, never mind, that doesn't work :/ [20:38:16 CET] <mfwitten> kepstin: Honestly, I think the `fps' filter should ignore EOF stuff. [20:38:29 CET] <mfwitten> kepstin: Why does it care? It should just do as it's told [20:39:25 CET] <kepstin> it's doing exactly as its told, right now. It's being told "make an X fps video from input with irregular frame timing that ends a Y", and so it duplicates frames as necessary to make the video constant framerate until the end time. [20:39:43 CET] <mfwitten> kepstin: The "end at Y" part is wrong. [20:40:07 CET] <mfwitten> kepstin: It should just regulate the stream to the desired FPS [20:40:08 CET] <kepstin> yes, the setpts filter is telling the fps filter a wrong value for the end time. [20:40:46 CET] <mfwitten> kepstin: But `fps' shouldn't try to hit a desired duration anyway [20:41:44 CET] <mfwitten> kepstin: The docs make it seem like it just drops/dups frames in order to achieve the specified FPS. It says nothing, really, about EOF; indeed, even the `eof_action' argument talks about the last frame, not the EOF PTS [20:42:25 CET] <kepstin> if the last frame is supposed to be displayed for 5 seconds, according to the input to the fps filter, then the fps filter will duplicate it sufficiently to achieve that. [20:42:38 CET] <mfwitten> kepstin: I would also suggest there be a new filter, `seteof' and/or `neweof', so that it can be shimmed into place to help people, should there be a similar problem with another filter [20:42:52 CET] <mfwitten> kepstin: I see. [20:43:10 CET] <kepstin> but yeah, video end times are complicated [20:43:22 CET] <kepstin> it's not a value most formats actually store [20:43:55 CET] <kepstin> so in general it's calculated - if you assume constant framerate, then the EOF is set to the time when the next frame would have been if there was one [20:44:43 CET] <mfwitten> kepstin: Well, I'll submit a report with your example output, and let the knowledgeablefolk discuss it [20:45:21 CET] <kepstin> (there is a special value for unknown/undetermined EOF pts, which if the fps filter recieves that it will deal with the last frame exactly as you describe) [20:46:37 CET] <mfwitten> kepstin: Is it the explicit convention that the last frame is meant to be presented until the EOF PTS ? [20:47:05 CET] <mfwitten> (I guess I mean "Is it a standard?" Is that ffmpeg's design decision?) [20:47:18 CET] <kepstin> within the ffmpeg filter system, if the EOF pts is set to a value other than AV_NOPTS_VALUE, then that's the expected result. [20:47:31 CET] <kepstin> but like I said, most video containers don't actually store an end timestamp value [20:48:01 CET] <kepstin> so instead the player just has to guess the amount of time to show the final frame - it's usually shown either "until the audio ends" or "for the same amount of time as the frame before it" [20:48:30 CET] <mfwitten> kepstin: Hmm. So, is the `trim' filter setting an explicit EOF? [20:48:58 CET] <kepstin> trim filter's eof handling is messy, turns out it doesn't really work around this issue. [20:49:35 CET] <kepstin> if the trim filter cuts the video before it would have ended anyways, it sets the eof timestamp to AV_NOPTS_VALUE; if the video ends before the trim filter has to do anything, the eof timestamp is passed through untouched. [20:51:22 CET] <mfwitten> kepstin: So, where is eof timestamp getting set in the problem example command line? [20:51:54 CET] <kepstin> mfwitten: it's getting set implicitly by ffmpeg when reading the input file. [20:52:26 CET] <kepstin> note that mp4 i think actually does support some edit lists features that means it can actually store an end time? Not sure if that's part of the issue here or not. [20:52:41 CET] <mfwitten> kepstin: But your example? Also, the original problem cropped up for me well into a complex filtergraph, where there had already been much trimming [20:53:53 CET] <kepstin> mfwitten: in my shortened example, it looks like the end timestamp is being set by the filter framework internally after the first trim filter cuts the video (since the video is constant framerate, the filter framework used the "time when the next frame would have been displayed" method to pick an EOF timestamp) [20:54:33 CET] <mfwitten> kepstin: I feel like this EOF timestamp is anathema to a stream-based system [20:57:15 CET] <mfwitten> kepstin: Ah. I see it in your output: [Parsed_trim_1 @ 0x56530a3a8180] Setting 'end_frame' to value '10' [20:57:26 CET] <mfwitten> oh [20:57:27 CET] <mfwitten> woops [20:57:43 CET] <mfwitten> nm [20:57:50 CET] <mfwitten> That's the just the argument [20:58:13 CET] <kepstin> that's not what actually sets the end pts, the trim filter actually sets it to AV_NOPTS_VALUE, but it looks like the filter framework internally is converting that to a number instead. [20:58:37 CET] <mfwitten> kepstin: Maybe that's another facet of the bug [20:58:57 CET] <mfwitten> kepstin: Sure, setpts should probably do something, too, but it should have never been a problem I would think [21:00:06 CET] <kepstin> well, setpts is a filter which can change the length of the output video, using the old filter api that didn't really support changing the length of the output video - but this wasn't that big of an issue as long as all the other filters were using the same old api [21:01:11 CET] <kepstin> but the fps filter got rewritten to use the newer api recentlyish (to fix a nasty bug actually, the old api required buffering all the frames to fill a large gap in one call, which meant that if you had a several minute gap with no frames it would use a ton of memory), and as a result there's weird interactions with old filters :/ [21:01:59 CET] <kepstin> proper solution is to just move more filters - particularly those that might change the length or speed of videos - to the new framework so everything's happy together. [21:02:45 CET] <kepstin> although it might also not be a bad idea to also add another setting for the "eof_action" parameter on the fps filter, to say "ignore" :) [21:04:16 CET] <kepstin> or maybe just change the behaviour of "pass" mode [21:04:32 CET] <kepstin> i'll have to check how the old version of the fps filter behaved to see what's best. [21:05:40 CET] <kepstin> but yeah, it basically comes down to this problem: say you have a 1fps video that's 2 frames long. How long is this video? [21:05:57 CET] <kepstin> a reasonable assumption is "2 seconds", so lets go with that. [21:06:08 CET] <kepstin> now you run the fps filter to convert it to 30fps [21:06:19 CET] <mfwitten> kepstin: You'll notice the docs describe `eof_action' in terms of the last frame, not the EOF. Strangely, too, it looks like `pass' is actually implemented as `AV_ROUND_UP', so it doesn't really just pass it along [21:06:38 CET] <kepstin> if you want the video to still be "2 seconds" long, it has to make 30 copies of the first frame, *and* 30 copies of the last frame. [21:07:12 CET] <kepstin> mfwitten: it can't really pass through the eof timestamp untouched, because the fps filter changes the timebase. [21:07:29 CET] <kepstin> pass mode just ensures that the last frame is never dropped [21:08:27 CET] <mfwitten> kepstin: I agree, but the docs are a bit wrongheaded [21:09:09 CET] <kepstin> yeah, the docs could probably use some updates there. I think that part is untouched from the old version of the fps filter that dealt only with frames. [21:12:15 CET] <mfwitten> kepstin: Just for clarification, what is the main purpose of the EOF timestamp; is it just to optimize the fact that the last frame remains displayed until that timestamp? [21:13:44 CET] <kepstin> mfwitten: my understanding is that the purpose of the eof timestamp is to preserve the time that the last frame is displayed until across filters that might change things like framerate. [21:16:08 CET] <mfwitten> kepstin: I see. I feel like the user should be responsible for handling those calculations himself. [21:16:13 CET] <kepstin> fixing the particular issue you're hitting could be done by either having setpts also adjust the eof time using the same formula as the per-frame pts times (i'm not sure if this'll always work, since some variables might not be available), or just by having it reset the eof time to AV_NOPTS_VALUE [21:18:01 CET] <kepstin> the latter is basically the equivalent of saying "well, i dunno what the user did with timestamps but it could have been anything, so i'm pretty sure the original eof isn't valid any more" [21:20:21 CET] <kepstin> note that the fps isn't the only thing affected - pretty much any framesync based filter (most filters with multiple inputs), including things like overlay, will use the eof timestamp. [21:21:08 CET] <kepstin> so e.g. if you were overlaying your setpts-adjusted video over something else with eof_action=pass, it would stay on screen for the extra length of time rather than disappearing when you expected. [21:22:51 CET] <kepstin> filters like overlay let you put video with one framerate over video with a different framerate, so it might have to duplicate the last frame in order for the duration to be as expected. [21:25:07 CET] <mfwitten> kepstin: Maybe it would be better to force users to think about syncing their sources manually. I'm still skeptical [21:26:30 CET] <kepstin> i mean, we could force people to convert both inputs to constant framerate and then manually duplicate the last frame if needed using tpad before overlaying videos, but that would be both very inconvenient, and mean that you can't use overlay with variable framerate stuff at all [21:27:07 CET] <kepstin> whereas now it just works :/ [21:27:32 CET] <kepstin> (and it will also just work with the setpts filter, once the bug where it doesn't reset eof timestamp is fixed) [21:28:41 CET] <mfwitten> kepstin: Yeah, but, does it *really* just work? Duplicating frames is not what *I* would choose; I'd use a more sophisticated `minterpolate' or whatever, if applicable. [21:28:58 CET] <kepstin> fps filter fills in gaps by duplicating frames [21:29:04 CET] <kepstin> if you want something else, use a different filter [21:29:12 CET] <kepstin> it treats the last frame the same as any other frame [21:29:24 CET] <mfwitten> kepstin: Well, I was going to. I was just playing around; I had no intention whatsoever of use `fps' [21:29:51 CET] <kepstin> but i'd expect the 'framerate' and 'minterpolate' filters to have similar eof behaviour [21:30:06 CET] <mfwitten> kepstin: My point is that I don't agree that it just works; there's a difference between working and not producing an error. [21:30:41 CET] <mfwitten> kepstin: Yes, they might. And that's exactly why I'm skeptical. Essentially, someone has made a design choice that takes control away from me, the user. [21:31:08 CET] <kepstin> you hit a bug in the setpts filter. [21:31:11 CET] <kepstin> it's a bug :/ [21:31:51 CET] <kepstin> if the setpts filter had correctly reset or recalculated the eof, your filter chain would have worked as you expected, and we wouldn't be having this conversation at all. [21:32:06 CET] <mfwitten> kepstin: You're going to have people doing overlays, and begging in forums for help on making their videos look smooth [at the end] [21:33:11 CET] <kepstin> not sure what you mean - in cases where the eof timestamp isn't broken, the last frame would behave exactly the same as any other frame in the video (duplicated if necessary to increase framerate to match the base video) [21:33:27 CET] <kepstin> so if it's "not smooth", they'd notice that on earlier frames well before the last frame [21:34:27 CET] <kepstin> all of the filters work by assuming the duration of a frame is "next frame's pts - current frame's pts" [21:34:42 CET] <kepstin> but the last frame doesn't have a next frame, so the eof timestamp fills in that role [21:37:31 CET] <mfwitten> kepstin: The overlay filter is choosing a particular way to sync the frames; instead, it should make the user think about what he wants to do. Secondly, what to do with the last frame is up to the player; it's up to whatever is *consuming* the stream of frames. Maybe ffmpeg shouldn't be making choices for consumers it knows nothing about [21:38:15 CET] <mfwitten> Does the player simply display the last frame and then stop doing anything? Or, does it shove in a black frame with the words THE END? [21:38:18 CET] <kepstin> i mean, if you're overlaying a 6fps video over a 24fps video, what other option is there than "repeat each frame 4 times"? [21:38:38 CET] <pink_mist> magic [21:39:14 CET] <mfwitten> kepstin: minterpolate instead? The overlay filter should just merge 2 synced streams, right? [21:39:47 CET] <kepstin> but the top video is 6fps, so duplicating it preserves exactly what it looks like when played back standalone [21:40:04 CET] <kepstin> minterpolate adds tons of motion artifacts and looks horrible on animation, for example [21:40:17 CET] <mfwitten> kepstin: But that's a choice. The overlay filter is more complicated than it should be; it's doing syncing for you [21:40:20 CET] <kepstin> mfwitten: i've actually already said what players do, earlier, but to repeat myself: they either hold the last frame on screen until the audio ends, display the last frame for the same amount of time as the frame before it, or don't show the last frame at all. [21:40:24 CET] <mfwitten> As a result, you've got all this EOF stuff [21:40:34 CET] <kepstin> mfwitten: it has to handle syncing. that's its job. [21:41:20 CET] <mfwitten> kepstin: I'd say overlying is its job. [21:41:31 CET] <kepstin> the only other way to do the overlay filter would be to require both inputs are constant framerate with the same framerate, and then it can't handle vfr content at all [21:41:32 CET] <mfwitten> kepstin: As for what a player does, you have certainly listed choices. [21:42:12 CET] <mfwitten> kepstin: Why would it have to be constant? [21:42:31 CET] <kepstin> mfwitten: because otherwise the streams wouldn't be in sync [21:43:01 CET] <kepstin> if you want to overlay one thing over another in sync, and the overlay filter isn't allowed to handle syncing timestamps, then you have to provide pairs of frames that are already in sync [21:43:13 CET] <mfwitten> Yes [21:43:37 CET] <mfwitten> I'm just saying that I suspect that sort of design choice would make more sense to me [21:43:51 CET] <kepstin> well, that certainly would make it a lot harder to use ffmpeg [21:43:55 CET] <mfwitten> EOF seems like a symptom of a wrong choice [21:44:42 CET] <kepstin> this has nothing to do with eof, other than that eof is used as a way to represent the duration of the last video frame. These choices apply to the duration of every individual frame in the stream [21:45:16 CET] <kepstin> anyways, i've made a note to look into fixing the eof behaviour of the setpts filter, and that'll fix the issue you've experienced. I'm done here for now. [21:45:35 CET] <mfwitten> OK [21:45:41 CET] <mfwitten> kepstin: I'll submit that report soon [22:08:52 CET] <cfaber> hey, can I specify multiple vf's like -vf filter1 filter2 filter3 ? [22:12:50 CET] <durandal_1707> cfaber: -vf filter1,filter2, ... [22:15:24 CET] <cfaber> thanks [22:16:14 CET] <cfaber> does order matter? in my case, I'm scaling then burning subtitles [22:17:08 CET] <durandal_1707> order matter, think what is best way [22:18:11 CET] <cfaber> okay thanks, so if I set subtitles first, it will burn those in, then scale everything (reducing the quality of the text) ? [22:18:24 CET] <durandal_1707> yes [22:26:58 CET] <cfaber> Thanks [22:39:43 CET] <mfwitten> kepstin: https://trac.ffmpeg.org/ticket/7716 [00:00:00 CET] --- Tue Feb 5 2019

1 0

ffmpeg-devel.log.20190203
by burek 04 Feb '19

04 Feb '19

[04:52:58 CET] <agrecascino> is there any way to tell if a track is non-indexed in like an mp4 file without reading the entirety of it [05:26:35 CET] <agrecascino> is adding something to a struct a big nono [15:57:25 CET] <JEEB> roflcopter bbq [15:57:42 CET] <JEEB> someone checked my colors against another implementation and I did the most classic mistake with ASS colors [15:57:51 CET] <JEEB> forgot the order was > BGR [16:07:48 CET] <JEEB> ok, vf_subtitles seems to have some helper macros for this [16:15:44 CET] <JEEB> except they're the other way [16:26:10 CET] <JEEB> #define RGB_TO_BGR(c) (c & 0xff) << 16 | (c & 0xff00) | ((c >> 16) & 0xff) [16:26:14 CET] <JEEB> well, this shall do it [16:35:30 CET] <JEEB> fixed version sent out [17:04:32 CET] <agrecascino> JEEB, is adding stuff to structs bad [17:04:36 CET] <agrecascino> also is there any way to see how many tracks are indexed [17:05:20 CET] <JEEB> internal structs can be added to [17:05:30 CET] <JEEB> usually to the end of them [17:06:17 CET] <agrecascino> is MOVContext internal [17:06:19 CET] <JEEB> agrecascino: see mov_read_header for example regarding how it iterates over the added AVStreams [17:06:22 CET] <JEEB> yes [17:06:37 CET] <agrecascino> ok [17:06:59 CET] <agrecascino> i'm trying to come up with the lowest effort way of accurately counting sidx boxes [17:07:23 CET] <agrecascino> because the current method fails if there's more than one stream [17:08:02 CET] <JEEB> of course the way the header reading thing does it is clearly after reading the found streams and registering them [17:08:10 CET] <JEEB> so if your thing is before that you have an issue [17:11:36 CET] <agrecascino> yeah uhm [17:11:49 CET] <agrecascino> this is is an issue in the sense that [17:12:21 CET] <agrecascino> i can't really count using the parser since it runs through every box in order [17:13:21 CET] <agrecascino> is any avstream going to indexable [23:20:52 CET] <cone-126> ffmpeg 03Michael Niedermayer 07master:e35c3d887b3e: avcodec/pgssubdec: Check for duplicate display segments [00:00:00 CET] --- Mon Feb 4 2019

1 0

ffmpeg.log.20190203
by burek 04 Feb '19

04 Feb '19

[01:34:32 CET] <seanrdev> I tried http://ffmpeg.pastebin.com/ and yet it's not returning a result so I just pasted in pastebin.com [01:34:36 CET] <seanrdev> https://pastebin.com/LZ5yQPb6 [01:36:19 CET] <seanrdev> There seems to be an error with my formatting of the output file name. If I name a simple file name in the absolute directory everything works great however when attempting to add dates and times things start to get crazy with incorrect codec params. [01:50:51 CET] <iive> seanrdev, after reading `man ffmpeg-formats` it seems that you need 'strftime' option in order to use its formatting for the filename [01:59:06 CET] <seanrdev> iive: use_localtime 1 gives the same result. [01:59:35 CET] <utack> what would be the correct "map" command to drop all this mjpeg mkv attachment nonsense? " Stream #0:7 (mjpeg) -> libvmaf:reference [01:59:35 CET] <utack> " [01:59:50 CET] <utack> i have tried a few, but can't figure out how to drop these entirely [02:00:50 CET] <utack> shouldn't "-map 0:0" pick the stream 0 from file 0 and drop all others? [02:01:25 CET] <seanrdev> Oh wait... I see there is an actual option -strftime when using that I start to get a different error so I guess maybe that is solved. [02:04:02 CET] <utack> "-map 0:V" also does not help [02:14:52 CET] <seanrdev> I can't seem to get this down. Now the save works but I'm having encoder errors now. Why would I start to have encoder errors when I start adding local time? https://pastebin.com/Yg3UF5MQ [13:11:44 CET] <lightbulb6> how can i extract a frame from an anamorphic video and encode it to png with correct sar? [13:12:39 CET] <lightbulb6> i'd like the resulting png file to look exactly as what ffplay shows when playing the input file, but i get a stretched out picture instead [13:13:28 CET] <lightbulb6> the command i use is as follows: ffmpeg -i in.mkv -frames 1 out.png [13:18:54 CET] <lightbulb6> a sample video can be created like so: ffmpeg -f lavfi -i "testsrc=s=256x256" -filter "scale=w=3*iw:h=ih,setsar=1/3" -frames 1 sample.mkv [13:20:40 CET] <lightbulb6> now, if i do "ffplay sample.mkv", i can see a square frame (which is what i want), but if i do "ffmpeg -i sample.mkv -frames 1 out.png", the resulting png is stretched out [15:36:30 CET] <GuiToris> hey, why is vp9 so weird? I've created a 1:50 long video with 2-pass encoding, and crf 40, 125mb and crf 43 resulted a 101mb file [15:36:37 CET] <GuiToris> aren't these files way to big? [15:36:57 CET] <GuiToris> they are 1920x1080p files [15:45:52 CET] <JEEB> ot [15:46:03 CET] <JEEB> it is not CRF and really, "crf" depends on the encoder and even options [15:46:22 CET] <JEEB> you will have to iterate over your test clip to find your preferred value in any VBR rate control [15:49:22 CET] <GuiToris> JEEB, what I used is: ffmpeg -y -i 0FULLRC.mkv -c:v libvpx-vp9 -pix_fmt yuv420p -b:v 0 -crf 43 -pass 2 -an -threads 1 -speed 0 43.webm [15:49:34 CET] <GuiToris> and this is still over 100mb [15:51:09 CET] <GuiToris> I was trying to raise the crf value but I didn't see much difference [15:51:12 CET] <iive> i'm not familiar with vp9 encoding, but... -b:v 0 -speed 0 ... did you get these from vp9 encoding example? [15:51:32 CET] <GuiToris> yes, hold on, I'll try to find the source [15:51:43 CET] <furq> -b:v 0 is required for -crf to actually do anything [15:51:53 CET] <furq> and -speed is the equivalent of -preset [15:52:19 CET] <GuiToris> but is this scale really light compared to x265? [15:52:28 CET] <JEEB> forget any other encoder's scale [15:52:30 CET] <furq> they have no relation to each other really [15:52:43 CET] <furq> and also it sounds like you have a pathologically bad input clip [15:52:48 CET] <JEEB> also I'm still kind of sore that libvpx's CQ mode was mapped to CRF :P [15:52:56 CET] <JEEB> since they are different [15:53:04 CET] <BtbN> 100MB for a high quality 2 minute clip does not seem that unreasonable. [15:53:13 CET] <JEEB> although heck, as I already said - crf is totally different between x264 and x265 [15:53:22 CET] <furq> well one wouldn't expect -crf 43 to still be "high quality" [15:53:26 CET] <JEEB> and even between presets in a single encoder [15:53:26 CET] <furq> but yeah it's vp9, who knows [15:53:32 CET] <BtbN> Does libvpx even care about crf? [15:53:38 CET] <BtbN> Isn't that a x2645 thing? [15:53:39 CET] <JEEB> BtbN: it's mapped to its CQ mode [15:53:43 CET] <GuiToris> if that matters, the source is a 20gb ffv1 nut file [15:53:46 CET] <JEEB> which is why I said I'm kind of sore about it :P [15:53:58 CET] <JEEB> "let's make this easy to use and map it to CRF" [15:54:06 CET] <JEEB> which I kind of understand buuut [15:54:14 CET] <furq> GuiToris: it depends on the contents, not the encoding [15:54:55 CET] <furq> at a glance that looks like a very high bitrate for ffv1 [15:55:00 CET] <furq> so i'm guessing the input clip is pretty complex [15:55:20 CET] <GuiToris> the problem with vp9 is it took about 14 hours to encode the second pass and I don't know if I should redo it [15:55:28 CET] <GuiToris> would 50mb too low in quality? [15:55:40 CET] <furq> that's not something anyone but you can answer [15:55:56 CET] <BtbN> 14 hours for a 2 minute clip? What? [15:56:13 CET] <furq> that sounds plausible with no multithreading and -speed 0 [15:56:13 CET] <GuiToris> BtbN, vp9 with speed 0 is rather slow [15:57:39 CET] <GuiToris> all I need is a clear picture, which is perfect now, but I find the file size a little bit big [15:58:18 CET] <GuiToris> do you use vp9? how far should I go with crf? [15:58:35 CET] <GuiToris> the manual says about 31 is the right value [15:58:42 CET] <JEEB> there is no "right value" [15:58:43 CET] <GuiToris> I've tried it and it was about 250mb [15:59:04 CET] <JEEB> you have a relatively short clip that should let you experiment with that sort of content [15:59:17 CET] <JEEB> (otherwise -ss and -t to make the clip around 1200-2500 frames or so is a good way) [15:59:18 CET] <furq> well not if it takes 14 hours to encode [15:59:28 CET] <JEEB> libvpx VP9 wasn't that slow last I checked [15:59:29 CET] <furq> you should probably enable row-mt [15:59:33 CET] <JEEB> even on my 8core atom [15:59:35 CET] <furq> or any multithreading at all really [15:59:52 CET] <GuiToris> I have an i3-2350m processor [16:00:11 CET] <furq> that's a 35W part [16:00:13 CET] <furq> that shouldn't be that slow [16:01:09 CET] <furq> i'm sure i've asked this before but how come ffmpeg has -speed and -cpu-used with different ranges [16:01:13 CET] <furq> i thought those were the same option [16:02:45 CET] <GuiToris> furq, they are both 0-4, aren't they? [16:03:05 CET] <GuiToris> I've used this page: http://wiki.webmproject.org/ffmpeg/vp9-encoding-guide [16:03:18 CET] <furq> -cpu-used <int> E..V..... Quality/Speed ratio modifier (from -8 to 8) (default 1) [16:03:21 CET] <furq> -speed <int> E..V..... (from -16 to 16) (default 1) [16:04:04 CET] <GuiToris> no way, it could be even slower than this?! [16:04:34 CET] <JEEB> furq: speed seems to be a "legacy option" looking at the source [16:04:47 CET] <JEEB> also the range probably is historic and just documeneted at some point [16:04:54 CET] <furq> i was about to say "it better not be a legacy thing for vp9" [16:04:56 CET] <furq> but i knew better [16:05:05 CET] <JEEB> remember, libvpxenc is used for all formats ever supported by that lib [16:05:11 CET] <JEEB> (during the age of the wrapper) [16:05:11 CET] <furq> true [16:06:05 CET] <GuiToris> how can I specify frames, I only used seconds with -ss and -t [16:06:25 CET] <GuiToris> I'll take a look whether it's worth increasing the crf number [16:06:49 CET] <furq> GuiToris: is there some reason you're not using multithreading [16:07:35 CET] <GuiToris> yes, because the wiki.webmproject.org doesn't use it either, beside that no [16:07:50 CET] <GuiToris> I just didn't want to mess up, and I used no multithreading [16:08:01 CET] <GuiToris> does it impact the quality? [16:08:13 CET] <furq> i don't know if row-mt does [16:08:29 CET] <furq> the old sliced threading stuff did but not much [16:08:54 CET] <furq> i think nowadays just -threads 4 -row-mt 1 should work [16:11:34 CET] <GuiToris> this is crf40 https://ptpb.pw/5iYS and 43: https://ptpb.pw/SO3_ [16:11:53 CET] <Cracki> you requested my presence [16:12:09 CET] <GuiToris> yes thank you Cracki [16:12:34 CET] <GuiToris> I was wondering if I share two images with you can you tell me the right homography values? [16:13:10 CET] <Cracki> I can point you to code you can run that does it [16:13:45 CET] <GuiToris> you did it once and turned out I should you windows or it was difficult or something like that [16:14:01 CET] <GuiToris> s/you/use [16:14:13 CET] <Cracki> uh, not really. opencv runs just fine headless on any linux. [16:14:36 CET] <GuiToris> alright, let's give it a shot [16:14:50 CET] <Cracki> anyway, samples/python/find_obj.py [16:15:01 CET] <Cracki> or simply post the images and let everyone have a go at it [16:16:38 CET] <GuiToris> Cracki, https://github.com/opencv/opencv/blob/master/samples/python/find_obj.py [16:17:01 CET] <GuiToris> is this what I need? [16:17:24 CET] <Cracki> pretty much [16:17:35 CET] <GuiToris> thanks I'll try it [16:18:08 CET] <GuiToris> furq, do you see any major difference between https://ptpb.pw/5iYS and https://ptpb.pw/SO3_ [16:18:24 CET] <GuiToris> do you agree that I should still increase the crf value? [16:18:53 CET] <GuiToris> the first one is crf40, this sample is ~15 mb [16:19:08 CET] <GuiToris> and the second one is 43 and 12mb [16:19:28 CET] <Cracki> for comparing videos: http://www.compression.ru/video/quality_measure/vqmt_download.html [16:21:01 CET] <GuiToris> Cracki, is vqmt the name of the program? [16:21:31 CET] <GuiToris> if so, at least it's in a repo [16:23:05 CET] <GuiToris> what I usually do is : for f in *.webm; do ffmpeg -y -ss 19 -i "$f" -frames 1 "{f%.*}.png" ; done [16:23:30 CET] <GuiToris> then I only need to compare still frames [16:39:46 CET] <GuiToris> Cracki, what prerequisites do I need before using find_obj.py [16:39:56 CET] <GuiToris> it's not just a python script, is it? [16:40:13 CET] <Cracki> of course not. you need opencv. [16:40:34 CET] <Cracki> and in particular the python bindings (included in opencv) [16:40:42 CET] <Cracki> just install opencv with pip [16:40:55 CET] <Cracki> https://pypi.org/project/opencv-python/ [16:42:44 CET] <GuiToris> thanks [16:47:38 CET] <GuiToris> Cracki, my Chinese is not perfect, is this what you were refering to? https://youtu.be/AUL96YQv1bs?t=205 [16:47:52 CET] <GuiToris> this is a command line tool, right [16:48:36 CET] <GuiToris> do you think I would be better off using Windows now? [16:48:55 CET] <Cracki> makes zero diff [16:49:08 CET] <GuiToris> isn't it easier to install opencv there? [16:49:14 CET] <Cracki> but you will want to edit that script or run it with "python -i" to get the matrix [16:49:32 CET] <Cracki> what could be easier than "pip install ..." [16:50:50 CET] <GuiToris> if that's all, I'll open up an Ubuntu then [16:52:19 CET] <GuiToris> I just don't use anything else but pacman on my host machine [16:54:08 CET] <Cracki> if you have pacman on your host, that's either some arch or whatever, or msys2 [16:54:20 CET] <Cracki> anyway, "pip" is a python thing, so you must have python [16:55:48 CET] <GuiToris> Cracki, I'm afraid if I install something with pip I won't be able to remove it with pacman [16:56:10 CET] <GuiToris> but it's not a big deal if I need to use Ubuntu now [16:56:23 CET] <Cracki> use pacman then, if your unnamed distribution has an opencv package with python bindings [16:56:34 CET] <GuiToris> arch [16:56:36 CET] <Cracki> pip can remove things again, so no big deal [16:57:31 CET] <GuiToris> I also tried using the measurement tool [16:57:35 CET] <GuiToris> it won't work [16:57:51 CET] <GuiToris> HDTV resolution only works in PRO version [16:58:06 CET] <GuiToris> I'm also not sure if vp9 is supported [16:58:12 CET] <GuiToris> but thank you for your suggestion :) [16:59:08 CET] <Cracki> use the "demo" [16:59:18 CET] <Cracki> I think it uses ffmpeg [17:01:12 CET] <GuiToris> I'll take a look [17:03:32 CET] <GuiToris> something is happening now [17:04:03 CET] <GuiToris> I got a graph [17:04:50 CET] <GuiToris> I'll share this with you [17:07:11 CET] <GuiToris> Cracki, https://ptpb.pw/iSUI [17:07:15 CET] <GuiToris> what do we see here? [17:07:38 CET] <Cracki> red has better SNR [17:07:58 CET] <Cracki> also I'd say the GOP length is rather short [17:08:06 CET] <GuiToris> this is not going to be easy, I don't see colors [17:08:18 CET] <GuiToris> can you refer to 40 and 43, please? [17:08:30 CET] <Cracki> and, intra frames are markedly better than P/B frames [17:08:51 CET] <Cracki> awesome. anyway, the "red" is 40, green is 43 [17:09:19 CET] <Cracki> and 43 has consistently lower SNR [17:09:51 CET] <Cracki> lowest I can eyeball is ~30, so that's all quite decent [17:10:19 CET] <GuiToris> do you think I should still lower the quality? [17:10:29 CET] <GuiToris> the main problem is that the filesize is large [17:10:43 CET] <GuiToris> 40 is ~120 and 43 is 100mb [17:10:44 CET] <Cracki> pick a target [17:11:08 CET] <Cracki> 100 mb for... 300 frames? [17:11:13 CET] <Cracki> that's a lot [17:11:36 CET] <GuiToris> I didn't say 300frames, did I?! [17:11:36 CET] <Cracki> what's "mb" to you? megabytes? megabits? [17:11:42 CET] <Cracki> the plot says 300 frames [17:12:01 CET] <GuiToris> it must be the demo version [17:12:36 CET] <GuiToris> it's a 110second long video [17:12:44 CET] <GuiToris> 29.97 frames per second [17:13:30 CET] <GuiToris> it must be about 3300 frames [17:13:52 CET] <Cracki> 800 megabit / 110 seconds is 7.2 Mbit/s [17:15:10 CET] <GuiToris> according to my filemanager 40 is 9Mb/s and 43 is 8 [17:16:03 CET] <GuiToris> I'm not sure if you have seen my samples but I personally don't see huge differencies and I was thinking of lowering the filesize and quality [17:16:14 CET] <GuiToris> the only problem is it takes about 14hours [17:16:21 CET] <GuiToris> so I should plan this [17:16:46 CET] <Cracki> probably [17:17:58 CET] <GuiToris> is 8Mb/s still a lot? [17:18:37 CET] <Cracki> ¯\_(Ä)_/¯ depends on so many things [17:19:17 CET] <GuiToris> I'll try to create small sections [17:21:46 CET] <GuiToris> thank you for your help Cracki [19:08:26 CET] <mfwitten> I'd like to zoom in on an area of interest with `crop=<maintain aspect ratio>...,scale=<original size>', but how do I remember `<original size>'? For simple computations, you can just use the inverse calculations, but that doesn't seem like a solid solution; surely there is a way to inject into `scale' the desired `in_h' and `in_w' from `crop' (`sendcmd'?) [19:14:19 CET] <mfwitten> Of course, maybe I could just use `zoompan', but I'd still be interested in knowing whether there is a way to communicate information from one filter to another (e.g., supply the `in_h' and `in_w' of `crop' to a later `scale'). [19:15:37 CET] <DHE> I think you're supposed to examine the input ahead of time (ffprobe or such), then build your commandline intelligently [19:15:52 CET] <mfwitten> DHE: Yeah. That's what I was afraid of. [19:15:58 CET] <furq> there's no generic way of doing that afai [19:15:58 CET] <furq> k [19:16:08 CET] <furq> some filters can communicate through frame metadata but that's generally listed in the docs [19:16:17 CET] <mfwitten> DHE, furq: OK. Thanks. [20:27:00 CET] <GuiToris> does the math work here? if a 5second long video is 2.5M then a 110second long video is going to be 55M? [20:27:08 CET] <GuiToris> I'm afraid not [21:20:33 CET] <calamari> I have 720x480 VFR NTSC interlaced video with live action parts a telecine 3:2 pulldown (I can see the duplicated fields with -vf field=top) and CGI parts are standard interlacing. I bet there are some bad splices in there too where field order changes or a pulldown is interrupted. I'd like to convert this to 60p. I'm assuming I'll need some combo of fieldmatch/pullup/yadif and then minterpolate (maybe a dejudder is needed in [21:20:33 CET] <calamari> there somewhere too, not sure). Any tips on how to put this all together? [21:21:52 CET] <furq> i would probably use vapoursynth for that [21:22:00 CET] <furq> not so much for the capability but because then you can use vsedit [21:22:04 CET] <JEEB> yea [21:22:12 CET] <JEEB> you could I think do that in lavfi just fine [21:22:24 CET] <JEEB> but not being able to preview frame accurately really hurts [21:22:49 CET] <JEEB> while vs with vapoursynth editor makes it relatively simple to write vs python scripts [21:22:52 CET] <JEEB> and preview them [21:23:18 CET] <JEEB> and then you can utilize vspipe etc to pass the vs output through a pipe to ffmpeg.c or any other encoder [21:26:21 CET] <calamari> I'll take a look at vaporsynth, thanks [21:27:06 CET] <durandal_1707> i will kick you all [21:27:37 CET] <JEEB> I think we've mentioned it specifically that it is not a problem in the functionality of lavfi specifically :P [21:28:00 CET] <JEEB> just that - unfortunately - the usability of it is less than vs + vs editor [21:28:10 CET] <JEEB> stop taking it as an attack at lavfi [21:28:11 CET] <JEEB> please [21:28:17 CET] <durandal_1707> i will kick you all [21:28:42 CET] <JEEB> suit yourself [21:32:41 CET] <calamari> can lavfi do the motion interpolation? [21:33:00 CET] <furq> it can do all of that stuff [21:33:24 CET] <calamari> cool. I might check that first, since it's intergrated into the tool already [21:41:40 CET] <calamari> huh, I guess I don't get it. it seems like -lavfi doesn't really apply to my situation, since it's only one video stream? what am I missing? [21:42:36 CET] <trfl> iirc you'll get way better performance doing motion interpolation with vs and mvtools, but assuming it's just for deinterlacing you should be fine with lavfi yeah [21:43:23 CET] <furq> calamari: lavfi meaning libavfilter [21:43:28 CET] <furq> not the option [21:45:31 CET] <calamari> trfl: I'm hoping I can have it pullup/yadif the interlaced video, then using the timing of the resulting progressive frames it should then interpolate the 60p frames from those (it might end up not even using any pure frames, depending on the timing) [22:43:09 CET] <calamari> found this, but it's definitely not right yet, as it's doing pullup in the CGI real interlaced sections (also tried minterpolate instead of fps, but that was making me sick): pullup,dejudder,idet,yadif=mode=1:deint=interlaced,fps=60000/1001 [23:07:25 CET] <_bluez> Hello everyone! I am a college student and I am interested in contributing to ffmpeg... how should I proceed? Also, I am familiar with github and have made some contributions to other projects, but the concept of "sending patches in mailing lists" is new to me... so how should I start? [23:08:36 CET] <mfwitten> DHE, furq: Looks like I'm a dummy, anyway. For `crop', `w' and `h' are calculated only once (when initialized), so `crop' cannot be used to implement zooming. [23:13:21 CET] <mfwitten> DHE, furq: For the sake of completness, I'll mention that it looks like `scale' can be configured to evaluate its expressions on each frame, and thus zooming could be achieved by scaling and then cropping, rather than cropping and then scaling. I also found `scale2ref', which might obviate the need to `ffprobe' inputs for dimensions [00:00:00 CET] --- Mon Feb 4 2019

1 0