Hi,
I would like to request for a play list feature.
Problem context:
I have a whole list of video files (+50 videos and counting) stored within a folder for a certain topic.
But I only wish to play certain videos for certain sessions of my meeting with my friends - planning ahead. However, as they are not sorted according to their file names, currently it's very hard to jump here and there. I have to stop a video, search for another video, then continue the playback.
Or I may wish to play certain videos for my kids from within another folder or a combination of folders.
My wish:
To be able to create multiple video playlist for different purposes.
That I can select a video, choose "add to a play list", select which play list from the ones I've created or add to (i.e. create) a new playlist.
Thank you for your considerations.
Regards.
This feature request already exists in the feature requests list, under high priority #8.
This feature is still missing on the latest mx player, I could not create a plylist
A VERY needed and basic feature indeed!
The player sees the m3u file but does not play the contents.
Hello everyone.
Registered user here of the pro version, I was wondering if its possible to implement IFO support when it comes to play a VIDEO_TS folder.
Playing vob files works great. I usually rip the DVD main movie via MakeMKV and play the resulting MKV with MPEG2 flawlessly, but when that main movie is greater than 4 GB I cannot do anything, because my device doesn't support any filesystem other than FAT32. That's why the IFO support would make this OK, copy vob files (1 GB) with IFO file and play as a standard VIDEO_TS folder (Im not talking about menus, just the IFOs)
Thanks
dalecooper said:
Hello everyone.
Registered user here of the pro version, I was wondering if its possible to implement IFO support when it comes to play a VIDEO_TS folder.
Playing vob files works great. I usually rip the DVD main movie via MakeMKV and play the resulting MKV with MPEG2 flawlessly, but when that main movie is greater than 4 GB I cannot do anything, because my device doesn't support any filesystem other than FAT32. That's why the IFO support would make this OK, copy vob files (1 GB) with IFO file and play as a standard VIDEO_TS folder (Im not talking about menus, just the IFOs)
Thanks
Click to expand...
Click to collapse
Normally if you start playing first vob file, then after completing first file mx will play the second vob file automatically. it'll be automatically added to the queue if it's in the same folder. (make sure "back to list" is disable in Settings 》Player)
Thanks.
Yes, I know that. The problem is when the movie has several audio or subtitle tracks, sometimes its unpredictable which one is gonna start with the next vob file, because the vob files by themselves don't have an identification of language other than 0x80-like, so you gotta change the track again and there's a pause that wouldn't be with an IFO file. Also, depending of the methods and tools of extracting the vobs, sometimes the length of the vob gets confused.
I am aware that is possible to watch a whole movie with this, I was just wondering probably this is not a big implementation (almost like a playlist?) and could make the playing of DVD movies an awesome feature. I understand this is not a feature most people would request, but I like not having to convert, just extract the movie, and watch it as is. Even when I know by H264 standards is a waste of space, but with 32gb cards that cheap nowadays, it's comfortable.
Thanks.
dalecooper said:
Thanks.
Yes, I know that. The problem is when the movie has several audio or subtitle tracks, sometimes its unpredictable which one is gonna start with the next vob file, because the vob files by themselves don't have an identification of language other than 0x80-like, so you gotta change the track again and there's a pause that wouldn't be with an IFO file. Also, depending of the methods and tools of extracting the vobs, sometimes the length of the vob gets confused.
I am aware that is possible to watch a whole movie with this, I was just wondering probably this is not a big implementation (almost like a playlist?) and could make the playing of DVD movies an awesome feature. I understand this is not a feature most people would request, but I like not having to convert, just extract the movie, and watch it as is. Even when I know by H264 standards is a waste of space, but with 32gb cards that cheap nowadays, it's comfortable.
Thanks.
Click to expand...
Click to collapse
We will check out this feature.
Thanks
Hi there.
Great player and thanks very much for all the devs' hard work. I'm wondering, since I have more than 25,000 DVDs in my collection, if there has been any further consideration of implementing a full DVD play feature.
Thanks.
Any update on this? I would be prepared to pay money for a full DVD play feature to be implemented.
Thanks.
Hello all, I have a little bit of an odd question for you today
I'm currently writing an app to pull metadata information/covers/subtitles from my Plex Media server, convert my videos to mp4 format, then embed the metadata/files into them using standard ID3v2 tags. So far I have everything working well; my files are looking great in Windows Explorer, and Media Player Classic displays the custom stream titles correctly, but unfortunately when I view them on Android I run into some issues. Now to be fair I had no expectations that the data would be read by most explorers/players as the inclusion of such information is up to the developer, but being it that within most players the streams are selectable I was really hoping that at least the stream's title would be one of the tags that would be read?
Currently I have re-titled each streams using the "handler" tag using FFMPEG (although in MediaInfo seems to display the tag as "Title"). As an example, my first audio stream will be displayed as "English (5.1)", the second as "English (Stereo)", and my subtitle streams usually fall in line like "English (Full)" or "English (Parts)". When using Media Player Classic on my Windows PC the stream titles are displayed correctly within the player options, but when I switch streams using MX Player I only see Generic titles for audio like "Audio track #1 - English", "Audio track #2 - English", and simply "English" for the subtitles? Unfortunately without seeing the custom stream titles in MX Player I cannot really tell which stream is which?
Now given the generic stream names shown in MX Player it seemed like the only file information used was the language that was set on each stream (which seems to be backed up under Tools >> Properties as it is the only real stream metadata that shows up?), so I refrained from setting the language tags in case MX Player was simply using that by default...but still no change? With that said, I would assume that MX Player must be getting some of the information to generate the stream titles so I am curious to know if anyone can provide me with the correct metadata tag to set to ensure I get the proper text to display for each stream...or if this is even possible to begin with?
Now I do know that MP4BOX uses the tag "handler_name" instead of "handler", but I am trying to stick to just FFMPEG if possible before I incorporate it into my project as it seems a bit much to include it for a single set of tags? Now unfortunately I was unable to set the "handler_name" tag with FFMPEG as it appears to overwrite the information with it's own text for each stream (like AudioHandler, SubtitleHandler, etc.), so before I go to far and incorporate MP4BOX, I'd just like to ensure I know whether I can expect the desired results from the "handler_name" tag?
Any help and/or further information would be greatly appreciated, I use Android TV Box's w/ MX Player as my default setup for all my TV's at home, so this would definitely be a plus if I could figure this one out!
TIA!
Are G. Bee said:
Hello all, I have a little bit of an odd question for you today
I'm currently writing an app to pull metadata information/covers/subtitles from my Plex Media server, convert my videos to mp4 format, then embed the metadata/files into them using standard ID3v2 tags. So far I have everything working well; my files are looking great in Windows Explorer, and Media Player Classic displays the custom stream titles correctly, but unfortunately when I view them on Android I run into some issues. Now to be fair I had no expectations that the data would be read by most explorers/players as the inclusion of such information is up to the developer, but being it that within most players the streams are selectable I was really hoping that at least the stream's title would be one of the tags that would be read?
Currently I have re-titled each streams using the "handler" tag using FFMPEG (although in MediaInfo seems to display the tag as "Title"). As an example, my first audio stream will be displayed as "English (5.1)", the second as "English (Stereo)", and my subtitle streams usually fall in line like "English (Full)" or "English (Parts)". When using Media Player Classic on my Windows PC the stream titles are displayed correctly within the player options, but when I switch streams using MX Player I only see Generic titles for audio like "Audio track #1 - English", "Audio track #2 - English", and simply "English" for the subtitles? Unfortunately without seeing the custom stream titles in MX Player I cannot really tell which stream is which?
Now given the generic stream names shown in MX Player it seemed like the only file information used was the language that was set on each stream (which seems to be backed up under Tools >> Properties as it is the only real stream metadata that shows up?), so I refrained from setting the language tags in case MX Player was simply using that by default...but still no change? With that said, I would assume that MX Player must be getting some of the information to generate the stream titles so I am curious to know if anyone can provide me with the correct metadata tag to set to ensure I get the proper text to display for each stream...or if this is even possible to begin with?
Now I do know that MP4BOX uses the tag "handler_name" instead of "handler", but I am trying to stick to just FFMPEG if possible before I incorporate it into my project as it seems a bit much to include it for a single set of tags? Now unfortunately I was unable to set the "handler_name" tag with FFMPEG as it appears to overwrite the information with it's own text for each stream (like AudioHandler, SubtitleHandler, etc.), so before I go to far and incorporate MP4BOX, I'd just like to ensure I know whether I can expect the desired results from the "handler_name" tag?
Any help and/or further information would be greatly appreciated, I use Android TV Box's w/ MX Player as my default setup for all my TV's at home, so this would definitely be a plus if I could figure this one out!
TIA!
Click to expand...
Click to collapse
Hi
MX player is using 'title' metadata as the primary stream name, if exists. 'handler' or 'handler_name' looks like irrelevant to stream name. Do you have definition for these metadata?
Thanks
bleu8888 said:
Hi
MX player is using 'title' metadata as the primary stream name, if exists. 'handler' or 'handler_name' looks like irrelevant to stream name. Do you have definition for these metadata?
Thanks
Click to expand...
Click to collapse
Thank you for your response, and I apologize for not elaborating further. There was no official definitions found to set the stream "title" with FFMPEG that I could find; and boy did I search...and search... In all fairness I am still a bit new to FFMPEG so maybe I just didn't quite know what keywords to search for specifically?
To clarify, the tags "handler_name" & "handler" are not id3 tags from what I could tell. "handler_name" was the tag name that appeared in FFMPEG's output information next to where the stream title was originally found. The tag "handler" was also found via trial and error when setting the "title" & "handler_name" tags failed. The "handler" tag also seems to replace the auto-generated "handler_name" tag that was set on the original file.
Now when I view the file information using MediaInfo after either setting the "handler_name" with MP4BOX, or "handler" with FFMPEG, they both still display under the tag "title", which leads me to believe that they are just name masks for the "title" tag which FFMPEG recognizes in their CLI? As suggested, with FFMPEG I have tried setting "-metadata:s:s:0 title="English (Full)", and it did show the tag name/information in the command output, but when I checked the file afterwards with both MediaInfo & FFMPEG, it did not appear to save it to the file? This was also the same effect when trying to set "handler_name" with FFMPEG. Before I go too far into detail here and junk up this thread with my FFMPEG issues, Here is some further information regarding my troubles with this if you would like to read up on it further.
My original post is on StackOverflow which explains it in more detail:
stackoverflow.com/questions/27518432/how-to-set-custom-handler-name-metadata-for-subtitle-stream-using-ffmpeg
I will go ahead and re-visit the "title" tag as per your suggestion, and I will also test it out with a few different versions of FFMPEG to ensure it's not a bug issue I overlooked...I primarily use a self-compiled build so who knows?
If by chance any of you have successfully set the "title" tag on a stream with FFMPEG, I would love to see an example of your command to see how this was accomplished.
Thanks again for your assistance, and I apologize again for half-hijacking this thread with my FFMPEG issues! Above all else, I'd just like to ensure I configure my setup to maximize my enjoyment with MX Player
So upon further testing I was able to conclude that my self-compiled build of FFMPEG does not set the "handler" tag at all. I'd also like to correct my previous statement and say that when you set it using the "handler" tag it replaces the current information under the "handler_name" tag, it does not replace the actual tag "handler_name". I have also verified that "handler_name" is indeed the equivalent to "title" everywhere else as shown using multiple tools like MediaInfo & ExifTool. Even with my latest run, MX Player does not seem to read the information set on the stream, it simply displays a generic name comprised of the audio stream number and language?
This got me thinking, and while playing around trying to figure this out I noticed there was a difference with accessible information within MX Player when playing local/network files. Initially I was playing the files through an SMB connection and when I went to Properties >> Tools, the only meta information shown was Resolution, Type, & the Audio's Language? After copying it to the device and playing it locally, When I went back to properties all of the metadata displayed just fine? The only problem I noticed was that although the stream title on the file was set, it only appeared to display the stream's language data and did not display the title set on the individual stream. I figured this might be intentional as what is actually displayed in MX might have been specifically chosen to keep the details from being over bloated? But nonetheless it just sat a bit funny that the only metadata showing for the stream in MX is the language, and that is also what is used within the auto-generated stream names I am currently seeing?
So I ran one more test, and I think I figured it out.
I removed the language metadata from the file by applying "-map_metadata -1" before I defined the audio stream title using "-metadata handler="Test"". Now when I play the file, Instead of it saying "Audio track #1 - English", it only says "Audio track #1". From what I can tell, the below seems to be the order of operation for how the stream names are displayed:
Audio:
If there is a title set on the audio stream, then as suggested, MX should use this information first
If no title is found, Use the default name "Audio Track #1" (where 1 is the index number of the audio stream)
If there is a language set on the audio stream then append " - [Language]" to the end of the default name.
Subtitles:
If there is a title set on the subtitle stream, then as suggested, MX should use this information first
If no title is found, check for user-defined language
If no language is found, use default name "Track #1" (where 1 is the index number of the subtitle stream)
So if it is supposed to be reading the title tag first and using that information as the stream title, then maybe there is a bug report I should be filing because this does not appear to work for me. Otherwise, it appears that MX is set to a generic title and will only append necessary information like the language to help clarify which stream is which? If that is the case, then I might have to make a feature request instead.
Additional Info:
Since this fluke discovery I have also figured out that the display of metadata on network files seems to be missing only when using H/W Decoder, and the information displays just fine under properties when using S/W & H/W+ Decoders. Furthermore, if I switch from H/W to S/W or H/W+, then switch back to H/W, the metadata information appears to show just fine. I am also having similar issues with the subtitle button displaying when using the H/W encoder. Upon first load the button does not show up, but when I switch to another decoder it immediately appears and (like the metadata) it stays when I switch back to the H/W decoder. I am not sure if this is actually decoder-specific, it almost seems like a gui refresh/update issue of sorts? As H/W is my default, it might not display at start-up regardless of the decoder and requires the decoder change to update the gui?
I just updated to the latest version "Pro 1.7.38 (NEON)" from https:// sites.google.com/site/mxvpen/download, and I am currently using the custom codec pack found in the forum. The device I am currently testing it on is a Rikomagic MK902 TV Box.
I will also provide the results from MediaInfo below, as well as append some images of the issue:
Code:
Format : MPEG-4
Format profile : Base Media
Codec ID : isom
File size : 749 MiB
Duration : 1h 31mn
Overall bit rate : 1 150 Kbps
Movie name : Atomic Title
Album : Atomic Album
Album/Performer : Atomic Album Artist
Grouping : Atomic Grouping
Performer : Atomic Artist
Composer : Atomic Composer
Genre : Atomic;Genre;Test
Description : Atomic Description
Recorded date : 2000
Writing application : Lavf56.18.100
Comment : Atomic Comment
LongDescription : Atomic Long Description
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : [email protected]
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 1h 31mn
Bit rate : 1 050 Kbps
Width : 1 280 pixels
Height : 528 pixels
Display aspect ratio : 2.40:1
Frame rate mode : Constant
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.065
Stream size : 684 MiB (91%)
Writing library : x264 core 142 r2479 dd79a61
Encoding settings : cabac=1 / ref=4 / deblock=1:-1:-1 / analyse=0x3:0x133 / me=umh / subme=9 / psy=1 / psy_rd=1.00:0.15 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-3 / threads=48 / lookahead_threads=4 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=2pass / mbtree=1 / bitrate=1050 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=31250 / vbv_bufsize=31250 / nal_hrd=none / filler=0 / ip_ratio=1.40 / aq=1:1.00
Color primaries : BT.709
Matrix coefficients : BT.709
Color range : Limited
Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : 40
Duration : 1h 31mn
Bit rate mode : Constant
Bit rate : 93.9 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Compression mode : Lossy
Stream size : 61.2 MiB (8%)
Title : Test
Language : English
Some metadata are defined in libavformat/avformat.h
(http://git.videolan.org/?p=ffmpeg.g...1a95fca7d90bd5362e8af855e27c49d439230;hb=HEAD)
I am not sure these are standard metadata but at least looks like de-factor standard in my experience.
Anyway, HW decoder is actually java.media.MediaPlayer Android Java class and it can't recognize metadata unlike HW+ and SW decoder.
If HW decoder is used for network source, MX does not uses FFmpeg at all unless source is from local server such as 192.168.x.x or localhost(127.0.0.1)
If you are launching MX using Intent, you can set title for individual items using "video_list.name" extra.
See https://sites.google.com/site/mxvpen/api for more information.
https://sites.google.com/site/mxvpen/api
bleu8888 said:
Some metadata are defined in libavformat/avformat.h
(git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/avformat.h;h=4211a95fca7d90bd5362e8af855e27c49d439230;hb=HEAD)
I am not sure these are standard metadata but at least looks like de-factor standard in my experience.
Anyway, HW decoder is actually java.media.MediaPlayer Android Java class and it can't recognize metadata unlike HW+ and SW decoder.
If HW decoder is used for network source, MX does not uses FFmpeg at all unless source is from local server such as 192.168.x.x or localhost(127.0.0.1)
If you are launching MX using Intent, you can set title for individual items using "video_list.name" extra.
See https ://sites.google.com/site/mxvpen/api for more information.
Click to expand...
Click to collapse
Thank you for your reply but I am not entirely sure what you are trying to point out from that link you provided? Which metadata is "some"? Not to mention I am a Python developer and that is what...C? Also that link is 2500+ lines, and I would be more then happy to look at it further for any relative information that it might contain but without knowing why I am looking, what I'm looking at, or what I am looking for, I really don't want to spend the whole night reading a novel of code I probably wouldn't make heads or tales of anyhow? I don't mean to be disrespectful in any regard, but please understand that I can only compile the FFmpeg code following instructions, I have no idea what the code means.
I am also not sure if I am following all of what you are saying with regards to "If HW decoder is used for network source, MX does not uses FFmpeg at all unless source is from local server such as 192.168.x.x or localhost(127.0.0.1)"? Are you suggesting that the media must be local to the device it is playing on (ie; attached via USB)? Or are you suggesting that as long as it is within a local network then H/W decoder should use FFmpeg (ie; all addresses starting with 192.168.x.x)? Also note that regardless of this statement, I know for fact that MX Player, network or local, still reads the stream's "language" tag's just fine and if found, uses that information to compile the generic subtitle stream's title. This will be explained in more detail in a few moments. Now if it helps to clarify further I am currently streaming the videos through my local network. The drive with the files are hosted on a PC in the room next to me using a Windows shared folder (SMB), and the device playing them is a Rikomagic MK902 Android TV Box, which is right in front of me. I am not trying to remote play the files outside of my local network.
I have also looked at the available API but in all fairness it does not really have any relevance towards my issue...at all? The title of this thread suggests I am referring to the names of the individual streams within a video, and the conversation so far has had nothing to do with the display title of the movie itself? I am not trying to display a new title for the video as a whole, I am trying to figure out which metadata tag MX Player reads to obtain it's stream title information from; as in the title(s) that are displayed when you click either the subtitle or audio buttons while a video is playing. That said, I am sure that ES File Explorer is launching it via an Intent but I have no way to access/alter what it is/isn't sending along with the URL. Also from my experiences, there are no actual issues accessing file metadata via SMB as I can access that information via the file's properties from within any explorer, Windows or Android? The only real question is whether it was implemented or not by the developers?
Now the reason I ask is because I would like to properly encode my files so that the titles I set for the stream(s) are displayed in place of the Generic titles that MX Player seems to use.
Here is an example of the current generic stream title(s) that display in MX Player:
Audio track #1 - English
The first part of the title "Audio track", is generic. The "#1" represents the stream number, and if there are two audio streams then it might say "#1" and/or "#2". Last but not least, " - English" is the detected language of the stream. I know that it is detecting the language metadata because when I remove the language tag from the file, the generic title changes to "Audio track #1". That said, my video files already have embedded titles associated with each audio/sub stream(s), and although I understand the need for generic names for files that do not have such metadata, I do not understand why this metadata is being ignored when it is available?
I do appreciate your efforts to respond, but in all fairness I am not quite sure if you really understood my question? If you did, and my lack of understanding the C code is stopping me from understanding what you were trying to suggest, then please let me humbly apologize and ask that you further clarify what you were suggesting, in layman's terms, for the less C-educated individuals like myself.
Here is example of the current generic titles, next to them are the custom titles that are already embedded into my files and should be replacing the generic ones.
Audio:
(generic) Audio track #1 - English <--> English (5.1) (custom)
(generic) Audio track #2 - English <--> English (Stereo) (custom)
Subtitle:
(generic) Track #1 - English <--> English (Full) (custom)
(generic) Track #2 - English <--> English (Parts) (custom)
It was suggested within the first response that MX Player "should" first look for the stream's title, then use the generic if none was found, but after some testing this does not appear to be the case. On first thought I had the exact same assumption because it really seemed like the logical/standard way to go about it, but after the testing was done I am now unsure and I would like some verification as to whether MX Player is actually setup to check for the stream's title, or not? If so, then I assume I should be filing a bug report? If it isn't, then I can simply put in a feature request to have MX Player read custom stream tags first, then imply the generic tag if none is found.
After that, all I'll need to do is be patient and hope it is approved/added in the near future....
Hopefully my further explanation has helped clarify the issue for you!
**UPDATE**
I think I might now understand more of what you are suggesting.
1. The "titles" are submitted with the intent, and not pulled from the metadata of the file; provided it is streaming.
2. Because the intent generated by ES File Explorer is not submitting the stream's title along with their intent, MX Player is defaulting to generic tags due to lack of provided information.
I should also point out that the display of the custom titles fails on locally played files just the same, but they are also being initiated by ES File Explorer so I will have to test them from within MX Player itself before I will know for sure if this is the issue
Looking back at the API, I only see "video_list.name" & "subs.name", which imply the Intent could at least handle the subs stream titles, but nothing about the audio streams seem to be defined? That said, I still cannot really access the intents that are being sent anyhow as they are being created by ES File Explorer when you launch the file
**UPDATE 2**
I have tested the files through MX Player directly and there is no change to the stream titles at all. It does appear that the language metadata is read regardless of whether it is played locally, or via a SMB connection so it appears the title metadata "could" be read, but it appears that it is being disregarded. Either way, the purpose of my app is to prepare the files with as much usable metadata as possible. How MX Player, or the application that launches MX Player via intent, handles the data I have provided within the media file is not really something that relates to what I am trying to accomplish, nor do I have any control over.
The first response I received suggested that MX Player should be using the stream's title, if found, but no matter how I test it this does not appear to be the case. As mentioned before, I already know that the stream's language metadata is being used to form the generic stream's name as the removal of these tags actively effect the stream name's end result, so access to the title information should be possible.
Unfortunately I am still somewhat confused with the suggestions/lack of clarification made within the second post but from what I could gather, H/W decoder has something to do with it if it is played via the network as it will not use FFmpeg. I'm assuming this suggests that FFmpeg is being used to gather the metadata, and because H/W decoder doesn't invoke it via the network(?), it will not display?
All I can say is that no matter which decoder is selected, whether it is played locally or via a local network, the stream's titles are not implemented. Although I would obviously prefer the first suggestion to be true , I have no problems if it isn't, and would be happy to wait in line for a feature request to be implemented (if it all). I would just like some solid clarification as to whether MX Palyer should be using the metadata or not, and if so, should I file a bug report after all the testing I have done?
If you would like to reproduce this issue, please modify the below FFmpeg command with a video & srt file on your system and give it a run:
Code:
ffmpeg -fflags +genpts -i "Video.mp4" -i "Video.srt" -map 0:0 -map 0:1 -map 0:1 -map 1:0 -map 1:0 -c:v copy -c:a:0 copy -c:a:1 copy -c:s:0 mov_text -c:s:1 mov_text -map_metadata -1 -map_chapters -1 -metadata:s:a:0 language="eng" -metadata:s:a:0 handler="English (Stereo)" -metadata:s:a:1 language="eng" -metadata:s:a:1 handler="English (5.1)" -metadata:s:s:0 language="eng" -metadata:s:s:0 handler="English (Full)" -metadata:s:s:1 language="eng" -metadata:s:s:1 handler="English (Parts)" -movflags faststart "output.mp4"
This should result in a file named "output.mp4" with 2 audio streams & 2 subtitle streams; all of which have two metadata tags set on each stream; title & language. You can use MediaInfo for your OS (CLI & GUI versions available - http: //mediaarea.net/en/MediaInfo/Download) to verify that the information is set on the file. If you prefer to use FFmpeg to obtain the metadata then look for handler_name under each stream, instead of Title. After testing the stream names for both Audio/Subtitle streams, you can remove the language tags from the same command and run it again, you will see that even with the Title tag set, the generic stream name will only change when the language tag is set/unset.
Thanks again!
Hi guys!
First, love MX Player, been using it for years for both local and network playback on Android devices in our household. Now, SMB support has improved much over the years, and is now more or less flawless. One thing though, often — especially when it comes to television series — there is a subfolder that is 99% of the times named Subs, where the subtitles are located. Now, in my case, I use Total Commander for all operation on my Android devices, and use the "Play (in foreground)" option in the SMB tree to make it start streaming over the LAN at home. Now, if the video.mp4 and subtitle.srt is in the same folder on the NAV/Windoze box/whatever, it loads up automatically, but not if it's in the .\Subs\ folder. Would this be possible to fix? Many players (e.g. MPC-HC) has .\Subs\ automatically searched since it's a very common place for subtitles to land. As for now, if I depend on subs, I need to prepare by moving them to be in the folder where the (for instance) television series season is. For those who has collections and wish to preserve a specific folder tree structure, this can be somewhat a hassle. Of course, this is truly a first world problem.
Thanks for a great player.
Cheers!
gewone said:
Hi guys!
First, love MX Player, been using it for years for both local and network playback on Android devices in our household. Now, SMB support has improved much over the years, and is now more or less flawless. One thing though, often — especially when it comes to television series — there is a subfolder that is 99% of the times named Subs, where the subtitles are located. Now, in my case, I use Total Commander for all operation on my Android devices, and use the "Play (in foreground)" option in the SMB tree to make it start streaming over the LAN at home. Now, if the video.mp4 and subtitle.srt is in the same folder on the NAV/Windoze box/whatever, it loads up automatically, but not if it's in the .\Subs\ folder. Would this be possible to fix? Many players (e.g. MPC-HC) has .\Subs\ automatically searched since it's a very common place for subtitles to land. As for now, if I depend on subs, I need to prepare by moving them to be in the folder where the (for instance) television series season is. For those who has collections and wish to preserve a specific folder tree structure, this can be somewhat a hassle. Of course, this is truly a first world problem.
Thanks for a great player.
Cheers!
Click to expand...
Click to collapse
Thanks for your post. Currently MX Player doesn't directly support the SMB. As MX Player doesn't have the SMB client, it can't get the actual path. Most of them act like a localhost. If the file listing is not possible, MX will try to get the subtitles by some brute force methods. So, It's very difficult at the moment.
But, we have some plans to work on our own SMB support. Once it's implemented, It may make things easy for you