Ffmpeg-3.14 has such a hole in the bug.

Tag: Log time manual order TOC str flags requires streams

Recently I use the downloaded ffmpeg-3.14 code to compile their own use, did not expect to encounter such a low-level pit.
I use my own compiled library will always be in the upload video with RTSP collapsed, at first I thought I compiled the x264 problem, because I was bypassing the use of Pkg-config, manually modified the Configure file. But no matter, I re-unzip the code compiled without the other three-party encoding library version, the same result occurs.
The result is that I compiled the library with this code package, only with RTSP as input but not as output. No other better way, had to look at the Code +gdb debugging.
The process is not much to say, time or time, it takes a lot of time.
program in and flow server completed Option,announce,setup,setup,record RTSP routine Five steps, a UDP packet has not been sent out, died in RTPENC.C

Rtp_write_packetprogram received signal SIGSEGV, segmentation fault.rtp_write_packet (s1=0x2ca28c0, pkt=0x22d548) at libavformat/rtpenc.c:524524     rtcp_bytes = ((s->octet_count-s->last_octet_count) * RTCP_TX_RATIO_NUM)/

The reason is that the rtpmuxer context (the classname of Muxer,outputformat avformatcontext,category is "RTP output"), its priv_data is 0, this priv_ Data was supposed to be a rtpmuxcontext, but it was 0. This is good to do, the original thought as long as the code to search for the rtpmuxcontext of the building where the detection. But this is a pure C project, and it's a priv_data, similar to the union of many interpretations.
There is no way for this priv_data to go up to 1.1 points to recover the entire chain of relationships. Locks more than 10 characters (objects) and dozens of operations.

Procedure omitted.
The original thought was not to build priv_data, and finally detected that priv_data in a place to build, but in another place was changed to 0. So, but no, the code for this project has been used by people all over the world, and there may be such a funny, low-level problem.
But it's really there.

The insertion instruction, the general InputFormat correspondence is the Demuxer,outputformat correspondence is the muxer. One decoding is the main, the other is main.

Rtspstream::transport_priv is a avformatcontext in the Muxer branch, and the priv_data of the context is a pointer to Rtpmuxcontext.
Rtspstream::transport_priv in the Demuxer branch is a rtpdemuxcontext, and the SSRC position of the context is the priv_data of the context above.
In this way the Muxer context was written as demuxer and miserable.

Find the previous version of 2.7.7 for comparison. Position in libavformat/rtsp.c, method int Ff_rtsp_open_transport_ctx (Avformatcontext *s, Rtspstream *rtsp_st):

int Ff_rtsp_open_transport_ctx (Avformatcontext *s, Rtspstream *rtsp_st) {rtspstate *rt = s->priv_data;    Avstream *st = NULL;    int reordering_queue_size = rt->reordering_queue_size;            if (Reordering_queue_size < 0) {if (Rt->lower_transport = = Rtsp_lower_transport_tcp | |!s->max_delay)        reordering_queue_size = 0;    else reordering_queue_size = rtp_reorder_queue_default_size; }/* Open the RTP context * * if (rtsp_st->stream_index >= 0) st = S->streams[rtsp_st->stream_inde    X];    if (!st) s->ctx_flags |= Avfmtctx_noheader;        if (config_rtsp_muxer && s->oformat && st) {//!!!!!!!!!! Note Here Rtsp_st->transport_priv is used as avformatcontext, for MUX operation//foreshadowing 1//INT ret = Ff_rtp_chain_mux_ope N ((Avformatcontext *) &rtsp_st->transport_priv, S, St, Rtsp_st->rtp_handl                                        ERtsp_tcp_max_packet_size, Rtsp_st->stream_index);        /* Ownership of Rtp_handle is passed to the RTP mux context */rtsp_st->rtp_handle = NULL;        if (Ret < 0) return ret;        St->time_base = ((avformatcontext*) rtsp_st->transport_priv)->streams[0]->time_base;        // !!!!!!!!!!!!        Even if it has been opened as a mux, it does not return, still downstream. Foreshadowing 2//} else if (Rt->transport = = Rtsp_transport_raw) {return 0;//Don ' t need to open any parse R here} else if (config_rtpdec && rt->transport = = Rtsp_transport_rdt && st) Rtsp_st->tra Nsport_priv = Ff_rdt_parse_open (S, St->index, Rtsp_st->dynamic_protocol_c    Ontext, Rtsp_st->dynamic_handler);                                         else if (config_rtpdec) Rtsp_st->transport_priv = Ff_rtp_parse_open (S, St, Rtsp_st-> Sdp_payload_type, reordering_queue_size);    if (!rtsp_st->transport_priv) {return averror (ENOMEM);        } else if (config_rtpdec && rt->transport = = RTSP_TRANSPORT_RTP) {//!!!!!!!!!!!!!!!        The old version of the MUX that has been opened naturally flows into the control stream here, because there is no other operation.///But!!!!!!!!!        Version 3.14!!!!        Add the following two sentences, the bug came////rtpdemuxcontext* Rtpctx = rtsp_st->transport_priv;               RTPCTX-&GT;SSRC = rtsp_st->ssrc; // ^ !!!!!!                    The above sentence is equal to the Avformatcontext priv_data assignment.                                              if (Rtsp_st->dynamic_handler) {Ff_rtp_parse_set_dynamic_protocol (Rtsp_st->transport_priv,                                              Rtsp_st->dynamic_protocol_context,        Rtsp_st->dynamic_handler);                           } if (Rtsp_st->crypto_suite[0]) Ff_rtp_parse_set_crypto (Rtsp_st->transport_priv,         Rtsp_st->crypto_suite, Rtsp_st->crypto_params);     } return 0;}

Version 3.14 added two lines of code to introduce the bug.

The solution is the patient hand pain, in the 3.14 version added two lines of code before adding Oformat judgment, generally outputformat for muxer and InputFormat for Demuxer.

Ffmpeg-3.14 has such a hole in the bug.