Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support FFmpeg timecode, fix AMF0 parsing failed. v5.0.179 v6.0.77 #3804

Merged
merged 4 commits into from
Sep 18, 2023

Conversation

winlinvip
Copy link
Member

@winlinvip winlinvip commented Sep 18, 2023

Please see #3803 for detail:

  1. When using FFmpeg with the -map 0 option, there may be a 4-byte timecode in the AMF0 Data.
  2. SRS should be able to handle this packet without causing a parsing error, as it's generally expected to be an AMF0 string, not a 4-byte timecode.
  3. Disregard the timecode since SRS doesn't utilize it.

See Error submitting a packet to the muxer: Broken pipe, Error muxing a packet


Co-authored-by: john hondaxiao@tencent.com

1. When using FFmpeg with the `-map 0` option, there may be a 4-byte timecode in the AMF0 Data.
2. SRS should be able to handle this packet without causing a parsing error, as it's generally expected to be an AMF0 string, not a 4-byte timecode.
3. Disregard the timecode since SRS doesn't utilize it.
@winlinvip winlinvip added the EnglishNative This issue is conveyed exclusively in English. label Sep 18, 2023
@winlinvip winlinvip linked an issue Sep 18, 2023 that may be closed by this pull request
@winlinvip winlinvip changed the title Support FFmpeg timecode, fix AMF0 parsing failed. Support FFmpeg timecode, fix AMF0 parsing failed. v5.0.179 v6.0.77 Sep 18, 2023
@winlinvip winlinvip added the RefinedByAI Refined by AI/GPT. label Sep 18, 2023
@winlinvip winlinvip merged commit 6a4ace9 into ossrs:develop Sep 18, 2023
17 checks passed
winlinvip added a commit that referenced this pull request Sep 18, 2023
Please see #3803 for detail:

1. When using FFmpeg with the `-map 0` option, there may be a 4-byte
timecode in the AMF0 Data.
2. SRS should be able to handle this packet without causing a parsing
error, as it's generally expected to be an AMF0 string, not a 4-byte
timecode.
3. Disregard the timecode since SRS doesn't utilize it.

