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

[burek]

[00:18:23 CET] <atoms118> sorry, had to get some dinner
[00:19:45 CET] <atoms118> I'm already using zerolatency and fastdecode
[00:20:48 CET] <atoms118> wait I had a syntax issue
[00:28:15 CET] <atoms118> ok so it seems ffplay is to blame; "mplayer -benchmark udp://127.0.0.1:1234" is significantly better, with a latency of ~300-400ms, which is still not ideal but much better
[00:28:39 CET] <atoms118> however, mplayer takes significantly longer to start up for whatever reason
[00:31:25 CET] <atoms118> is there a way to make ffmpeg receive the stream faster?
[00:32:10 CET] <atoms118> 400ms is a lot considering it's running over loopback and not even using very much CPU
[01:27:19 CET] <BtbN> you'll need to write both player and sender yourself. Generic code is pretty much always optimized for reliability, not zero latency.
[05:12:53 CET] <kepstin> and ffplay is designed to be a basic working example player, not to be actually useful for playing.
[13:34:00 CET] <skident> Hi there!
[13:34:44 CET] <skident> Who knows, how to measure latency of ffmpeg audio filters? Are there any special functions in avfilter library?
[15:49:46 CET] <dv_> does anybody know about the sequence layer header in wmv3 RCV headr?
[15:50:17 CET] <dv_> in the VC-1 spec (SMPTE 421M), there is the annex.L
[15:51:46 CET] <dv_> section L.2 defines the sequence layer, and it mentions a constant byte 0xC5. I am trying to find out what this 0xC5 means. I found in NXP code something about a "codec version" and a "header extension bit". if you combine these two constants in the nxp code, you get 0x85... but I can't find any more info. so, 0xC5 remains a mysterious magical value with no defined meaning except that is has to be there.
[17:20:27 CET] <kepstin> dv_: lots of formats have "magic" values that are simply present for format detection or resyncing
[17:21:09 CET] <dv_> kepstin: it does not seem to be a "magic" value though
[17:21:11 CET] <dv_> https://github.com/genesi/gst-fsl-plugins/blob/master/src/video/vpu_dec.full/src/mfw_gst_vpu_decoder.c#L517
[17:21:37 CET] <dv_> but I cannot find any spec that mentions a "header extension bit" or a "codec version"
[18:54:14 CET] <dv_> okay, bit #6 seems to specify whether or not RCV V1 or V2 is used.
[18:54:32 CET] <dv_> does anybody know anything about that RCV format that is used for WMV3? I cannot find any spec for it
[19:24:46 CET] <JEEB> dv_: I'm not sure who would be the expert on WMVx
[19:24:59 CET] <JEEB> probably someone who had been reverse engineering those formats in the past
[19:25:14 CET] <JEEB> you'd probably get something out of looking at the history of the wmv3 decoder
[19:25:21 CET] <JEEB> but yes, wmv3 had no spec
[19:25:25 CET] <JEEB> and the VC-1 one is limited
[19:26:25 CET] <JEEB> https://wiki.multimedia.cx/index.php/VC-1
[19:26:44 CET] <JEEB> wmv3 seems to redirect to that
[19:31:19 CET] <dv_> wmv3 is pretty much the same as vc-1 main profile
[19:31:24 CET] <dv_> so that doesn't surprise me
[19:31:38 CET] <dv_> what does surprise me though is that information about RCV is virtually nonexistent
[19:32:02 CET] <dv_> the most I found out was from http://www.dre.vanderbilt.edu/~schmidt/android/android-4.0/hardware/qcom/media/mm-video/vidc/vdec/test/omx_vdec_test.cpp
[19:32:10 CET] <JEEB> well people were making decoders by reverse engineering the parts that actual available samples were utilizing
[19:32:17 CET] <JEEB> at least in open source
[19:32:21 CET] <dv_> yea
[19:32:30 CET] <JEEB> so if your sample did not utilize any other values you really didn't care about the field
[19:33:09 CET] <dv_> oh well, it seems to work well with this info, so I am going to stick to the 0x85 and 0xC5 constants (0x85 for RCV1, 0xC5 for RCV2)
[19:39:31 CET] <iive> wmv3 has some "legacy" encoding modes that are not supported by vc1,
[22:32:59 CET] <DHE> I'm encoding x264 using the avcodec API. I received a packet with AV_PACKET_FLAG_KEY true, but pts != dts. That's impossible, right?
[22:33:10 CET] <DHE> *AV_PKT_FLAG_KEY
[22:35:54 CET] <DHE> I should mention I forced the frame to be a keyframe with frame->pict_type=AV_PICTURE_TYPE_I;
[22:37:50 CET] <kepstin> if you want it to start a new gop (emit an IDR frame when you ask for an I frame), you need to set the forced-idr avoption.
[23:43:00 CET] <DHE> kepstin: yes I did do that
[23:43:50 CET] <DHE> I do get the expected keyframe, but this keyframe has dts != pts which I thought was a spec violation or otherwise not valid
[00:00:00 CET] --- Tue Dec  4 2018