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

[burek]

[00:21:37 CET] <nevcairiel> JEEB: looking at the libc ML there, he really never got a hard no, apparently he just didnt push for it any further
[00:23:03 CET] <JEEB> yea
[00:23:18 CET] <nevcairiel> even the guy with the initial no said he wouldnt have any problems with it if someone elses agrees
[00:23:56 CET] <JEEB> yup, too bad the guy had already taken the thing as NACK and then people went with "yeah, that's probably a good idea" with regards to the linuxtv thing
[00:24:06 CET] <JEEB> also I just took a look at the code there
[00:24:13 CET] <JEEB> the use of macros is interesting
[00:24:22 CET] <nevcairiel> its a hundred year old gnu-adjacent code
[00:24:23 CET] <JEEB> and how I guess the included .c file generates the module
[00:24:26 CET] <nevcairiel> better have eye soap ready
[00:24:33 CET] <JEEB> from all those defines
[00:47:21 CET] <cone-791> ffmpeg 03Michael Niedermayer 07master:1e59071aad95: avcodec/ac3: Explicitly return to discard large amounts of nonsense bytes
[00:47:21 CET] <cone-791> ffmpeg 03Michael Niedermayer 07master:1aa796bc9c65: avcodec/mpegvideo_enc: Use av_assert1() instead of assert() in merge_context_after_encode()
[00:47:21 CET] <cone-791> ffmpeg 03Nikolas Bowe 07master:2b8458fcc5d5: avformat/movenc: Add more error checking when writing sample entries.
[10:47:39 CET] <ubitux> i have a mp4 sample (generated with ffmpeg) with multiple aac audio frames in its packets
[10:47:46 CET] <ubitux> like, 2 audio frames in every packets
[10:47:57 CET] <ubitux> does anyone have any clue what's the cause of this?
[10:48:33 CET] <ubitux> it's not causing much issue to ffmpeg for playback (except a warning), but it's causing trouble for the rest of the world
[10:48:58 CET] <nevcairiel> i would think that even ffmpeg couldnt play raw aac when the packet boundaries are broken
[10:49:13 CET] <nevcairiel> because it lacks sync markers
[10:49:48 CET] <ubitux> it seems mpv and ffplay are able to deal with this; on other players you typically get a full speed playback or whatever similar madness
[10:50:02 CET] <ubitux> i'm just curious how we could end up with such a file generated by ffmpeg
[10:50:07 CET] <ubitux> (Lavf58.12.100)
[10:50:44 CET] <nevcairiel> well if a file  was like that and you used stream copy, it might seem like ffmpeg caused this
[10:50:49 CET] <nevcairiel> not sure how encoding would result in that
[10:51:18 CET] <ubitux> oh, stream copy mmh
[10:51:32 CET] <ubitux> like, stream copy from mpeg ts or something like that?
[10:52:07 CET] <nevcairiel> any source really i guess
[10:53:02 CET] <nevcairiel> although a clue would be if the second frame has an ADTS header
[10:53:14 CET] <ubitux> but the source would already have this audio frame pairing in the first place, or it's the stream copy that would have cause this?
[10:53:38 CET] <ubitux> (and if it's the source, in what situation would it be valid?)
[10:54:04 CET] <nevcairiel> raw aac frames without packet boundaries are really never valid
[10:54:29 CET] <nevcairiel> what I could imagine happening is that the origin stream was ADTS, which has sync markers and therefor can exist without containers 
[10:54:38 CET] <nevcairiel> and a conversion of that went wrong somewhere
[10:57:44 CET] <ubitux> ok, i'm going to check that ADTS header, thank you !
[11:02:19 CET] <ubitux> http://b.pkh.me/p/2019-02-07-110147-thuw8Ees
[11:02:23 CET] <ubitux> i don't see any sync word
[11:09:48 CET] <ubitux> cuts are systematic, but look pretty much random 371/743 476/986 487/978 452/876 ...
[18:28:52 CET] <kevinnn> hey does anyone know if libav can be used to create an rtsp stream? Can libav be an rtsp server?
[18:33:37 CET] <JEEB> there's an rtsp input/output format as far as I can see :P
[18:33:56 CET] <JEEB> what you define as "rtsp server" is a whole separate discussion of course
[18:34:01 CET] <JEEB> and IIRC rtsp is a mess
[18:35:34 CET] <kevinnn> why would you say rtsp is a mess?
[18:36:00 CET] <JEEB> what some vendor means with "rtsp" can mean something completely different to another
[18:36:58 CET] <JEEB> that's why there's live555 for example which is an old and probably the most compatible thing for RT(S)P
[18:37:02 CET] <JEEB> but yea, it's a mess :P
[18:37:25 CET] <kevinnn> I am currently using live555 as my rtsp server, but unfortunately because the way the code is structured (with a bunch of classes and abstract functions) it makes integrating with my current code base a struggle
[18:37:44 CET] <kevinnn> the abstract functions don't let me pass along any parameters I want to
[18:38:00 CET] <kevinnn> and because classes are initialized and deleted often during the life time of the stream
[18:38:11 CET] <kevinnn> passing data to live555 is very difficult
[18:38:33 CET] <kevinnn> I basically had to create a bunch of global static variables to pass data into live555
[18:39:01 CET] <kevinnn> I was hoping for a simpler solution but is live555 basically my best option?
[18:39:12 CET] <kevinnn> If I want a UDP stream for video
[18:39:30 CET] <JEEB> I have no idea. I see the input and output modules so you should be able to check if those contain the features you require
[18:39:47 CET] <kevinnn> I considered rtmp for a while but since it transmits video using tcp I figured it would be prone to more latency than rtsp
[18:40:04 CET] <kevinnn> what do you mean input and output modules?
[18:40:08 CET] <kevinnn> can you link me?
[18:40:17 CET] <JEEB> libavformat/rtsp*.c
[18:40:39 CET] <JEEB> you use those when you open an AVFormatContext with rtsp://
[18:40:56 CET] <kevinnn> any nice examples implementing these?
[18:41:20 CET] Last message repeated 1 time(s).
[18:41:20 CET] <kevinnn> also I only see libavformat/rtsp.c
[18:41:23 CET] <kevinnn> nothing else
[18:41:35 CET] <JEEB> rtspenc.c?
[18:41:52 CET] <JEEB> rtspdec.c?
[18:42:08 CET] <JEEB> anyways, I've only used rtsp in FFmpeg for reading
[18:42:25 CET] <JEEB> and in that case you just made sure if you were using UDP or TCP, and then passed on the URL
[18:42:36 CET] <JEEB> nothing special as far as API-wise usage goes
[18:42:45 CET] <kevinnn> hmm, I see a bunch of references to tcp in that source file...
[18:43:00 CET] <JEEB> yes, there's an option to either use TCP or UDP
[18:43:12 CET] <kevinnn> the comments suggest otherwise
[18:43:40 CET] <JEEB> rtsp.c AVOption rtsp_transport
[18:44:00 CET] <JEEB> which seems to utilize the variable lower_transport_mask
[18:46:04 CET] <JEEB> anyways, most UDP output I've done so far has just been plain old UDP with MPEG-TS
[18:47:04 CET] <kevinnn> okay thanks, I'
[18:47:13 CET] <kevinnn> ll keep digging around
[20:00:43 CET] <Mathieu_Du> before making more mess on the ML, I guess I should ask here, when updating a proposed patch should it be send in a new thread? as a reply? if so to what post?
[20:02:11 CET] <JEEB> I generally do an in-reply-to to the original patch, and first format-patch it out, to modify the [PATCH] header to [PATCH vXYZ]
[20:02:30 CET] <JEEB> that way people can separate it from the previous version(s)
[20:03:14 CET] <JEEB> see for example the libaribb24 thread I've been recently posting in
[20:03:22 CET] <JEEB> (has versions 2,3 there)
[20:04:04 CET] <JEEB> also format-patching means you can add comments after the --- line, but before the first diff
[20:04:11 CET] <JEEB> (unless I've been getting that wrong 8))
[20:05:49 CET] <Mathieu_Du> oh I see, so you don't pass a commit name to git send-email ?
[20:06:52 CET] <JEEB> I either note a directory, or a specific format-patch patch if I need to add comments or a preface
[20:07:03 CET] <Mathieu_Du> some info on this would probably be make for a useful update to doc/developer.texi :)
[20:07:50 CET] <JEEB> if I don't need to add comments etc I just do git send-email --suppress-cc=all master..HEAD or something :)
[20:08:13 CET] <JEEB> cc suppression just to make sure I don't cause random spam to people :)
[20:08:40 CET] <Mathieu_Du> I see, thanks :)
[20:08:55 CET] Action: Mathieu_Du refrains from addressing the elephant in the room
[20:09:15 CET] <nevcairiel> great, now the elephant is lonely again
[20:11:05 CET] Action: Mathieu_Du pats the elephant
[00:00:00 CET] --- Fri Feb  8 2019