See [Error submitting a packet to the muxer: Broken pipe, Error muxing a
packet](https://trac.ffmpeg.org/ticket/10565)

---------

Co-authored-by: john <hondaxiao@tencent.com>
duiniuluantanqin pushed a commit to duiniuluantanqin/srs that referenced this pull request Oct 11, 2023
Please see ossrs#3803 for detail:

1. When using FFmpeg with the `-map 0` option, there may be a 4-byte
timecode in the AMF0 Data.
2. SRS should be able to handle this packet without causing a parsing
error, as it's generally expected to be an AMF0 string, not a 4-byte
timecode.
3. Disregard the timecode since SRS doesn't utilize it.

See [Error submitting a packet to the muxer: Broken pipe, Error muxing a
packet](https://trac.ffmpeg.org/ticket/10565)

---------

Co-authored-by: john <hondaxiao@tencent.com>
@streamingsystems
Copy link

streamingsystems commented Nov 16, 2023

2.mp4

Hi,

It seems like maybe this problem is not fixed or there is a related bug. I am running FFMPEG 6 and the latest version of SRS (I just built it from the source).

When I run this:

ffmpeg -stream_loop -1 -re -i 2.mp4 -stream_loop -1 -re -i 2.mp4 -stream_loop -1 -re -i 2.mp4 -map 0 -c copy -f flv rtmp://127.0.0.1:1935/live/ss/1 -map 1 -c copy -f flv rtmp://127.0.0.1:1935/live/ss/2 -map 2 -c copy -f flv rtmp://127.0.0.1:1935/live/ss/3

(In my real application I have different video as inputs but they were too big to all upload to GitHub but the above command will use the same input video and reproduce the problem)

When the video is done and starts over at the beginning ffmpeg crashes with this:

av_interleaved_write_frame(): Broken pipesize= 4881kB time=00:00:49.98 bitrate= 800.0kbits/s speed= 1x
[out#1/flv @ 0x7fd52e90cec0] Error muxing a packet
av_interleaved_write_frame(): Broken pipe
[out#2/flv @ 0x7fd52ea112c0] Error muxing a packet

"Broken Pipe" usually means the server hit some type of an error.

Do you have any developers that also work on FFMPEG we would pay the money to fix this problem in ffmpeg as it seems ffmpeg is not sending the correct bytes in this situation.

Thanks!

@winlinvip
Copy link
Member Author

winlinvip commented Nov 16, 2023

@streamingsystems In fact, you don't need to modify FFmpeg. I noticed that there is a timeout during the Stream loop. So, you just need to extend the timeout period below to solve the problem:

vhost __defaultVhost__ {
    publish { 
        firstpkt_timeout 30000; 
        normal_timeout 30000; 
    }
}

TRANS_BY_GPT4

@streamingsystems
Copy link

Good evening,

It seems that ffmpeg is not sending some data properly that is causing a longer timeout needed?

If you just use "1" map like this:

ffmpeg -stream_loop -1 -re -i 2.mp4 -map 0 -c copy -f flv rtmp://127.0.0.1:1935/live/ss/1 -map 1

ffmpeg does not exit with a "broken pipe" and runs correctly with no change to the timeout.

But if I do 2 (or more( maps:

ffmpeg -stream_loop -1 -re -i 2.mp4 -stream_loop -1 -re -i 2.mp4 -map 0 -c copy -f flv rtmp://127.0.0.1:1935/live/ss/1 -map 1 -c copy -f flv rtmp://127.0.0.1:1935/live/ss/2

av_interleaved_write_frame(): Broken pipe 4855kB time=00:00:49.55 bitrate= 802.6kbits/s speed= 1x

To me, this seems to be a bug in the "map" or "rtmp" code in ffmpeg that it's behaving differently by maybe not sending the data related to timecode that is causing the server to hit a timeout and fail?

I use the timouts low for other reasons so I am trying to not have to increase the timeout for what seems to be a bug in ffmpeg.

As always thanks for your help.

@winlinvip
Copy link
Member Author

winlinvip commented Nov 16, 2023

@streamingsystems In fact, we cannot completely rule out the possibility of a bug in FFmpeg. You could report this to the FFmpeg community. By increasing the timeout configuration in SRS, you should be able to get around this issue without affecting your business. Additionally, if 'map 0' is problematic, is it possible to not use 'map 0' and only use 'map 1', 'map 2', 'map N', etc.?

@streamingsystems
Copy link

Hi,

I don't believe that map 0 specifically is the problem, it seems when you use more than 1 map (map 0 being the first) it causes the problem.

What is puzzling and problematic to me is that it seems like ffmpeg with more than 1 map in the command is not sending the proper timing information to the server which is causing the timeout to be hit.

In other words, with just a single map the server does not need a 30s timeout and ffmpeg works fine. When more than 1 map is used, the server times out which would imply to me that ffmpeg is not sending the proper data to the server which is causing it to timeout.

I am trying to find a ffmpeg developer that can look at the "map" function.

If you see this bug report I opened a while ago:

https://trac.ffmpeg.org/ticket/10565

Steven Luis replies with this comment:

Looks the problem is happened when it publish timecode stream:

Stream #0:20x3: Data: none (tmcd / 0x64636D74)
Metadata:
handler_name : VideoHandler
timecode : 01:00:00:00

I am emailing with Steven now to see if I can pay him to look at the code and see if maybe ffmpeg is not sending up the proper timecode information when more than 1 map is used.

@winlinvip
Copy link
Member Author

winlinvip commented Nov 16, 2023

Steven Liu is my good friend and also the maintainer of the FFmpeg RTMP/FLV module. If he is willing to spend time on it, there is hope that he can solve this problem.

TRANS_BY_GPT4

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
EnglishNative This issue is conveyed exclusively in English. RefinedByAI Refined by AI/GPT.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support FFmpeg timecode, fix AMF0 parsing failed.
3 participants