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

[burek]

[01:28:24 CEST] <jleclanche> I'm trying to record a video with a usb webcam on my laptop, but it's coming out kind of unreliable (always broken halfway through). This is the command line I use: `ffmpeg -f v4l2 -video_size 1920x1080 -i /dev/video1 out.mkv` -- my question: is there a way to stream the raw feed to disk, and do the conversion to mkv later?
[01:29:33 CEST] <DHE> you can put "-c copy" before the output file
[01:30:22 CEST] <jleclanche> perfect!
[01:30:23 CEST] <jleclanche> thank you
[01:30:41 CEST] <DHE> the file format doesn't determine CPU usage. it's the codec
[01:31:23 CEST] <jleclanche> DHE: I'm not sure how to tune this to come out reliably is the thing. If I have the raw feed then at least i can mess with it later and i dont have to rerecord
[01:31:35 CEST] <jleclanche> but if you have a suggestion on tuning this so it comes out good, I'm all ears
[01:32:13 CEST] <DHE> start with my suggestion. it may produce a large file but still .mkv. then you can edit that however you want
[01:32:24 CEST] <jleclanche> Yes, I'm using that now, it's perfect :)
[01:32:32 CEST] <DHE> lacking details I'm making assumptions here though. so give it a spin first and see how it goes
[01:32:42 CEST] <jleclanche> just did, it works well
[01:43:16 CEST] <spot> Hello, is anybody here?
[01:43:51 CEST] <TheAMM> Just 417 users plus some +v and ops
[01:46:40 CEST] <spot> OK then. I have developed a set of settings for Handbrake which accomplishes exactly what I want, which is to convert .ts files downloaded from my TiVo unit, to .mkv files suitable for playing in one corner of my computer screen. If I post the complete set of these Handbrake settings, can someone please tell me what the equivalent ffmpeg settings will be, to incorporate into a script, so I don't need to start Handbrake?
[01:51:19 CEST] <spot> I take silence to mean yes. Here are the settings: Auto Crop off, Loose Crop unchecked, 0-0-0-0, Optimal for Source unchecked, 722, 406, Anamorphic off, Alignment 2, Keep Aspect checked.
[01:51:29 CEST] <spot> Detelecine off, Interlace Detection off, Deinterlace Yadif, Deinterlace preset Bob, Deblock off, Denoise Filter Off
[01:51:40 CEST] <spot> H.264, Framerate 59.94, Constant, Bitrate 4160, 2-Pass encoding, Turbo first pass unchecked, preset placebo, Tune none, Profile high, Level 4.1, fast decode unchecked.
[01:51:52 CEST] <spot> ref=4:bframes=1:b-pyramid=none:weightp=1:8x8dct=1:me=umh:subme=9:merange=16:direct=auto:b-adapt=2:trellis=2:aq_mode=1:aq_strength=1:psy_rd=1.00,0.15:fast_pskip=0:deblock=0,0:dct-decimate=0:keyint=600:keyint_min=120:rc_lookahead=120:sync_lookahead=120:qcomp=0.45:non-deterministic=1:qpmin=0:qpmax=30:qpstep=5:analyse=i4x4,i8x8:chroma_qp_offset=-1:nr=1
[01:52:06 CEST] <DHE> placebo? really?
[01:52:21 CEST] <spot> That's all. What CLI lines for a 2-pass ffmpeg encode will equate to this set of Handbrake settings?
[01:52:33 CEST] <TheAMM> I don't know what the files look like
[01:53:21 CEST] <spot> Input is .ts files downloaded (via kmttg) from my TiVo unit, they're 1920x1080. Output is 722 x 406 .mkv.
[01:53:34 CEST] <TheAMM> Audio?
[01:54:13 CEST] <TheAMM> Are you sure you want 2-pass?
[01:54:29 CEST] <spot> AC3, bitrate 160, Dolby Pro Logic II mixdown, samplerate same as source, gain 0db, drc off, passthru aac
[01:55:21 CEST] <spot> Yes, 2-pass, it produces perfect results. What I am doing is transcribing CNBC daytime shows. I have not found a 1-pass set of settings which makes the ticker across the bottom run smoothly. Two-pass works fine.
[01:55:57 CEST] <TheAMM> 2-pass should not affect framerate at all
[01:56:23 CEST] <spot> Works fine, that is, with the above settings in Handbrake. I'd like to automate the process with a script called from within kmttg. But to do so, I need to know what the CLI commands are for an ffmpeg 2-pass transcription.
[01:56:26 CEST] <TheAMM> Not even decoding speed, if you think your machine would lag on the video
[01:57:24 CEST] <TheAMM> So filesize is not an issue per se?
[01:57:24 CEST] <spot> I did a lot of trial-and-error to come up with these Handbrake settings, they work. Machine is a dual E5-2696 v3 Xeon.
[01:57:49 CEST] <TheAMM> You just want something that'll play in the corner of your screen, right?
[01:58:35 CEST] <spot> I am reducing a 10 GB input .ts to a 4GB output .mkv, that's good enough.
[01:59:23 CEST] <spot> Output is a 722x406 .mkv file. I have a 24-inch 16:9 monitor so it's plenty good enough.
[02:01:40 CEST] <spot> I have found that I can reduce bitrate by half with only slight reduction in video quality, but storage space is not so pressing an issue that I need to be so miserly with kbps.
[02:02:55 CEST] <TheAMM> What are you playing the fiels with?
[02:03:00 CEST] <TheAMM> files*
[02:03:17 CEST] <spot> I am playing the files on the same computer I am encoding them on.
[02:04:08 CEST] <TheAMM> I mean are you using vlc, mpv, something else
[02:04:17 CEST] <furq> yeah there is absolutely no way that 2-pass affects the smoothness of a ticker
[02:04:24 CEST] <furq> the only thing that'd affect that is your deinterlacing method
[02:04:52 CEST] <spot> Well, I tried everything I could think of in 1-pass and the results were not as good as I can achieve with 2-pass.
[02:04:59 CEST] <TheAMM> Something like 'ffmpeg -i in.ts -vf yadif,scale=722:406 -c:b libx264 -b:v 2500k -preset ultrafast -b:a 144k out.mkv' should maybe work
[02:05:04 CEST] <spot> Usually I use vlc, but sometimes smplayer or xine.
[02:05:17 CEST] <TheAMM> It should be a whole lot faster than the 2-pass
[02:05:21 CEST] <furq> yeah don't do that
[02:05:40 CEST] <TheAMM> Raise the bitrate if it's too low, and if you don't need deinterlacing drop the "yadif,"
[02:05:59 CEST] <furq> if this is from a tv capture box then i assume it can be guaranteed to be 50i
[02:06:38 CEST] <furq> -i foo.ts -vf yadif=1,scale=722:-2 -c:v libx264 -crf 18 -preset veryslow -c:a copy bar.mkv
[02:06:45 CEST] <furq> would be my quick suggestion
[02:07:04 CEST] <furq> not entirely sure why you've picked 722 for width but nvm
[02:07:35 CEST] <spot> OK I will try these 1-pass suggestions. But I would still like to know what the exact ffmpeg 2-line 2-pass equivalent would be.
[02:08:01 CEST] <spot> 722 uses up approximately 1/4 of my screen, it leaves enough room for a browser in the rest of the screen.
[02:08:08 CEST] <TheAMM> There are a lot of unnecessary options in the dump you posted, spot
[02:08:21 CEST] <TheAMM> And you should be able to resize your video player
[02:08:40 CEST] <furq> actually i'm not sure what's going on with the x264 settings there
[02:08:41 CEST] <TheAMM> Although I get encoding a working copy instead of a full 1080p video
[02:08:48 CEST] <furq> you mentioned preset placebo but those x264 options are definitely not preset placebo
[02:10:01 CEST] <spot> No doubt there are unnecessary options and I wouldn't be surprised if preset placebo conflicts with some settings. As I understand it, Handbrake takes the preset and then modifies in accordance with whatever additional settings you feed it. I am not an expert, I derived this through trial and error! That's why I'm here!
[02:10:27 CEST] <furq> well yeah if you want to use those exact x264 options then you can pass them to -x264-params
[02:10:34 CEST] <furq> the same string you pasted
[02:10:41 CEST] <furq> i would just stick with the vanilla presets though
[02:11:28 CEST] <furq> https://trac.ffmpeg.org/wiki/Encode/H.264#twopass
[02:11:35 CEST] <furq> if you really need a specific target bitrate then that's how you do 2-pass
[02:11:47 CEST] <furq> i would definitely be using crf mode for this though
[02:12:05 CEST] <spot> If I play a full 1920x1080 video in vlc, I must resize vlc. Don't need to resize smplayer, it remembers its window dimensions. But on 3-hour shows smplayer sometimes loses its audio-video synchronization. VLC is better at keeping audio and video synchronized.
[02:13:09 CEST] <TheAMM> furq: is there any speed difference between crf and cbr?
[02:14:00 CEST] <furq> -b is abr, not cbr
[02:14:17 CEST] <spot> I tried passing -x264-params and it didn't take them. This is on Fedora Linux 26. Maybe I need to compile ffmpeg myself?
[02:14:28 CEST] <furq> also
[02:14:36 CEST] <furq> spot: what about mpv --geometry=722x406
[02:14:41 CEST] <spot> I tried crf 17 and even 0 and did not get a smooth ticker.
[02:14:54 CEST] <TheAMM> furq: is there any speed difference between crf and abr?
[02:15:00 CEST] <furq> not really
[02:15:14 CEST] <spot> This machine encodes, in Handbrake given the above settings, at about 105 fps.
[02:15:14 CEST] <furq> abr is generally just worse
[02:15:29 CEST] <furq> 2-pass is really just crf mode
[02:15:42 CEST] <furq> the first pass just selects the correct crf value to hit the target bitrate
[02:17:31 CEST] <furq> apparently fc26 has ffmpeg 3.3 so that should be plenty new enough
[02:19:08 CEST] <spot> Just a minute...
[02:20:45 CEST] <spot> ffmpeg version N-90176-g27cbbbb Copyright (c) 2000-2018 the FFmpeg developers, built with gcc 7
[02:21:23 CEST] <furq> like i said i'd just forget those params anyway
[02:21:28 CEST] <furq> just stick with the presets
[02:21:47 CEST] <spot> I will try your suggestions and report back. Thanks much.
[02:22:00 CEST] <furq> and yeah make sure you're using -vf yadif=1
[02:22:20 CEST] <furq> you could also try bwdif=1, i've had somewhat better results with that
[02:23:11 CEST] <furq> but yeah if this is just in the pursuit of your player being the correct size then you should probably just use mpv --geometry
[02:23:14 CEST] <spot> Handbrake absolutely requires Deinterlace: yadif and Deinterlace preset: bob to produce an .mkv with smooth ticker scroll.
[02:23:21 CEST] <furq> right
[02:23:25 CEST] <furq> yadif mode 1 is bob
[02:23:37 CEST] <furq> bwdif is a different deinterlacer but it also has a bob mode
[02:23:53 CEST] <furq> i don't think bwdif made it into handbrake yet
[02:24:53 CEST] <spot> I'll be back tonight to report results.
[02:42:41 CEST] <_vince> any tips on repairing a barely playable jerky video with a lot of these errors:  top block unavailable for requested intra mode, mb_type 43 in P slice too large at 35 3
[02:43:14 CEST] <_vince> out of range intra chroma pred mode
[04:16:21 CEST] <spot> Back again. For comparison screencap, see https://drive.google.com/open?id=1er282wlTBX_jmF24nHN3BGAvMnt0PXUD
[04:16:42 CEST] <spot> The one on the left is with 1-pass ffmpeg, the one on the right is 2-pass Handbrake.
[04:17:48 CEST] <spot> Smoothness of ticker scroll is acceptable with both, however the 2-pass Handbrake is better quality. Noticeable particularly in the skin details of the interviewee, and sharpness of text.
[04:18:08 CEST] <spot> The ffmpeg line was:
[04:18:17 CEST] <spot> ffmpeg -i 'Squawk Alley - 03-27-2018 (03_27_2018).ts' -vf yadif=1,scale=722:406 -c:v libx264 -b:v 4160k -preset veryslow -b:a 144k 'Squawk Alley - 03-27-2018.mkv'
[04:19:22 CEST] <TheAMM> You can raise the bitrate or replace the -b:v with a -crf 20 or 18 or lower if you want better quality
[04:20:38 CEST] <spot> OK I'll try crf 18.
[04:23:28 CEST] <spot> Speed of encode was 48-49 fps, however since only 1 pass took about the same amount of time as 2-pass Handbrake. Took 59 minutes (it's a 59 minute video).
[04:39:47 CEST] <furq> spot: you can try using a faster preset
[04:40:00 CEST] <furq> slower will be noticeably quicker than veryslow
[04:43:04 CEST] <furq> also i guess handbrake does this for you, but hdtv and sdtv use different colour primaries, so if it's not signalled in the file then your player will guess based on resolution
[04:45:33 CEST] <furq> so you'll want to add -color_primaries bt709 -color_trc bt709 -colorspace bt709
[04:45:35 CEST] <furq> as output options
[04:46:36 CEST] <furq> you might want to doublecheck the source is bt709, but if this is an hdtv capture it's a pretty safe assumption
[04:57:02 CEST] <spot> furq: mediainfo says Color space: YUV, Chroma subsampling: 4:2:0, Bit depth: 8 bits, I presume this is bt709?
[05:00:57 CEST] <beandog> HandBrake guesses, but chooses bt709 by default for two of the colors, but not for the third.
[05:00:59 CEST] <furq> if it doesn't explicitly mention color primaries in mediainfo then it'll just be assumed to be bt.709
[05:01:03 CEST] <beandog> I just had to fix mine for DVDs.
[05:01:11 CEST] <beandog> furq, what are you encoding? what's the source
[05:01:16 CEST] <furq> i'm not encoding anything
[05:01:23 CEST] <furq> spot is encoding hdtv to 480p
[05:01:24 CEST] <beandog> oh, I meant spot
[05:01:43 CEST] <beandog> Anything above 480, the HDTV will assume it's 709
[05:01:46 CEST] <furq> right
[05:01:56 CEST] <beandog> you ... probably just said that.
[05:01:58 CEST] <beandog> :)
[05:02:00 CEST] <furq> i sure did
[05:02:03 CEST] <beandog> ll
[05:02:08 CEST] <beandog> I'll just crawl back in my cave.
[05:02:26 CEST] <furq> thanks for the preset reference page btw
[05:02:37 CEST] <beandog> dude that thing is balls out of date
[05:02:49 CEST] <beandog> I need to fix it
[05:03:01 CEST] <beandog> well. partially out of date.
[05:03:14 CEST] <furq> yeah i can't imagine they've changed that much
[05:03:43 CEST] <beandog> anyway, if you want HandBrake to force the right color set (from a DVD, which is all my sources), you'd need these x264 opts: colorprim=smpte170m:transfer=smpte170m:colormatrix=smpte170m
[05:04:03 CEST] <furq> i wonder if i have any that need fixing
[05:04:11 CEST] <spot> The colors all look correct to me. beandog: I'm taking CNBC shows, in .ts format, downloaded from my TiVo using kmttg, and turning them into .mkv files so I can play them on my computer. Reducing them from the original 1920x1080 down to 722x406, so I can view them in one quarter of my monitor's real estate, whilst using a browser on the other half.
[05:04:28 CEST] <beandog> dude \o/
[05:04:38 CEST] <beandog> downloading from a tivo. I used to have a Tivo2 I'd rip mine off. Those were the days.
[05:04:41 CEST] <beandog> I still have the code.
[05:06:02 CEST] <beandog> that's an interesting setup, though.
[05:06:13 CEST] <_vince> how to repair a broken video?
[05:06:18 CEST] <furq> yeah i still think it's crazy to reencode everything instead of just resizing your player
[05:06:34 CEST] <furq> just throwing that out there
[05:06:37 CEST] <beandog> that .... is what I was going to ask .. but I figured he had a good response and was tired of giving it :)
[05:06:51 CEST] <furq> i think he said something about it not working reliably in vlc
[05:06:55 CEST] <beandog> oh
[05:06:56 CEST] <furq> if you can imagine something not working reliably in vlc
[05:07:01 CEST] <beandog> makes sense.
[05:07:02 CEST] <beandog> I never use VLC
[05:07:15 CEST] <beandog> So I don't even know what it's like, quality-wise
[05:07:19 CEST] <_vince> furq: having a down scaled copy saves processing power in playing
[05:07:43 CEST] <furq> yeah but you then burn that saved power 100x by reencoding it in advance
[05:07:58 CEST] <beandog> yep
[05:08:11 CEST] <furq> unless the target machine is incapable of playing the source smoothly
[05:08:18 CEST] <spot> By downsizing it from 1920x1080 to 722x406 I can start it in my preferred player, vlc, and not have to resize the window. It's convenient to watch the shows and take notes on the other half of my monitor. Also reduces file size by about 60%.
[05:08:24 CEST] <beandog> that was gonna be my next guess, maybe something related to framerate.
[05:08:42 CEST] <furq> if you're actually archiving these and disk space is a concern then sure, that makes sense again
[05:09:00 CEST] <beandog> spot, looks good then :)
[05:09:22 CEST] <spot> Well, I have 10 TB, so space isn't really a worry.
[05:09:41 CEST] <beandog> What are your encoding parameters?
[05:09:47 CEST] <beandog> now I'm really curious
[05:11:12 CEST] <beandog> I actually go the opposite direction and bump mine up so that I have warm fuzzies. And it looks better.
[05:11:23 CEST] <beandog> bump it up size-wise
[05:13:23 CEST] <spot> Not sure what you mean by "parameters." Do you mean, what Handbrake settings am I using?
[05:14:19 CEST] <beandog> Yeah
[05:14:47 CEST] <spot> Wait a sec, I'll post them to Google Drive. I posted them, above, and got ranted at a bit for using so much space.
[05:14:51 CEST] <beandog> So you're using HB to re-encode your TS files? That's interesting.
[05:15:04 CEST] <beandog> as in, time-saving.
[05:15:22 CEST] <beandog> and other reasons.
[05:16:00 CEST] <spot> Yes but I want to use ffmpeg instead, that will save even more time, because ffmpeg can be called programmatically from kmttg. So I can download, decrypt, and transcribe multiple shows in one fell swoop.
[05:16:35 CEST] <spot> Poor _vince, he is not getting his question answered. Can anyone help him?
[05:17:03 CEST] <beandog> _vince, what was the question? broken video?
[05:17:26 CEST] <beandog> spot, oh right on, I can translate for you :D being the multimedia nerddom that I am
[05:17:31 CEST] <_vince> 16:42 < _vince> any tips on repairing a barely playable jerky video with a lot of these errors:  top block unavailable for requested intra mode, mb_type 43 in P slice too large at 35 3
[05:17:35 CEST] <_vince> 16:43 < _vince> out of range intra chroma pred mode
[05:17:58 CEST] <beandog> that's above my pay grade.
[05:21:35 CEST] <spot> Mine too. beandog: https://drive.google.com/open?id=1TFYbnUsPaEUSR5NkXs8RCSLwRmeBSnEr
[05:21:52 CEST] <beandog> yee boi, another distraction from homework
[05:22:47 CEST] <beandog> dang, dude, you are turning off *all* the features.
[05:22:51 CEST] <beandog> that makes it dead simple.
[05:23:56 CEST] <spot> I'm trying various suggested 1-pass ffmpeg command lines. First tried a command line with -b:v 4160k, it was not as sharp as my Handbrake settings. Just finished a second ffmpeg try with -crf 18, will tell you in a minute how it compares.
[05:24:03 CEST] <beandog> first knee-jerk reaction: don't use placebo, use slow at the most, don't use two-pass, do a high CRF like ... I dunno ... 18 and it'll look sexy ... I'd dump it at 60fps myself because that's how I roll.
[05:24:44 CEST] <beandog> After years, I settled myself on 23 as a general setting, 18 for the shows I like, and 14 for the ones I want to look godly.
[05:24:54 CEST] <beandog> like Teen Titans Go
[05:25:12 CEST] <beandog> if you really don't care about space, then yeah, use a high CRF
[05:25:46 CEST] <beandog> er, if you prefer *quality* over space. that's a better way to put it.
[05:26:05 CEST] <beandog> don't set the bitrate yourself, though, that'll just cause gray hairs.
[05:26:46 CEST] <beandog> ok plz hold let me translate this thing.
[05:26:48 CEST] <spot> I see no difference between -b:v 4160k and -crf 18. For a comparison see https://drive.google.com/open?id=1er282wlTBX_jmF24nHN3BGAvMnt0PXUD
[05:26:57 CEST] <spot> The one on the left is with 1-pass ffmpeg, the one on the right is 2-pass Handbrake
[05:27:41 CEST] <spot> The Handbrake one has sharper skin detail and crisper text.
[05:27:48 CEST] <beandog> well the bitrate is fixed, so you'll lose quality at some points. or use too much space at others. the CRF is quality based.
[05:28:36 CEST] <beandog> try a better CRF :)
[05:28:52 CEST] <spot> OK I'll try crf 14.
[05:28:52 CEST] <beandog> I know what it's like to be picky on quality.
[05:30:41 CEST] <beandog> oh, and you could run HandBrakeCLI as well, so you don't have to run the GUI. That's always an option, but you mentioned your app integrates ffmpeg so that probably wouldn't help much.
[05:32:14 CEST] <furq> you might want to add -tune film
[05:32:19 CEST] <furq> that should help with sharpness on fine detail
[05:32:24 CEST] <beandog> that, too ^^
[05:32:38 CEST] <furq> i notice handbrake is using deblock 0:0 so that can't be why that looks sharper
[05:32:48 CEST] <spot> Actually, tune=film was one of my experiments and the result was inferior.
[05:33:15 CEST] <furq> it will look worse at the same bitrate in abr mode
[05:33:25 CEST] <furq> in crf mode it'll bump the rate a bit to compensate
[05:35:47 CEST] <furq> you might also want to try bwdif instead of yadif
[05:36:05 CEST] <spot> I didn't try HandbrakeCLI because I read somewhere that not all the x264 parameters are obeyed/implemented in it.
[05:37:00 CEST] <spot> furq: OK I will. The "b" in "bwdif" stands for Bob and the "w" is his last name, the guy who invented yadif bob, if I remember correctly.
[05:37:13 CEST] <beandog> spot, .... wth ... of course it can do all the x264 params
[05:37:20 CEST] <beandog> who said that?
[05:37:23 CEST] Action: beandog smacks someone
[05:37:43 CEST] <beandog> --encopts
[05:37:56 CEST] <spot> Eh?
[05:38:46 CEST] <beandog> here's me being lazy and showing one of my examples
[05:38:52 CEST] <beandog> HandBrakeCLI '--markers' '--detelecine' '--cfr' --title '7' --encoder 'x264' --quality '14' --rate '60' --encoder-profile 'high' --encoder-level '4.1' --encoder-preset 'slow' --encoder-tune 'animation' --encopts 'colorprim=smpte170m:transfer=smpte170m:colormatrix=smpte170m' --audio '1' --aencoder 'ac3' --subtitle '3' --input '/home/steve/Media/Laundry-Basket/1.059.0242.BTMNB.iso' --output '1.059.0242.02020.BTMNB.mkv'
[05:39:13 CEST] <beandog> --encopts is where you dump those exact x264 params you had earlier
[05:39:51 CEST] <spot> Ah I see. Like -x264-params in ffmpeg.
[05:39:55 CEST] <beandog> yee
[05:40:04 CEST] <beandog> it's called encopts because it uses other encoders as well
[05:40:13 CEST] <beandog> it used to be x264-opts but they just folded it into one option
[05:40:30 CEST] <beandog> same with --encoder-level, profile, preset, etc.
[05:40:32 CEST] <furq> i don't think bob deinterlacing is named after a guy
[05:40:44 CEST] <furq> it's because a naive bob will result in alternate frames bobbing up and down
[05:41:28 CEST] <spot> https://github.com/kfrn/ffmpeg-things/blob/master/deinterlacing.md
[05:41:35 CEST] <beandog> spot, what's the source audio codec? do you care if you just pass it through? that'd save some time.
[05:41:39 CEST] <spot> bwdif: Bob Weaver Deinterlacing Filter
[05:41:47 CEST] <furq> yeah, because it combines bobbing and weaving
[05:41:56 CEST] <spot> Ah. Of course.
[05:41:59 CEST] <furq> it's just a coincidence that it sounds like a guy's name
[05:42:23 CEST] <furq> i suspect whoever named it did that on purpose
[05:42:36 CEST] <spot> Yeah, prolly.
[05:42:56 CEST] <beandog> hmm .. that's interesting ... I gotta check that out. There's some cartoons I have that decombing it makes it look more ugly, but less interlaced.
[05:43:04 CEST] <furq> it's all subjective but bwdif is the best realtime option in ffmpeg
[05:43:16 CEST] <furq> nnedi is the best quality but it's unbelievably slow
[05:43:35 CEST] <beandog> how slow is slow?
[05:43:41 CEST] <furq> obviously i said "it's all subjective" and then the bit after that is my opinion, not an absolute fact like i made it look there
[05:43:47 CEST] <furq> and uh
[05:44:12 CEST] <furq> like single-digit fps for 480p
[05:44:22 CEST] <furq> low single digits unless you have crazy clock speeds
[05:44:28 CEST] <beandog> spot, are you gonna try handbrake cli out? because if so, I'm not gonna translate this sucker. :)
[05:44:38 CEST] <beandog> that is slow.
[05:44:38 CEST] <spot> The source audio codec is AC3, Codec ID 129, at constant 384 kbps. So says mediainfo.
[05:44:41 CEST] <furq> nnedi is what avisynth/vapoursynth qtgmc uses, and it's multithreaded there so it's not so bad
[05:45:02 CEST] <beandog> spot, okay, yeah, you could just leave it there.
[05:45:28 CEST] <furq> also honestly those x264 options you pasted look crazy to me
[05:45:39 CEST] <spot> First I'm gonna try ffmpeg with a long -x264-params line plus the -tune and -profile.
[05:45:40 CEST] <furq> like 1 bframe and 120 lookahead is a bit eye-watering
[05:45:58 CEST] <beandog> furq, it's HandBrake just printing out its defaults -- it's not actually overriding *all* of it
[05:46:10 CEST] <spot> Yeah I know but I swear bframe=1 looks better than bframe=3 or 4.
[05:46:25 CEST] <beandog> spot, okay
[05:47:24 CEST] <spot> Ditto the huge values for keyint, keyint_min, rc_lookahead, and sync_lookahead. Primary goal was to get butter-smooth scroll of the ticker, secondary goal was sharpness of text.
[05:48:15 CEST] <beandog> fair enough.
[05:48:26 CEST] <spot> Just a minute, I'll post mediainfo of the output .mkv to Google Drive so you can see what Handbrake did.
[05:48:39 CEST] <beandog> yeah that'd be helpfl
[05:49:27 CEST] <beandog> Im gonna try out these other filters on my Superman TAS DVDs
[05:49:32 CEST] <beandog> They are grossly horrible interlaced.
[05:49:58 CEST] <beandog> and I'll use my sexy dvd_copy program to pipe it right through! woo hoo! or copy it to the hdd. whichever.
[05:53:03 CEST] <spot> mediainfo of the .mkv output: https://drive.google.com/open?id=1xRy494MWXOayWEoicARJP7O4GvO5Dr8b
[05:53:47 CEST] <beandog> spot, can you throw up a mediainfo output for the source material too?
[05:54:00 CEST] <spot> Sure, just a moment
[05:55:06 CEST] <beandog> that's an old-ish handbrake install
[05:55:24 CEST] <beandog> but *most* development changes they make are for GUI, so you're probably not missing out.
[05:56:30 CEST] <spot> mediainfo of the source .ts: https://drive.google.com/open?id=1pYURjyZXbmUzzsBh4ZIgga7iJ61nBKrc
[05:56:40 CEST] <spot> It's the standard supplied with Fedora 26.
[05:56:45 CEST] <beandog> k thx
[05:56:46 CEST] <beandog> ah ok
[05:57:35 CEST] <beandog> hmm, only a 50% drop in size .. and if you're picky on quality, I'd actually leave it alone and tell the player to resize it.
[05:57:44 CEST] <beandog> but we already went over that :)
[05:58:15 CEST] <beandog> okay slightly more than 50% .. but whatevs
[06:00:21 CEST] <beandog> what video player *are* you using, anyway?
[06:01:28 CEST] <spot> VLC version 3.0.1 Vetinari (3.0.1-0-gec0f700fcc), Compiled by mockbuild on buildvm-03.online.rpmfusion.net (Feb 27 2018 19:59:16), Compiler: gcc version 7.3.1 20180130 (Red Hat 7.3.1-2). Again, the standard issue with Fedora 26.
[06:04:48 CEST] <beandog> Hmm.
[06:04:52 CEST] <spot> And before you ask...the machine is a dual-E5-2696v3 Xeon. 2 x 18 cores, plus hyperthreading, so 72 virtual cores total. So 36 threads is no worry.
[06:05:20 CEST] <spot> Of course I don't know whether Handbrake actually *uses* all those cores.
[06:05:28 CEST] <beandog> it can
[06:05:36 CEST] <beandog> x264 will use all of them by default
[06:05:49 CEST] <beandog> you can see the threads= value in the mediainfo. I think.
[06:06:05 CEST] <beandog> threads=36
[06:06:06 CEST] <beandog> yee boi
[06:06:18 CEST] <spot> Well, ffmpeg makes my cpu utilization go to 13%, Handbrake goes to 26%.
[06:06:30 CEST] <spot> Handbrake encodes at ~105 fps.
[06:06:57 CEST] <spot> So a 2-pass encode on a 1-hour show takes about 1 hour start to finish. Actually slightly less.
[06:06:58 CEST] <beandog> well they're running completely different arguments
[06:08:53 CEST] <beandog> but that does bring up the question of what part does encoding time take into this, priority wise
[06:08:56 CEST] <beandog> how fast do you need something
[06:09:47 CEST] <spot> I'd like to view it the same day it's broadcast.
[06:10:24 CEST] <spot> I'm quite comfortable with a 1-hour show taking 1 hour to encode. Quality is my main objective.
[06:12:29 CEST] <beandog> got it
[06:12:38 CEST] <spot> I'm quite happy with the quality of the Handbrake encode. Just, I'd like to be able to do it from a cli program. Either ffmpeg or handbrake-cli will serve the purpose. I came here originally tonight to ask if anyone can tell me the 2-line ffmpeg 2-pass equivalent to my exacerbatingly-arrive-at Handbrake setup.
[06:12:57 CEST] <spot> arrived-at
[06:13:05 CEST] <beandog> right, and I was going to add awhile ago that I didn't have it on my lappy, so I'm waiting for the thing to finish building.
[06:13:32 CEST] <spot> It took me *months* of experiments to arrive at settings I was satisfied with.
[06:13:43 CEST] <beandog> spot, well your handbrake settings are pretty basic. Very much so. It's just that it's also printing out all these defaults.
[06:13:53 CEST] <beandog> hold on though
[06:14:39 CEST] <beandog> crap. I don't have ghb installed either. I *think* if you look at the debug window it'll give you the actual command it's running.
[06:14:54 CEST] <beandog> maybe not. it's been a while. Hold on. I can get a HB line for you much faster.
[06:15:15 CEST] <spot> ghb *is* Handbrake GUI.
[06:15:33 CEST] <beandog> right
[06:15:35 CEST] <beandog> I only use the CLI
[06:15:38 CEST] <beandog> I'm saying I don't have it on my box
[06:15:41 CEST] <spot> Ah. I see.
[06:15:59 CEST] <spot> I don't think ghb has a debug window.
[06:16:31 CEST] <spot> I should note here, I am not a programmer, only an end user.
[06:17:16 CEST] <beandog> setting custom width and height is a pain. hb is snotty about that.
[06:20:26 CEST] <spot> Another 20 minutes or so, and I should have the ffmpeg 1-pass crf=14 encode finished. That may turn out to be all I need.
[06:20:57 CEST] <beandog> okay here
[06:21:07 CEST] <beandog> HandBrakeCLI -d bob -w 406 -l 722 -e x264 -r 59.94 --cfr -vb 4160 -2 --no-turbo --encoder-preset placebo --encoder-level 4.1
[06:21:11 CEST] <beandog> I slapped that together
[06:21:30 CEST] <beandog> HandBrakeCLI -d bob -w 406 -l 722 -e x264 -r 59.94 --cfr -vb 4160 -2 --no-turbo --encoder-preset placebo --encoder-level 4.1 -i input.ts -o output.mkv
[06:22:26 CEST] <beandog> If you wanna play with it, do a 60 second encode and see what you think: --stop-at duration:60
[06:22:43 CEST] <spot> And add the --encopts= followed by my complete Handbrake additional parameters?
[06:22:57 CEST] <beandog> no
[06:23:00 CEST] <beandog> placebo is setting them.
[06:23:05 CEST] <spot> OK hang on.
[06:23:05 CEST] <beandog> no touchy
[06:23:57 CEST] <beandog> it'll bump the profile to high as well, so I didn't really need that.
[06:24:09 CEST] <beandog> Oh. I didn't put it in there. Good for me.
[06:26:15 CEST] <beandog> once it runs do a diff or vimdiff on the two mediainfo outputs. That'll give you a clear vision of what it's changing (or not changing)
[06:26:18 CEST] <spot> Encoding...
[06:28:57 CEST] <beandog> hokay
[06:29:44 CEST] <spot> 10 seconds more...
[06:31:11 CEST] <spot> Quality looks pretty good. However, it created a 1330 x 722 video, not a 722 x 406 one.
[06:31:33 CEST] <furq> -w and -l are flipped
[06:31:44 CEST] <furq> assuming -l is "height"
[06:32:07 CEST] <beandog> uh
[06:32:09 CEST] <beandog> yeah
[06:32:10 CEST] <beandog> :)
[06:32:20 CEST] <beandog> wait.
[06:32:22 CEST] <beandog> Yeah that sounds right.
[06:32:33 CEST] <spot> Ticker scroll is a bit fuzzy.
[06:32:34 CEST] <furq> is that command deinterlacing
[06:32:40 CEST] <beandog> yeah
[06:32:49 CEST] <beandog> it's using bob
[06:32:56 CEST] <spot> Looks like it's not a yadif bob deinterlace.
[06:33:15 CEST] <beandog> Hmm
[06:33:18 CEST] <furq> also those settings you were using weren't placebo
[06:33:19 CEST] <beandog> my params might be wrong sec.
[06:33:34 CEST] <beandog> --encoder-preset placebo
[06:33:41 CEST] <furq> yeah i meant the x264 params pasted earlier
[06:33:44 CEST] <spot> The crf=14 encode just finished, let me look at that.
[06:33:57 CEST] <furq> virtually none of those matched preset placebo
[06:34:03 CEST] <beandog> Oh, ok
[06:34:06 CEST] <furq> some nice guy made a webpage where you can easily compare them
[06:34:16 CEST] <beandog> yee
[06:35:08 CEST] <furq> spot: pastebin the full ffmpeg command you're using
[06:35:09 CEST] <beandog> Hmm, yeah, I'm not entirely sure I'm doing deinterlacing right. I always do detelecine on mine and let it go.
[06:35:14 CEST] <spot> It is my understanding that Handbrake takes the preset you give it as the starting point, then adjusts the parameters individually in accordance with the additional parameters you give it in the "More settings" box.
[06:35:23 CEST] <furq> and also bear in mind most x264 options won't actually make any difference given enough bitrate
[06:35:36 CEST] <beandog> spot, yeah, it does
[06:35:48 CEST] <beandog> what furq said.
[06:36:04 CEST] <beandog> I learned that the hard way.
[06:36:17 CEST] <furq> i'd be surprised if you can tell the difference between superfast and placebo at crf 14
[06:37:00 CEST] <beandog> Yeah I've done tests on that. You can't.
[06:37:00 CEST] <spot> The crf=14 encode is slightly better than the crf=18 encode, but still not as good as the Handbrake encode.
[06:37:12 CEST] <furq> pastebin the ffmpeg command
[06:39:50 CEST] <spot> Hold on, I have to stitch it together first.
[06:41:54 CEST] <beandog> mine keeps want to keep building against x265. le sigh.
[06:42:19 CEST] <beandog> oh well
[06:45:58 CEST] <spot> https://drive.google.com/file/d/1ICSPFYOji6shV2sY2z6YwYlNK4zZ_VF5/view
[06:46:48 CEST] <spot> It's going at 123-124 fps, so should take about 30 minutes.
[06:47:11 CEST] <furq> are you encoding the whole thing every time
[06:47:25 CEST] <spot> Yes
[06:48:01 CEST] <spot> Can I put in a parameter similar to the HandbrakeCLI parameter which stops it after, say, 60 seconds?
[06:48:27 CEST] <furq> -t 60
[06:48:35 CEST] <spot> Oh OK, let me restart it.
[06:51:09 CEST] <furq> http://vpaste.net/STb3Z
[06:51:10 CEST] <furq> try that
[06:51:34 CEST] <furq> i should really have remembered earlier that scale will use bicubic by default, which is probably why it looks soft
[06:51:46 CEST] <furq> that plus the fixed colour primaries should look much better
[06:52:17 CEST] <beandog> Hmm .. I'm playing with other deinterlacing filters, this is already looking good .. thanks furq :D
[06:52:28 CEST] <furq> qtgmc is unmatchable for sd stuff
[06:52:33 CEST] <furq> for sd sources, i mean
[06:52:41 CEST] <furq> but it means going via vapoursynth
[06:52:52 CEST] <furq> and also an elaborate and annoying install procedure
[06:53:06 CEST] <furq> it's absolutely worth it if you're ripping a lot of dvds though
[06:53:09 CEST] <spot> The long-line 1-pass ffmpeg looks identical to the crf=14 encode. Let me try furq's suggested line.
[06:54:16 CEST] <beandog> I've got everything nailed down, there's only like 3 or 4 shows that have *nasty* interlacing on it, that any filter on it removes it, but makes other lines look worse. :T
[06:54:29 CEST] <furq> yeah qtgmc is excellent for that
[06:54:42 CEST] <beandog> ok
[06:54:47 CEST] <furq> the one thing it's a godsend for in my experience is a lot of bbc/channel 4 dvds where they've deinterlaced it badly and it has a ton of stairstepping
[06:55:00 CEST] <furq> it has a specific mode for repairing that and it works really well
[06:55:09 CEST] <beandog> really
[06:55:11 CEST] <beandog> that is interesting
[06:55:16 CEST] <furq> but yeah it's really slow
[06:55:44 CEST] <furq> even multithreaded with vapoursynth, just deinterlacing is slower than encoding with veryslow
[06:56:51 CEST] <beandog> I *really* need to look into this. I generally just shrug it off and then get mad.
[06:56:56 CEST] <furq> fortunately 1080i stuff tends to benefit less from it because that would take longer than the lifetime of the universe
[06:57:01 CEST] <beandog> heh
[06:57:12 CEST] <furq> especially because i'm normally resizing that to 720p anyway
[06:57:13 CEST] <beandog> I'm happy with 480i thanks
[06:57:17 CEST] <spot> furq's line, the crf=14 line, and the very long like-ghb line all give equal results. Handbrake still looks crisper.
[06:57:36 CEST] <spot> I mean Handbrake GUI 2-pass.
[06:57:45 CEST] <furq> you should definitely notice a difference between default scaling and lanczos scaling
[06:57:51 CEST] <furq> and you should also definitely notice the colours are correct now lol
[06:57:59 CEST] <furq> unless vlc is being wonky
[06:58:35 CEST] <spot> Yeah, you're right, skin tone is a little washed out on the like-ghb encode. Not washed out on yours.
[07:02:12 CEST] <spot> The 2-pass Handbrake encode is still just slightly crisper. But not by much.
[07:03:53 CEST] <spot> Let me look at the mediainfo diff...
[07:03:55 CEST] <beandog> hmm
[07:04:13 CEST] <beandog> dude give x264 crf a try :)
[07:05:45 CEST] <furq> 4mbit is really high for 480p
[07:05:55 CEST] <furq> i guess you could drop the crf some more
[07:06:26 CEST] <furq> i've never encoded anything below 18 in my life but if you're really pixel-gazing it might make a difference
[07:07:28 CEST] <furq> apparently handbrake uses lanczos scaling by default so i'm now out of ideas as to what the difference could be
[07:08:03 CEST] <beandog> In my case, I'm mostly pedantic and obssessed
[07:09:02 CEST] <beandog> okay cool, I got some good pngs of the original source that has horrible deinterlacing
[07:09:14 CEST] <beandog> er, interlacing.
[07:10:01 CEST] <furq> fwiw i think qtgmc is the best deinterlacer in general
[07:10:13 CEST] <furq> all the realtime ones leave you with some stairstepping in my experience
[07:10:46 CEST] <furq> certainly from a dvd source where you're not resizing it
[07:10:48 CEST] <beandog> Yeah I'm just getting a setup where I can actually begin testing some
[07:11:16 CEST] <beandog> furq, there you go - source/1.036.0173.TNTTN.iso
[07:11:17 CEST] <beandog> gah
[07:11:20 CEST] <beandog> stupid buffer
[07:11:25 CEST] <beandog> http://dev.beandog.org/superman-tas/
[07:12:13 CEST] <furq> that sort of just looks like a regular telecine
[07:13:47 CEST] <beandog> yeah, it is, but detelecing ruins it at the same time
[07:13:50 CEST] <beandog> which makes me sad cakes
[07:14:05 CEST] <spot> Here's the diff between mediainfo of furq's result and my ghb one: https://drive.google.com/file/d/1Lkkaf043FZntaYKV3IOTv4GRu3l2dqMG/view
[07:14:07 CEST] <furq> i'm in a pal region so i never have to deal with ivtc
[07:14:28 CEST] <beandog> I hate you.
[07:14:35 CEST] <beandog> :D
[07:16:14 CEST] <beandog> wait
[07:16:18 CEST] <beandog> what encoding preset did you use?
[07:16:46 CEST] <beandog> these are totally different
[07:19:55 CEST] <spot> oops I did mediainfo on "Squawk Alley - 03-28-2018" not 03-27 as before. Shouldn't make any difference though. Same settings.
[07:22:25 CEST] <spot> Er, oops again. Forgot...when I encoded today's Squawk Alley (03-28) I eliminated the threads and lookahead threads settings, as an experiment. Otherwise, should be same.
[07:23:32 CEST] <spot> Also dropped me_range from 24 (03-27) to 16. That might make a difference. Let me run the diff again on 03-27 vs. furq's.
[07:25:16 CEST] <beandog> do this as well
[07:25:40 CEST] <beandog> mediainfo video.mkv | grep "Encoding settings" | head -n 1 | cut -d ':' -f 2- | tr '/' '\n' | cut -d ' ' -f 2-
[07:25:46 CEST] <beandog> for both videos, then compare them
[07:25:50 CEST] <beandog> that'll show you the x264 changes
[07:26:03 CEST] <beandog> then we can actually get a *fair* comparison, since that's all that really matters here.
[07:26:24 CEST] <spot> Will do, wait...
[07:27:13 CEST] <beandog> You need to get those to match, starting with the one *you like*
[07:27:17 CEST] <beandog> and then you're pretty much done.
[07:29:34 CEST] <furq> i doubt the encoding settings really matter at all
[07:29:42 CEST] <furq> if you really want, you can rule those out entirely by encoding with -crf 0
[07:30:12 CEST] <furq> all settings give identical PQ at crf 0, only the filesize will differ
[07:30:32 CEST] <beandog> oh. I guess I already had that online. http://dev.beandog.org/x264_preset_reference.html
[07:30:37 CEST] <beandog> I like the new one better.
[07:30:49 CEST] <furq> is this not the new one
[07:30:49 CEST] <beandog> furq, I'm just wondering if his presets are changing
[07:31:08 CEST] <beandog> sorry, I meant that x264 info line
[07:31:18 CEST] <beandog> old one: mediainfo video.mkv | grep Encoding | cut -d ':' -f 2- | tr '/' '\n' | cut -d ' ' -f 2-
[07:32:09 CEST] <furq> at this point i have to suspect it's some difference between handbrake and ffmpeg's scaler or implementation of yadif
[07:32:20 CEST] <furq> assuming handbrake isn't just using swscale and avfilter
[07:33:34 CEST] <beandog> if he's using bob like I passed
[07:33:53 CEST] <beandog> yeah nvm I thought --help had more info. nvm
[07:36:30 CEST] <spot> https://drive.google.com/file/d/1l0cRO7H4Q9w3bpw0Sr84zpVZE0CDvVV0/view
[07:39:37 CEST] <beandog> yeah umh vs hex
[07:40:07 CEST] <beandog> one's encoding a medium preset
[07:40:17 CEST] <beandog> *at
[07:40:45 CEST] <beandog> one sec
[07:40:48 CEST] <furq> apparently preset slow is hex now
[07:41:11 CEST] <beandog> is it?
[07:41:12 CEST] <beandog> hmm
[07:41:16 CEST] <furq> yeah i just checked
[07:41:22 CEST] <beandog> see? my thing is outdated. :)
[07:41:22 CEST] <furq> i guess it does change after all
[07:41:36 CEST] <beandog> I didn't know that though, I do all mine at slow.
[07:41:39 CEST] <furq> anyway yeah like i said
[07:41:52 CEST] <furq> spot: if you want to rule out encoding settings, run my command again with -crf 0
[07:42:00 CEST] <furq> and whatever preset you want since it makes no difference
[07:42:06 CEST] <furq> might as well go with ultrafast
[07:42:24 CEST] <furq> if that still looks different then it's the scaler or deinterlacer
[07:42:53 CEST] <spot> OK wait
[07:43:20 CEST] <beandog> yeah, that makes sense.
[07:43:25 CEST] <beandog> I need to get back to work
[07:43:31 CEST] <beandog> these four hour lunch breaks are awesome.
[07:43:53 CEST] <spot> Haha I'm in Seattle where it's 10:43 PM. Past my bedtime.
[07:43:58 CEST] <beandog> ghb is actually doing lower quality, imo
[07:44:35 CEST] <beandog> in my very humble opinion. But, I'm biased, and I'm not the one watching it, so it's a moot point.
[07:46:19 CEST] <beandog> spot, can you send me a link again to that original hexchat convo so I can see your original x264 options again
[07:49:59 CEST] <spot> Auto Crop off, Loose Crop unchecked, 0-0-0-0, Optimal for Source unchecked, 722, 406, Anamorphic off, Alignment 2, Keep Aspect checked.
[07:50:07 CEST] <spot> Detelecine off, Interlace Detection off, Deinterlace Yadif, Deinterlace preset Bob, Deblock off, Denoise Filter Off
[07:50:15 CEST] <spot> H.264, Framerate 59.94, Constant, Bitrate 4160, 2-Pass encoding, Turbo first pass unchecked, preset placebo, Tune none, Profile high, Level 4.1, fast decode unchecked.
[07:50:23 CEST] <spot> ref=4:bframes=1:b-pyramid=none:weightp=1:8x8dct=1:me=umh:subme=9:merange=16:direct=auto:b-adapt=2:trellis=2:aq_mode=1:aq_strength=1:psy_rd=1.00,0.15:fast_pskip=0:deblock=0,0:dct-decimate=0:keyint=600:keyint_min=120:rc_lookahead=120:sync_lookahead=120:qcomp=0.45:non-deterministic=1:qpmin=0:qpmax=30:qpstep=5:analyse=i4x4,i8x8:chroma_qp_offset=-1:nr=1
[07:51:14 CEST] <beandog> thx
[07:53:20 CEST] <spot> The crf=0 encode is...indistinguishable from my Handbrake encode.
[07:54:19 CEST] <spot> However, 60 seconds at crf=0 occupies 423 MB. 60 minutes from Handbrake, 1842 MB.
[07:56:29 CEST] <beandog> CRF is lossless
[07:56:39 CEST] <beandog> er
[07:56:44 CEST] <beandog> CRF 0 is lossless
[07:56:55 CEST] <beandog> The point was to see if its the video filters that are throwing it off.
[07:57:28 CEST] <beandog> anyway I think this is *close* ..
[07:57:29 CEST] <furq> fun
[07:57:34 CEST] <beandog> ffmpeg -i dvd_track_08.vob -c:v libx264 -preset placebo -crf 18 -x264-params ref=4:bframes=1:b-pyramid=none:weightp=1:8x8dct=1:me=umh:subme=9:merange=16:direct=auto:b-adapt=2:trellis=2:aq_mode=1:aq_strength=1:psy_rd=1.00,0.15:fast_pskip=0:deblock=0,0:dct-decimate=0:keyint=600:keyint_min=120:rc_lookahead=120:sync_lookahead=120:qcomp=0.45:non-deterministic=1:qpmin=0:qpmax=30:qpstep=5:analyse=i4x4,i8x8:chroma_qp_offset=-1:nr=1 -acodec copy -t 1 -r
[07:57:34 CEST] <beandog> 59.94 -vf bwdif output.mkv
[07:57:47 CEST] <beandog> verbose ftw.
[07:58:05 CEST] <furq> yeah my suggestion is to just run mine again but with -crf 14
[07:58:11 CEST] <beandog> Yeah
[07:58:12 CEST] <beandog> Do 14.
[07:58:23 CEST] <furq> like i said, 4mbit is enormous for 480p
[07:58:49 CEST] <furq> you can try with and without -tune film as well, idk how that'll affect text and stuff
[07:58:59 CEST] <furq> it's supposed to bias towards fine detail so i figured it'd make edges crisper
[07:59:04 CEST] <beandog> Okay I really do need to get to work, good luck spot. Read the output of 'HandBrakeCLI --help' it's not scary and you can build it yourself if you don't wanna go the ffmpeg route
[07:59:58 CEST] <beandog> In fact, you can *use* the presets in the GUI.
[08:00:25 CEST] <beandog> HandBrakeCLI --preset-list
[08:00:31 CEST] <beandog> Yet another thing I should have mentioned hours ago..
[08:00:54 CEST] <beandog> and then just override what you want.
[08:01:36 CEST] <spot> I already tried crf=0. It's a little better than crf=18 and about the same as furq's first suggestion, but furq's use of the Lancosz algo then made the colors better. I think the next thing to try will be a 2-pass 2-line ffmpeg encode, from the long line I posted at https://drive.google.com/file/d/1ICSPFYOji6shV2sY2z6YwYlNK4zZ_VF5/view. HandBrakeCLI is available in the Fedora repo's, I already downloaded and tried it. But I like the
[08:01:36 CEST] <spot> idea of doing it with ffmpeg a la furq.
[08:01:59 CEST] <spot> I mean "already tried crf=14"
[08:02:19 CEST] <spot> Need to hit the sack soon.
[08:02:29 CEST] <beandog> HandBrakeCLI --preset 'H.264 MKV 1080p30' -i dvd_track_08.vob -o waddup.mkv --stop-at duration:1
[08:02:30 CEST] <beandog> k
[08:02:31 CEST] <beandog> good luck :D
[08:02:38 CEST] <beandog> I'm outta
[08:02:50 CEST] <spot> good night zzzz
[08:19:50 CEST] <spot> I of course could not sleep until I made one more try at it. This 1-pass ffmpeg line produces an encode which looks identical to my 2-pass Handbrake encode. Better, because the encode runs at 150+ fps. So this is going to save me quite a bit of time.
[08:20:21 CEST] <spot> ffmpeg -i 'Squawk Alley - 03-27-2018 (03_27_2018).ts' -vf bwdif=1,scale=722:406:flags=lanczos,fps=60000/1001 -c:v libx264 -b:v 4160k -preset placebo -profile:v high -x264-params ref=4:bframes=1:b-pyramid=none:weightp=1:8x8dct=1:me=umh:subme=9:merange=16:direct=auto:b-adapt=2:trellis=2:aq_mode=1:aq_strength=1:psy_rd=1.00,0.15:fast_pskip=0:deblock=0,0:dct-decimate=0:keyint=600:keyint_min=120:rc_lookahead=120:sync_lookahead=120:qcomp=0.4
[08:20:21 CEST] <spot> 5:non-deterministic=1:qpmin=0:qpmax=30:qpstep=5:analyse=i4x4,i8x8:chroma_qp_offset=-1:nr=1 -t 180 -r 59.94 -acodec copy 'Squawk Alley like ghb r 5994 - 03-27-2018.mkv'
[08:21:06 CEST] <spot> Without the -t 180 in real world use, of course.
[08:30:32 CEST] <Ankit> Hi I am unable to build ffmpeg for android can anyone help me out here
[08:30:44 CEST] <Ankit> the error comes on the line patching file library.mak patching file libavutil/common.h
[08:30:56 CEST] <Ankit> aarch64-linux-android-gcc is unable to create an executable file. C compiler test failed.
[09:37:59 CEST] <axew3> hello all, little confused on installing ffmpeg into a centos server, after i execute the last ffmpeg command to install, it return ERROR: vorbis not found using pkg-config, and i note that there are two different folders pkgconfig, one is on /root/ffmpeg_build/lib/pkgconfig and one is on /usr/local/lib/pkgconfig: if i launch th elast install, and i try to set the one or the other, i get ever
[09:37:59 CEST] <axew3> the same error ... sorry i'm not so skilled
[09:41:45 CEST] <axew3> should i try to copy/paste all files of one into the other, and try out if work in this way?
[10:01:45 CEST] <beandog> spot, cool, I'm glad you got it worked out
[10:04:32 CEST] <spot> Heh...yeah, but upon closer look, the colors and contrast in the Handbrake encode are better. And, even though Handbrake shows it as encoding at 105 fps and ffmpeg shows 145-155, both take about one hour to encode a 1-hour show.
[10:05:33 CEST] <spot> Still, I'm encouraged, and I thank you and furq for helping me. I might try HandBrake-CLI next time I have free time on my hands.
[10:06:21 CEST] <spot> Going to bed for real now.
[10:08:24 CEST] <beandog> Yeah I noticed you're not setting the colors in ffmpeg.
[10:08:29 CEST] <beandog> run a mediainfo diff again
[10:08:34 CEST] <beandog> I'm out, too
[10:13:11 CEST] <ritsuka> handbrake always sets the color tag (if the original haven't got one, it guesses it), in ffmpeg you have to do i manually
[10:26:21 CEST] <axew3> ]# PKG_CONFIG_PATH=/usr/local/lib/pkgconfig
[10:26:21 CEST] <axew3> [root at admin573 ffbuild]# pkg-config --list-all
[10:26:21 CEST] <axew3> shared-mime-info shared-mime-info - Freedesktop common MIME database
[10:26:21 CEST] <axew3> zlib             zlib - zlib compression library
[10:26:21 CEST] <axew3> freetype2        FreeType 2 - A free, high-quality, and portable font engine.
[10:26:22 CEST] <axew3> fontutil         FontUtil - Font utilities dirs
[10:26:22 CEST] <axew3> systemd          systemd - systemd System and Service Manager
[10:26:23 CEST] <axew3> udev             udev - udev
[10:26:23 CEST] <axew3> bash-completion  bash-completion - programmable completion for the bash shell
[10:26:24 CEST] <axew3> [root at admin573 ffbuild]# export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:$PKG_CONFIG_PATH
[10:26:24 CEST] <axew3> [root at admin57343206 ffbuild]# pkg-config --list-all
[10:26:25 CEST] <axew3> systemd          systemd - systemd System and Service Manager
[10:26:25 CEST] <axew3> fdk-aac          Fraunhofer FDK AAC Codec Library - AAC codec library
[10:26:26 CEST] <axew3> fontutil         FontUtil - Font utilities dirs
[10:27:18 CEST] <axew3> pkg-config --exists --print-errors vorbis
[10:27:18 CEST] <axew3> Package vorbis was not found in the pkg-config search path.
[10:27:18 CEST] <axew3> Perhaps you should add the directory containing `vorbis.pc'
[10:27:18 CEST] <axew3> to the PKG_CONFIG_PATH environment variable
[10:27:18 CEST] <axew3> No package 'vorbis' found
[10:27:19 CEST] <axew3> ERROR: vorbis not found using pkg-config
[10:27:48 CEST] <durandal_1707> USE PASTEBIN!!!!!!!!
[10:28:11 CEST] <axew3> what i should execute to add also vorbis, which is isntalled, to the PKG_CONFIG_PATH?
[10:31:05 CEST] <durandal_1707> it obviously is not installed, or its .pc file is different directory where no utility searches
[10:32:31 CEST] <axew3> sorry so what i should do? exactly it is in another directory
[10:33:27 CEST] <axew3> What mean use PASTEBIN? please not ban me at this point ...
[10:34:01 CEST] <durandal_1707> copy it to directory where are almost all pkg-config files located
[10:35:30 CEST] <axew3> @durandal_1707 i will try right now
[11:27:55 CEST] <_vince> why is mplayer more popular than ffplay?
[11:28:36 CEST] <BtbN> Because it's an actual player
[11:28:44 CEST] <BtbN> ffplay is a prove of concept, nothing more
[11:29:01 CEST] <_vince> it's slower too
[11:29:04 CEST] <BtbN> it's a horrible player though, use mpv instead
[11:29:20 CEST] <_vince> as in mplayer is horrible?
[11:29:43 CEST] <furq> i wouldn't go that far but you shouldn't be using mplayer
[11:30:25 CEST] <_vince> why is that?
[11:30:30 CEST] <furq> because mpv exists
[11:30:58 CEST] <_vince> does it have more bells and whistles or is it better in performance as well
[11:31:13 CEST] <furq> it's just better in general
[11:31:53 CEST] <_vince> ill give it a shot thanks
[11:32:03 CEST] <_vince> btw can mencoder do anything ffmpeg command cant do?
[11:33:09 CEST] <furq> shrug
[11:33:11 CEST] <furq> i've never used it
[11:33:30 CEST] <durandal_1707> mencoder is unmaintained, it just can use binary codecs, nothing more
[11:34:39 CEST] <furq> http://www.mplayerhq.hu/design7/images/left.jpg
[11:35:04 CEST] <durandal_1707> old days
[11:35:06 CEST] <furq> i always forget about mplayer's fourth-place-at-mekka-&-symposium-2001-ass logo
[11:37:22 CEST] <_vince> just tried mpv the track bar lingers for half a second after using the wheel, yuck
[11:37:27 CEST] <_vince> it should disappear instantly
[11:37:41 CEST] <furq> it's configurable
[11:38:16 CEST] <durandal_1707> come one, you complain about players bars?
[11:38:22 CEST] <furq> also a few mplayer frontends support mpv as a backend now
[11:38:32 CEST] <furq> although it sounds like you're not interested in those
[11:39:29 CEST] <_vince> durandal_1707: yeah i'd prefer there were no bar
[11:39:36 CEST] <furq> again, that's all configurable
[11:39:46 CEST] <_vince> yeah, will look into it now
[11:39:57 CEST] <furq> you can disable the osc and/or osd completely if you don't want them
[11:44:14 CEST] <_vince> has anyone had success cancelling out machinery noise, especially like washing machine in the background
[11:44:52 CEST] <_vince> its not white and cancelling it from a sample also degragess human speech
[11:45:39 CEST] <durandal_1707> it doesn't need to be white noise...
[12:12:55 CEST] <_vince> so what happened to mplayer2?
[12:13:14 CEST] <_vince> i remember a time when people were saying it's the fastest bestest thing
[12:13:26 CEST] <_vince> i guess now you reserve that to mpv
[12:24:13 CEST] <durandal_1707> _vince: yes, mpv replaced mplayer2
[12:25:37 CEST] <_vince> cool, do you think mpv beats mplayer performance wise
[12:26:09 CEST] <JEEB> _vince: basically even the mplayer2 maintainer is now on mpv's development channel, so that was a rather clean switch
[12:28:24 CEST] <durandal_1707> _vince: only drawback is that mpv removed binary support from mplayer2
[12:28:37 CEST] <durandal_1707> iirc
[12:28:41 CEST] <durandal_1707> might be wrong
[12:28:47 CEST] <JEEB> wasn't that already removed with mplayer2? :D
[12:28:52 CEST] <JEEB> if not, color me surprised
[12:29:38 CEST] <_vince> i dont have a great graphics card and my cpu is pentium 4 so having a speedy player helps a lot
[12:29:48 CEST] <_vince> most HD stuff played here lags
[12:30:18 CEST] <_vince> i would say mplayer was noticably better than vlc, lets see how mpv goes
[12:40:05 CEST] <durandal_1707> _vince: mpv expect modern gpu
[12:40:41 CEST] <durandal_1707> not some potato
[12:49:31 CEST] <JEEB> there's still some low-end renderers left
[12:49:32 CEST] <JEEB> in mpv
[12:49:35 CEST] <JEEB> for the dumb devices
[13:00:26 CEST] <th3_v0ice> JEEB: Its interesting that transcoding.c example from github is also not transcoding all of the frames. It is missing 2 for the 3.4.2 release. For the latest commit from the master, its missing 9 frames.
[14:10:58 CEST] <th3_v0ice> JEEB: I fixed my problem. Thanks for all the help! :)
[14:11:23 CEST] <JEEB> cheers
[14:11:24 CEST] <JEEB> what was it?
[14:19:32 CEST] <th3_v0ice> I was using wrong decoder context to flush :)
[14:20:18 CEST] <JEEB> ah
[14:20:20 CEST] <JEEB> classic
[14:21:59 CEST] <th3_v0ice> Haha, yeah. I knew it was something stupid.
[14:22:38 CEST] <th3_v0ice> Decoder contexts are stored in array, was using the wrong index to acess the decoder ctx.
[15:48:29 CEST] <joepadmiraal> Hi all. I created a hardware device context with av_hwdevice_ctx_create and decoded a frame with avcodec_send_packet/avcodec_receive_frame. Now I want to use that decoded frame in a cuda kernel. Is this possible?
[17:57:20 CEST] <th3_v0ice> joepadmiraal: It is. Decoded frame is just YUV in some specific format (420, 422, 444). Its array of chars if I am not mistaken.
[19:49:10 CEST] <SortaCore> hey folks
[19:49:36 CEST] <SortaCore> any idea how to boost an MP4's audio volume (without clipping) while retaining the best source quality?
[19:49:47 CEST] <furq> replaygain if your player supports it
[19:50:33 CEST] <SortaCore> well, I can use 200% in VLC, but I was more wanting the video file boosted itself
[19:51:22 CEST] <furq> i mean adding replaygain tags to the file
[19:51:30 CEST] <furq> a lot of video players support that
[19:51:48 CEST] <SortaCore> how do
[19:52:11 CEST] <SortaCore> ah, found it on StackOverflow
[19:52:53 CEST] <SortaCore> does replaygain take a value, because I don't know the exact dB to boost it to take it to -0.0dB
[19:56:54 CEST] <furq> i don't know if ffmpeg even does it tbh
[19:57:01 CEST] <furq> i normally do it in an audio player
[19:59:38 CEST] <SortaCore> there's an audio filter called replaygain
[19:59:52 CEST] <furq> yeah but filters require reencoding
[19:59:59 CEST] <furq> at which point you might as well just change the volume
[20:00:50 CEST] <furq> if you're ok with reencoding then -af volumedetect, then -af volume=5dB or whatever value volumedetect gives as max_volume
[20:01:51 CEST] <ChocolateArmpits> You should use volumedetect first to determine peak volume, then use the volume filter to compensate accordingly
[20:04:32 CEST] <ChocolateArmpits> for true peak display use ebur128 or loudnorm filter
[20:06:39 CEST] <SortaCore> re-encoding is ok, just as close to source as possible
[20:27:26 CEST] <kepstin> well, re-encoding a lossy file will always have some loss, and it's up to you to figure out codec settings that meet your quality requirements
[20:32:26 CEST] <adminjoep> th3_v0ice: Thanks. I tried to feed the AVFrame.data[0] pointer which I received from the avcodec_receive_frame call to my kernel. To thest this I run the kernel with a grid of 5 and simply print a byte from the threadIdx.x position. In order to wait for the kernels to complete I do a MemcpyDtoH. When I run this program it returns this error: MemcpyDtoH failed IllegalAddress. I don't think MemcpyDtoH is the
[20:32:28 CEST] <adminjoep> actual problem as when I remove the frame pointer reading from the kernel the program runs without issues. And this includes executing the MemcpyDtoH command. I thought this might be caused by the fact that the kernels run on a different cuda context as the ffmpeg decoder. So I tried to search for ways to retrieve the cuda context from ffmpeg but I did not succeed. Does anyone know if this could be the issue
[20:32:30 CEST] <adminjoep> and wheter it is possible to obtain the cuda context? Thanks, Joep.
[20:34:56 CEST] <kepstin> adminjoep: which ffmpeg decoder are you actually using? If you're just selecting the default, it's probably just doing a software decode on the cpu.
[20:35:37 CEST] <adminjoep> kepstin: I'm using hevc_cuvid
[20:38:05 CEST] <kepstin> hmm. Admittedly I haven't done much with hwaccel stuff before, but I was under the impression that you could provide a specific hardware context for the decoder to use when initializing it.
[20:39:48 CEST] <BtbN> If you have a CUDA frame, you can get the hw_frames_ctx from it, and the hw_device_ctx from that, and that holds the CUDA context
[20:40:09 CEST] <BtbN> Or provide your own hw_device_ctx in the first place
[20:56:06 CEST] <SortaCore> hm I boosted by max_volume (6.9dB) but not a very noticeable difference
[20:56:16 CEST] <SortaCore> maybe I have to normalise instead
[20:59:08 CEST] <ChocolateArmpits> SortaCore, 7db should be pretty evident, unless you expect a very large increase. Open the original and the filtered audio in audacity and compare
[20:59:17 CEST] <kepstin> "normalizing" is a bit of an overloaded term, but the standard usage is "increase gain to the max level that doesn't clip" - which is exactly what you just did
[20:59:46 CEST] <ChocolateArmpits> kepstin, some software referes to the procedure as "maximizer"
[21:01:04 CEST] <SortaCore> hm ok
[21:01:14 CEST] <ChocolateArmpits> SortaCore, It could be that there's a single high peak while the rest of the audio is rather quiet, you'd have to compress the audio or increase the volume further -- that single peak may clip but not really sound noticeable
[21:01:44 CEST] <SortaCore> actually, the new file is quieter
[21:02:16 CEST] <ChocolateArmpits> SortaCore, impossible. Did you input the minus sign rather than a plus sign for the volume filter?
[21:02:58 CEST] <SortaCore> no... but i apparently put 6.4d instead of 6.4dB
[21:03:03 CEST] <SortaCore> I'll re-run it
[21:03:13 CEST] <SortaCore> atm there's no plus or minus
[21:03:33 CEST] <SortaCore> now it's noticeably louder,y ea
[21:03:34 CEST] <ChocolateArmpits> no sign means additional volume is applied
[21:03:52 CEST] <SortaCore> what does d on its own do?
[21:04:05 CEST] <ChocolateArmpits> probably nothing, strange it didn't crash
[21:04:29 CEST] <SortaCore> no, it just seemed to make it quieter, although not sure to what level
[21:10:39 CEST] <apus> while trying to capture vhs content i inevitably run into this error: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1708922  which kills the file. my source is stk1160 the usb video grabber.  is there a workaround for this? some patch that i'd need to manually apply to ffmpeg?
[21:12:55 CEST] <BtbN> that looks more like a broken driver than anything ffmpeg related
[21:14:44 CEST] <apus> as far as i could figure out the problem is in the linux kernel. however, since the issues i found concerning this are sometimes at least 2 years old, i don't expect the solution to come from that side
[21:15:34 CEST] <apus> i don't care if i have to disable some if condition somewhere, as long as it works for this problem i'll happily compile a separate ffmpeg
[21:15:55 CEST] <JEEB> time to make your own patched version of the kernel module :P
[21:16:43 CEST] <apus> if i knew which module was responsible and where i'd need to look, that would be an option. what i can find is the place in the ffmpeg code that outputs the error/warning that ffmpeg throws
[21:17:09 CEST] <BtbN> it's a crash, in the driver. Not something you can just "not print".
[21:23:07 CEST] <SortaCore> freopen
[21:23:21 CEST] <SortaCore> anyway, volume boosted ok, thanks folks
[21:23:33 CEST] <SortaCore> catcha later
[21:27:22 CEST] <th3_v0ice> adminjoep: Try to copy all of the data and validate that its there. Dont use pointers if you dont know how long they exist. Take a look at this example https://github.com/FFmpeg/FFmpeg/blob/master/doc/examples/decode_video.c
[22:00:05 CEST] <axew3> running last ffmpeg install step, after addition of all the rest, i hope, it return me ERROR: libx264 not found but i can't find out this file and the final message on terminal return.  make
[22:00:05 CEST] <axew3> Makefile:2: ffbuild/config.mak: No such file or directory
[22:00:05 CEST] <axew3> Makefile:40: /tools/Makefile: No such file or directory
[22:00:05 CEST] <axew3> Makefile:41: /ffbuild/common.mak: No such file or directory
[22:00:05 CEST] <axew3> Makefile:90: /libavutil/Makefile: No such file or directory
[22:00:06 CEST] <axew3> Makefile:90: /ffbuild/library.mak: No such file or directory
[22:00:06 CEST] <axew3> Makefile:92: /fftools/Makefile: No such file or directory
[22:00:07 CEST] <axew3> Makefile:93: /doc/Makefile: No such file or directory
[22:00:07 CEST] <axew3> Makefile:94: /doc/examples/Makefile: No such file or directory
[22:00:08 CEST] <axew3> Makefile:160: /tests/Makefile: No such file or directory
[22:00:08 CEST] <axew3> make: *** No rule to make target `/tests/Makefile'.  Stop.
[22:00:09 CEST] <axew3> [root at admin57343206 ffmpeg]# make install
[22:00:09 CEST] <axew3> Makefile:2: ffbuild/config.mak: No such file or directory
[22:00:10 CEST] <axew3> Makefile:40: /tools/Makefile: No such file or directory
[22:26:59 CEST] <apus> are these the kernel modules that cause the problem? are they fixing it at the moment? https://www.mail-archive.com/linux-media@vger.kernel.org/msg128416.html
[22:31:47 CEST] <seb_> Hello, I understand not good how to make a multi output with filters (some filter are the same, some are different):  ffmpeg -i udp://239.100.0.1:1234 -vf "crop=720:574:0:2, yadif=0, scale=9:8, fps=25" -copyts -f image2 -frame_pts 1 "/tmp/seb/deux/%d.pgm" ffmpeg -i udp://239.100.0.1:1234 -map 0:0 -vf "crop=720:574:0:2, yadif=0, scale=iw/2:ih/2" out.ts
[22:32:22 CEST] <seb_> so "crop=720:574:0:2, yadif=0" is the same
[22:32:58 CEST] <seb_> I follow https://trac.ffmpeg.org/wiki/Creating%20multiple%20outputs
[22:33:09 CEST] <seb_> but it doesn't work for me
[22:38:43 CEST] <seb_> ffmpeg -i udp://239.100.0.1:1234 -filter_complex '[0:v]crop=720:574:0:2,yadif=0,split=2[out1] [out2]' \ -map 'out1' -vf "scale=9:8, fps=25" -copyts -f image2 -frame_pts 1 "/tmp/seb/deux/%d.pgm" \ -map '[out2]0:0 -vf "scale=iw/2:ih/2" out.ts
[22:39:00 CEST] Last message repeated 1 time(s).
[22:41:11 CEST] <ChocolateArmpits> seb_, for multiple outputs you need to use a single filtergraph before the first output
[22:41:31 CEST] <ChocolateArmpits> not filtergraphs for each output
[22:42:06 CEST] <ChocolateArmpits> so place that second scale inside of the initial filter_complex
[22:42:22 CEST] <ChocolateArmpits> actually both of them
[22:45:11 CEST] <seb_> the first filtre scale is " scale=9:8 " (for the first output)  and the for the second output, the filter is "scale=iw/2:ih/2
[22:45:25 CEST] <ChocolateArmpits> so put them both inside the filter_complex
[22:45:55 CEST] <seb_> after split?
[22:46:17 CEST] <ChocolateArmpits> well yeah because you need them scaled differently
[22:46:27 CEST] <seb_> ok thanks
[22:46:42 CEST] <ChocolateArmpits> split=2[v1][v2];[v1]scale=...[out1];[v2]scale=...[out2]
[22:46:43 CEST] <ChocolateArmpits> like that
[22:47:26 CEST] <quint> Is there any information on libaom/AV1 implementation for an ffmpeg release?
[22:47:56 CEST] <BtbN> libaom stuff just got merged
[22:47:59 CEST] <JEEB> it seems like the libaom wrapper got merged so it will be part of the next release if you really want a release
[22:48:06 CEST] <JEEB> (you generally don't want a release with FFmpeg)
[22:49:01 CEST] <quint> JEEB: why's that?
[22:49:17 CEST] <BtbN> Nobody really cares about releases anyway
[22:49:29 CEST] <BtbN> they are arbitrary snapshots, because people and distributions keep asking for them
[22:49:37 CEST] <quint> ahh.
[22:49:44 CEST] <JEEB> yes, and they get very little attention in general
[22:49:59 CEST] <JEEB> which fixes get  or get not into a release or releases depends on a whim more or less
[22:50:08 CEST] <JEEB> and f.ex. I don't know which releases at this point are supported, even
[22:50:14 CEST] <BtbN> security fixes will get in, but other than that...
[22:50:24 CEST] <JEEB> possibly not even security fixes
[22:50:31 CEST] <JEEB> did the http commit by wm4 get in?
[22:50:33 CEST] <JEEB> :D
[22:50:49 CEST] <BtbN> There was no release-round since then
[22:51:09 CEST] <JEEB> yea but was it back-ported into any release branches? I bet no
[22:52:23 CEST] <JEEB> the main thing that get backported are the google fuzzing "security" things which can be useful, but in some cases they are just a pain in a butt. and then the imperfect sanity check can't be removed because of """security""" (and I'd post a patch for a better one but to get the proper limits of all fields for movenc for example is not really easy)
[23:02:59 CEST] <seb_> Hello
[23:03:25 CEST] <seb_> a little error  : "Cannot find a matching stream for unlabeled input pad 0 on filter Parsed_fps_4"
[23:03:38 CEST] <seb_> with the command :
[23:03:48 CEST] <seb_> ffmpeg -i udp://239.100.0.1:1234 -filter_complex '[0:v]crop=720:574:0:2,yadif=0,split=2[in1][in2];[in1]scale=9:8[out1],fps=25;[in2]scale=iw/2:ih/2[out2]' \ -map '[out1]' -copyts -f image2 -frame_pts 1 "/tmp/seb/deux/%d.pgm" \ -map '[out2]' out.ts
[23:38:43 CEST] <spot__> NICK spot
[23:38:54 CEST] <spot__> oops
[00:00:00 CEST] --- Fri Mar 30 2018