- edited description
Optimize file more
Issue #648
invalid
Version 1.6.10 (1.6.10) - Big Sur 11.3
I have several subler-optimized mp4 where ffmpeg says :
- Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv), 1920x1040 [SAR 1:1 DAR 24:13], 3157 kb/s, 23.98 fps, 23.98 tbr, 100k tbn, 47.95 tbc (default)
- Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 194 kb/s (default)
- Stream #0:2(fra): Subtitle: mov_text (tx3g / 0x67337874), 1920x156, 0 kb/s (default)
- Stream #0:3(fra): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 195 kb/s
- Stream #0:4(fra): Subtitle: mov_text (tx3g / 0x67337874), 1920x156
- Stream #0:5(und): Data: bin_data (text / 0x74786574)
- Stream #0:6: Video: mjpeg, yuvj420p(pc, bt470bg/unknown/unknown), 1400x2100 [SAR 1:1 DAR 2:3], 90k tbr, 90k tbn, 90k tbc
When I stream this file it takes 2 min to start (through vpn and plex).
If I suppress 1 chapter of the chapter stream and then save it with subler (without optimisation), I instantly get this file :
- Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv), 1920x1040 [SAR 1:1 DAR 24:13], 3157 kb/s, 23.98 fps, 23.98 tbr, 100k tbn, 47.95 tbc (default)
- Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 194 kb/s (default)
- Stream #0:2(fra): Subtitle: mov_text (tx3g / 0x67337874), 1920x156, 0 kb/s (default)
- Stream #0:3(fra): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 195 kb/s
- Stream #0:4(fra): Subtitle: mov_text (tx3g / 0x67337874), 1920x156
- Stream #0:5: Video: mjpeg, yuvj420p(pc, bt470bg/unknown/unknown), 1400x2100 [SAR 1:1 DAR 2:3], 90k tbr, 90k tbn, 90k tbc
- Stream #0:6(und): Data: bin_data (text / 0x74786574)
This file starts in 15 seconds with Plex in same conditions.
To me the difference is the order of stream 5 and 6.
So my question : can optimisation also reorder streams to prevent from ending with mjpeg video stream ?
Thank you !
Cyril
Comments (3)
-
reporter -
repo owner I would say that this is a Plex issue and they should fix it. A bunch of bytes in a different position shouldn’t cause such difference in start time.
-
repo owner - changed status to invalid
- Log in to comment