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

[burek]

[08:47:31 CET] <liyou> hi
[08:57:16 CET] <stevenliu> hi
[09:26:36 CET] <minru> "mpegts @ 0x235afa0] Non-monotonous DTS in output stream 0:0; previous: 5457171600, current: 5457171600; changing to 5457171601. This may result in incorrect timestamps in the output file." From time to time I get these warnings, can this cause the video/audio sync problem after couple of hours of transcoding live stream?
[09:44:39 CET] <JEEB> minru: if you are using the DTS and need it to be correct, yes. you're feeding the same DTS value to the muxer twice, and libavformat is being nice to you and trying to unfsck your stuff :)
[09:54:14 CET] <minru> I just trying to find out what is causing the video/audio sync problem even I using input PTS for output
[09:55:34 CET] <minru> I'm test 2 sources one is stable and there is no problem with sync, and another is connected by wifi and there is lost packets from time totime
[09:55:44 CET] <minru> *testing
[11:55:33 CET] <minru> JEEB: how to tell libavformat do not try to correct DTS?
[14:00:01 CET] <Bear10> has anyone tried using ffmpeg to produce mpeg-dash and then reproducing it with dash.js on the browser? i'm wondering about recommended ffmpeg params / dash.js config
[14:20:08 CET] <BtbN> I'd rather use hls
[14:20:10 CET] <BtbN> less insane
[14:22:00 CET] <Bear10> do you use that with hlsjs?
[14:22:26 CET] <Bear10> and do you have a recommended command i could use for the ffmpeg cli to try and test it out
[14:42:09 CET] <DHE> for live or ondemand video?
[14:42:33 CET] <DHE> ondemand might also be "pre-processed" or whatever you want to call it
[14:43:41 CET] <DHE> there are different commands for each
[14:46:48 CET] <minru> why every second packet doesn't have PTS when I use h264_qsv encoder with VBR LA ratecontrol? https://pastebin.com/6hZ0LRPt
[15:14:31 CET] <minru> also have notice that TBR is 25 when I use VBR LA ratecontrol
[15:14:33 CET] <minru> Stream #0:0[0x100]: Video: h264 (Main) ([27][0][0][0] / 0x001B), yuv420p(top first), 720x576 [SAR 64:45 DAR 16:9], 25 fps, 25 tbr, 90k tbn, 50 tbc
[15:14:33 CET] <minru> Stream #0:0[0x100]: Video: h264 (Main) ([27][0][0][0] / 0x001B), yuv420p(top first), 720x576 [SAR 64:45 DAR 16:9], 25 fps, 50 tbr, 90k tbn, 50 tbc
[15:14:57 CET] <minru> video is interlaced
[16:00:23 CET] <Nacht> MPEGTS doesn't support HEVC, correct ? If you want HEVC on a HLS stream you need to use fmp4. Or did I miss something...
[16:03:26 CET] <kepstin> hevc should be fine in mpeg-ts, but it's probably not supported by many web browsers. Recent apple devices maybe can play it.
[16:04:09 CET] <JEEB> yea, MPEG-TS side is OK. it was specified ages ago
[16:05:56 CET] <Nacht> Hmmm. Cause from an Apple presentation about IOS 11, I saw this: For Apple clients, HEVC must be packaged as fMP4. No support for HEVC in MPEG-2 TS
[16:06:12 CET] <BtbN> That's their implementation
[16:07:19 CET] <Nacht> I see, so technically it's possible, but if you wish to serve Apple devices, it has to be fmp4
[16:08:36 CET] <Dan39> hi, running on fedora linux. i am trying to put ffmpeg command into a bash script, but it hangs. it seems to be something with the tty, stuck on SIGTTOU. i found that doing `ffmpeg ... </dev/null` makes it work, but then i cant control ffmpeg. any ideas?
[16:11:11 CET] <Dan39> this is what i am trying to do: https://ptpb.pw/Sf8H
[16:11:21 CET] <Dan39> if there is a better way to record camera, let me know :P
[16:12:33 CET] <Nacht> @Dan39: You just want to make snapshots constantly ?
[16:13:05 CET] <Dan39> Nacht: it doesnt make snapshots, it records video
[16:14:13 CET] <Dan39> 10 minutes worth, so that i can view the old footage while it is still recording
[16:14:40 CET] <Dan39> players refuse to open the mp4 until ffmpeg gracefuly exits
[16:15:04 CET] <BtbN> mp4 is useless until the moov atom has been written, and it can only be written at the very end
[16:15:16 CET] <Dan39> yea thats the errors i get, about the damn moov atom
[16:15:32 CET] <alexpigment> i've had luck on viewing MKV before it's fully written, fwiw
[16:15:36 CET] <Dan39> is there a better format maybe?
[16:15:37 CET] <alexpigment> (using Kodi)
[16:15:43 CET] <Dan39> hmm maybe ill try mkv
[16:15:50 CET] <BtbN> mkv is half-broken until it's finallized
[16:16:01 CET] <alexpigment> yeah, the time of the video is wrong
[16:16:03 CET] <alexpigment> but it works
[16:16:10 CET] <alexpigment> the length of the video, rather
[16:16:10 CET] <BtbN> Use mpeg-ts if you want that kind of functionality
[16:16:19 CET] <Nacht> Perhaps just limit it with -t 00:10:00 and then a while loop checking if it's still running ?
[16:16:19 CET] <Dan39> about 1/50 mp4s dont work even after ffmpeg finishes
[16:16:21 CET] <c_14> or fragmented mp4
[16:16:25 CET] <c_14> depending on what needs to read it
[16:16:38 CET] <Dan39> and ffplay is the only player that reliably plays the rtso stream live... :|
[16:16:52 CET] <alexpigment> re MPEG-TS, that's probably a better solution, but FFMPEG's MPEGTS muxer is fairly finicky with audio formats. don't use PCM
[16:16:54 CET] <Dan39> vlc or mplayer/mpv sometimes play, but most of the time freeze after a half second of video
[16:17:18 CET] <Dan39> well it doesnt have audio, so dont care :P
[16:17:28 CET] <alexpigment> well then MPEG-TS is probably a good bet
[16:18:29 CET] <Dan39> but back to my original issue...
[16:18:40 CET] <Dan39> putting ffmpeg into shell script.
[16:19:30 CET] <DHE> iirc mpegts only specifies a single byte as a "codec identifier", so the list of allowed codecs is rather limited to broadcast-certified codecs
[16:19:50 CET] <Nacht> What exactly does the 'timeout' do ?
[16:20:09 CET] <c_14> Dan39: probably not ffmpeg's fault, but timeout's
[16:20:16 CET] <c_14> it's probably not passing stdin/stdout correctly
[16:20:40 CET] <c_14> you can get ffmpeg to ignore stdin with -nostdin
[16:20:48 CET] <alexpigment> DHE: do you think that's why it can't do s16be? (as per the blu-ray spec)
[16:20:48 CET] <Nacht> or just use -t ?
[16:21:02 CET] <c_14> and -v quiet for stderr
[16:21:17 CET] <DHE> alexpigment: maybe? I do more broadcast-type stuff than bluray-type stuff
[16:21:43 CET] <Dan39> looks like you are right c_14
[16:21:50 CET] <alexpigment> DHE: to be clear, I'm just talking about the FFMPEG muxer. I always have to go to MKV first, then make the TS with Tsmuxer
[16:22:01 CET] <Dan39> c_14: it works fine if i paste the script into current terminal though :|
[16:22:53 CET] <c_14> is your terminal also bash?
[16:22:55 CET] <c_14> do you fork?
[16:23:02 CET] <c_14> *the shell in your terminal
[16:23:59 CET] <Nacht> Dan39: https://pastebin.com/QuvWYvnj ?
[16:24:05 CET] <Nacht> that should just work
[16:25:12 CET] <Dan39> c_14: yea, bash
[16:25:30 CET] <Dan39> Nacht: ah, good idea, will try
[16:32:34 CET] <Dan39> so should i change the output extension to.... .ts ?
[16:32:40 CET] <Dan39> or try .mkv first?
[16:39:31 CET] <Dan39> .ts seems to be working well, and i can view it :)
[16:39:48 CET] <Dan39> might still want to put a like 60 minute timeout on it or something
[16:46:40 CET] <Dan39> hmm
[16:46:48 CET] <Dan39> backstep doesnt work well with .ts
[16:47:10 CET] <Dan39> lets try .mkv
[16:47:51 CET] <Dan39> thats the winner!
[16:47:58 CET] <Dan39> dunno why i chose mp4
[16:48:05 CET] <Dan39> i always use mkv for everything else
[17:01:32 CET] <blap> anyone here in europe?
[19:30:09 CET] <LigH> Hi.
[19:30:51 CET] <LigH> I guess the development will be interested in implementing the now OpenSource'd CineForm codec libraries... where may I read about the progress first?
[19:32:26 CET] <JEEB> there is none
[19:33:01 CET] <JEEB> I mean, I think the rest of the stuff in the open sourced thing could be implemented in the decoder now, but nobody seems to have (at least publicly) cared
[19:35:00 CET] <LigH> Having an encoder available would be interesting, to use this format for HBD intermediate files possibly.
[19:35:36 CET] <JEEB> "HBD"?
[19:37:07 CET] <LigH> High Bit Depth
[19:37:18 CET] <LigH> 10 / 12 bit per component
[19:37:45 CET] <JEEB> if you need something like that which can be opened in an editor I'd rather recommend Ut Video. I'm pretty sure it supports 10bit/12bit now
[19:37:51 CET] <JEEB> and it's lossless
[19:38:08 CET] <kepstin> i'd honestly probably just use x264 for 10bit stuff.
[19:38:25 CET] <JEEB> well yea, I just expected him wanting lossless if it's "intermediate"
[19:38:36 CET] <kepstin> x264 can do lossless? :)
[19:38:43 CET] <JEEB> yes, but the editors can't read it
[19:38:49 CET] <DHE> yes, but you must set qp=0 and select a lossless colourspace
[19:38:56 CET] <kepstin> ah, i could see that being an issue, yeah
[19:38:59 CET] <DHE> which has decoder capability issues
[19:39:37 CET] <JEEB> basically the only reason I'd see to encode cineform is to load it up in a video editor, and to be honest for that use case you've already got various other formats
[19:39:56 CET] <LigH> Just curiosity at first, if this format is at all an acceptable compromise, how noticable the loss is at which ratio to really lossless encoded material.
[19:40:17 CET] <JEEB> weird people
[19:40:39 CET] <JEEB> if you go lossy then you've got 10bit AVC and all that jazz around with proper encoders
[19:40:51 CET] <JEEB> but why the flying numnuts would you do lossy for an intermediate
[19:41:46 CET] <LigH> Yeah, curiosity is weird. People like me would indeed invest time into discoveries. Even if the result is disappointing. But if noone tries it, where could I read that it doesn't pay?
[19:42:23 CET] <JEEB> well feel free to waste yer time
[19:42:39 CET] <JEEB> and compare not lossless formats for lossless format use cases
[19:42:43 CET] <JEEB> ggkthx
[19:43:14 CET] <JEEB> anyways, depending on how batshit retarded the cineform library is, it might get supported at some point
[19:43:30 CET] <LigH> Why do I deserve so much disgust?
[19:43:52 CET] <LigH> Did I ever insult you personally?
[19:44:44 CET] <JEEB> lolwat
[19:46:05 CET] <LigH> I feel treated like a person with zero experience... indeed, I am no developer, I don't know every codec in all its details. That makes me a halfwit. But one with some foundation.
[19:46:35 CET] <JEEB> it's just that if you want those awful lossy things that enterprise apps eat there's already prores and dirac/vc2
[19:46:45 CET] <JEEB> and jpeg2000 for that matter if you want to go into java world
[19:47:15 CET] <JEEB> thus, making cineform clips really is nothing that you'd get discoveries from. it's a yet another format in a class that really doesn't make much sense
[19:48:08 CET] <JEEB> but yea, if you make a patch for the library to encode that stuff you can test!
[19:48:36 CET] <JEEB> although seeing if our decoder did anything wrong or didn't support something would most likely be more useful
[19:50:03 CET] <LigH> Rating Cineform low from theoretical knowledge is surely sensible. But people without that amount of insight may prefer a practical sample: "Here, look, I was generous, but it still fails." ;)
[19:50:21 CET] <LigH> I remember how I tested Rududu and was disappointed.
[19:50:24 CET] <LigH> :o
[19:51:12 CET] <LigH> My coding knowledge is not sufficient to provide a library compatible to be bound into ffmpeg. So I will wait and see.
[19:51:49 CET] <LigH> At least I can now tell people that this won't happen "soon"", thanks. :)
[19:52:00 CET] <LigH> Bye.
[19:52:25 CET] <JEEB> well the only thing I know is that nobody has publicly shown interest in seeing how (in)sane the library is :P
[19:52:34 CET] <JEEB> and if it can be integrated into FFmpeg
[19:53:19 CET] <LigH> Good summary. Disappointing, but on point.
[20:11:37 CET] <xscs> Hi , i want to stream on rtsp... who can help me please?
[20:11:50 CET] <xscs> when i stream h264 via udp i got lot of erros
[20:16:16 CET] <ice9> how to convert dv4 to avi or mp4?
[21:06:00 CET] <Cracki> problem: got an aborted mp4 file, so no moov atom. I have another complete one with same settings (just different duration). I've fixed up the mdat box and transplanted the moov (so codec info is good). however, now the various tables are wrong. how can I tell ffmpeg to ignore those and just decode the mdat? streamcopy worked, but it's complaining about aac bitstream errors (don't need the audio actually)
[21:06:27 CET] <Cracki> hm, the video is just black too
[21:06:34 CET] <jya> I have a URL to a ts stream, that changes over time... how do you tell ffplay to not stop when it reaches the end and not treat it as EOF ?
[21:06:53 CET] <Cracki> any way to reconstruct the structure in that mdat box? it's h264 and aac
[21:08:16 CET] <jya> Cracki: the mdat box contains the raw content, and it's indexed by the moov or moof box
[21:08:22 CET] <Cracki> does h264+aac data in an mdat have any recognizable structure?
[21:08:28 CET] <jya> you can't just decode it
[21:08:33 CET] <jya> no
[21:08:53 CET] <Cracki> do you know more about the bitstreams of aac and h264?
[21:08:54 CET] <jya> it's just a big binary blob, and the index is store in the metadata,
[21:09:14 CET] <jya> you won't even be able to tell where the blob of aac are or h264 are
[21:09:15 CET] <Cracki> I'd be ok with speculative decoding
[21:09:21 CET] <jya> if the content is interleaved
[21:10:41 CET] <Cracki> where would I find the specs of h264 and aac bitstreams?
[21:11:03 CET] <SpeakerToMeat> Hello
[21:11:25 CET] <SpeakerToMeat> QUestion is there any way to capture from gstreamer on ffmpeg? I want to capture (and compress) video from a declink in linux, and it seems to be the only way
[21:13:55 CET] <jya> Cracki: for h264 you can get it on ISO site; for AAC you need to pay
[21:13:59 CET] <Cracki> hm
[21:14:02 CET] <jya> but you;ll never get something out of that
[21:14:07 CET] <Cracki> the framing would be enough for aac
[21:14:07 CET] <jya> not in a million years
[21:14:22 CET] <jya> it all depends on the type of AAC
[21:14:33 CET] <Cracki> aac lc
[21:14:36 CET] <jya> you don't know where the data start, where it stops and so on
[21:14:48 CET] <Cracki> I know where the mdat starts
[21:14:50 CET] <jya> h264 in a mp3 is avcc
[21:14:56 CET] <jya> it doesn't have tag at the start
[21:15:01 CET] <Cracki> aye
[21:15:11 CET] <jya> you can't look at the content and say: oh here is the start of a h264 frame
[21:15:21 CET] <Cracki> I don't trust your word on that
[21:15:29 CET] <jya> as you wish...
[21:15:32 CET] <Cracki> ^^
[21:15:49 CET] <Cracki> you're just some random guy who says "it can't be done"
[21:16:02 CET] <jya> I work with h264 bytestream and mp4 on a daily basis, I know pretty well how it's stored in a mp4
[21:16:10 CET] <Cracki> ic
[21:16:42 CET] <Cracki> I do too
[21:16:44 CET] <jya> (i wrote the h264 player and the mp4 demuxer used in firefox), it has a fairly high number of users
[21:16:54 CET] <Cracki> I haven't looked at or written a h264 decoder yet though
[21:16:58 CET] <jya> anyhow... feel free to try
[21:17:48 CET] <Cracki> it's only opaque data to someone who can't make assumptions. I can make assumptions about the data.
[21:18:29 CET] <Cracki> example: a qtrle bitstream contains enough structure to be able to at least manually get started
[21:18:56 CET] <BtbN> If it would be easy/possible to fix broken mp4 files, there would already be tons of tools for it
[21:20:35 CET] <Cracki> nobody said it would be easy
[21:20:49 CET] <Cracki> or cheap ;)
[21:20:59 CET] <jya> like everything, the probability that you can make sense of the data is not zero
[21:21:04 CET] <Cracki> I'm sure those who can do it ask a tidy sum for the service
[21:21:22 CET] <jya> but it's about as much as making sense of purely random data ...
[21:21:26 CET] <SpeakerToMeat> jya: He has a stream of h264 in mp4 without a fourcc/moov?
[21:21:33 CET] <Cracki> aye, no moov
[21:21:37 CET] <SpeakerToMeat> ouch
[21:21:37 CET] <Cracki> I can transplant a moov
[21:21:48 CET] <SpeakerToMeat> Cracki: From the same device? that can help
[21:21:49 CET] <Cracki> so the codec params are the same, but the index tables are wrong
[21:21:51 CET] <BtbN> https://github.com/ponchio/untrunc is the closest thing to an attempt at it I know
[21:22:01 CET] <Cracki> yes same device, or rather same program + codec
[21:22:46 CET] <Cracki> thx I'll look at it
[21:24:50 CET] <jya> for aac, if it was constant bitrate, then maybe... and the aac stream is within an adts container like it's sometimes seen
[21:25:50 CET] <Cracki> hahah that untrunc does some magic number matching
[21:26:13 CET] <Cracki> I'll see if I can verify that in the hex editor
[21:28:29 CET] <Cracki> I'll build it and see what it does...
[21:28:31 CET] <BtbN> it says "horrible hack that needs adjustment on a file-by-file basis" in a lot of places
[21:28:53 CET] <BtbN> specially in the part that handles mp4a
[21:30:45 CET] <Cracki> oh, what are NALs?
[21:30:56 CET] <dreamp> Hi guys I'm using ffprobe to show some info about my frames `ffprobe input.mp4 -show_frames -loglevel trace` and then in between the report it prints this -> `[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fbe9c802a00] stream 1, sample 312, dts 9984000` what is the sample here?
[21:32:52 CET] <jya> NAL is the block that makes a h264 stream.. mp4 are AVCC, so a NAL is made of Size_NAL | NAL_type | blah
[21:33:06 CET] <jya> the Size of the NAL can be 1 to 4 bytes long
[21:33:28 CET] <jya> the size of the NAL size is also found in the moov extra data (in the SPS)
[21:33:47 CET] <Cracki> fascinating http://yumichan.net/video-processing/video-compression/introduction-to-h264-nal-unit/
[21:35:42 CET] <jya> that page doesn't describe what you find in an mp4
[21:36:24 CET] <jya> the 000001 NAL delimiter is not used for AVCC
[21:36:27 CET] <jya> that's AnnexB
[21:36:57 CET] <Cracki> I see structure however :D
[21:38:56 CET] <Cracki> i see lots of 00000003 09
[21:42:28 CET] <Cracki> ok that's more work than I want to spend now, but this tells me it's definitely possible to get data out of this
[21:42:36 CET] <jya> yeah right :)
[21:43:43 CET] <JEEB> if you have some sort of reference from the same device and how the structures are written - it's possible. but takes a lot of time and effort
[21:44:08 CET] <JEEB> I think jya linked untrunc which I think is so far the only open source thing that tries to semi-automate it
[21:47:13 CET] <Cracki> anyone happen to have a windows binary of untrunc? I have qt creator open and will tell it where the ffmpeg dev stuff is, but it's not finding it on its own
[21:48:22 CET] <Cracki> lol hardcoded libav-12.2 path in that .pro file
[21:48:44 CET] <JEEB> yea, definitely not the best of ideas :) usually you use pkg-config for that stuff
[21:49:04 CET] <Cracki> let's see if it builds with ffmpeg too
[21:49:06 CET] <JEEB> PKG_CONFIG_PATH=/your/prefix/lib/pkgconfig pkg-config --libs libavcodec
[21:49:08 CET] <BtbN> the readme just tells you to build it manually with a single g++ invocation
[21:49:11 CET] <Cracki> this is windows ;)
[21:49:16 CET] <Cracki> oh hm
[21:49:19 CET] <Cracki> worth a try
[21:49:32 CET] <JEEB> pkg-config is a thing on windows as well if you have the mingw-w64 toolchain anyways
[21:49:37 CET] <Cracki> not keen on handmade g++ cmdline that includes qt stuff
[21:49:45 CET] <BtbN> There is no qt involved there
[21:49:50 CET] <BtbN> no idea where you're getting that from
[21:50:05 CET] <Cracki> https://github.com/ponchio/untrunc/blob/master/untrunc.pro
[21:50:07 CET] <Cracki> from there
[21:50:18 CET] <Cracki> guess it doesn't use that then
[21:50:22 CET] <BtbN> it even explicitly disables qt
[21:50:36 CET] <BtbN> It's just a .pro file for IDE usage I guess
[21:52:19 CET] <Cracki> ok it's asking for some endian.h, that's not part of ffmpeg
[21:53:03 CET] <Cracki> ah, some c++ stuff...
[21:57:24 CET] <Cracki> yeah that's 5 years old and depends on libav, can't just patch that up to work with ffmpeg
[21:58:07 CET] <Cracki> does dpeend on recent libav (12.2), so I'll try that hten :P
[22:30:11 CET] <Cracki> hm yes that data looks very framed to me
[22:33:55 CET] <Cracki> the one file has frames of 0000 0003, the other 0000 0008
[23:06:34 CET] <SortaCore> hi
[23:06:44 CET] <SortaCore> how complicated is it to use h264_qsv instead of h264
[23:07:05 CET] <SortaCore> I manually select h264_qsv by encoder name, but the output (and CPU usage) seems to say it's using h264 native instead
[23:17:35 CET] <Cracki> please be more specific
[23:22:06 CET] <SortaCore> ...I'm not sure how I could be more specific
[23:22:31 CET] <JEEB> see the hwaccel example(s) under doc/examples
[23:23:22 CET] <SortaCore> I did, they were about as helpful as gasoline against an arsonist
[23:23:34 CET] <JEEB> ok
[23:23:56 CET] <alexpigment> i've done a lot of work with h264_qsv encoding
[23:24:00 CET] <alexpigment> I can help
[23:24:07 CET] <alexpigment> but you need to give your command line so I can see what's failing
[23:24:17 CET] <SortaCore> I'm not using commandline, I'm doing it in C++
[23:24:17 CET] <JEEB> I have a hunch he's using the API
[23:24:23 CET] <alexpigment> ah
[23:24:47 CET] <alexpigment> well, that renders my help useless ;)
[23:24:51 CET] <SortaCore> at the moment I'm finding encoder with avcodec_find_encoder_by_name
[23:25:00 CET] <SortaCore> and yet the output is in h264
[23:25:04 CET] <SortaCore> not h264_qsv
[23:25:10 CET] <SortaCore> so I'm not sure what is needed
[23:25:37 CET] <JEEB> are you trying to decode or encode, first of all?
[23:27:17 CET] <SortaCore> ideally, both
[23:27:39 CET] <SortaCore> I'm receiving a RTSP stream with H264, and re-encoding it into an MP4
[23:27:48 CET] <Cracki> the output is h264 format, the encoder can be h264_qsv
[23:27:58 CET] <SortaCore> yea
[23:28:28 CET] <JEEB> ok, seems like qsv isn't supported by the hw decode example
[23:28:38 CET] <SortaCore> I'm not sure if it is using h264_qsv though, in either case it produces a mp4
[23:28:41 CET] <JEEB> even though many other hwaccels are usable
[23:28:51 CET] <SortaCore> oh, is that a bug or something?
[23:29:13 CET] <JEEB> dunno. possibly just because installing the intel custom drivers etc is a chore or something
[23:29:22 CET] <JEEB> so the dev didn't have what to test it with
[23:29:29 CET] <JEEB> ...or the qsv decoder is a PITA :P
[23:29:34 CET] <JEEB> s/decoder/hwaccel/
[23:29:49 CET] <JEEB> (because those two *are* not the same in FFmpeg nomenclature)
[23:30:00 CET] <JEEB> uhh, meant to put the emphasis on the not
[23:30:01 CET] <SortaCore> well, good thing it's left to the userbase instead of the developers then
[23:30:21 CET] <JEEB> well ffmpeg.c uses the API so it's clearly possible :P
[23:30:25 CET] <SortaCore> would hate for such a PITA to be a problem for more people
[23:30:42 CET] <JEEB> generally if some hwaccel is a PITA it's because the source API is a PITA
[23:30:48 CET] <SortaCore> yea, but if memory serves, last year I spent several weeks trying to work it out
[23:31:10 CET] <SortaCore> didn't really work
[23:31:55 CET] <JEEB> anyways, the hwaccel decode example generally seems to be capable of handling most hwaccels so I guess you would just have to ask the QSV pix_fmt here https://github.com/FFmpeg/FFmpeg/blob/master/doc/examples/hw_decode.c#L47
[23:32:09 CET] <SortaCore> what's the most surefire way to check the actual codec being used for encoding/decoding?
[23:33:03 CET] <JEEB> I'm actually not sure which AVCodec you get back with the whole pix_fmt stuff that's there with hwaccels
[23:33:12 CET] <JEEB> thankfully that seems to be going away in the future, possibly
[23:34:18 CET] <SortaCore> I actually have code converting to format NV12, not QSV
[23:34:29 CET] <SortaCore> because the QSV expects NV12
[23:34:37 CET] <SortaCore> ...or as far as I could work out it did
[23:34:46 CET] <JEEB> you will get NV12 out of QSV, yes
[23:34:55 CET] <JEEB> I'm still speaking in decoding terms since you wanted both
[23:35:04 CET] <kingsley> How dp you specify the total number of frames to render from an ffmpeg source like "mandelbrot" or "cellauto"?
[23:35:09 CET] <JEEB> anyways, it seems like at least qsv decoder has an AVCodec
[23:35:20 CET] <JEEB> so you can check the name part of the struct
[23:35:23 CET] <JEEB> what that says
[23:35:37 CET] <JEEB> if your AVCodec's .name says "h264" then that's the sw decoder
[23:35:46 CET] <JEEB> oh
[23:35:54 CET] <JEEB> it has separate decoder and hwaccel
[23:36:03 CET] <JEEB> :|
[23:37:20 CET] <SortaCore> yea, :| sums me up
[23:37:32 CET] <SortaCore> but add a lot more impatience due to lack of docs
[23:37:52 CET] <SortaCore> and having spent weeks on it watching my finite time on this earth ebb away into tedium
[23:37:54 CET] <JEEB> uhh, I'm just taking a look at the main() of doc/examples/hw_decode.c
[23:38:04 CET] <JEEB> and this isn't too bad :P
[23:38:34 CET] <JEEB> you grab the hwdevice, get the hw_pix_fmt mapping to it
[23:38:35 CET] <SortaCore> if you select h264_qsv and it switches to native, it's pretty bad
[23:38:54 CET] <SortaCore> but I will investigate what was the problem last year
[23:39:01 CET] <durandal_1707> kingsley: with duration option or trim filter
[23:39:18 CET] <SortaCore> I put big #ifdef RTSP_QSV_DECODER around a bunch of the code, which isn't a good sign
[23:40:27 CET] <JEEB> SortaCore: I can't see your crap so I have NFI where you were going wrong. but I would have guessed the QSV decoder (not hwaccel!) gets used if you pick the "h264_qsv" with the normal AVCodec picking API
[23:40:51 CET] <kingsley> durandal_1707: I'm looking for an example of ffmpeg using "duration"...
[23:41:29 CET] <SortaCore> so there's more hoops to jump through and it doesn't pick hwaaccel like any sane code would? >.>
[23:41:59 CET] <JEEB> hwaccels have *always* been special because they need additional initialization and give you HARDWARE textures
[23:41:59 CET] <SortaCore> welp it just crashed and the only infomation is "fatal program exit requested" with no call stack, o boy
[23:42:35 CET] <JEEB> the qsv_h264 decoder also uses the same APIs but gives you RAM pictures
[23:42:36 CET] <SortaCore> how could you use a hardware encoder and not use hardware textures?
[23:42:38 CET] <JEEB> as far as I can see
[23:42:51 CET] <SortaCore> it's not exactly a logical choice, but ok
[23:42:51 CET] <JEEB> also goddamnit I thought we were doing this step by step
[23:43:03 CET] <JEEB> first get the goddamn decoding working
[23:43:03 CET] <SortaCore> well, I have code as is
[23:43:07 CET] <JEEB> then the encoding
[23:43:12 CET] <SortaCore> alright, let me lay it out then
[23:43:34 CET] <SortaCore> I have encoding and decoding working, video file is produced, and I'm getting a display feed from the RTSP stream too
[23:43:49 CET] <JEEB> for decoding as far as I can goddamn see the doc/examples/hw_decode.c example might be able to do QSV by just adding the pix_fmt for QSV hwaccel into the list
[23:43:51 CET] <SortaCore> I just need to make sure it uses QSV properly because right now the CPU is exploding constantly
[23:44:10 CET] <JEEB> and yes, QSV is known to be *very* quirky
[23:44:21 CET] <JEEB> not the libavcodec version, but QSV in general
[23:44:26 CET] <JEEB> s/version/wrapper/
[23:44:30 CET] <JEEB> fuck I should be sleeping by now
[23:44:43 CET] <JEEB> instead of trying to generally help a person who gladly seems to be taking the piss on FFmpeg
[23:44:47 CET] <durandal_1707> kingsley: -vf mandelbrot,trim=start_frame=0:end_frame=0
[23:44:57 CET] <durandal_1707> got idea?
[23:45:09 CET] <JEEB> also my condolences on picking QSV because that seems to be the least liked hwaccel thing
[23:45:21 CET] <JEEB> for decoding there's thankfully VAAPI on intel
[23:45:27 CET] <JEEB> (and I think it has encoding now?)
[23:45:29 CET] <SortaCore> I appreciate your help JEEB, last time I was here I got barely anything
[23:46:08 CET] <kingsley> durandal_1707: OK, thank you. I seem to have also got it working by adding ... "-vf trim=duration=1".
[23:46:17 CET] <SortaCore> as in, a year or so ago, that's why I left it for a year
[23:46:38 CET] <JEEB> I love the documentation on QSV https://trac.ffmpeg.org/wiki/Hardware/QuickSync
[23:46:41 CET] <durandal_1707> kingsley: yes that trims to 1 sec duration
[23:46:48 CET] <JEEB> basically a big "please don't try to use it"
[23:47:10 CET] <JEEB> the QSV stuff, that is
[23:47:59 CET] <SortaCore> "Windows: (TODO)"
[23:48:21 CET] <JEEB> I know it is there with libmxf
[23:48:24 CET] <JEEB> *mfx
[23:48:30 CET] <JEEB> and it gets built on windows as well
[23:48:35 CET] <JEEB> and it /might/ even work
[23:48:39 CET] <SortaCore> yea, I built libmfx
[23:48:45 CET] <JEEB> but it seems to be a "fun" dance with driver versions etc
[23:48:49 CET] <SortaCore> and I suspect it would work, if I can just make sure I invoke it properly
[23:49:09 CET] <SortaCore> so I should look up hwaaccel after getting the decoder?
[23:49:37 CET] <JEEB> for decoding please take a look at the hwaccel decoding example, it will also let you test dxva2/d3d11va
[23:49:46 CET] <JEEB> which are the windows standard HW decoding APIs
[23:49:52 CET] <JEEB> and even intel is relatively stable with that
[23:50:09 CET] <SortaCore> my client wants performance, basically
[23:50:25 CET] <SortaCore> there'll be multiple rtsp feeds (think camera software)
[23:50:38 CET] <JEEB> that will basically work until you hit the top limit on the GPU
[23:50:42 CET] <SortaCore> so if D3D11VA will be better than QSV, I'll go for it
[23:51:17 CET] <JEEB> they should give similar if not the same perf decoding-wise, but I'm not sure which is simplest to then feed to the encoder
[23:51:31 CET] <JEEB> ok, there seems to be a patch for a qsv encoding example
[23:51:35 CET] <JEEB> on the mailing list
[23:52:12 CET] <SortaCore> alright, throw it at me
[23:52:19 CET] <JEEB> https://patchwork.ffmpeg.org/patch/4581/
[23:52:28 CET] <JEEB> from intel itself
[23:53:08 CET] <JEEB> seems to feed local buffers of a dummy image into QSV
[23:53:36 CET] <JEEB> (there's now a function to get an all-black frame so that could be made simpler)
[23:54:47 CET] <SortaCore> "patch format detection failed"
[23:54:58 CET] <SortaCore> it's the download link at the bottom of that URL right
[23:55:11 CET] <JEEB> SortaCore: best way to get the patch is to `curl -L https://patchwork.ffmpeg.org/patch/4581/mbox/ > thing.patch`
[23:55:18 CET] <JEEB> and then `git am thing.patch`
[23:55:21 CET] <JEEB> which would apply it
[23:55:25 CET] <JEEB> on top of your current tree
[23:56:34 CET] <JEEB> some parts might not apply cleanly in the indexes but applying those lines manually should be real simple
[23:56:43 CET] <JEEB> indexes I mean lists
[23:56:59 CET] <SortaCore> yea, it's fussing, I'll go manual
[23:57:07 CET] <JEEB> since things were added into them after this patch and the fuzzy application of patches doesn't necessarily understand it :P
[23:57:50 CET] <JEEB> funky how it's using normal CPU memory
[23:58:12 CET] <JEEB> although I guess that makes sense for an oversimplified example
[23:58:12 CET] <SortaCore> I'm not sure how QSV works, it seems midway between CPU and integrated GPU
[23:58:20 CET] <JEEB> it's on the "GPU" part
[23:58:29 CET] <JEEB> the ASIC that is
[23:58:37 CET] <SortaCore> hmm, alright
[23:58:47 CET] <JEEB> and I know that for copy-back people have written optimized custom memcpys from the "GPU" memory region
[23:58:53 CET] <JEEB> even though it's on the CPU die
[23:59:08 CET] <JEEB> so in theory "GPU"-"GPU" should be fastest
[23:59:18 CET] <JEEB> but yea, the example comes from intel so it should work and use QSV hwaccel :P
[00:00:00 CET] --- Fri Nov 10 2017