Hi,
I'm using Subler to mux subtitles from a .srt file into an .mp4 file that was
output by VideoReDo (running in Parallels Desktop on my Mac). My aim is to put
the Subler .m4v output file into my iTunes library and then stream it via Home
Sharing to my iPad's Videos app.
The .mp4 video file input to Subler has 960x544 resolution and a data rate
shown in QuickTime Player of 2.40 Mbit/s.
I have several questions/issues:
(1) If I don't modify the Visual Settings of the subtitle track that I see in
Subler after I have dragged my .srt file into Subler's window (where it appears
alongside the dragged-in video and sound tracks) I get a remuxed .m4v file that
nominally works fine on my Mac but gives me trouble when streamed to my iPad.
The issue seems to be that I get unwanted pauses during playback, but only when
I am viewing the video with subtitles turned on. The playback buffer seems to
run out of material to play. With subtitles turned off, there is not a problem.
I am able to monitor the data rate, i.e., the numbers of bytes being sent and
received, by watching these statistics as reported by my router. With subs off,
the streaming data rate is quite moderate. When I turn subs on, the streaming
data rate skyrockets.
The problem persists if, in VideoReDo, I drastically lower the data rate of
what is to become the Subler .mp4 input video, by restricting the average and
maximum bitrates to the point where the video has a lot of macroblocking.
So, best I can tell, Subler is by default creating a Tx3g subtitle track that
generates a lot of bitrate (or data rate) overhead.
Before Subler creates its remuxed .m4v output file, the Visual Settings
parameters for the subtitles track are basically all zeroes, and Preserve
Aspect Ratio is checked. (Alternate Group is 2, Forced is No, and Forced track
is None.)
Afterward, I see:
Normal Size: 960 x 81 pixels
Scaled Size: 960 x 81 pixels
Preserve Aspect Ratio: checked
Aspect Ratio: 1 x 1
Offset: 0 x 462 pixels
Alternate Group: 2
Forced: No
Forced track: None
With subtitles off on the iPad, my network sees about 6 million bytes being
streamed every 20 seconds. With subtitles on, it sees about 20 million bytes
being streamed every 20 seconds.
So that's a sizable data rate overhead. My main question is, how can I lower it?
(2) I made the assumption that I could lower it by fiddling with the Visual
Settings of the subtitles track before saving Subler's .m4v output file. But I
find that changing the parameters I see there doesn't work as I expected.
If I start with these default/null values:
Normal Size: 0 x 0 pixels
Scaled Size: 0 x 0 pixels
Preserve Aspect Ratio: checked
Aspect Ratio: 0 x 0
Offset: 0 x 0 pixels
Alternate Group: 2
Forced: No
Forced track: None
I can change them to:
Normal Size: 0 x 0 pixels
Scaled Size: 960 x 10 pixels (i.e., 1/8 of the original 81 vertical pixels)
Preserve Aspect Ratio: not checked
Aspect Ratio: 0 x 0
Offset: 0 x 534 pixels
Alternate Group: 2
Forced: No
Forced track: None
After saving the .m4v file and closing the window in Subler, then reopening the
resulting .m4v file in Subler, the subtitles' Visual Settings turn out to have
become:
Normal Size: 960 x 10 pixels
Scaled Size: 960 x 10 pixels
Preserve Aspect Ratio: checked
Aspect Ratio: 1 x 1
Offset: 0 x 462 pixels
Alternate Group: 2
Forced: No
Forced track: None
So it looks like my settings were overridden for some reason. My second
question is, why?
(3) That second .m4v file streams with, if anything, a higher data rate than
the first one: on the order of over 40 million bytes every 20 seconds, when
subtitles are on. Third question: Why?
(4) So I believe I need to get the elevated data rates down, when I am
streaming these videos to the iPad with subtitles on. How can I go about doing
that? Would I be able to do it with manually entered Visual Settings
parameters? If so, how would I keep the parameters I enter from being
overridden?
Thank you very much in advance for your advice on your quite useful remuxing
utility.
Best,
Eric Stewart
Catonsville, MD
epstewart2004@yahoo.com
Original issue reported on code.google.com by epstewar...@gmail.com on 9 May 2014 at 7:04
Original issue reported on code.google.com by
epstewar...@gmail.com
on 9 May 2014 at 7:04