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

[burek]

[00:19:03 CEST] <DHE> I'm looking for something that is suitable for a daemonized version of ffmpeg. In particular if something goes wrong, it should restart. (This if for a streaming task). There's an option -max_error_rate which looks like a step in the right direction but doesn't appear to actually do anything beyond exit code
[00:19:25 CEST] <DHE> I can script something up, it's a matter of error detection really
[01:45:22 CEST] <Seablade_pixel> Quick question, it appears ffmpeg typically creates some sort of average for the console output (IE. fps seems to be an average of the last X seconds) am I correct in this first?  If not how is it calculated?  If so, is there a way I could get it to show me more instantaneous results?
[01:46:27 CEST] <Seablade_pixel> Primarily I am trying to come up with a good way to monitor network issues when using ffmpeg to generate an output stream, and it doesn't seem like it responds quite as fast as I would like and more realtime output could help with this if what I am seeing is correct
[02:15:45 CEST] <c_14> If you're streaming at constant bitrate, you could just check the network output, otherwise you could try the -progress option
[02:27:44 CEST] <Seablade_pixel> c_14: Thanks, I will look into -progress.  Not a constant bitrate in this case.
[02:28:50 CEST] <Seablade_pixel> c_14: Pretty much I am capturing from a blackmagic design card and streaming out, I have my suspicions that around 8PM my time when everyone around me gets onto the network, I am seeing drops in network performance, which is causing ffmpeg to back up on encoding frames and fill the buffer of bmdcapture causing it to fail, but that is all conjecture at this point
[04:05:08 CEST] <ig0r_> is there a simple way to convert an MKV-file to an MP4-file without re-encoding it?
[04:36:58 CEST] <Seablade_pixel> ig0r_: ffmpeg -i INPUT.mkv -c copy OUTPUT.mp4
[04:37:38 CEST] <Seablade_pixel> Might have to do `-c:v copy -c:a copy` instead of just -c copy, can't remember off hand.  And if you only want certain streams you will need to use -map to say what streams you want
[05:11:41 CEST] <oscargot> Hello, I'
[05:11:51 CEST] <oscargot> oops..
[05:13:51 CEST] <oscargot> Hello, is there anyway to directly encode a NV12 pix format image to MPEG4 using libav rather than having to first convert it to YUV420P sws_scale?
[06:17:26 CEST] <karkhaz> Hi, I'm trying to trace a segfault in libffmpeg. It happens in a function called ff_pack_2ch_float_to_int16_a_sse2
[06:17:40 CEST] <karkhaz> Where is this function defined? I can't find it anywhere
[06:18:12 CEST] <oscargot> Hello, is there anyway to directly encode a NV12 pix format image to MPEG4 using libav rather than having to first convert it to YUV420P sws_scale? Or optimise the conversion step?
[06:18:19 CEST] <karkhaz> That function gets called from swri_audio_convert in libswresample/audioconvert.c
[06:19:31 CEST] <karkhaz> gdb won't tell me where it is. It get assigned in libswresample/x86/audio_convert_init.c, but otherwise I can't tell where the function is actually implemented.
[06:21:28 CEST] <karkhaz> from swri_audio_convert there is a call to ctx->simd_f(...), so simd_f is a pointer to the function ff_pack_2ch_float_to_int16_a_sse2. But I can't see where that function is implemented
[06:38:21 CEST] <EO_> is -strftime unsupported?
[06:38:41 CEST] <EO_> [mp4 @ 0x26b5be0] Invalid segment filename template 'seg-%Y-%m-%d_%H-%M-%S.mp4'
[06:39:08 CEST] <EO_> ^^^ I specified "-strftime 1" in the output params.  It works when I just use %d there instead of actual strftime format string entities.
[06:40:06 CEST] <EO_> https://www.ffmpeg.org/ffmpeg-all.html#segment_002c-stream_005fsegment_002c-ssegment <-- Manual claims support for -strftime
[06:47:53 CEST] <EO_> it seems from the error message like use_strftime was not set
[06:55:04 CEST] <EO_> heh, works with latest git build.  I guess the ffmpeg static build is out of date.
[07:27:40 CEST] <Stifler> Hi! Is there a way to make/force ffmpeg attempt to take thumbnails on a known 'corrupt' piece of video?
[08:05:54 CEST] <durandal_1707> karkhaz: in x86 subdirectory
[08:14:23 CEST] <oscargot> Hello, is there anyway to directly encode a NV12 pix format image to MPEG4 using libav rather than having to first convert it to YUV420P sws_scale? Or optimise the conversion step?
[08:20:28 CEST] <durandal_1707> oscargot: conversion is slow for you?
[09:53:47 CEST] <Lushi> hi
[09:54:56 CEST] <Lushi> I am looking for some help using ffmpeg to create a multi-variant HLS stream.
[09:55:20 CEST] <Lushi> I am having trouble getting the segments to line up.
[09:55:35 CEST] <Lushi> Is there anyone here that has experience with this?
[12:09:39 CEST] <DHE> I'd have answered Lushi but he's gone
[13:41:36 CEST] <Lushi> I am looking for some help encodign an HLS file with different bitrates and framerates.
[13:41:52 CEST] <Lushi> Does anyone here have experience doing this?
[13:42:20 CEST] <Lushi> Also, when is generally a good time to ask questions on this IRC channel?
[13:43:28 CEST] <Lushi> I posted a detailed description of the problem to ffmpeg-user list: http://ffmpeg-users.933282.n4.nabble.com/HLS-segment-duration-for-multiple-framerate-encoding-td4671498.html
[13:43:49 CEST] <Lushi> Does anyone have any ideas or pointers?
[14:08:03 CEST] <DHE> Lushi: I'm doing that right now actually
[14:09:04 CEST] <DHE> not with multiple framerates, but if you explicitly set your framerate it should be okay. keep in mind that a lot of TV runs at 29.97 fps  (or more specifically, 30/1.001 fps)
[14:18:57 CEST] <ILEoo> apples mediastreamvalidator errors out on different segment lengths?
[14:24:55 CEST] <JEEB> I don't see https://developer.apple.com/library/ios/technotes/tn2235/_index.html showing such warning/error at least
[14:30:31 CEST] <Lushi> DHE, thanks for writing back.
[14:31:20 CEST] <Lushi> my understanding of HLS with multiple variants is that the segments must have teh same duration
[14:31:41 CEST] <DHE> yes, and each should represent an identical segment in time
[14:31:49 CEST] <Lushi> correct.
[14:32:38 CEST] <Lushi> in addition to that, they should also all have the same EXT-TARGETDURATION
[14:33:16 CEST] <Lushi> so, as you can se in my email, when I am running the ffmpeg segmentor on teh same input stream, I often end up with differnt length segments, and even different EXT-TARGETDURATION.
[14:33:48 CEST] <Lushi> can the player jump around between streams when they have different length segments? my assumption is no..
[14:35:08 CEST] <JEEB> currently there are things that do not strictly set IDR frames at exact specific points and it seems to work
[14:35:17 CEST] <JEEB> I guess http://tools.ietf.org/html/draft-pantos-http-live-streaming-16 is the authority on these things
[14:38:12 CEST] <DHE> ffmpeg seems to do the right thing for a single segment, but in the end each .m3u8 is its own private thing and there's no coordination between them. I'm using "-x264opts no-scenecut:keyint=60" to force regular keyframes. if all videos have constant framerates then it all works out.
[14:42:08 CEST] <JEEB> all of my TARGETDURATIONs seem to be matching, but naturally the extinf duration can be variable. the TARGETDURATION is just the maximum length of a segment
[14:42:19 CEST] <JEEB> which seems to match the spec
[14:43:55 CEST] <ILEoo> Lushi: player should check segment for timestamp in the beginning to sync playback positions when switching playlists
[15:43:36 CEST] <noncom> hi!
[15:48:36 CEST] <Lushi> sorry - was pulled a way for a bit.
[15:49:15 CEST] <Lushi> one problem is when you have different TARGETDURATIONs - then the apple tester complains
[15:52:14 CEST] <Lushi> another problem is that ffmpeg doesn't even listen to teh recommended lengths - in all my examples I asked for 9 seconds segments - and I got some segments that were up to 12 seconds
[15:53:25 CEST] <Lushi> it seems that -force_key_frames fave more accurate splits than -g
[15:55:00 CEST] <JEEB> -g just sets the maximum length of a GOP
[15:56:33 CEST] <JEEB> I use VLC for the HLS muxing, and it seems to set TARGETDURATION to what I set on the command line. And as long as I have max GOP length in a similar figure (a bit lower just in case), the thing seems to work fine
[15:57:39 CEST] <Lushi> when you say muxing, what do you mean? segmenting the file into chunks? or creating a master playlist for multiple streams?
[15:58:21 CEST] <JEEB> creating the segments
[15:58:59 CEST] <JEEB> but to be honest I'd be surprised if ffmpeg's muxer doesn't follow what you set as long as the GOPs are within that range
[15:59:00 CEST] <Lushi> as I showed in my email, I was using ffmpeg to segment the files and create teh single stream m3u8 file - and was getting differnt segment lengths and even different target durations for different bitrates/framerate/resolutions...
[15:59:03 CEST] <JEEB> so that could be looked into it
[15:59:15 CEST] <JEEB> segment lengths being different is OK
[15:59:24 CEST] <JEEB> TARGETDURATION not being what you set is getting herp derp
[15:59:53 CEST] <JEEB> unless you have VFR and cannot signal that to libx264 so it keeps using the original GOP lengths picture-wise
[15:59:55 CEST] <Lushi> why is it ok for segment lengths to be different? how will the player switch between streams when teh segment lengths differ?
[16:00:14 CEST] <JEEB> by parsing the lengths of the segments and then seeking within the segment?
[16:00:18 CEST] <JEEB> as far as I can see that works fine
[16:00:52 CEST] <JEEB> TARGETDURATION being different might cause complaints, that I don't disagree about. I just can't test the app because I don't have my apple credentials around
[16:00:56 CEST] <Lushi> ex: if one stream segment goes from second 0-9 and the other stream goes from second 0-10, then the client can't switch tto teh second stream at the end of the first...
[16:01:03 CEST] <Lushi> or do I not understand that correctly?
[16:01:21 CEST] <JEEB> why can't it? it should have the playlist loaded for both, no?
[16:01:39 CEST] <JEEB> the playlists contain the lengths of the segments
[16:02:04 CEST] <Lushi> at the end of the first segment (second 9), there is no start of the second stream segment until second 10.
[16:02:35 CEST] <Lushi> so it will load segment 2 of the first stream for 1 second and then switch to the second stream?
[16:03:04 CEST] <JEEB> if the player is switching from playlist A to playlists B on the meta playlists, it would check its current timestamp in playback, and load/seek the segment accordingly
[16:03:18 CEST] <JEEB> that's exactly why the lengths are there for the segments
[16:03:22 CEST] <Mavrik> Not all of them do that reliably though.
[16:03:33 CEST] <Mavrik> IIRC Apple can do that well, Android is buggy and STBs mostly crap out
[16:04:12 CEST] <JEEB> well as far as I could see the samsung TV I had access to did it well as well. But I do agree that different implementations and their versions can have bugs
[16:04:36 CEST] <Mavrik> At least we had huge issues and had to make sure all segments are of same length and have key frames at same interval
[16:05:39 CEST] <JEEB> well the experiences around me seem to be of more positive results, thankfully :)
[16:05:42 CEST] <Lushi> tI found where in teh apple sdocs it said that segments should be equal length
[16:05:43 CEST] <Lushi> https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/StreamingMediaGuide/HTTPStreamingArchitecture/HTTPStreamingArchitecture.html#//apple_ref/doc/uid/TP40008332-CH101-SW8
[16:06:06 CEST] <Lushi> "If you already have a media file encoded using supported codecs, you can use a file segmenter to encapsulate it in an MPEG-2 transport stream and break it into segments of equal length."
[16:06:52 CEST] <Lushi> this is why I was freaking out when ffmpeg segmentor was making different duration files...and then even more when it was making different TARGETDURATIONs
[16:07:07 CEST] <JEEB> and then it proceeds to to say that "For maximum accuracy, you should specify all durations as floating-point values when sending playlists to clients that support version 3 of the protocol or later. (Older clients support only integer values.) You must specify a protocol version when using floating-point lengths; if the version is omitted, the playlist must conform to version 1 of the protocol."
[16:07:13 CEST] <JEEB> also the thing is a standard now
[16:07:17 CEST] <JEEB> I recommend you just keep to the standard
[16:07:37 CEST] <JEEB> https://tools.ietf.org/html/draft-pantos-http-live-streaming-16
[16:07:40 CEST] <Lushi> you can have floating point values and have each one be the same length...
[16:08:03 CEST] <Lushi> Mavrik, we are discussing http://ffmpeg-users.933282.n4.nabble.com/HLS-segment-duration-for-multiple-framerate-encoding-td4671498.html
[16:08:27 CEST] <Lushi> if you have any input, I would be thrilled! - been working on this since last week :)
[16:08:32 CEST] <JEEB> take a look at the example in chapter 2 of the spec
[16:08:47 CEST] <Mavrik> Hmm, didn't have that use-case, since TV broadcasts are (and must be) CFR
[16:09:05 CEST] <Mavrik> Too much hardware out there that chokes if it isn't :)
[16:09:15 CEST] <DHE> I haven't tried this yet, but for content known to be 29.97fps I'd use something like "ffmpeg -i input [...] -r 30/1.001 -x264opts keyint=60 output-high.m3u8  [...] -r 15/1.001 -x264opts keyint=30 output-low.m3u8"
[16:09:17 CEST] <DHE> have you tried that?
[16:10:56 CEST] <Lushi> are you creating multiple segments with the same command line?
[16:11:48 CEST] <Lushi> if so, then that might allow ffmpeg to split them all together at the same places...which is what I want...
[16:12:15 CEST] <JEEB> it's separate encoders
[16:12:16 CEST] <JEEB> so no
[16:14:04 CEST] <Lushi> Mavrik: CFR - do you mean CRF (Constant Rate Factor) ?
[16:14:40 CEST] <JEEB> no
[16:14:43 CEST] <JEEB> constant frame rate
[16:14:57 CEST] <Lushi> ah
[16:15:26 CEST] <Lushi> JEEB, in the example in chapter 2 of the spec, the first 2 segments have the same duration - only the last one is shorter (which is understandable -since that is the "leftover content" att the end)
[16:15:50 CEST] <JEEB> it /could/ be
[16:15:57 CEST] <JEEB> anyways, I tried to search for specific limitations
[16:15:59 CEST] <JEEB> those were not found
[16:16:10 CEST] <JEEB> at least looking for the instances of "duration" or "segment duration"
[16:16:28 CEST] <raven737> Hi, i would like to get motion vectors of mpeg streams as quickly as possible (least recourse utilization). Would it be possible to only parse mpeg streams without decoding images to get that data? I don't want any image output , just mv info. Is that possible as it is now or with simple code modification?
[16:16:43 CEST] <JEEB> also the fact that iOS devices seem to handle that just fine seems to note that it is not against the standard to do that.
[16:18:11 CEST] <Lushi> ok - so you think it is not a problem to have different lengths between different resolutions...but the TARGETDURATION would still be a problem...and without strictly controlling the segemtn durations, you can't strictly control the TARGETDURATION///
[16:18:24 CEST] <Lushi> (as is seen in my first example)...
[16:18:54 CEST] <raven737> I saw: https://ffmpeg.org/pipermail/ffmpeg-devel/2014-August/161593.html ... Can I somehow get MV data into CSV files?
[16:19:23 CEST] <JEEB> well I just set the parameter that controls TARGETDURATION and my GOPs maximum lengths are just under that value
[16:19:31 CEST] <JEEB> unless I suddenly get VFR input it should be OK
[16:19:42 CEST] <Lushi> which parameter is that?
[16:20:03 CEST] <JEEB> with VLC it's seglen
[16:20:12 CEST] <JEEB> I haven't checked the ffmpeg HLS muxer yet
[16:20:14 CEST] <Lushi> I got duration 10 when I request "-hls_time 9"
[16:20:36 CEST] <Lushi> maybe I'll just try the VLC muxer if you have good luck with that.. is that CLI as well?
[16:21:35 CEST] <Lushi> and do you use vlc as the transcoder as well (can it even do that?)? or just to segment the resulting files?
[16:21:56 CEST] <DHE> Lushi: I'm using one process to do them all
[16:22:03 CEST] <DHE> but same framerates fore ach
[16:22:04 CEST] <DHE> each
[16:23:16 CEST] <JEEB> Lushi: it can re-encode as well but right now I'm not doing that
[16:23:21 CEST] <JEEB> I've done that for other stuff though
[16:23:27 CEST] <JEEB> and yes, it's cli
[16:23:31 CEST] <JEEB> see #videolan for help
[16:30:16 CEST] <Lushi> maybe I'll try that...it just seems strange that this isn't a "
[16:30:29 CEST] <Lushi> isn't a "solved problem" for ffmpeg...
[16:31:06 CEST] <JEEB> it should be as long as your GOPs are within that maximum length
[16:31:07 CEST] <Lushi> I can't be the only person to try to transcode files into multiple bitrate streams for apple devices..that is THE simplest use case of HLS...
[16:31:33 CEST] <BtbN> that's the most complicated usecase.
[16:31:43 CEST] <Lushi> :)
[16:31:59 CEST] <BtbN> And i don't think ffmpeg supports more than plain single-stream hls output.
[16:32:16 CEST] <JEEB> yeah, you have to make the meta playlists yourself, and the encodes are going to be separate
[16:32:28 CEST] <JEEB> it's just weird if it cannot set the TARGETDURATION to be what the user sets
[16:32:33 CEST] <Lushi> so maybe the question is wrong... which of my commands in my email were not correct to set the GOPs to the correct maximum length.
[16:33:00 CEST] <JEEB> -g should be all that's needed for maximum GOP length control
[16:33:46 CEST] <JEEB> anyways, looking at the HLS muxer's code
[16:33:49 CEST] <JEEB> avio_printf(out, "#EXT-X-TARGETDURATION:%d\n", target_duration);
[16:34:30 CEST] <Lushi> well - if you look in my example, I set -g 90 and  -hls_time 9 and I still got durations of 11.xxx seconds...
[16:34:39 CEST] <JEEB> seems like you might not be able to specifically control that target_duration variable
[16:34:52 CEST] <JEEB> because just before that printf line I see it going through the segments
[16:35:01 CEST] <JEEB> target_duration = ceil(en->duration);
[16:35:01 CEST] <Lushi> that value is just the maximum length of each of the segments..
[16:35:58 CEST] <JEEB> and yes it's weird if it doesn't let you control the maximum duration if that hls_time parameter is for that
[16:36:06 CEST] <JEEB> and this is with the latest HEAD ffmpeg or so?
[16:36:37 CEST] <Lushi> that is correct acording to the spec... the problem is that it is allowing some segments to be longer than I requested...which is bumping up the TARGETDURATION (but only on certain resolutions/bitrates/framerates)...which means that I can't combine them together...
[16:37:35 CEST] <Lushi> a version downloaded from http://johnvansickle.com/ffmpeg/ a few days ago: 2.7.1-static
[16:38:04 CEST] <JEEB> anyways, I recommend trying out VLC's muxing with say an mp4 sample you encoded with ffmpeg
[16:39:06 CEST] <Lushi> the TARGETDURATION wouldn't be a problem if it consistantly set keyframes every 3 seconds and chopped the segemnt after 9 seconds exactly...
[16:39:09 CEST] <JEEB> that really sounds quite weird, but it might be that the ffmpeg HLS muxer is specifically limited in some ways that make it just simpler to disable scenecut in libx264
[16:39:46 CEST] <Lushi> but apparently that isn't happening (at least with the arguments I am giving it) ..since each segment is a different duration...
[16:40:13 CEST] <Lushi> what does diabling scenecut do? make it not look for the "best" place to put a segment/keyframe?
[16:40:27 CEST] <JEEB> it wouldn't set keyframes at every 3 seconds, and the segment length would be variable. that is OK. what is not OK is that even though you are setting a maximum length to a segment it is not following that
[16:40:41 CEST] <JEEB> which is why I note that you should definitely try using VLC's muxer
[16:40:48 CEST] <JEEB> since it seems to be handling this fine as far as I can see
[16:42:05 CEST] <Lushi> why wouldn't setting -force_key_frames "expr:gte(t,n_forced*3)" or -g 90 along with disablign scenecut not force a keyframe every 3 seconds?  isn't that what they are made for?
[16:42:19 CEST] <Lushi> maybe if I use them both together?
[16:42:26 CEST] <JEEB> no, the latter should work just fine
[16:44:40 CEST] <Lushi> I'm going to try al 3 together - see if I can brut force this... what is teh command to disable scene cut?
[16:44:42 CEST] <JEEB> and probably the first two as well, but that's the worst case equipment
[16:45:00 CEST] <JEEB> nah, don't
[16:45:06 CEST] <JEEB> it's either the previous two or the latter two
[16:45:34 CEST] <JEEB> -x264opts I think? and then you check what is the API option that is the same as --no-scenecut in x264cdli
[16:45:37 CEST] <JEEB> *cli
[16:48:10 CEST] <Lushi> found something interesting I read earlier and tossed aside.
[16:48:14 CEST] <Lushi> https://sonnati.wordpress.com/2011/08/19/ffmpeg-%E2%80%93-the-swiss-army-knife-of-internet-streaming-%E2%80%93-part-iii/
[16:48:23 CEST] <Lushi> Sometimes you may need to have a consistent, contant gop size across multiple bitrates (i.e. for Http Dynamic Streaming or HLS). To do that set min and max gop size equal and disable completely scene change (i.e. -g 100 -keyint_min 100 -sc-threashold 0).
[16:49:59 CEST] <Lushi> I'll report back in a few minutes with results..
[16:50:35 CEST] <JEEB> well I'll just note one more time that the segments' lengths don't have to match, and that the main bugbear seems to be that you're not getting your set maximum segment length saved
[16:50:51 CEST] <JEEB> making all GOPs the same length is a workaround around that
[17:08:54 CEST] <Lushi> results: are dissapointing
[17:08:55 CEST] <Lushi> http://pastebin.com/JqxiMe3U
[17:09:53 CEST] <JEEB> yeah... if I cared enough I'd be poking the HLS muxer's code at this point
[17:10:03 CEST] <JEEB> thankfully VLC's seems to work for me
[17:10:25 CEST] <JEEB> that way I can control TARGETDURATION and that is all I need personally
[17:10:45 CEST] <Lushi> should this be something I bring up to the devel list?
[17:11:57 CEST] <JEEB> more like the trac issue tracker I guess. if you want to poke the original author he's in the libav project
[17:12:07 CEST] <JEEB> lu_zero methinks
[17:12:19 CEST] <JEEB> since hlsenc.c has * Copyright (c) 2012, Luca Barbato
[17:13:01 CEST] <Lushi> I'll try running that using the segment segmentor (instead of hls) and see what what I get...as well...
[17:13:46 CEST] <Lushi> what is the URL for the trac issue tracker? and do I put it in libav or in ffmpeg's tracker?
[17:14:22 CEST] <JEEB> libav stuff generally gets merged on an almost daily basis so if you want to have it fixed for everyone then you go for libav and poke the original author
[17:25:13 CEST] <pinkj> are there any known issues/expectations regarding multiple Streams from a single Feed in ffserver?  I noticed that ffmpeg seems to report higher framerates on the command line when ffserver has only one Stream enabled and lower framerates when I have three Streams enabled.
[17:29:14 CEST] <courrier> Hey guys! I'm tweaking the bitrate and fps during a 2pass encoding on the same input, do I need to reexecute the pass 1 each time?
[17:30:39 CEST] <DHE> courrier: playing with the bitrate is usually okay. other settings like framerate will ruin the first pass logs
[17:31:55 CEST] <courrier> DHE: ok thanks :)
[17:38:05 CEST] <Lushi> JEEB, do you think I can post to the avconv tracker using my current ffmpeg arguments? or do I need to redo all my commands and experiments using avconv?
[17:38:27 CEST] <Lushi> or should I just post it to ffmpeg and see what they do with it?
[17:38:39 CEST] <Lushi> by the way, thanks for all the help!
[17:40:36 CEST] <thiagoss> AVFrame->channel_layout seems to be 0 for stereo audio for a wmav2 file I have here. Wouldn't it be better if it contained the default stereo layout? Gstreamer currently uses av_get_channel_layout_nb_channels so it thinks the sample has 0 channels
[17:41:16 CEST] <thiagoss> I've been trying to find where that would be set but still couldn't understand where that would be set
[17:43:19 CEST] <thiagoss> It seems to be wma specific as 2-channels AAC seem to work nicely
[17:56:48 CEST] <thiagoss> The issue seems to have been introduced by commit 9dd0b7ad821ae1b60acd9ac8f6384c03bd28be51
[18:10:50 CEST] <thiagoss> Either that or 464f94b206b041fa383ab4257226cb3f18dfb550
[18:11:34 CEST] <molavy> hi
[18:11:58 CEST] <molavy> one convert make me crazy all day
[18:12:50 CEST] <molavy> i try make audio output for newrock om4-4s for greeting
[18:12:57 CEST] <molavy> on phone calls
[18:13:04 CEST] <molavy> but i can't make it work
[18:13:32 CEST] <molavy> on manuall there is codec table Table 2-23 Codec Methods Supported by OM
[18:13:32 CEST] <molavy> Bit Rate (Kbit/s) Time Intervals of RTP Package
[18:13:32 CEST] <molavy> Sending (ms)
[18:13:32 CEST] <molavy> G729A 8 10/20/30/40
[18:13:33 CEST] <molavy> PCMU/PCMA 64 10/20/30/40
[18:14:13 CEST] <molavy> and on upload page is on line guide
[18:14:14 CEST] <molavy> The size of the IVR file is limited to 300K bytes for PCMU format and 37K bytes for G.729 format
[18:15:02 CEST] <molavy> i  check codec default files on devices by download and open them using vlc
[18:15:08 CEST] <molavy> codec info show
[18:15:25 CEST] <molavy> Codec: PCM S16 LE (s16l)
[18:15:33 CEST] <molavy> Sample rate: 8000 Hz
[18:15:39 CEST] <molavy> mono
[18:15:55 CEST] <molavy> Bits per sample: 16
[18:16:22 CEST] <molavy> i don't know how can i convert our recorded video that let me use it on this device
[18:16:29 CEST] <molavy> can some one help me with this
[18:16:33 CEST] <molavy> ?
[18:20:47 CEST] <molavy> any idea?
[18:22:50 CEST] <molavy> there is no idea?
[18:22:59 CEST] <molavy> i really need help about this
[18:25:10 CEST] <AstralStorm> hey, I'm having trouble with decoding ffmpeg-encoded MPEG-4 AAC to the right length
[18:25:31 CEST] <AstralStorm> I'm now correctly skipping negative PTS data, but I get an oversized duration last packet
[18:25:48 CEST] <AstralStorm> packet has duration e.g. 1536 while nb_frame is 1024
[18:26:42 CEST] <AstralStorm> *nb_samples
[18:32:58 CEST] <AstralStorm> I cannot just take the modulo as this could potentially be valid in some formats
[18:33:10 CEST] <AstralStorm> (non-mp4, the decoder is generic)
[18:34:53 CEST] <Mavrik> I don't understand your issue
[18:35:11 CEST] <Mavrik> If you need 1024 long frames, you'll have to split the 1536 to a 1024 + 512 one
[18:37:24 CEST] <molavy> Mavrik: what about my problem
[18:37:34 CEST] <molavy> can you help me
[18:37:35 CEST] <molavy> ?
[18:37:37 CEST] <Mavrik> What about it?
[18:37:57 CEST] <Mavrik> I don't really understand what do you want.
[18:38:00 CEST] <molavy> one convert make me crazy all day
[18:38:08 CEST] <molavy> i try make audio output for newrock om4-4s for greeting  on phone calls
[18:38:31 CEST] <molavy> but i can't upload because it don't accept file
[18:38:44 CEST] <molavy> on manual there is codec table
[18:38:46 CEST] <molavy> Table 2-23 Codec Methods Supported by OM
[18:39:02 CEST] <molavy> Methods Supported by OM Bit Rate (Kbit/s) Time Intervals of RTP Package
[18:39:20 CEST] <molavy> G729A 8 10/20/30/40
[18:39:20 CEST] <molavy> PCMU/PCMA 64 10/20/30/40
[18:39:27 CEST] <molavy> and on upload page is one line guide
[18:39:33 CEST] <molavy> The size of the IVR file is limited to 300K bytes for PCMU format and 37K bytes for G.729 format
[18:39:40 CEST] <molavy> i  check codec default files on devices by download and open them using vlc
[18:40:06 CEST] <Mavrik> What you pasted is non-sensical and doesn't really help determining what do you need.
[18:40:13 CEST] <molavy> codec info show :  Codec: PCM S16 LE (s16l)   Sample rate: 8000 Hz  mono Bits per sample: 16
[18:40:49 CEST] <molavy> Mavrik: what you need to know
[18:42:10 CEST] <molavy> ?
[18:42:20 CEST] <Mavrik> container, codec, parameters
[18:42:53 CEST] <AstralStorm> Mavrik: that's how I encoded it
[18:43:06 CEST] <AstralStorm> the problem is in decoding - last packet *decoded* is too long duration
[18:45:35 CEST] <AstralStorm> ffprobe says duration is correct and start is also correctly offset (by one frame delay)
[18:46:19 CEST] <molavy> Mavrik: if i know who to export and and parameters i don't ask it here
[18:46:32 CEST] <molavy> how
[18:46:48 CEST] <AstralStorm> no, wait, last packet is overlong, wtf
[18:46:54 CEST] <AstralStorm> why.
[18:55:25 CEST] <molavy> i try this
[18:55:30 CEST] <molavy> with no success
[18:55:31 CEST] <molavy> ffmpeg -i NewMorning.wav  -f s16le -ar 8000  -ac 1  -acodec pcm_s16le output.pcm
[18:58:31 CEST] <AstralStorm> hmm, it seems I mucked with pts/dts on flushed packets
[18:58:44 CEST] <AstralStorm> so this is potentially why I got wrong packet duration
[19:00:54 CEST] <molavy> there is no one here that help me
[19:01:08 CEST] <molavy> i just want make an output
[19:03:47 CEST] <Lushi> JEEB, DHE, Maverik: I filed a bug. https://trac.ffmpeg.org/ticket/4733
[19:06:14 CEST] <AstralStorm> hmm, weird, the extra is actually similar to what output of fdkenc is
[19:06:41 CEST] <AstralStorm> last packet made by fdkenc in -G 1 mode is overlong too and even more  so
[19:12:52 CEST] <molavy> can some one help me with this
[19:13:07 CEST] <AstralStorm> oh, I see, ffmpeg does not support edit list?
[19:13:18 CEST] <molavy> i just want convert a file for use in phone call greeting system
[19:13:24 CEST] <AstralStorm> as in ISO/IEC 14496-12:2003
[19:14:44 CEST] <AstralStorm> hmmh
[19:20:05 CEST] <molavy> 302 user with no answer
[19:20:40 CEST] <molavy> i forced go to windows and use windows tools with gui
[19:39:47 CEST] <Lushi> JEEB, you still there?
[19:39:55 CEST] <JEEB> never
[19:40:08 CEST] <Lushi> :)
[19:43:25 CEST] <Lushi_> ...sorry..my network went down for a minute...
[19:49:58 CEST] <oscargot> @durandal_1707: yes it is fairly slow and takes about 150ms per conversion when resolution is 1080p
[19:51:03 CEST] <Mavrik> hmm, that sounds overly excessive
[19:51:04 CEST] <durandal_1707> oscargot: I forgot what is slow?
[19:51:13 CEST] <Mavrik> considering it's a simple swap
[19:51:21 CEST] <Mavrik> are you copying stuff around too much?
[19:52:22 CEST] <oscargot> here is my original question: Hello, is there anyway to directly encode a NV12 pix format image to MPEG4 using libav rather than having to first convert it to YUV420P sws_scale? Or optimise the conversion step?
[19:52:38 CEST] <oscargot> Mavrik: I am trying to convert NV12 to YUV420p
[19:52:42 CEST] <Mavrik> I mean, there's no way your pix format conversion should take more than the encode.
[19:52:47 CEST] <Mavrik> Yes.
[19:54:56 CEST] <oscargot> hmmmm the time measurement was done by measure the time right before/after sws_scale, I'm not doing any copying myself between this time.
[19:55:46 CEST] <Mavrik> If you're on an embedded device, you could do conversion youself in NEON or something
[19:56:00 CEST] <Mavrik> As I said, NV12 -> YUV420p means just deinterleaving a plane
[19:56:28 CEST] <oscargot> Mavrik: yes that's true, I've not heard of NEON before, I will look into it thanks
[19:56:39 CEST] <Mavrik> NEON is an ARM instruction set
[19:56:44 CEST] <Mavrik> what kind of device do you have?
[19:59:19 CEST] <oscargot> I'm working with an arm processor so it should apply?
[20:01:23 CEST] <Mavrik> If it has that instruction set.
[20:01:30 CEST] <Mavrik> (It's not mandatory)
[20:37:17 CEST] <benbro1> what's the standard FPS for browsers? 29 fps?
[20:38:22 CEST] <JEEB> I don't think there is such a thing :P
[20:38:39 CEST] <JEEB> you encode with the frame rate your content is, or do VFR or whatever
[20:38:47 CEST] <JEEB> all containers contain timestamps
[20:39:04 CEST] <JEEB> (I mean, all of the ones supported by browsers)
[20:40:50 CEST] <benbro1> ok. thanks
[20:43:30 CEST] <AStorm> so folks what about decoding m4a with ffmpeg gaplessly?
[20:43:36 CEST] <AStorm> as it is now the final packet is overlong
[20:43:59 CEST] <AStorm> and I need to handle that in a way that does not break other decoders
[20:47:42 CEST] <benbro1> JEEB: should I use 25 fps or 29 fps for live streaming?
[20:51:03 CEST] <JEEB> benbro1: whatever your source rate is?
[20:51:14 CEST] <JEEB> I mean, I see no fucking reason to change your source rate for anything
[20:52:30 CEST] <JEEB> AStorm: if it's supposedly marked with edit list then it might be better for you to try and get that virtual timeline stuff into mainline, although it will be quite funky and hard most probably
[20:53:18 CEST] <AStorm> JEEB: I think both are
[20:53:26 CEST] <AStorm> even ffmpeg puts an edit listin
[20:53:29 CEST] <JEEB> yeah
[20:53:32 CEST] <JEEB> there's always an edit list
[20:53:40 CEST] <JEEB> but it's usually for the whole length, or implicit
[20:53:50 CEST] <benbro1> JEEB: I had a file with 1000 fps. not sure why
[20:53:51 CEST] <Mavrik> Also, you certanly shouldn't use 29 fps :P
[20:54:01 CEST] <AStorm> fdkenc seems to put in elst too
[20:54:14 CEST] <benbro1> Mavrik: what's wrong with 29 fps? what should I use instead?
[20:54:21 CEST] <AStorm> yeah, 29.97 is the right FPS ;p
[20:54:24 CEST] <JEEB> benbro1: sounds like something misparsed FLV's timebase as frame rate :P
[20:54:28 CEST] <JEEB> AStorm: 30000/1001
[20:54:32 CEST] <AStorm> yup
[20:54:44 CEST] <Mavrik> Isn't lately 60 or 30 more like default
[20:54:50 CEST] <AStorm> yep
[20:54:52 CEST] <benbro1> I converted wmv to mp4 and the result was 1000.1 fps
[20:54:55 CEST] <AStorm> 60 FPS is all the rage
[20:54:56 CEST] <Mavrik> or is US still recording stuff in 59.97?
[20:55:11 CEST] <AStorm> also 50 FPS
[20:55:29 CEST] <Mavrik> 50 is for interlaced PAL 25
[20:55:33 CEST] <Mavrik> rarer these dasy
[20:55:35 CEST] <Mavrik> *days
[20:55:46 CEST] <AStorm> you mean noninterlaced
[20:56:23 CEST] <Mavrik> Erm, no.
[20:56:41 CEST] <Mavrik> But I did mean fieldrate :)
[20:57:25 CEST] <benbro1> so I should use "-r 20.07" ?
[20:57:33 CEST] <benbro1> sorry "-r 29.97"
[20:57:51 CEST] <Mavrik> benbro1, you should not use anything
[20:57:57 CEST] <Mavrik> and leave the framerate you have
[20:58:11 CEST] <Mavrik> framerate conversion just ruins quality
[20:58:12 CEST] <benbro1> but what if the source frame rate isn't ideal?
[20:58:12 CEST] <JEEB> I'm pretty sure your content isn't 1000fps but rather WMV's VFR antics caused you to have a lulzy timebase
[20:58:39 CEST] <JEEB> VMW encoders have been known to create VFR if stuff doesn't change on screen
[20:58:43 CEST] <Mavrik> benbro1, how will deleting frames and readding duplicates improve the situation? It won't, if it's ruined, it's ruined. But I doubt yours is, it just has wrong metadata.
[20:59:30 CEST] <JEEB> of course it's possible that whatever re-encoded your VMW drove off the retard cliff
[20:59:51 CEST] <JEEB> but then you take that WMV into your pretty hands again and start jerking the WMV into something less proprietary
[21:00:51 CEST] <Mavrik> *shudders*
[21:02:17 CEST] <benbro1> ok
[21:15:21 CEST] <benbro1> can ffmpeg convert pcap capture of RTP to a video?
[00:00:00 CEST] --- Fri Jul 24 2015