If fifo_thread_recover() succeeds immediately after
fifo_thread_dispatch_message() fails, the dts of the packet is scaled
twice, causing cur_dts to be abnormally large and "Application provided
invalid, non monotonically increasing dts to muxer in stream" to occur
repeatedly.
Steps to reproduce:
1. ffmpeg -f lavfi -i testsrc -c:v libx264 -map 0:v -flags +global_header -f fifo -fifo_format flv -attempt_recovery 1 -recover_any_error 1 rtmp://example.com/livekey
2. set a breakpoint on fifo_thread_recover
3. force disconnect from the rtmp server
4. wait for break
5. reconnect to the rtmp server
6. resume execution of ffmpeg
Signed-off-by: Ryoji Gyoda <gy.cft4@gmail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
Do this by allocating AVStream together with the data that is
currently in AVStreamInternal; or rather: Put AVStream at the
beginning of a new structure called FFStream (which encompasses
more than just the internal fields and is a proper context in its own
right, hence the name) and remove AVStreamInternal altogether.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
av_dict_copy() puts the onus on the caller to clean up dst on failure;
it can be nonempty if copying a later entry of src fails after having
successfully copied an earlier entry.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is possible now that the next-API is gone.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Muxers may want to directly access filename in stored in
AVFormatContext. For example in case of RTSP, the filename (url)
is used by the muxer to extract parameters of the connection.
These muxers will fail when used with fifo pseudo-muxer.
This commit fixes this issue by passing filename from AVFormatContext
of fifo pseudo-muxer to all AVFormatContext(s) of underlying muxers
during initialization.
Signed-off-by: Jan Sebechlebsky <sebechlebskyjan@gmail.com>
