I saved a webcast transport stream last weekend, and in editing it, I've found what I think I would describe as a compatibility problem that exists with TV Suite 6 and my usual video PC video players (principally VLC). The issue does not arise with TV Suite V5.
The source webcast stream is slightly unusual in that it is 50fps, but each frame is displayed twice, so there are only 25 different frames per second. However, I observed a similar issue with a HD DVB-S broadcast a few weeks ago, in rather different circumstances.
Circumstances of issue with webcast :
* The source webcast contains a glitch where the video freezes for 1 second and 48 frames. I attempted to eliminate this glitch by trimming exactly the frozen frames; no more and no less. The output was set to not re-encode - using the "Matroska MKV" output profile - except of course it will have done so around the edit point; and symptoms were the same regardless of whether I output to .ts, mkv, or mp4.
* When I used TV Suite V6 (6.62.6.833 / 2021-09-22) under Windows 10, and play back the output using (an old version of) Splash Lite or VLC (current version), also under Windows 10, the image goes black twice, for around 1/5th of a second on each occasion; once prior to the edit point and once after it. This is the compatibility issue / problem that concerns me. The PCs that exhibiting this behaviour are Windows 10 machines with built-in graphics. They are by no means brand spanking new or cutting edge, but they are capable of comfortably playing back HD video in normal circumstances, without any problems.
* In VLC's "Tools" / "Media Information" / "Statistics" tabs, VLC does report a large number of "Lost" video frames that correspond to the section between the bursts of black frames (and not just the black frames themselves).
* On a Debian PC, VLC freezes the video momentarily at similar spots to the Windows PC black frames, and reports a similar number of "Lost" video frames
* I tested TV Suite V6 Beta (6.63.7.836 / 2022-03-23) and the output had the same issue.
* However, other playback solutions are not showing any problem :
** Newer version of Splash Lite does not show any problems.
** NVidia Shield TV playback via PLEX is perfect
** Debian PC playback using the default media player does not show any problems.
** Android phone playback via PLEX is perfect; I even Chromecast'ed this source to a TV without problems.
** When I open the output file in TV Suite, and move through it frame by frame, TV Suite does not see any of the frames as being blank / black.
There is one reasonable conclusion from the above, which is that either my PCs (which are the same HP Desktop model) are at fault, or VLC is at fault. However ...
* When I used TV Suite V5 (5.4.84.771 / 2018-09-24) on the same PC, the output plays back fine in VLC (and Splash Lite) where previously it did not.
Circumstances of issue with DVB-S broadcast :
* This was a UK Channel 4 HD broadcast 2 or 3 weeks ago from which I edited out commercial breaks using TV Suite V6. I put markers on I-Frames; I think that they were in fact marked IDR, but I can't be certain, and I no longer have the source .ts file. (So 1080i 25fps).
* When I played back the output file there was flickering similar to described above, with at least two instances of black frames being shown around the edit point.
* Since I wasn't happy with the black frames / flickering, I altered the edits to be at points other than the I-Frames, and this time the output was fine.
* I didn't think much more of it, except that I was sure that I hadn't noticed it before, and I was suprised that it was happening when I marked the I-Frames for edit points, since I've previously found this to be the easiest / most convenient / laziest way to edit, and my understanding is that TV Suite has less work to do (and no re-encoding) when cutting from I-Frame to I-Frame.
* I am fairly certain that this was an exceptional case. I like to think that I would have spotted it before if it were endemic, and I often replay edit points to verify that everything went OK, before deleting source files. However, I don't often have the luxury to choose I-Frames, so this may be common behaviour that I hadn't spotted before.
I would really like to have this working with VLC on my Windows PCs. I don't have any other Windows installations that I can test with, in particular, none with more advanced graphics. I imagine that the V6 output is theoretically good & proper, and perhaps my software is not entirely up the task of playing something that is theoretcially good & proper, but that V5 was doing something better / tidier / more efficiently / more considerate of players, and whatever that difference is could be identified.
I have prepared :
* A 26 second / 18MB file for the input .ts data
* The TV Suite V6 .Vprj project file that I used to trim the section with frozen video, so that others can replicate my edit.
* The 25 second output (16MB) created by TV Suite V6, which exhibits some problems for me
* The 25 second output (16MB - in fact 300kB bigger than the V6 output) created by TV Suite V5, which plays back fine for me in all cases
* Footage taken with my phone camera, showing the glitchy VLC playback
* A text file with an explanation of each file listed above
I've uploaded this collection of files - 67MB zipped - here : https://mega.nz/file/0VoShSQI#oAtEB2r3vIN52VT1GXGcs2u3rW671ubRuPNRuxIUR4w
Happy to try to provide any other information if requested.
The source webcast stream is slightly unusual in that it is 50fps, but each frame is displayed twice, so there are only 25 different frames per second. However, I observed a similar issue with a HD DVB-S broadcast a few weeks ago, in rather different circumstances.
Circumstances of issue with webcast :
* The source webcast contains a glitch where the video freezes for 1 second and 48 frames. I attempted to eliminate this glitch by trimming exactly the frozen frames; no more and no less. The output was set to not re-encode - using the "Matroska MKV" output profile - except of course it will have done so around the edit point; and symptoms were the same regardless of whether I output to .ts, mkv, or mp4.
* When I used TV Suite V6 (6.62.6.833 / 2021-09-22) under Windows 10, and play back the output using (an old version of) Splash Lite or VLC (current version), also under Windows 10, the image goes black twice, for around 1/5th of a second on each occasion; once prior to the edit point and once after it. This is the compatibility issue / problem that concerns me. The PCs that exhibiting this behaviour are Windows 10 machines with built-in graphics. They are by no means brand spanking new or cutting edge, but they are capable of comfortably playing back HD video in normal circumstances, without any problems.
* In VLC's "Tools" / "Media Information" / "Statistics" tabs, VLC does report a large number of "Lost" video frames that correspond to the section between the bursts of black frames (and not just the black frames themselves).
* On a Debian PC, VLC freezes the video momentarily at similar spots to the Windows PC black frames, and reports a similar number of "Lost" video frames
* I tested TV Suite V6 Beta (6.63.7.836 / 2022-03-23) and the output had the same issue.
* However, other playback solutions are not showing any problem :
** Newer version of Splash Lite does not show any problems.
** NVidia Shield TV playback via PLEX is perfect
** Debian PC playback using the default media player does not show any problems.
** Android phone playback via PLEX is perfect; I even Chromecast'ed this source to a TV without problems.
** When I open the output file in TV Suite, and move through it frame by frame, TV Suite does not see any of the frames as being blank / black.
There is one reasonable conclusion from the above, which is that either my PCs (which are the same HP Desktop model) are at fault, or VLC is at fault. However ...
* When I used TV Suite V5 (5.4.84.771 / 2018-09-24) on the same PC, the output plays back fine in VLC (and Splash Lite) where previously it did not.
Circumstances of issue with DVB-S broadcast :
* This was a UK Channel 4 HD broadcast 2 or 3 weeks ago from which I edited out commercial breaks using TV Suite V6. I put markers on I-Frames; I think that they were in fact marked IDR, but I can't be certain, and I no longer have the source .ts file. (So 1080i 25fps).
* When I played back the output file there was flickering similar to described above, with at least two instances of black frames being shown around the edit point.
* Since I wasn't happy with the black frames / flickering, I altered the edits to be at points other than the I-Frames, and this time the output was fine.
* I didn't think much more of it, except that I was sure that I hadn't noticed it before, and I was suprised that it was happening when I marked the I-Frames for edit points, since I've previously found this to be the easiest / most convenient / laziest way to edit, and my understanding is that TV Suite has less work to do (and no re-encoding) when cutting from I-Frame to I-Frame.
* I am fairly certain that this was an exceptional case. I like to think that I would have spotted it before if it were endemic, and I often replay edit points to verify that everything went OK, before deleting source files. However, I don't often have the luxury to choose I-Frames, so this may be common behaviour that I hadn't spotted before.
I would really like to have this working with VLC on my Windows PCs. I don't have any other Windows installations that I can test with, in particular, none with more advanced graphics. I imagine that the V6 output is theoretically good & proper, and perhaps my software is not entirely up the task of playing something that is theoretcially good & proper, but that V5 was doing something better / tidier / more efficiently / more considerate of players, and whatever that difference is could be identified.
I have prepared :
* A 26 second / 18MB file for the input .ts data
* The TV Suite V6 .Vprj project file that I used to trim the section with frozen video, so that others can replicate my edit.
* The 25 second output (16MB) created by TV Suite V6, which exhibits some problems for me
* The 25 second output (16MB - in fact 300kB bigger than the V6 output) created by TV Suite V5, which plays back fine for me in all cases
* Footage taken with my phone camera, showing the glitchy VLC playback
* A text file with an explanation of each file listed above
I've uploaded this collection of files - 67MB zipped - here : https://mega.nz/file/0VoShSQI#oAtEB2r3vIN52VT1GXGcs2u3rW671ubRuPNRuxIUR4w
Happy to try to provide any other information if requested.
