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

[burek]

[00:11:09 CEST] <DHE> I usually say mp4 for industry codecs, mkv for anything that gives you trouble
[00:30:58 CEST] <mozzarella> holyshit lol
[00:31:15 CEST] <mozzarella> av_interleaved_write_frame(): No space left on device
[00:31:22 CEST] <mozzarella> Conversion failed!
[00:31:26 CEST] <mozzarella> all that for nothing
[00:31:29 CEST] <mozzarella> I hate myself
[00:42:16 CEST] <systemd0wn> Question, When FFmpeg constructs a RTMP packet, what is the value of the Timestamp field? Is this the system time when the packet was constructed?
[00:42:34 CEST] <c_14> check the source code?
[00:43:03 CEST] <systemd0wn> c_14: I looked around a bit but I'm not super savy with C.
[00:57:37 CEST] <nicolas17> hmm I should write an AWS S3 protocol for ffmpeg
[01:03:58 CEST] <nicolas17> does ffmpeg ever read from output files? or is all the data for eg. writing the moov atom kept in memory?
[01:04:32 CEST] <nicolas17> (obviously -movflags faststart does read from the file, but that's a bit of a special case)
[01:05:21 CEST] <c_14> numerous output formats require seeking
[01:05:31 CEST] <c_14> non fragmented mp4
[01:05:35 CEST] <c_14> non streamable matroska
[01:05:56 CEST] <nicolas17> a plain old mp4 will write to the file, and when it finishes it will seek to the beginning and write the header
[01:06:18 CEST] <nicolas17> but does it need to *read*? or just writes to the beginning?
[01:07:03 CEST] <nicolas17> faststart is a notable case where ffmpeg will have to read the file it just wrote again
[01:08:41 CEST] <c_14> I think it won't read in most cases
[01:08:43 CEST] <c_14> But I'm not sure
[01:19:59 CEST] <nicolas17> bah nevermind
[01:20:04 CEST] <nicolas17> I would need the ability to read anyway
[01:21:51 CEST] <nicolas17> if ffmpeg seeks to the beginning and rewrites the first 100 bytes... I can't overwrite a chunk that small in S3, the minimum part size is 5MB, so I would need to read the existing contents first
[01:22:21 CEST] <nicolas17> screw that, I'll make it read-only
[01:27:05 CEST] <acos> Back.  Now where was I
[01:28:22 CEST] <dorvan> nicolas17: I've reduced to 5mbit/s and removed almost all optimization for mpeg-dash conversion on streamed input. at moment i have 38mbyte/s input stream and a fluent 5.x <6 sec delayed live (net cam have a native delay of 2sec)
[01:29:13 CEST] <dorvan> nicolas17: profile it's high always, no vantages to downgrade it..
[01:30:58 CEST] <acos> What's a good format to avoid generation loss? What's a good format to merge many files into a single one?
[01:33:10 CEST] <dorvan> acos: what do you need as output? a big file to see like a movie, or a live dynamic stream?
[01:34:06 CEST] <dorvan> acos: at moment we record small .mp4 files for playback and a small and fast live stream with dash...
[01:34:38 CEST] <dorvan> where, like to hls, you have a playlist of various files
[01:35:12 CEST] <dorvan> acos: not a single monolithic file, but a playlist.
[01:35:41 CEST] <acos> Well dorvan I'm editing a wedding video and am doing it part by part exporting each scene from an editor.  Then I want to merge into a single file to send to my client.
[01:36:26 CEST] <acos> I'm trying to avoid generation loss
[01:37:05 CEST] <dorvan> acos: ah okay a totally different case, so you need to reorder single slices and merge a single video without recoding a full video?
[01:37:49 CEST] <acos> That's the hope.  But concat no work for me
[01:38:37 CEST] <dorvan> source slices are all in the same format? what is the format?
[01:39:01 CEST] <acos> Well it's h264 as an avi
[01:40:30 CEST] <dorvan> i think you can use ffmpeg with params to avoid a reconding on live realtime streaming
[01:41:16 CEST] <dorvan> simply the video it's read "as is" and sent to output (same format)
[01:41:34 CEST] <acos> It complains about the audio.  Source is mp3 and it wants aac
[01:41:38 CEST] <klaxa> you mean -c copy?
[01:42:21 CEST] <dorvan> klaxa: copy with  preset to force the realtime...
[01:43:42 CEST] <dorvan> klaxa: https://trac.ffmpeg.org/wiki/StreamingGuide
[01:44:11 CEST] <dorvan> in this way, follow the logic, you have only to organize the input stream
[01:45:03 CEST] <dorvan> klaxa: do you know if a playlist can be used as input directly?
[01:45:08 CEST] <acos> Ohhh. I was following that concat guide trying to convert to a ts file then merge those.
[01:45:28 CEST] <klaxa> you can use the concat demuxer
[01:45:43 CEST] <klaxa> the playlist has to be in the format: file "somefile.mkv" for each file
[01:45:59 CEST] <klaxa> then you can do: ffmpeg -f concat -i playlist.txt [whatever] output.mkv
[01:46:01 CEST] <acos> It did not work klaxa
[01:46:18 CEST] <acos> And it reszied my video to 1920x1088
[01:46:52 CEST] <dorvan> klaxa: acos have asked for something different :-)
[01:47:13 CEST] <klaxa> huh, but you asked for the playlist thing
[01:47:16 CEST] <klaxa> i'm confused
[01:47:24 CEST] <dorvan> consider the request firstly :-)
[01:47:27 CEST] <acos> :/ I'm hitting all the errors possible with this software.
[01:47:35 CEST] <dorvan> yes... acos can't use concat...
[01:47:52 CEST] <acos> Aww. Well at least I tried.
[01:48:00 CEST] <dorvan> klaxa: acos does not want to use concat...
[01:48:17 CEST] <acos> Also my videos have a green line on top and bottom of my video not sure why.
[01:48:26 CEST] <dorvan> so i'm thinking a way to produce a single file for a multiple input....
[01:48:39 CEST] <klaxa> use the concat filter?
[01:48:45 CEST] <dorvan> no
[01:48:47 CEST] <dorvan> :-D
[01:48:48 CEST] <klaxa> that needs re-encoding though
[01:48:49 CEST] <acos> I will post logs in a bit.
[01:49:00 CEST] <dorvan> oh fuc*
[01:49:07 CEST] <klaxa> you can use a lossless codec to avoid quality loss
[01:49:09 CEST] <dorvan> klaxa... without using concat...
[01:49:33 CEST] <klaxa> so you want to concat without concat
[01:49:36 CEST] <dorvan> klaxa: acos does not want to "re-convert"
[01:49:42 CEST] <klaxa> there are two ways to concat
[01:49:44 CEST] <dorvan> exactly:-D
[01:49:59 CEST] <acos> Maybe my logs will help clarify the issue
[01:50:02 CEST] <klaxa> one only works if the files have the same codec and codec parameters
[01:50:07 CEST] <klaxa> the other is independent
[01:50:13 CEST] <klaxa> but requires re-encoding
[01:50:19 CEST] <acos> How can I force an output resolution ?
[01:50:28 CEST] <klaxa> -s 1920x1080
[01:50:37 CEST] <klaxa> that will re-encode
[01:50:44 CEST] <klaxa> if you use -c copy it will be ignored afaik
[01:50:46 CEST] <dorvan>  input (playlist) -> c:copy preset ultrafast lowlatency -> 1 file output  :-)
[01:51:02 CEST] <acos> Why would it change the resolution ? Some kind of x264 bug?
[01:51:28 CEST] <dorvan> klaxa: resolution it's not included in acos question...  can be a secondary problem
[01:51:28 CEST] <klaxa> what is your command line?
[01:51:51 CEST] <acos> Got 99 problems and a girl ain't one
[01:51:55 CEST] <dorvan> acos... if you have all the slices in same and correct format you don't need to change resolution...
[01:52:01 CEST] <dorvan> right?
[01:52:11 CEST] <acos> It does it for me for some reason.
[01:52:15 CEST] <dorvan> you have only to mount the movie...
[01:52:18 CEST] <klaxa> codec options (i.e. preset ultrafast lowlatency) are ignored when using -c copy
[01:52:29 CEST] <dorvan> not...
[01:52:35 CEST] <dorvan> i have different results
[01:52:38 CEST] <acos> Also it changed the frame rate to 28.6882828
[01:52:45 CEST] <acos> From 30
[01:53:03 CEST] <klaxa> what is your command line?
[01:53:30 CEST] <acos> I will post in a bit. Computers off right now.  Thanks for the help people ^_^
[01:53:31 CEST] <klaxa> afaict you have a bunch of clips you exported from some other program, right?
[01:53:53 CEST] <klaxa> and you want to concatenate them into one file?
[01:54:46 CEST] <klaxa> are you sure the program you use for exporting isn't messing something up already?
[01:54:46 CEST] <dorvan> it's embedded in the our program since a week after some weeks on here to read the same things you are writing now..
[01:55:09 CEST] <dorvan> I've followed this https://trac.ffmpeg.org/wiki/StreamingGuide
[01:55:29 CEST] <dorvan> and many other related topics on the web...
[01:55:52 CEST] <klaxa> wait, how is this related to streaming?
[01:55:52 CEST] <dorvan> also this https://sonnati.wordpress.com/
[01:55:56 CEST] <klaxa> or is that another problem?
[01:56:02 CEST] <acos> klaxa: ya
[01:56:02 CEST] <dorvan> yes :-)
[01:56:09 CEST] <klaxa> it was an "or" question
[01:56:12 CEST] <klaxa> "yes" is an invalid answer
[01:56:23 CEST] <dorvan> klaxa: i'm happy i've not a problem, i've answering and trying to help acos...
[01:56:47 CEST] <acos> klaxa: well yes videos from a program.  They are exports.
[01:56:49 CEST] <dorvan> i've asked to you 1 thing i don't know... and you are going around and around :-)
[01:57:27 CEST] <klaxa> can you repeat that question? i'm really confused by you guys :P
[01:57:31 CEST] <acos> Sorry.  Not sure what to do.
[01:57:38 CEST] <dorvan> acos: your video slices are all ready in the same format and all you need, right? you have only to merge up without make a recoding, right?
[01:57:59 CEST] <acos> Yes? They are h264 video clips
[01:58:18 CEST] <klaxa> if they really are the same format, the concat demuxer *should* work, however without output from ffmpeg no definite conclusion can be made
[01:58:20 CEST] <dorvan> ok... you have to concat without using concat :-D
[01:58:31 CEST] <dorvan> klaxa: you are a mirror
[01:58:33 CEST] <acos> It gets mad about the audio not being acc
[01:58:43 CEST] <klaxa> then use a different container
[01:58:52 CEST] <acos> Not sure how.
[01:58:53 CEST] <dorvan> ok... i go to bed ...
[01:59:04 CEST] <klaxa> ffmpeg [input stuff] output.mkv
[01:59:05 CEST] <acos> I'm new to ffmpeg command line
[01:59:19 CEST] <klaxa> just specify the output file as something that ends in .mkv
[01:59:27 CEST] <dorvan> good night acos, good night mr blinders
[01:59:44 CEST] <acos> Night dorvan
[01:59:51 CEST] <acos> Thanks for the help :)
[02:00:15 CEST] <klaxa> whoops
[02:00:17 CEST] <klaxa> bad touchpad
[02:01:35 CEST] <dorvan> acos: if the solution of klaxa, does not match your problem (can be a good percentage...) looks to merge video as streaming input, without recoding.
[02:02:47 CEST] <acos> Will do. Going to do some dishes then hop on the pc
[02:06:26 CEST] <dorvan> acos: the klaxa tips can be good... https://stackoverflow.com/questions/11647868/using-ffmpeg-to-stream-continuously-videos-files-to-a-rtmp-server
[02:07:39 CEST] <acos> Sounds great. :D
[03:25:44 CEST] <redrabbit> what is a good interface/service for win10 to transcode a media library, music and videos
[03:26:01 CEST] <redrabbit> i dont want something like plex
[04:33:34 CEST] <mozzarella> guys
[04:34:15 CEST] <mozzarella> when I reencode a video, it doesn't use hardware acceleration (i.e. my graphic card), right?
[04:37:31 CEST] <c3r1c3-Win> Well... not unless you tell it to use whatever compressor your GPU has.
[04:39:09 CEST] <Over> Hi, i'm having trouble with ffmpeg, and searching on google didn't solve my problem
[04:40:53 CEST] <mozzarella> c3r1c3-Win: how do I do that? is it going to be faster?
[04:41:59 CEST] <c3r1c3-Win> mozzarella: Faster? Depends. Better Quality at the same bitrate as x264 at veryfast? No, at least not that I've ever seen.
[04:45:11 CEST] <Over> Maybe someone can help me, so here is my problem, i'm using cuda to hw accelerate the encoding of a rtmp live stream, and when i want to apply filters to resize it, i get this : "Impossible to convert between the formats supported by the filter 'graph 0 input from stream 0:0' and the filter 'auto_scaler_0'
[04:45:27 CEST] <c3r1c3-Win> mozzarella: How? Depends on your GPU. If you have an Intel look at the Quicksync option in ffmpeg. If you have an NVidia, look at the NVENC options. If you have an AMD... I think someone by the name of Xaymar is working on AMF support in ffmpeg, but don't quote me on that.
[08:54:00 CEST] <igracia> morning! go a question related to padding a video with black frames to delay it, using vstack and hstack. I've managed to achieve this with overlay and setpts=PTS-STARTPTS+xx/TB, and yesterday c_14 suggested just concatenating black video. Thing is I'll be building a matrix of 16-25 videos, and 15-24 of them will have this offset. Is hstack+vstack+concat 16 videos more performant than overlaying 16 videos?
[08:54:13 CEST] <igracia> Morning! got a question related to padding a video with black frames to delay it, using vstack and hstack. I've managed to achieve this with overlay and setpts=PTS-STARTPTS+xx/TB, and yesterday c_14 suggested just concatenating black video. Thing is I'll be building a matrix of 16-25 videos, and 15-24 of them will have this offset. Is hstack+vstack+concat 16 videos more performant than overlaying 16 videos?
[08:54:31 CEST] <igracia> c_14: yesterday I lost connection, that's why I couldn't follow up
[09:08:54 CEST] <thebombzen> igracia: overlay is much slower than hstack and vstack
[09:12:21 CEST] <igracia> thebombzen: even with the generation+concatenation of 15 black color streams? Of course I cna always measure, but just checking here just in case it's not even worth measuring
[09:12:50 CEST] <igracia> I can't reuse the same "color" filter output, right?
[09:13:01 CEST] <thebombzen> generation of pure black is extremely easy
[09:13:29 CEST] <thebombzen> the overlay filter is slow, and if you can avoid using it you should
[09:14:16 CEST] <thebombzen> I mean, to generate pure black you basically just have to zero out memory. that's not hard
[09:34:21 CEST] <igracia> thebombzen: thanks a lot!
[09:59:01 CEST] <mozzarella> guys
[09:59:06 CEST] <mozzarella> hello
[10:04:20 CEST] <tadau> hi
[10:04:49 CEST] <tadau> are there no keys defined to adjust volume in ffplay?
[10:07:31 CEST] <JEEB> don't try to use ffplay as a real player; utilize something like mpv or libmpv as a player based on the FFmpeg libraries :)
[10:42:42 CEST] <taniey> can ffplay get multiple input?
[10:49:40 CEST] <BtbN> thebombzen, zeroing out memory gives you green though
[10:50:13 CEST] <BtbN> getting black, with yuv, is slightly more complex
[10:50:23 CEST] <JEEB> I think wm4 added a function for that
[10:50:43 CEST] <JEEB> it went into libav at least, probably ffmpeg too
[10:50:58 CEST] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=commit;h=463b81de2b252691d75417643597c42684bf830d
[10:51:01 CEST] <JEEB> yup
[10:51:32 CEST] <JEEB> > Common cases like yuv420p10 or RGBA can't be handled with a simple memset
[11:48:32 CEST] <dragmore> so im trying to test my Nvidia 1070GTX for cuvid encoding, anyone got some examples where one can see the profile, preset, scenecut usage etc?
[11:49:45 CEST] <BtbN> cuvid is a decoder. nvenc is the encoder
[11:52:37 CEST] <dragmore> btbn, sorry, i mean nvenc
[11:53:16 CEST] <BtbN> Can always consult ffmpeg -help encoder=nvenc
[11:54:06 CEST] <dragmore> nvenc is h264, is the same one used for HEVC ?
[11:54:19 CEST] <JEEB> I think the encoders are separate
[11:54:22 CEST] <JEEB> nvenc_hevc or so?
[11:54:27 CEST] <BtbN> hevc_nvenc
[11:54:30 CEST] <JEEB> ight
[11:54:33 CEST] <BtbN> as h264_nvenc is the h264 one
[11:54:47 CEST] <dragmore> yupp thats the one
[11:54:50 CEST] <BtbN> They are essentially the same encoder though. Sharing 99% of the code
[11:55:25 CEST] <BtbN> And don't expect wonders from the hevc encoder. It's not very good
[11:55:31 CEST] <dragmore> i knwo
[11:55:38 CEST] <dragmore> its for some realtime projects
[11:55:52 CEST] <JEEB> you'd probably get better results from realtime AVC :D
[11:55:54 CEST] <dragmore> 2160p50 8bit source material
[11:55:56 CEST] <JEEB> in either SW or HW
[11:56:03 CEST] <BtbN> You might be better off sticking with h264 for those. Way better compatiblity.
[11:56:17 CEST] <dragmore> target is our STB (uhd main10 decode)
[11:56:27 CEST] <JEEB> right
[11:57:04 CEST] <BtbN> As stupid as it sounds: For video encoding jobs with nvenc, a 1050 or 1050 Ti is the better choice, if you don't need the GPU power of a 1070.
[11:57:06 CEST] <dragmore> im just curious if ffmpeg+nvenc can deliver something thats watchable at all ;)
[11:57:23 CEST] <dragmore> 1070 is what i have here infront of me ;)
[11:57:26 CEST] <JEEB> BtbN: it's not stupid, it's called "they share an ASIC"
[11:57:46 CEST] <BtbN> the 1050 has a better, more modern, ASIC than the 1060 and higher
[11:57:51 CEST] <JEEB> oh
[11:57:52 CEST] <JEEB> funky
[11:57:58 CEST] <dragmore> whats the relationship with the cudacores and the nvenc asic part?
[11:58:01 CEST] <BtbN> Because it was the last card to be released
[11:58:06 CEST] <JEEB> dragmore: not really much
[11:58:11 CEST] <BtbN> nvenc/cuvid is dedicated silicon
[11:58:17 CEST] <JEEB> ASIC is a separate component on the thing
[11:58:19 CEST] <BtbN> the GPU is not involved with it at all
[11:58:21 CEST] <dragmore> does the nvenc "encoder" use cuda at all for some parts of the work?
[11:58:26 CEST] <dragmore> ok
[11:58:41 CEST] <BtbN> Some of the post-processing features of cuvid use cuda
[11:58:45 CEST] <BtbN> like deinterlacing and scaling
[11:58:55 CEST] <JEEB> even GPU manufacturers noticed that the kool-aid was not gonna help GPGPU encoding
[11:59:01 CEST] <dragmore> well this is source = destination regards to resolution, framerate etc
[11:59:20 CEST] <dragmore> any reccomended settings for RT 25fps?
[11:59:45 CEST] <BtbN> the slowest one you can find
[12:00:02 CEST] <BtbN> so, just put slow there, and let the automatism do its job
[12:00:13 CEST] <dragmore> -preset slow -profile main10 -level 5
[12:00:18 CEST] <dragmore> what rate control method?
[12:00:25 CEST] <BtbN> no need to specify a level, unless you are constrained
[12:00:36 CEST] <dragmore> box can handle 5.1 main10
[12:00:59 CEST] <BtbN> yeah, restrict it to 5.1 then
[12:01:09 CEST] <BtbN> rate control is up to you
[12:01:23 CEST] <dragmore> -rc cbr_ld_hq -b 25000 would prolly suffice
[12:01:26 CEST] <BtbN> if you don't care about the bitrate, just use constqp for a constant quality
[12:01:47 CEST] <dragmore> im allowed a max of 30mbps
[12:01:50 CEST] <BtbN> cbr is generally the worst choice quality wise
[12:01:59 CEST] <dragmore> but for Realtime encoding
[12:02:20 CEST] <BtbN> I'd still stick with vbr_hq and specify a maxrate
[12:02:25 CEST] <dragmore> this is prolly gonna be SMTE 2022-6 input and RTP multicast out
[12:03:04 CEST] <dragmore> SMPTE 2022-6 sorry
[12:03:12 CEST] <BtbN> the only difference between cbr and vbr is that cbr inserts NULL-NAL-Units to fill up to the given bitrate
[12:03:28 CEST] <BtbN> between cbr and vbr + maxrate
[12:03:50 CEST] <BtbN> If you need the strict static bitrate, cbr_hq
[12:03:51 CEST] <dragmore> is there a "skewed realtime" mode for 2 pass vbr?
[12:03:56 CEST] <BtbN> hm?
[12:03:59 CEST] <dragmore> with increased latency
[12:04:10 CEST] <BtbN> nvenc does not have classic two pass
[12:04:15 CEST] <BtbN> It's some weird internal thing.
[12:04:19 CEST] <dragmore> i was just thinking the other day, can one let the encoder to multiple passes within the VBV buffer
[12:04:31 CEST] <BtbN> you can just always turn it on. It just makes it slightly slower
[12:05:01 CEST] <BtbN> I guess you are looking for -rc-lookahead?
[12:05:27 CEST] <dragmore> well.. im a newb here.. so i dont know ;)
[12:05:36 CEST] <dragmore> but this is my offline h264 encoding
[12:05:37 CEST] <dragmore> "ffmpeg -i source.mp4 -pix_fmt yuv420p -codec:v libx264 -x264opts rc-lookahead=50:keyint=100:min-keyint=50:crf=24 -profile high -level 4.1 -preset slow -maxrate 7M -bufsize 14M -force_key_frames "expr:eq(mod(n,50),0)" -c:a copy -y AiB_HQ_3.mp4"
[12:05:57 CEST] <dragmore> something like that, just for Realtime and hevc using nvenc
[12:06:41 CEST] <dragmore> i need to force an IDR frame each gop (2 sec) and give the encoder a scenecut ability to insert an iframe where neded
[12:07:06 CEST] <BtbN> I don't think you can do that with ffmpeg.c
[12:07:25 CEST] <BtbN> There is no interface to dynamically insert an I frame
[12:07:41 CEST] <dragmore> well it works with x264
[12:07:48 CEST] <BtbN> How do you signal it?
[12:07:52 CEST] <BtbN> There is no interface for that
[12:07:54 CEST] <dragmore> as my syntax above, ffprobe confirms it
[12:08:35 CEST] <dragmore> i get an IDR frame every 50fps
[12:08:49 CEST] <dragmore> and additional iframes when there is a hard scene change
[12:08:50 CEST] <BtbN> That's just the gop length
[12:08:59 CEST] <BtbN> And there is some automatic scenecut detection if you use lookahead
[12:09:21 CEST] <dragmore> yes, (i just found it on the net).. so i dont understand it completely
[12:09:32 CEST] <dragmore> but from the export in ffprobe, it seem to work
[12:12:01 CEST] <dragmore> so the syntax for hevc would be something like : ffmpeg input -rc vbr_hq -level 5.1 -profile main10 -preset slow -pix_fmt yuv420p -codec:v hevc_nvenc output
[12:12:58 CEST] <dragmore> how does one specify the max bitrate for -rc ?
[12:13:12 CEST] <dragmore> -rc vbr_hq -maxrate 40000 ?
[12:14:49 CEST] <BtbN> -b:v for the average bitrate, and -maxrate:v for the maxrate
[12:15:12 CEST] <BtbN> Setting a -bufsize:v might also be a good idea
[12:15:45 CEST] <dragmore> ok
[12:15:47 CEST] <dragmore> ffmpeg -i AiB_GoT_Master4-2-2_1080p-IMX-2chWAV.mkv -rc vbr_hq -b:2000 -maxrate:4000 -bufsize:4000 -level 5.1 -profile main10 -preset slow -rc-lookahead=50 -pix_fmt yuv420p -codec:v hevc_nvenc test.ts
[12:16:27 CEST] <dragmore> forgot the encoder ;)
[12:16:29 CEST] <dragmore> ffmpeg -i AiB_GoT_Master4-2-2_1080p-IMX-2chWAV.mkv -c:v hevc_nvenc -rc vbr_hq -b:2000 -maxrate:4000 -bufsize:4000 -level 5.1 -profile main10 -preset slow -rc-lookahead=50 -pix_fmt yuv420p -codec:v hevc_nvenc test.ts
[12:16:33 CEST] <BtbN> and that whole -force_key_frames thing looks just like -g 50 to me?
[12:16:57 CEST] <dragmore> Unrecognized option 'rc-lookahead=50'.
[12:17:17 CEST] <BtbN> the = does not belong there
[12:17:46 CEST] <dragmore> ffmpeg -i AiB_GoT_Master4-2-2_1080p-IMX-2chWAV.mkv -c:v hevc_nvenc -rc vbr_hq -b:2000 -maxrate:4000 -bufsize:4000 -level 5.1 -profile main10 -preset slow -rc-lookahead 50 -pix_fmt yuv420p -codec:v hevc_nvenc test.ts
[12:17:52 CEST] <dragmore> [NULL @ 00000000028833c0] Unable to find a suitable output format for '5.1' 5.1: Invalid argument
[12:18:50 CEST] <BtbN> It thinks 5.1 is your output filename
[12:19:13 CEST] <BtbN> The : is also wrong
[12:19:19 CEST] <BtbN> It's always a space
[12:19:24 CEST] <BtbN> and it's -b:v and -maxrate:v
[12:19:32 CEST] <dragmore> ffmpeg -i AiB_GoT_Master4-2-2_1080p-IMX-2chWAV.mkv -c:v hevc_nvenc -rc vbr_hq -b:2000 -maxrate:4000 -bufsize:4000 -level 5.1 -profile main10 -preset slow -rc-lookahead 50 -pix_fmt yuv420p -codec:a copy -f test.ts
[12:19:54 CEST] <BtbN> I'd also recommend dropping the -pix_fmt entirely
[12:20:05 CEST] <BtbN> and if the input is h264, you can utilize full hw transcoding
[12:20:12 CEST] <dragmore> problem is that the source is 4:2:2
[12:20:19 CEST] <dragmore> mpeg2 xdcam as source
[12:20:28 CEST] <BtbN> hm, yeah. That won't work with hw decoding then
[12:21:26 CEST] <dragmore> hmm
[12:21:27 CEST] <dragmore> ffmpeg -i AiB_GoT_Master4-2-2_1080p-IMX-2chWAV.mkv -c:v hevc_nvenc -rc vbr_hq -b:2000 -maxrate:4000 -bufsize:4000 -level 5.1 -profile main10 -preset slow -rc-lookahead 50 -pix_fmt yuv420p -codec:a copy -f test.ts
[12:21:54 CEST] <dragmore> still : Unable to find a suitable output format for '5.1' 5.1: Invalid argument
[12:25:33 CEST] <dragmore> ffmpeg -i AiB_GoT_Master4-2-2_1080p-IMX-2chWAV.mkv -c:v hevc_nvenc -rc vbr_hq -b:v 2000 -maxrate:v 4000 -bufsize:v 4000 -level 5.1 -profile:v main10 -preset slow -rc-lookahead 50 -pix_fmt yuv420p -c:a copy -f test.ts
[12:25:36 CEST] <dragmore> getting closer
[12:28:33 CEST] <dragmore> hehe
[12:28:34 CEST] <dragmore> [hevc_nvenc @ 00000000026a3d40] No NVENC capable devices found
[12:28:39 CEST] <dragmore> ffmpeg crashed
[12:29:12 CEST] <dragmore> even if ffmpeg -help encoder=hevc_nvenc gave me an output
[12:31:52 CEST] <dragmore> "[hevc_nvenc @ 0000000002797020] Loaded Nvenc version 8.0 [hevc_nvenc @ 0000000002797020] Nvenc initialized successfully [hevc_nvenc @ 0000000002797020] 1 CUDA capable devices found [hevc_nvenc @ 0000000002797020] [ GPU #0 - < GeForce GTX 770 > has Compute SM 3.0 ] [hevc_nvenc @ 0000000002797020] Codec not supported [hevc_nvenc @ 0000000002797020] No NVENC capable devices found"
[12:32:06 CEST] <dragmore> ffs.. wrong gfx card ;)
[13:07:33 CEST] <BtbN> That last commandline looks fine. Only missing the -g 50 for the gop length
[13:47:56 CEST] <dystopia_> hevc encoding doesnt seem viable yet
[13:48:01 CEST] <dystopia_> sooo slooow :(
[13:48:14 CEST] <JEEB> and very few care about the format it seems
[13:48:17 CEST] <JEEB> at least in open source
[13:48:22 CEST] <JEEB> so decoding isn't optimized, either
[13:50:34 CEST] <BtbN> blame the patent crazyness around it
[13:50:46 CEST] <BtbN> And it just is a very complex codec. It will always be somewhat slow
[13:52:00 CEST] <JEEB> in encoding, yes
[13:52:16 CEST] <JEEB> comparatively to AVC that is
[13:52:23 CEST] <JEEB> decoding wise it should be on similar level as VP9 if someone put some love into it
[13:52:35 CEST] <BtbN> hw decoding for it is quite widespread by now
[13:52:39 CEST] <JEEB> yea
[14:14:26 CEST] <charly> Hello
[14:14:33 CEST] <charly> I have a live TS stream containing closed captions
[14:14:41 CEST] <charly> How to burn them into the decoded video ?
[14:15:08 CEST] <JEEB> which  type of CCs?
[14:15:33 CEST] <charly> eia608
[14:18:12 CEST] <JEEB> charly: when you demux packets for the track that can have CCs, check for side data packets with CCs. then if found, open a decoder for the format and create an AVPacket of the side data => feed to decoder => get text => render text with libass or something on top of the video => done
[14:18:19 CEST] <JEEB> it's contrived but possible :P
[14:21:06 CEST] <charly> ok so as i supposed, ass & subtitles filters can't operate with live streams ?
[14:21:28 CEST] <JEEB> why not? it's just that I don't think there's any AVFilters that take in subtitles :D
[14:22:08 CEST] <JEEB> charly: so you get an RGB overlay from libass, and then you can overlay that with the overlay avfilter
[14:22:09 CEST] <JEEB> whether or not you're live or not doesn't really matter does it :P
[14:23:57 CEST] <charly> ok, i will use libass. Thank you !
[14:24:42 CEST] <JEEB> good luck
[16:54:40 CEST] <blap> libass needs fixing :/
[16:55:14 CEST] <blap> putting new subs up at 'random' lines on the screen is unreadable, for multiline/overlapping subs
[17:03:44 CEST] <JEEB> I think the rendering order depends on the order of entry
[17:32:30 CEST] <thatandyrose> hey there! total n00b here. Can anyone help with a question or shall I just ask?
[17:33:55 CEST] <DHE> IRC rule is to read the topic, then just ask according to whatever rules the topic has provided
[17:34:59 CEST] <thatandyrose> thanks DHE... sorry, first time on IRC. Basically I have this ffmpeg related question: https://stackoverflow.com/questions/45964212/how-to-merge-two-audio-files-while-retaining-correct-timings-with-ffmpeg
[17:35:35 CEST] <thatandyrose> If my question is inappropriate or I'm asking in an inappropriate way do let me know
[17:48:10 CEST] <durandal_1707> thatandyrose: perhaps you neeed asetpts filter, hard to guess without input files
[17:50:29 CEST] <thatandyrose> @durandal_1707 thank you for the heads up. You know what... I think my question is flawed. When do `ffmpeg -i 1audio.m4a` I see that start is not at 0... it's at 5... I don't quite get this.... but, is there a way to merge two audio files which take into account non 0 start positions?
[17:50:55 CEST] <thatandyrose> sorry, typo. It should be "When I do ffmpeg..."
[17:52:19 CEST] <durandal_1707> thatandyrose: then you need adelay filter with parameters that will add silence samples so start matches
[17:53:50 CEST] <thatandyrose> @durandal_1707 hmm can you point me to an example? I'll start googling now but if you know of a good one let me know. Another option is to pad each file so they start at 0 right? how would I do that?
[17:54:44 CEST] <durandal_1707> adelay pads audio at beginning
[17:54:57 CEST] <durandal_1707> apad filter pads at end
[17:59:08 CEST] <thatandyrose> cool, thanks @durandal_1707, I'll start taking a look at those. Thanks for your help!
[17:59:35 CEST] <durandal_170> thatandyrose: something like: ffmpeg -i first.mp4 -i second.mp4 -lavfi "[0:a]adelay=5000|5000[a],[a][1:a]amerge"
[18:00:01 CEST] <durandal_170> 5000|5000 says to delay each channel to 5 seconds
[18:02:53 CEST] <thatandyrose> hmm thanks @durandal... ok, I gotta figure out how I get the delay first as I need this to be programmatic with dynamic input. #killmenow
[18:04:10 CEST] <durandal_170> thatandyrose: delays is first pts of first input minus first pts of second input
[19:26:55 CEST] <idlus> Hello, isn't it possible to chain two chromakey filters? It seems that only the last one is in effect.
[19:28:25 CEST] <durandal_1707> idlus: of you need 2 you are doing something wrong
[19:28:56 CEST] <durandal_1707> -vf chromakey,chromakey
[19:30:16 CEST] <idlus> I'll paste my filter chain, hope it's not too long
[19:30:26 CEST] <idlus> [vid1] split=2 [jeu][cam]; [jeu] crop=.65*iw:.86*ih:.065*iw:.01*ih [jeu]; [cam] crop=.21*iw:.23*ih:.75*iw:.75*ih, chromakey=black,chromakey=blue, scale=-1:ih, [jeu] overlay=0:main_h-overlay_h [vo]
[19:30:56 CEST] <BtbN> it's probably not exactly black or not exactly blue
[19:31:17 CEST] <idlus> if I use either one individually it works as I expect
[19:31:43 CEST] <idlus> eg the black region or the blue region is filtered out, but when chained only the blue is in effect
[19:31:51 CEST] <durandal_1707> chromakey only modifies alpha
[19:32:09 CEST] <BtbN> Well, it will overwrite the alpha channel
[19:32:17 CEST] <idlus> oh ok
[19:32:17 CEST] <BtbN> so it kind of makes sense only the last one is "active"
[19:32:30 CEST] <idlus> sure, how can I combine them then
[19:32:31 CEST] <idlus> ?
[19:32:39 CEST] <BtbN> Don't think you can
[19:32:51 CEST] <durandal_1707> yes just merge alphas
[19:33:01 CEST] <durandal_1707> its complicated
[19:34:06 CEST] <idlus> so maybe another filter branch with alphamerge?
[19:34:17 CEST] <BtbN> alphamerge does not just merge two alpha channels
[19:34:21 CEST] <durandal_170> split[a][b],[a]chromakey=black[a],[b]chromakey=blue[b],[a][b]blend=c3_mode=and...
[19:35:23 CEST] <durandal_170> this will create union of two alpha channels
[19:36:21 CEST] <idlus> ok, never used "blend" before, I'll read up on it and test your solution
[19:36:24 CEST] <idlus> thank you both
[20:09:56 CEST] <nicolas17> how do I stop ffplay from disabling my desktop compositor?
[20:10:09 CEST] <nicolas17> I lose window transparency and shadows while ffplay is running
[20:10:25 CEST] <JEEB> don't use ffplay if you want a player based on FFmpeg's libraries: mpv is much preferred
[20:10:33 CEST] <JEEB> it is an actual player while ffplay is a Proof of Concept
[20:11:56 CEST] <nicolas17> I made a 4fps timelapse with ffmpeg and I'm watching the result with ffplay just because vlc seems to get an inconsistent framerate
[20:27:02 CEST] <alexpigment> hey guys, I'm trying to make a patch that adds "coder" (cabac vs cavlc) to NVENC. i'm extremely green on the source code, but here's what I see in libx264.c: https://ffmpeg.org/doxygen/3.0/libx264_8c_source.html (line 974)
[20:27:51 CEST] <alexpigment> and here's what I see in nvEncodeAPI.h https://www.ffmpeg.org/doxygen/3.2/nvEncodeAPI_8h_source.html (line 570)
[20:28:31 CEST] <JEEB> note: that's from 3.2, if you want latest that's "trunk" (or you just use git.videolan.org to browse)
[20:28:39 CEST] <alexpigment> I'm wondering if I can copy what's shown in libx264 into nvenc.c , but I'm not sure what parameters need to reference what's shwn in nvEncodeAPI.h
[20:29:06 CEST] <JEEB> also I have no idea if nvenc even lets you set CAVLC or CABAC
[20:29:25 CEST] <JEEB> well, OK - baseline profile requires CAVLC IIRC
[20:29:33 CEST] <JEEB> so it has to have it around
[20:29:47 CEST] <alexpigment> the API says you can set it
[20:30:04 CEST] <alexpigment> but it's not hooked up in FFMPEG's nvenc in any way that I can tell
[20:30:10 CEST] <alexpigment> the coder parameter is certainly ignored
[20:30:22 CEST] <alexpigment> but the API exposes it, which you can see in nvEncodeAPI.h
[20:30:49 CEST] <JEEB> ok, then you just limit the parameter according to valid values in init()
[20:30:59 CEST] <JEEB> of the libavcodec thing you want
[20:31:10 CEST] <JEEB> and then set the value accordingly in nvenc's API
[20:31:15 CEST] <alexpigment> I've transplanted the code from libx264.c into nvenc.c , but I just am not sure how to hook up the specific parameters from the API
[20:31:47 CEST] <BtbN> also needs a proper capability check if the hardware even supports CABAC
[20:31:56 CEST] <BtbN> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=compat/nvenc/nvEncodeAPI.h;h=c3a829421282d5f22f82fc285723f13eb660f053;hb=HEAD#l718
[20:32:55 CEST] <alexpigment> I don't think there are any nvenc-capable cards that dont' support cabac, although I understand it's safer to check
[20:33:31 CEST] <JEEB> huh, I thought coder was a global avcodec option but the vaapi thing actually defined the AVOption there
[20:33:34 CEST] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=commit;h=c6a8c2a4f7396c4524a081df8a0ef9656946067d
[20:33:45 CEST] <JEEB> (it has more values most likely because it supports more than AVC)
[20:33:46 CEST] <alexpigment> it's global, but it isn't hooked up for nvenc
[20:34:15 CEST] <JEEB> then I wonder why vaapi wrapper got it implemented in the way it got
[20:34:25 CEST] <JEEB> because you can see it definining those AVOoptions
[20:34:53 CEST] <JEEB> if it's just available in AVCodecContext then (´4@)
[20:35:13 CEST] <BtbN> probably so it shows up in help
[20:35:40 CEST] <BtbN> I wish there was some kinda mechanism to declare "I use this global option"
[20:35:47 CEST] <BtbN> which then makes it show up in -help for that encoder.
[20:35:51 CEST] <jkqxz> This one, with all the deprecation guards around it?  <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/avcodec.h;h=513236a863728d123379da834a1ddb48e5affacf;hb=HEAD#l2788>
[20:35:59 CEST] <alexpigment> BtbN, i would be a big fan of that
[20:36:48 CEST] <JEEB> jkqxz: ah ok
[20:36:59 CEST] <JEEB> I had no idea it was being deprecated in favour of encoder-specific AVOptions
[20:37:03 CEST] <JEEB> but then it makes sense :)
[20:37:05 CEST] <jkqxz> I didn't actually look at when it was deprecated, but the private option matches libx264.
[20:37:36 CEST] <alexpigment> for what it's worth, I'm just trying to address a bug I logged up a while back: https://trac.ffmpeg.org/ticket/6475
[20:37:50 CEST] <alexpigment> there's no deprecation warning, at least the last time I tested
[20:39:14 CEST] <BtbN> there definitely is one now
[20:39:54 CEST] <jkqxz> Commit was <http://git.videolan.org/?p=ffmpeg.git;a=commit;h=be00ec832c519427cd92218abac77dafdc1d5487>, apparently.  Makes sense, I guess.
[20:40:44 CEST] <jkqxz> alexpigment:  There is just no warning in general for common options which aren't actually used.
[20:42:16 CEST] <jkqxz> And that isn't really a very easy thing to change.  Every codec would need to declare the set of options they care about and then there could be some common code to check whether any of them are specified and warn.
[20:44:19 CEST] <jkqxz> And if they only use them in some modes but not others then that becomes even more complicated.
[20:44:37 CEST] <alexpigment> honestly, i'm not really picky about global vs encoder-specific options
[20:44:39 CEST] <BtbN> well, only warn if they do declare
[20:44:43 CEST] <BtbN> so the transition can go slowly
[20:44:49 CEST] <alexpigment> I just need it to be hooked up
[20:44:59 CEST] <alexpigment> fwiw, it's certainly not deprecated for x264 as a global option
[20:45:08 CEST] <alexpigment> no warnings
[20:45:13 CEST] <jkqxz> x264 is a private option as well.
[20:45:57 CEST] <jkqxz> <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/libx264.c;h=b11ede61988639ea82f7f8f378ef45792fda779d;hb=HEAD#l968>
[20:46:12 CEST] <alexpigment> ok, so you'll have to pardon my ignorance on how this all works. everything I log on trac is ignored, so I'm trying to about addressing things and I know nothing about programming or the inner workings of ffmpeg
[20:46:33 CEST] <BtbN> I haven't seen anything about this option missing on trac
[20:46:34 CEST] <alexpigment> all I'm trying to do is to get CAVLC encoding in nvenc via ffmpeg
[20:46:36 CEST] <alexpigment> and it is not hooked up
[20:46:46 CEST] <BtbN> what even is that? I never heard that term before.
[20:47:08 CEST] <alexpigment> BtbN: are you being facetious?
[20:48:19 CEST] <alexpigment> well, I'll assume you aren't. it's "context-adaptive variable-length coding", as opposed to cabac = "context-adaptive binary arithmetic coding"
[20:48:19 CEST] <BtbN> what?
[20:49:12 CEST] <alexpigment> cavlc is requires much less processing power and is commonly used on intra-frame formats in NLEs
[20:49:49 CEST] <BtbN> Does HEVC have something similar, or is it h264 only?
[20:50:03 CEST] <alexpigment> if HEVC has it, I'm not aware
[20:50:25 CEST] <jkqxz> HEVC does not have any non-arithmetic coder, no.
[20:50:40 CEST] <JEEB> HEVC decided to drop CAVLC
[20:50:43 CEST] <JEEB> it's CABAC only
[20:51:03 CEST] <alexpigment> yeah, HEVC is already processor intensive enough that they probably didn't see much merit in a coding mode that was easier to process
[20:52:16 CEST] <sikilikis> hey all. How do I get the "fontfile" parameter to work when using the drawtext filter? It seems to be completely ignored. The font never changes and if I provide a bogus filepath to it, ffmpeg happily ignores it anyway
[20:58:08 CEST] <sikilikis> the text gets drawn but I can't change the font being used
[21:00:47 CEST] <jkqxz> BtbN:  Um, ffmpeg probably shouldn't segfault if you try to use h264_nvenc without any hardware, right?
[21:01:04 CEST] <jkqxz> alexpigment:  This work?  <http://sprunge.us/ZbMH>  (Not actually tested.)
[21:01:15 CEST] <BtbN> It should just tell you that it found no GPU. Or just straight up failed to load the cuda libs
[21:03:07 CEST] <jkqxz> Apparently not <http://sprunge.us/QSEZ>.
[21:04:01 CEST] <jkqxz> It shouldn't be trying to call that context function if there is no cuda at all, I guess?
[21:10:53 CEST] <alexpigment> jkqxz: sorry, was away
[21:11:25 CEST] <alexpigment> when you said "Apparently not" were you saying that the patch didn't work, or were you replying the BtbN?
[21:12:29 CEST] <alexpigment> BtbN: actually, I know someone who ran into that same thing, although I had no explanation. I figured he just had some driver debris sitting around
[21:12:41 CEST] <BtbN> The crash?
[21:12:44 CEST] <alexpigment> Yeah
[21:12:55 CEST] <BtbN> That's just an oversight when adding context pushes everywhere
[21:12:56 CEST] <jkqxz> That was to the crash.  First patch might work.
[21:13:00 CEST] <alexpigment> They started getting the crash with a build from late June
[21:13:27 CEST] <alexpigment> OK
[21:13:29 CEST] <alexpigment> Testing this out now
[21:14:03 CEST] <alexpigment> Thank you very much. I would have never known that I needed to make changes to all 3 files
[21:16:20 CEST] <BtbN> https://github.com/BtbN/FFmpeg should have fixes for both
[21:18:06 CEST] <alexpigment> Awesome. Testing now
[21:18:34 CEST] <BtbN> no idea how to determine if that coder mode works or does anything though
[21:19:08 CEST] <alexpigment> really it's just specifying coder 0 and seeing if MediaInfo reports it as CABAC still
[21:19:08 CEST] <jkqxz> Run it through the trace_headers BSF and look for entropy_coding_mode_flag in the PPS.
[21:19:21 CEST] <alexpigment> if coder 0 creates a CABAC file, it's not working ;)
[21:19:38 CEST] <BtbN> coder 0 is auto, which will produce whatever nvenc likes
[21:19:49 CEST] <alexpigment> really?
[21:19:53 CEST] <BtbN> yes
[21:19:58 CEST] <alexpigment> OK, well, i'll use the appropriate command
[21:20:07 CEST] <alexpigment> x264 has coder = cavlc
[21:20:20 CEST] <alexpigment> a little confusing when switching between the two, but not a huge deal I suppose
[21:20:30 CEST] <BtbN> I keps the names consistent for a reason
[21:20:33 CEST] <BtbN> *kept
[21:20:42 CEST] <alexpigment> sorry, i meant to say coder = 0 is cavlc in x264
[21:20:42 CEST] <BtbN> The numerical values are arbitrary
[21:21:25 CEST] <alexpigment> well, they are certainly arbitrary, although you'd like their meanings to stay the same when switching between two encoders
[21:21:43 CEST] <BtbN> nvenc and x264 are diffrent. Can't make them match up perfectly
[21:22:15 CEST] <alexpigment> I agree with you, but you also don't want the behavior to be the opposite
[21:22:31 CEST] <BtbN> The opposite?
[21:22:36 CEST] <alexpigment> At any rate, I can work with this and change the code accordingly so that coder 0 does cavlc
[21:22:49 CEST] <BtbN> Just use the const name, it's there for that reason
[21:22:50 CEST] <alexpigment> nvenc is probably always going to do cabac when set to auto
[21:32:03 CEST] <alexpigment> coder now working for NVENC :)
[21:32:08 CEST] <alexpigment> awesome work
[21:32:18 CEST] <alexpigment> checking the other patches I made now
[21:33:08 CEST] <alexpigment> jkqxz: to clarify, I tested your patch
[21:33:30 CEST] <alexpigment> coder 0 produces CAVLC and coder 1 produces CABAC, perfectly matching x264
[21:34:56 CEST] <BtbN> do not use the numerics
[21:35:02 CEST] <BtbN> they are arbitrary
[21:35:09 CEST] <BtbN> and can change without notice
[21:35:35 CEST] <alexpigment> BtbN: honestly, if you saw how many tutorials and stackoverflows and the like on google that specifically mention coder 0, you might think differently
[21:35:38 CEST] <alexpigment> this is not about me
[21:35:51 CEST] <BtbN> There are a lot of bad "guides" out there, yes.
[21:35:52 CEST] <DHE> doesn't make it right
[21:35:58 CEST] <alexpigment> this is about making sure that the information on the internet remains applicable
[21:36:08 CEST] <BtbN> It never was applicable in the first place
[21:36:12 CEST] <alexpigment> it certainly was
[21:36:15 CEST] <BtbN> It's a const option. You are supposed to use the name.
[21:36:17 CEST] <alexpigment> It was 100% applicable
[21:36:26 CEST] <alexpigment> The guides specifically are referring to x264
[21:36:40 CEST] <BtbN> It's the same for libx264
[21:36:52 CEST] <alexpigment> What I'm saying is that it's preferable to maintain parity with x264 since it's another encoder that produces the same output format
[21:36:59 CEST] <alexpigment> what is the same?
[21:37:14 CEST] <BtbN> It maintains perfect parity with x264. As it uses the exact same constants.
[21:37:59 CEST] <alexpigment> then why are you insisting that I not use constants?
[21:38:07 CEST] <BtbN> Because you are not.
[21:38:15 CEST] <alexpigment> sorry
[21:38:17 CEST] <alexpigment> constants
[21:38:17 CEST] <alexpigment> yes
[21:38:24 CEST] <alexpigment> lemme rephrase
[21:38:35 CEST] <alexpigment> why are you insisting that I not use numerics
[21:38:44 CEST] <BtbN> Because they are not part of the API
[21:38:51 CEST] <BtbN> And can change without notice
[21:39:21 CEST] <alexpigment> look, just google "ffmpeg cabac"
[21:39:22 CEST] <alexpigment> first result
[21:39:27 CEST] <alexpigment> it will tell you to use coder 0
[21:39:37 CEST] <alexpigment> that's very powerful and important
[21:39:42 CEST] <BtbN> And wrong
[21:39:48 CEST] <alexpigment> the first result is spreading "misinformation" according to you
[21:39:50 CEST] <alexpigment> but it works for libx264
[21:39:54 CEST] <alexpigment> to this day it works
[21:40:05 CEST] <alexpigment> if coder 0 can work for nvenc, it should
[21:40:32 CEST] <BtbN> I'm not going to make this code more complicated to cater to bad answers someone gave on stackoverflow.
[21:40:44 CEST] <alexpigment> it's the old saying about software companies. if microsoft has a bug that affects your software, *it's your bug*
[21:40:58 CEST] <BtbN> The numerics are not part of the API for libx264 either.
[21:41:05 CEST] <alexpigment> BtbN: you don't need to. jkqxz already did this in his patch
[21:41:19 CEST] <BtbN> His patch does not expose the auto option nvenc has
[21:41:43 CEST] <DHE> http://ffmpeg.org/ffmpeg-codecs.html#Options-25 libx264 does not list 0 and 1 as valid options to the 'coder' parameter
[21:41:43 CEST] <alexpigment> what is the point of auto?
[21:42:07 CEST] <BtbN> It lets nvenc automatically decide which mode to use
[21:43:29 CEST] <alexpigment> if you specify profile baseline and set the coder to auto, what happens?
[21:43:45 CEST] <BtbN> Don't know. That's driver-internal.
[21:43:50 CEST] <DHE> it will adhere to the baseline limitations
[21:44:13 CEST] <alexpigment> ok, so if you don't specify coder auto and set it to baseline, what happens?
[21:44:24 CEST] <BtbN> It will use the value the preset declares
[21:44:48 CEST] <alexpigment> then I guess it brings me back to the question of "what is the point of auto"?
[21:45:13 CEST] <BtbN> It's what the API declares. So if a preset defines something else, you can override it.
[21:45:24 CEST] <alexpigment> if setting the profile automatically changes the coding mode, then there is really no point in additionally specifying that the coder should be set to auto
[21:45:43 CEST] <alexpigment> in theory, you would only ever specify the coder when you know that the auto is going to be the opposite of what you want
[21:45:48 CEST] <DHE> it's also possible that using a preset will override any settings that conflict with it. but again that's driver dependent
[21:47:26 CEST] <alexpigment> at any rate, I've got something working now, and I appreciate all the work being done here. I was really just trying to make sure that we could keep parity with x264 in terms of all the information that is readily available on the internet
[21:47:39 CEST] <BtbN> There is perfect parity with x264
[21:47:42 CEST] <BtbN> The public API matches
[21:47:47 CEST] <BtbN> except that nvenc has one additional option
[21:48:56 CEST] <alexpigment> BtbN: you said that coder 0 is auto rather than cavlc
[21:49:04 CEST] <alexpigment> that is the nonparity i'm talking about
[21:49:21 CEST] <BtbN> The numeric values are arbitrary
[21:49:35 CEST] <BtbN> cabac or ac is cabac, cavlc or vlc is cavlc.
[21:49:43 CEST] <alexpigment> I get your point, but please step back from being a developer for once second
[21:49:44 CEST] <BtbN> Exactly the same as for libx264
[21:49:50 CEST] <alexpigment> google: ffmpeg "coder 0"
[21:49:54 CEST] <alexpigment> 28,600 results
[21:50:01 CEST] <alexpigment> now google ffmpeg "coder vlc"
[21:50:03 CEST] <alexpigment> 128 results
[21:50:14 CEST] <alexpigment> that should tell you that you kinda have to just give in to the masses
[21:50:19 CEST] <BtbN> again, I'm not going to cater to wrong guides or answers. If we started doing that, ffmpeg would be one hell of a mess
[21:50:26 CEST] <alexpigment> especially considering your assignment of 0 to auto is arbitrary
[21:50:43 CEST] <BtbN> I did not make any assignments, except defining -1 as undefined
[21:50:54 CEST] <BtbN> everything else just comes from the nvEncodeApi header
[21:51:59 CEST] <BtbN> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=compat/nvenc/nvEncodeAPI.h;h=c3a829421282d5f22f82fc285723f13eb660f053;hb=HEAD#l589
[21:53:01 CEST] <alexpigment> I see what you're saying
[21:53:13 CEST] <alexpigment> I don't think you see what I'm saying
[21:53:37 CEST] <BtbN> I see what you're saying. I just plain disagree.
[21:54:19 CEST] <alexpigment> BtbN: Most developers probably would. Anyone in QA or customer-facing positions would not.
[21:54:22 CEST] <JEEB> it's the same thing as all of those recommendations of strict -2 (experimental) breaking if the internal values happen to change for one reason or another (except it was evn mentioned in a message which is d'uh)
[21:55:33 CEST] <alexpigment> Well sure, but any developer probably recognizes that strict -2 is being used rampantly in the wild and won't change it
[21:55:39 CEST] <alexpigment> I would hope so at least
[21:55:51 CEST] <BtbN> If there is a good reason to change it, it would be changed.
[21:56:11 CEST] <alexpigment> BtbN: And that's why people don't update open source software often
[21:56:33 CEST] <alexpigment> I know people in professional environments who won't upgrade their copy of Linux unless they absolutely have to
[21:56:37 CEST] <JEEB> also since the option is being added to a new thing it makes even less sense to try and match internal values between sub-libraries headers since the strings are the thing you're supposed to be using
[21:56:55 CEST] <alexpigment> JEEB: did you see my example about the google search results?
[21:57:16 CEST] <alexpigment> I know you guys are developers, but surely you can see from the end user point of view to *some* degree, right?
[21:57:19 CEST] <JEEB> yes, and that's quite unfortunate. but are any of those about this specific encoder?
[21:57:52 CEST] <alexpigment> No, but that doesn't stop people from having something that works, then trying to port over their code to a similar encoder
[21:58:26 CEST] <alexpigment> I'm sure when you try to learn another programming language, you hope things here and there match up so you don't have to unlearn what you know from the other language
[21:58:29 CEST] <iive> so you are saying that we should forbid this option from taking a number at all
[21:58:38 CEST] <JEEB> iive: that sounds like a good idea
[21:58:50 CEST] <JEEB> the thing is rather incidental anyways :P
[21:59:49 CEST] <alexpigment> I guess I just don't see you guys have such a case of developer-brain that my logic isn't seeping in at all
[22:00:16 CEST] <JEEB> there are cases where doing things for compatibility's sake makes sense
[22:00:27 CEST] <alexpigment> Either way, jkqxz made a great patch, and so I've got something that works fine right now
[22:00:56 CEST] <iive> btw, why do you want cavlc again?
[22:01:13 CEST] <alexpigment> AVC Intra, NLE usage
[22:01:34 CEST] <alexpigment> takes out decoding hit, especially at higher bitrates
[22:01:43 CEST] <iive> so low quant, high bitrates?
[22:01:47 CEST] <alexpigment> right
[22:01:54 CEST] <JEEB> in this case it most definitely doesn't given how this is a new option added for a new encoder (Thus guides do not point at it) and generally if people utilize internal values and expect them to be *globally* the same then derp
[22:02:09 CEST] <JEEB> just like you'd expect all encoders have the same preset values as libx264
[22:02:16 CEST] <iive> alexpigment: does it really help, aka have you benchmarked it?
[22:02:54 CEST] <JEEB> also I think the most hilarious thing would be if the values are mapped to nvidia header values and then *nvidia* changed the internal values they'd point at :P
[22:02:58 CEST] <alexpigment> iive: I trust that the experts at Adobe, Panasonic, etc have done those benchmarks for me and that's why they use it
[22:03:04 CEST] <JEEB> pffft
[22:03:23 CEST] <JEEB> just look at how panasonic, sony etc fucked "AVC Intra"
[22:03:35 CEST] <iive> if you can benchmark, then do benchmark
[22:03:57 CEST] <JEEB> > ISO/IEC standard > companies make proprietary and non-standard versions of it (that cannot be decoded with a standard decoder often)
[22:04:10 CEST] <JEEB> > put out a public spec and an NDA'd implementation thing
[22:04:14 CEST] <iive> because i've heard that cavlc makes low quants so huge, that the cache misses ruin the benefit of the simpler computation.
[22:04:16 CEST] <JEEB> > the two don't match
[22:04:33 CEST] <JEEB> anyways, CAVLC's effect depends really
[22:04:56 CEST] <alexpigment> Why do I feel like every time I come here I'm dealing with a bunch of overworked and underpaid developers? I'm not here to defend international standards. I'd just like to follow what's out there because I don't go out of my way to reinvent to wheel
[22:04:59 CEST] <JEEB> depends on if you use more CPU running through the extra bits, or if you shave off time by the means of CAVLC being faster
[22:05:23 CEST] <JEEB> alexpigment: it's because you say as if those corporations always do their decisions based on cold facts and objective measures
[22:05:38 CEST] <alexpigment> JEEB: again, I'm not trying to defend them. that's not my job
[22:05:46 CEST] <JEEB> yea, your comment was just funny :P
[22:05:53 CEST] <JEEB> but do note I actually commented about CAVLC
[22:05:58 CEST] <iive> alexpigment: we are saying, that you have to do the benchmarks on your own.
[22:06:10 CEST] <iive> their assemstments might be just obsolete
[22:06:24 CEST] <alexpigment> I don't have to do benchmarks. All I came here to do was to make sure that a parameter in the NVENC API was actually hooked up
[22:06:37 CEST] <iive> maybe at the time the cabac hasn't been optimized
[22:06:38 CEST] <JEEB> I generally tend to utilize something like Ut Video for NLE and if I absolutely need to use something non-lossless then libx264 with up to 3 frame or so GOP
[22:07:14 CEST] <JEEB> I think dw made some benchmarks for seeking speed etc some years ago
[22:07:33 CEST] <JEEB> as in, how big of a GOP you can have with H.264 to start having a delay in seeking in NLE-like use cases
[22:08:02 CEST] <alexpigment> Does it really matter though? I'm just trying to match a standard, not see how far I can get away from the standard before it starts to affect performance
[22:08:12 CEST] <JEEB> sure
[22:08:20 CEST] <alexpigment> So this conjecture is pointless to me
[22:08:45 CEST] <alexpigment> You want AVC Intra, you set the GOP to 1 and the encoding type to CAVLC
[22:08:54 CEST] <JEEB> although I'm actually surprised nvenc can output "AVC Intra" looking at how fucked up the panasonic stuff is
[22:09:07 CEST] <JEEB> hard-coded parameter sets that you cannot write into the bit stream
[22:09:08 CEST] <JEEB> etc
[22:09:15 CEST] <alexpigment> Well, this is certainly a case of "let's get as close as we can"
[22:09:25 CEST] <JEEB> ok, so you're not doing actual "AVC Intra"
[22:09:29 CEST] <JEEB> but just intra AVC
[22:09:31 CEST] <JEEB> ;)
[22:09:32 CEST] <BtbN> it probably can't perfectly. But good enough to be accepted by some specific player/software
[22:09:36 CEST] <alexpigment> NVENC's interlace handling is currently fucked, so that's another issue entirely
[22:09:50 CEST] <alexpigment> well, FFMPEG's implementation of nvenc's interlace handling, to be clear
[22:09:52 CEST] <BtbN> It's supposedly fixed in recent enough drivers.
[22:10:01 CEST] <BtbN> The ffmpeg side of it is fine.
[22:10:07 CEST] <BtbN> The driver wasn't
[22:10:14 CEST] <alexpigment> BtbN: I've got an open issue about it still
[22:10:25 CEST] <BtbN> with nvidia?
[22:10:29 CEST] <alexpigment> no, with ffmpeg
[22:10:31 CEST] <BtbN> where?
[22:10:35 CEST] <alexpigment> I compared it with Staxrip
[22:11:07 CEST] <alexpigment> sorry, looking for the ticket now
[22:11:13 CEST] <BtbN> There really isn't a lot to it from the ffmpeg side.
[22:11:23 CEST] <Sgt_Tailor> Hey, I was wondering if it is possible to add a new input to ffmpeg while it is running and add it to a complex_filter as well. I know you can send commands to filters to change the positions of layers in the complex filter, but I've been unable to find anything about adding more inputs on the fly
[22:11:28 CEST] <BtbN> If it does something subtly wrong, it's most likey in the driver
[22:11:46 CEST] <BtbN> Sgt_Tailor, it's not that flexible unfortunately.
[22:11:56 CEST] <BtbN> So, no, not possible.
[22:12:55 CEST] <alexpigment> BtbN: https://trac.ffmpeg.org/ticket/5818
[22:12:59 CEST] <alexpigment> see my last comment
[22:13:02 CEST] <alexpigment> that was from 2 months ago
[22:13:22 CEST] <alexpigment> I haven't checked back in since then, but I think the driver update you're talking about was from earlier this year
[22:13:28 CEST] <Sgt_Tailor> Hmm, can you point me in the direction of something that does allow me to do that BtbN(Excluding OBS because it has no cli or api I can program against)
[22:14:00 CEST] <BtbN> obs has an api
[22:14:14 CEST] <BtbN> All its functionality is in libobs, and the ui just uses that lib itself
[22:14:28 CEST] <BtbN> And it's really the best(and only) thing I know for that job.
[22:14:55 CEST] <Sgt_Tailor> holy balls, thanks! Not sure how I missed that
[22:16:52 CEST] <BtbN> alexpigment, that ticket is quite old. Interlaced Encoding by now works. If you are using the latest nvidia driver
[22:17:04 CEST] <BtbN> I think it was 384?
[22:17:24 CEST] <BtbN> https://devtalk.nvidia.com/default/topic/976088/video-technologies/ffmpeg-h264_nvenc-interlaced-encode/
[22:17:30 CEST] <BtbN> 375.39
[22:17:34 CEST] <alexpigment> Yes, I remember this thread
[22:17:51 CEST] <alexpigment> In that example, they're getting combing artifacts
[22:18:17 CEST] <alexpigment> Now what happens is that there's no combing, but each field in a frame is from the same timestamp
[22:18:32 CEST] <alexpigment> Either way, I'll double check now that it's been 2 months since I last checked it
[22:23:34 CEST] <alexpigment> BtbN: same problem
[22:23:40 CEST] <alexpigment> https://trac.ffmpeg.org/ticket/6260
[22:23:59 CEST] <alexpigment> if you try the "how to reproduce" code with the interlacedsample.mp4, you'll see the problem
[22:24:09 CEST] <alexpigment> x264 creates a smooth 60i video
[22:24:28 CEST] <alexpigment> nvenc creates a choppy video that looks the same as if it were 30p
[22:26:27 CEST] <alexpigment> now of course, you're going to have to use a player that correctly deinterlaces from 60i to 60p (i.e. not VLC)
[22:30:08 CEST] <alexpigment> I tested with 384.76 for what it's worth. However, the important part is that the encode works in Staxrip's NVENC implementation, but not FFMPEG's, so I don't believe this has anything to do with the driver at this point
[22:38:12 CEST] <azarus> What's faster to encode vp8/9 video with, VDPAU or VAAPI (AMD R9 Fury / Intel i5-6600K)?
[22:38:32 CEST] <BtbN> vdpau is a decoder
[22:38:42 CEST] <BtbN> And I don't think vaapi can encode either of them
[22:39:45 CEST] <azarus> BtbN: https://stackoverflow.com/questions/26000606/how-do-you-get-ffmpeg-to-encode-with-vaapi#38133123
[22:39:58 CEST] <azarus> Seems on new platforms hw encode is supported.
[22:40:37 CEST] <jkqxz> VP8 will work on the Intel but not the AMD.  VP9 won't work on either.
[22:40:58 CEST] <BtbN> Does ffmpeg even implement the vaapi vp8 encoder?
[22:41:34 CEST] <azarus> jkqxz: And hw encode is almost always faster, right?
[22:41:43 CEST] <BtbN> you trade speed for quality
[22:42:05 CEST] <azarus> BtbN: Still a massive gain in efficiency.
[22:42:15 CEST] <BtbN> depends
[22:42:23 CEST] <BtbN> if you need twice the bitrate for comparable quality
[22:43:42 CEST] <azarus> BtbN: At least it doesn't take hours for simple and short videos -.-
[22:44:16 CEST] <BtbN> if it takes hours for simple and short videos with libvpx, something is very wrong
[22:47:11 CEST] <azarus> Just a slow proc, and
[22:47:19 CEST] <azarus> maybe wrong cmdlind options.
[22:47:21 CEST] <BtbN> slow proc, that has vp8 hw encoding?
[22:47:35 CEST] <azarus> Well... Was doing it on a different proc before.
[22:48:12 CEST] <azarus> Once on a i7-2600 and once on a Core 2 Duo P8600.
[22:48:21 CEST] <azarus> Now I'll try on a CPU with hw encode.
[22:48:33 CEST] <BtbN> that i7 should be more than capable
[22:49:05 CEST] <azarus> Ehh, still too slow. It was about 2x as fast than the P8600 though.
[22:49:13 CEST] <azarus> faster*
[23:00:43 CEST] <alexpigment> BtbN: I don't suppose you have any interest in looking into why NVENC interlacing is broken, right?
[23:00:54 CEST] <alexpigment> I know there's another developer who tackles all the hardcore NVENC stuff
[23:01:24 CEST] <BtbN> It's 11pm. I don't have much interest to look into anything at the moment.
[23:01:33 CEST] <BtbN> But I'll definitely look at it
[23:01:51 CEST] <alexpigment> That's fine. You asked about it earlier, so I didn't know if that meant you were interested
[23:02:15 CEST] <alexpigment> Anyway, do you thing. I do appreciate all your help, even if we disagree about a few specifics :)
[23:02:19 CEST] <alexpigment> *do your thing, rather
[23:31:09 CEST] <BtbN> jkqxz, could you test if that patch fixes the crashing? I'm fairly confident it does, but don't want to push it untested. And I don't have any machines without nvidia GPUs
[23:34:55 CEST] <jkqxz> ?  The one I sent to the ML earlier works for me.
[23:35:12 CEST] <jkqxz> Or do you mean something else?
[23:47:20 CEST] <alexpigment> so I tried to patch h264_nvenc so that it accepts -level 52 as a valid parameter
[23:47:56 CEST] <alexpigment> but now that I do that, ffmpeg crashes and I get an error that says "Value 52.000000 for paramter 'level' out of range [0 - 51]"
[23:48:22 CEST] <alexpigment> are the valid parameters defined outside of nvenc_h264.c?
[23:49:28 CEST] <alexpigment> nvEncodeAPI.h shows NV_ENC_LEVEL_H264_52 as being an option
[23:49:39 CEST] <alexpigment> I figured I could just add that option to nvenc_h264.c as well
[23:50:07 CEST] <jkqxz> There is an upper bound in the "level" parameter as well as needing to add the 5.2 value at the end of the list.
[23:50:58 CEST] <jkqxz> Third to last element in the initialiser on the line <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/nvenc_h264.c;h=5fcbcb9f4f8f3aa53329d68a3c0924a32e15b080;hb=HEAD#l47>.
[23:51:27 CEST] <alexpigment> yeah, I just added a line after 70
[23:52:00 CEST] <alexpigment> with 5.2 at the beginning instead of 5.1, then I changed the NV_ENC_LEVEL_H264_52 at the end
[23:52:02 CEST] <kepstin> alexpigment: you have to update the max on line 47 as well
[23:52:22 CEST] <alexpigment> ahhh
[23:52:25 CEST] <alexpigment> good eye kepstin
[23:52:27 CEST] <alexpigment> I didn't see that one
[23:53:18 CEST] <alexpigment> Seems weird that it's falsely limited to 5.1, but oh well
[23:53:51 CEST] <kepstin> probably 5.2 was added later and nobody got around to updating it. Once you've done the patch, consider submitting it?
[23:54:20 CEST] <alexpigment> I'll have to familiarize myself with the process, but sure
[23:55:25 CEST] <kepstin> I suppose there isn't usually any reason to set the level to the max supported, of course, since usually the only thing setting level does is apply additional limits
[23:56:02 CEST] <alexpigment> it's a completely fair point. I'm only really doing this because it currently gives a fatal error
[23:56:22 CEST] <alexpigment> sure, no need to do it, but you can't error out on something the encoder supports (and will automatically assign in the right scenarios)
[23:57:48 CEST] <kepstin> i dunno how exactly the nvenc coded works, but with x264 if you set a level that's higher than actually needed, it'll ignore it and save the real, lower level in the file.
[23:58:01 CEST] <alexpigment> yeah, that sounds about right
[23:58:05 CEST] <kepstin> in the file metadata
[23:58:16 CEST] <kepstin> or stream metadata or whatever
[23:58:49 CEST] <alexpigment> the nvenc thing is just like [encoding parameters + -level 52] = fatal error. [encoding parameters without -level 52] = no error, ends up setting level to 5.2 anyway
[23:59:20 CEST] <alexpigment> kepstin: actually, now that I think of it, I think x264 lets you set dumb levels regardless of the need to do so
[00:00:00 CEST] --- Thu Aug 31 2017