Calculation of streaming buffer time of VLC receiving network ()

Original post address: http://blog.csdn.net/coroutines/article/details/7472743

 

 

VLC version 2.0.1

A recent study of IP-STB audio and video synchronization problems, found that the solution comes with automatic STC in the network delay is too large, the audio and video cannot be synchronized successfully. After referring to the stream playback mechanism of VLC, we thought that proper buffering could solve this problem. Unfortunately, the final result is a slight relief and cannot be fundamentally solved. However, the computing of this buffer time has some reference significance for the injection of audio and video data based on the network.

1. Initial clues:

When the-vvv parameter is used to start VLC, Prompt:

 

Run the command line to start VLC:./Vlc.exe-vvv

 

[0xb73005f0] main input debug: Buffering 0%[0xb73005f0] main input debug: Buffering 3%[0xb73005f0] main input debug: Buffering 6%[0xb73005f0] main input debug: Buffering 9%[0xb73005f0] main input debug: Buffering 12%[0xb73005f0] main input debug: Buffering 15%[0xb73005f0] main input debug: Buffering 18%[0xb73005f0] main input debug: Buffering 21%[0xb73005f0] main input debug: Buffering 24%[0xb73005f0] main input debug: Buffering 27%

 

We can find that the printing of this buffer process is output from src/input/es_out.c: 658 rows. The function esoutdecodersstopbuffering is used to determine whether the length of the Current Buffer stream I _stream_duration has reached the preset I _buffering_duation length. If yes, the buffer is stopped; otherwise, a wait is returned.

 

The following describes how to calculate I _stream_duration and I _buffering_duation.

2. I _stream_duration calculation:

In esoutdecodersstopbuffering, I _stream_duration is obtained through input_clock_getstate. Input_clock_getstate is the difference value between the two clock_point_t object members of the input_clock_t object and the I _stream of the ref object as the length of the buffered data.

After continuing to search for the I _stream value, we can find that I _stream is only set in clock_point_create, while the I _stream values of last and ref objects are updated in input_clock_update, the data used to update I _stream is transmitted by I _ck_stream. The input_clock_update function is called at es_out.c: 2324. This code is used to set the pcr value of the input_clock_t object. The upper-layer input command is es_out_set_group_pcr. The function that passes in this command has only one ts. c: 2173 rows of pcrhandle.

The pcrhandle Code shows that the PCR calculation is to directly obtain the PCR data of the adaption field from the TS package, convert the data to seconds according to the 90 kHz clock, and multiply the value by 1000000 into microseconds, passed To input_clock_update to complete the I _stream_duration calculation.

3. Calculation of I _buffering_duration:

In esoutdecodersstopbuffering, I _buffering_duration is determined by the I _pts_delay attribute of an es_out_sys_t object plus several other parameters. Here I only studied the I _pts_delay acquisition. In my test, the remaining values are 0.

The es_out_sys_t object is passed in by the es_out_t parameter out of the callback. it traces back the code calling process and implements <-esoutcontrollocked <-esoutcontrol <-es_out_vacontrol <-es_out_control <-cmdexecute, here, the out parameter is changed to another es_out_t parameter p_out. Continue tracing. cmdexecutedcontrol <-controllocked <-Control <-es_out_vacontrol <-es_out_control <-pcrhandle, p_out is a member of the demux_t parameter p_demux, and pcrhandle <-gatherpes <-Demux <-demux_demux <-mainloop Demux. Here, p_demux is a member of the input_thread_t object p_input, and then backtracing. mainloopdemux <-mainloop <-run, p_input is initialized in input. C: 550 through the init function.

Read part of the init code and you will find that. c: The I _pts_delay value changes after the initsourceinit function of Row 3. If you go deeper, you will find the value in the input. c: Row 2644 has an access_get_pts_delay operation, which corresponds to UDP in my test. in row C: 173, VLC obtains a value called network-caching. The value is set to 1000. I guess it should be ms, and the value is multiplied by 1000 when the result is returned, convert to microseconds and compare it with the I _stream_duration value.

Summary:

In this test, only UDP-based multicast playback is performed. Other protocols may have many details that are different from those of UDP. The analysis will be conducted later.

After reading the TS protocol for a long time, we found that many things are different from what we imagined in actual applications. It is impossible to get things out of reality.

The PCR-based buffer length mechanism of VLC does not help me solve the problem of non-synchronization. However, it may be helpful to play network streaming at different bit rates. Suppose we enable a fixed-size buffer. Due to data transmission efficiency problems, the decoder buffer overflow or underflow often occurs. However, if I use a time-based buffer, there should be some improvement, but I don't know if this method for analyzing the real-time PCR value introduces another bottleneck.