Torrent file streaming. Order of load disturbed.

[Nikitenko]

Seems like https://github.com/se-bastiaan/TorrentStream-Android/issues/22 When we stream MKV files, player jump to forward on already loaded part of file. It is possible to load file by order?

Imagine that: loaded part of file: + not loaded part of file: -

Then stream file seems like: +++-------++------++++---

Need: +++++++++----------------

Maybe frostwire-jlibtorrent allows to set highest priority to load first parts of file?

Exampe of MKV http://d.rutor.info/download/543319

[vonclutch]

Hey, which media player did you use ? Cause it's looks like the implantation of the stream part didn't work rly nice. It should wait the other pieces not downloaded but instead go directly on the next pieces who has already been downloaded. Have you tried to set the priority high on the next pieces ? (Seems you can do it since few months).

[Nikitenko]

We use own player founded on ffmpeg player on our STB device.

How to set the priority high on the next pieces ?

[vonclutch]

ok, I don't rly know ffmepg so I can't tell you if it's good for an adaptive stream :/ Maybe @se-bastiaan can help.

To manage the priority you need to look for Torrent#TorrentHandle.

[se-bastiaan]

TorrentStream actually works like this:

1. Add the torrent file or magnet link to the libtorrent session and select the largest file as only download. Also calculated the amount of pieces that need to be downloaded before the stream is marked as 'ready'. TorrentStream.java#L83
2. Prioritise the first and last pieces of the selected file using the previously calculated amount of pieces. Torrent.java#L264 This should result in: ++----------------------++
3. Once the prioritised pieces are downloaded set the download to sequential. Either using the sequential mode in libtorrent or sequential downloading in TorrentStream depending on the knowledge we have of the pieces. Torrent.java#L457 Torrent.java#L401
4. Profit +++---------------------++ ++++--------------------++ +++++-------------------++

Now it does happen that a videoplayer doesn't really like the incomplete file. The only ones that have worked for me are VLC, ExoPlayer and MX Player. ijkplayer may also work but it's been some time since I last tried it. Can you try downloading VLC and opening the video via an Intent in VLC to see what happens?

The 'set the priority high on the next pieces' that vonclutch mentions is probably this which is used by TorrentInputStream.java. It allows you to seek in the 'stream' by calculating which pieces are needed for a certain byte in the video file. That in turn is used by TorrentStreamServer-Android since this'll turn the video file in a 'real' HTTP stream that most likely works better due to the way partial content is handeled.

[Nikitenko]

First of all VLC cannot start playback. When i changed onStreamReady: intent.setDataAndType(Uri.parse(torrent.getVideoFile().toString()), "video/mp4"); to intent.setDataAndType(Uri.parse("file:///" + torrent.getVideoFile().toString()), "video/mp4"); VLC starts playback fine.

At first i test TorrentStream-Android with VLC. Sometimes VLC freezes on about one second and i see:

org.videolan.vlc W/VLC: [6e2dbd80/146d] core video output: picture is too late to be displayed (missing 372 ms)

and after a few minutes, VLC freezes hard and playback not continues.

At second i test TorrentStreamServer-Android with VLC, sometimes VLC freezes on about one second and i see same debug:

org.videolan.vlc W/VLC: [6e2dbd80/146d] core video output: picture is too late to be displayed (missing 328 ms)

Playback continues always, no hard freezes. But at the middle of playback VLC silently closed and i see debug:

