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

[burek]

[03:30:44 CEST] <Zexaron> hello
[03:31:11 CEST] <Zexaron> how come AV_register_all and the stuff is all deprecated, what are the replacements?
[03:43:45 CEST] <Zexaron> allright not neded I guess, works fine without it
[06:55:36 CEST] <grosso> hi
[06:57:06 CEST] <grosso> I have a little problem:
[06:57:45 CEST] <grosso> I'm streaming video with ffmpeg, using mpegts and a udp:// filename
[06:58:14 CEST] <grosso> the video is encoded as h264
[06:58:48 CEST] <grosso> the problem is that when decoding, sps/pps nals are missing
[07:00:06 CEST] <grosso> how can I force ffmpeg to put that data on the stream?
[07:15:22 CEST] <Adcock> furq: I can't understand x axis of the graph.
[07:15:33 CEST] <Adcock> Look Opus bitrate 96
[07:16:02 CEST] <Adcock> Then next line says 107 kbps.
[10:13:14 CEST] <Adcock> How to achieve visually lossless encoding using vp9 ?
[12:03:34 CEST] <Genocide> hi all! its possible to stream videos to rtmp server using playlist or pipe without reconnect?
[12:07:40 CEST] <Blacker47> pi-, stop it.
[14:28:50 CEST] <victorqueiroz> How to detect the right decoder for the video?
[14:30:33 CEST] <BtbN> avformat tells you which codec was found, if it has any idea from the container. If not, you'll have to probe for it.
[14:31:15 CEST] <victorqueiroz> This is what I have:
[14:31:16 CEST] <victorqueiroz> major_brand=mp42
[14:31:16 CEST] <victorqueiroz> minor_version=1
[14:31:16 CEST] <victorqueiroz> compatible_brands=mp41mp42isom
[14:31:16 CEST] <victorqueiroz> creation_time=2018-10-01T12:45:20.000000Z
[14:31:24 CEST] <victorqueiroz> I believe it'd be mp42?
[14:32:06 CEST] <BtbN> That's the container...
[14:32:58 CEST] <Mavrik> I think it's worth figuring out if he's using the API or hacking together something else :P
[14:33:03 CEST] <BtbN> avcodec has a probe function, and containers usually tell you what they contain, avformat tells you about it
[14:33:34 CEST] <BtbN> When using the commandline there is no point to think about that, since ffmpeg.c does it right on its own
[14:33:59 CEST] <victorqueiroz> I'm using the C++ API, actually. I believe it's better to read the command line implementation?
[14:34:25 CEST] <BtbN> There is no C++ API
[14:34:30 CEST] <victorqueiroz> Sorry, the C API
[14:34:47 CEST] <Mavrik> the C API will tell you which codec the stream has
[14:34:53 CEST] <victorqueiroz> I'm writting C++ code using it... Like a wrapper to create various formats for a video sent by the client. Not sure how fast that'll be
[14:34:55 CEST] <Mavrik> and then you just use avcode_find_decoder or whatever the call is
[14:35:07 CEST] <Mavrik> victorqueiroz: there's a whole example/ dir that will give you the code you need :P
[14:35:41 CEST] <victorqueiroz> Mavrik: That? https://github.com/FFmpeg/FFmpeg/tree/master/doc/examples
[14:36:33 CEST] <Mavrik> yes, the transcoding.c is probably the most interesting
[14:36:48 CEST] <Mavrik> or demuxing_decoding.c for only the decode part
[14:41:25 CEST] <victorqueiroz> Mavrik: Yes, thank you.
[14:41:43 CEST] <victorqueiroz> Apparently two streams h264 and aac. I suppose it's Video and Audio respectively
[15:15:14 CEST] <Hello71> or you could just use ffprobe (hell, even ffmpeg will tell you)
[15:15:29 CEST] <victorqueiroz> Interesting, now on decoding I'm getting: pps_id 3199971767 out of range
[16:48:34 CEST] <grosso> decode_slice_header error
[16:48:34 CEST] <grosso> no frame!
[16:48:34 CEST] <grosso> non-existing PPS 0 referenced
[17:06:39 CEST] <pi-> Blacker47: sorry about that, I don't know why my MacBook is connecting and dying multiple times while I'm sleeping.
[18:06:50 CEST] <hiihiii> hi
[18:07:10 CEST] <hiihiii> can someone shed some light on the -frame_drop_threshold option
[18:07:12 CEST] <hiihiii> ?
[18:08:45 CEST] <hiihiii> what's written in the documentation is vague for me
[18:08:47 CEST] <hiihiii> "which specifies how much behind video frames can be before they are dropped. In frame rate units, so 1.0 is one frame. The default is -1.1."
[18:09:39 CEST] <furq> hiihiii: i'm guessing that's for use with -vsync
[18:10:24 CEST] <hiihiii> yes
[18:10:55 CEST] <hiihiii> that was my initial thought. it's written after vsync's documentation
[18:11:21 CEST] <hiihiii> what I'm doing right now is using ffmpeg to capture my screen
[18:11:52 CEST] <hiihiii> -vsync 2 gives me good results but in VFR
[18:12:41 CEST] <hiihiii> with -vsync 1 my recordings seem like they are in 30fps rather than the 60fps I told ffmpeg to capture
[18:13:38 CEST] <BtbN> How are you capturing the screen?
[18:14:22 CEST] <hiihiii> ffmpeg -loglevel quiet -hwaccel dxva2 -threads 1 -f gdigrab -rtbufsize 512M -framerate 60 -offset_x 187 -offset_y 92 -video_size 630x464 -draw_mouse 0 -show_region 0 -i desktop -pix_fmt yuv420p -c:v libx264 -preset ultrafast -tune zerolatency -crf 21 -an -r 60 -vsync 1 "source_vsync1_fdt120.mp4"
[18:15:37 CEST] <hiihiii> this step (capturing) is for preparation for another round of encoding using two inputs
[18:16:15 CEST] <hiihiii> one inputs is in VFR. the second one I'm trying to get now has to be CFR
[18:16:34 CEST] <hiihiii> otherwise I'll run into syncing issues
[18:17:06 CEST] <hiihiii> right now I don't have a problem
[18:17:32 CEST] <hiihiii> I just want to capture the best possible way I can
[18:18:27 CEST] <hiihiii> maybe I'll increase the size of -rtbufsize and lower the -crf and see where that takes me
[18:19:05 CEST] <BtbN> maybe it just can't keep up with 60 fps
[18:19:28 CEST] <hiihiii> obviously yeah
[18:19:31 CEST] <furq> gdigrab is slow
[18:19:47 CEST] <hiihiii> -f dshow
[18:19:48 CEST] <furq> idk if that's the problem but it's generally better to use a proper dshow capture device
[18:20:58 CEST] <hiihiii> I was gonna try that too but really wanted to know if -frame_drop_threshold would be beneficial
[18:38:53 CEST] <hiihiii> -f gdigrab -rtbufsize 2048M -framerate 60 -offset_x 187 -offset_y 92 -video_size 630x464 -draw_mouse 0 -show_region 0 -i desktop -pix_fmt yuv420p
[18:39:15 CEST] <hiihiii> the same command with dshow
[18:39:18 CEST] <hiihiii> -f dshow -rtbufsize 2048M -framerate 60 -pixel_format yuv420p -i "video=screen-capture-recorder" -vf "crop=630:464:187:92"
[18:40:16 CEST] <hiihiii> :( dshow performed badly. I think since this command needs to corp its input
[18:49:41 CEST] <kepstin> you should consider using OBS for screen capture on windows, it has a higher performance builtin capture method.
[18:53:31 CEST] <BtbN> ffmpeg could use a desktop duplication capture source
[18:53:33 CEST] <BtbN> but it's a mess
[18:56:09 CEST] <BtbN> like, it doesn't just give you frames. It gives you dirty rects and move regions. You then have to contstruct the actual image from that
[19:10:11 CEST] <hiihiii> sounds like an overkill
[19:10:31 CEST] <hiihiii> shoot link
[20:11:43 CEST] <dreamon_> hello. want to deinterlace a video without losing quality. how can I do?
[20:13:45 CEST] <dreamon_> ffmpeg -i input.mp4 -deinterlace out.mp4 ’ but it loosing much quality
[20:17:59 CEST] <pzich> try adjusting the CRF: https://trac.ffmpeg.org/wiki/Encode/H.264
[20:18:11 CEST] <pzich> -crf 0 is lossless, but will result in a massive file
[20:20:24 CEST] <dreamon_> pzich, Unrecognized option 'crf'. maybe Im using a old ffmpeg version?
[20:21:38 CEST] <dreamon_> ffmpeg version N-83775-gdbc932e
[20:25:06 CEST] <dreamon_> fflogger, https://pastebin.ubuntu.com/p/WTtKmr4z7r/
[20:25:59 CEST] <durandal_1707> do not use -deinterlace
[20:26:10 CEST] <pzich> that says your build is from 2016 :o you should probably update
[20:26:45 CEST] <dreamon_> durandal_1707, but I want to deinterlace its a old interlaced video..
[20:27:31 CEST] <dreamon_> pzich, where do I found a newer version for 18.04 Ubuntu..
[20:27:33 CEST] <kepstin> deinterlacing is a tricky problem, you'll want to try specific deinterlacing filters to find something that works well for your content.
[20:28:10 CEST] <dreamon_> kepstin, I used -deinterlace and it look good but quality was poor
[20:29:21 CEST] <kepstin> that could be either because the -deinterlace option picked a bad deinterlacer, or encoding quality issues. But yeah, get a newer ffmpeg first.
[21:05:29 CEST] <Adcock> VP9 VS H264 bitrate comparsion.
[21:06:44 CEST] <Adcock> H264 bitrate 1424K
[21:07:21 CEST] <Adcock> What bitrate should I use for vp9 to get similar quality?
[21:16:01 CEST] <Hello71> tias
[21:20:22 CEST] <Adcock> Hello71: Me?
[21:20:30 CEST] <Hello71> yes
[21:20:51 CEST] <Adcock> Explain please.
[21:21:51 CEST] <Adcock> What about size?
[21:25:58 CEST] <Hello71> try it and see
[21:26:16 CEST] <Adcock> I did.
[21:26:49 CEST] <Adcock> I just can't find the right options.
[21:27:12 CEST] <Adcock> I need some general information if you have time.
[21:27:16 CEST] <Adcock> :)
[21:27:49 CEST] <Adcock> Are vp9 videos of the same quality smaller in size than vp9?
[21:28:10 CEST] <Adcock> I know ffmpeg devs aren't responsible for it.
[21:28:19 CEST] <Adcock> But whom to ask?
[21:28:55 CEST] <Adcock> Are vp9 videos of the same quality smaller in size than H264?
[21:29:58 CEST] <JEEB> it's not as simple as that
[21:30:17 CEST] <JEEB> like, VP9 as a format may be better on the paper
[21:30:31 CEST] <JEEB> but when you're testing youj have encoder A and encoder B
[21:31:10 CEST] <JEEB> if you are interested in testing video encoders I can link you some general old articles
[21:31:29 CEST] <Adcock> Please :)
[21:32:49 CEST] <JEEB> https://web.archive.org/web/20140822041755/http://x264dev.multimedia.cx/archives/472
[21:33:44 CEST] <JEEB> possibly useful write-up as well https://web.archive.org/web/20140427064753/http://x264dev.multimedia.cx:80/archives/102
[21:40:42 CEST] <JEEB> Adcock: anyways generally speaking when I test things I attempt to max out parameters (things get slow, which is generally my use case), and then encode with the slower thing with a quantizer level that does still have some issues visible
[21:40:52 CEST] <JEEB> then I go to the faster one, and match size :P
[21:41:11 CEST] <JEEB> (and of course you have to match all the little details like GOP length etc)
[21:42:30 CEST] <Adcock> What is Keyframe interval?
[21:42:38 CEST] <Adcock> IS it fps?
[21:42:48 CEST] <JEEB> no
[21:43:08 CEST] <JEEB> also known as GOP length, which is the interval between two Random Access Points
[21:43:23 CEST] <JEEB> aka where the decoding can be started without being afraid that you'd have some references before it
[21:43:53 CEST] <JEEB> usually even if you have a "keyframe" (one that can be decoded by itself), you might still have leftover references
[21:44:04 CEST] <JEEB> so when you get to the following frame, it might not be decode'able
[21:44:33 CEST] <JEEB> a Random Access Point is defined so that if you start decoding there, you can (in presentation order) show all following frames after that
[21:46:09 CEST] <Adcock> What is PSNR?
[21:47:06 CEST] <JEEB> wikipedia will probably tell you that it's a signal thing that lets you know how much the signal has been kept the same
[21:47:14 CEST] <JEEB> (it also in video *loves* blurring)
[21:47:31 CEST] <Adcock> :D
[21:47:48 CEST] <Adcock> That's a common problem while encoding.
[21:48:00 CEST] <JEEB> yes, many encoders actually are optimized for PSNR
[21:48:00 CEST] <Adcock> At least Ihave experienced it.
[21:48:08 CEST] <JEEB> which is pretty bad for human eyes :P
[21:48:27 CEST] <JEEB> or well, I dunno. If you don't know the original maybe it's not that bad
[21:48:39 CEST] <JEEB> x264 for example attempts to create something that tries to look like the detail
[21:48:45 CEST] <JEEB> which is worse for PSNR
[21:48:51 CEST] <JEEB> but tends to look better for humans
[21:51:46 CEST] <kupi> hi
[21:51:56 CEST] <kupi> is there any way to loselessly compress videos?
[21:52:00 CEST] <JEEB> yes
[21:52:05 CEST] <Adcock> if you don't mind may I ask how powerful computer do you use?
[21:52:07 CEST] <JEEB> but if your input is not lossless
[21:52:20 CEST] <JEEB> then the compressed result will probably be bigger than your source :P
[21:52:38 CEST] <Hello71> hm... what about mjpeg?
[21:52:39 CEST] <Adcock> o_o
[21:53:01 CEST] <JEEB> Hello71: I'm not sure JPEG does lossless?
[21:53:07 CEST] <Hello71> that's my point
[21:53:21 CEST] <Hello71> mjpeg is a very inefficient codec
[21:53:24 CEST] <JEEB> Adcock: nothing special - I've had this 4790K for quite a while
[21:53:51 CEST] <JEEB> Hello71: if we go by something like prores that's lossy and like MJPEG, that generally tends to be smaller than lossless things
[21:54:11 CEST] <JEEB> so I'd expect MJPEG still be smaller than comparable lossless
[21:54:20 CEST] <Adcock> I asked because you said speed is slow.
[21:54:21 CEST] <Adcock> For me it is super slow.
[21:54:21 CEST] <Hello71> huh.
[21:54:47 CEST] <JEEB> Adcock: well my test cases are "max out the encoders, match certain parameters so it's fair, let them run"
[21:54:53 CEST] <Hello71> Adcock: video encoding is slow
[21:54:55 CEST] <JEEB> and that's why I match against the slowest encoder
[21:55:01 CEST] <JEEB> so that I don't have to re-encode :P
[21:55:35 CEST] <Adcock> :)
[22:05:59 CEST] <kupi> Adcock: 7440HQ
[22:06:59 CEST] <Adcock> ?
[22:07:11 CEST] <Adcock> oH
[22:07:11 CEST] <Adcock> :)
[22:10:34 CEST] <kupi> JEEB: how can I tell if a video can be compressed lossless?
[22:10:51 CEST] <JEEB> all video can be compressed with lossless compression (in theory)
[22:11:06 CEST] <JEEB> unless you have some very specific definition of lossless compression in mind :P
[22:11:16 CEST] <JEEB> (such as re-compression without full re-encoding)
[22:11:58 CEST] <kupi> my definition is decreasing file size without sacrificing quality :D
[22:12:09 CEST] <Adcock> :D
[22:12:15 CEST] <Adcock> Me too.
[22:12:36 CEST] <Hello71> impossible
[22:12:37 CEST] <Hello71> next question
[22:12:48 CEST] <Adcock> Why?
[22:13:14 CEST] <Adcock> Okay. No.
[22:13:17 CEST] <Adcock> Skip.
[22:13:37 CEST] <JEEB> in theory if your video was H.264 and it was CAVLC you could redo that with CABAC (which compresses better)
[22:13:41 CEST] <JEEB> but guess if there are tools for that
[22:15:21 CEST] <kupi> the video is WMV3
[22:15:38 CEST] <kupi> and I believe there are more efficient formats such as h265
[22:19:53 CEST] <JEEB> then no, there is no magical *lossless* pathway anywhere
[22:22:02 CEST] <kupi> JEEB: what about AVC?
[23:17:03 CEST] <^Neo> hello friends, I'm curious if anyone has any experience driving FFmpeg with pipes with python?
[23:44:36 CEST] <victorqueiroz>  Interesting, now on decoding I'm getting: pps_id 3199971767 out of range
[23:51:15 CEST] <Zexaron> Hello
[23:51:54 CEST] <Zexaron> I'm trying to compare ffprobe output from different formats/codecs, but I'm not sure if it really outputs from start to finish in order show_packets
[23:51:58 CEST] <Zexaron> what does POS mean?
[23:52:09 CEST] <Zexaron> position in filesize bytes ?
[23:52:35 CEST] <Zexaron> because it's so different it's not really comparable from packet ID to packet ID
[23:52:52 CEST] <Zexaron> 1 vs 1, 2 vs 2
[23:53:21 CEST] <ChocolateArmpits> Zexaron, maybe the packets are listed in the decoding order?
[23:53:37 CEST] <ChocolateArmpits> there's also show_frames
[23:53:56 CEST] <kepstin> Zexaron: not sure where you're getting 'POS' from, but pkt_pos is position of the packet within the file in bytes, yeah.
[23:54:45 CEST] <kepstin> (the -show_frames output is what i'm looking at)
[23:55:24 CEST] <kepstin> looks like the 'pos' value in -show_packets matches the 'pkt_pos' value in -show_frames, which makes sense :)
[23:58:35 CEST] <Zexaron> both AVI/MPEG4 and MKV/H264 have this from the frame dumped videos produced by this https://github.com/dolphin-emu/dolphin/blob/944b5fade625823814c04b4acbf835c89fbd191d/Source/Core/VideoCommon/AVIDump.cpp
[23:58:51 CEST] <Zexaron> oh okay
[23:59:12 CEST] <Zexaron> trying to understand it and how to improve it, apparently it uses some kind of emulated frame wall time to compensate when the PC isn't fast enough to keep stable FPS the game is designed to run at, tese games have gamespeed bound to FPS also, I was thinking if it was possible to try other methods, like just trying to make a CRF slideshow with fixed framerate, make FFmpeg simply wait as frames get delivered pack them in fixed 60 or 30
[23:59:12 CEST] <Zexaron> or whatever FPS
[23:59:44 CEST] <kepstin> i hope the name of that function is wrong, and you're not actually using AVI to store h264 video :)
[00:00:00 CEST] --- Wed Oct 17 2018