Seeking and metadata extraction from matroska file

[p2004a]

I created a simple Matroska file with Opus stream: https://drive.google.com/file/d/0B8b4jUX2s15VTWRKbjk4bmRIX1E/view?usp=sharing

The playback starts fine but seeking fails. After pausing, unpausing also restarts playback.
The other problem is the app didn't extract both the title and the cover from the file.

After re-encoding file from mka/opus to mka/aac using ffmpeg, problems didn't disappear so it looks like a problem with Matroska container support.

App-Version: git master (c89b1ad)
Phone Name: Sony Z2, Nexus 5X API 26 x86 (Emulator)
Android Version: 6.0.1, 8.0

[PaulWoitaschek]

Can you report this upstream?

[p2004a]

TBH I'm not sure what do you mean by upstream. I didn't investigate which part of the application is responsible for seeking and what library or sth fails in doing that. I think I can do it but not earlier than in the next week.

[PaulWoitaschek]

The part of the application responsible for the media playback is ExoPlayer, so it would be great if you could report it there.

[0rAX0]

Anyway around this issue before I go convert my files?

[PaulWoitaschek]

@0rAX0
I think this issue is rate. Try it and report if it does not work please.

[0rAX0]

Actually, I stumbled upon it the other day and came searching the open issues before reporting. :)

The files were Youtube videos downloaded using JDownloader with AAC option to only get the sound. I can provide more info on the issue if you want.

[rezad1393]

I have the same issue.

[x0wllaar]

@rezad1393 @p2004a Did you try doing
ffmpeg -i bad_file.mka -dash 1 -codec copy new_file.mka
?

Thing is, ffmpeg does not write information that is necessary for seeking/chapter selection to work to audio-only Matroska's and WebM's unless you explicitly ask for it (-dash 1 option)

See here for further info

[p2004a]

I confirm that what you suggested @x0wllaar fixes the problem.

Few quotes about Cues element that is missing from the Matroska files that don't work:

From Matroska specification:
About Cues element: "Should be mandatory for non "live" streams."
About mandatory elements: "All the other elements can be omitted although Cues (index) improve the playback experience greatly."

From webm spec, demuxer guidelines:
"Seeking will be disabled if the webm file does not have a key frame Cues element.
The project is considering support for seeking without a Cues element."
But from the different place: "The Cues element SHOULD contain only video key frames, to decrease the size of the file header.". It's not clear to me how should it work for audio only files.

So it seems that it's kind of fine to not support seeking in files without Cues. Maybe it would be nice to detect those files and report to the user why he can't seek in them and hint how to fix it?

[rezad1393]

what about the aac files downloaded from youtube?
I have the same broblem 0rAx0 has.

[giddie]

So thanks to this thread I've figured out how to add cues to my MKA files by using ffmpeg with --dash 1 - thanks so much!

But now I've found that I'm unable to get cover art working - I've added the cover.jpg file as an attachment to the container, and it appears in VLC, but Voice still shows a placeholder. Should cover artwork extraction be working for MKA?

[giddie]

And in fact now, it seems Voice is unable to read the Cue data from my mka files again, and the timestamps are showing hundreds of hours on the player screen and negative on the index screen. Was there an update recently that could have broken it?

[PaulWoitaschek]

Send me a file and I'll look into it.

[giddie]

Here you go. I put this together from TED talk audio, converted with ffmpeg to AAC in an MKA container, using the --dash 1 flag to create CUEs. I used MKVToolnix to generate chapters at every minute marker. I also attached a cover for good measure, and the good news is that the cover extraction now works perfectly. Unfortunately, the timestamps and seeking are not.

sample.mka.gz

[giddie]

The situation was the opposite before the 1st April update - timestamps, seeking, and chapters were all working great, but cover extraction was not.

[PaulWoitaschek]

Does it work for you in 5.0.1? @giddie

[giddie]

I'm still on 5.0.0 from Google Play. Is there an APK I can test?

[PaulWoitaschek]

Sure, I attached the release here.
https://github.com/PaulWoitaschek/Voice/releases/tag/5.0.1

Super annoying how slow google play releases on corona ^^
It was just an increase in the rollout; it's not like someone would need to manually review that.

[giddie]

Yes! That fixes it, and the cover art is still extracted correctly. I did notice that the grid layout doesn't work with this build — only one tile per line instead of two, but that's by the by.

Thanks for taking the time to sort this :)

[PaulWoitaschek]

@giddie can you open a ticket with a screenshot?

[giddie]

Sorry, I was being an idiot: it was only because I had two audiobooks visible, and one was "Current" and the other "Not started yet". Everything is perfect. Thanks again!