[FFmpeg-devel] [PATCH 0/3] Patch set to delay output live stream

[Andreas Rheinhardt]

Marton Balint:
> 
> 
> On Tue, 5 May 2020, Tao Zhang wrote:
> 
>> Marton Balint <cus at passwd.hu> 于2020年5月5日周二 上午3:48写道：
>>>
>>>
>>>
>>> On Sat, 2 May 2020, Tao Zhang wrote:
>>>
>>> > Marton Balint <cus at passwd.hu> 于2020年5月2日周六 下午7:05写道：
>>>
>>> [...]
>>>
>>> >> I see. But you could add an option to the fifo muxer to only write
>>> header
>>> >> when the first packet arrives. This way you will be able to use a
>>> >> bitstream filter to buffer packets and the fifo muxer will only write
>>> >> header when the first packet passes through the bitstream filter.
>>> Does
>>> >> this seem OK?
>>> > It seems OK. If nobody object it, I'm glad to add
>>> > write_header_on_first_packet option on fifo muxer and create a new
>>> > bitstream filter which buffers fixed duration packets.
>>>
>>> Great. I suggest a shorter name for the option of the fifo muxer,
>>> delay_write_header I think is enough, you can explain the details in the
>>> docs.
>> Great suggestion. I'll follow it.
>>>
>>> Also it should be pretty straightforward to add this feature to fifo.c,
>>> from a quick look at the code one approach is to add a NOOP message
>>> type,
>>> and if the option is set, then use that message type for the first
>>> message, if it is not set, use the WRITE_HEADER message type, as it is
>>> used now.
>>>
>>> Also we should find a good name for the bitstream filter, maybe
>>> "buffer",
>>> or "fifo", or if you want to better refer to the use case, then
>>> "timeshift" can also work.
>> Maybe "caching" or "cache"?
>>>
>>> Another thing you should think about is what should happen at the end of
>>> the stream, when flushing the bitstream filter:
>>> - drop pending packets
>>> - flush pending packets as fast as possible
>>> - flush pendning packets realtime
>>> Maybe it should be selectable between the 3 options? I can imagine use
>>> cases for all three possibilities.
>> Although I have not imagined the first and second use cases, I'm glad
>> to implement all three.
> 
> I have given the bitstream filter approach some additional thought and
> since each stream will have a different bitstream filter I think you
> will have problems when flushing them in ffmpeg.c because it will flush
> them sequentially, the packet interleaving will be something like
> - all remaining packets from the first stream
> - all remaining packets from the second stream

Maybe the custom interleavement functions should be split into one that
does the "add packet to packet list" part and another one for "return
packet from packet list"? This would allow to drain all the bsfs and to
add all packets to the interleavement queue, before starting to output them.
(This proposal would increase sizeof(AVOutputFormat) and would therefore
cause problems when one uses a new libavformat together with an old
libavdevice (despite no libavdevice muxer using custom interleavement
functions). This could be solved by using a hack: We put the add packet
function in place of the old interleave_packet() function and only ever
check for the existence of the get_packet() function if the add_packet()
function pointer is not NULL.)

- Andreas

PS: Nothing said above is intended to block your other patchset in any
way. I just wanted to mention it because the current interleave_packet()
functions are already naturally split into two independent parts.