ctrlaltdefeat 8 Posted July 27, 2015 Share Posted July 27, 2015 When I play .ASS subtitles with subtitles being in more places than just the text at the bottom(text being at the top or translation for a sign for example(in case of anime)) libVLC either crashes or will only display the subtitles at the bottom in a plain font. Example of how it should be(taken in MX Player):http://i.imgur.com/HfeQX3N.jpg In the app only the bottom text will display in a plain font instead of the one I see in the screenshot (I was unable to take a screenshot of how it is in the native app because it crashes before I get to take a screenshot and fast forwarding doesnt work(the time goes forward but the frames just freeze and wont move anymore)) I am unsure at what log to provide(or how to get it in the android app) If there are questions or uncertainties, please let me know. CtrlAltDefeat Link to comment Share on other sites More sharing options...
Luke 37008 Posted July 28, 2015 Share Posted July 28, 2015 Do you know if it's direct playing or transcoding? Link to comment Share on other sites More sharing options...
ctrlaltdefeat 8 Posted July 28, 2015 Author Share Posted July 28, 2015 It is synced to my phone using quality Original. But after checking the folder that the files are synced to(the folder on the phone) I see an .srt files(which didnt get removed after the episode was played when the video file was, but that is another issue of its own) Would it help if I posted the srt file? Link to comment Share on other sites More sharing options...
Luke 37008 Posted July 28, 2015 Share Posted July 28, 2015 No. We will just have to remove .ass from the direct play profile if Vlc doesn't yet render them properly. Their issues are now our issues as well, although in fairness, the old player couldn't direct play .ass either so it's not as if we've lost anything. maybe the upcoming vlc 1.5 release will improve it. until then consider not syncing at original quality. Link to comment Share on other sites More sharing options...
ctrlaltdefeat 8 Posted July 28, 2015 Author Share Posted July 28, 2015 When i DO transcode, it is not much better. Result, a case of syncing with quality High to my Galaxy S4: http://i.imgur.com/86wCJVH.png For as far as I've tested(which wasnt thoroughly), karaoke subs(to clarify, subs where parts of words light up in order) won't work at all. But I assume that's an issue we inherit from FFmpeg? Link to comment Share on other sites More sharing options...
Luke 37008 Posted July 28, 2015 Share Posted July 28, 2015 not necessarily. post the transcoding log please. Link to comment Share on other sites More sharing options...
ctrlaltdefeat 8 Posted July 28, 2015 Author Share Posted July 28, 2015 https://gist.github.com/CtrlAltDefeat94/0820f646157c146a69d2 Link to comment Share on other sites More sharing options...
Luke 37008 Posted July 28, 2015 Share Posted July 28, 2015 that's a playback log? Link to comment Share on other sites More sharing options...
ctrlaltdefeat 8 Posted July 28, 2015 Author Share Posted July 28, 2015 I see now, my mistake. I had 2 log files open and accidentally copied the wrong one. The same link should contain the right log now https://gist.github.com/CtrlAltDefeat94/0820f646157c146a69d2 Link to comment Share on other sites More sharing options...
Luke 37008 Posted July 28, 2015 Share Posted July 28, 2015 I'm still not sure that's a playback log but in any case, I think I know what's going on. We convert .ass to plain text in an attempt to reduce transcoding cpu load, and sometimes avoid transcoding altogether if the file would otherwise direct play. i'm just going to take this out, because the side effect is what you see above where the .ass styles are lost because of it. Link to comment Share on other sites More sharing options...
ctrlaltdefeat 8 Posted July 28, 2015 Author Share Posted July 28, 2015 Okay. Sounds good That about the log I think is strange. That's the only log file of the day with the filename in it I used to test the transcode. Next question might be going off-topic a bit but, how come that there are .srt files in the sync folder(on the phone) while the quality Original was used? And more important, why weren't they removed after the media file was removed when the episode was set to watched? Link to comment Share on other sites More sharing options...
ctrlaltdefeat 8 Posted August 1, 2015 Author Share Posted August 1, 2015 @Luke, The update made it better but unfortunately hasnt fixed it fully. When there are subs in multiple places(text at the top and one at the bottom), only one will be displayed. When signs for example are translated(and the subs is placed on the sign to replace the original text on it), it still won't show. Link to comment Share on other sites More sharing options...
Luke 37008 Posted August 1, 2015 Share Posted August 1, 2015 Is the server burning them in with ffmpeg? If so then all we can really do is open an ffmpeg ticket. Link to comment Share on other sites More sharing options...
ctrlaltdefeat 8 Posted August 1, 2015 Author Share Posted August 1, 2015 I am unsure how to check that. I can provide the transcoded file via PM if that helps I tried some more. If I sync with Original quality, the subs will play just fine/correct in MX player, but in libvlc it'll play with basic font instead of the original one and like said before it'll show subs in only one place. If I sync with High quality, the subs will be broken in MX Player, like in a previously shown image http://i.imgur.com/86wCJVH.png. And the location where the subs are located isnt correct(for example subs will be displayed at the top where they wouldve displayed on say height 30%(measuring bottom to top). With quality High the subs won't even turn on in libvlc. Link to comment Share on other sites More sharing options...
Luke 37008 Posted August 1, 2015 Share Posted August 1, 2015 yes. when the next server release rolls around .ass subtitles will always be burnt in. I think that will at least be better than the text conversion that is going on now. Of course, if the burning in process isn't perfect, then it's likely an issue that needs to be reported with ffmpeg. Link to comment Share on other sites More sharing options...
ctrlaltdefeat 8 Posted August 1, 2015 Author Share Posted August 1, 2015 I am uploading the both the High quality and the Original quality file and will PM you the link to it. Might also make it easier for you to see the results of both cases. Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now