Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

October 2016

1 participants
62 discussions

ffmpeg-devel.log.20160930
by burek 01 Oct '16

01 Oct '16

[00:24:18 CEST] <llogan> michaelni__: did you unsubscribe the bouncing user that cehoyos mentioned? that address is not in the membership list. could be an alias... [00:26:04 CEST] <michaelni__> llogan, i wanted to look into it but forgot, so no i didnt unsub him [00:28:47 CEST] <llogan> i guess I'll email the user directly and ask him what the alias is [00:30:21 CEST] <llogan> ...becasue fixing DKIM seems like too much of a pain in the ass [00:34:02 CEST] <wm4> I already regret "returning" to ffmpeg development [00:34:05 CEST] <wm4> all this ridiculous crap... [00:34:28 CEST] <wm4> I can only hope project management will be different in the future [00:43:08 CEST] <jamrial> wm4: it's not the first time a patch that makes such a big change breaks a weird file or scenario [00:43:29 CEST] <jamrial> the codecpar and bsf ports also broke a lot of things at first [00:47:14 CEST] <wm4> that's not the problem, but that it has to be libavdevice/openal [00:56:22 CEST] <iive> wm4: what's the problem? [00:58:48 CEST] <wm4> bad test case [01:14:34 CEST] <iive> ?? [01:15:21 CEST] <Chloe> iive: wm4 doesn't want to use openal, so they want a different way to produce the issue michaelni is describing (not involving lavd) [01:16:03 CEST] <iive> what's the issue? [01:16:37 CEST] <Chloe> The testcase uses openal [01:17:09 CEST] <iive> testcase for what? [01:18:15 CEST] <llogan> refer to the ML [01:18:32 CEST] <Chloe> iive: https://ffmpeg.org/pipermail/ffmpeg-devel/2016-September/200319.html [07:56:11 CEST] <Wesley_Chan> Hi. [08:00:35 CEST] <Wesley_Chan> I'm not sure if anyone is listening to this but I want "-map_metadata 0" to copy nothing but only the language part. I had to modify av_dict_copy() in libavutil/dict.c to archieve this. I know this is a dirty fix but is there a better place to put my patch? Maybe a "-metadata_cleanup" switch in the future? [08:34:56 CEST] <rcombs> hmm, I've been considering a similar feature [08:35:00 CEST] <rcombs> too bad they're gone [08:35:09 CEST] <rcombs> might do it with a tweak to copy_metadata to let you specify specific keys to map [09:21:27 CEST] <Chloe> michaelni: I still don't understand, why couldn't the libfaac testcases be moved to another encoder? [09:23:03 CEST] <nevcairiel> there arent even actual proper testcases, not in the sense of FATE [09:23:12 CEST] <nevcairiel> because we dont test external libnraries [10:03:44 CEST] <wm4> michaelni: do you really expect me to install openal and to enable libavdevice? [10:05:23 CEST] <ubitux> how portable is regex.h? [10:07:02 CEST] <rcombs> ubitux: probably portable enough to have as an optional dep, but not portable enough to require for anything core? [10:07:13 CEST] <rcombs> (available on win32, but a pain) [10:07:20 CEST] <ubitux> my guess as well, ok [10:07:24 CEST] <rcombs> what for? [10:07:35 CEST] <ubitux> there is a patch for multistream SAMI [10:07:52 CEST] <ubitux> that format needs you to parse the CSS style to extract languages specifications (don't ask me.) [10:08:05 CEST] <ubitux> the patch is just doing some regex to find them [10:09:28 CEST] <rcombs> sounds like it should probably be rewritten without regex, but also wow what a mess [10:09:34 CEST] <ubitux> yeah [10:09:41 CEST] <ubitux> it's not the right approach too [10:09:45 CEST] <ubitux> it needs to create multiple streams [10:12:15 CEST] <wm4> ubitux: it's not? [10:12:37 CEST] <wm4> (haven't looked at the patch) [10:12:58 CEST] <ubitux> it's not creating multiple streams for each language [10:14:11 CEST] <rcombs> would be nice to have some mechanism for a decoder (parser?) to split input into multiple streams [10:14:32 CEST] <rcombs> happens for e.g. subtitles crammed into H.264, too [10:15:59 CEST] <wm4> well this is a demuxer [10:16:06 CEST] <wm4> or should be [10:30:45 CEST] <rcombs> wm4: so, pass streams coming from e.g. a .ts through a "chained" demuxer? [10:31:19 CEST] <wm4> I meant the sami thing [10:31:38 CEST] <rcombs> oh, yeah, if that's in a plaintext sami file sure [10:32:00 CEST] <rcombs> for some reason I thought we were talking about multiple actual streams in the same e.g. MKV track [10:32:02 CEST] <wm4> for A53 captions, feeding the side data back to a pseudo-demuxer stream might work (mpv does that)# [10:32:32 CEST] <rcombs> I'd just like to see it handled within lavf [10:33:49 CEST] <wm4> for that it'd have to be able to do frame reordering within the parser [11:51:22 CEST] <michaelni> Chloe, to test a ticket for regression one looks at the ticket on trac, takes the input sample and the quoted command line from the ticket. Now to truly move these to a different encoder one would have to check if the original issue is reproducable with a diferent encoder with old FFmpeg and if needed adjust the testcase until it reproduces then update the testcase in the ticket. Noone will do this, its a completely [11:51:22 CEST] <michaelni> unrealistic amount of work [11:54:59 CEST] <nevcairiel> keeping some old piece of unused code for this a lone seems also rather silly [13:13:22 CEST] <rcombs> https://puu.sh/rsOdK/e9eca8a945.ts mmmmmmm update_stream_timings issues [13:14:34 CEST] <rcombs> https://gist.github.com/50d4b9123bae598d9c3d1a9f321e44b7 fixes [13:25:15 CEST] <jsodjfcn> am I readable ? [13:26:02 CEST] <jsodjfcn> am I readable ? any developers around ? wanted to submit a bug if its a bug ? [13:27:13 CEST] <wm4> jsodjfcn: you are readable [13:27:26 CEST] <wm4> rcombs: looks scary [13:27:41 CEST] <BtbN> "git: 'send-email' is not a git command. See 'git --help'." I'm quite sure it is git. [13:27:43 CEST] <rcombs> wm4: there's already almost identical code for end times [13:28:18 CEST] <wm4> BtbN: you probably need to install it separately [13:28:39 CEST] <jsodjfcn> wm4: are you a devel ? should I start my bug story ? [13:29:00 CEST] <wm4> jsodjfcn: bug reports go on the bug tracker [13:29:11 CEST] <jsodjfcn> wm4: I dont know if its a bug [13:29:27 CEST] <wm4> normally you'd go to #ffmpeg or so and ask there [13:29:45 CEST] <wm4> (let's just say they have better experience dealing with user problems) [13:29:55 CEST] <jsodjfcn> wm4: I'm coming from there only, there was only BtbN responding and helping out [13:30:01 CEST] <wm4> ubitux: is there a chance yet to have a new AVFrame based subtitle API? [13:30:21 CEST] <nevcairiel> how do you put text into AVFrames [13:30:30 CEST] <wm4> that's the question [13:31:22 CEST] <nevcairiel> unifying subtitles into the same structures would definitely be great [13:31:31 CEST] <BtbN> wm4, indeed. Seems to be a new feature. [13:31:35 CEST] <wm4> yeah, just for the APIs [13:32:10 CEST] <nevcairiel> but then, subtitles have some additional metadata that AVFrames just dont carry yet [13:32:18 CEST] <nevcairiel> like, position [13:32:40 CEST] <wm4> if anything the AVFrame could merely point to an AVSubtitle [13:33:06 CEST] <ubitux> wm4: yeah, now that i'm done with nlmeans and codecpar, i have time for this [13:33:38 CEST] <wm4> ubitux: once this is done, ffmpeg.c's data flow could possibly be changed to something that's nicer with the new APIs [13:33:38 CEST] <ubitux> i'm a bit anxious about the libav merge commits stack though [13:33:46 CEST] <ubitux> wm4: yeah, i know ;) [13:33:54 CEST] <ubitux> that will be grea [13:33:56 CEST] <ubitux> +t [13:34:15 CEST] <wm4> also, does ffprobe have any tests? [13:34:17 CEST] <nevcairiel> you guys got a lot of the "bad" backlog of merges out of the way [13:34:20 CEST] <nevcairiel> it does [13:34:31 CEST] <wm4> within the fate target? [13:34:34 CEST] <nevcairiel> yes [13:34:37 CEST] <wm4> oh, ok [13:34:53 CEST] <rcombs> wm4: yeah, fate-ffprobe-<format> [13:35:17 CEST] <rcombs> and a fair number of other tests are based on comparison of ffprobe output [13:35:22 CEST] <nevcairiel> not sure what other things it might be used for in the tests [13:38:06 CEST] <jsodjfcn> wm4: 1st part of story- I download a video of 2 parts from web and joined them with ffmpeg *** 2nd part- joinging with latest version from zerone plays only 1st part and not 2nd part video, audio however plays fine. **** 3rd part - joining the same 2 vids with an older version of ffmpeg embedded with thekmplayer plays video fine. both parts and audio also. *** now is it some kind of bug in new version ? [13:38:26 CEST] <wm4> that's definitely a #ffmpeg question, go there [13:38:50 CEST] <jsodjfcn> wm4: told you, I'm coming from there only [13:39:02 CEST] <wm4> then wait longer for a reply [13:39:09 CEST] <wm4> this channel is not for user help [13:39:10 CEST] <BtbN> and you already got the right reply. Please report it on trac. [13:40:59 CEST] <jsodjfcn> I've already joined video with older version, I need no further help on this particular matter, I just wanna help ffmpeg in bringing to its notice a bug if its a bug [13:41:31 CEST] <wm4> then report it on the bug tracker [13:42:08 CEST] <jsodjfcn> BtbN: thnx for your help, but reporting a bug doesnt completes a task currently on hand [13:42:23 CEST] <jsodjfcn> anyways thnx all, BtbN thnx [13:42:36 CEST] <BtbN> by the time you have spent arguing about this you could have filed the bug multiple times. [13:43:20 CEST] <jsodjfcn> BtbN: I'm not arguing, just clearing my point, I was very very clear, I dont wanna create a new account [13:47:19 CEST] <Compn> jsodjfcn : whats the url of your files and i'll post the trac bug for you [13:47:29 CEST] <Compn> also need full output from both ffmpeg versions [13:47:46 CEST] <Compn> including the commands you used [13:47:57 CEST] <Compn> paste it all to pastebin so i can grab it easily... [13:48:48 CEST] <Compn> without your specific sample files, its possible we wont find the bug [13:49:59 CEST] <Compn> oh also isnt there pre made account people can use on ffmpeg trac to report bugs ? [13:50:03 CEST] <Compn> hmm theres one for mplayer ;D [13:50:26 CEST] <Compn> that would make it easier for people who dont want to register to post bugs :) [13:51:01 CEST] <jsodjfcn> Compn: okay, gimme a few minutes, I'll do it slowly, I'm not a pro (I support FFMPEG :D) [13:51:09 CEST] <Compn> thanks :) [14:13:37 CEST] Action: Compn goes kinda afk will read later [15:41:06 CEST] <BBB> atomnuker: isnt faac an encoder? [15:41:35 CEST] <BBB> (I think it was just a typo, you seem to be talking about encoding stuff in yuor response, but you said decoder instead of en) [15:42:26 CEST] <wm4> yeah it's only an encoder [15:43:02 CEST] <wm4> man I remember mplayer times, and how I sometimes had to switch decoder libs for various broken streams or decoder bugs [15:43:08 CEST] <wm4> usually for aac [15:43:45 CEST] <wm4> libfaad [15:44:34 CEST] <wm4> wow there's even libfaad2 [15:44:39 CEST] <wm4> which gstreamer uses (???) [15:45:07 CEST] <wm4> trying to remove it from debian will literally wipe all KDE packages [15:45:09 CEST] <wm4> so backwards [15:45:49 CEST] <atomnuker> wm4: shouldn't do it if you have the null phonon backend [15:46:30 CEST] <atomnuker> (though dependencies are messed up wrt phonon backends and its hard not to install vlc) [16:01:45 CEST] <BBB> linux package management... [16:01:49 CEST] <BBB> omg, the memories [16:02:45 CEST] <rcombs> at least it's not windows [16:02:49 CEST] <wm4> or OSX [16:03:07 CEST] <BBB> and the trollwar began :D [16:03:10 CEST] Action: BBB runs [16:24:55 CEST] <philipl> What happens with hwframes if the frame size changes mid-stream? I don't see it getting reinitialized, but maybe I'm missing something. [16:31:38 CEST] <nevcairiel> hwaccels will typically just re-create the entire decoder block, with new hwframes [16:31:47 CEST] <nevcairiel> non-hwaccel t hings will probably have to die horribly [16:39:32 CEST] <philipl> ok. So I'm reading it correctly :-) [19:41:00 CEST] <ubitux> http_multiclient crashes out of the box [19:41:14 CEST] <cone-427> ffmpeg 03Clément BSsch 07master:44103c600167: build: sort EXAMPLE_LIST [19:41:14 CEST] <cone-427> ffmpeg 03Clément BSsch 07master:352ca77f8ab5: build: fix avio_dir_cmd and avio_reading example dependencies [19:41:14 CEST] <cone-427> ffmpeg 03Clément BSsch 07master:fb5e58cd773e: doc/examples/http_multiclient: fix compilation [19:41:14 CEST] <cone-427> ffmpeg 03Clément BSsch 07master:f2579f7ee232: doc/examples/http_multiclient: fix mixed declarations and code [19:41:14 CEST] <cone-427> ffmpeg 03Clément BSsch 07master:3d064b7802fd: build: remove references to inexistant avcodec example [19:41:15 CEST] <cone-427> ffmpeg 03Clément BSsch 07master:1e647d200fae: doc/examples/gitignore: add forgotten qsvdec entry [19:41:15 CEST] <cone-427> ffmpeg 03Clément BSsch 07master:1a9b4bc4c7b6: doc/examples: build http_multiclient example [19:41:41 CEST] <ubitux> http://sprunge.us/NiQE [19:41:59 CEST] <ubitux> anyone familiar with this? [20:15:25 CEST] <BBB> ubitux: looks like a NULL pointer being used somewhere [20:15:28 CEST] <BBB> no I havent used it before [20:24:40 CEST] <Chloe> ubitux: nice prompt [20:25:15 CEST] <ubitux> Chloe: and you don't even see the on failure ;) [20:25:53 CEST] <Chloe> oh wow, I just have a '$' which change colours, your prompt sounds really fancy [23:47:34 CEST] <ubitux> Chloe: not really; http://sprunge.us/gDAD [23:48:23 CEST] <ubitux> (+setopt transient_rprompt) [23:48:36 CEST] <Chloe> is that just bash? [23:48:45 CEST] <ubitux> zsh [23:50:10 CEST] <Chloe> ah, maybe I should add some emoji to mine as well. my zsh prompt: PS1="%6F%n%f@%5F%m%f:%4F%~%f%(!.%(?.%2F#%f.%1F#%f).%(?.%2F$%f.%1F$%f)) " I made it when I understood how it worked, I should have probably used the long options instead of the short ones [00:00:00 CEST] --- Sat Oct 1 2016

