[Libav-user] custom IO + fragmented mp4

[Mert Gedik]

Hi,

In my project, I am trying to demux the data in the memory using custom IO
feature of ffmpeg, and the data is not in my control, another closed source
player is managing the data and I am intercepting and then storing it in a
byte array.

in a more understandable way,

|closed source player|  ----->  |proxy| -----> | resource on internet
(fragmented mp4)|
and in the proxy box, the data is intercepted and send it to the bytearray

ffmpeg side,

|proxy|   --->  memory byte array ---> |ffmpeg custom io callback
functions, read, seek|

So, when ever ffmpeg needs data, the read and seek functions are called,
and the bytes are provided from the byte array

So far, it's working fine, the issue that I can not handle/don't know how
to handle is below,

1. Internet connection is very bad and closed source player is waiting for
new bytes
2. Since ffmpeg demuxer is depending on the response of closed source
request' responses, it's also waiting in the read callback.
3. In this case, if the user does seek to a future point, then I am
returning 0 to read callback (because the seek op requires another read op
and the current one that is waiting needs to be returned)
4. when I return the waiting read callback with 0 and for the first time,
the seek op is handled and I can see that the new offset is set and and
waiting the new bytes of the new offset.
5. If the user do another seek op in this time, again I am returning 0 to
read callback, but this time, mov demuxer somehow set the new offset in the
beginning of the file which is wrong byte offset.

The above scenario may seem complex but it's not, it's very similar to
common scenario like below
1. internet is very slow - even no data
2. player is waiting for bytes to continue playing
3. in this case, user is seeking a future point
4. then user is seeking to another future point


I am basically asking what we should do to cancel the waiting read callback
properly to do seek operation ? Thanks

Regards,

MG
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://ffmpeg.org/pipermail/libav-user/attachments/20210907/16bb121b/attachment.htm>