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

[burek]

[00:01:21 CEST] <nickster> ffserver command not found? Every solution I find just states to install ffmpeg but I already have that installed.
[00:02:01 CEST] <another> ffserver has long been deprecated and recently dropped
[00:03:40 CEST] <nickster> is it still possible to output to a website like with ffserver?
[00:15:17 CEST] <another> output to a website? what do you mean by that
[00:20:37 CEST] <nickster> ffserver gave one the option to throw up an http host or something, by the looks of it, and ffmpeg can stream right to it.
[00:20:49 CEST] <nickster> It seems I am just going to have to work with udp/rtmp
[00:21:34 CEST] <kepstin> for modern setups you normally want to serve up e.g. hls or dash for live streaming, and ffmpeg can output that directly to a directory, and any webserver works
[00:21:55 CEST] <kepstin> or you can use something like the nginx-rtmp module, that's pretty popular
[00:23:50 CEST] <another> or something like icecast
[00:36:29 CEST] <friendofafriend> Yeah, icecast works great with MPEG-TS.
[02:33:13 CEST] <analogical> I
[02:34:51 CEST] <analogical> I've noticed something strange. Using ffpmpeg to download a files is much faster on Windows 10 and on Linux than it is on Windows 7 using the same computer.
[02:35:26 CEST] <analogical> there shouldn't be any difference should there?
[02:36:44 CEST] <another> hmm.. maybe the overhead of process spawning on windows?
[02:37:47 CEST] <another> but that should apply to w10 too
[06:09:35 CEST] <logicWEB> huh, curious. "... [a]; color=c=black:s=whatever:d=whatever [b]; [1][a] alphamerge [c]; [b][c] overlay" is almost twice as fast as just "... [a]; [1][a] blend=c0_mode=multiply"
[07:09:05 CEST] <Mrjoker>  what is better ?  720p or 1080i
[07:21:16 CEST] <Buster> if deinterlacing is enabled then 1080i is better
[07:23:18 CEST] <Mrjoker> buster can you even see the video if "deinterlacing" is not "enabled"?
[07:25:16 CEST] <Buster> if there are a lot of dynamic scenes, it will look bad
[08:27:33 CEST] <another> aaand he's back
[09:16:45 CEST] <aleek> sup guys! ABR live streaming here! So I am able to generate a mp4 segment file with one frame - h264 key frame. I'd like to covert it to png/jpg/bmp - without ffmpeg. Code should be in c/c++. Any ideas?
[09:17:07 CEST] <aleek> I have trouble finding any valuable information on the Internet ;(
[09:21:20 CEST] <aleek> As I understand now, I have to dig into mp4's mdat segment, and treat it as h264 block
[14:00:25 CEST] <kepstin> aleek: in order to turn that frame into a png/jpg/whatever, you're going to need an h264 decoder
[14:01:02 CEST] <kepstin> aleek: probably the easiest h264 encoder to get is the one built in to ffmpeg... so why not just use ffmpeg?
[14:02:15 CEST] <another> ffmpeg has no builtin avc encoder. it uses libx264
[14:03:03 CEST] <kepstin> er, typo. i meant decoder
[14:03:04 CEST] <another> oh wait. i think you meant DEcoder
[14:28:27 CEST] <aleek> so I can use x264 lib in this case
[16:12:52 CEST] <Hello71> no.
[16:13:04 CEST] <Hello71> well you can but it won't really help
[16:14:37 CEST] <kepstin> aleek: x264 is an encoder only, it's not a decoder
[18:49:54 CEST] <logicWEB> MrJoker: there's a trade-off to be made between the different options. 720p video will always "play nicely", with the caveat that you only have 720 scans of video. this is actually pretty good, really, but if you're frequently watching 1080p or 2160p content on a very large screen, your eye might be attuned enough to notice a slighty fuzziness about 720p video
[18:50:04 CEST] <logicWEB> MrJoker: but... 1080i has some challenges in being played back well. an interlaced format presenting X frames per second is actually really 2X frames per second, but you're only getting half of each frame. so, with 30fps 1080i, you'll get a new picture 30 times per second, but each picture has (e.g.) all the even scans from one frame and the odd scans from another frame that comes after
[18:50:20 CEST] <logicWEB> MrJoker: if you just play it like that, you'll see "combing" during motion, which, I mean, it's totally _possible_ to just put up with it and still enjoy the content, but it can be really annoying
[18:50:31 CEST] <logicWEB> MrJoker: the other way to play 1080i content is to use a "deinterlacer", which splits that combined frame apart into the "parts of" the two original frames it was made up from. since each of these is only _half_ the original frame (even scans vs. odd scans), they aren't called "frames" per se, but "fields" of the combined frame in the 1080i source
[18:50:59 CEST] <logicWEB> MrJoker: these split-out fields will then typically be played by using a heuristic to "guess" the pixels from the scans that aren't part of the field. so, basically, you're taking 540 scans and "guessing" the other 540 in between. the result is a frame with 1080 scans to put on your screen, but it doesn't actually have 1080 rows of detail. it's essentially 540 rows of detail
[18:51:13 CEST] <logicWEB> MrJoker: so, you can think of 720p 30fps as just that, 720p 30fps, but 1080i 30fps as really more like 540p 60fps
[18:51:35 CEST] <logicWEB> MrJoker: in my personal opinion, just going with 720p is a better experience than the artefacts that result from deinterlacing 1080i video
[18:51:57 CEST] <logicWEB> MrJoker: but... this loss of resolution only happens vertically, so from left to right, a 720p video has 1280 pixels, while a 1080i video has 1920 pixels, so even though the 1080i video may be less sharp vertically, it can still be more sharp horizontally
[18:52:16 CEST] <logicWEB> MrJoker: if you're trying to make a decision, I recommend trying it both ways and making a value judgment based on your own personal experience
[18:53:59 CEST] <logicWEB> one thing I've seen is naively-encoded interlaced video where the frame is treated as progressive, and _that_ makes a mess because the combing is generally far too high frequency to fit into the bitrate constraints -- the result is that the fields interfere with each other, so even after they're split out by the deinterlacer, each one can suffer from a "ghost" of the other frame
[18:54:21 CEST] <logicWEB> I don't have firsthand experience, but I'm pretty sure with proper settings, the encoder doesn't try to naively encode the alternating scans this way, and the issue _can_ be avoided
[19:07:28 CEST] <irwiss> is it normal to get sporadic AVFrames where values for pts look like -9223372036854775808 1 90000 ? (pts first, the other 2 are time based num/denominator) do i just throw away such frames or i can somehow estimate pts in another way?
[19:07:45 CEST] <irwiss> time base*
[19:10:06 CEST] <JEEB> is it the NOPTS value?
[19:10:26 CEST] <JEEB> AV_NOPTS_VALUE
[19:12:58 CEST] <ChocolateArmpits> logicWEB, I find that with proper deinterlacing 1080i to be markedly better than 720p50/60. When having to key greenscreen footage the higher resolution really goes a mile. It's only really with poor deinterlacing that issues crop up. I personally advocate for QTGMC when quality is concerned.
[19:15:15 CEST] <DHE> I've seen some mpegts streams where some packets have no timing data at all...
[19:15:32 CEST] <JEEB> yes
[19:15:45 CEST] <JEEB> for teletext f.ex. PTS is optional IIRC
[19:16:04 CEST] <JEEB> so then all you can do is put it somewhere around pcr
[19:21:02 CEST] <irwiss> NOPTS_VALUE seems to be 0x8000000000000000 which i guess is -1 signed? that weird -922.... number is sitting inside the frame->pts, and as far as i can see the stream does have pts usually, but some frames come with mangled one :(
[19:25:30 CEST] <irwiss> yep looks to be no pts value for one specific frame
[19:26:36 CEST] <DHE> JEEB: I've seen one feed where this is happening in the h264 video stream... :/
[19:27:09 CEST] <DHE> 0x8000000000000000 is the smallest possible integer. -1 has representation 0xFFFFFFFFFFFFFFFF
[19:29:39 CEST] <irwiss> oh right, largest positive, but well the pts value on some frames appears to have the no_pts constant, while previous frame and the next appears to be fine, and time base is also preserved, guess i need to throw away the pts on frames like these if they come in a stream that normally provides pts
[21:12:50 CEST] <kepstin> irwiss: consider using av_frame_get_best_effort_timestamp() which might give you something a bit more usable
[21:13:55 CEST] <kepstin> er, let me double check that function name, i had some really old ffmpeg docs open
[21:15:45 CEST] <irwiss> i think i used that before, but upgraded to 4.1 recently it claimed to be obsolete, unless i still need it
[21:16:03 CEST] <kepstin> ah, just read the best_effort_timestamp directly from the frame struct now
[21:45:25 CEST] <logicWEB> ChocolateArmpits: mm, yeah I guess it really make a big difference what you're using it for. but, it is really important that it be done right in the first place. here's a concrete example of it being done _really not right_:
[21:45:27 CEST] <logicWEB> https://imgur.com/a/wGezjnG
[21:46:01 CEST] <logicWEB> the first image comes off of the DVD of Pink Floyd's The Wall, that's exactly how the frame is on the DVD (except resized from 720x480 to 853x480 for aspect ratio)
[21:46:24 CEST] <logicWEB> but the DVD is encoded as though it is progressive, and it just can't accurately represent the stark contrast from one scan to the next as it flips between the fields
[21:46:46 CEST] <logicWEB> the second and third images are reconstructions of the fields (just using bicubic interpolation after extracting the relevant scans)
[21:47:23 CEST] <ChocolateArmpits> I'd expect such a source to be telecined albeit with a field shift
[21:51:21 CEST] <ChocolateArmpits> But while that's more common with improperly prepared DVD material, I don't really think high definition suffers from such mistakes simply because of more format options in terms of delivery. In my case having control over the video format makes for no problems in further interlace processing
[00:00:00 CEST] --- Fri Apr 19 2019