mp4 like Adobe premiere result

[emcodem]

OK great, thanks for testing this.
So to come forward we need to further simplify the whole thing to an absolute minimum.
I noticed for example that my file version does not have an audio descriptor "English" set while the working one has.
For future experiments, i would like to work without audio, is that possible? Can you please test if the working file version (and please take exactly the uploaded ts file) also works when you remove the audios by rewrapping?

Also we have some noticeable differences in the h264 syntax between the streams, e.g. the working one has aspect ratio info stored, the non working does not have. We will try to find out if/how we can force ffmpeg to generate the same syntax as the adobe file.
If you have more working examples than adobe (which i believe also uses mainconcept for encoding), please share them if possible.

[Wahyu]

OK great, thanks for testing this.
So to come forward we need to further simplify the whole thing to an absolute minimum.
I noticed for example that my file version does not have an audio descriptor "English" set while the working one has.
For future experiments, i would like to work without audio, is that possible? Can you please test if the working file version (and please take exactly the uploaded ts file) also works when you remove the audios by rewrapping?

I tested the .ts file with no audio and the playout can still run even without audio. maybe we can try without audio.

Also we have some noticeable differences in the h264 syntax between the streams, e.g. the working one has aspect ratio info stored, the non working does not have. We will try to find out if/how we can force ffmpeg to generate the same syntax as the adobe file.
If you have more working examples than adobe (which i believe also uses mainconcept for encoding), please share them if possible.

i have sample from them and used mainconcept https://www.dropbox.com/s/og6zvm77rnfue ... S.mpg?dl=0

[emcodem]

thanks, thats great info.

OK, so i spent most of the day with analyzing and playing around, trying to align the h264 metadata analysis of your working files with some ffmpeg output. I used ffmpeg bistream filters to do this. Unfortunately, after the bitstream filter, all the "stuffing bytes" get lost, thus the filesize is minimal.
The reason for the minimal file size is of course that we use a static image "colorbars" as source file and h264 is a pretty smart encoder.

Please can you first try if your working file still plays after removing all the stuffing:

The commandline for this was:

Code: Select all

ffmpeg -i C:\temp\working.mpg -c:v copy -bsf:v filter_units=pass_types=1-5 -an c:\temp\working_nal_removed.mp4

ffastrans.com/share (samples->h264_qsv) working_nal_removed.ts

If this file plays, we know that the "fillers" which consist of either 0 or FF bytes (95% of the content from our other files consisted of fillers only and there was 4.5% audio.), do not play a role and you can continue with the following example.

ffastrans.com/share (samples->h264_qsv) bsf.ts

The next file is as mentioned, a humble try to align the h264 header entries with the ones from a working file. If the working_nal_removed.ts works, please download this file and also try it (otherwise no need to try it, in that case we NEED stuffing bytes)

The commandline used to produce this file was (i use still quicksync encoding because of the interlacing):

Code: Select all

ffmpeg -f lavfi -i smptebars=duration=10:size=1920x1080:rate=50 -f lavfi -i "sine=frequency=1000:duration=10" -map 0 -map 1 -map 1 -ac 2 -c:a libtwolame -ar 48000 -flags:v +ildct -top 1 -dpb_size 4 -profile:v high -level:v 41 -vsync:v cfr -pix_fmt yuv420p -g 25 -cbr true -r 25 -brand mp42 -async 1 -c:v h264_qsv -b:v 20M -minrate 20M -maxrate 20M -refs 4 -muxrate 20M -f matroska -| ffmpeg -i - -codec copy -map 0:0  -bsf h264_metadata=colour_primaries=1,h264_metadata=colour_primaries=1,h264_metadata=transfer_characteristics=1,h264_metadata=matrix_coefficients=1,h264_metadata=video_format=5 -minrate 20M c:\temp\bsf.ts -y

Additional info: for analyzing and comparing the h264 metadata, i use this command:

Code: Select all

ffmpeg -i c:\temp\bsf.ts -an -bsf trace_headers -codec copy -f null -

Of course once for a working file and once for my own version, then compare the output. Currently i just compare the entries in "Sequence Parameter Set"

[Wahyu]

thanks, thats great info.
...

I've tried the sample you shared and the playout still doesn't work. i tested h264_qsv, pix_fmt yuv420p not compatible then auto-selecting format to nv12.

[emcodem]

Yeah no worries about the nv12 stuff, qsv will still produce yuv420 in the end.
But there is a little confusion now about which sample you tested as the first file "working_nal_removed.ts" is your working original with fillers removed instead of some qsv encoded. Did you try this and it failed as well?

[Wahyu]

Yeah no worries about the nv12 stuff, qsv will still produce yuv420 in the end.
But there is a little confusion now about which sample you tested as the first file "working_nal_removed.ts" is your working original with fillers removed instead of some qsv encoded. Did you try this and it failed as well?

yes, failed as well.
basically what is needed here is an mp4 file. although playout requires a ts file, that's why I added Custom FFmpeg behind. I focus on the results of the mp4 because the source video uses mpg (mpeg-ps). some of the codecs I've used and the closest one is h264_nvenc or h262_qsv, but these don't work either.

[emcodem]

OK thats good to know. With this information, i believe i got one step further because there seems to be a huge difference in how qsv encoder wrote the "stuffing packets" and how your working examples did it. Maybe this is exactly the difference i have been looking for - but it will take some time for me to engineer around it.

