File size of transportstreams VRD5 - VRD4

Winnewup

Member
During the tests concerning the Batch Manager (h264 transportstream, just cuts, no recoding of the hole file), I noticed that the output files from VRD4 and VRD5 have significant differences in the file size. I made some more tests and I think the settings in VRD4 and VRD5 are the same.
Test omit null packets no / one audio VRD4.ts3.144.267.664 Bytes
Test omit null packets no / one Audio VRD5.ts3.144.267.852 Bytes
Test omit null packets yes / all audio VRD4.ts1.855.815.116 Bytes
Test omit null packets yes / all Audio VRD5.ts2.271.683.712 Bytes
Test omit null packets yes / one audio VRD4.ts1.773.538.608 Bytes
Test omit null packets yes / one Audio VRD5.ts2.189.321.288 Bytes

There is nearly no difference between VRD4 and VRD5 if the output vid contains null packets.
But if these null packets should be removed, the output file of VRD5 is bigger than the file made with VRD4. I tried with one and all audio streams, but the difference between one and all is nearly the same in VRD4 and VRD5. The subtitle streams are both in VRD4 and VRD5 results.
Does VRD5 leave some null packets in the stream so that it might be more compatible to video players? Or is there another option I didn't find yet?

Is it right that I can't remove the subtitle streams? You will find the video information of the source file in the attachment.

It would be nice if someone could help me.
 

Attachments

Last edited:

Danr

Administrator
Staff member
Do you have a lot of cuts or did you save the entire file? Are you saving the entire file, any edits, full or intelligent recode?

Open both the V4 and V5 output files, the ones with omit null packets, and see if there's any difference in the Tools>Show Program Info. (BTW, when posting program info, use the copy button on that screen and paste the text output into a reply).

Also, check the options on the T>O>H.264 page between the two versions. In V5 there's a setting remove "SEI NALs". In V4, there's a similar option, "Remove Filler NALs".

The best test is to save as elementary streams and compare the file sizes especially the video output. That will indicate is it's a muxing issue or an elementary stream issue.
 
Last edited:

Winnewup

Member
I have only two cuts (begin and end). The first cut is an I-Frame. I use intelligent recode and only the last few frames at the end are recoded (logfile). The speed is high and nearly the same and you can see, that there is nearly no recoding (most is fast frame copy; just the end is recoded).

Output-info of file processed with VRD4:
File: Name : F:\Test omit null packets yes one audio VRD4.ts
Size : 1.774 GB
Duration : 00:21:49.49
Mux type : TS Stream
TS mux rate : 19.235 Mbps
Video: Encoding : H.264
VideoStreamID : x14E7
Frame rate : 50.00 fps
Encoding size : 1280 x 720
Aspect ratio : 16:9
Header bit rate : 20.000 Mbps
VBV buffer : 380 KBytes
Profile : High/4.0
Progressive : Progressive
Chroma : 4:2:0
Entropy mode : CABAC
Bit rate : 9.975 Mbps
Audio Stream: 1 (Primary) Codec : AC3
Format : AC3 stream
Channels : 2.0
Language : deu
PID : x14EC
PES Stream Id : xBD
Bit rate : 448 Kbps
Sampling rate : 48000
Sample size : 16 bits
Subtitle: 1-1 Type : DVB Teletext
PID : 0x14EA
Language : ger
Page : 100
Subtitle: 2-1 Type : DVB Subpic
PID : 0x14EB
Language : deu
Page : 1

Output-info of file processed with VRD5:
File: Name : F:\Test omit null packets yes one Audio VRD5.ts
Size : 2.189 GB
Duration : 00:21:49.49
Mux type : TS Stream
TS mux rate : 19.241 Mbps
Video: Encoding : H.264
VideoStreamID : x14E7
Frame rate : 50.00 fps
Encoding size : 1280 x 720
Aspect ratio : 16:9
Header bit rate : 20.000 Mbps
VBV buffer : 380 KBytes
Profile : High/4.0
Progressive : Progressive
Chroma : 4:2:0
Entropy mode : CABAC
Bit rate : 12.415 Mbps
Audio Stream: 1 (Primary) Codec : AC3
Format : AC3 stream
Channels : 2.0
Language : deu
PID : x14EC
PES Stream Id : xBD
Bit rate : 448 Kbps
Sampling rate : 48000
Sample size : 16 bits
Subtitle: 1-1 Type : DVB Teletext
PID : 0x14ED
Language : ger
Page : 100
Subtitle: 2-1 Type : DVB Subpic
PID : 0x14EE
Language : deu
Page : 1

