" We only support 3 kinds of subtitles... NTSC closed captions, PAL teletext and DVB subtitles. And we only support them for passthrough, which means you can only keep them if the output contianer also supports them. MKV does not support any of them, so all subtitles are lost when saving to MKV. MP4 supports closed captions, but not the other two. The only format that supports all 3 is TS."
I now had the time to carry out a few more experiments with the improved playback of ts-streams in the VLC player.
Basically, there are no longer any notable delays with the jumps. But the changed behaviour only takes effect when the ts muxrate is set to auto. Unfortunately, this often results in pts underflows in recorded programs, some of them are larger. (by the way: QSF doesn't solve this problems) So far I have always set the ts muxrate to manual in the defined output profile and set a sufficiently high value (e.g 23000). With manually sets underflows usually only occur when something is wrong in the stream. The manual settings do not cause any problems with the playback devices.
Is it possible to transfer the improvements with the edited ts-streams to manual or atsc muxrate as well? That would be a big improvement (and it was also the case a long time ago in VRD5), because unfortunately the automatic ts muxrate often doesn't work really well. If I use match source profile, the engine uses atsc with no underflows, but jumps in VLC have video delays up to 3-4 seconds and the vid playback after jumps often begins with pixelation (improvement not working because mux rate isn't auto).
I have another question: could it be possible that "remove filler NALs" isn't working any more?
FYI PTS Underflow errors don’t really mean anything to the average user playing the file on a local PC or streamer. That PTS underflow error is not actually removing any data. It's simply warning you that at some point in the file the bitrate spiked above the muxrate. But unless you're in the broadcasting industry the muxrate doesn't matter and your file should still play just fine.
Thanks for the info...
But might it be possible to the transfer the improvements with playback of edited ts-streams on VLC (and other devices too) to manual or atsc muxrate as well? If you use "match source" for example, mostly atsc muxrate is used and then you will have the clumsy playback if you jump in the file with VLC (and some other devices), because the improvements only work with auto muxrate.
The another question: could it be possible that "remove filler NALs" isn't working any more?
I'm not sure why VLC has an issue with manual muxrates but not auto. All "auto" does is sample the file in a few locations and then sets the muxrate to the highest value it finds. The actual muxing process is identical to "manual". (ATSC does set a few extra variables)
As for "remove filler NALs".... that's an H.264 encoding option and will only apply if you're doing a full recode of the video. There is no way for us to remove any NALs from an already encoded stream. It also has nothing to do with TS and applies to all H.264 encoding.
many thanks for the reply and the information.
Something was changed in version 820a to improve video playback on VLC: TVSuite V6 - 22.214.171.1240 ( Released 2020-08-20)
[Change] Transport stream output: If TS mux rate set to auto and null packets are omitted (default for TVSuite), mux plays better in VLC.
This change works well for playback on VLC (and some other devices) and especially jumps don't have those video delays (3-4 sec) like before. But this only works if you set ts mux rate to auto. My question is if it possible to implement the changes you made for auto also for manual or atsc. For example atsc is mostly used if I use the profile "match source" and then the delays on VLC (and some other devices) are back, same if I use manual.
Just for info: sometimes I have to use manual, if there are bigger underflows that do sometimes cause problems with audio synchronisation on my dreambox (I don't know why).
I didn’t even realize that change existed. It's something DanR worked on outside my knowledg. So apparently he did make some change to differentiate auto from manual. I didn’t realize, sorry. DanR is the resident TS expert here, so he knows a lot more about the nitty gritty details of the format than I do. He must have figured out some optimization for auto beyond how it use to work.
Also I think you were might have been talking about null packets, not filler NALs, in your previous post. They're two different things so that theew me a bit.
- clumsy jumps in VLC and some other devices, if not using auto muxrate (to avoid PTS underflows)
- match source uses wrong muxrate (atsc instead of higher values in the original, e.g. 25000) and produces same clumsy jumps in VLC and some other devices - remove filler NALs seems not to work anymore (edit: this was my fault, the edited vids had no filler NALs)
We have no open issues on this since we addressed the issue in the 820 build. ATSC simply sets the mux rate to 19.2 Mbps. Do you want to upload a source video and output profile to us? In the email you send to support tell us how to duplicate and what to look for.
thanks for the information. Please excuse the late reply, but I've only made a few attempts to record a suitable and short video. The email with a detailed description of the problem and how to duplicate is sent to support and I also made a successful upload with the source file. Ticket id and folder: JSH-95754-239.
I just made some tests with the new beta 835b and an old problem with ts-files is back.
Actually there is again a playback delay in VLC player if you jump to another point in the video if the muxrate is set to manual. Jumps in VLC have video delays up to 3-4 seconds before the playback begins and the vid playback after jumps often begins with pixelation.
If the muxrate is set to auto or atsc, there is no noticeble delay if you jump to another point in the video.
Maybe something got wrong in the muxmodule with the last changes, because the previous beta doesn't have this problem. TS-files created with the previous beta versions play fine in VLC, no matter if the muxrate is auto, manual or atsc.
I will try out, if auto works better now. If I get in trouble with pts underflows with the actual version (so that I have to use manual) I would report again. Jumps in VLC player (and my mediaplayer in a satellite receiver) are very clumsy if it was muxed with manual bitrate...
Question: Isn't it possible to make the muxer behave the same way on manual as on auto or atsc (in my eyes it seems to be "just" another bitrate)? With the last versions it also worked well. It would be very nice if it would be possible.
Hi Frank, Please try auto or atsc (both do the same thing now). There were other issues with manual bit rate when the source video had a lot of VBR content. The new auto/atsc fixes the VBR issues and lets the manual bit rate work as it should.