New post
0

H.264 video in MRSS feeds

Avatar
JRB Technical
None
Follow

Hello:

 

Is there a key with descriptions of all the abbreviations used in the log files on the SD card?

Some of them make sense, others do not.

I am trying to track down why a MP4 video at the beginning of a MRSS Feed is not playing, typically every 3rd pass of the entire presentation loop.

I turned on all logging options, and in looking at the log files, there are no entries in the failedLog file relevant to the MP4 video.  In looking at the currentLog file, I see nothing that seems to indicate a problem, other than there is no entry for the MP4 video where it should be in the playlist order, at the times that it is being dropped.

These are relatively small videos, a little over 8 seconds, that update about every 5-10 minutes, but the file update doesn't seen to coincide with when the player (HD220-4.0.26) is dropping the video.

Just trying to figure out what is going on, and if there are any clues to be found in the log files.

Thanks!

John

Date Votes

18 comments

  • 0
    Avatar
    Lyndon

     

    What brightauthor release are you using? I don't thi nk there's a key in the faq, but the error codes are in the autorun.brs itself. But, if it's an mrss issue, I would recommend updating your firmware, so you can update to the latest brightauthor beta release. There have been a number of mrss changes in the beta version of BrightAuthor. 

  • 0
    Avatar
    JRB Technical

    I'm using BrightAuthor 3.0.0.19 currently.  I usually try to stay with the official releases of software in general for production when possible, but this feed type (NWS radar loop) is going out to a variety of players/firmware.  I am just trying to find out what seems to be the most stable across all players/firmware, which can be daunting at times.

    In testing different scenarios, it seems to be the most stable if a image is the first item in the feed, and then a video.  If I put the video first, then it is unreliable, and there seems to be no reason or indication that I have been able to find so far as to why it is occasionally dropping the video when played first.

    John

  • 0
    Avatar
    Alex

    Ensure that the video meets the following requirements:

    http://support.brightsign.biz/entries/143091-what-video-formats-and-codecs-does-the-brightsign-support

  • 0
    Avatar
    JRB Technical

    The videos are encoded with the H264 - MPEG-4 AVC (part 10) (avc1) codec, and usually do not go over 1 MB bitrate if even that.

    I changed a test feed so that a PNG is the first item in the MRSS feed, and then the video as the second item in the feed, and let it run this way overnight.  I just went through the log file, and it was rock solid in playing the video file this way.  But again, when the video is the first item in the feed, the player doesn't play the video about every 2nd or 3rd pass through the presentation as it loops through all the items. Everything else plays fine.

    The feeds have been validated, the media content types are being set as "image/png" and "video/mp4", and like I said it is only a little over 8 seconds for the video, with a file size comparable to most images. And I checked the video cache, and the player is properly caching the files.

    I can not find any legitimate reason as to why the player is skipping over the video file on occasion when the video is the first item in the feed.

    I will download the 4.1.35 Beta and test it on my box in a bit, to see how it reacts to paying the video first, or second.

    John

  • 0
    Avatar
    Lyndon

    You should also update BrightAUthor to 3.2.0.11 for your test since it has updated mrss code.

  • 0
    Avatar
    JRB Technical

    Ok, I updated to 4.1.35 Beta and BA 3.2.0.11 and it is still doing the same thing, if the video is first, it skips over the video every 2nd or 3rd time through the presentation.

    Also, I have a client with some HD210(w) and HD1010 boxes with older firmware (3.8.19 and 3.8.24 I believe), and they are not playing for them at all, I think they said the are displaying all black when they should be playing the video.

    I can deal with the workaround that a image has to be the first item in the feed, but not with the not working at all.

    Is there a point in the 3.x series firmware that H.264 mp4's in MRSS feeds was not supported?

    What video format is best for compatibility with older firmware if clients do not wish to update firmware?

    Thanks!

    John

  • 0
    Avatar
    Lyndon

    No, h.264 files have been supported for quite some time, before 3.8 firmware. What brightauthor are they using and are they using a media rss feed as well? Can you send support the mrss feed you are having problems with?

    THis is a simple mrss feed running out of my dropbox account. It points to 4 videos in a subfolder. It plays fine on my brightsigns. All videos play without problems. 

    https://dl.dropbox.com/u/3480052/mrss-video-dropboxsample.xml

     

    I just downgraded my software to 3.0.0.10 and tested, and my first video plays first. 

  • 0
    Avatar
    JRB Technical

    This is my current test pair. The weather.xml has current and forecast slides (2-png's), and radar.xml has current radar image (png) and loop (mp4). This seems to play fine every pass on my HD220:

    http://www.brightsign.info/feedtestmp4/weather.xml
    http://www.brightsign.info/feedtestmp4/radar.xml


    Here is the version of the radar with the loop (mp4) first, and then the image (png). This is the one that is consistanly dropping the mp4 every 2nd or 3rd pass:

    http://www.brightsign.info/feedtestmp4/radarflip.xml

    The mp4's should be compliant with the BrightSign specs, is H.264 format, High Profile level 4.1. It is 978x550 resolution (16:9 version of the full size image from NWS), but the players seem to scale media fine, so I don't think that is an issue.

    I have also tried the radar feed with other combinations of feeds with the same results.

    The person that says the video is not showing up for them has a different location set, but the server side images and video are being created in the same manor as these.  I do not know what version of BA they are using at this time.

    Anyone is welcome to try the feeds listed above, I will keep them active for a couple of weeks, unless people start using up a lot of bandwidth. Please post what player/firmware you used and if the video played ok or not.

    I would just like to know why it isn't working for some people, if it is a format that should work on more recent versions of firmware.

    Thanks for your time.

    John

  • 0
    Avatar
    Alex

    OK, the contents in this mrss feed are playing in proper order.

    http://brightsignnetwork.com/download/1stvideo2ndimage.xml

  • 0
    Avatar
    JRB Technical

    I know this is getting off topic now from the original post, but instead of a new thread, I will keep it here (maybe a MOD can change  the title to "H.264 video in MRSS feeds").

    All the time I have been talking about H.264 videos, and you keep using examples that are MPEG-2.

    I am trying to find out why it seems that H.264 videos are not playing on what seems to be the vast majority of players and firmware when used in MRSS feeds, even though you say they are supposed to work?

    What is the solution here?

    Do I have to go to MPEG-2 which uses more bandwidth, so I have to charge my (and your) customers more?

    H.264 has been around for quite a while, the codec I am using is a popular server side codec, and the videos are in the format as described by BrightSign.  The newer format H.265 is right around the corner now, which will improve the online size and performance of moving these videos on the internet.

    I don't want to have to go backwards to MPEG-2, does no one have any insight as to why the majority of players/firmware don't seem to want to play H.264 in a MRSS feed?  I can see that all the different players are downloading the files successfully, it is just that they are not playing (but they are playing on the newer HD220 boxes fine - as long as they are not the first item in the feed).

    I don't understand why this should be so difficult.  If the players are supposed to play H.264, and I have created the movies within the H.264 constraints as provided by BrightSign, why are they not playing on the players that they say they should??? 

  • 0
    Avatar
    Alex

    My HD1010 doesn't play the video which is included in your feed http://www.brightsign.info/feedtestmp4/radarflip.xml, HD1020 does play. I downloaded just one video file, included it in my project and it failed on the HD1010 with the latest firmware installed (fw3.9.9). Did you try to do such test?

    The following feed contains h.264 video and all contents play in proper order on both the HD1020 and HD1010.

    http://www.brightsignnetwork.com/download/MRSS/test/mrss_test/test.xml

    Please re-encode your video or use different application to encode. Check our faqs for details.

  • 0
    Avatar
    JRB Technical

    The videos are being encoded server side, using ffmpeg and the VideoLan x264 library.  The x264 library is widely used by Youtube, Facebook, Vimeo, Hulu, broadcast television, etc.  This is the best server side encoder for H.264 in use today.

    I have tried encoding using what little details are available in the FAQ for the H.264 format; Level 4 and Level 4.1, Main and High Profiles, 1280 x 720, 1920 x 1080, etc., all seem to be getting mixed results across different BrightSign Players.

    There are many many different configuration parameters available for encoding H.264, I am trying to keep things basic as I would think that should work the best, but there must be something that is causing the issues; minimum bitrate, minimum number of I, P, or B frames, CABAC,  etc. I could go on and on.

    Maybe support does not know the answer to what parameter settings should used at this time, but since H.264 is widely used, as is the x264 library, BrightSign engineers may wish to look into this to better provide use information to your customers.  Otherwise we are just throwing darts at a dartboard hoping one of the throws will wind up a bullseye.

    John

  • 0
    Avatar
    Lyndon

    Here are two different ffmpeg strings I've seen used for image to video conversion. The videos that result from them have played properly....

     

    ffmpeg -r 30 -i %~n1%%d.jpg -vcodec libx264 -s 1920x1080 -y -level 41 -8x8dct 0 -threads 1 -crf 15 -coder 0 -vbsf h264_mp4toannexb -refs 4 "%~n1.ts"

     

    ffmpeg -y -i %~n1%%d.jpg -vcodec libx264 -level 41 -crf 20 -bufsize 20000k -maxrate 25000k -g 250 -r 30 -threads 4 "%~n1.mp4"

     

  • 0
    Avatar
    Romeo

    Hi John,

     

    As for video encoding for the BrightSign players, I would suggest the following ffmpeg parameters for a file for the HDx20 players (.MP4 container)

    ffmpeg -i hd_distributor_bbc_films.m2ts -vcodec libx264 -y -level 41 -threads 1 -b:v 8000k -coder 0 -acodec libvo_aacenc -ac 2 -ar 44100 -ab 128k HDx20_player_file.mp4

     

    Media info encoding settings

     

    cabac=0 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=1 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=24 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=abr / mbtree=1 / bitrate=8000 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00

     

     

    I hope this helps.

     

    Romeo

  • 0
    Avatar
    JRB Technical

    Sorry - I have been busy adding hurricane data screens to customer feeds in Florida and Gulf Coast.

    Support America:

    The first one seems to create a H.264 video then change it to a MPEG-2 stream, seems like a waste of H.264 video processing, when you could just create a MPEG-2 directly.

    The second one is creating a extremely large file for 8 seconds of video, over 6MB.

     

    Support EMEA (Romeo): 

    This looks a little more promising, but is still a bit large at around 3MB for video at 1280x720 size.

    Is there a minimum bitrate for the players?  Also, you said that was for the HDx20, what about other players (210, 1010, etc)?

    I was using "-crf 30" to keep the file size lower, but that seems to not be a good if you say I need to set a 8000k bitrate:

    ffmpeg -r 5 -f image2 -i /var/www/weather/loop/ENX%2d.jpg -vcodec libx264 -level 4.1 -vprofile high -preset veryslow -vf scale=1280:720 -refs 9 -crf 30 -r 30 -y /var/www/weather/ENX.mp4

     

    ffmpeg -r 5 -f image2 -i /var/www/MLBweather/loop/MLB%2d.jpg -vcodec libx264 -level 4.1 -vprofile high -preset veryslow -vf scale=1920:1080 -refs 4 -crf 30 -r 30 -y /var/www/MLBweather/MLB.mp4

    I'll try this for now:

    ffmpeg -r 5 -f image2 -i /var/www/MLBweather/loop/MLB%2d.jpg -vcodec libx264 -level 41 -vf scale=1280:720 -threads 1 -b:v 8000k -coder 0 -r 30 -y /var/www/MLBweather/MLB.mp4

    I'll have to wait to hear back from some of my beta testers, as the HD220 boxes seem to be much more forgiving as to what videos they will play.  I guess I will have to start looking for some older boxes on eBay, so I can look at things on older boxes/firmware.  

    I wish there was a virtual BrightSign player for windows, in which you could pick any of the players and firmware versions possible, to view presentations to see how they would behave with that player/firmware combination.

    John

  • 0
    Avatar
    Lyndon

    There isn't a minimum bitrate. It's just whatever bitrate you're satified with that looks good enough. 

  • 0
    Avatar
    JRB Technical

    There seems to be some sort of minimum bitrate, as when I get down to around 1000k, even though the video quality is acceptable when played with VLC, the HD220 players will just play only black video for about 2 seconds, and then continue to the next item.

    I am still trying to get a better grasp on what will work best for all players, I will try and update with more information when I can.

    John

  • 0
    Avatar
    Romeo

    I never go below 2000k. Unless i'm converting JPG into MPG.

    Generally, I tend to encode video at bitrates between 3000k-15000k

    Romeo

     

     

Please sign in to leave a comment.