SeekableCallbackMedia stops reading buffer

[roiniti]

Hi, I'm building my own SeekableCallbackMedia for playing custom web streams but in some point the video stops playing, debugging I saw that its not problem of the web stream, the problem resides in that onRead is called until x point reading the buffer but then its not called anymore causing the video stop like it has reached the end earlier than normal, i don't know why this happens. I also tested with using RandomAccessFileMedia instead, but i have the same problem. I'm doing this to play the video capricaMediaPlayer.media().prepare(new RandomAccessFileMedia(new File("path to mp4 file")),options); and later i do capricaMediaPlayer.controls().play(); where caprocaMediaPlayer is an EmbeddedMediaPlayer created with the MediaPlayerFactory

[caprica]

This is difficult to troubleshoot, because it is actually VLC that calls back into the vlcj code to read the data. It's not like vlcj is in control of when read gets called.

So it would appear that VLC has stopped asking the Java code for more data.

Without a repeatable test case it is going to be very difficult to look at this, and even then it may be a problem in VLC, not vlcj.

At the least you should run VisualVM or something similar and see if any threads are stuck.

[caprica]

If you play your stream in VLC and seek around, is it ok?

[roiniti]

I didn't tried in VLC, i need to send specific headers to access the stream but downloading the stream and then playing it in vlcj with .media().play(AbsolutePath) works, using VisualVM i see no much weird things, when i start the player i see three media-player-events threads running that runs until the video reaches the end (not the end of the stream, the end of the stream that it reads, that is 21910660 bytes of 83920527 total, the number of bytes read changes every time), i only notice that its creating 0ms of life threads when i use my implementation of SeekableCallbackMedia

[caprica]

Those Thread objects (not actual threads) are just an artefact of how JNA works.

[roiniti]

I found a method to get the stream working in vlc using the parameters but definitely this is a problem, i think you can replicate the problem by playing a mp4 video +10 minutes with RandomAccessFileMedia, for me the problem allways happens

[caprica]

Can you post a thread dump at the point it stops reading?

[roiniti]

I don't know if i did it correctly but here it is https://pastebin.com/wVHxEDg7 , I started the player with RandomAccessFileMedia of a mp4, 25 minutes, and then seeked arround the half of the video

[caprica]

You did it correctly, but you could've just posted it here.

[caprica]

I dunno, I don't see any vlcj classes in that dump. It's hard to say.

[roiniti]

Sorry i think its because the video ended playing because it reached the end, i paused the video waiting the buffer to get filled, this is before it reaches the end of the buffer, the video is still playing at this moment but the buffer has ended its reading i think dump.txt

[roiniti]

Ok, so a tiny workarround I think that can make this work (its a bit dirty), building a little localhost HTTP server and pass the uri to VLC so it manages all, (for what im doing its a good solution because it will simplify the implementation for vlc android that im also using), i don't know how this workarround sounds to you

[caprica]

How does it sound to me? Well, if it solves your problem, it sounds just fine to me. :-)

[roicbr]

Yeah but you could reproduce the problem? if libvlc stops reading the buffer at some point then all the CallbackMedia subclases are useless

[caprica]

If the problem is in libvlc, I can't/won't fix it.

If the problem is in vlcj, I will have to write a new sample and apparently wait 25 minutes each time to troubleshoot it. It may be the case in fact that the "normal" usage of the callback media is fine, and it's only cases like this custom streaming arrangement where there is a problem, and this report doesn't contain a sample.

So thanks for your comment, but time is precious. If I find some spare time, I will try, but I can't promise when.