01-17 14:00:41.738 10158-10158/com.github.se_bastiaan.torrentstreamer.sample I/nikitenko: status.progress: 92.7723
01-17 14:00:43.278 2825-3082/system_process I/WindowState: WIN DEATH: Window{419d5f40 u0 com.github.se_bastiaan.torrentstreamer.sample/com.github.se_bastiaan.torrentstreamerserver.sample.MainActivity}
01-17 14:00:43.338 2825-2869/system_process W/InputDispatcher: channel '419d5f40 com.github.se_bastiaan.torrentstreamer.sample/com.github.se_bastiaan.torrentstreamerserver.sample.MainActivity (server)' ~ Consumer closed input channel or an error occurred.  events=0x9
01-17 14:00:43.338 2825-2869/system_process E/InputDispatcher: channel '419d5f40 com.github.se_bastiaan.torrentstreamer.sample/com.github.se_bastiaan.torrentstreamerserver.sample.MainActivity (server)' ~ Channel is unrecoverably broken and will be disposed!
01-17 14:00:43.338 2825-3082/system_process W/InputDispatcher: Attempted to unregister already unregistered input channel '419d5f40 com.github.se_bastiaan.torrentstreamer.sample/com.github.se_bastiaan.torrentstreamerserver.sample.MainActivity (server)'
01-17 14:00:45.408 2825-2837/system_process I/ActivityManager: Process com.github.se_bastiaan.torrentstreamer.sample (pid 10158) has died.
01-17 14:00:46.148 3863-27269/org.videolan.vlc D/VLC: [6e2bbbc8/6a85] transport access: resolving 127.0.0.1 ...
01-17 14:00:46.148 3863-27269/org.videolan.vlc D/VLC: [6e2bbbc8/6a85] transport access: connecting to 127.0.0.1 port 8082 ...
01-17 14:00:46.148 3863-27269/org.videolan.vlc E/VLC: [6e2bbbc8/6a85] transport access: cannot connect to 127.0.0.1 port 8082: Connection refused
01-17 14:00:46.178 3863-10335/org.videolan.vlc D/VLC: [740073f0/285f] cache_block stream: b_seek=0 th*avg=10235 skip=1816
01-17 14:00:46.178 3863-10335/org.videolan.vlc D/VLC: [740074e8/285f] mkv demux: MKV/Ebml Parser: m_el[mi_level] == NULL
01-17 14:00:46.178 3863-10335/org.videolan.vlc W/VLC: [740074e8/285f] mkv demux: EOF
01-17 14:00:46.178 3863-10335/org.videolan.vlc W/VLC: [740074e8/285f] mkv demux: cannot get block EOF?
01-17 14:00:46.178 3863-10335/org.videolan.vlc D/VLC: [6cddd0b0/285f] core input: EOF reached
01-17 14:00:46.188 3863-10335/org.videolan.vlc D/VLC: [6cddd0b0/285f] core input: waiting decoder fifos to empty
01-17 14:00:46.288 3863-10335/org.videolan.vlc D/VLC: [6cddd0b0/285f] core input: waiting decoder fifos to empty
01-17 14:00:46.388 3863-10335/org.videolan.vlc D/VLC: [6cddd0b0/285f] core input: waiting decoder fifos to empty
01-17 14:00:46.488 3863-10335/org.videolan.vlc D/VLC: [6cddd0b0/285f] core input: waiting decoder fifos to empty
01-17 14:00:46.588 3863-10335/org.videolan.vlc D/VLC: [6cddd0b0/285f] core input: waiting decoder fifos to empty
01-17 14:00:46.688 3863-10335/org.videolan.vlc D/VLC: [6cddd0b0/285f] core input: waiting decoder fifos to empty
01-17 14:00:46.788 3863-10335/org.videolan.vlc D/VLC: [6cddd0b0/285f] core input: waiting decoder fifos to empty
01-17 14:00:46.888 3863-10335/org.videolan.vlc D/VLC: [6cddd0b0/285f] core input: waiting decoder fifos to empty
01-17 14:00:46.988 3863-10335/org.videolan.vlc D/VLC: [6cddd0b0/285f] core input: waiting decoder fifos to empty
01-17 14:00:47.088 3863-10335/org.videolan.vlc D/VLC: [6cddd0b0/285f] core input: waiting decoder fifos to empty
01-17 14:00:47.188 3863-10335/org.videolan.vlc D/VLC: [6cddd0b0/285f] core input: waiting decoder fifos to empty
01-17 14:00:47.288 3863-10335/org.videolan.vlc D/VLC: [6cddd0b0/285f] core input: waiting decoder fifos to empty
01-17 14:00:47.388 3863-10335/org.videolan.vlc D/VLC: [6cddd0b0/285f] core input: waiting decoder fifos to empty
01-17 14:00:47.468 3863-10379/org.videolan.vlc E/VLC: [6e23a610/288b] mediacodec decoder: Decoder is draining
01-17 14:00:47.488 3863-10335/org.videolan.vlc D/VLC: [6cddd0b0/285f] core input: waiting decoder fifos to empty
01-17 14:00:47.508 3863-10379/org.videolan.vlc W/VLC: [6e23a610/288b] mediacodec decoder: EOS sent, waiting for OutThread
01-17 14:00:47.528 3863-10374/org.videolan.vlc E/ACodec: [onOMXFillBufferDone] OMX.realtek.video.dec: saw input EOS, pass it to output
01-17 14:00:47.528 3863-10374/org.videolan.vlc E/ACodec: [OMX.realtek.video.dec] saw output EOS, signal result -1011
01-17 14:00:47.528 3863-10378/org.videolan.vlc W/VLC: [6e23a610/288a] mediacodec decoder: EOS received, abort OutThread
01-17 14:00:47.528 3863-10378/org.videolan.vlc W/VLC: [6e23a610/288a] mediacodec decoder: OutThread stopped
01-17 14:00:47.528 3863-10378/org.videolan.vlc D/dalvikvm: threadid=18: thread exiting, not yet detached (count=0)
01-17 14:00:47.548 2825-2837/system_process D/dalvikvm: GC_EXPLICIT freed 82K, 4% free 152243K/158140K, paused 7ms+529ms, total 2134ms
01-17 14:00:47.568 2825-2839/system_process I/ActivityManager: Start proc MiracastSink.Service for service com.example.RTKMiracastSink/.MiracastSinkService: pid=27287 uid=1000 gids={41000, 1028, 1015, 3002, 3001, 3003}
01-17 14:00:47.588 3863-10335/org.videolan.vlc D/VLC: [6cddd0b0/285f] core input: waiting decoder fifos to empty
01-17 14:00:47.718 3863-10379/org.videolan.vlc D/dalvikvm: threadid=16: thread exiting, not yet detached (count=0)
01-17 14:00:47.718 3863-10335/org.videolan.vlc D/VLC: [6e23a610/285f] core decoder: killing decoder fourcc `h264', 0 PES in FIFO
01-17 14:00:47.728 3863-10335/org.videolan.vlc D/VLC: [6e23a610/285f] core decoder: removing module "mediacodec"
01-17 14:00:47.768 3863-10374/org.videolan.vlc E/ACodec: [OMX.realtek.video.dec] ExecutingState flushing now (codec owns 3/3 input, 4/12 output).
01-17 14:00:47.768 3863-10374/org.videolan.vlc E/ACodec: [OMX.realtek.video.dec] Now Flushing

To this moment torrentstreamer loaded 92 percents

In both cases i use this torrent: http://d.rutor.info/download/543319

[vonclutch]

Hey,

Ok looks like you didn't manage correctly the options for the libvlc. you should take a look of what the (butter/popcorntime ) team did.

VLCOptions

The libvlc is rly nice but a bit (even really) hard to manage, you need the "Hardware Decoder" tthrough the VLCOptions.

Another thing, you should take a look at Exoplayer ( or Exomedia ). it's the best media lib i found for this kind of thing. Lighter and easier to integrate to your project.

[se-bastiaan]

The VLCOptions file we used is exactly the same as the one VLC itself uses if I remember correctly. Maybe a bit (well, a lot) outdated.

I'll not be able to take a look at this in the next +-10 days, after that I'm going to take a look at the torrent. In the mean time, can you try a couple different torrents? Maybe it's just this one specifically.

[vonclutch]

The Libvlc has many implementation regarding the version you use and the VLCOptions is not implemented except if you do it by yourself. So if he didn't implement it, this can be the problem ( or not ^^ ).

And from what i remember on the videolan forum this was a recurent problem.

[se-bastiaan]

I know, I was the one who put VLC into Butter ;) Although, it looks like the Play Store VLC app itself is being used here. The logs say org.videolan.vlc.

[vonclutch]

never said he didn't use the libvlc, just said it's looks like he didn't manage the options ^^

btw nice implementation ( i maybe used some of your code so ^^ ) :+1:

[Nikitenko]

Thank you very much for your replies. Yes, i used Play Store VLC. I'll try your recommendation (using libvlc with options, or Exoplayer). When I test same cases from my comment on my smartphone all works well. I think you can close this issue.