To compare the video bit rate:
Original: 12.229 Mbps
Cut with null packets VRD5: 18.018 Mbps

The only difference I see is the video bitrate; if I use a calculator this might be the reason for the filesize. But I don't know why the bitrate is higher. The options I see are the same (including the options you discribed above). Output Settings specially for transport streams in the advanced section seem to be o.k. (see attachment; rest of the options is unchecked).
advanced options.jpg
I saved as elementary streams and the difference is between the video files:
VRD4: 1.601.444.429 Bytes
VRD5: 2.009.138.077 Bytes
 
Last edited:

Dan203

Senior Developer
Staff member
Without making any edits at all save the original file to elementary streams. Is there any difference in size between v4 and v5?
 

Danr

Administrator
Staff member
Did you check: "Also, check the options on the T>O>H.264 page between the two versions. In V5 there's a setting remove "SEI NALs". In V4, there's a similar option, "Remove Filler NALs".?
 

Winnewup

Member
I checked the options in T\O\H.264. SEI NALs/Filler NALs should be removed in both versions.

I made some more tests with these options checked and unchecked (shown as "(2)" in the filename). I just saved the original file to elementary streams without any cuts.

In the third test (filename with "(3)"), the option in the output advanced section "remove filler NALs" (VRD5)/Null-packets weglassen" (VRD4/ts-options, only in german Version!) is false/unchecked. These options have been true/checked in the tests before.

The audio file sizes are the same, so I only show them once at the beginning.
Test.ts4.578.469.844 Bytes
Test_VRD4_1.mpa64.760.256 Bytes
Test_VRD4_2.ac3151.105.024 Bytes
Test_VRD4_3.mpa64.760.256 Bytes
Test_VRD4.h2642.987.403.939 Bytes
Test_VRD5.h2644.000.188.619 Bytes
Test_VRD4 (2).h2644.001.331.307 Bytes
Test_VRD5 (2).h2644.001.416.786 Bytes
Test_VRD4 (3).h2646.476.235.656 Bytes
Test_VRD5 (3).h2644.001.416.786 Bytes
 
Last edited:

Dan203

Senior Developer
Staff member
The "Remove all SEI NALs" option in v5 is NOT the same thing as the "Remove filler NALs" option in v4. It's for a completely different issue and should be left unchecked in most cases. The "Remove filler NALs" option has been moved into the profiles in v5. When saving click Options, then Advanced, then expand the H.264 Stream Options section and you will see the "Remove filler NALs" option.

If you want to make this a permanent change you can edit the profile(s) you use most often in Tools->Edit profiles list and set that option to always be on so you don't have to do it each time you save.
 

Dan203

Senior Developer
Staff member
Oops we just discovered a bug. That profile option is not wired in correctly so it doesn't actually work. We'll fix it in the next beta
 

Danr

Administrator
Staff member
@Winnewup, if you email me at support AT videoredo.com and mention topic=35155, I would like to send you an alpha version with the fix to test. Don't have a file that handy that has the filler data.
 

hvda

New member
The "Remove all SEI NALs" option in v5 is NOT the same thing as the "Remove filler NALs" option in v4. It's for a completely different issue and should be left unchecked in most cases. ...
About EIS : I searched the internet to find some more information on EIS (Supplemental enhancement information) messages in a transport stream, but I couldn't figure out in which circumstances it might be useful/(recommended ?) to delete these EIS packets (eg: I found information in Annex D of document INTERNATIONAL STANDARD ISO/IEC 14496-10, but no practical examples).

To give us some more insight in the use of this VRD 5 option : can you give one or two concrete cases where the "Remove all SEI NALs" option could/should be used ?
 

Danr

Administrator
Staff member
SEI is used to store information that is not related directly to decoding the video. For example in North American it's sometimes used to store captions. It's also used to store frame display timing information and telecine playback. In some cases, they have been used to store filler although that's not the recommended method. The X.264 encoder uses SEI to store a copy of it's encoding parameters. I don't remember the exact reason, but a user had an issue playing back files that had certain SEI tracks so we added this feature to remove them all.

Unless you have a specific issue, I would not recommend enabling this option.

This is NOT the same as the remove filler NALs which where an H264 option in V4 and have now been moved to an output profile setting.
 
Top Bottom