1 0

ffmpeg.log.20160930
by burek 01 Oct '16

01 Oct '16

[00:03:44 CEST] <tdr> transhuman, found a post where someone says adding -demuxer mov to his before the output file name fixed his same error, trying adding that with the write format of file (if you're not using mov) [00:05:14 CEST] <tdr> eh that may be a switch to his mplayer he was using ffmpeg through [00:25:00 CEST] <transhuman> ok can i see the link ? [00:30:10 CEST] <TwinTailed> I've got a problem with LibAV (FFMpeg version), its that I can't set H264 video to high, the log says that the profile is High, but the generated MP4 is Baseline [00:33:02 CEST] <TwinTailed> And what does "shifted frame pts," debug message mean? [00:34:15 CEST] <TwinTailed> what about "forced frame type (5) at 2648 was changed to frame type (3)"? What does it mean [00:45:36 CEST] <transhuman> tdr problem with the & method is that it gives me no way of telling when all the ffmpeg manipulations have completed [00:47:29 CEST] <TwinTailed> I will be online for a while if anyone knows the answer to any of my questions please reply to me [00:48:00 CEST] <markvandenborre> hi... can anyone around here say anything useful about multithreading and h264 [00:48:01 CEST] <markvandenborre> ? [00:48:30 CEST] <markvandenborre> when compressing files, h264 seems incredibly efficient in working all the cores [00:48:49 CEST] <markvandenborre> but I wonder how things will be different for streams... [00:49:03 CEST] <markvandenborre> any comments welcome! [00:49:36 CEST] <DHE> yes, libx264 is multi-threaded to the extreme. but too many threads will also compromise image quality [00:49:57 CEST] <DHE> what do you mean by "streams" ? [00:50:36 CEST] <TwinTailed> DHE: what does "shifted frame pts," debug message mean? [00:50:56 CEST] <TwinTailed> DHE: [mov,mp4,m4a,3gp,3g2,mj2 @ 0090bc20] shifted frame pts, curr_cts: 5394138 @ 1165 [00:50:57 CEST] <TwinTailed> , ctts: 3754, ctts_count: 28196 [00:51:19 CEST] <DHE> TwinTailed: stop asking me random questions directly [00:53:31 CEST] <TwinTailed> DHE: you know that ffmpeg's documentation doesn't cover much, so i'm somehow desperate for help [00:53:48 CEST] <TwinTailed> especially when it comes to LibAV and Libx264 [00:54:20 CEST] <DHE> you know I'm not an ffmpeg dev and my scope of knowledge is limited [00:56:23 CEST] <TwinTailed> you helped me many times before [00:56:48 CEST] <markvandenborre> DHE: we're looking into encoding for 24 parallel rtmp streams for a big FOSS conference [00:57:02 CEST] <markvandenborre> 720p25 video [00:57:45 CEST] <markvandenborre> we can get hold of a pile of Intel Xeon E7530 servers (quad hexacore, 2 threads per core, so 48 threads/machine) [01:00:10 CEST] <markvandenborre> DHE: I'm researching this for https://fosdem.org [01:05:29 CEST] <markvandenborre> so I really appreciated your comment [01:24:14 CEST] <Atm0spher1c> hello, how can I rate limit ffmpeg stream? [01:25:01 CEST] <Chloe> try -re [01:25:31 CEST] <llogan> that's a somewhat vague question [01:26:54 CEST] <TwinTailed> Chloe, can I ask you something about libav (ffmpeg)? [01:27:43 CEST] <Chloe> TwinTailed: I probably wouldnt be able to answer it if it's an API question, but others might [01:28:45 CEST] <TwinTailed> why my output MP4 file shows black screen (audio plays) on QuickTime and Windows Media Player? Even though the pix format is shown yuv420p on MediaInfo [01:28:59 CEST] <TwinTailed> On VLC and FFMPEG based players, it plays normally [01:30:43 CEST] <markvandenborre> TwinTailed: ffprobe ? [01:31:17 CEST] <Atm0spher1c> Chloe: thanks. basically wondering if its possible to set the download rate in bytes per second for example. [01:31:25 CEST] <Atm0spher1c> download rate is too fast, i want to slow it down [01:31:41 CEST] <markvandenborre> that should give you some info on encoding [01:31:53 CEST] <Chloe> Atm0spher1c: wow! more information, but stilll not enough. What command are you actually running?a [01:36:43 CEST] <TwinTailed> here is my ffprobe http://pastebin.com/t3VuDY0X [01:41:56 CEST] <Atm0spher1c> Chloe: llogan https://paste.debian.net/845976/ [01:43:57 CEST] <llogan> Atm0spher1c: why did you not include the complete console output? [01:45:43 CEST] <Atm0spher1c> honestly, im running it from a python script that doesnt include console output [01:46:15 CEST] <llogan> not much we can do without it [01:46:58 CEST] <Chloe> Atm0spher1c: run it outside of the script? [01:47:06 CEST] <Atm0spher1c> without console output you don't know if ffmpeg has an option --rate-limit 300k? [01:52:06 CEST] <DHE> markvandenborre: ffmpeg can be run in the background with nohup and parameter -nostdin [01:52:32 CEST] <DHE> alternatively I'm a fan of running in a screen (or tmux if you prefer) session so you can attach to it later and see any errors or stats [01:53:17 CEST] <DHE> right now ffmpeg has a bit of a flaw that it needs a working stdin, hence the above "requirements" [01:54:41 CEST] <TwinTailed> Does anyone know what "Duration_LastFrame" means in MediaInfo? [02:00:21 CEST] <iive> i don't know, but my guess would be that it indicates [02:00:35 CEST] <iive> how log the audio keeps playing after the last video frame [02:01:46 CEST] <TwinTailed> iive: and if its negative? [02:02:16 CEST] <iive> it probably means the audio stops before the video [02:03:33 CEST] <TwinTailed> I see... thank you :) [02:45:33 CEST] <TwinTailed> does anyone know what "forced frame type (3) at 2999 was changed to frame type (1)" means? [02:48:30 CEST] <DHE> produced by which AVClass? [02:50:53 CEST] <TwinTailed> DHE: its produced by libx264 [02:52:25 CEST] <DHE> you requested a P-frame but x264 called bullshit and turned it into a keyframe [04:35:04 CEST] <rue_house> I'm trying to recode a video from my camera, which has like no encoding so its huge [04:35:12 CEST] <rue_house> [mp2 @ 0x845f4d8]Sampling rate 8000 is not allowed in mp2 [04:35:20 CEST] <rue_house> from ffmpeg -i p1080476.mov video.mpg [04:35:23 CEST] <rue_house> help? [04:37:32 CEST] <c_14> Did you build that version of ffmpeg yourself? [04:37:41 CEST] <c_14> Is there any specific reason you're using the mpg container? [04:37:51 CEST] <c_14> Have you tried using -c:a copy? [04:38:36 CEST] <rue_house> I just need it encoded to anything thats not 1G [04:38:45 CEST] <rue_house> VO: [x11] 640x480 => 640x480 Planar YV12 [04:38:54 CEST] <rue_house> I think its not that compressed out of the camera [04:39:43 CEST] <rue_house> what should I use? [04:39:59 CEST] <rue_house> I just dont want to uplaod it to youtube in its 1G size [04:40:12 CEST] <c_14> If you don't care about the container, just use .mkv [04:40:20 CEST] <rue_house> ok [04:40:50 CEST] <rue_house> is that copressed at all? [04:40:55 CEST] <rue_house> heh cant type [04:41:28 CEST] <c_14> a container is just a container, but the default codecs ffmpeg chooses for matroska should be libx264 and internal aac (or if you don't have libx264, mpeg4) [04:41:49 CEST] <c_14> You might want to set a bitrate for aac (not sure what it defaults to), libx264 defaults to crf 23 preset medium which is probably fine [04:42:22 CEST] <rue_house> my experience with camera footage is that even recoding it to the same thing, with no quality loss, results in a file half the sizze [04:42:53 CEST] <rue_house> Unable for find a suitable output format for 'video.mkv' [04:42:58 CEST] <rue_house> FFmpeg version SVN-r5826, Copyright (c) 2000-2004 Fabrice Bellard [04:43:14 CEST] <c_14> wooooow [04:43:20 CEST] <rue_house> it finished an mpg but the quality is horrid, can I just bump it a bit? [04:43:21 CEST] <c_14> Are you by any chance a time traveller? [04:43:30 CEST] <rue_house> yea, I came from yesterday [04:43:36 CEST] <rue_house> I am from the past [04:43:37 CEST] <c_14> The year 2004 called, they want their code back [04:43:49 CEST] <c_14> get a static build from https://www.johnvansickle.com/ffmpeg/ and try with that [04:43:54 CEST] <rue_house> k whatever can you help me bump the codec quality? [04:43:56 CEST] <c_14> (or build from source, or get a better distro) [04:44:04 CEST] <rue_house> no lets not recompiel my computer now [04:44:12 CEST] <c_14> Use a newer build of ffmpeg, it'll look better [04:44:30 CEST] <rue_house> can I just tell the mpeg encoder to be high quality? [04:44:37 CEST] <c_14> more or less [04:44:42 CEST] <c_14> set -b:a to something high(ish) [04:44:45 CEST] <rue_house> k, how would I do that? [04:44:48 CEST] <c_14> -b:a 2m or something [04:44:50 CEST] <c_14> maybe [04:44:53 CEST] <rue_house> ok [04:45:29 CEST] <rue_house> is the a litteral or 2m? [04:45:56 CEST] <c_14> literally add '-b:a 2m' (without the quotes) before output.mpeg [04:46:16 CEST] <rue_house> ffmpeg: unrecognized option '-b:a' [04:46:19 CEST] <rue_house> its older than that [04:46:30 CEST] <c_14> -ab 2m [04:46:37 CEST] <rue_house> -b? [04:46:43 CEST] <c_14> eh, right [04:46:45 CEST] <c_14> -b [04:46:47 CEST] <c_14> -ab is audio [04:46:52 CEST] <c_14> It's either -b or -vb [04:47:38 CEST] <rue_house> hmm I wonder if its encoding it at 2kb/s .... [04:47:56 CEST] <rue_house> Output #0, mpeg, to 'video.mpg': [04:47:56 CEST] <rue_house> Stream #0.0: Video: mpeg1video, yuv420p, 640x480, q=2-31, 2 kb/s, 30.00 fps(c) [04:48:08 CEST] <rue_house> the audio is 64k/s so... [04:48:13 CEST] <rue_house> hahahaha [04:48:17 CEST] <_merlim_> the ffprobe on my osx was updated and now I am getting a "-d,: No such file or directory" on my command line to calculate resolutions, that used to work fine until now [04:48:21 CEST] <rue_house> I'm gonna get 3 pixels per fame [04:48:42 CEST] <rue_house> Stream #0.0: Video: mpeg1video, yuv420p, 640x480, q=2-31, 2000 kb/s, 30.00 fps(c) [04:48:44 CEST] <rue_house> there we go [04:50:30 CEST] <_merlim_> fflogger: https://arin.ga/H8YhCe/raw [04:51:50 CEST] <_merlim_> oh gosh found the problem, so ashamed I created a usr/bin/ script with the name of "cut" [04:52:04 CEST] <c_14> That'll do it [08:38:21 CEST] <maziar> please somebody help me [09:00:04 CEST] <retard> you're not making it easy [12:25:10 CEST] <jsodjfcn> cmd shows this message - "Using AVStream.codec to pass codec parameters to muxers is deprecated, use ACStream.codecpar instead". what does it mean ? [12:25:24 CEST] <BtbN> It means the tool you are using is deprecated API. [12:25:44 CEST] <jsodjfcn> so what to do now ? BtbN [12:25:47 CEST] <BtbN> nothing [12:26:02 CEST] <BtbN> It's just deprecated, not gone or broken. [12:26:17 CEST] <jsodjfcn> while joining twoo videos, second part video is not playing. its the message inbetween cmd window [12:27:04 CEST] <jsodjfcn> BtbN: ?? ^^^ [12:27:28 CEST] <BtbN> The message has no impact at all. It's just a warning to remind developers to migrate stuff. [12:28:06 CEST] <jsodjfcn> while joining the same 2 parts with an older version of ffmpeg, output plays fine, including 2part also [12:28:21 CEST] <jsodjfcn> 2nd* part [12:29:17 CEST] <jsodjfcn> BtbN: how to copy cmd output ? fflogger [12:29:30 CEST] <jsodjfcn> BtbN: ^^ [12:29:40 CEST] <BtbN> Just Copy&Paste it. [12:30:46 CEST] <jsodjfcn> BtbN: how to copy ? copy option is greyed out in right button click [12:31:07 CEST] <BtbN> No idea what kind of terminal you are using and how to handle it. [12:31:22 CEST] <BtbN> Can allways pipe it to a file and copy from that [12:31:36 CEST] <jsodjfcn> normal cmd inbuilt windows 7 [12:31:37 CEST] <BtbN> ffmpeg ... 2>output.txt [12:31:57 CEST] <BtbN> windows cmd can copy&paste just fine [12:31:59 CEST] <jsodjfcn> ok 2mins [12:32:08 CEST] <BtbN> you have to select text for the copy option to show up [12:32:43 CEST] <BtbN> On old Windows versions like Win7 you might have to manually enter selection mode from the menu, and then copy with return. [12:44:53 CEST] <jsodjfcn> BtbN: http://pastebin.com/CDr3zGrC [12:54:38 CEST] <TwinTailed> does anyone know what "forced frame type (3) at 2999 was changed to frame type (1)" means? [12:55:12 CEST] <jsodjfcn> BtbN: you there ? http://pastebin.com/CDr3zGrC [13:04:03 CEST] <BtbN> looks about right. There must be some issue with your input files. If it worked before, you can file a bug because it's a regression. [13:04:41 CEST] <jsodjfcn> you want input files link ? BtbN [13:05:10 CEST] <BtbN> Can't test right now. You can open a ticket on track with them. [13:05:34 CEST] <jsodjfcn> where and how ? [13:07:26 CEST] <BtbN> !trac [13:07:29 CEST] <BtbN> hm [13:07:32 CEST] <BtbN> trav.ffmpeg.org [13:07:44 CEST] <BtbN> or rahter, trac.ffmpeg.org ... [13:08:01 CEST] <jsodjfcn> BtbN: how to download rtmp and rtmpe streams with ffmpeg ? BtbN also how to pause cmd window after window full of coomands, many commands just vanish up [13:08:36 CEST] <jsodjfcn> while doing ffmpeg -help [13:08:49 CEST] <BtbN> pipe the output in a file if you only want to see the commands [13:08:55 CEST] <BtbN> or use | less [13:08:58 CEST] <BtbN> if that exists on windows [13:09:04 CEST] <BtbN> i think at least more does exist [13:10:52 CEST] <TwinTailed> BtbN: Do you know what causes MediaInfo to result "Duration_LastFrame: -20 ms" on an H264 MP4? [13:14:50 CEST] <jsodjfcn> BtbN: do one has to register for submitting a bug report ? [13:14:56 CEST] <BtbN> yes [13:16:49 CEST] <jsodjfcn> I have no account, you can register a new bug on my behalf [13:19:26 CEST] <TwinTailed> it takes less than a minute to register one [13:21:15 CEST] <jsodjfcn> TwinTailed: I dont want to register, if anything else, I'am ready to generate all the reports and transfer to you, if you are ok with submitting it [13:22:09 CEST] <TwinTailed> I am as lazy as you tbh [13:23:38 CEST] <jsodjfcn> TwinTailed: sorry, but I'm not lazy, generating bug reports and submitting them takes a lot of time than just registering an account, I'm ready for all the bug reports and works but just dont wanna register a new account [13:47:03 CEST] <TwinTailed> How do I fix "Duration_LastFrame: -20 ms"?? Why is there a delay? (I am using LibAV FFMPEG) [14:21:32 CEST] <mbarisa> hi guys, any idea how to propertly cut video from url, i am currently using "ffmpeg -ss 00:00:06.000 -i " + url + " -t 00:00:05.000 -c:a copy -c:v copy outputfile.mp4" [14:21:46 CEST] <mbarisa> i think keyframe is wrong, and it cuts it wrong.. [14:22:07 CEST] <mbarisa> any idea how to get it precise [14:24:14 CEST] <BtbN> mbarisa, if you want frame exact cutting, you have to re-encode [14:24:25 CEST] <BtbN> otherwise it can only cut at keyframes [14:24:45 CEST] <mbarisa> that is too expensive on mobile [14:25:00 CEST] <mbarisa> how would this line look with re-encoding? [14:25:13 CEST] <BtbN> don't copy, but specify any codec and its parameters you like. [14:26:29 CEST] <nonex86> mbarisa which codec you wonna cut? [14:26:42 CEST] <mbarisa> h264 [14:27:14 CEST] <nonex86> you need to frame precis cut from ffmpeg cli? [14:27:32 CEST] <s0126h> i love that i can just go to wiki and make changes [14:27:41 CEST] <mbarisa> nonex86: yeah, i think so [14:27:58 CEST] <mbarisa> any idea? [14:29:18 CEST] <nonex86> mbarisa, well, usually its possible to create "fast" cut of h264, reencoding just 1 or 2 gops, but not sure is it possible from ffmpeg cli [14:30:34 CEST] <mbarisa> i think the issue is with audio/video sync for me [14:30:42 CEST] <mbarisa> so maybe it is not ffmpeg issue [14:31:07 CEST] <nonex86> usually its better to reencode audiostream [14:31:19 CEST] <nonex86> its pretty fast [14:31:35 CEST] <nonex86> and you can position the audio depending of the video frame start [14:32:13 CEST] <nonex86> once again - i dont use ffmpeg cli, i just used ffmpeg api in my software [14:32:23 CEST] <nonex86> wich able to cut/merge h264 streams [14:32:38 CEST] <BtbN> audio does not have a gop inverval that makes cutting hard [14:32:40 CEST] <BtbN> so there [14:32:44 CEST] <nonex86> *which [14:32:47 CEST] <BtbN> 's usually no need to eneocode it [14:33:44 CEST] <TwinTailed> How do I fix "Duration_LastFrame: -20 ms"?? Why is there a delay? (I am using LibAV FFMPEG) [14:33:50 CEST] <nonex86> thats if you can tolerate some stream start difference [14:33:58 CEST] <nonex86> between audio and video [14:34:13 CEST] <nonex86> i perefer to have audio stream start == video stream start :) [14:34:35 CEST] <BtbN> that makes no sense, the worst difference there could be is one audio frame [14:34:41 CEST] <BtbN> which is a couple thousand samples at max [14:34:46 CEST] <BtbN> so, way less than a second [14:35:02 CEST] <nonex86> maybe you right [14:35:44 CEST] <BtbN> And it won't go out of sync. Just start the audio or video late [14:35:53 CEST] <BtbN> Provided the player is somewhat sane [14:36:08 CEST] <nonex86> agree, its the player problem to get it in sync [15:27:08 CEST] <TwinTailed> Is it normal to get AVERROR(EAGAIN) for a few loops when decoding, encoding and then writing to format context? [15:27:32 CEST] <BtbN> that's the whole point of that error code. [15:27:36 CEST] <DHE> if you overfill or overdrain any portion of the pipeline, sure [15:27:51 CEST] <TwinTailed> after a few loops with AVERROR(EAGAIN) coming from avcodec_receive_packet, i then start receiving packets normally [15:28:14 CEST] <TwinTailed> so that doesn't cause a delay? [15:28:24 CEST] <BtbN> most decoders and encoders have a delay, to re-order packages and better fill their pipeline [15:28:31 CEST] <flux> twintailed, you mean you don't call avcodec_sennd_frame in between? [15:28:35 CEST] <DHE> ... that's the kind of behaviour I would expect from a non-blocking TCP socket, but I don't think the encoding pipeline is non-blocking [15:29:10 CEST] <BtbN> the usual flow is you send packets/frames until you get EAGAIN, and then you receive frames/packets until you get EAGAIN there. [15:29:45 CEST] <flux> btbn, is that better for the encoder if you do that instead of just calling them avcodec_send/receive and dealing with the return codes? [15:29:52 CEST] <flux> (or does it matter?) [15:30:19 CEST] <BtbN> currently it does not matter, as there is not a single encoder implementing that new API [15:30:29 CEST] <BtbN> so it gets mapped to the one-in one-out API internally anyway [15:30:31 CEST] <flux> well I suppose one should call the receive function at least until it returns the EAGAIN [15:30:41 CEST] <flux> btbn, but in future then perhaps? [15:30:42 CEST] <TwinTailed> my loop continue; after it receives the AVERROR EAGAIN [15:30:48 CEST] <TwinTailed> does it cause any delay? [15:30:59 CEST] <TwinTailed> because my video is 20ms shorter than it should be [15:31:05 CEST] <BtbN> specially hardware encoders are a lot more efficient if they have time to process multiple frames in parallel [15:31:25 CEST] <flux> btbn, but would such a hardware just require that it has n frames lookahead, until you terminate the stream? [15:31:49 CEST] <BtbN> at least nvenc does not require that at all [15:31:58 CEST] <BtbN> it just gets like 200 times faster if you give it time [15:32:24 CEST] <flux> twintailed, in a sense it causes lag, because you didn't get an encoded frame for a decoded one, the resulting video file should however contain one frame per one input frame [15:32:42 CEST] <flux> twintailed, that the file is 20 ms shorter could be due to other reasons. do you have the same number of frames? [15:32:56 CEST] <TwinTailed> flux: yes same number of frames [15:33:11 CEST] <flux> in that case it's all fine. [15:33:28 CEST] <TwinTailed> flux: when I receive AVEAGAIN should I send NULL inputs or continue normally? [15:33:36 CEST] <flux> twintailed, continue normally [15:33:43 CEST] <BtbN> sending NULL signals EOF [15:33:44 CEST] <flux> twintailed, you're not terminating the stream there are you [15:33:54 CEST] <BtbN> and will terminate encoding/decoding [15:34:16 CEST] <TwinTailed> flux: I am "continue;"ing the loop [15:34:26 CEST] <TwinTailed> so the loop restarts [15:34:28 CEST] <BtbN> when you send a null packet, you will start getting EOF errors from the send function [15:34:35 CEST] <flux> twintailed, let's say it this way: if you DO send a null, you cannot send anything to the stream anymore [15:34:41 CEST] <BtbN> and receive will still give you frames, until it finally also ends with EOF [15:34:51 CEST] <TwinTailed> BtbN: well then I guess its not a problem and its not the main cause of delay [15:35:04 CEST] <flux> what do you mean by delay? [15:35:08 CEST] <TwinTailed> BtbN: Isn't that flushing what u're talking about? [15:35:11 CEST] <BtbN> There is no "delay" in the sense you are talking from. [15:35:15 CEST] <TwinTailed> the duration is 20ms shorter [15:35:15 CEST] <BtbN> That's EOF. [15:35:23 CEST] <flux> that's not a delay [15:35:29 CEST] <flux> that's a discrepency in the track lengths [15:35:44 CEST] <BtbN> sounds to me like you're not propperly handling EOF and missing the last frame. [15:35:53 CEST] <flux> you can use MP4Box -nhml or ffprobe -show_frames to see individual frame time stamps [15:36:02 CEST] <flux> I'm guessing there's a difference there compared to the original stream [15:36:05 CEST] <TwinTailed> BtbN: can i send u just the EOF snippet? [15:36:14 CEST] <TwinTailed> BtbN: a few lines of code only [15:36:16 CEST] <flux> or perhaps the original video has 20 ms no-frame-time at the beginning [15:36:34 CEST] <BtbN> Or it does weird stuff with the timestamps and starts at -20 [15:36:47 CEST] <TwinTailed> BtbN: http://pastebin.com/4iq5UqEV [15:36:50 CEST] <TwinTailed> thats how I EOF [15:37:08 CEST] <flux> if you have the same number of streams in both input and output, then the difference in the track lengths must be in the frame time stamps/durations/edit lists [15:37:24 CEST] <TwinTailed> flux: MediaInfo shows Duration_LastFrame: -20 [15:38:39 CEST] <TwinTailed> BtbN: am I EOFing right? [15:39:30 CEST] <flux> personally I would just loop until any non-zero return value is returned [15:39:49 CEST] <flux> but as I imagine that loop terminates, it's ok [15:40:32 CEST] <BtbN> TwinTailed, the first while loop might discard frames. [15:40:50 CEST] <BtbN> What if there are multiple frames to receive still? [15:41:07 CEST] <TwinTailed> BtbN: So I should remove it? [15:41:13 CEST] <TwinTailed> BtbN: The loop i mean [15:41:24 CEST] <BtbN> you are also not sending any frames to the encoder [15:41:34 CEST] <flux> you should have a loop. but the point is, what are you doing with the frames avcodec_receive_frame returns? [15:41:37 CEST] <BtbN> just a hardcoded null, even though there might still be frames in the pipeline [15:41:55 CEST] <BtbN> I'd say that's where your frames go missing [15:42:12 CEST] <flux> I think it might be easier to just replace that code with a state machine that on the first round sends the NULL, on the other round exits [15:42:18 CEST] <flux> and after the loop tou send NULL frame to the output [15:42:29 CEST] <BtbN> if avformat signals you EOF, you keep transcoding normaly. Just send NULL to the decoder, so it starts to go EOF itself. [15:42:43 CEST] <BtbN> When the decoders is EOF itself, you send EOF to the encoder [15:42:51 CEST] <BtbN> Until that goes EOF as well, then you are done. [15:43:00 CEST] <TwinTailed> BtbN: Ahaa [16:48:22 CEST] <itt788> where on the website of ffmpeg can i find informations about compiling and most importantly the list of dependencies it needs? [16:49:28 CEST] <pgorley> itt788: https://trac.ffmpeg.org/wiki/CompilationGuide [16:49:28 CEST] <tdr> https://trac.ffmpeg.org/wiki/CompilationGuide [20:20:20 CEST] <TwinTailed> BtbN: So after avformat sends EOF, I give avcodec_send_packet a NULL until avcodec_receive_frame returns EOF? After that I start giving avcodec_send_frame NULL in the same transcoding loop until avcodec_receive_packet returns EOF, then I exit? [20:21:34 CEST] <TwinTailed> BtbN: Or should I make a new loop for send_frame/receive_packet? [20:29:34 CEST] <DHE> one NULL to the send_packet is sufficient [20:33:10 CEST] <itt788> does the option --enable-libvo-amrwbenc need amrwb or opencore-amr with suffice? [20:38:15 CEST] <TwinTailed> DHE: But the next transcode loop will send normal packets [20:41:14 CEST] <shincodex> I reset stream on eof [20:41:51 CEST] <shincodex> freepacket -> avformat close avformatopen [20:42:07 CEST] <shincodex> same formatContext and inputFormat I opened with in beggining [20:42:13 CEST] <shincodex> hasnt blown up or leaked yet [20:42:38 CEST] <shincodex> Oh but i dont send or receieve packets heh [20:44:10 CEST] <DHE> you still need to reset the codec though, right? [20:48:24 CEST] <TwinTailed> DHE: To whom is this message? [22:18:12 CEST] <DelphiWorld> hey [22:18:30 CEST] <DelphiWorld> anyone know if is it pocible to use miracast & cromCast with vitamio player? [23:20:55 CEST] <zgreg> hey there, I see linker errors with libavutil. with VDPAU support compiled in, libavutil should link against libvdpau and libx11 [23:21:03 CEST] <zgreg> this was introduced by https://github.com/FFmpeg/FFmpeg/commit/38392b2af815898b8716826c4e29d95c04f… [23:21:38 CEST] <zgreg> so I think the pkg-config file should include these libraries. or am I missing something? [23:22:27 CEST] <zgreg> specifically, I see some failures to detect ffmpeg's VDPAU support in mpv because of this [23:43:12 CEST] <TwinTailed> BtbN: So after avformat sends EOF, I give avcodec_send_packet a NULL until avcodec_receive_frame returns EOF? After that I start giving avcodec_send_frame NULL in the same transcoding loop until avcodec_receive_packet returns EOF, then I exit [23:48:38 CEST] <TwinTailed> BtbN: I have made almost a state machine, but i am still getting delay/cut of 20ms [23:49:27 CEST] <flux> twintailed, so you send null exactly once dring the lifetime of the function [23:50:37 CEST] <TwinTailed> here is a loop which reads from the stream (avformat), and there is an int variable called "state", it is 0 by default, when avformat returns EOF, this is increased by one (once only), and if state is 1, it will avcodec_send_packet NULL only [23:51:51 CEST] <TwinTailed> and continue as usual, until avcodec_receive_frame returns EOF, then state is increased one, when its increased, avcodec_send_frame NULL is done once and the loop continues until avcodec_receive_packet is EOF [23:51:55 CEST] <TwinTailed> flux: ^ correct? [23:52:09 CEST] <flux> sounds right [23:52:31 CEST] <Venti> /window 20 [23:52:35 CEST] <TwinTailed> flux: i guess i have missed something, im still getting the delay/cut of 20ms [23:53:17 CEST] <flux> twintailed, but the thing is, you are not missing any frames. you said yourself that you have the same number of frames in input and output. and I very highly doubt a frame would somehow get duplicated to hide a dropped frame. [23:53:32 CEST] <TwinTailed> flux: thats the statemachine http://pastebin.com/bVgwyfgm [23:53:51 CEST] <TwinTailed> flux: the AV_LOG_DEBUG shows the frame number from the decoder [23:53:56 CEST] <TwinTailed> what if the encoder is not writing it? [23:55:04 CEST] <flux> twintailed, check the resulting file instead.. [23:55:26 CEST] <TwinTailed> I do [23:55:29 CEST] <flux> ffprobe -show_streams foo.mp4 |grep nb_frames [23:55:47 CEST] <TwinTailed> im on windows, no grep, but i will find u nb_frames [23:55:49 CEST] <TwinTailed> 1 sec [23:56:48 CEST] <flux> -show_frames will give you more information [23:57:13 CEST] <TwinTailed> flux: nb_frames=3021 [23:57:16 CEST] <TwinTailed> which is correct [23:57:53 CEST] <flux> so what is the timestamp of the first and last frames in the original and resulting video? [23:57:56 CEST] <TwinTailed> flux: ah found it [23:58:03 CEST] <TwinTailed> flux: its the sound stream with missing frames [23:58:09 CEST] <TwinTailed> flux: 1 frame missing from audio stream [23:58:21 CEST] <TwinTailed> nb_frames=5204 supposed to be 5205 [00:00:00 CEST] --- Sat Oct 1 2016

1 0