VideoHelp Forum
+ Reply to Thread
Page 5 of 6
FirstFirst ... 3 4 5 6 LastLast
Results 121 to 150 of 165
Thread
  1. Originally Posted by drmpeg View Post
    I spent a few hours today testing some quality settings. Here's my new command line:
    Code:
    ffmpeg -i Terminator.m2ts -c:v mpeg2video -r 30/1.001 -b:v 22000000 -bufsize 9781248 -maxrate 23000000 -bf 2 -sc_threshold -30000 -seq_disp_ext 1 -color_primaries 1 -color_trc 1 -colorspace 1 -dc 10 -me_range 960 -inter_matrix 16,17,18,19,20,21,22,23,17,18,19,20,21,22,23,24,18,19,20,21,22,23,24,25,19,20,21,22,23,24,26,27,20,21,22,23,25,26,27,28,21,22,23,24,26,27,28,30,22,23,24,26,27,28,30,31,23,24,25,27,28,30,31,33 -acodec ac3 -muxrate 25000000 terminator.ts
    The Non_Intra_Quantiser_Matrix makes a big difference. This is the standard non-flat matrix that I came up with when I was working at C-Cube Microsystems back in 1994. I stole it from an MPEG-1 bitstream that was encoded with the Philips Video CD encoder.
    Just as I got a D-VHS machine and was looking for a way to do the same thing I was pointed to this thread via tapeheads. But my search for wisdom is a little bit more tricky. You see, the thing is, I have JVC HM-DR10000EU, and this is a PAL machine, it does not output data over fireqire and it does not support HD, only PAL SD. But I have no idea if it supports progressive scan 576p...

    So please help me Doctor, what ffmpeg commands should I use for the following three types of video:
    1. Standard PAL DV video 720x576 at 25fps.
    2. 4:3 HD formats: 4000x3000, 1944x1458, 1440x1080, 960x720 at 25fps to convert to 720x540 and to populate the remaining 36 lines with black bars.
    3. Widescreen HD, FHD and UHD to convert to anamorphic 720x540 (values are respectively 50/9, 27/10, 2, 3/4 times smaller than resulutions in ad.2) and to populate the remaining 36 lines with black bars.

    In order to get D-VHS compliant stream to record via DVHSTool onto PAL D-VHS. If my machine supports progressive PAL then to output ad.2 and ad.3 to progressive, if my machine does not support progressive then to output ad.2 and ad.3 to progressive segmented frame, so preserve the image, but to make the machine think it's interlaced. Interlaced materials must be deinterlaced when downscaled either way.
    Quote Quote  
  2. Originally Posted by SF01 View Post

    2. 4:3 HD formats: 4000x3000, 1944x1458, 1440x1080, 960x720 at 25fps to convert to 720x540 and to populate the remaining 36 lines with black bars.
    3. Widescreen HD, FHD and UHD to convert to anamorphic 720x540 (values are respectively 50/9, 27/10, 2, 3/4 times smaller than resulutions in ad.2) and to populate the remaining 36 lines with black bars.
    Why this strange requirements? 720x540 with 36 black bar, not sure even if it is valid from MPEG-2 perspective (very limited DAR choices).
    Quote Quote  
  3. Originally Posted by pandy View Post
    Originally Posted by SF01 View Post

    2. 4:3 HD formats: 4000x3000, 1944x1458, 1440x1080, 960x720 at 25fps to convert to 720x540 and to populate the remaining 36 lines with black bars.
    3. Widescreen HD, FHD and UHD to convert to anamorphic 720x540 (values are respectively 50/9, 27/10, 2, 3/4 times smaller than resulutions in ad.2) and to populate the remaining 36 lines with black bars.
    Why this strange requirements? 720x540 with 36 black bar, not sure even if it is valid from MPEG-2 perspective (very limited DAR choices).
    720x540 is the scaled image from 1440x1080 by factor of 2 and PAL resolution is 720x576, so the remaining 36 lines need to be occupied by black to achieve 576 lines.
    Quote Quote  
  4. Originally Posted by SF01 View Post
    720x540 is the scaled image from 1440x1080 by factor of 2 and PAL resolution is 720x576, so the remaining 36 lines need to be occupied by black to achieve 576 lines.
    1440x1080 4:3 or 16:9?
    Quote Quote  
  5. 1440x1080 already anamorphic widescreen converted from full raster FHD.
    So first step is anamorphic conversion from for example 1920x1080 to 1440x1080 (like HDV), then to PAL SD.
    Quote Quote  
  6. Originally Posted by SF01 View Post
    1440x1080 already anamorphic widescreen converted from full raster FHD.
    So first step is anamorphic conversion from for example 1920x1080 to 1440x1080 (like HDV), then to PAL SD.
    There is rare 4:3 1440x1080 content at first, secondly then if 1440x1080 is anamorphic already then you should convert it to 720x576 and mark as intended to be displayed on 16:9 display. There is no difference between 1920x1080 and anamorphic 1440x1080 in term of aspect.
    Quote Quote  
  7. Originally Posted by SF01 View Post
    720x540 is the scaled image from 1440x1080 by factor of 2 and PAL resolution is 720x576, so the remaining 36 lines need to be occupied by black to achieve 576 lines.
    No. Go right to 720x576 with no black bars. If the source is really 1920x1080, then encode that 720x576 video as 16:9 in your MPEG-2 encoder.

    So first step is anamorphic conversion from for example 1920x1080 to 1440x1080 (like HDV), then to PAL SD.
    No, again. pandy is correct. And why the multiple resizes? Unless done losslessly, at each generation the video is further degraded. Simply resize to 720x576 from 1920x1080. No black bars.

    Why did you hijack dellsam34's thread?
    Quote Quote  
  8. Originally Posted by manono View Post
    Originally Posted by SF01 View Post
    720x540 is the scaled image from 1440x1080 by factor of 2 and PAL resolution is 720x576, so the remaining 36 lines need to be occupied by black to achieve 576 lines.
    No. Go right to 720x576 with no black bars. If the source is really 1920x1080, then encode that 720x576 video as 16:9 in your MPEG-2 encoder.

    So first step is anamorphic conversion from for example 1920x1080 to 1440x1080 (like HDV), then to PAL SD.
    No, again. pandy is correct. And why the multiple resizes? Unless done losslessly, at each generation the video is further degraded. Simply resize to 720x576 from 1920x1080. No black bars.

    Why did you hijack dellsam34's thread?
    OK, from the first point to poreserve the picture aspect ratio the resize would result in 720x540 image, so black bars at top and bottom are needed, or the picture will be vertically streched to 576.

    The resize from widescreen to anamorphic widescreen at 1080 is a virtual step, anamorphic compression must occur while downscaling 1920x1080 to 720x576.

    Because my inquiry of of the same nature to record to D-VHS, but with different parameters. Should I condense it and start new thread?
    Quote Quote  
  9. Originally Posted by SF01 View Post
    OK, from the first point to poreserve the picture aspect ratio the resize would result in 720x540 image, so black bars at top and bottom are needed, or the picture will be vertically streched to 576.
    Provide math as - remember that 1920 is frequently resized to 1440 to save bandwidth ((1440/1920)*74.25MHz)/2=27.8MHz - still decent Y bandwidth.
    In decoding process it is resized back to 1920 so resizing from 1920(1440)x1080 to 720x576 will keep correct aspect ratio (same as for 1920x1080).

    Originally Posted by SF01 View Post
    The resize from widescreen to anamorphic widescreen at 1080 is a virtual step, anamorphic compression must occur while downscaling 1920x1080 to 720x576.
    If you decide to pad video with 36 black lines then your horizontal resolution should be like (540*16)/9=960 not 1024 (576*16)/9=1024.

    You can reuse previous script https://forum.videohelp.com/threads/391572-M2TS-to-MPEG-2-1080i/page2#post2538708 (can't provide newer as i observe regression in quality when i'm trying new options).

    Some easy changes are required to satisfy your video processing requirements (IMHO incorrect):
    Code:
    @set vproc="pp=ac,scale=720:540:sws_flags=spline+accurate_rnd+full_chroma_int+full_chroma_inp:sws_dither=0,pad=720:576:0:(oh-ih)/2,format=pix_fmts=yuv420p"
    For interlace and hard telecine video processing path is different.

    Another topic is framerate conversion, there is few options on table - same as in NTSC only framerate is not 30000:1001/60000:1001 but 25/50.
    And another topic is progressive vs interlace encoding, also MPEG-2 level question (if it is allowed to use HL to encode SD resolution for D-VHS or not? ML bitrate limit is 15Mbps max and for HL max limit is 80Mbps).
    Quote Quote  
  10. I still feel there is a communication breakdown.

    The video will be full 1024x576, the 540 and 36 black lines come from letterboximg the image of thevideo itself in the 720x576 container. Just like you would have widescreen video in letterbox format, but in this case the video will be resized to 720x540 and the remaining 36 rows of pixels will become the letterbox in 576 vertical resolution.

    The thing is the bitrate, for STD speed the bitrate of 14,1 MBps is used. And there is the question of audio, can LPCM be used and if not what can be and in what bitrate, perhaps AAC @384kbps stereo?
    Quote Quote  
  11. Originally Posted by SF01 View Post
    I still feel there is a communication breakdown.
    nope

    Originally Posted by SF01 View Post
    The video will be full 1024x576, the 540 and 36 black lines come from letterboximg the image of thevideo itself in the 720x576 container. Just like you would have widescreen video in letterbox format, but in this case the video will be resized to 720x540 and the remaining 36 rows of pixels will become the letterbox in 576 vertical resolution.
    1440x1080 is anamorphic 1920x1080 so to not distort original aspect you should reduce video proportionally in both direction - if you decided to have 540 lines video then or you reduce video to 675 pixels wide to prevent further aspect distortion or by keeping 720x540 (embedded to 720x576) you will get target with distorted aspect. Once again - above calculations are based on assumption that your source was 16/9 before anamorphic conversion to 1440x1080. This is simple 1920 to 1440 means aspect distortion as number of lines is same for both (so pixel aspect ratio is no longer 1:1 but instead it is 0.66:1) if you insist to reduce number of lines to 540 not 576 then you will distort pixel aspect not only in horizontal but also in vertical direction (540:576).


    Originally Posted by SF01 View Post
    The thing is the bitrate, for STD speed the bitrate of 14,1 MBps is used. And there is the question of audio, can LPCM be used and if not what can be and in what bitrate, perhaps AAC @384kbps stereo?
    Yes, for SD i.e. MP@ML maximum bitrate allowed is 15 Mbps however MP@HL allow up to 80Mbps and any MP@HL MPEG-2 decoder is capable to decode lower resolutions.
    IMHO AAC was not used in D-VHS times (but it will be nice if you can provide some manual for your deck) and LPCM may not offer significant benefits - i recommend to provide at least 1 AC-3 audio track as seem it is most worldwide compliant home cinema codec.
    Still valid is most important question about interlace and frame-rate conversion.
    If you are interested in MP@ML then i highly recommend to follow DVD encoding guides (perhaps with exception that maximum allowed bitrate is not 9.6Mbps but 14Mbps). HCEnc may offer some functionality not present in ffmpeg. I can imagine script using ffmpeg and HCEnc.
    Quote Quote  
  12. Well, my calculations were as follows:
    1920x1080 to 1440x1080 is a standard anamorphic compression. Then dividing both dimensions by 2, ie downscaling the frame into 1/4 of the area gives 1440/2=720 and 1080/2=540.
    1440x1080 is 4:3, 720x576 is not 4:3, but 720x540 is 4:3, so shrinking 1440x1080 to 720x540 should preserve everything and the resulting 720x540 frame is contained in 720x576 via letterbox. At least this is my reasoning. But I see the problematic point now. The expansion of 720x576 will not result in 960x540 that is 1/4 of 1920x1080, it will be stretched to 1024, which is too much. The thing is 720x576 is not 4:3 format, so it would be logical first to do downscaling of the video to 1024x576 and then do the anamorphic compression, without the "540" step. Which means the original widescreen video should be downscaled by a factor of 1/1,875 to 1024x576 and then compressed anamorphicaly into 720x576. Does it sound more realistic? Which should be the workflow for other 16:9 materials
    But the native 4:3 such as 1440x1080 still would be better if done the previous method, just scaled down to 720x540 and letterboxed.

    I guess I can uploadthe manual, but I don't know it it will help.

    Audio:
    Of course not AAC, my mistake, I was thinking about AC3 @384kbps, only if D-VHS does not support LPCM. LPCM is lossless, useful for concerts and I preffer my audio lossless. It's the issue of max allowed bitrate for audio.
    Quote Quote  
  13. Originally Posted by SF01 View Post
    Well, my calculations were as follows:
    1920x1080 to 1440x1080 is a standard anamorphic compression. Then dividing both dimensions by 2, ie downscaling the frame into 1/4 of the area gives 1440/2=720 and 1080/2=540.
    1440x1080 is 4:3, 720x576 is not 4:3, but 720x540 is 4:3, so shrinking 1440x1080 to 720x540 should preserve everything and the resulting 720x540 frame is contained in 720x576 via letterbox. At least this is my reasoning. But I see the problematic point now. The expansion of 720x576 will not result in 960x540 that is 1/4 of 1920x1080, it will be stretched to 1024, which is too much. The thing is 720x576 is not 4:3 format, so it would be logical first to do downscaling of the video to 1024x576 and then do the anamorphic compression, without the "540" step. Which means the original widescreen video should be downscaled by a factor of 1/1,875 to 1024x576 and then compressed anamorphicaly into 720x576. Does it sound more realistic? Which should be the workflow for other 16:9 materials
    But the native 4:3 such as 1440x1080 still would be better if done the previous method, just scaled down to 720x540 and letterboxed.
    Nope - display surface decide about aspect NOT absolute pixels and lines. There is no need for two step resize - just resize any 16:9 video to anamorphic 720x576 16:9 - decoder will restore video correctly unless your display aspect ratio is something less than 16:9.
    Also it is not clear to me what are connectivity possibilities for your D-VHS deck thuscan't advice more.

    Originally Posted by SF01 View Post
    I guess I can uploadthe manual, but I don't know it it will help.
    And that's why it will be nice to see specification


    Originally Posted by SF01 View Post
    Audio:
    Of course not AAC, my mistake, I was thinking about AC3 @384kbps, only if D-VHS does not support LPCM. LPCM is lossless, useful for concerts and I preffer my audio lossless. It's the issue of max allowed bitrate for audio.
    This issue video bitrate vs other bitrates vs maximum allowed bitrate for tape.
    IMHO for AC-3 with high bitrates like 448 - 512 or even 640kbps (not widely recommended as not allowed by DVD) you will be unable to perceive any quality loss. But at some corner case (proper noiseshaping) LPCM may deliver more than 120dB dynamics.
    Quote Quote  
  14. Originally Posted by SF01 View Post
    ...and the resulting 720x540 frame is contained in 720x576 via letterbox. At least this is my reasoning
    And your reasoning is dead wrong. Have you no knowledge of what DAR (Display Aspect Ratio) even means?

    If it's square pixel at 1920x1080=1.778:1, then it's resized to 720x576 and encoded as 16:9.

    If it's square pixel at 1440x1080=1.33:1, then it's resized to 720x576 and encoded as 4:3.

    The DAR tells the player how to resize it at playback time. Yes, 720x576=1.25:1=5:4, but that's more or less irrelevant. That 1.25:1 ratio video is how it's stored in its container, not how it's seen at playback time. What's important is the DAR. 4:3=1.33, 16:9=1.778. This is all kind of basic stuff.

    For example, a 640 × 480 VGA image has a SAR of 640/480 = 4:3, and if displayed on a 4:3 display (DAR = 4:3) has square pixels, hence a PAR of 1:1. By contrast, a 720 × 576 D-1 PAL image has a SAR of 720/576 = 5:4, but is displayed on a 4:3 display (DAR = 4:3).
    https://en.wikipedia.org/wiki/Pixel_aspect_ratio
    Quote Quote  
  15. Originally Posted by pandy View Post
    Originally Posted by SF01 View Post
    Well, my calculations were as follows:
    1920x1080 to 1440x1080 is a standard anamorphic compression. Then dividing both dimensions by 2, ie downscaling the frame into 1/4 of the area gives 1440/2=720 and 1080/2=540.
    1440x1080 is 4:3, 720x576 is not 4:3, but 720x540 is 4:3, so shrinking 1440x1080 to 720x540 should preserve everything and the resulting 720x540 frame is contained in 720x576 via letterbox. At least this is my reasoning. But I see the problematic point now. The expansion of 720x576 will not result in 960x540 that is 1/4 of 1920x1080, it will be stretched to 1024, which is too much. The thing is 720x576 is not 4:3 format, so it would be logical first to do downscaling of the video to 1024x576 and then do the anamorphic compression, without the "540" step. Which means the original widescreen video should be downscaled by a factor of 1/1,875 to 1024x576 and then compressed anamorphicaly into 720x576. Does it sound more realistic? Which should be the workflow for other 16:9 materials
    But the native 4:3 such as 1440x1080 still would be better if done the previous method, just scaled down to 720x540 and letterboxed.
    Nope - display surface decide about aspect NOT absolute pixels and lines. There is no need for two step resize - just resize any 16:9 video to anamorphic 720x576 16:9 - decoder will restore video correctly unless your display aspect ratio is something less than 16:9.
    Also it is not clear to me what are connectivity possibilities for your D-VHS deck thuscan't advice more.

    Originally Posted by SF01 View Post
    I guess I can uploadthe manual, but I don't know it it will help.
    And that's why it will be nice to see specification


    Originally Posted by SF01 View Post
    Audio:
    Of course not AAC, my mistake, I was thinking about AC3 @384kbps, only if D-VHS does not support LPCM. LPCM is lossless, useful for concerts and I preffer my audio lossless. It's the issue of max allowed bitrate for audio.
    This issue video bitrate vs other bitrates vs maximum allowed bitrate for tape.
    IMHO for AC-3 with high bitrates like 448 - 512 or even 640kbps (not widely recommended as not allowed by DVD) you will be unable to perceive any quality loss. But at some corner case (proper noiseshaping) LPCM may deliver more than 120dB dynamics.
    I upload the manual.

    The connectivity is via FireQire, the DVHSTool can control tape transport, I just need to input compliant file.

    Indeed, it's the question if LPCM is allowed by bitrate, if not, then AC3 is the way at highest bitrate possible.

    Again, the middle step of 1024x576 is completely virtual.

    Originally Posted by manono View Post
    Originally Posted by SF01 View Post
    ...and the resulting 720x540 frame is contained in 720x576 via letterbox. At least this is my reasoning
    And your reasoning is dead wrong. Have you no knowledge of what DAR (Display Aspect Ratio) even means?

    If it's square pixel at 1920x1080=1.778:1, then it's resized to 720x576 and encoded as 16:9.

    If it's square pixel at 1440x1080=1.33:1, then it's resized to 720x576 and encoded as 4:3.

    The DAR tells the player how to resize it at playback time. Yes, 720x576=1.25:1=5:4, but that's more or less irrelevant. That 1.25:1 ratio video is how it's stored in its container, not how it's seen at playback time. What's important is the DAR. 4:3=1.33, 16:9=1.778. This is all kind of basic stuff.

    For example, a 640 × 480 VGA image has a SAR of 640/480 = 4:3, and if displayed on a 4:3 display (DAR = 4:3) has square pixels, hence a PAR of 1:1. By contrast, a 720 × 576 D-1 PAL image has a SAR of 720/576 = 5:4, but is displayed on a 4:3 display (DAR = 4:3).
    https://en.wikipedia.org/wiki/Pixel_aspect_ratio
    I came to the same conclusions as well, I had a flaw in my reasoning, because I tried to oversimplyfy things, but in turn I made them the opposite.

    So either way I should downscale 16:9 and 4:3 to 720x576 and it will retain proper DAR at playback, or I will have to manually set the TV that input is anamorphic.

    So the only thing to determine is the bitrate of video and audio and I can experiment with ffmpeg.
    Image Attached Thumbnails JVC - HM-DR10000EU.pdf  

    Quote Quote  
  16. Originally Posted by SF01 View Post
    I upload the manual.

    The connectivity is via FireQire, the DVHSTool can control tape transport, I just need to input compliant file.

    Indeed, it's the question if LPCM is allowed by bitrate, if not, then AC3 is the way at highest bitrate possible.

    Again, the middle step of 1024x576 is completely virtual.

    So the only thing to determine is the bitrate of video and audio and I can experiment with ffmpeg.
    Ok, so it looks like different case than primary OP - first SD machine is not HD as before. Easiest approach from my perspective is to rip DVD without re-encoding video and just remux video ES to TS where i assume net bitrate is 19.14Mbps (but it is not clear to me and it can also gross bitrate). Looks like max video bitrate is 14.1Mbps, no S/PDIF may imply no support for anything except LPCM and or MPEG-1 Layer 2 audio.
    So i would rather focus on audio than on video - with ffmpeg you may wish to use HRTF to convert multichannel source audio to stereo binaural (side to already existing tracks). Anyway overall task is less interesting than HD MPEG-2 D-VHS.
    If you still wish to convert HD NTSC-like to PAL then frame rate conversion and or interlace (vs progressive 25 - supported or not?) is still valid.
    Quote Quote  
  17. I don't have DVDs and I won't be converting NTSC to PAL. IVTC maybe from BD. But DVD is too heavily compressed to use.

    This is why I wrote that I need to use 576 PAL. Maybe not as interesting as HD D-VHS, but the principle is the same.

    Still several questions remain. For example will it accept native 576p, ir should it be encoded as PsF. I had a ascript for sox to downmix 6 channel surround to stereo using components from center and sub speaker and left/right front and back respectively for each channel.

    The biggest problem is that I cannot capture D-VHS with this to see what parameters the machine uses, because it does not allow for firewire rip.
    Quote Quote  
  18. Originally Posted by SF01 View Post
    I don't have DVDs and I won't be converting NTSC to PAL. IVTC maybe from BD. But DVD is too heavily compressed to use.
    This is why I wrote that I need to use 576 PAL. Maybe not as interesting as HD D-VHS, but the principle is the same.[/QUOTE]

    https://forum.doom9.org/showthread.php?t=174620
    https://forum.doom9.org/showthread.php?p=1809116#post1809116 (by default it produce DVD NTSC - some changes are required to match new ffmpeg syntax, fix some errors (parameter may be incorrect) and most important change bitrate to max 14100k and color space from 170 to 601.
    and few other topics on https://forum.doom9.org/forumdisplay.php?f=62

    Originally Posted by SF01 View Post
    Still several questions remain. For example will it accept native 576p, ir should it be encoded as PsF. I had a ascript for sox to downmix 6 channel surround to stereo using components from center and sub speaker and left/right front and back respectively for each channel.

    The biggest problem is that I cannot capture D-VHS with this to see what parameters the machine uses, because it does not allow for firewire rip.
    Downmixing can be easily performed by ffmpeg - i use few different downmixes, also i like HRTF function where IMHO downmixed multichannel audio is way more natural and subjectively better.

    This one for 7.1 to 5.1 (perhaps wrong but it should keep all spatial audio components)
    Code:
    "pan=5.1(side)|FL<1.414FL+FLC|FR<1.414FR+FRC|FC<2.828FC+FLC+FRC|LFE=LFE|SL<SL+BL|SR<SR+BR,aresample=resampler=soxr:osr=48000:cutoff=0.99:precision=24:dither_method=0"
    my standard 5.1 to 2.0 (can be easily extended to 7.1 case)
    Code:
    "pan=stereo|FL<FL+1.414FC+0.5BL+0.5SL+0.25LFE|FR<FR+1.414FC+0.5BR+0.5SR+0.25LFE,dynaudnorm=p=1/sqrt(2):m=100:s=20,aresample=resampler=soxr:osr=48000:cutoff=0.99:precision=24:dither_method=0"
    And SOFA (HRTF) however it require -filter_complex and this mean different approach to audio and video processing (-vf and -af no longer works thus video and audio need to be processed explicitly together but separated).
    Code:
    "[0:a:0]aformat=channel_layouts=7.1,aresample=resampler=soxr:osr=48000:cutoff=0.99:precision=24:dither_method=0,asplit[71][sofai];[sofai]sofalizer=sofa=dodeca_and_7channel_3DSL_HRTF.sofa:gain=11:lfegain=9[sofao]"
    You need SOFA filter coefficient bank file "dodeca_and_7channel_3DSL_HRTF.sofa" - present with VLC (i think you may use VLC to check difference between ordinary i.e. only level downmixing and HRTF downmixing - phase and level) - highly recommended for headphones.
    Quote Quote  
  19. OK, based on the original code provided for NTSC 1080i I have modified several parameters that are in the first line of the code, but I have no idea how to adjust theo ther parameters and what they actually do starting from line 2:
    Code:
    ffmpeg -i INPUT.XXX -c:v mpeg2video -r 25 -vf scale=720:576 -aspect 16:9
     -b:v 14100000
     -minrate 14100000
     -maxrate 14100000
     -bufsize 9781248
     -bf 2
     -sc_threshold -30000
     -seq_disp_ext 1
     -color_primaries 1
     -color_trc 1
     -colorspace 1
     -dc 10
     -me_range 960
     -inter_matrix 16,17,18,19,20,21,22,23,17,18,19,20,21,22,23,24,18,19,20,21,22,23,24,25,19,20,21,22,23,24,26,27,20,21,22,23,25,26,27,28,21,22,23,24,26,27,28,30,22,23,24,26,27,28,30,31,23,24,25,27,28,30,31,33
     -acodec lpcm
     -muxrate 19140000
     OUTPUT.ts
    This is for stereo, should I downmix surround to stereo I will insert the codes that wre provided in the post above.

    The bitrate is the max bitrate specified for STD speed, the muxrate is the max recording bitrate for this device, as specified in the manual.
    I'm still groping in the dark when it comes to ffmpeg.

    16:9 for videos that are such, for 4:3 this will be removed.
    Quote Quote  
  20. Originally Posted by SF01 View Post
    OK, based on the original code provided for NTSC 1080i I have modified several parameters that are in the first line of the code, but I have no idea how to adjust theo ther parameters and what they actually do starting from line 2:
    Code:
    ffmpeg -i INPUT.XXX -c:v mpeg2video -r 25 -vf scale=720:576 -aspect 16:9
     -b:v 14100000
     -minrate 14100000
     -maxrate 14100000
     -bufsize 9781248
     -bf 2
     -sc_threshold -30000
     -seq_disp_ext 1
     -color_primaries 1
     -color_trc 1
     -colorspace 1
     -dc 10
     -me_range 960
     -inter_matrix 16,17,18,19,20,21,22,23,17,18,19,20,21,22,23,24,18,19,20,21,22,23,24,25,19,20,21,22,23,24,26,27,20,21,22,23,25,26,27,28,21,22,23,24,26,27,28,30,22,23,24,26,27,28,30,31,23,24,25,27,28,30,31,33
     -acodec lpcm
     -muxrate 19140000
     OUTPUT.ts
    This is for stereo, should I downmix surround to stereo I will insert the codes that wre provided in the post above.

    The bitrate is the max bitrate specified for STD speed, the muxrate is the max recording bitrate for this device, as specified in the manual.
    I'm still groping in the dark when it comes to ffmpeg.

    16:9 for videos that are such, for 4:3 this will be removed.
    Above script probably will not provide high quality MPEG-2 encoding.
    IMHO you should go for CBR RDO.
    IMHO you should convert color from 709 to 601 and properly signal this in ffmpeg

    Code:
      -color_primaries   <int>        ED.V..... color primaries (from 1 to INT_MAX) (default unknown)
         bt709                        ED.V..... BT.709
         unknown                      ED.V..... Unspecified
         bt470m                       ED.V..... BT.470 M
         bt470bg                      ED.V..... BT.470 BG
         smpte170m                    ED.V..... SMPTE 170 M
         smpte240m                    ED.V..... SMPTE 240 M
         film                         ED.V..... Film
         bt2020                       ED.V..... BT.2020
         smpte428                     ED.V..... SMPTE 428-1
         smpte428_1                   ED.V..... SMPTE 428-1
         smpte431                     ED.V..... SMPTE 431-2
         smpte432                     ED.V..... SMPTE 422-1
         jedec-p22                    ED.V..... JEDEC P22
         unspecified                  ED.V..... Unspecified
      -color_trc         <int>        ED.V..... color transfer characteristics (from 1 to INT_MAX) (default unknown)
         bt709                        ED.V..... BT.709
         unknown                      ED.V..... Unspecified
         gamma22                      ED.V..... BT.470 M
         gamma28                      ED.V..... BT.470 BG
         smpte170m                    ED.V..... SMPTE 170 M
         smpte240m                    ED.V..... SMPTE 240 M
         linear                       ED.V..... Linear
         log100                       ED.V..... Log
         log316                       ED.V..... Log square root
         iec61966-2-4                 ED.V..... IEC 61966-2-4
         bt1361e                      ED.V..... BT.1361
         iec61966-2-1                 ED.V..... IEC 61966-2-1
         bt2020-10                    ED.V..... BT.2020 - 10 bit
         bt2020-12                    ED.V..... BT.2020 - 12 bit
         smpte2084                    ED.V..... SMPTE 2084
         smpte428                     ED.V..... SMPTE 428-1
         arib-std-b67                 ED.V..... ARIB STD-B67
         unspecified                  ED.V..... Unspecified
         log                          ED.V..... Log
         log_sqrt                     ED.V..... Log square root
         iec61966_2_4                 ED.V..... IEC 61966-2-4
         bt1361                       ED.V..... BT.1361
         iec61966_2_1                 ED.V..... IEC 61966-2-1
         bt2020_10bit                 ED.V..... BT.2020 - 10 bit
         bt2020_12bit                 ED.V..... BT.2020 - 12 bit
         smpte428_1                   ED.V..... SMPTE 428-1
      -colorspace        <int>        ED.V..... color space (from 0 to INT_MAX) (default unknown)
         rgb                          ED.V..... RGB
         bt709                        ED.V..... BT.709
         unknown                      ED.V..... Unspecified
         fcc                          ED.V..... FCC
         bt470bg                      ED.V..... BT.470 BG
         smpte170m                    ED.V..... SMPTE 170 M
         smpte240m                    ED.V..... SMPTE 240 M
         ycgco                        ED.V..... YCGCO
         bt2020nc                     ED.V..... BT.2020 NCL
         bt2020c                      ED.V..... BT.2020 CL
         smpte2085                    ED.V..... SMPTE 2085
         unspecified                  ED.V..... Unspecified
         ycocg                        ED.V..... YCGCO
         bt2020_ncl                   ED.V..... BT.2020 NCL
         bt2020_cl                    ED.V..... BT.2020 CL
    IMHO VBV bffer is way too big for MP@ML ( maximum allowed is 1835008)

    Code:
    Encoder mpeg2video [MPEG-2 video]:
        General capabilities: delay threads 
        Threading capabilities: slice
        Supported framerates: 1/1 2/1 3/1 4/1 5/1 6/1 8/1 9/1 10/1 12/1 15/1 16/1 18/1 20/1 24/1 25/1 30/1 32/1 36/1 40/1 45/1 48/1 50/1 60/1 72/1 75/1 80/1 90/1 96/1 100/1 120/1 150/1 180/1 200/1 240/1 750/1001 800/1001 960/1001 1000/1001 1200/1001 1250/1001 1500/1001 1600/1001 1875/1001 2000/1001 2400/1001 2500/1001 3000/1001 3750/1001 4000/1001 4800/1001 5000/1001 6000/1001 7500/1001 8000/1001 10000/1001 12000/1001 15000/1001 20000/1001 24000/1001 30000/1001 60000/1001
        Supported pixel formats: yuv420p yuv422p
    mpeg2video encoder AVOptions:
      -gop_timecode      <string>     E..V..... MPEG GOP Timecode in hh:mm:ss[:;.]ff format. Overrides timecode_frame_start.
      -intra_vlc         <boolean>    E..V..... Use MPEG-2 intra VLC table. (default false)
      -drop_frame_timecode <boolean>    E..V..... Timecode is in drop frame format. (default false)
      -scan_offset       <boolean>    E..V..... Reserve space for SVCD scan offset user data. (default false)
      -timecode_frame_start <int64>      E..V..... GOP timecode frame start number, in non-drop-frame format (from -1 to I64_MAX) (default -1)
      -non_linear_quant  <boolean>    E..V..... Use nonlinear quantizer. (default false)
      -alternate_scan    <boolean>    E..V..... Enable alternate scantable. (default false)
      -seq_disp_ext      <int>        E..V..... Write sequence_display_extension blocks. (from -1 to 1) (default auto)
         auto                         E..V.....
         never                        E..V.....
         always                       E..V.....
      -video_format      <int>        E..V..... Video_format in the sequence_display_extension indicating the source of the video. (from 0 to 7) (default unspecified)
         component                    E..V.....
         pal                          E..V.....
         ntsc                         E..V.....
         secam                        E..V.....
         mac                          E..V.....
         unspecified                  E..V.....
      -mpv_flags         <flags>      E..V..... Flags common for all mpegvideo-based encoders. (default 0)
         skip_rd                      E..V..... RD optimal MB level residual skipping
         strict_gop                   E..V..... Strictly enforce gop size
         qp_rd                        E..V..... Use rate distortion optimization for qp selection
         cbp_rd                       E..V..... use rate distortion optimization for CBP
         naq                          E..V..... normalize adaptive quantization
         mv0                          E..V..... always try a mb with mv=<0,0>
      -luma_elim_threshold <int>        E..V..... single coefficient elimination threshold for luminance (negative values also consider dc coefficient) (from INT_MIN to INT_MAX) (default 0)
      -chroma_elim_threshold <int>        E..V..... single coefficient elimination threshold for chrominance (negative values also consider dc coefficient) (from INT_MIN to INT_MAX) (default 0)
      -quantizer_noise_shaping <int>        E..V..... (from 0 to INT_MAX) (default 0)
      -error_rate        <int>        E..V..... Simulate errors in the bitstream to test error concealment. (from 0 to INT_MAX) (default 0)
      -qsquish           <float>      E..V..... how to keep quantizer between qmin and qmax (0 = clip, 1 = use differentiable function) (from 0 to 99) (default 0)
      -rc_qmod_amp       <float>      E..V..... experimental quantizer modulation (from -FLT_MAX to FLT_MAX) (default 0)
      -rc_qmod_freq      <int>        E..V..... experimental quantizer modulation (from INT_MIN to INT_MAX) (default 0)
      -rc_eq             <string>     E..V..... Set rate control equation. When computing the expression, besides the standard functions defined in the section 'Expression Evaluation', the following functions are available: bits2qp(bits), qp2bits(qp). Also the following constants are available: iTex pTex tex mv fCode iCount mcVar var isI isP isB avgQP qComp avgIITex avgPITex avgPPTex avgBPTex avgTex.
      -rc_init_cplx      <float>      E..V..... initial complexity for 1-pass encoding (from -FLT_MAX to FLT_MAX) (default 0)
      -rc_buf_aggressivity <float>      E..V..... currently useless (from -FLT_MAX to FLT_MAX) (default 1)
      -border_mask       <float>      E..V..... increase the quantizer for macroblocks close to borders (from -FLT_MAX to FLT_MAX) (default 0)
      -lmin              <int>        E..V..... minimum Lagrange factor (VBR) (from 0 to INT_MAX) (default 236)
      -lmax              <int>        E..V..... maximum Lagrange factor (VBR) (from 0 to INT_MAX) (default 3658)
      -ibias             <int>        E..V..... intra quant bias (from INT_MIN to INT_MAX) (default 999999)
      -pbias             <int>        E..V..... inter quant bias (from INT_MIN to INT_MAX) (default 999999)
      -rc_strategy       <int>        E..V..... ratecontrol method (from 0 to 1) (default ffmpeg)
         ffmpeg                       E..V..... deprecated, does nothing
         xvid                         E..V..... deprecated, does nothing
      -motion_est        <int>        E..V..... motion estimation algorithm (from 0 to 2) (default epzs)
         zero                         E..V.....
         epzs                         E..V.....
         xone                         E..V.....
      -force_duplicated_matrix <boolean>    E..V..... Always write luma and chroma matrix for mjpeg, useful for rtp streaming. (default false)
      -b_strategy        <int>        E..V..... Strategy to choose between I/P/B-frames (from 0 to 2) (default 0)
      -b_sensitivity     <int>        E..V..... Adjust sensitivity of b_frame_strategy 1 (from 1 to INT_MAX) (default 40)
      -brd_scale         <int>        E..V..... Downscale frames for dynamic B-frame decision (from 0 to 3) (default 0)
      -skip_threshold    <int>        E..V..... Frame skip threshold (from INT_MIN to INT_MAX) (default 0)
      -skip_factor       <int>        E..V..... Frame skip factor (from INT_MIN to INT_MAX) (default 0)
      -skip_exp          <int>        E..V..... Frame skip exponent (from INT_MIN to INT_MAX) (default 0)
      -skip_cmp          <int>        E..V..... Frame skip compare function (from INT_MIN to INT_MAX) (default dctmax)
         sad                          E..V..... Sum of absolute differences, fast
         sse                          E..V..... Sum of squared errors
         satd                         E..V..... Sum of absolute Hadamard transformed differences
         dct                          E..V..... Sum of absolute DCT transformed differences
         psnr                         E..V..... Sum of squared quantization errors, low quality
         bit                          E..V..... Number of bits needed for the block
         rd                           E..V..... Rate distortion optimal, slow
         zero                         E..V..... Zero
         vsad                         E..V..... Sum of absolute vertical differences
         vsse                         E..V..... Sum of squared vertical differences
         nsse                         E..V..... Noise preserving sum of squared differences
         dct264                       E..V.....
         dctmax                       E..V.....
         chroma                       E..V.....
         msad                         E..V..... Sum of absolute differences, median predicted
      -sc_threshold      <int>        E..V..... Scene change threshold (from INT_MIN to INT_MAX) (default 0)
      -noise_reduction   <int>        E..V..... Noise reduction (from INT_MIN to INT_MAX) (default 0)
      -mpeg_quant        <int>        E..V..... Use MPEG quantizers instead of H.263 (from 0 to 1) (default 0)
      -ps                <int>        E..V..... RTP payload size in bytes (from INT_MIN to INT_MAX) (default 0)
      -mepc              <int>        E..V..... Motion estimation bitrate penalty compensation (1.0 = 256) (from INT_MIN to INT_MAX) (default 256)
      -mepre             <int>        E..V..... pre motion estimation (from INT_MIN to INT_MAX) (default 0)

    IMHO lpcm codec doesn't exist and perhaps you should replace it with something like:
    Code:
    -c:a pcm_s16le -ac 2 -ar 48000
    Forgot to mention about selecting proper profile and level:
    Code:
    #define FF_PROFILE_MPEG2_422    0
    
    level = 5; /* Main */
    level = 2; /* High */
    
    #define FF_PROFILE_MPEG2_HIGH   1
    #define FF_PROFILE_MPEG2_SS     2
    #define FF_PROFILE_MPEG2_SNR_SCALABLE  3
    #define FF_PROFILE_MPEG2_MAIN   4
    #define FF_PROFILE_MPEG2_SIMPLE 5
    level = 8; /* Main */
    level = 6; /* High 1440 */
    level = 4; /* High */
    Last edited by pandy; 25th Jan 2019 at 14:46.
    Quote Quote  
  21. First the colour. According to this:
    https://kdenlive.org/en/project/color-hell-ffmpeg-transcoding-and-preserving-bt-601/
    the line is:
    Code:
    -color_primaries bt470bg -color_trc gamma28 -colorspace bt470bg
    or would "bt601" suffice in those three?

    So the buffsize will be 1835008. Or should it be less?

    Yes, the lpcm was too muuch of a shortcut, the pcm16le is the way to go,I only found it later as I was reading documentation.

    And the profile structure should be as follows:
    Code:
    -profile:v 4 -level:v 8
    Therefore the code looks for now like this:

    Code:
    ffmpeg -i INPUT.XXX -c:v mpeg2video -profile:v 4 -level:v 8 -r 25 -vf scale=720:576 -aspect 16:9 -b:v 14100000 -minrate 14100000 -maxrate 14100000 -bufsize 1835008 -color_primaries bt470bg -color_trc gamma28 -colorspace bt470bg
     -bf 2
     -sc_threshold 0
     -seq_disp_ext 1
     -dc 10
     -me_range 960
     -inter_matrix 16,17,18,19,20,21,22,23,17,18,19,20,21,22,23,24,18,19,20,21,22,23,24,25,19,20,21,22,23,24,26,27,20,21,22,23,25,26,27,28,21,22,23,24,26,27,28,30,22,23,24,26,27,28,30,31,23,24,25,27,28,30,31,33
     -c:a pcm_s16le -ac 2 -ar 48000
     -muxrate 19140000
     OUTPUT.ts
    Still, what do parameters
    Code:
    -bf
    ,
    Code:
    -seq_disp_ex
    ,
    Code:
    -dc
    ,
    Code:
    -me_range
    ,
    Code:
    -inter_matrix
    do? And most importantly how to set them properly for PAL MPEG-TS?
    Quote Quote  
  22. Originally Posted by SF01 View Post
    First the colour. According to this:
    https://kdenlive.org/en/project/color-hell-ffmpeg-transcoding-and-preserving-bt-601/
    the line is:
    Code:
    -color_primaries bt470bg -color_trc gamma28 -colorspace bt470bg
    or would "bt601" suffice in those three?
    Well... if your source is true HD then it will probably use BT.709 so you should convert it or by using dedicated filter "colormatrix=bt709:bt601" or by using similar functionality in "scale" filter.

    bt601 means same as bt470bg - BT.470 is analog composite video standard where BT.601 is digital version of BT.470 and BG means PAL in EUrope

    Originally Posted by SF01 View Post
    So the buffsize will be 1835008. Or should it be less?
    VBV maximum allowed for MP@ML is 112 where 112 is in fact 112*16384 i.e. 1835008 - VBV can be lower than this but anyway it should be mod16384 - see no point in reducing VBV as DVD forced all MPEG-2 decoder to accept maximum allowed for MP@ML.

    Originally Posted by SF01 View Post
    Therefore the code looks for now like this:

    Code:
    ffmpeg -i INPUT.XXX -c:v mpeg2video -profile:v 4 -level:v 8 -r 25 -vf scale=720:576 -aspect 16:9 -b:v 14100000 -minrate 14100000 -maxrate 14100000 -bufsize 1835008 -color_primaries bt470bg -color_trc gamma28 -colorspace bt470bg
     -bf 2
     -sc_threshold 0
     -seq_disp_ext 1
     -dc 10
     -me_range 960
     -inter_matrix 16,17,18,19,20,21,22,23,17,18,19,20,21,22,23,24,18,19,20,21,22,23,24,25,19,20,21,22,23,24,26,27,20,21,22,23,25,26,27,28,21,22,23,24,26,27,28,30,22,23,24,26,27,28,30,31,23,24,25,27,28,30,31,33
     -c:a pcm_s16le -ac 2 -ar 48000
     -muxrate 19140000
     OUTPUT.ts
    IMHO you should properly setup scale filter - flags are important, i always use something like
    Code:
    scale=720:576:sws_flags=spline+accurate_rnd+full_chroma_int+full_chroma_inp
    Originally Posted by SF01 View Post
    Still, what do parameters
    Code:
    -bf
    ,
    Code:
    -seq_disp_ex
    ,
    Code:
    -dc
    ,
    Code:
    -me_range
    ,
    Code:
    -inter_matrix
    do? And most importantly how to set them properly for PAL MPEG-TS?
    First i would read about those settings later would not touch some of the default settings for example maximum number of B frames for DVD (and as such for general consumer MPEG-2 decoders) is 2 stay on safe side - depends on encoder quality B frames may be good or bad choice - sometimes observe better quality at the same or marginally higher bitrate when B frames are not used. H.264 significantly improved B frames but MPEG-2 encoder B frames are NOK.
    I use adding display extension as it prevent problems during seek, each GOP has access to correct display extension at a cost of few tens/hundred bytes - if you starving from bits then you may consider to not use this feature but you may expect some problems on badly designed MPEG-2 decoders...

    dc is precision of DCT coefficient for DC block (it represent average luminance of whole block) - 8, 9 or 10 bits, where 8 worst, 10 highest - usually 8 bit is used when you using low bitrate (to save bits) for high bitrates higher than 8 is recommended
    https://forum.videohelp.com/threads/225262-TMPGEnc-s-DC-component-precision-setting

    IMHO ME range should be with respect to maximum motion range vector allowed by MP@ML which is
    Code:
    Horizontal Vector Range -512:+511.5
    Vertical Vector Range (frame pictures) -128:+127.5
    Had not time to analyse how ffmpeg links those two and how overall quality is affected - perhaps ME-range like 16..32 is better than 127 - no clue - ffmpeg documentation is highly incomplete on many aspects - i mean you need to guess based frequently on code analysis what option do and how useful it can be - also it is very important - ffmpeg never had good, finished MPEG-2 encoder - it was substantially improved over years but still missing many features that can be considered as very important nowadays - for example trellis, rdo not work as intended, no dynamic GOP size almost at all, almost no psychovisual modelling - HCEnc is way better on this but still plenty of new techniques can be implemented to further refine MPEG-2 encoding - i know it was some try first to develop based on x264 a new MPEG-2 encoder (x262) even some effort to accommodate x262 within ffmpeg but seem from few years all works on this project are on hold and seem that MPEG-2 died without fully using it potential.
    This is probably not important for your case where max allowed bitrate is very high but still.
    And my personal impression - CBR encoding is bad and unnatural - there is no such thing as lossy Constant Bitrate encoder... trying to bend lossy encoder to work as CBR usually doesn't gain any quality and is usually first problem to encoder secondly just crude workaround for faulty multiplexer.

    INTRA and INTER quantization matrices are directly responsible for shaping spectral characteristic of your video with respect to overall scene complexity and available bitrate: https://forum.doom9.org/showthread.php?t=54147 , if you use them, use them wisely as bad quantization matrices usually lead to increase overall high quantization factor and instead delivering higher quality they tend to deliver bad quality. Too flat or too sharp may elevate overall quantizer to very high values.
    All this depends on spatial content of your video and encoding bitrate.

    Once again you should spent some time and read about tweaking ffmpeg to do hq MPEG-2 encoding - difference between your D-VHS case and DVD is only maximum video bit rate allowed and target muxing rate.
    https://forum.doom9.org/showthread.php?t=174620
    Quote Quote  
  23. The sources will be various from the materials I recorded in DV and HD in either AVC, HEVC, or ProRes.
    Composite as in composite analog video? MPEG should be capable of RGB encoding.
    And this
    Code:
    scale=720:576:sws_flags=spline+accurate_rnd+full_chroma_int+full_chroma_inp
    is sufficient for both 4:3 and 16:9 source?
    I've read about B-frames and what value it should have, 2 is default for DVD, but maybe higher value would work for MPEG-TS. The rest of parameters I could not find in extended ffmpeg documentation, only brief appearances in commands.

    Then I can use the -dc 10 parameter, as I use at least twice the bitrate of DVD and 3/5 of DV bitrate.

    The video inside MPEG-TS can be VBR from hat IO've read, but the stream must be CBR and this is done by using null packets.

    I'll try without matrices first.

    Overall, the code after revisions is now of this shape:
    Code:
    ffmpeg -i INPUT.XXX -c:v mpeg2video -profile:v 4 -level:v 8 -r 25 -vf scale=720:576 -aspect 16:9 -b:v 14100000 -minrate 14100000 -maxrate 14100000 -bufsize 1835008 -color_primaries bt470bg -color_trc gamma28 -colorspace bt470bg scale=720:576:sws_flags=spline+accurate_rnd+full_chroma_int+full_chroma_inp  -bf 2 -dc 10 -c:a pcm_s16le -ac 2 -ar 48000 -muxrate 19140000 OUTPUT.ts
    Aything to correct in the scaling and colour department?
    Quote Quote  
  24. Originally Posted by SF01 View Post
    The sources will be various from the materials I recorded in DV and HD in either AVC, HEVC, or ProRes.
    Composite as in composite analog video? MPEG should be capable of RGB encoding.
    MPEG-2 is capable to encode YCbCr and YCgCo - 4:2:0 and 4:2:2, IMHO MPEG-2 doesn't allow to use RGB 4:4:4 natively.

    Originally Posted by SF01 View Post
    And this
    Code:
    scale=720:576:sws_flags=spline+accurate_rnd+full_chroma_int+full_chroma_inp
    is sufficient for both 4:3 and 16:9 source?
    It is aspect independent and force swscale to use hq resize.

    Originally Posted by SF01 View Post
    I've read about B-frames and what value it should have, 2 is default for DVD, but maybe higher value would work for MPEG-TS. The rest of parameters I could not find in extended ffmpeg documentation, only brief appearances in commands.
    D-VHS MPEG-2 decoder and DVD largely overlapping - you can try various settings and look what is accepted - this is magnetic tape so you can easily check various settings.

    Originally Posted by SF01 View Post
    Then I can use the -dc 10 parameter, as I use at least twice the bitrate of DVD and 3/5 of DV bitrate.
    Yes, it is recommended as it directly affect quality.

    Originally Posted by SF01 View Post
    The video inside MPEG-TS can be VBR from hat IO've read, but the stream must be CBR and this is done by using null packets.
    MPEG-TS can be CBR or VBR (but in your case it may be required that TS is CBR), MPEG-2 ES can be CBR (but in real life it will be always VBR).
    Both TS and ES may use additional stuffing to be strict CBR.


    Originally Posted by SF01 View Post
    I'll try without matrices first.
    OK, but with high bitrate and strict CBR you may see underflow VBV errors. That's why i recommend to use VBR ES.


    Originally Posted by SF01 View Post
    Overall, the code after revisions is now of this shape:
    Code:
    ffmpeg -i INPUT.XXX -c:v mpeg2video -profile:v 4 -level:v 8 -r 25 -vf scale=720:576 -aspect 16:9 -b:v 14100000 -minrate 14100000 -maxrate 14100000 -bufsize 1835008 -color_primaries bt470bg -color_trc gamma28 -colorspace bt470bg scale=720:576:sws_flags=spline+accurate_rnd+full_chroma_int+full_chroma_inp  -bf 2 -dc 10 -c:a pcm_s16le -ac 2 -ar 48000 -muxrate 19140000 OUTPUT.ts
    Aything to correct in the scaling and colour department?
    I would suggest this:

    Code:
    ffmpeg -i INPUT.XXX -dn -sn -c:v mpeg2video -profile:v 4 -level:v 8 -qmin 2 -b:v 14100000 -minrate 14100000 -maxrate 14100000 -bufsize 1835008 -bf 2 -g 15 -dc 10 -me_range 127 -vf scale=720:576:sws_flags=spline+accurate_rnd+full_chroma_int+full_chroma_inp:out_color_matrix=bt601,format=pix_fmts=yuv420p -aspect 16:9 -color_primaries bt470bg -color_trc gamma28 -colorspace bt470bg -c:a pcm_s16le -ac 2 -ar 48000 -muxrate 19140000 -r 25 OUTPUT.ts
    Quote Quote  
  25. I've also read to use
    Code:
    -f mpegts
    and
    Code:
    -packetsize 188
    to fill space between vbr video and cbr container with null packets.

    The "-aspect 16:9" obviously only for widescreen sources, which I think I will mostly use.
    Quote Quote  
  26. Originally Posted by SF01 View Post
    I've also read to use
    Code:
    -f mpegts
    You can add but IMHO ffmpeg will add it automatically when TS extension will be used - anyway it is good to tell ffmpeg explicitly what format should be used.

    Originally Posted by SF01 View Post
    and
    Code:
    -packetsize 188
    to fill space between vbr video and cbr container with null packets.

    The "-aspect 16:9" obviously only for widescreen sources, which I think I will mostly use.
    Nope (i mean have no clue in case of D-VHS) packet 188 bytes is used by DVB - DVD and D-VHS may use different packet size. I would rely on default packet size and try other packet size in case when your deck refuse to accept default packet size.
    And CBR TS is created by using "-muxrate 19140000" option - there is special PID (1FFF) used as stuffing ie on this PID all data are used to fill difference of bitrate between sum of all bitrates (PID's) and required TS bitrate. Commonly this PID is ignored in demuxer.

    Yes, if your source should be displayed on 16:9 display then aspect should be 16/9 if content should be displayed on 4:3 then aspect should be 4/3 - MPEG-2 accept only limited amount of aspects. Modern codecs are way more flexible on this.
    Quote Quote  
  27. But the "-muxrate 19140000" is not allowed in MP@ML.

    Right, I read about the packet 188 in DVB documentation whiletrying to find more informations about MPEG_TS.

    I'm not sure, if the bitstream shouldn't be exactly 19140000 packed with null packets to fill that.
    Quote Quote  
  28. Originally Posted by SF01 View Post
    But the "-muxrate 19140000" is not allowed in MP@ML.

    Right, I read about the packet 188 in DVB documentation whiletrying to find more informations about MPEG_TS.

    I'm not sure, if the bitstream shouldn't be exactly 19140000 packed with null packets to fill that.
    MPEG-2 is a video codec, where MPEG-TS is a container - don't confuse both things - in your case MPEG-2 video ES maximum bitrate is 14100k and MPEG-TS bitrate should be 19140k. Bitrate for container is always higher than bitrate of video embedded inside container.
    Quote Quote  
  29. Yes, the container contain video, audio and sometimes other stuff, so it's overall bitrate is the sum of its parts.
    I'll try with the final version of the command and check the results.
    Quote Quote  
  30. Capturing Memories dellsam34's Avatar
    Join Date
    Jan 2016
    Location
    Member Since 2005, Re-joined in 2016
    Search PM
    I've been away due to an injury now I'm back on track, I just want to update the thread with the new tests I've done with Drmpeg's latest commend in post 117, although little slower than previous one but works better, This time I tried both VLC firewire streaming on my computer and HDMI port to TV from the deck and the results were glitch free.
    I've done a full length film and noticed a minor pexilization somewhere in the middle of the tape, I'm pretty sure it's a tape dropout, I got those even on pre recorded tapes.

    I'm still interested in DTS testing, With all the tools available to me I haven't been able to demux and remux DTS successfully without sync problems, My next approach is to do DTS HD to DTS without demuxing from the video to avoid sync problems and then convert the video with FFMPEG. Can FFMPEG process videos with DTS soundtrack without altering the DTS soundtrack?
    Quote Quote  



Similar Threads

Visit our sponsor! Try DVDFab and backup Blu-rays!