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

[burek]

[11:47:20 CEST] <heftig> is it legal to resume feeding a decoder after flushing it?
[11:48:06 CEST] <JEEB> https://www.ffmpeg.org/doxygen/trunk/group__lavc__encdec.html
[11:48:09 CEST] <JEEB> goes through that I think
[11:48:26 CEST] <JEEB> yes, it does
[12:16:58 CEST] <Guest17399> Hi there, how are you? Hey I was trying to read the ffmpeg output and then I saw this pattern: "encoder: Lavc57.89.100 <videoenc>"
[12:17:10 CEST] <Guest17399> I would like to know what is Lavc57.89.100
[12:17:28 CEST] <Guest17399> what this does reference? (lib av? v 57 ?)
[12:17:42 CEST] <_julian> is it allowed to change AVCodecParameters of an AVStream at runtime?
[12:17:45 CEST] <Guest17399> because I saw this for both audio and video.
[12:17:47 CEST] <BtbN> The libavcodec version.
[12:17:57 CEST] <Guest17399> encoder         : Lavc57.89.100 libx264
[12:18:03 CEST] <_julian> inside a libavdevice input module
[12:18:04 CEST] <Guest17399> encoder         : Lavc57.89.100 libfdk_aac
[12:18:31 CEST] <Guest17399> thanks BtbN and _julian
[12:20:22 CEST] <Guest17399> BtbN: is it an internal version? because when I look at the official docs it seems that libavcoded is on 3.2 https://www.ffmpeg.org/doxygen/3.2/index.html
[12:20:44 CEST] <BtbN> It's the libavcodec version, not the ffmpeg project version.
[12:21:21 CEST] <BtbN> And the latest ffmpeg version is 3.4.
[12:22:43 CEST] <Guest17399> BtbN: thanks, I took that (now I know it's wrong) conclusion by just looking at the official docs.
[12:26:21 CEST] <memeka> hi; how are decoded frames sent to the video drivers? profiling gstreamer and mpv+ffmpeg, I get very different results: on my arm board with no dmabuf-import gpu support, gstreamer spends most of the time doing memcpy, and less in the gpu driver, but mpv+ffmpeg spends most of its time in the driver: 72% libmali.so               cobjp_neon_linear_to_block_8b_8x8, 16% libmali.so
[12:26:21 CEST] <memeka> cobjp_neon_linear_to_block_16b_8x8, 7% memcpy
[12:26:43 CEST] <Guest17399> I saw where it's defined thanks a lot BtbN https://ffmpeg.org/doxygen/trunk/libavcodec_2version_8h.html#ab85a906b062b0a195ad772d45727bccf
[14:57:31 CEST] <armegeden> hello:  I'm trying to figure out the syntax to take any media file, strip all metadata, then insert a custom Title and Comment metadata.  i have this so far:  ffmpeg -i "input.mp4" -c copy -map 0 -map_metadata -1 -metadata title="TITLE" -metadata comment="TEST" "output.mp4"    --- but it doesn't appear to be taking the arguments.  Am i missing some
[14:57:31 CEST] <armegeden> thing?
[15:17:30 CEST] <memeka> hi; how are decoded frames sent to the video drivers? profiling gstreamer and mpv+ffmpeg, I get very different results: on my arm board with no dmabuf-import gpu support, gstreamer spends most of the time doing memcpy, and less in the gpu driver, but mpv+ffmpeg spends most of its time in the driver: 72% libmali.so               cobjp_neon_linear_to_block_8b_8x8, 16% libmali.so
[15:17:30 CEST] <memeka> cobjp_neon_linear_to_block_16b_8x8, 7% memcpy
[15:19:54 CEST] <jkqxz> mpv uses GL to do rendering for display (colour conversion and overlays).  No idea what gstreamer does, but presumably not that.
[15:48:06 CEST] <IamTrying> http://paste.ubuntu.com/25809471/ - Why not converting?
[15:50:23 CEST] <c_14> need a -i before the input file
[15:50:33 CEST] <c_14> and you probably want -c copy if it'll work
[15:50:37 CEST] <c_14> If you just want to remux the files
[15:50:41 CEST] <c_14> so you don't reencode everything
[15:59:41 CEST] <IamTrying> Oh boy. thank you c_14, very difficult to remember all those.
[17:21:57 CEST] <_julian> can h264_vaapi be configured to cbr mode?
[17:26:55 CEST] <jkqxz> Set rc_max_rate (-maxrate) equal to bit_rate (-b).
[17:27:18 CEST] <_julian> jkqxz: thanks :)
[17:27:22 CEST] <jkqxz> (You also get it automatically on old driver versions with no VBR support.)
[17:27:28 CEST] <_julian> ok
[18:18:25 CEST] <N0rdell> Why the change in 3.1 from the decode_video/audio api to send/receive packet/frame api?
[19:09:35 CEST] <pgorley> N0rdell: it decouples input and output, other than that, i wouldn't know
[19:10:28 CEST] <JEEB> N0rdell: lets format do separation of the two things better (not every feed call gets a decoded frame, and you don't need to feed another packet to get stuff out of the decoder
[19:10:34 CEST] <JEEB> basically as a design I prefer it
[19:10:56 CEST] <DHE> there were some other changes, such as the old API occasionally not consuming all input...
[19:11:30 CEST] <JEEB> N0rdell: https://www.ffmpeg.org/doxygen/trunk/group__lavc__encdec.html
[19:11:44 CEST] <JEEB> this document explains how this stuff works and replaces some legacy functions
[19:11:47 CEST] <JEEB> also one thing I forgot
[19:11:53 CEST] <JEEB> it normalizes behavior between video and audio
[19:12:05 CEST] <JEEB> they both now have the same functions
[19:15:43 CEST] <N0rdell> I see more clarity in what is considered a frame and what is considered a packet
[19:17:38 CEST] <N0rdell> I was seeing some behaviour - the send api was causing the receive api to buffer a lot of frames.  receive packet never returned any encoded frames until I entered flush mode - and then I received all the frames
[19:17:54 CEST] <N0rdell> I wonder if there is way to configure how many frames are buffered by the format
[19:19:16 CEST] <JEEB> the decoder shouldn't buffer more than it needs
[19:23:26 CEST] <N0rdell> Thank you JEEB
[19:24:10 CEST] <JEEB> so it's either a bug or something else. I would always recommend trying the latest master's HEAD if FATE looks green
[19:24:19 CEST] <JEEB> FATE being http://fate.ffmpeg.org/
[19:24:25 CEST] <JEEB> which is the automated testing suite
[19:24:41 CEST] <N0rdell> Another problem I am running into; I had some of my own code that did what avcodec_parameters_to_context is doing.  So I pulled it out because the deprecated codec object.  But the problem I am seeing now is I cant configure details such as reference frames
[19:25:10 CEST] <N0rdell> I would love to hand off an SPS and get back a fully configured context
[19:25:23 CEST] <N0rdell> Now it looks like I am going to have to rewrite that code
[19:26:40 CEST] <JEEB> yea, for AVC/HEVC you shouldn't have to set any values before hand (although you can indeed move info from a demuxer to a decoder via that helper from codecpar thing
[19:26:53 CEST] <JEEB> if you feed it parameter sets and then video it should JustWork (TM)
[19:27:05 CEST] <JEEB> (in AVPackets of course)
[19:27:15 CEST] <JEEB> and then you get an AVFrame which then contains the state of the decoded video at that point
[20:18:32 CEST] <N0rdell> JEEB: sorry - I missed there.  Where is the api where you can feed a parameter set and get an encode context?  I have always done it by hand...
[20:20:00 CEST] <JEEB> N0rdell: if you really want to do the parsing yourself you can make AVPackets out of NAL units and push them to the decoder
[20:20:16 CEST] <JEEB> there is also an AVC and HEVC parser
[20:20:30 CEST] <N0rdell> Ill need to get an encode context from those packets tho
[20:20:37 CEST] <N0rdell> not a decode context
[20:20:47 CEST] <JEEB> packets are already coded data
[20:21:10 CEST] <JEEB> avpacket -> decoder -> avframe -> encoder -> avpacket
[20:21:37 CEST] <JEEB> coded data -> decoder -> raw data -> encoder -> coded data
[20:21:39 CEST] <N0rdell> So you are saying... feed an encoded frame to the encoder and the encoder will automagically configure itself
[20:21:52 CEST] <JEEB> you were talking of SPS/PPS
[20:21:57 CEST] <JEEB> which is decoding
[20:22:12 CEST] <JEEB> so something is definitely lost in translation :P
[20:22:47 CEST] <N0rdell> Yeah I have a video I want to decode... make some changes and reencode using the same SPS/PPS
[20:25:38 CEST] <N0rdell> In other words... lets say the input video used 3 reference frames and 1 bframe.  It should be relatively straight forward to pass the encoder the SPS as all that information is encoded in the SPS.  But its not that simple.  avcodec_parameters_to_context must be used between the decode and encode context and its still not complete
[20:26:08 CEST] <N0rdell> So avcodec_parameters_to_context is a step in the right direction but is incomplete
[20:26:41 CEST] <JEEB> well it's not meant for that kind of stuff I think. it's usually used to initialize the decoder from the demuxer's decoder instance I think
[20:26:45 CEST] <N0rdell> it would be cool to have avcodec_sps_pps_to_context
[20:26:49 CEST] <JEEB> although I'm not 100% sure :P
[20:27:32 CEST] <JEEB> anyways, I wish I remembered the code I wrote some time ago encoding things so I'd remember the current correct flow
[20:27:36 CEST] <JEEB> I mostly do internal development
[20:28:08 CEST] <N0rdell> Just work on ffmpeg?
[20:28:58 CEST] <JEEB> the libraries
[20:29:13 CEST] <JEEB> I do code API clients as well but it's been a few months since I've written my last full encoder :P
[20:30:11 CEST] <pgorley> can AVCodecContext->get_format be called twice in a row with different pixel formats?
[20:31:43 CEST] <N0rdell> JEEB thanks for the help
[20:31:43 CEST] <JEEB> N0rdell: I think we nowadays have parameter set parsing functionality in the libraries (unless that thing didn't get merged yet), but I am not sure how much that is usable externally
[20:32:16 CEST] <JEEB> and yes, with encoding you set AVOptions and touch the AVCodecContext
[20:33:25 CEST] <pgorley> for decoding, i mean
[20:41:25 CEST] <evelynzx> http://bit.ly/realgirlz  -  Meet REAL cosplay girls, women, couples, gay, bi and more for Free! check it out
[21:36:29 CEST] <JASTON> Hey gang, having issues with the HLS muxer, looking for some guidance.  I'm trying to extract audio tracks from a file, with segment time set at 10.  The resulting audio segments seem to honor -hls_time, but the resulting m3u8 is all over the place with durations:  https://pastebin.com/qjPutLtk
[22:51:10 CEST] <jbreeden> Working on developing an SVC decoder module. Unsure of the correct way to deal with frame size changes. When a different-sized frame is decoded, I update the avctx height & width, and reinitialize AVFrame, but I get the following error: https://pastebin.com/VahNYAcp . Is there something else I must do to handle size change?
[22:53:19 CEST] <JEEB> that sounds like an avfilter issue. I know that the AVC, HEVC and mpeg-2 decoders should support resolution changes
[22:53:33 CEST] <JEEB> not sure if exactly what you're doing is correct, but yunno
[22:53:48 CEST] <JEEB> jbreeden: also if you're doing SVC for libavcodec I recommend you pop over to the -devel channel
[22:53:56 CEST] <JEEB> that's the FFmpeg internals development stuff
[22:55:57 CEST] <jbreeden> JEEB: Okay, thanks, I'll post it over there. I've been searching through h264 and hevc modules trying to understand what they're doing, I'm still in a little over my head.
[22:56:10 CEST] <JEEB> :)
[00:00:00 CEST] --- Wed Oct 25 2017