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

[burek]

[11:13:51 CEST] <superware> AVPacket holds pts/dts, where can I find the corresponding time_base relating to the entire packet?
[13:56:22 CEST] <DHE> in the avformatcontext->streams[pkt-
[13:57:09 CEST] <DHE> in avformatcontext->streams[pkt->stream_index]->time_base iirc
[18:36:30 CEST] <jokoon> hello
[18:38:20 CEST] <jokoon> so scale="320:-1" requires -vf before it
[18:39:37 CEST] <another> was that a question?
[18:46:40 CEST] <jokoon> yes
[18:46:47 CEST] <jokoon> I guess it's a yes but nevermind
[18:46:48 CEST] <jokoon> Invalid pixel aspect ratio 5121/5120, limit is 255/255 reducing
[18:47:31 CEST] <jokoon> I realized what I wanted was scale="-1:320"
[18:47:58 CEST] <jokoon> converting from 264 to mp4
[18:48:09 CEST] <jokoon> I know it's wrong but Im doing it anyway
[18:48:56 CEST] <JEEB> also generally I would recommend -2 instead of -1
[18:49:19 CEST] <JEEB> since if you're converting to 4:2:0 etc you need the resulting value to be divisible by two
[18:49:47 CEST] <JEEB> since in 4:2:0 the chroma layers are stored in a single value for a 2x2 block
[18:49:51 CEST] <jokoon> mh ok thanks for the heads up
[18:50:34 CEST] <JEEB> and yes, that "scale=blah" thing is a filter chain
[18:50:52 CEST] <JEEB> so you either put it into a vf (video filter chain), or if you want more fancy things there's also the complex filter chain stuff
[18:51:00 CEST] <jokoon> any doc for that precise -2 ?
[18:51:05 CEST] <jokoon> ok
[18:51:29 CEST] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html#scale-1
[18:51:47 CEST] <jokoon> thanks
[18:51:47 CEST] <JEEB> > If one and only one of the values is -n with n >= 1, the scale filter will use a value that maintains the aspect ratio of the input image, calculated from the other specified dimension. After that it will, however, make sure that the calculated dimension is divisible by n and adjust the value if necessary.
[18:52:42 CEST] <jokoon> mmmh
[18:52:52 CEST] <jokoon> what if the input is not divisible by 2?
[18:53:12 CEST] <jokoon> should I use a n that is a multiple of the input?
[18:53:18 CEST] <JEEB> the input doesn't really matter
[18:53:26 CEST] <JEEB> this is just a calculation based on the input values
[18:53:43 CEST] <jokoon> I don't understand, why -2 instead of -1 then?
[18:53:55 CEST] <JEEB> that controls the output divisibility
[18:54:24 CEST] <jokoon> but anything is divisible by 1
[18:54:43 CEST] <JEEB> ok, so most video out there and most likely what you are pushing out is 4:2:0
[18:54:58 CEST] <JEEB> 4:2:0 is a way in YCbCr where the "black and white" (luma) has full resolution
[18:55:09 CEST] <JEEB> but then the color information is stored for a single value for a 2x2 block
[18:55:29 CEST] <JEEB> you cannot store images with the height/width not being divisible by two in 4:2:0
[18:55:43 CEST] <jokoon> ok
[18:55:46 CEST] <JEEB> if you set -1 you are not making sure your calculation output is divisible by two
[18:55:56 CEST] <JEEB> -2 is meant to help with that part
[18:56:16 CEST] <JEEB> because after the scaling your exact output value might be not divisible by two
[18:56:17 CEST] <JEEB> :P
[18:57:38 CEST] <jokoon> I thought that rule only applied for 264, not for mpeg
[18:57:52 CEST] <JEEB> it applies to anything coding in 4:2:0
[18:57:54 CEST] <JEEB> it's not the format
[18:58:01 CEST] <JEEB> like the video compression format
[18:58:13 CEST] <JEEB> H.264 for example supports everything from 4:0:0 to 4:4:4
[18:58:27 CEST] <JEEB> the first being "no color information at all" to "color information is full resolution"
[18:58:47 CEST] <JEEB> the reason why everyone uses 4:2:0 for video is because that's what everything most often supports :P
[18:59:13 CEST] <TheAMM> (where's my 4:1:1)
[18:59:40 CEST] <TheAMM> Or wait, does H.264 handle that too?
[19:02:02 CEST] <jokoon> scale="320:-2" will be a height of 320 right?
[19:02:13 CEST] <jokoon> no a width
[19:02:17 CEST] <DHE> width:height
[19:02:30 CEST] <jokoon> yes
[19:02:49 CEST] <DHE> 4:1:1 isn't listed as supported by libx264... 4:2:0 is the most common, being what hardware decoders are usually limited to and what broadcasts like TV and Youtube run
[19:03:10 CEST] <jokoon> what's better about 4:1:1 or 4:4:4 ?
[19:03:52 CEST] <DHE> 4:4:4 has full colour data for all pixels. any other (lower) number has adjacent pixels share at least some chroma data with each other
[19:04:22 CEST] <jokoon> so higher color restitution
[19:05:56 CEST] <jokoon> mmmmh so will I save space with 4:1:1?
[19:06:12 CEST] <TheAMM> Please don't use 4:1:1
[19:06:16 CEST] <TheAMM> Forget my joke
[19:06:17 CEST] <DHE> since x264 doesn't support it, yes since it will produce a 0 byte file
[19:06:24 CEST] <DHE> :)
[19:06:29 CEST] <jokoon> is there a way to save space when converting from 264 to mpeg4?
[19:06:44 CEST] <DHE> wait, what? why are you going from mpeg4 part-10 to part-2 ?
[19:06:57 CEST] <jokoon> Im converting to mpeg4 so I guess it doesn't matter?
[19:07:13 CEST] <jokoon> a device cant read 264
[19:07:19 CEST] <jokoon> it's a old nokia phone
[19:07:20 CEST] <DHE> what ffmpeg calls "mpeg4" is the video codec once known as divx back in like 2001
[19:07:31 CEST] <DHE> oh, my condolences.
[19:11:59 CEST] <JEEB> DHE: mpeg-4 part 2, which was the "original" MPEG-4 video codec in that set of specs. nobody probably thought back then that we'd have multiple :)
[19:12:14 CEST] <JEEB> you had pt1 for containers/system stuff
[19:12:17 CEST] <JEEB> pt2 for video
[19:12:22 CEST] <JEEB> pt3 for audio I think?
[19:12:53 CEST] <DHE> JEEB: my company has an IPTV product. whenever I hear "MPEG4" I had to mentally substitute "H264"
[19:13:18 CEST] <JEEB> yea, by now that makes sense :)
[19:13:26 CEST] <JEEB> since mpeg-4 part 2 more or less simmerred off
[19:13:50 CEST] <JEEB> or well, it's unfortunate but makes sense xD
[19:13:54 CEST] <DHE> and I'm largely okay with it, but then these little incidents happen with [really] old hardware or users getting confused
[19:49:13 CEST] <shibboleth> i've got a security camera which will only provide video over rtsp (h264) and only provide audio over http (pcm_ulaw). how can i run a background, respawning process to provide a muxed rtsp stream for a third party DVR?
[20:12:47 CEST] <dablitz> getaddrinfo(fc6f, 19): Name or service not known
[20:12:47 CEST] <dablitz> rtp://fc6f:19fc:d0ef:fdc0:f356:bf23:3bd4:854d:52000: Input/output error  <--- can I get some help. using ---> ffmpeg -f alsa -i hw:1,0 -acodec pcm_mulaw -f rtp rtp://fc6f:19fc:d0ef:fdc0:f356:bf23:3bd4:854d:52000
[20:23:33 CEST] <another> dablitz: try putting the ipv6 addr in brackets [ ]
[20:24:02 CEST] <dablitz> another thankyou I will try that
[20:24:31 CEST] <dablitz> that worked thanks
[20:46:57 CEST] <dablitz> ffmpeg -re -f alsa -i hw:1,0 -acodec pcm_mulaw -f rtp rtp://[fca4:b047:503e:3bfb:413c:5726:3a69:e82a]:52000 <--- this starts what it is suppose to start doing, but the other end --->  ffplay rtp://[fc6f:19fc:d0ef:fdc0:f356:bf23:3bd4:854d]:52000 produces this error ---> [rtp @ 0x7fe020000b80] Unable to receive RTP payload type 97 without an SDP file describing it
[20:47:21 CEST] <dablitz> Input #0, rtp, from 'rtp://[fc6f:19fc:d0ef:fdc0:f356:bf23:3bd4:854d]:52000':
[20:47:46 CEST] <dablitz> Duration: N/A, bitrate: N/A
[20:48:10 CEST] <dablitz> Failed to open file 'rtp://[fc6f:19fc:d0ef:fdc0:f356:bf23:3bd4:854d]:52000' or configure filtergraph
[21:05:37 CEST] <pranayvshah> Can someone please please help me with this issue - https://github.com/harfbuzz/harfbuzz/issues/1654
[21:07:23 CEST] <another> dablitz: look into rtsp
[21:09:12 CEST] <dablitz> another, this is something I am very new at. all I want to do is stream simple audio via ffmpeg point to point. would happen to have a good document on rtsp?
[21:10:10 CEST] <another> 'fraid not
[21:10:44 CEST] <another> i'm not an expert on this either
[21:10:44 CEST] <dablitz> ok i will continue to google
[21:12:32 CEST] <pranayvshah> I tried with Handbrake GUI and the output (the hindi subtitles) were rendered correctly. Tried the same with HandbrakeCli, that worked too. Adding the subs as a stream works fine too when I view the video through VLC media player
[21:30:54 CEST] <pranayvshah> Can someone please please help me with this issue - https://github.com/harfbuzz/harfbuzz/issues/1654 . I tried with Handbrake GUI and the output (the hindi subtitles) were rendered correctly. Tried the same with HandbrakeCli, that worked too. Adding the subs as a stream works fine too when I view the video through VLC media player
[21:51:00 CEST] Last message repeated 1 time(s).
[21:55:30 CEST] <pink_mist> please don't repeat yourself this much
[21:55:40 CEST] <pink_mist> at least wait a couple of hours between asking
[21:56:43 CEST] <pranayvshah> Sorry about it, I am new to IRC chat and I was not sure my message was even being broadcast
[21:58:27 CEST] <Ariyasu> set utf-8
[21:59:10 CEST] <pranayvshah> My file is UTF-8 encoded and ffmpeg subtitles documentation says that is the default anyway.
[22:00:10 CEST] <Ariyasu> -sub_charenc UTF-8
[22:00:16 CEST] <Ariyasu> ok
[22:00:38 CEST] <Ariyasu> i remember mkvmerge never set it and always used system default which screwed up a ton of sub files rendering for years
[22:01:13 CEST] <pink_mist> it wouldn't screw up like his screenshots show though.
[22:02:32 CEST] <pranayvshah> Just tried with the charenc set to UTF-8, did not make a difference
[22:03:02 CEST] <Ariyasu> so Glyph 0x74 not found in your font
[22:03:13 CEST] <Ariyasu> i take it thats the character that gets messed up?
[22:04:26 CEST] <pranayvshah> No, that's not the character which is getting messed up
[22:08:47 CEST] <pink_mist> Ariyasu: it's just a little line on top of the characters that gets put in the wrong place (or at least that's what it looks like to me who can't tell front from back of any of those characters)
[22:21:25 CEST] <pranayvshah> Hey sorry, is the difference clearer with this picture - https://res.cloudinary.com/qblm/image/upload/v1554668448/Annotation_2019-04-03_171815.jpg
[23:19:27 CEST] <f3ndot> Curious: is there a timeline for the 4.2 release? where can such information be obtained?
[23:23:36 CEST] <JEEB> I don't think there is
[23:23:57 CEST] <JEEB> releases are cut every N months, at semi-random spots
[23:43:34 CEST] <coolhp48> Hi JEEB. Thank you for your help yesterday. You did point me in the right direction. Those AAC frames I was trying to decode were indeed RAW AAC without the ADTS headers. I ended up just reconstructing an ADTS header and adding that to every frame I received before passing it to the AV_CODEC_ID_AAC decoder.
[23:43:50 CEST] <coolhp48> It works like a charm.
[23:46:07 CEST] <JEEB> nice
[23:51:03 CEST] <coolhp48> Now I'm stuck with another issue and I have no idea of where to get started with this : In the framework I'm working off of, I'm given a uint8_t* pointer called "sampleBuffer". This is actually an array of pointers, one per channel. Each channel has a pointer to an uint8_t that is supposed to be where I should write the RAW PCM. But the AV_CODEC_ID_AAC decoder gives me float32s instead of uint8s and I have no
[23:51:04 CEST] <coolhp48> idea of how to overcome that.
[23:51:28 CEST] <coolhp48> This is very poorly explained... probably because I myself arent sure of what I'm dealing with here.
[23:52:58 CEST] <coolhp48> Is it possible to convert 32bit float PCM to 8bit unsigned int PCM on the fly ?
[23:53:20 CEST] <JEEB> yes
[23:53:37 CEST] <JEEB> either via swresample with the AVFrame API, or through libavfilter audio filtering which utilizes swresample in the background
[23:53:53 CEST] <JEEB> which in both cases means that you feed the resampler the AVFrame you get from decoder
[23:54:03 CEST] <JEEB> and you get another AVFrame back
[23:54:30 CEST] <coolhp48> Aha ! That sounds promising. I'm going to look into it right away. Thanks JEEB !
[23:54:48 CEST] <JEEB> :)
[23:55:34 CEST] <coolhp48> Is examples/resampling_audio.c what I should be looking at as a roadmap ?
[00:00:00 CEST] --- Mon Apr  8 2019