What could really,really help here if we also had a chance to try to make progressive files work. I have a feeling that even progressive files e.g. 50p from ffmpeg will not work on your playout but the ones from mainconcept will work. If this is the case, our experiments to find out what exactly in the bitstream is disturbing the playout would be a lot more easy because we could work with x264 which allows us to set a lot more params.

basically what is needed here is an mp4 file. although playout requires a ts file, that's why I added Custom FFmpeg behind. I focus on the results of the mp4 because the source video uses mpg (mpeg-ps). some of the codecs I've used and the closest one is h264_nvenc or h262_qsv, but these don't work either.

Unfortunately i don't see where you come from, there is no relation between the container that you produce and the container of the original source file. Also i don't understand what you do with an mp4 file when the goal is to make the .ts file work on the playout.
Anyway, there is no problem for you to just change containers as you like, i could upload it as .mkv and you rewrap it to .mp4 or .ts, it would not matter at all for the final result as we currently only concentrate on the h264 part.

[Wahyu]

What could really,really help here if we also had a chance to try to make progressive files work. I have a feeling that even progressive files e.g. 50p from ffmpeg will not work on your playout but the ones from mainconcept will work. If this is the case, our experiments to find out what exactly in the bitstream is disturbing the playout would be a lot more easy because we could work with x264 which allows us to set a lot more params.

my system is on 1080/50i, it might not hurt to try 50p. I want to ask, which file do you use to be "working_nal_removed.ts" ?

Unfortunately i don't see where you come from, there is no relation between the container that you produce and the container of the original source file. Also i don't understand what you do with an mp4 file when the goal is to make the .ts file work on the playout.
Anyway, there is no problem for you to just change containers as you like, i could upload it as .mkv and you rewrap it to .mp4 or .ts, it would not matter at all for the final result as we currently only concentrate on the h264 part.

Sorry to confuse you, the final result is a TS file with mp4(h264) with mp2 audio. The video is sourced from IRD Satellite (DVB-S2) mp4 with mp2 audio (stream output), then I thought to make mp4(h264) like the output from IRD before entering the playout.
starting from here I started, I was given a sample by Vigor in the form of a TS file and then how to make this with FFAStran and ffmpeg. maybe by breaking it down before it becomes TS it will be easier to find, and I started thinking about making mp4(h264) first and then turning it into TS.
until finally what is currently happening, the results of the premiere mp4 (h264) that are used as TS can actually be run by playout other than using MainConcept.

[FranceBB]

Well MP4 is just a container, in the end it doesn't matter if you encode the H.264 stream as raw_video.h264 and then mux to .ts and send it to the playout or if you go to .mp4 and then remux to .ts. Still, I'm now curious to see if the progressive file works 'cause this way we wouldn't have the added nag of TFF and the added question mark around interlacing and MBAFF etc.

By the way emcodem is doing an outstanding job and he's keeping us all updated in our internal chat.
I've seen what he's talking about and it's definitely weird.
I mean, we're essentially using color bars as an example, which means that they're static and synthetic so motion compensation works like a charm when it detects motion vectors and therefore saves lots of bits.
Now, since the playout requires CBR and we're sending CBR, encoders have to occupy all the bitrate available anyway even if they don't need it, therefore they do something called "zero-fill".
In the Intel Quicksync encoder, the zero fill is quite literal in the sense that I can definitely see zeroes that are there just to occupy the bitrate, but in the Premiere one... well... no.
Emcodem showed me a bunch of repeated "Y" which I have no idea what they're, but it's pretty clear that they're there only to fill the bitrate and get CBR. The problem is: how can we recreate this?

The good thing is that you're in good hands 'cause if there's someone that can work on this, that is emcodem.

[emcodem]

my system is on 1080/50i, it might not hurt to try 50p. I want to ask, which file do you use to be "working_nal_removed.ts" ?

It is very good that you ask this, we need to be absolutely precise here. The working_nal_removed.ts is this file from you (but i removed all "filler bytes" using a ffmpeg bitstream filter as shown above):
https://www.dropbox.com/s/tfs1zowkjunn5 ... S.mpg?dl=0
TESTBARS-TS.mpg

Also, please just try to export some 50p from adobe and test on playout. If it works, please upload the file, it will be VERY useful for us to also make your interlaced files work.

Sorry to confuse you, the final result is a TS file with mp4(h264) with mp2 audio. The video is sourced from IRD Satellite (DVB-S2) mp4 with mp2 audio (stream output), then I thought to make mp4(h264) like the output from IRD before entering the playout.
starting from here I started, I was given a sample by Vigor in the form of a TS file and then how to make this with FFAStran and ffmpeg. maybe by breaking it down before it becomes TS it will be easier to find, and I started thinking about making mp4(h264) first and then turning it into TS.
until finally what is currently happening, the results of the premiere mp4 (h264) that are used as TS can actually be run by playout other than using MainConcept.

Sorry but it is still a little bit confusing for us (see FranceBB's message above).

Is it like this? If not, can you come up with a similar list from your perspective?

premiere export h264+mp2 in mpeg2ts directly (no ffmpeg ) -> playout works
mainconcept export h264+mp2 in mp4 -> rewrap to .ts using ffmpeg -> playout works

mainconcept export ts+mp2 directly (no ffmpeg ) -> playout fail
mainconcept export ts+mp2 -> rewrap to .ts using ffmpeg -> playout works