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

[burek]

[00:15:56 CET] <Rickky> I'm trying to simply forward an incoming RTMP stream to another RTMP endpoint, but keep running into [NULL @ 0x3da41a0] Unable to find a suitable output format for 'rtmp://xxx.com' rtmp://xxxx.com: Invalid argument
[00:16:35 CET] <Rickky> I tried to force certain format types but think I am messing in the wrong order
[00:17:18 CET] <aguardar> what's your command
[00:17:23 CET] <Rickky> See http://pastebin.com/raw/v9xpZnCZ
[00:21:25 CET] <JEEB> -f flv after the input
[00:21:36 CET] <JEEB> although it should have guessed by the protocol... I think?
[00:21:45 CET] <Rickky> Input is HLS
[00:22:07 CET] <Rickky> Input stream actualluy seems to be recognized properly
[00:22:11 CET] <JEEB> yes
[00:22:16 CET] <JEEB> because that gets probed
[00:22:16 CET] <Rickky> e.g. reads metadata correctly
[00:22:34 CET] <JEEB> it's just that it can't guess the *output* format from the "file name"
[00:22:50 CET] <JEEB> so you have to tell it that the output (thus, after -i INPUT) is flv
[00:23:06 CET] <JEEB> also if the input is RTMP like you said before it cannot be HLS, it's FLV
[00:23:14 CET] <Rickky> Ah
[00:23:15 CET] <JEEB> because RTMP is an FLV-only protocol
[00:25:05 CET] <Rickky> yeah
[00:26:26 CET] <Rickky> JEEB: yep that's it!
[00:26:35 CET] <Rickky> quality not that good, but let's tweak that
[00:26:44 CET] <JEEB> first of all kill minrate
[00:27:01 CET] <JEEB> that's a libavcodec option (somehow?) implemented in there
[00:27:11 CET] <JEEB> in other words it's not something within libx264 itself
[00:27:21 CET] <JEEB> which is a separate library, and which is well tested
[00:28:08 CET] <JEEB> also you're not specifying bufsize
[00:28:27 CET] <JEEB> which is not required but you most likely want to set it in addition to maxrate, since I have no idea what the default is
[00:28:42 CET] <the_k_> can anyone help me get something that's working into something better?!
[00:28:52 CET] <JEEB> VBV/HRD in libx264 works with both maxrate and bufsize - in other words maxrate over bufsize
[00:29:14 CET] <JEEB> the_k_: are metaquestions so darn hip nowadays?
[00:29:14 CET] <the_k_> i have a camera feed being recorded to disk with motion detection enabled that only writes frames that have changes in them
[00:29:18 CET] <the_k_> ffmpeg -i rtsp://fd:554/Streaming/Channels/2 -vf "select=gt(scene\,0.005),setpts=N/(25*TB)" fd_motion.mp4
[00:29:24 CET] <the_k_> yep
[00:29:38 CET] <the_k_> gotta feed the crowd maan
[00:30:31 CET] <the_k_> i have that and it works fine, but i'd like to have it so that it writes to a dated filename
[00:31:21 CET] <the_k_> on my other recording feed, i have it so it demuxes it so i can play the file that's being written in near realtime (2-5s delay at the end of the file) and the fiodated
[00:31:23 CET] <the_k_> loops
[00:31:25 CET] <the_k_> oops***
[00:31:32 CET] <the_k_> ..and the file is dated correctly
[00:31:53 CET] <the_k_> and the command for that is:
[00:32:07 CET] <the_k_> ffmpeg -i rtsp://fd:554/Streaming/Channels/1 -c copy -f segment -segment_time 21600 -strftime 1 fd_HD_%%Y-%%m-%%d-%%H;%%M;%%S.ts
[00:32:40 CET] <the_k_> my problem is just that when i try to add the -f segment .. etc part to the previous command it doesn't like it
[00:33:39 CET] <Rickky> JEEB: -bufsize is set to $CBR right, which is 3000k
[00:34:09 CET] <JEEB> oh, I missed it on the third line
[00:34:21 CET] <the_k_> "filtering and streamcopy can not be used together"
[00:34:39 CET] <JEEB> basically set it to the amount of buffer the client would have to do to 100% not have to buffer again
[00:34:51 CET] <JEEB> the bigger the buffer the more fluctuation you can have
[00:35:01 CET] <JEEB> within that buffer
[00:35:37 CET] <JEEB> (in other words in a simplistic way of saying it, maxrate is the overall average bit rate over bufsize at all points of the clip)
[00:39:17 CET] <the_k_> ok nevermind i got it working, i thought i had tried taking  "-c copy" out
[00:42:37 CET] <ZeroWalker> how do you initialize an audio codec context? (libopus). cause basically all the parameters are for video:s
[00:49:30 CET] <Rickky> JEEB: Pretty sure this is why minrate got into it: " To force CBR video output: xxx -minrate 4000 -maxrate 4000" http://ffmpeg.org/ffmpeg.html#Video-and-Audio-file-format-conversion one but last example
[00:50:11 CET] <JEEB> yea, that's for some other encoders
[00:52:14 CET] <Rickky> JEEB: So just drop minrate?
[00:52:18 CET] <JEEB> yes
[00:53:42 CET] <Rickky> Got a pretty stable stream now, tweaked around a bit. Apparently I missed implementing $FPS. Now set that using -r
[01:03:29 CET] <Rickky> That's great... After enabling reload=1 on drawtext, speed drops from 1.2x to 0.08x...
[01:11:04 CET] <Rickky> How could I improve performance/speed with drawtext enabled? I turned down both framerate as 264 quality beyond acceptable already, and I still consistently see okay-ish framerate first couple of seconds, quickly see it drop to 0.5-0.8 speed now tops
[01:11:23 CET] <Rickky> What is it bound? bitrate?
[01:11:34 CET] <Rickky> FPS obviously but putting it below 15 is pretty ridiculous
[01:45:02 CET] <Rickky> Trying to figure out what the bottleneck is. Doubled the VM in CPU, still same result once enabling drawtext
[02:05:04 CET] <Rickky> I really don't understand why my speed drops to 0.3x while I see 8 CPUs at 100% idle... Threads = 6 but don't see that actually happening
[02:31:09 CET] <DHE> ffmpeg isn't 100% multithreaded. there's a single thread taking input, submitting it to the filters, and submitting it to the outputs
[02:31:28 CET] <DHE> some decoders are multi-threaded, some filters are multi-threaded, and some encoders are multi-threaded. but that doesn't mean 100% usage all the time
[04:22:54 CET] <hiihiii> what's the correct way to encode an RGB mp4
[04:23:49 CET] <hiihiii> -c:v libx264rgb -pix_fmt bgr24?
[04:24:42 CET] <hiihiii> -c:v libx264 -pix_fmt bgr24?
[04:24:55 CET] <hiihiii> -c:v libx264rgb -pix_fmt rbg24?
[04:25:41 CET] <hiihiii> 1st worked. 3rd did not
[04:26:20 CET] <hiihiii> *sorry I meant : 1st worked. 2nd did not
[04:36:05 CET] <relaxed> hiihiii: ffmpeg -h encoder=libx264rgb | less
[15:05:33 CET] <ldiamond> is it supposed to take a long time to cut a small part of a video starting ~10mins in? ffmpeg seems to be working hard (80% cpu usage) but no frame is being encoded.
[15:05:40 CET] <ldiamond> This is my command: ffmpeg -i P3101158.MOV -ss 00:10:53 -t 00:00:18 -r 60000/1001 -async 1 cut1.mp4
[15:06:07 CET] <ldiamond> seems like its working hard to reach 10:53, idk if there's a more efficient command I could use
[15:06:56 CET] <BtbN> put -ss before the -i
[15:07:48 CET] <ldiamond> yea much better.
[15:08:23 CET] <ldiamond> so putting the -i before makes ffmpeg convert the whole file then seek and get the part I want?
[15:24:11 CET] <jarkko> i had this line in my winff -c:a aac -strict experimental  -b:a 128k -b:v 3000k  -filter:v yadif -b:a 128k -r:a 44.1  -ac 2...i dont know why its so complicated, it has been much simpler before. but it doesnt produce the result i want
[15:24:24 CET] <jarkko> i want 2 channel 44.1 128 audio
[15:30:38 CET] <BtbN> you don't need the experimental flag for aac anymore.
[15:30:44 CET] <BtbN> And I'm pretty sure it's -ar
[15:30:48 CET] <BtbN> and it takes it in Hz, not kHz
[15:31:41 CET] <jarkko> so its "-ar 44100" ?
[15:32:34 CET] <JEEB> note: AAC-in-FLV doesn't require specific audio rates
[15:33:07 CET] <jarkko> JEEB: FLV?
[15:33:23 CET] <JEEB> well I guess that if you're writing -ar 44100 you most likely are pushing out FLV :P
[15:33:34 CET] <JEEB> (either into a file or to an rtmp(e) server
[15:36:10 CET] <jarkko> is it possible to use crf=28 rate control and kilobytes same time? for video?
[15:36:52 CET] <BtbN> you can't have a constant quality at a constant bitrate, with what magic would that work?
[15:37:02 CET] <JEEB> CRF/ABR as main rate controls can't be mixed, but you can set a bufsize and a maxrate over the bufsize
[15:37:12 CET] <JEEB> so you can have CRF but limitede by VBV/HRD
[15:37:31 CET] <jarkko> what's the meaning of bufsize? i can understand maxrate
[15:37:49 CET] <furq> bufsize is the amount of data over which maxrate is measured
[15:37:54 CET] <JEEB> ^this
[15:38:20 CET] <jarkko> makes sense but how do you "measure" what's good value
[15:38:22 CET] <JEEB> that way the client has to buffer bufsize amount of data and to have a connection at the very least of maxrate, and it will *always* be able play that stream afterwards
[15:38:46 CET] <JEEB> jarkko: the bigger the better. you just have to decide the amount of buffering the client should do
[15:38:53 CET] <JEEB> then you match the encoder and playback
[15:38:54 CET] <furq> -maxrate 1500k -bufsize 1000k means the bitrate will never exceed 1500kbps in any given 1000kB of data (note kB, not kbit)
[15:39:10 CET] <JEEB> really?
[15:39:14 CET] <furq> yeah
[15:39:21 CET] <JEEB> I thought both were in kilobits
[15:39:26 CET] <JEEB> that'd be really surprising if not :D
[15:40:07 CET] <furq> http://vpaste.net/hz1Go
[15:40:15 CET] <furq> maybe ffmpeg maps it differently though
[15:40:25 CET] <furq> oh wait that says kbit
[15:40:28 CET] <furq> the fuck am i thinking of then
[15:40:51 CET] <JEEB> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/libx264.c#L500
[15:41:04 CET] <JEEB> yea, they get handled exactly the same way, too
[15:41:15 CET] <kepstin> the ffmpeg command uses bits, yeah. so there is a conversion - bit ’ kbit :)
[15:41:15 CET] <furq> oh i'm thinking of slice-max-size
[15:41:19 CET] <furq> ignore me, i'm dumb
[15:41:46 CET] <furq> that one actually makes sense for it to be in bytes
[15:43:57 CET] <kepstin> jarkko: it often makes sense to think of bufsize as time not size - so maxrate 1500k bufsize 1000k means that if you have a 1500k internet connection, you'll need about 1.5s of buffer to handle bitrate fluctuations.
[15:44:46 CET] <kepstin> er, i got that backwards
[15:44:58 CET] <kepstin> bufsize / maxrate = time
[15:45:06 CET] <kepstin> iirc?
[15:45:13 CET] <kepstin> ah, i'm still half asleep.
[15:45:49 CET] <furq> thank you for this show of solidarity
[15:46:23 CET] <jarkko> kepstin: i am not encoding for streaming...i am  still figuring out the options
[15:46:54 CET] <kepstin> if you're not encoding for streaming or for a media with limited speed (dvd/bd), then don't use bufsize/maxrate at all.
[15:46:59 CET] <furq> if it's not for streaming then just don't cap the bitrate
[15:47:07 CET] <furq> let crf do its thing
[15:47:17 CET] <JEEB> you just need to find the highest CRF value that still looks good for you
[15:47:18 CET] <jarkko> but i want to have minimum bitrate, anyway to set that?
[15:47:28 CET] <JEEB> encode ~2500 frames or so with different values
[15:47:31 CET] <furq> there's absolutely no point doing that
[15:47:48 CET] <JEEB> just use a CRF you know is good enough for you and then you get the quality you want
[15:47:50 CET] <JEEB> that's all that matters
[15:47:52 CET] <JEEB> in the end
[15:47:52 CET] <JEEB> :P
[15:47:54 CET] <furq> setting a minimum bitrate will just waste bits with no quality gain
[15:48:03 CET] <furq> or it would if you could do it, which iirc you can't with crf
[15:48:36 CET] <JEEB> getting too low bit rate usually manifests with bad quality, and in that case you just go and lower your CRF value
[15:48:46 CET] <JEEB> because then you've picked the wrong CRF value
[15:49:03 CET] <JEEB> start with 23 and go up if it looks good, down if it looks bad.
[15:49:20 CET] <furq> i use the same crf for more or less everything and it's fine
[15:49:30 CET] <furq> 20 for <720p, 21 for >=720p
[15:49:53 CET] <JEEB> I'd also limit that to similar types of content and of course to the usual presets you use
[15:50:03 CET] <furq> i only change that for really pathological cases like old fps footage
[15:50:03 CET] <JEEB> but yes, after you get the ranges you want it gets pretty automagic
[15:50:09 CET] <furq> and i've not fucked with that in years
[15:50:15 CET] <jarkko> i installed winff and it seems to make things more complicated than really helping
[15:50:21 CET] <furq> although yeah i should have pointed out that i use the same preset as well
[15:50:47 CET] <furq> and yeah ffmpeg guis are universally shit
[15:51:12 CET] <furq> they're either more complicated than ffmpeg or they're missing one option you want
[15:51:14 CET] <jarkko> the thing is that i want to downgrade audio from 48000 to 44.1 and 2 channels. also i want subtitles to be copied over to the mkv file even i wouldnt use it
[15:51:16 CET] <furq> or both, usually
[15:51:33 CET] <BtbN> why do you want to resample?
[15:51:35 CET] <furq> it's easier to just learn ffmpeg
[15:51:41 CET] <furq> at least that knowledge is useful
[15:51:57 CET] <jarkko> not really fmpeg own website is refering often to x264 and then saying that this doesnt work on x265
[15:52:10 CET] <furq> huh
[15:52:12 CET] <JEEB> it's two different encoders, so d'uh
[15:52:22 CET] <jarkko> see yourself how x265 quide is made
[15:52:25 CET] <furq> if you mean the wiki then that's often wrong
[15:52:38 CET] <furq> it's usually best to ignore that
[15:52:48 CET] <JEEB> well the libx265 wrapper is rather minimal :P
[15:52:55 CET] <JEEB> it's more geared towards "use x265-params"
[15:53:12 CET] <JEEB> it will take some basic things from CRF,preset etc, but anything more requiring would end up with x265-params
[15:53:40 CET] <JEEB> including maxrate/bufsize/level/profile I think?
[15:54:07 CET] <JEEB> so yes, different encoders within FFmpeg require different parameters. who wudda known?!
[15:54:27 CET] <jarkko> what preset you usually use?
[15:54:34 CET] <furq> slower or veryslow
[15:54:48 CET] <JEEB> what preset I use shouldn't matter for you
[15:54:57 CET] <JEEB> because I have my needs, you have yours
[15:55:00 CET] <jarkko> well do you think thats helpful
[15:55:10 CET] <JEEB> as I said, encode like 2500 frames with different presets
[15:55:13 CET] <furq> ^
[15:55:13 CET] <JEEB> compare the speed
[15:55:23 CET] <JEEB> then pick the slowest that is still fast enough for you
[15:55:28 CET] <furq> it depends how patient you are and how much quality you care about
[15:55:43 CET] <furq> and how good your cpu is
[15:55:47 CET] <JEEB> and if you say you don't care about the speed then just go fsck yourself with preset placebo and come back crying you want it faster
[15:55:53 CET] <jarkko> but do you see any difference between the presets with human eye if the presets are close to each other
[15:56:05 CET] <furq> it depends on the content
[15:56:09 CET] <JEEB> I do see differences between them when compression is actually required
[15:56:21 CET] <furq> some content you'll see a big difference between slower and veryslow
[15:56:25 CET] <furq> most of the time you won't
[15:56:28 CET] <JEEB> CRF just makes it really easy to make files which look good, whatever the preset
[15:56:47 CET] <JEEB> so thus it comes down to your speed preference and how much you care about file size
[15:56:51 CET] <furq> you're probably overthinking it really
[15:56:56 CET] <furq> the x264 defaults are already pretty good
[15:57:09 CET] <jarkko> have they always been?
[15:57:28 CET] <JEEB> for the last... six?  years, yes
[15:57:28 CET] <furq> they have been for a long time
[15:57:37 CET] <JEEB> I don't even remember when the preset system was made
[15:58:12 CET] <kepstin> unfortunately, you still sometimes see cargo cult x264 options hanging around on forums and wikis and stuff from before the preset system was added :/
[15:58:32 CET] <furq> wait are you saying that forum posts might have incorrect ffmpeg information
[15:58:34 CET] <furq> now this i gotta see
[16:06:40 CET] <jarkko> well i am getting somwehere...but
[16:06:43 CET] <jarkko> -c:a aac -b:a 128k -ar:44100 -ac2
[16:06:50 CET] <jarkko> is that constant bitrate or variable?
[16:07:08 CET] <JEEB> depends on the encoder but for audio you usually get CBR
[16:07:23 CET] <jarkko> aac..
[16:07:44 CET] <jarkko> if you have 5.1 sounds. does it sound any good with 128 bitrate?
[16:07:50 CET] <jarkko> i have no idea
[16:08:07 CET] <JEEB> fuck if I fucking know. in most fucking cases the audio is so small it makes no fucking sense to re-encode it even if it's raw PCM
[16:08:27 CET] <JEEB> so feel free to think once again why the flying fuck you're raping the audio
[16:10:02 CET] <jarkko> well audio is consuming most likely more bits than video then
[16:10:15 CET] <jarkko> go fuck yourself
[16:11:26 CET] <furq> what a nice young man
[16:11:44 CET] <JEEB> such cases just get tiring as hell
[16:11:55 CET] <furq> i thought the finns were more robust than that
[16:12:08 CET] <JEEB> we're different :P
[17:14:12 CET] <acresearch> hello people, i have a 23GB 4k mkv video that is not playing on a samsung TV, how can i convert it so it can play on a samsung tv while maintaining the high def?
[17:14:35 CET] <JEEB> first of all find out what your thing supports
[17:15:16 CET] <acresearch> JEEB: well my TV support mkv, but for some reason it is not playing this one, i read somewhere that the mkv header is different, i do not understand what that means or how to change it
[17:15:33 CET] <JEEB> oh
[17:15:43 CET] <JEEB> but I mean, video and audio formats within the container
[17:16:09 CET] <JEEB> anyways, the first thing I'd do is do `ffmpeg -i input.mkv -c copy -sn -movflags faststart out.mp4`
[17:16:13 CET] <JEEB> and put the video into mp4
[17:16:24 CET] <JEEB> (that grabs the primary video and audio track)
[17:16:30 CET] <JEEB> then try that first
[17:16:43 CET] <acresearch> JEEB: would i lose quality?
[17:16:44 CET] <JEEB> given that your TV supports whatever was inside that matroska file
[17:16:46 CET] <JEEB> no
[17:16:51 CET] <JEEB> that's just bit stream copying
[17:16:56 CET] <acresearch> ok, i will try that, :-) thanks JEEB
[17:17:05 CET] <JEEB> take the streams out of matroska, then push them into mp4
[17:18:18 CET] <acresearch> ok
[18:25:53 CET] <ren0v0> Hi, i'm trying to simply split a file using ffmpeg, but the first 4-5 seconds are frozen    >  ffmpeg -i input.avi -vcodec copy -acodec copy -copyinkf -ss 00:09:17 -t 00:10:00 output.avi
[18:25:54 CET] <ren0v0> any ideas?
[18:26:14 CET] <ren0v0> i think it's related to key frames somehow, but need a solution
[18:29:50 CET] <BtbN> "first few frames are frozen"?
[18:40:51 CET] <ren0v0> yea
[18:41:06 CET] <ren0v0> no movement on the video for like 2-5 seconds
[18:43:41 CET] <ren0v0> also, a separate question. If i'm generating a video (h.264 codec), from JPEGs, at 15fps 1080p res, what bitrate should i use for best quality?
[18:55:05 CET] <BtbN> for litterally best quality you want to use lossless mode
[18:57:38 CET] <DHE> start with -crf 18 and see how it goes. lower the number for better quality, raise it for a smaller file size
[19:01:26 CET] <ren0v0> DHE,  i'm using this currently, where would -crf fit in?
[19:01:28 CET] <ren0v0> -r 15 -codec:v libx264 -profile:v high -preset slow -threads 0 -b 4000k -minrate 800k -maxrate 6000k
[19:02:11 CET] <ren0v0> the stream where the JPEGs are generated from is set i believe to 8192 bitrate, not sure if that makes any difference
[19:09:34 CET] <furq> -profile high, -threads 0 and -minrate are all doing nothing in that command
[19:09:51 CET] <furq> replace -b 4000k with -crf 18
[19:10:29 CET] <furq> also probably get rid of -r 15
[19:10:58 CET] <furq> if you have -framerate set on the input then -r is redundant as well
[19:12:17 CET] <ren0v0> i see, is -crf in the docs?
[19:12:34 CET] <ren0v0> will be interesting to see how this effects filesize
[19:12:39 CET] <furq> -h encoder=libx264
[19:13:54 CET] <ren0v0> -h encoder=libx264 -codec:v libx264 -preset slow -crf 18         < so this ?
[19:14:27 CET] <furq> uh
[19:14:28 CET] <furq> no
[19:14:37 CET] <furq> you asked if crf was in the docs
[19:14:47 CET] <furq> -h is help
[19:16:31 CET] <ren0v0> doh
[19:16:38 CET] <ren0v0> what is FLT_MAX denoted by?
[19:22:30 CET] <furq> http://vpaste.net/yGbA7
[19:23:52 CET] <ren0v0> err
[19:24:40 CET] <ren0v0> so 18 is well within limits then :D
[19:24:58 CET] <ren0v0> so where are you picking 18 from, experience?
[19:25:34 CET] <furq> something like that
[19:25:55 CET] <furq> anything below 18 is overkill
[19:26:18 CET] <furq> i've never used anything below 20
[19:26:43 CET] <furq> obviously that doesn't stop some people from using 14 and then releasing their stupidity to the internet
[20:15:03 CET] <rexxster> I had a gstreamer->gstreamer stream setup, but due to distro upgrades my client gstreamer doesn't work anymore.  My distro includes MPV with a working vdpau implementation.
[20:15:05 CET] <rexxster> So, what I need from the experts here is a replacement mpv(ffmpeg pipeline) invocation for the client. http://pastebin.com/QAnXWLL3  I had no help in #mpv and was refered here by someone.
[20:51:22 CET] <acresearch> JEEB: are you still here?
[20:51:27 CET] <JEEB> never
[20:51:57 CET] <acresearch> haha, i tried your command (ffmpeg -i input.mkv -c copy -sn -movflags faststart out.mp4) but still the TV says not supported codec
[20:52:32 CET] <JEEB> then most likely the video format is not something that your TV supports, or it utilizes features not supported by the ASIC decoder in your TV
[20:53:14 CET] <acresearch> this is very complicated, and i don't know how to prevent it
[20:53:39 CET] <acresearch> the problem with TV is that i cannot just install a program for every codec out there
[20:54:09 CET] <JEEB> and due to it being low on computational strength (as it uses a HW ASIC decoder for most formats) you wouldn't even get too much help from sw decoders :P
[20:54:33 CET] <JEEB> now find out what profiles and levels of different video/audio formats it supports
[20:54:46 CET] <acresearch> JEEB: i am sorry, i do not understand what that means, i am not very professional in video codecs
[20:55:12 CET] <acresearch> let me see what the samsung tv likes to support
[20:55:26 CET] <JEEB> if it's samsung there is a list somewhere (most likely :P) on the profiles and levels of video,audio formats it supports
[20:55:36 CET] <JEEB> like H.264 up to high profile, level 4.1 or so
[20:56:25 CET] <acresearch> i found this, but i am not sure if it is my tv or not, http://www.samsung.com/uk/support/skp/faq/884733
[20:56:44 CET] <acresearch> i am not sure what my tv sub brand is, there are many samsung tvs
[20:56:44 CET] <JEEB> that's the containers
[20:57:38 CET] <acresearch> JEEB: this is better? http://samsung-galaxy-video-converter.blogspot.com/2016/01/best-video-format-for-samsung-smart-tv.html
[20:57:55 CET] <JEEB> no
[20:58:01 CET] <JEEB> usually it's in your manual
[20:58:09 CET] <JEEB> samsung should offer you the manual as PDF
[20:58:57 CET] <acresearch> the problem there are many different sumsung tv types, i am not sure which one is mine, (its not as easy as just searching iphone 7)
[20:59:21 CET] <JEEB> yes, I know. but for example in my case I could search for KS8005 for example :P
[20:59:58 CET] <JEEB> and yes, samsung also likes to use slightly different model numbers between continents just to make it that much easier to compare reviews
[21:00:42 CET] <JEEB> also you could post the output of `ffprobe file.mkv` in a pastebin or so
[21:00:48 CET] <JEEB> and link it here
[21:02:10 CET] <acresearch> JEEB: http://paste.ubuntu.com/24166543/
[21:02:42 CET] <acresearch> isn't there just a universal codec?
[21:03:10 CET] <JEEB> who the fuck encoded that thing...
[21:03:34 CET] <JEEB>  yuvj420p(pc, bt709) <- I'm pretty sure no broadcast or media source uses full range
[21:03:45 CET] <JEEB> (the *j* in there)
[21:03:46 CET] <acresearch> i don't understand
[21:04:01 CET] <JEEB> also I would deeply recommend you update your FFmpeg, 2.8.x is *old*
[21:04:30 CET] <JEEB> if you are just using the command line tools probably the simplest way for you would be to grab one of those static binaries linked around here every now and then
[21:04:44 CET] <JEEB> that way you can extract it and just run it by executing the full path
[21:05:02 CET] <JEEB> https://johnvansickle.com/ffmpeg/ seems to be it
[21:05:07 CET] <JEEB> but do note, I have never used these
[21:05:19 CET] <JEEB> since they get so often linked there they probably are OK, but just sayin'
[21:05:25 CET] <JEEB> s/there/here/
[21:06:44 CET] <acresearch> JEEB: i am sorry, i am completely lost, i have no idea what you are talking about, i am not a video professional, i just want to watch a movie in 4K HD
[21:07:22 CET] <JEEB> I'm just trying to take you one step a time towards a better experience :P
[21:07:26 CET] <JEEB> also how old is your TV :P
[21:07:35 CET] <acresearch> i bought it in 2014
[21:07:48 CET] <JEEB> ok, so forget about watching that video in any way or form as-is
[21:07:57 CET] <JEEB> HEVC stuff was added in 2015, I think?
[21:08:17 CET] <JEEB> also not sure if it will support 2160p too easily
[21:08:27 CET] <acresearch> hmmm
[21:08:49 CET] <JEEB> unless something specifically says it does, in which case you'll have good fun transcoding that to an older format
[21:09:33 CET] <JEEB> and that will take time as well as not be lossless (although not necessarily visible)
[21:10:48 CET] <acresearch> i am trying to find the serial number to identify it, but there is nothing
[21:11:04 CET] <acresearch> webites say it should be on the right, but there is nothing,,, so annoying!!!
[21:14:25 CET] <acresearch> JEEB: ok i found the model code: ua55f6400
[21:15:04 CET] <acresearch> JEEB: but this is the only page i get: http://www.samsung.com/uk/support/skp/faq/884733
[21:15:16 CET] <JEEB> not this? http://www.samsung.com/sa_en/consumer/tv-av/tv/full-hd/UA55F6400ARXUM/ :P
[21:15:23 CET] <JEEB> although this is for saudi arabia but seems similar enough
[21:16:24 CET] <acresearch> maybe it is, yes i am in saudi arabia
[21:16:42 CET] <feliwir> Hey, i don't quite understand how AVFrame->data works. Is it an array of buffers?
[21:16:44 CET] <acresearch> it looks like all their TV,   i do have a 55"
[21:16:49 CET] <feliwir> If so, where do they get allocated
[21:17:13 CET] <feliwir> because i can't find that for vp6 codec (the line where anything gets allocated)
[21:17:13 CET] <JEEB> feliwir: yes. as the https://ffmpeg.org/doxygen/trunk/structAVFrame.html says
[21:17:28 CET] <feliwir> JEEB, so where do the planes get allocated?
[21:17:28 CET] <JEEB> you should only care if you are creating the AVFrame yourself manually
[21:17:37 CET] <JEEB> decoder should be creating them for you
[21:17:55 CET] <JEEB> if you are creating them by yourself then you will have to utilize av_malloc etc
[21:18:05 CET] <feliwir> JEEB, i am trying to understand the vp6 decoder and that makes use of those buffers. But in the decoder itself those planes don't get allocated
[21:22:06 CET] <acresearch> JEEB: ok upgraded ffmpeg
[21:25:21 CET] <kubast2> If LAME - Lame Ain't an MP3 Encoder Ain't an MP3 Encoder ,how come LAME is an MP3 Encoder
[21:25:44 CET] <acresearch> JEEB: ok then what is the highest HD i can work with?
[21:25:51 CET] <JEEB> feliwir: https://ffmpeg.org/doxygen/trunk/group__lavu__frame.html#ga6b1acbfa82c79bf7fd78d868572f0ceb
[21:26:15 CET] <JEEB> this thing gets called based on some variables, as well as some decoders need to update the size
[21:34:08 CET] <feliwir> hm, never saw a call to that from vp6 decoder
[21:34:52 CET] <JEEB> yes, there are wrappers around it and formats that don't need to change width/height/pixel format on the fly wouldn't be needing it
[21:35:11 CET] <feliwir> just loads of av_frame_ref and av_frame_unref
[21:35:27 CET] <JEEB> generally at the point where avcodeccontext is initialized the framework knows various information on the data that's going to be pushed into the AVFrame
[21:35:30 CET] <feliwir> well but somewhere the memory still needs to be allocated
[21:35:43 CET] <JEEB> yes, after init and before decode() I would guess
[21:36:09 CET] <JEEB> and formats which would have to support different sizes and pixel formats on the fly most likely call a function that re-calls that one :P
[21:36:23 CET] <JEEB> (I would guess mostly H.264 supports that)
[21:36:48 CET] <JEEB> so in case of VP6 I would guess it just gets created and you don't need to be overriding it
[21:37:34 CET] <acresearch> JEEB: ?
[21:38:28 CET] <JEEB> acresearch: most likely something like this would work `ffmpeg -i input.mkv -c:v libx264 -preset veryfast -crf 21 -vf scale=1920:1080 -c:a copy -sn out.mp4` would work
[21:38:33 CET] <JEEB> uhh, wait
[21:38:52 CET] <JEEB> `ffmpeg -i input.mkv -c:v libx264 -preset veryfast -level 41 -crf 21 -vf scale=1920:1080 -c:a copy -sn out.mp4`
[21:38:58 CET] <JEEB> forgot the level definition :P
[21:39:09 CET] <JEEB> (41 gets parsed as 4.1)
[21:39:20 CET] <JEEB> anyways, that will take quite a bit of time
[21:39:44 CET] <JEEB> it will decode the video, and re-transcode it with libx264, preset veryfast :P
[21:39:48 CET] <acresearch> JEEB: no problem, thanks for your help, i hope it works, will update you when it finishes :-)
[21:39:59 CET] <JEEB> and before transcoding it will scale it down to 1080p
[21:40:06 CET] <acresearch> oh ok
[21:40:30 CET] <JEEB> it's a HD screen and I'd be surprised if your TV's ASIC could take 2160p AVC
[21:40:57 CET] <acresearch> oh ok, so my screen cannot handel more than 1080p?
[21:41:17 CET] <feliwir> JEEB, well for YUV 4:2:2 what would the size be? Just width*height?
[21:41:50 CET] <JEEB> depends on what sort of pixel format you're aiming for
[21:41:58 CET] <JEEB> additionall there's a helper for that so you don't have to do it yourself
[21:42:05 CET] <JEEB> (which I linked to you from the docs)
[21:42:14 CET] <acresearch> where is the helper in the tv or ffmpeg?
[21:44:57 CET] <feliwir> JEEB, i am not using the FFMPEG Api for my project
[21:45:03 CET] <feliwir> so i can't use that to allocate my frame
[21:45:22 CET] <JEEB> well good luck and have fun since you're as far as I can tell making your life much more painful for yourself
[21:45:29 CET] <feliwir> trying to do the Vp6 decoder in C#, so some ffmpeg functions don't help me
[21:45:33 CET] <JEEB> is C# FFI really that much of a trainwreck?
[21:45:49 CET] <feliwir> well i was told vp6 decoding is relatively simple
[21:45:53 CET] <feliwir> it's the worst^^
[21:46:12 CET] <feliwir> and then when doing cross platform development with C# i need native binaries for every platform
[21:46:14 CET] <JEEB> then how the flying fsck do people get away with the libmpv C# example, for example?
[21:46:20 CET] <JEEB> well yes
[21:46:53 CET] <JEEB> I mean, it's not like you can't really evade native libraries altogether. none of the UI libs are 100% .NET either
[21:47:32 CET] <feliwir> i am not doing UI. I am using OpenTK which gets away without native libraries :P
[21:48:31 CET] <JEEB> anyways, even if VP6 is simple it's probably going to bring you much more blood sweat and tears trying to implement it yourself
[21:48:50 CET] <JEEB> which is OK for a hobby project but for something that you're going to be distributing... not necessarily
[21:49:12 CET] <JEEB> also if it's a player then I recommend looking into libmpv if you can get an opengl context out of opentk
[21:52:14 CET] <feliwir> JEEB, it's just for a hobby project. I know ffmpeg is great and i always use it when i am doing C/C++. The problem is i am rewritting a game engine in C# and that particular engine uses the Vp6 codec :)
[21:52:51 CET] <JEEB> feliwir: basically if you are going to be publishing it and wanting people to use it I would just bite the bullet and require libavcodec et al
[21:52:58 CET] <JEEB> and just not show the videos if not found
[21:53:17 CET] <JEEB> if it's truly just a hobby thing which isn't supposed to be used by others and just for your learning - just fine :)
[21:53:22 CET] <JEEB> learning's fun and all
[21:55:11 CET] <feliwir> well it should eventually be used by others. But i only require a single codec/container combination
[21:55:36 CET] <feliwir> so i guessed before wrapping the entire ffmpeg library for C# i just go ahead and write that single codec & container myself
[21:55:49 CET] <JEEB> there's no single library :)
[21:56:01 CET] <JEEB> there's N libraries, most commonly used being libavformat and libavcodec
[21:56:31 CET] <feliwir> yea, you know what i meant :D But i would eventually require avfilter and swsresample aswell.
[21:57:04 CET] <feliwir> Also ffmpeg is lacking a vp6 encoder, so i thought when i write the decoder i might learn some useful things that i could put into an encoder
[21:57:24 CET] <feliwir> eventhough an encoder is probably X times more difficult
[22:00:34 CET] <JEEB> depends really, you can make a really limited encoder if you want
[22:00:50 CET] <JEEB> but yea, don't get my words wrong - learning these things is fun
[22:01:49 CET] <feliwir> yup. I think starting with H264 or something similiar would be much more complicated than vp6
[22:03:26 CET] <JEEB> I started with something even less complicated
[22:03:29 CET] <JEEB> Ut Video
[00:00:00 CET] --- Mon Mar 13 2017