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

[burek]

[00:12:43 CEST] <faLUCE> DHE: it seems that if I force a keyframe, while encoding, the global quality decrease and remains with that lower quality
[00:13:20 CEST] <DHE> keyframes are large. forcing them will negatively impact quality.
[00:13:38 CEST] <faLUCE> DHE: ok, but why that quality remains bad forever?
[00:13:57 CEST] <DHE> you don't get stuck using keyframes the whole way from then on are you?
[00:16:52 CEST] <faLUCE> DHE: you are right again
[00:17:07 CEST] <faLUCE> so, How can I unset AV_PICTURE_TYPE_I ?
[00:17:43 CEST] <faLUCE> (on pict_type)
[00:18:07 CEST] <faLUCE> AV_PICTURE_TYPE_NONE ?
[00:18:24 CEST] <DHE> yeah
[00:18:25 CEST] <JEEB> yes, anything that is not I/P/B goes to default
[00:18:35 CEST] <JEEB> which is X264_TYPE_AUTO
[00:20:26 CEST] <DHE> it's worth noting there's a special setting for x264 that makes I frames into IDR frames, which may be what you want
[00:21:15 CEST] <faLUCE> what a asshole I was ;-). x264 was soo good that I even did note that all were keyframes...
[00:21:22 CEST] <faLUCE> I did not note
[00:23:07 CEST] <DHE> called it
[02:52:30 CEST] <Ariyasu> maybe offtopic question
[02:52:48 CEST] <Ariyasu> if my display is set to 2160p and im playing a 1080p video
[02:53:19 CEST] <Ariyasu> what is handling the upscaling to 2160p? the media player? the display itself? the os?
[02:55:01 CEST] <tlacatlc6> that'd be the media player
[03:40:05 CEST] <dongs> uh, depends completely on what is playing, and waht mode etc.
[03:42:45 CEST] <Hello71> if you have dpi scaling on your media player that's a shit media player
[03:43:20 CEST] <Ariyasu> i use mpc-hd with lav and playing back a m2ts from bluray
[03:43:30 CEST] <Ariyasu> i was just curious what was handling the scaling
[03:43:35 CEST] <klaxa> the most sane way would be some scaling filter in the player
[03:43:39 CEST] <Ariyasu> mpc-hc*
[03:43:43 CEST] <klaxa> and that's what probably all do
[03:44:01 CEST] <klaxa> you can make the OS scale it by reducing the screen resolution
[03:44:18 CEST] <klaxa> the display should only output what it is fed
[03:44:52 CEST] <klaxa> having the scaling done in the player adds the advantage that you can choose how to scale
[03:45:29 CEST] <klaxa> also probably less syscalls if you had to call the OS to scale
[03:51:37 CEST] <dongs> yeah but like, if youre in fullscreen exclusive mode it could be your gpu or your monitor
[03:52:00 CEST] <dongs> Hello71: dpi has nothing to do with this
[03:52:06 CEST] <klaxa> wouldn't that scale on OS level then?
[03:52:19 CEST] <dongs> thats what im saying, theres not enough information in the question to ansewr
[03:52:42 CEST] <klaxa> i think there is enough information
[03:52:44 CEST] <dongs> "i play back 1080p video on 2160p screen, what is doing the scaling"? answer: could be anything depending on how its done
[03:52:59 CEST] <dongs> klaxa, what if its not even fullscreen
[03:53:02 CEST] <dongs> then there's no scaling.
[03:53:03 CEST] <klaxa> ><Ariyasu> i use mpc-h[c] with lav and playing back a m2ts from bluray
[03:53:22 CEST] <klaxa> ><Ariyasu> what is handling the upscaling to 2160p? the media player? the display itself? the os?
[03:53:34 CEST] <dongs> decoder will output 1080p, eihter renderer or gpu or monitor will be scaling
[03:53:45 CEST] <dongs> depending on screen mode
[03:53:46 CEST] <klaxa> should probably be a setting in the player
[03:56:32 CEST] <Hello71> the question specifically says "set to 2160p"
[03:57:57 CEST] <dongs> the real answer is nobody gives a shit cuz you wont notice the difference anyway.
[03:58:00 CEST] <dongs> :)
[03:59:01 CEST] <klaxa> blasphemy!
[12:08:18 CEST] <sadasaulna> Hi.  Is the warning "[mp3float @ 0x7f7ff7b03800] Could not update timestamps for skipped samples." something I should worry about?
[12:36:57 CEST] <DHE> it probably means the file is damaged. mp3 is recoverable with some glitchy sound where the damage is...
[13:45:19 CEST] <ozette> Does anyone know if MPEG-4 Part 2 can be decoded by browsers? I got a .mp4 here, which won't play in chrome nor firefox. It was "converted" from a .mpeg, I don't know how exactly, but supposedly 4videosoft's 'video converter' was used
[13:45:39 CEST] <ozette> Chrome says: Resource interpreted as Document but transferred with MIME type video/mp4
[13:46:03 CEST] <ozette> Firefox says a whole lot and then: No MP4 audio () or video () tracks
[13:46:49 CEST] <furq> no it can't
[13:46:53 CEST] <ozette> MediaInfo shows 'Video' in Tree view and under that: Format: MPEG-4 Visual
[13:46:58 CEST] <ozette> oh
[13:47:31 CEST] <furq> mpeg-4 part 2 is like divx/xvid etc
[13:47:46 CEST] <furq> browsers will generally only decode h.264 (mpeg-4 part 10 if you want to be technical)
[13:47:52 CEST] <furq> at least in mp4
[13:47:59 CEST] <ozette> Yea I noticed
[13:48:17 CEST] <ozette> I'm not familiar with divx or vidx codecs
[13:49:32 CEST] <ozette> Thanks :)
[17:43:26 CEST] <pkeroulas_> I'd like to convey closed captions in flv/rtmp stream. It is suggested to use AMF messages and more precisely "onCaptionInfo" event to do that. Is there any support/example/doc in ffmpeg for that use case?
[17:47:15 CEST] <pkeroulas_> apparently, the flv decoder can handle such messsages but not the encoder
[18:26:26 CEST] <zerodefect> When scaling YUV420p with sws_scale() (using C-API), do I have to make any explicit considerations for chroma subsampling when setting up the scaler? I'm getting a crash, but I can't quite put my finger on the problem.
[18:31:57 CEST] <DHE> the input data fields need to be arrays of pointers. maybe you're providing the wrong frame fields?
[18:35:19 CEST] <zerodefect> Well, what's interesting is my logic works for YUV422P but not YUV420P. In my height calculations, I'm not taking chroma subsampling into consideration, but I think that is ok. The problem is definitely my side, but just trying to corner it.
[18:50:23 CEST] <DHE> I just call sws_scale(scaler, (const uint8_t* const*)source_frame->data, source_frame->linesize, 0, input_h, frame->data, frame->linesize); // source source_frame is the input, and frame is the output. I'm going 420p to 420p but it's been fine for me...
[18:55:04 CEST] <Mavrik> linesize array is the prime suspect there
[19:28:05 CEST] <dablitz> start : --->  ffmpeg -f alsa -i hw:1,0 -acodec libopus -ar 8000 -sdp_file sdp -f rtp rtp://192.168.100.21:52000
[19:28:05 CEST] <dablitz> <dablitz> and when i play : ---> ffplay -nodisp rtp://192.168.100.20:52000
[19:28:05 CEST] <dablitz> <dablitz> it should allow the audio to stream from one computer to the next. I do get cli showing stings are happening on the sending side...but nothing on the recieving side
[19:28:05 CEST] <dablitz> * alex`` (~alex at aputeaux-651-1-292-49.w86-249.abo.wanadoo.fr) has joined
[19:28:05 CEST] <dablitz> <dablitz> ffplay just sits :  nan    :  0.000 fd=   0 aq=   0KB vq=   0KB   f=0/0
[19:39:29 CEST] <siperman> hello
[19:40:15 CEST] <siperman> i need some help with ffmpeg running on ubuntu
[19:40:28 CEST] <siperman> i am using it to make an udp stream
[19:41:18 CEST] <siperman> i have a problem with the packet creation, and i read on the wiki that i need to apply a patch
[19:41:25 CEST] <siperman> i downloaded the patch
[19:41:36 CEST] <siperman> but i dont know how to apply it
[19:43:42 CEST] <DHE> for mpegts?
[19:44:42 CEST] <siperman> yes
[19:45:49 CEST] <siperman> i have a problem when i use the pkt_size=1316, the files are not constant sized, is well known problem and auser create a patch, but i dont know how to apply it
[19:47:32 CEST] <DHE> I see... I've not actually had that as a problem though. nothing's complained about the packet sizes
[19:49:29 CEST] <siperman> did you need to apply a patch in the past?
[19:50:47 CEST] <DHE> I see small packets from time to time. but there's been nothing on the network complaining about it so I've just ignored it as a non-issue
[19:50:54 CEST] <DHE> curious what you have that's causing you grief
[19:53:26 CEST] <siperman> the problem is because i am trying to send the feed to an equipment that i am thinking is the decoder from hell
[19:53:40 CEST] <siperman> but the decoder doesent see the udp packets
[19:54:14 CEST] <DHE> multicast?
[19:54:33 CEST] <siperman> the brand and the model os the decoder is Ateme Kyrion DR5000
[19:54:48 CEST] <siperman> no, i am sending as an unicast
[19:55:02 CEST] <siperman> i am sending the packags directly to the decoder
[21:21:52 CEST] <zerodefect> @DHE / @Mavrik - Silly mistake with my YUV420p scaling problem - the height of the frame was not a multiple of 2 so the scaler was reading off the end of the buffer :(
[21:23:51 CEST] <pranayvshah> Can anyone please help me with an issue regarding burning Indic subtitles into a video. Works perfectly fine with Handbrake GUI and CLI and also when the subtitles are added as a stream instead of burning them into the video.
[23:36:16 CEST] <Hackerpcs> reading about AAC encoding https://trac.ffmpeg.org/wiki/Encode/AAC , it says about using a higher cutoff "keeping in mind that a higher limit may audibly reduce the overall quality." why is that?
[23:42:49 CEST] <furq> because you're encoding more data at the same bitrate
[23:46:26 CEST] <Hackerpcs> what could possibly be a good combination of the highest available cutoff and bitrate for fdk acc to achieve transparency?
[23:46:37 CEST] <Hackerpcs> highest is 20k
[23:46:41 CEST] <furq> if you just want no cutoff then use -vbr 5
[23:48:00 CEST] <Hackerpcs> that works, it goes over 20k too
[23:50:07 CEST] <Hackerpcs> thanks!
[00:00:00 CEST] --- Wed Apr 10 2019