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

[burek]

[00:12:54 CET] <faLUCE> is there any test program for mpegts+h264+aac ?
[00:13:14 CET] <faLUCE> (I mean: test code example)
[01:12:39 CET] <obamoose> hello
[01:12:46 CET] <obamoose> how do I eternally loop a directory?
[01:13:04 CET] <obamoose> streaming*
[01:24:07 CET] <obamoose> anyone ;_;?
[01:25:45 CET] <Threads> would be helpful if you could explain abit more on what you want todo
[01:26:18 CET] <obamoose> https://ubuntuforums.org/showthread.php?t=2083105
[01:26:21 CET] <obamoose> basically this
[01:26:30 CET] <obamoose> but I'm looking for an ffmpeg-native solution
[01:26:46 CET] <obamoose> I'm streaming a directory using *.mp4
[01:26:53 CET] <obamoose> all files in that directory
[01:27:04 CET] <obamoose> But I want it to start over when the last file has finished playing
[03:33:21 CET] <Dark_Arc> I recently discovered that the Telegram messenger is not releasing its source code for their Android client, despite touting open source clients, and releasing under GPL. Said Android client is also statically linking against ffmpeg in violation of LPGL. What would be the best way to report this?
[03:37:05 CET] <Dark_Arc> This is the offending repo: https://github.com/DrKLO/Telegram
[03:37:27 CET] <Dark_Arc> Which is not up to date with the latest release https://play.google.com/store/apps/details?id=org.telegram.messenger&hl=en
[03:43:45 CET] <relaxed> Dark_Arc: open a bug report and state your findings
[06:46:33 CET] <thebombzen> Dark_Arc: if the code is GPLed then it can be statically linked against ffmpeg and comply with the LGPL
[06:46:43 CET] <thebombzen> the issue is that they're not distributing the source code
[08:00:10 CET] <lei-lhg> 	Hi,all.I was trying to build ffplay using bitbake. But it always complaint "SDL not found".
[08:00:11 CET] <lei-lhg> 	| DEBUG: Executing shell function do_configure
[08:00:13 CET] <lei-lhg> 	| ERROR: SDL not found
[08:00:14 CET] <lei-lhg> 	In fact,I have run "bitbake -c install libsdl" successfully, I don't know why ffmpeg say "sdl not found"
[08:00:16 CET] <lei-lhg> 	Did anyone have met this problem?
[08:00:17 CET] <lei-lhg> 	any advice and suggestions will be greatly appreciated
[08:12:11 CET] <aster__> what is libavresample? thanks
[08:17:01 CET] <cableguy> team
[08:17:12 CET] <cableguy> when trying no snatch something from the web with ffmpeg -i
[08:17:15 CET] <cableguy> why is it so slow
[08:17:22 CET] <cableguy> is it encoding at same time or something
[08:18:06 CET] <cableguy> i was snatching this 4k video from some .m3u that contained the video in partial .ts files
[08:18:14 CET] <cableguy> and it took 1h to snatch 20min video
[08:18:31 CET] <cableguy> im not following
[08:18:44 CET] <cableguy> no, its not the internet speed.
[10:56:15 CET] <BtbN> cableguy, are you just stream copying, or transcoding?
[10:56:28 CET] <BtbN> lei-lhg, ffplay needs SDL 2.
[10:59:10 CET] <cableguy> BtbN, idk i just want to dl it to my hdd but looks like its transcoding it while in process
[10:59:18 CET] <cableguy> so it takes too long
[10:59:30 CET] <cableguy> but why transcode raw files if i also want them raw
[10:59:44 CET] <BtbN> Because the default is to transcode
[10:59:54 CET] <BtbN> stream-copy is a special case.
[11:00:04 CET] <BtbN> Just add -c copy in front of your output, if you don't have it already.
[11:01:50 CET] <cableguy> uh u mean '-c copy -i'
[11:02:12 CET] <BtbN> It's an output option, not an input one.
[11:03:40 CET] <cableguy> the input is .m3u with multiple streams
[11:03:55 CET] <cableguy> does ffmpeg have a command like youtube-dl that lets to select which format u want to dl
[11:03:59 CET] <cableguy> like -f format_code
[11:04:08 CET] <BtbN> no, use youtube-dl for that.
[11:04:19 CET] <BtbN> youtube-dl can even call ffmpeg for you I think.
[11:04:23 CET] <cableguy> i tried using youtube-dl but it toggles ffmpeg instead
[11:04:32 CET] <cableguy> and then in which part i pass ffmpeg commands
[11:04:51 CET] <BtbN> there is no logic in ffmpeg to decypher the always varying magic all those video sites do
[11:04:54 CET] <BtbN> Would be insane to add
[11:04:58 CET] <BtbN> That's why youtube-dl exists
[11:06:11 CET] <cableguy> what im saying is that if i run youtube-dl it calls ffmpeg to download from that .m3u but like you said ffmpeg transcodes by default
[11:06:29 CET] <cableguy> so i cant put in ffmpeg commands in youtube-dl command line
[11:06:34 CET] <cableguy> the -c copy
[11:06:39 CET] <BtbN> I'm pretty sure youtube-dl correctly uses a stream copy.
[11:06:52 CET] <furq> it doesd
[11:06:53 CET] <furq> -d
[11:07:02 CET] <cableguy> whats -d
[11:08:18 CET] <cableguy> e.g.
[11:08:37 CET] <cableguy> youtube-dl http://stream.m3u -f 123
[11:08:40 CET] <cableguy> it calls ffmpeg
[11:08:44 CET] <cableguy> and ffmpeg starts transcoding
[11:08:50 CET] <cableguy> but i want copy
[11:08:54 CET] <BtbN> No it doesn't.
[11:08:57 CET] <cableguy> yes it does
[11:08:58 CET] <BtbN> It copies
[11:09:11 CET] <cableguy> frame=  361 fps= 58 q=-1.0 Lsize=   26505kB time=00:00:14.91 bitrate=14556.1kbits/s speed=2.39x
[11:09:17 CET] <cableguy> isnt this transcoding
[11:09:25 CET] <furq> no
[11:09:25 CET] <BtbN> No, that's the progress indicator.
[11:09:45 CET] <cableguy> so why its so slow
[11:09:49 CET] <cableguy> and speed drops beloe 0.5
[11:09:59 CET] <BtbN> Is anything else faster at downloading that stream?
[11:10:00 CET] <furq> is it using any cpu
[11:10:25 CET] <cableguy> yeah i can download at 10mb/s from that site e.g. mp4 files
[11:10:32 CET] <cableguy> youtube-dl downloads fast, ffmpeg is slow
[11:11:09 CET] <BtbN> What is the exact ffmpeg commandline?
[11:11:10 CET] <cableguy> ffmpeg is like at 1% cpu
[11:11:20 CET] <furq> yeah that's not transcoding
[11:11:34 CET] <furq> it's not unheard of for streaming sites to throttle live streams
[11:11:39 CET] <furq> although 0.5x sounds a bit suspicious
[11:11:42 CET] <cableguy> idk whats ffmpeg cli youtube-dl just calls it
[11:11:49 CET] <BtbN> look it up
[11:11:55 CET] <BtbN> should be in ps aux while it's running.
[11:12:13 CET] <cableguy> let me make screenshot
[11:12:22 CET] <BtbN> it's plain text... just copy it
[11:12:55 CET] <furq> youtube-dl -v will print the ffmpeg command line
[11:14:48 CET] <cableguy> http://i.imgur.com/t0SX5Qt.jpg
[11:15:00 CET] <BtbN> Why do you take a picture... of text?!
[11:15:10 CET] <furq> also text that doesn't contain the command line
[11:15:16 CET] <BtbN> also, the command line is not in there
[11:15:52 CET] <furq> when you say "10mb/s" do you mean 10MB/s or 10mbps
[11:15:54 CET] <cableguy> u mean
[11:15:58 CET] <cableguy> -i /playlist.m3u8' -c copy -f mp4 -bsf:a aac_adtstoasc file:master-master.mp4.part
[11:16:04 CET] <furq> if it's the latter than that video is 15mbps, so that's not really a mystery
[11:16:10 CET] <cableguy> 10mb/s as in 100mbit
[11:16:39 CET] <BtbN> Is that a live stream?
[11:16:42 CET] <cableguy> no
[11:16:53 CET] <BtbN> It will download however fast the server can sustain then
[11:16:58 CET] <BtbN> And your Internet Connection, that is
[11:17:11 CET] <cableguy> well its 10 faster from save server with youtube-dl or browser or whatever
[11:17:18 CET] <cableguy> but ffmpeg is x10 times slower
[11:17:24 CET] <cableguy> and speed constantly dropping
[11:18:42 CET] <cableguy> e.g. i can download same file from same server in e.g. mp4 extension with e.g. youtube-dl and its fast 10mb/s, but when it comes to .m3u source and it calls ffmpeg in same server its slow and drops under 0.5
[11:20:02 CET] <BtbN> ffmpeg can easily download m3u8 sustaining my 200Mbit/s downstream for me. It's something on your end. Like slow disk, slow connection, or both
[11:20:23 CET] <cableguy> its ssd
[11:20:33 CET] <cableguy> and 100/100
[11:20:56 CET] <cableguy> like i said everything is fast except when it comes to ffmpeg downloading same file from same server but from .m3u
[11:21:16 CET] <BtbN> So it's not the same file, but an m3u playlist?
[11:21:40 CET] <BtbN> ffmpeg -i "http://sample.vodobox.net/skate_phantom_flex_4k/skate_phantom_flex_4k.m3u8" -c copy out.mp4
[11:21:54 CET] <BtbN> that easily uses up all available downstream bandwidth for me.
[11:22:55 CET] <cableguy> frame=  998 fps= 39 q=-1.0 size=   33708kB time=00:00:40.03 bitrate=6898.1kbits/s speed=1.55x
[11:23:49 CET] <cableguy> thats from ur link
[11:26:53 CET] <cableguy> it starts at speed 7x and constantly dropping till 0.5
[11:27:50 CET] <cableguy> but if u open that .m3u and download one .ts chunk from browser or whatever no problem quick and fast
[11:27:54 CET] <cableguy> while ffmpeg is choking on it
[11:29:23 CET] <BtbN> of course on chunk is fast, any kind of throtheling will kick in much later.
[11:30:03 CET] <BtbN> It runs at a constant 2-2.5x speed for me, around 7Mbps
[11:41:23 CET] <cableguy> alright
[11:50:57 CET] <jubalh> So I have amazon prime, and they have some nice series. But I cannot watch them on my kodi media station. Now I think about downloading them somehow. it seems there is a lib that can decode the drm stuff but noone implemented anything with it yet?
[11:51:01 CET] <jubalh> https://github.com/rg3/youtube-dl/issues/1753
[11:51:19 CET] <jubalh> kind of offtopic to ffmpeg but maybe someone in here knows about it
[11:51:40 CET] <jubalh> since also with audible ffmpeg could help to decode the thing with the activation bytes
[11:51:59 CET] <BtbN> Amazons DRM is not broken, if that's your question.
[11:52:06 CET] <BtbN> And if it was, they'd probably quickly fix it.
[11:55:39 CET] <jubalh> tbh I dont know how this works but to play the video in firefox and chromium etc i guess those browsers have to encrypt the stream
[11:55:55 CET] <jubalh> since those are open source i thought that the same technique could be used by other applications?
[11:57:32 CET] <BtbN> They download a binary blob from the server, that then decrypts the stream and opens a protected channel to the graphics card, to ensure nothing can intercept the video on its way there.
[11:58:21 CET] <BtbN> best bet at capturing those streams is an HDMI capture card with an HDCP stripper in front of it.
[11:59:14 CET] <jubalh> what? it works like that. i had no idea. i would prefer not having such binaries here.. good thing i didnt install the plugin yet
[11:59:29 CET] <BtbN> Browses don't need a plugin for that anymore
[11:59:52 CET] <jubalh> or enabled that feature
[12:00:29 CET] <BtbN> Chrome recently decided that it should not be possible to disable it anymore iirc
[12:01:23 CET] Action: jubalh uses Firefox
[12:01:32 CET] <jubalh> with what reasoning?
[12:02:40 CET] <BtbN> http://www.tomshardware.com/news/chrome-57-permanently-enabled-drm,33527.html
[12:06:20 CET] <jubalh> interesting, thanks
[12:11:58 CET] <cableguy> that top comment tho
[12:39:17 CET] <furq> 10:51:59 ( BtbN) Amazons DRM is not broken, if that's your question.
[12:39:21 CET] <furq> it has been broken and they did quickly fix it
[15:11:17 CET] <kcghost> I have a quick question regarding the "tune" option in x264: https://trac.ffmpeg.org/wiki/Encode/H.264
[15:11:40 CET] <kcghost> For presets it says "you will simply save bitrate by choosing a slower preset."
[15:12:08 CET] <kcghost> Does the same logic hold true for the tune parameter? e.g. When using crf 18?
[15:12:22 CET] <kepstin> kcghost: most of the tune options are just minor tweaks to help with certain types of content, that hurt other types of content
[15:12:40 CET] <kepstin> (exceptions are psnr, ssim, zerolatency which are only used in special cases)
[15:13:00 CET] <kepstin> if you don't know why you might want to use a tune, you probably don't want to use a tune. The defaults are generally ok for most stuff.
[15:14:43 CET] <kcghost> I was thinking of attempting to autodetect a proper tune. If the constant quality logic is true, then tune only affects filesize, and you could try a clip at different tunes and go with the one with the smallest size.
[15:14:53 CET] <furq> it isn't
[15:15:04 CET] <furq> film will generally increase bitrate, and grain will increase it even more
[15:15:37 CET] <furq> animation will generally reduce bitrate (iirc) but it'll do so for live-action content as well
[15:15:41 CET] <furq> which will make it look worse
[15:15:59 CET] <kcghost> Good to know, thanks
[15:19:47 CET] <furq> at crf 18 it might not be worth worrying about
[15:19:54 CET] <furq> obviously given enough bitrate the tuning makes no difference
[15:20:19 CET] <furq> it's just a way of biasing the bitrate allocation you do give it in a particular way
[15:23:03 CET] <kcghost> Ah, so at crf 18 only the presets would affect the filesize and not tune? Or just that tune would make a very small difference at crf 18?
[15:23:27 CET] <furq> tune will make less difference at lower crf
[15:23:40 CET] <furq> it'll probably still be noticeable at 18, i've never checked
[15:23:55 CET] <furq> obviously at -qp 0 then it makes no difference at all because that's lossless regardless
[15:24:29 CET] <furq> it definitely makes a noticeable difference at 20, and i've never really touched anything lower
[15:25:26 CET] <user128> hi, I am looking at https://github.com/FFmpeg/FFmpeg/blob/master/ffplay.c but I can't figure out the part where the audio is actually send to SDL for playing. any tips?
[15:43:32 CET] <BtbN> user128, i don't think it sends audio to SDL
[16:04:22 CET] <user128> BtbN, I see. I wonder how ffplay is sending audio to the sound card. I see calls to "pa_stream_write" in the debugger but I don't see them in ffplay source. need to spend more time looking at source!
[16:04:38 CET] <user128> pa_stream_write is pulseaudio api function
[16:04:40 CET] <BtbN> It'll probably just use lavd
[16:07:12 CET] <user128> debugger says calls to pulseaudio functions are coming from PULSEAUDIO_PlayDevice <- SDL_RunAudio. so sdl does seem to be involved in the audio playback.
[16:07:52 CET] <BtbN> So if you have a trace, you can just see where it comes from
[16:08:51 CET] <user128> the problem is that this takes places in a different thread, I can see the ffplay code involved clearly. I will debug more, thanks!
[17:49:35 CET] <mabynogy> hello
[19:16:36 CET] <obamoose> Hello
[19:16:54 CET] <obamoose> I'm using a 'while do do done' loop to loop a directory
[19:17:03 CET] <obamoose> but it stops and starts a new stream every time it's done with a file
[19:17:14 CET] <obamoose> can't I make it a single full stream?
[19:25:21 CET] <BtbN> If the files are similar enough, you can just use a concat last as input
[19:27:49 CET] <obamoose> extension similar?
[20:05:35 CET] <MR-2> Hello
[20:05:40 CET] <MR-2> :)
[20:07:49 CET] <MR-2> how can i fix malformed pts/dts issues on a mp4. Last 35mins of it is dumped in the last 1-2sec right now:/
[20:07:52 CET] <MR-2> ?
[20:20:32 CET] <c3r1c3-Win> MR-2: Did you try a simple remux?
[20:29:43 CET] <MR-2> i have tried -c copy
[20:31:58 CET] <MR-2> don't work
[20:33:41 CET] <MR-2> really weird issue:/
[20:34:54 CET] <MR-2> first 90min works great but then te last 1-2sec has like 30-35min smoshed into it
[20:50:36 CET] <Spring> is there anything I should keep in mind to always ensure proper audio sync when encoding to h264? I've realized the method I've been using produces out of sync audio /slightly/
[20:54:36 CET] <Spring> looking at the ffmpeg encoding options that I added to the metadata for reference I used both -ss/-to and -filter_complex with trim/atrim (set to the same beginning/end values).
[20:55:07 CET] <BtbN> If your inputs have proper timestamps, there's usually nothing you have to do.
[20:56:57 CET] <Spring> BtbN, any idea why h264 in particular has slightly off-sync'd audio, while libvpx doesn't using the same trim method described above?
[20:57:32 CET] <BtbN> h264 is a video codec, it is not involved with audio.
[20:58:24 CET] <BtbN> I'd guess h264 uses re-ordering, while VP9 doesn't, and the delay introduced by that clashes with your wonky input timestamps
[20:58:40 CET] <Spring> sorry, should have specified, Mp4 with h264 and (vanilla) 'aac' for the audio
[20:58:58 CET] <BtbN> to test, add -tune zerolatency to libx264, that disables any reordering and delays
[20:59:12 CET] <JEEB> as long as your input timestamps are OK and you are not funkying with the timestamps that come from the encoders
[20:59:16 CET] <JEEB> mp4 should be OK
[20:59:22 CET] <JEEB> it should even have the audio encoder delay
[20:59:41 CET] <JEEB> like, noted in the file. whether your player or whatever is decoding it reads it correctly is a separate thing
[21:00:33 CET] <Spring> in this case I was taking the A and B trim timecodes from a video player (HH:MM:SS.MSS) for the timestamp values of the trims to give to ffmpeg.
[21:00:57 CET] <BtbN> what?
[21:01:25 CET] <BtbN> just don't mess with the timestamps unless they are broken, and stuff will just work
[21:01:56 CET] <Spring> eg: -ss 00:02:44.641 -to 00:03:40.893 -filter_complex [0:v]scale=iw:ih,trim='00\:02\:44.641':'00\:03\:40.893'[v];[0:a]atrim='00\:02\:44.641':'00\:03\:40.893'[a] -map [v] -map [a]
[21:07:26 CET] <Spring> hmm, maybe it's the source and I'm mistaking the lip syncing as being off. Will need to test with more sources.
[21:11:54 CET] <BtbN> why are you adding the trim and atrim filters?
[21:13:49 CET] <CptnOblivious> Hello, I'm trying to record a live stream but I'm getting errors every few minutes saying segments skipped. The video plays back but those skipped segments cause audio to stop through playback. Is there anyway to clean the file up?
[21:15:29 CET] <Qas> hello everyone, I am using this command 'for f in *.flv; do ~/Downloads/ffmpeg-3.2.4-64bit-static/ffmpeg -i "$f" "${f%.*}.mp4"; done' in order to bulk convert flv files into mp4, but I get an error that says '*.flv: no such file or directory'.
[21:16:36 CET] <Qas> sorry I will reconnect
[21:16:54 CET] <Spring> BtbN, I believe it was as it was more accurate and the -ss/-to was to speed up skipping to the desired start point, or something like that. The complex filter also bit gets optional parts added to as necessary, some of which need the trim/atrim filter.
[21:17:44 CET] <Qas> back again
[21:18:05 CET] <BtbN> Qas, no -c copy?
[21:18:15 CET] <BtbN> Also, your shell wants to tell you there there are no .flv files to be found.
[21:18:26 CET] <Qas> BtbN, but there are.
[21:18:51 CET] <Qas> I mean, I wanted to search recursively all subfolders, and there are flv files in them
[21:18:55 CET] <BtbN> Your shell disagrees, and is usually right about that.
[21:19:08 CET] <BtbN> that's not what you told your shell to do
[21:19:18 CET] <BtbN> you told it to enumerate all files ending in .flv in the current directory.
[21:19:38 CET] <Qas> I want to convert them to mp4
[21:20:23 CET] <BtbN> you should add -c copy and -movflags faststart for that
[21:22:33 CET] <Qas> so, like 'for f in *.flv; do ~/Downloads/ffmpeg-3.2.4-64bit-static/ffmpeg -i -c -movflags "$f" "${f%.*}.mp4' ?
[21:26:35 CET] <Qas> that returns error, too
[21:27:42 CET] <Qas> could anyone help me with the right command please? I dont know why it doesnt work now, last time it didi
[21:27:45 CET] <Qas> did*
[21:33:04 CET] <BtbN> Because there are no .flv files in the directory where you run it
[21:33:20 CET] <BtbN> Also you forgot half of the arguments I mentioned
[21:33:46 CET] <BtbN> and put them in a strange place...
[21:36:07 CET] <Qas> then where is the right place?
[21:36:41 CET] <BtbN> not between -i and the input file...
[21:37:02 CET] <BtbN> But still after -i, as they are output options
[21:39:02 CET] <Qas> to make it clear, I dont know a thing about all these commands. I got them here and there and it worked before. therefore I dont know where to put them. if someone can tell it to me straight away, I'd be thankful. that's why I am here
[21:41:53 CET] <BtbN> Well, I told you two times now why the original command does not work.
[21:42:04 CET] <BtbN> There simply are no .flv files where you are running it
[22:11:13 CET] <Qas> I am running it in directory1. and directory1 has subdirectories which contain flv files, which is what I wanted to do; apply the command to all subdirectories.
[22:11:39 CET] <__jack__> how deep is the tree ?
[22:11:47 CET] <Qas> 2-3 levels
[22:12:07 CET] <__jack__> use find -iname "*.flv" -exec ffmpeg -i {} blablabla \;
[22:12:27 CET] <Qas> I'd like to convert flv to mp4
[22:14:25 CET] <__jack__> use find -iname "*.flv" -exec ffmpeg -i {} -c copy -movflags faststart {}.mp4 \;
[22:19:46 CET] <hiihiii> Hello. What's the proper wat to encode libx264 in RGB? I know about libx264rgb and have done it once but still do not know what are the sufficient switches to do it
[22:21:12 CET] <furq> that is the switch to do it
[22:21:46 CET] <__jack__> you're welcome qas ..
[22:22:28 CET] <hiihiii> furq: so nothing else other than -c:v libx264rgb is needed?
[22:22:38 CET] <hiihiii> ok thx
[22:24:16 CET] <hiihiii> now should I switch to using RGB or stick to YUV? I'm not sure what is the pros or cons that RGB might bring?
[22:26:30 CET] <BtbN> Well, I kind of like most players being able to play the video I encode.
[22:26:47 CET] <BtbN> h264 with rgb in it will probably cause quite a mess
[22:27:11 CET] <Qas> sorry, I was instantly cut off as I had a machine problem.
[22:30:24 CET] <hiihiii> BtbN: not really sure about that but ok
[22:35:46 CET] <furq> rgb is a bit bigger in my experience
[22:37:15 CET] <BtbN> than yuv444?
[22:37:27 CET] <furq> yeah
[22:37:35 CET] <hiihiii> the only thing I know is that yuv is better in terms of compression
[22:37:47 CET] <BtbN> yuv420 is obviously smaller
[22:38:05 CET] <BtbN> But for 444 it's just a matter of how well the algorithm handles it
[22:38:20 CET] <hiihiii> they feel as they if they have a yellow tint no?
[22:38:27 CET] <BtbN> no?
[22:39:12 CET] <hiihiii> idk I did some clips with yuv and then rgb. rgb came on top because of that yellowish tint yuv had
[22:39:25 CET] <furq> sounds like something's fucking up the conversion
[22:39:27 CET] <furq> or your player sucks
[22:39:51 CET] <thebombzen> yuv444p should work just as well as rgb24 in theory
[22:40:06 CET] <thebombzen> but I can imagine an encoder having better algorithms for yuv than rgb
[22:40:39 CET] <hiihiii> I still have those clips if you like a screen shot
[22:41:16 CET] <hiihiii> yuv was done with sony vegas' youtube preset
[22:42:17 CET] <furq> that sure sounds like something that'd fuck up a colourspace conversion
[22:43:22 CET] <hiihiii> rgb was done with ffmpeg
[22:43:46 CET] <hiihiii> I don't think my player sucks be cause I can play the clip in raw
[22:44:20 CET] <hiihiii> the ffmpeg clips were closer to the colors of raw than vegas' yuv clips
[22:46:44 CET] <hiihiii> vega's out put :
[22:47:22 CET] <hiihiii> https://thepasteb.in/p/xGhmkqQy116FM
[22:47:32 CET] <hiihiii> ffmpeg's output:
[22:47:38 CET] <hiihiii> https://thepasteb.in/p/KOh8Oxrl1BptJ
[22:47:53 CET] <hiihiii> oh it was yuv420 for vegas
[22:49:40 CET] <furq> do both with ffmpeg if you want to compare
[22:50:01 CET] <furq> vegas isn't even using the same encoder
[22:50:49 CET] <hiihiii> I might do that some day
[22:51:01 CET] <hiihiii> i don't have enoug time today
[22:51:13 CET] <hiihiii> but even with diff encoders
[22:51:26 CET] <hiihiii> the algorithms are similar no?
[22:51:27 CET] <furq> i mean the encoder shouldn't make a difference because that doesn't do the conversion
[22:51:57 CET] <furq> but if you're noticing a colour shift after an rgb to yuv conversion then it's probably a bad conversion
[22:52:17 CET] <furq> yuv444 and rgb should very rarely look perceptibly different
[22:52:39 CET] <hiihiii> okay I'll just run some tests tomorrow and see what's on
[22:52:49 CET] <hiihiii> take care
[23:50:25 CET] <nyuszika7h> even if I do -r 25 on input and output, and -x264-params 'force-cfr=1', MediaInfo insists that the output file is variable frame rate
[23:50:52 CET] <JEEB> you'd have to see what mediainfo actually reads for that information
[23:51:29 CET] <JEEB> with some containers it has some weird ideas of what's CFR and what's not
[23:51:58 CET] <JEEB> if you absolutely need to know, you actually use a timestamp tool to extract the timestamps from the container
[23:52:49 CET] <nyuszika7h> well, it seems to be fine but I don't know why it thinks it's VFR
[23:53:22 CET] <JEEB> you can just confirm it from the timestamps as I said, whatever mediainfo says being secondary
[23:53:34 CET] <JEEB> if you see that the timestamps are monotonically rising
[23:53:42 CET] <JEEB> then that's CFR no matter how you look at it
[23:55:08 CET] <thebombzen> if you use force-cfr=1 with x264 it probably will encode the H.264 bitstream as cfr but if it's muxed as vfr then you're SOL
[23:55:15 CET] <thebombzen> what happens if you use -vsync cfr
[23:55:34 CET] <thebombzen> that'll tell the muxer that it's cfr, whereas x264-params is an encoder thing, not a muxer thing
[23:56:05 CET] <JEEB> well first of all I recommend seeing if he has a problem at all
[23:56:13 CET] <JEEB> before sticking more params at it
[23:56:16 CET] <thebombzen> lol
[23:56:37 CET] <thebombzen> I thought the problem was "I need mediainfo to report cfr"
[23:56:41 CET] <thebombzen> otherwise /shrug
[23:56:51 CET] <JEEB> mediainfo can be a very useful tool but you cannot trust its heuristics blindly
[23:57:03 CET] <JEEB> and he already had -r 25 on both sides of his chain it seems
[23:57:07 CET] <thebombzen> hm
[23:57:08 CET] <nyuszika7h> well it's not a big deal because I can't see any issues with the output file, I'm just trying to find out why
[23:57:10 CET] <JEEB> so any input timestamps would have already gotten rewritten
[23:57:34 CET] <thebombzen> sure, but afaik by default ffmpeg.c will use vfr for vfr containers even if it ends up being cfr
[23:57:34 CET] <JEEB> nyuszika7h: plain and simply if the timestamps are monotonically rising then mediainfo's just plain wrong
[23:57:43 CET] <thebombzen> monotonically increasing?
[23:57:48 CET] <thebombzen> that just means nondecreasing
[23:57:52 CET] <thebombzen> doesn't mean cfr
[23:57:58 CET] <JEEB> well derivate being stable I mean
[23:58:07 CET] <JEEB> as in, monotonic amount of rise between samples :P
[23:58:17 CET] <thebombzen> still doesn't mean cfr
[23:58:30 CET] <JEEB> ok, so how the fuck else do you define CFR then?
[23:58:34 CET] <thebombzen> the word monotonic has nothing to do with this
[23:58:39 CET] <JEEB> if all timestamps have monotonically rising timestamps
[23:58:45 CET] <thebombzen> that's not what monotonic means
[23:58:48 CET] <JEEB> ok
[23:58:59 CET] <thebombzen> https://en.wikipedia.org/wiki/Monotonic_function
[23:59:09 CET] <JEEB> if each sample has exactly the same duration
[23:59:11 CET] <JEEB> there
[23:59:29 CET] <thebombzen> I mean the easiest way to describe it is the difference between consecutive timestamps is constant
[23:59:50 CET] <JEEB> yes, that's another word for duration
[00:00:00 CET] --- Sun Mar 19 2017