how to avoid add m_pFormatContext->start_time to seek_pts in FFmpegStream::SeekTime? #232
Comments
|
it seems that we need a new |
|
If you change the code and build the addon does it work for your use case? |
|
im working on it. |
|
If you create a PR, Jenkins will build it for you. It will build for Windows, Android and Mac. Just click the Jenkins link and then Artefacts to find them. |
thx |
|
it works. if i start play , and when the play time is 1:00, then i seek to 2:00, it will play the stream at 2:00 but the process bar shows 1:00. i think it was because of here ok, i found the dts is -9223372036854775808 in log , it is AV_NOPTS_VALUE（-9223372036854775808（0x8000000000000000） i think this value should be provid by librtmp I don't know what to do with this situation yet oh i see. i seek |
|
Is the error in librtmp or in ffmpegdirect? What exactly is the change you had to make to get it to work? have you checked to see if an updated version of librtmp is available? |
i think the error is because of librtmp. ok, i konw it, i will build inputstream.rtmp with the new source code of librtmp |
|
it works. |
|
You need to add the hash for librtmp tarball (all 3 directories in depends) and also update The new version number should be 21.0.1. Then I can merge, tag and release the PR. |
|
im working on it. |
|
Please also squash the url and the hash of the new librtmp commits. |
1 similar comment
|
Please also squash the url and the hash of the new librtmp commits. |
|
sorry, in my case, there is two points to fix. in my case, the seek_pts shouldnt add the m_pFormatContext->start_time, i think the better way is set a new flag like #KODIPROP:inputstream.ffmpegdirect.is_ignore_start_time_on_seek=truethe second one is update the latest code of librtmp. |
|
i will be back tomorrow, im going to bed now. |
|
Which addon are you using to play the stream? You should play with either inputstream.ffmpegdirect or inputstream.rtmp, not both. |
|
it's inputstream.ffmpegdirect |
|
Ok, if ffmpegdirect then changing inputstream.rtmpw will make no difference. have you tried using inputstream.rtmp on its own? |
|
no, im using |
|
Yes, but only one of them will be used to play your rtsp streams. |
|
Do you have an example the M3U entry you use to play a stream. You can force the one use by putting a KODIPROP before each M3U entry. for ffmpegdirect: for rtmp: for kodi’s internal ffmpeg: |
the live stream is a broadcast stream i will try |
|
Please try all 3x ffmpegdirect, rtmp and ffmpegz internal inputstreams with each type of URL and see what happens. Because RTMP itself has the ability to playback within a video it could be the catchup functionality in iptvsimple is interfering. The easiest to test that is to not use ffmpegdirect at all. |
|
in my case So this problem arises because I did not write my m3u file correctly, thanks for your enthusiastic help, I will continue to observe the status after modifying the m3u file, once I find that the problem is completely solved, I will close the issue and PRs |
my rtsp stream broken when i seek in kodi.
but it play well in potplayer.
so i use tcpdump to find out whats the different.
after that i use tcpdump to catch packages between my iptv provider and my iptv box
i found the different:
the 245 is “the number of seconds that elapsed from the start of the stream"
and i use potplayer to play the rtsp stream:
i got
and everything works well.
but kodi send a value that is much larger than the length of the entire stream.
for example:
and it should be 38.
i find these in kodi‘s logs
this line:
2023-03-19 19:39:36.248 T:18072 INFO <general>: AddOnLog: inputstream.ffmpegdirect: ffmpeg[EA45BCCB]: Duration: 00:32:00.00, start: 26328.772378, bitrate: N/Athe start is 26328
then i drag the progress to 00:17
then kodi send a request with:
26345 - 26328 = 17
then, i try again, drag the progress to 00:50
26378 - 26328 = 50
and the extra 0.772 is in the start 26328.772378
so i guess, when i drag a progress bar, someone add the progress value and a number called start then send the sum.
then i restart kodi
i found the start is still 26328.772378.
then i try another stream, the start is 17161.329422 now.
ok, i check the source code the found the parameter is output here
inputstream.ffmpegdirect/src/stream/FFmpegStream.cpp
Line 762 in 2783127
the start is part of the protocol，this is a wrong way, i need to find out who add the start and the progress value, and i know the start is
FFmpegStream::m_pFormatContext->start_timegot it:
https://github.com/xbmc/inputstream.ffmpegdirect/blob/278312774bb9d7f8936c7463a1d363e9b88a3221/src/stream/FFmpegStream.cpp#LL1483
but why?
i need kodi send the real progress value without add the ic->start_time
what should i do?
The text was updated successfully, but these errors were encountered: