Undersized result after H.264-TS -> MKV or MP4

[MarcN]

Hello!

I have recently recorded a movie from digital HDTV. The format is .ts and the size is about 11.3 GB. It contains a h264 video stream at 50fps (720p50) plus Audio (AC3 and MP2). After demuxing the streams with the latest DGAVCIndex I wanted to put them into a mkv-container using mkvmerge GUI. The resulting mkv-file however is only half the size of the raw h264-stream, about 6.5 GB. The mkv-file plays fine and there seems to be no loss of picture quality. Using mp4muxer to put the streams into a mp4-container produces an equally small filesize.

My guess is that there is something wrong with the original ts-file. The bitrate is virtually constant at 12MBit/s, unusual for the channel. Could it be, that the ts-stream and demuxed h264-stream contain lots of useless information that is just disregarded by mkvmerge and mp4muxer? And if so, is there a way to proof that?

Thanks a lot.

[crypto]

Does the .ts file play ok in the second half?

[Oleg Rode]

What is about to demux with the tsMuxeR?

[Comatose]

Well, .ts files have (or can have?) redundancy information, and they can also have padding. That might be it.

[MarcN]

@crypto: Yes the .ts-file plays fine all the way through

@Oleg Rode: No change from the DGAVCIndex result

In the meantime I searched for a H.264-Stream analyzer and found h264_parse. It produces a lot of entries like this:

Nal length 17433 start code 4 bytes
ref 0 type 12 filler data

filler data = useless information? And are the .ts-file and h.264-stream therefor just unnecessarily bloated up?

Thanks a lot guys,
Marc

[crypto]

It could also be that the recording program includes unnecessary PIDs in the .ts stream, maybe even another program or a SD subchannel, additional audio tracks, or teletext streams. Some program even allow to record the full mux. You need to run the .ts stream thru an analyzer or a program that lists the PIDs to be sure.

[MarcN]

I checked the ts-file with ProjectX and other tools, there are no other PIDs in the stream. I guess I should have made it clearer that the demuxed h.264 stream is also about 11 GB in size. But after muxing it and the audio back into a mkv-file the size shrinks to 6.5 GB.

I have now extracted all the NAL-entries from the h264_parse scan that say 'filler data' and added up there sizes: 4.984.593.818

Thats practically the size that I lose by muxing the streams to mkv.

[crypto]

Ah, that explains it. This is an interesting observation since filling doesn't happen the null PID, but is contained in the video PID. I know at least one case where the video bitrate is measured by counting up the video PID pakets. So as we see now this can lead to faulty results. May I ask which channel and perhaps what encoder is involved?

[MarcN]

The channel is ORF HD (Austrian Television). As for the encoder, I have no idea.